If you look at "safety" as only one dimension (weight) than is an SUV really that much "safer?" What if you're rear-ended by a 40,000 pound tractor-trailer? Or worse, T-boned? Of course the SVU is "safer" than a car by this measure, but by how much?
If you take a more holistic view of safety and include the vehicle's manuverability (ability to avoid and accident), plus the driver's skill level, small cars may actually be just as "safe" or even "safer" than an SUV. Inexperienced drivers have a MUCH higher incidence of accidents than experienced ones, and sports cars can corner more sharply and come to a stop in a much shorter distance, whereas SUVs take a much longer distance to come to a stop, and have a nasty tendency to roll if they corner too sharply.
So, take the extra money you're going to have to spend on an SUV and sign-up for some defensive driving classes.
The philanthropic W. K. Kellogg Foundation has a similar arrangement. The foundation receives funds from the W.K. Kellogg Foundation Trust, which is the majority shareholder of Kellogg's Corporation.
Instead of trying to stop the debating, why not set up a few subprojects for each of the warring factions and see what emerges? Let your user community try each one out, and see which they like better.
802.11 networks have spread rapidly in the residential area, and it is common for neighbors to receive signals from each other's home wireless networks. PERM allows residents to leverage such an opportunity to improve their last-mile Internet connectivity, at no additional cost, by pooling their Internet accesses together. PERM is practical in that it does not rely on support from the network infrastructure in terms of advanced naming scheme or proxy, the remote host in terms of new transport protocols, or the end-user in terms of explicit application feedback or configuration. Instead, PERM employs automated on-line analysis of the user's networking behaviors, and exploits the identified patterns to achieve high-performance scheduling at the flow level. PERM is also highly usable for normal residential users. It preserves a user's privacy and security, and mitigates the free-riding problem. We have implemented PERM for Linux clients and the open-source Linksys wireless router.
Compares two dates for equality. The result is true if and only if the argument is not null and is a Date object that represents the same point in time, to the millisecond, as this object.
Thus, two Date objects are equal if and only if the getTime method returns the same long value for both.
The millisecond values of Date objects are the time in UTC, so they are not impacted by time zones, DST, etc. The current time of the JVM is the time of the host computer.
Also keep in mind that creating a C++ object in the stack is 25 times faster than creating a Java object (even with the server VM) according to my benchmarks...
If there's one thing we should all know by now, it's that benchmarking the performance of Java bytecode running on a JVM with a Just in Time compiler is very, very tricky. Modern JVMs may apply optimizations to your code while it's running, based on the way the code is actually being used.
...when requests come up (on an almost weekly bases) to change the code and rework specific modules entirely at the whim of management, things start to get complicated.
Willy-nilly changes are a huge risk to your success. Your management needs to focus on a goal, and let you reach it. It's like running twenty-five miles of a marathon and then having them move the finish line one you: Pretty soon, you drop dead from exhaustion. You can help them focus by making a list of all the stuff that they don't keep changing their minds about. Get that stuff built first. You can add window dressing later.
...as this project grows, I am reaching my mental limits of recalling and remembering what each method in that application does and why I even wrote some of them in the first place.
This is exactly why you want unit tests in place. The unit tests are your assumptions about how the code is supposed to behave, expressed in code. The ability to rerun hundreds or thousands of these tests very quickly against the code base, to make sure that things still work the same way as when you wrote them is a huge time saver.
By definition, unit tests don't test the assembly of the units, just the units themselves, so you'll still need to perform other types of testing to get complete coverage (funtional, integration, etc.) A good tester (i.e. someone who could write the program themselves but enjoys breaking code more than making it) can pay huge dividends here.
I've never understood why there isn't some kind of auto-completion feature in chat programs. For example, if I typed brb follwed by tab, the output would be I'll be right back. That way, the chat program wouldn't be making people far too comfortable reading weird abbreviations.
Re:New language does not equal better programmers
on
IronPython 1.0 is Born
·
· Score: 1
It is called training.
Training that, I assume, your company doesn't offer, even in VB, right? Otherwise, I'd assume that the poorly performing programmers would be receiving training to bring their coding skills up to snuff.
I first learned C. Then I learned C++ and became a better all around programmer. I then learned PHP, Java, and C#. Each new language required me to learn new techniques and made me a better programmer.
Clearly, you care about your craft enough to go and learn new langauges, and to improve your skills. But we're talking about the poorly performing VB programmers at your company.
VB is/was such a simple language it didn't really require much learning and it certainly didn't require much knowledge about programming techniques and algorithms.
Is VB such a simple language that it prevents you from learning programming techniques and algorithms? If one of your VB programmers were actually interested in improving their coding, would VB become a roadblock? Would they be unable to implement an algorithm in VB, for exampe?
Requiring them to get training in a new language with new programming techniques and algorithms will make them better.
You're probably right that they'll get a little better. But I'd suspect providing training in new programming techniques and algorithms without switching languages will help quite a bit.
There is also the possibility that a lot of those vb-only "programmers" will not have the aptitude to learn new languages and techniques, thus weeding out the bad apples.
If your management hired them in the first place, what makes you think that the same managers will do a better of hiring their replacements?
Someone said: "There are no technology problems, just people problems." The point is, you're blaming VB (the technolgy) for the poor output of some programmers (the people), and now you're suggesting changes to the people side of the equation (through triaining or dismissals) part of the solution. Shouldn't the team be able to switch languages without new training or staff changes, and see the quality of their work improve?
I actually find the multi-language of of the CLR to be a negative. I work at a fortune 500 and most of us use C# and/or Java. There are a few groups of "programmers" that have always been VB-only/ASP-Only "programmers". They have really no understanding of programming maintainable code.
I'm not sure I follow your logic... How would forcing your poor programmers to switch languages make them better programmers? I think the best that you could hope for is that they'd still be poor programmers, just in a different language.
Besides, the Java Virtual Machine has justasmany, if not more lanugages available for it than the CLR. (Note that I said "available" not "supported.")
This is a kind of neat idea, except, of course, if I have CSS that does something with, oh, say, a class of "dtstart". Sure, it's easy to recognise that ".vevent >.url >.dtstart" is a microformat data item for an hCalendar, but if I'm already using "dtstart" or "url" regularly in my markup so I can apply styles to those kinds of things, I'm pretty much SOL.
Not necessarily. If the existing style rules don't look ugly when applied to the microformat then no problem. Otherwise, do exactly what you said: Add style rules for.vevent >.url >.dtstart and for.vevent >.url
The iPod/iTunes system will move into a niche with Macintosh computers because Steve Jobs has again stuck with closed architecture and total control.
If we view the iPod as just another appliance, then there no evidence to back this claim. There are millions of televisions, DVD players, stereo stytems, etc. sold every year that do not have an open architecture. Most people do not need access to the architecture of these devices. They just want them to work when they use them.
On the other hand, if we view the iPod as a Personal Server gussied up to look like an music player, then there may be something to this. The real question is how closed is the iPod platform, and how quickly could Apple open it if or when they needed to?
So instead of 40 employees working less hours and having more free time, we have 10 employees working longer hours doing the work 40 employees did then.
So those thirty people now have the time to solve a new class of problems, and they go out and create whole new industries.
Today's pace of change means that we're looking at a lifetime of learning new skills instead of a lifetime of screwing the same nut onto the same bolt.
According to the article linked to by arsdigita, this is not about.NET at all, but about SAP. It looks to me like Oracle is actively porting its middleware to Java in order to claim that they are easier to develop for and less proprietary than SAP's counterparts. Sun and Oracle will promote each other's non-competing products as a part of this deal.
The guy turned around and sued the company to be recognized as an employee because he wanted the benifits.
Yes. He was arguing that he was a Common Law Employee, that is, he didn't control when and where he worked, which tools he used to perform his work, etc.
Lately, I've come to realize that management has a profound influence on code quality. Simply saying "let's just throw a bunch of great programmers at it" won't do. First of all, you're fighting the bell curve. On average, the programmer you hire will be... average. Well, not quite. They will likely "fit in" to your culture, and will perform about as good as everyone else on the team. Since management is responsible for the culture, it's essential that they do everything they can to make the team as productive as possible, otherwise, even the best programmers probably won't help, and if they do help, they'll probably last six months and then quit in frustration, having been made horribly unproductive.
In fact, I'd argue that a team can be made far more productive just by changing the manager. (Like that'll ever happen.)
Sure, and diet and exercise help control insulin levels in diabetics, but you don't hear anyone telling them they shouldn't use insulin if it's required.
Seriously, the whole pharmaceutical company consipiracy theory thing is getting really, really tired.
For a community that touts their "above average" intelligence, Slashdotters are showing more than just a little ignorance of what depression and mental illness really are.
Please, take a look at the Mayo Clinic's Very brief description of depression before you post more uninformed blather.
Given the diversity of religions (mono-, poly-, a-), gender-roles (mammals, insects, etc.), work and play here on planet earth, I'd say anything is possible.
Is it me, or do the Japanese automakers take an "AND" approach to engineering, as in "high-performance AND low emissions." In contrast, the U.S. automakers seem to always take the "OR" approach.
If there is nothing you can do to improve the relationship between you and your employer in your final days, leave now, if you can. By staying you are only incresing the probability that something you do will make the relationship even worse. I doubt you'll be using this guy as a charater reference, anyway.
Abraham Lincoln asked: "If you call a leg a tail, how many tails does a dog have?"
An employer-employee relationship exists when that relationship satisifes certain conditions. It has nothing to do with who pays you, or how your are paid.
Some of the conditions are: -if you are told when and where to work -if your are told how to do the job, rather than deciding for yourself. There are others. Consult your lawyer.
So, how many tails does a dog have? "One. Calling a leg a tail doesn't make it so."
Slashdot Mirror
If you look at "safety" as only one dimension (weight) than is an SUV really that much "safer?" What if you're rear-ended by a 40,000 pound tractor-trailer? Or worse, T-boned? Of course the SVU is "safer" than a car by this measure, but by how much?
If you take a more holistic view of safety and include the vehicle's manuverability (ability to avoid and accident), plus the driver's skill level, small cars may actually be just as "safe" or even "safer" than an SUV. Inexperienced drivers have a MUCH higher incidence of accidents than experienced ones, and sports cars can corner more sharply and come to a stop in a much shorter distance, whereas SUVs take a much longer distance to come to a stop, and have a nasty tendency to roll if they corner too sharply.
So, take the extra money you're going to have to spend on an SUV and sign-up for some defensive driving classes.
The philanthropic W. K. Kellogg Foundation has a similar arrangement. The foundation receives funds from the W.K. Kellogg Foundation Trust, which is the majority shareholder of Kellogg's Corporation.
Instead of trying to stop the debating, why not set up a few subprojects for each of the warring factions and see what emerges? Let your user community try each one out, and see which they like better.
I'm amazed that nobody has mentioned the Practical End-host collaborative Residential Multihoming framework (PERM). From the site:
If there's one thing we should all know by now, it's that benchmarking the performance of Java bytecode running on a JVM with a Just in Time compiler is very, very tricky. Modern JVMs may apply optimizations to your code while it's running, based on the way the code is actually being used.
Take a look at the slides from Dr. Clifford Click's presentation Java Technology Performance Myths Exposed (PDF) and at Performance Considerations for Run-Time Technologies in the .NET Framework by Emmanuel Schanzer to get an idea of how your code is manipulated at runtime to increase performance. Also, Performance of Java versus C++ by J.P.Lewis and Ulrich Neumann discusses some of the difficulties of benchmarking Java.
Willy-nilly changes are a huge risk to your success. Your management needs to focus on a goal, and let you reach it. It's like running twenty-five miles of a marathon and then having them move the finish line one you: Pretty soon, you drop dead from exhaustion. You can help them focus by making a list of all the stuff that they don't keep changing their minds about. Get that stuff built first. You can add window dressing later.
This is exactly why you want unit tests in place. The unit tests are your assumptions about how the code is supposed to behave, expressed in code. The ability to rerun hundreds or thousands of these tests very quickly against the code base, to make sure that things still work the same way as when you wrote them is a huge time saver.
By definition, unit tests don't test the assembly of the units, just the units themselves, so you'll still need to perform other types of testing to get complete coverage (funtional, integration, etc.) A good tester (i.e. someone who could write the program themselves but enjoys breaking code more than making it) can pay huge dividends here.
I've never understood why there isn't some kind of auto-completion feature in chat programs. For example, if I typed brb follwed by tab, the output would be I'll be right back. That way, the chat program wouldn't be making people far too comfortable reading weird abbreviations.
Training that, I assume, your company doesn't offer, even in VB, right? Otherwise, I'd assume that the poorly performing programmers would be receiving training to bring their coding skills up to snuff.
Clearly, you care about your craft enough to go and learn new langauges, and to improve your skills. But we're talking about the poorly performing VB programmers at your company.
Is VB such a simple language that it prevents you from learning programming techniques and algorithms? If one of your VB programmers were actually interested in improving their coding, would VB become a roadblock? Would they be unable to implement an algorithm in VB, for exampe?
You're probably right that they'll get a little better. But I'd suspect providing training in new programming techniques and algorithms without switching languages will help quite a bit.
If your management hired them in the first place, what makes you think that the same managers will do a better of hiring their replacements?
Someone said: "There are no technology problems, just people problems." The point is, you're blaming VB (the technolgy) for the poor output of some programmers (the people), and now you're suggesting changes to the people side of the equation (through triaining or dismissals) part of the solution. Shouldn't the team be able to switch languages without new training or staff changes, and see the quality of their work improve?
I'm not sure I follow your logic... How would forcing your poor programmers to switch languages make them better programmers? I think the best that you could hope for is that they'd still be poor programmers, just in a different language.
Besides, the Java Virtual Machine has just as many, if not more lanugages available for it than the CLR. (Note that I said "available" not "supported.")
If we view the iPod as just another appliance, then there no evidence to back this claim. There are millions of televisions, DVD players, stereo stytems, etc. sold every year that do not have an open architecture. Most people do not need access to the architecture of these devices. They just want them to work when they use them.
On the other hand, if we view the iPod as a Personal Server gussied up to look like an music player, then there may be something to this. The real question is how closed is the iPod platform, and how quickly could Apple open it if or when they needed to?
IIRC, the helicopter in Blue Thunder wasn't meant to be fiction but actually based on technology that existed when the movie was made.
Read the source (article), Luke!
According to the article linked to by arsdigita, this is not about .NET at all, but about SAP. It looks to me like Oracle is actively porting its middleware to Java in order to claim that they are easier to develop for and less proprietary than SAP's counterparts. Sun and Oracle will promote each other's non-competing products as a part of this deal.
Yes. He was arguing that he was a Common Law Employee, that is, he didn't control when and where he worked, which tools he used to perform his work, etc.
For a clearer description of this, please read the Internal Revenue Service publication Independent Contractors vs. Employees
Yes. I believe that (now defunct?) Garbage magazine dubbed these EPVs: "Elsewhere Polluting Vehicles."
Lately, I've come to realize that management has a profound influence on code quality. Simply saying "let's just throw a bunch of great programmers at it" won't do. First of all, you're fighting the bell curve. On average, the programmer you hire will be... average. Well, not quite. They will likely "fit in" to your culture, and will perform about as good as everyone else on the team. Since management is responsible for the culture, it's essential that they do everything they can to make the team as productive as possible, otherwise, even the best programmers probably won't help, and if they do help, they'll probably last six months and then quit in frustration, having been made horribly unproductive.
In fact, I'd argue that a team can be made far more productive just by changing the manager. (Like that'll ever happen.)
Sure, and diet and exercise help control insulin levels in diabetics, but you don't hear anyone telling them they shouldn't use insulin if it's required. Seriously, the whole pharmaceutical company consipiracy theory thing is getting really, really tired.
For a community that touts their "above average" intelligence, Slashdotters are showing more than just a little ignorance of what depression and mental illness really are. Please, take a look at the Mayo Clinic's Very brief description of depression before you post more uninformed blather.
Given the diversity of religions (mono-, poly-, a-), gender-roles (mammals, insects, etc.), work and play here on planet earth, I'd say anything is possible.
Is it me, or do the Japanese automakers take an "AND" approach to engineering, as in "high-performance AND low emissions." In contrast, the U.S. automakers seem to always take the "OR" approach.
Here's what's included in Atlas, according to Scott Guthrie's blog:
This will be very popular, assuming that they deliver this with a reasonable API.
If there is nothing you can do to improve the relationship between you and your employer in your final days, leave now, if you can. By staying you are only incresing the probability that something you do will make the relationship even worse. I doubt you'll be using this guy as a charater reference, anyway.
Abraham Lincoln asked: "If you call a leg a tail, how many tails does a dog have?"
An employer-employee relationship exists when that relationship satisifes certain conditions. It has nothing to do with who pays you, or how your are paid.
Some of the conditions are:
-if you are told when and where to work
-if your are told how to do the job, rather than deciding for yourself.
There are others. Consult your lawyer.
So, how many tails does a dog have? "One. Calling a leg a tail doesn't make it so."