I suspect the comments in the article are actually a result of applications developed in-house by on-staff programmers. As time goes on, I find more and more people are familiar with the basics -- word processing, e-mail, browsing, and so on. The non-technical general public still isn't comfortable with the rate of change in the industry, but I don't think as many of them are surprised by it any more. In my experience, the "I-hate-IT" attitude does not mirror the end-user response to basic upgrades to Office and relatively standard tools of that nature.
Instead, we hear that kind of thing about software developed in-house. I believe the "hatred" is a combination of the user never (or rarely) getting what they really want, and frustration when they realize part of the blame rests with them, and IT can't wave a wand and make it easier for them.
The unfortunate part is it's a double-edged sword, because IT often works very hard to give the user what they ASKED for... but what they requested isn't what they WANT. This is not a new problem (and all the CMMing, SixSigmaing, UPMing, RUPing and other process crap in the world isn't helping -- sorry, pet peeve). Being non-technical, the user doesn't know how to ask for the right things. They don't know how to think critically about a design they firmly insisted upon in the early phases of the project, which then turns out to be cumbersome and hard to use. They don't understand how non-technical people like themselves respond to user interface issues, so they demand weird features, and surprise, nobody can figure out how it works when it's deployed. They can't identify bottlenecks in the processing flow, but by god they WANT that flow, and then the bottleneck is IT's fault.
Indeed, my current employer relies heavily on legacy systems, some pieces of which are 30 years old... there are plenty of cases where we're asked to reengineer something, but the business users really aren't even sure how that part of the business actually works! Sometimes the best information we get is, "Then we go to green screen XYZ and put an 'R' in this field, and we don't know what happens next". Then it's up to us to track down how it actually works, backtrack WHY it's done that way, and figure out what WE need to do in the new app... all within the original deadline. Very often in medium and large companies, users have the *final* word when it comes to in-house applications, and very headstrong non-technical people end up making those decisions, so whatever those people want GOES -- and IT gets the blame if those people don't guess correctly. I've seen it at several large companies -- as far as I can tell, it's just The Way.
On the flip side, IT is to blame (sort of) because we are often in the position of having to deny requests, reduce functionality, or take other shortcuts just so we can meet immutable deadlines and budgets. The real world often does nasty things to Dream Projects, and IT is usually the ones who have to deliver the bad news. Time to wake up, your dream is over, and your budget isn't big enough to buy what you've requested.
Finally, there is a nasty bit of hidden overhead that users rarely take into account. When it comes to writing custom in-house software, IT must wear two hats. We need an intimate undestanding of programming, databases, networks, and more esoteric things like good UI design, various levels and types of architecture, the available frameworks and libraries, OOP theory, and so on... but then on top of that, we have to learn the user's job, too. In fact, since our "work product" has to CORRECTLY support, improve, emulate, and/or reproduce their "work product", we often have to learn their job BETTER than they know it. Little details they can ignore, or track down when it becomes an issue -- all must be accounted for UP FRONT before you can safely build a new system to do that job. This requires serious effort, no small amount of brains, dedication, and talent, and often receives no recognition whatsoever. The user thinks IT overstates the difficulty of our jobs (because after all, THEY do their job every day, and "all" we have to do is what they do every day), and consequently their opinion of us goes down at every turn.
This reminds me of my current project. I asked the users how they wanted the software to handle a rare but financially serious condition which I discovered was a possible case given a certain series of inputs. The user was baffled. "But that almost never happens," was the best reply I could get for several *weeks*. They had a very difficult time understanding that we still had to account for these rare cases. I could have taken the easy way out and just thrown up a warning (or some equivalent shortcut), which in this case would have caused a minor disaster at some point in the future -- but instead we eventually (slowly) tracked down the right way to handle the condition, and now it's a documented process which the application addresses transparently. Yet the user's frustration with IT inched up another notch in the process, and somehow, it's *our* fault.
I believe *this* is the kind of scenario that lead to the newspaper article we are discussing, not the occasional MS Office update.
Microsoft's Nathan Myrrhvold made a hilarious statement in an interview recently. When asked for details about Microsoft's processes for changing features in Office, he replied, "Software sucks because users demand it."
The moderation history on this one is amusing. Equal parts insightful and overrated, with a dash of troll. For the moderators who Don't Get It, I wasn't slamming the holiday or even the poor sap who posted the article. The point was, this isn't slashdot material. Newsflash: YOU ARE NOT IN AN AOL CHAT ROOM.
Christ, if the guy had any sense at all, he'd ask her friends or other women before coming to slashdot, which is about the least likely place possible to get a helpful answer when it comes to romance. (Cue some closet-thespian Star Trek junkie to tell us how geekery and romance don't have to be mutually exclusive -- again missing the point.)
Maybe he should try the Turbo-Diesel Registry forum next, those guys are REAL smooth with the ladies.
You know what I want? Cheap, reliable 8 MB disks. I don't need any more than that to carry my work and class documents on. Most of the hype today is on cramming as much information onto the smallest space possible and then charging $40+ *PER CARD*.
Personally I don't understand why we couldn't replace floppies with Compact Flash slots. They're a very popular and well-understood standard, they aren't any slower than floppies (and if you spring for the more expensive cards, they can be a lot faster), it would be cheap to manufacture the "drives" because in CF the "brains" are on the card (which is why CF is far more interesting than Smartmedia or Sony's MonopolySchtick), and an 8MB card as Decimal craves is only about $15... but the same "drive" can easily accept any size device (1GB cards are available today). Seems like a win/win all the way 'round.
I really, really wish CF cards would replace floppies...
But until that day comes, I think it's stupid to get rid of floppy support. I install floppy drives in every machine I build because sooner or later, it comes in handy. Sometimes I'll mount it farther back so I can use the front panel to cover it up -- I admittedly use them THAT rarely -- but as somebody else already said, when I need it, I usually really need it.
Seriously, with a language like C you can feel like you actually know ALL the rules, and it makes you feel safe. With the beasts that are VB.net/VB6 and C#, and the one that Java is becoming, you always have that lingering "What If" in the back of your head.
I agree with you fully when it comes to VB and Java, but C# does not deserve to be lumped into this category. Everybody knows VB wasn't really "designed", it just sort of "happened" over the years. Java had a lot more design work behind it, but it still suffers from weird evolutionary lumps that always "feel wrong" when you're using it. However, C# went through a very long and intensive design period, with more well-defined goals than Java (the set-top-box language), and I believe with a LOT more R&D-phase input from the real world (as anybody who participated in Don Box's.NET listserv discussions can tell you).
C# is a lot like C in that the language itself is limited and well-defined, although not to the extreme basics of a 12-keyword universe like C, owing primarily to the additional keyword overhead needed to express certain modern concepts, many (most?) of which are OOP-related. In that sense it's a little like C++.
For an experienced programmer, the trick is to first understand the.NET class hierarchy (hint: avoid books that harp too heavily on web services buzzwords; web services are just a few pieces of the very large.NET puzzle). Next, understand the C# language on it's own. Most of the books out there seek to tackle both of them simultaneously, and that's a big hinderance to learning, and probably what causes people to make statements like that made by vandel405, above.
Don't judge the subject matter by the quality of instruction...
Slashdot is really going down the tubes. Sorry, using the word "geek" in your paragraph isn't sufficient to make this "news for nerds" and it certainly isn't "stuff that matters".
When I look back over the list of articles I've had rejected by the editors, this kind of pisses me off...
I wish I could give you all of my future moderator points for that one statement.
Our current "architect" hasn't written a line of running code in ten years and can barely keep up with our explanations, yet he's constantly "designing" things, then relying on us to correct his mistakes (in very diplomatic ways that make it look like we're merely suggesting revisions).
Several of the people in my group used to be architects here (before the powers On High decided we only needed one architect). We stayed in the code as often as possible, and consequently the things we wrote and built worked well, as designed, as long as we could keep the Now-Lone Architect's fingers out of the pie.
Now, of course, the people who are really good at both design and programming are being turned into "analysts" where we'll do neither design nor programming, but simply fight with users over poorly defined requirements. Meanwhile our actual skills slowly rust away, and we end up as useless as our architect who can't be bothered to write real code. (Yes, many of us are thinking it may be time to pull up the roots and move on.)
To me, there is no difference. In a perfect world, an architect should simply be a programmer who is really good at what he does, which is write code. To me, writing code implies you also design systems/applications/software/whatever. "Architecting" is just part of the coding process. When I say "I write programs" I don't bother to point out that "I write programs, then I debug them," because debugging is just an aspect of coding -- just like designing or architecting or whatever you want to call it.
I suppose a caveat might be that in very large systems, the design portion can occupy so much time and effort that it warrants people spending most of their time on it, but I can't see any justification for making it an exclusive full-time role. However, some of the most important architectural changes I've seen in systems like this are a result of the top-level guys trying to build their ideas in code (often as a mock up or prototype), so I think even the dedicated architects should be writing code in some capacity. (For reference, to date the largest system I have worked on had a budget in the neighborhood of $42M, so I do have real experience with complex large-scale software projects.)
The traditional answer is that they'll use sound vibration as a power source or possibly vibrations from the natural Brownian motion of the other nanoscale moleclues and dust motes bouncing around alongside them. A power source is definitely one of the major open questions that threatens the concept of free-roaming nanotech (for better or for worse).
Reality is way ahead of Star Trek, at least in terms of dreaming this up.
See generally the Foresight Institute, but in particular: Drexler's books. Very specifically, Engines of Creation mentions this in Chapter 11 and it was first published back in 1986:
"States could become more like organisms by dominating their parts more completely. Using replicating assemblers, states could fill the human environment with miniature surveillance devices."
Nice, huh?
Re:Overseas Outsourcing Destroying Domestic IT Job
on
Lifetime Careers in IT?
·
· Score: 4, Interesting
The bad part is the several-year cycle before the big American companies figure out that off-shore won't work. My employer (over 50K employees) has decided this is the Hot New Thing and is busily shedding developers all 'round the world. We're hiring folks in India at cheerfully insignificant sweatshop rates, and in some cases temporarily bringing them to the US for training (where they're literally kept far away from everyone else during their short stay).
Meanwhile, those of us still doing development are watching in horror as we receive awful newbie-grade code from these off-shore super-genuises, projects slip as communications fail (verbal and connectivity-wise) or the foreigners simply go missing for hours or days at a time, delivery dates come and go and the apps still don't work right -- the stories go on and on.
Now, this isn't a simple case of us having just chosen the wrong company to contract with. As I noted above, we're an enormous company (Fortune 50). We have contracts with many companies in India, and in some cases contracts with American companies who employ off-shore resources in turn. So far, I haven't been able to dig up any success stories. I have been personally involved with (although thankfully not responsible for) quite a few ridiculous failures -- none of which would have occurred if we hadn't been chasing this magical off-shore solution. However, the trend will continue in big companies because middle management has no choice but to show (and therefore report) success, and upper management has no connection with what's really going on day-to-day which means they only rely on the falsely-rosy middle managers' reports.
I should point out that nothing I said about our experiences with the off-shore effort was even a little bit exagerated, either. I have personally been involved in these problems for the last seven or eight months. Here are a few examples I've seen in just the past 45 days or so:
Several weeks ago I recieved a piece of modified code from an off-shore guy who had been described to me as literally a "hot shot" by the proud manager who "owned" him. The code was awful. I ripped out the ninteen lines of new code this guy wrote, and did the same thing in a single line of code. Even our newest programmer trainees would have been capable of doing the same thing. This was all inside a smallish procedure (his modifications more than doubled the size of it), so the leeway for making an excuse was minimal at best. When I questioned this, the contracting company was reportedly "concerned". This same "hot shot" is still writing code on another related project which is now four weeks late and is failing in production.
A friend in an office near me was asked to call an Indian off-shore maintenance programmer who reported an outage in a critical system a few hours before -- this was an emergency, and the fastest way to fix it was to get more info from the person who reported it. This friend of mine starts going through the several phone numbers the off-shore guy had in his auto-sig at the bottom of his e-mail. The first number connected him to someone who didn't speak English. He gave up after being put on hold the third time. The second number connected him to a different non-English-speaking person, and this time he didn't waste time (emergency, remember?). The third number connected him to an Air National Guard airbase switchboard halfway across the US. We never did manage to contact the person who reported the problem.
Last week one of the off-shore guys put a call into networking and convinced them to change a password on a major database component. This had the fortuitous effect of fixing the off-shore's application, but breaking no less than 28 other far more important applications. When we informed the off-shore developer of the consequences of his decision -- which he had been previously advised to avoid by another developer here in the office -- he became angry and has apparently chosen to avoid communicating with us. Because middle management is shielding his "on-shore" rep (I guess you'd call it), we have no choice but to work around this guy to complete the project.
Again, those examples all involve completely different off-shore contracting comapies, unrelated projects, and very different skillsets and responsibilities -- yet they are all characteristic of every report I've heard from co-workers and colleagues at large companies who are enduring this fabulous new technique for managing the bottom line, and similar examples are not hard to find if you go digging around on-line.
In a nutshell, so far it appears the only positive stories come from managers, and they mostly appear to focus on up-front costs -- not quality, or long-term costs. (And in a company this big, believe me, even the worst little application can have a lifespan measured in many years.)
I'll say this much -- it makes me miss working for smaller companies. Sure the pay wasn't as good, and the risk was greater, but at least mid- to small-sized companies simply don't have the option of sustaining the massive waste of exercises like the great off-shore push.
Now before somebody goes and labels me racist or a nationalist or jingoistic or whatever thesaurus.com spits out next, please understand I don't blame these off-shore guys in the least. If I could live on a few bucks a day (I read recently that the average programmer in India makes about $12K) I'd be undercutting the big boys too, and my skillsets be damned -- at that point I'm competing purely on price, and even the shittiest hack-job code still has a chance of running right; certainly business managers aren't going to review it. But so far, in my experience and in the considerable experience of many people I know, the basic quality and skills are sorely lacking, and success stories are few and far between. This is my opinion based on real experience. If my experiences change (and by god I hope it does, given the way our current project is spinning out of control and requiring the stereotypical "heroic efforts" of our now-scorned American programmers) then I'll gladly sit back and agree with the Wisdom of Management. But I've just seen too much failure to deliver in the Great Off-Shore Push, so far.
The long answer is yes, if you can choose to not support retardedly old jvm implementations.
And what if we just write a nice fast fat Windows client? By which I mean to say, I choose not to support retardedly old *NIX-based operating systems.
Before you label this flamebait (I know the trigger fingers are itchy), pause to consider that I believe my statement isn't any more flippant than the assertion made by the parent. If you're going to introduce arbitrary limits, you might as well take the easy one and build something that will run fast and smooth on 95% of the machines on the planet -- good old Win32. Indeed, someone is more likely to know that "I run Windows" or "I run Linux" than "I run a JVM which is compatible with Swing 1.24"...
Listen, Betamax was a better format than VHS, and I knew this. But did I ever go out and buy a Betamax player? No. Why not? Because Blockbuster doesn't carry Beta. Because my friends, my mom, and everyone I know don't have Beta.
Quote from the page linked above: Comparisons between VCRs with similar features showed no significant differences in performance. In fact, most of the differences could only be seen with sensitive instruments, and likely would never show up on most consumer grade television sets. [5] In particular, the qualitative differences between the two formats were less than the differences between any two samples from the same manufacturer. [8]
The Bungi makes several good points. The only thing I would add in support of his argument that IL is not just a mutant form of C# is the fact that IL supports quite a few capabilities which are impossible to express in C#. It's hard to find better evidence than that. For example, the CLR (Common Language Runtime) actually permits return-value overloading, which very few languages have ever supported. C# certainly doesn't. Because support for this is so rare, the CLS (S=specification) actually prohibits using this feature.
Sadly.NET is one of the least-understood and most inappropriately-maligned collection of tools and technologies that I have seen in many years. I mostly blame Microsoft marketing, but I reserve quite a bit of blame for people like the typical/.er who jumps to a conclusion, then defends it with his life.
And since this discussion is actually mostly about Java, I'll say this -- sure.NET has it's problems, but overall is FAR better thought-out and implemented than any Sun has done with Java so far. Again, as I just noted, it does have problems, and I can show you a shopping list of things I don't like about it -- but that pales in comparison to the three miserable years I spent dealing with Java. (Admittedly, I was mostly doing client-side Java, which is an order of magnitude worse than server-side -- but then, client-side Java is the subject under discussion, isn't it?)
And since I dared to cross that line and suggest Java isn't all that, I should close with a plea for you to save your Java flames. This wasn't a "religious" commentary -- I've been there and written tens of thousands of lines of Java code, and I won't go back. I was just expressing an opinion about the quality of the implementation, and I already know full well that many/.ers will disagree with me completely -- and a lot of them will do so without actually knowing anything about.NET.
In any case, I hope my blurb about C# vs. the IL helped clarify that C# is not simply a front-end for IL...
A friend of mine does a lot with GIS at all scales (national region down to cm point sizes), and they rely heavily on GPS. I shot him an e-mail. He isn't aware of any orientation issues (and they're WAY into GPS... they own several of the big $25,000 backpack rigs and so on).
If I solved the GPS problem, drop me a line and I'll send your employer a bill.:D
Ah! I didn't realize it was a "we" thing... it sounded like it was a story you had just heard about somewhere... But as I understand it, it isn't antenna orientation, it's antenna "visibility" -- having a clear path between the antenna and the satellite(s) -- so when it's flying sideways, both antennas should have a lock, right?
That sounds like *half* a story to me... what did they do?
Seems like they'd just add a GPS antenna on the bottom of the plane, too. You could probably get your "very fast" lock with the bottom antenna before you lost your lock with the top one, and vice-versa coming out of the roll.
Many cars -- American, European, and Japanese alike -- have some kind of "trick" for reading codes. Often it's something like a pattern of flicking the ignition between off/run several times. Then the car will either honk or blink turn signals or something like that to indicate the codes that were set. A different pattern usually clears them. These tricks are less likely to be available on newer cars now that OBD is so ubiquitous (and now that consumers/home-tinkerers have caught on) but some models still have them.
Basically, if everyone in the country, or on earth shared one phone system, putting us all under one umbrella from New York and on to far Beijing, a rationalized system would work but you would be very hard pressed to interest anyone in establishing one.
Everyone except we poor bastards who actually have to use the phone system, that is...
Bingo, I was scanning down to see if anybody would catch this.
As many people have noted, just having the tag inside the tire wouldn't identify you in itself, but "They" already have license-plate camera systems. Combine it with a pair of sensors separated by a hundred feet of road, and you have a totally undetectable, fully automated, highly reliable speed trap.
The only real problem would be the well-known "it wasn't me driving" argument, but they can easily address that with a wave of the legislative wand.
DOH! Somebody's been spending a little too much time in UBB forums...:)
Re:Open standards in car electronics ?
on
Cars for Tinkerers?
·
· Score: 2, Informative
OBD, OBDII and the been-proposed-forever OBDIII are more concerned with defining [b]what[/b] to measure and record, versus [b]how[/b] to do it. There are still proprietary interfaces and codes, and the underlying implementation differs wildly from one car to another (even within a single manufacturer). Some things have been reasonably consolidated (for example, there are only a couple of different connector types) but it's far from standardized.
Incidentally, OBDIII is something to fear. They've proposed things like remote-kill capability. I don't trust cops that much...
I prefer to use a real address at the company asking for the address. So on the very, very rare occasions I install the Real player, I'll use abuse@real.com, webmaster@real.com, or something along those lines. Somebody else suggested something like biteme@real.com, but they'll never see that. I suppose if I was feeling more ambitious, I'd try to find an address for the marketing VP or something along those lines.
Besides, Real has always sucked. I've never been able to figure out their popularity. From what I've seen, over the years they seem to consistently have the lowest-quality streaming out there at any given time.
Excellent point about the Clipper chip. Heck, since it seems certain Palladium (or at least trusted computing) requires new hardware, it's really an improved Clipper (improved for "Them" anyway). Hmm. So, did it fail, or is Palladium merely Clipper 2.0?
You're right about critical mass, and I can only hope the same marketing blunders that resulted in them mis-judging.NET adoption time on the desktop has also clouded their Palladium projections. I get the feeling their marketroids don't learn very quickly.
Slashdot Mirror
Instead, we hear that kind of thing about software developed in-house. I believe the "hatred" is a combination of the user never (or rarely) getting what they really want, and frustration when they realize part of the blame rests with them, and IT can't wave a wand and make it easier for them.
The unfortunate part is it's a double-edged sword, because IT often works very hard to give the user what they ASKED for... but what they requested isn't what they WANT. This is not a new problem (and all the CMMing, SixSigmaing, UPMing, RUPing and other process crap in the world isn't helping -- sorry, pet peeve). Being non-technical, the user doesn't know how to ask for the right things. They don't know how to think critically about a design they firmly insisted upon in the early phases of the project, which then turns out to be cumbersome and hard to use. They don't understand how non-technical people like themselves respond to user interface issues, so they demand weird features, and surprise, nobody can figure out how it works when it's deployed. They can't identify bottlenecks in the processing flow, but by god they WANT that flow, and then the bottleneck is IT's fault.
Indeed, my current employer relies heavily on legacy systems, some pieces of which are 30 years old... there are plenty of cases where we're asked to reengineer something, but the business users really aren't even sure how that part of the business actually works! Sometimes the best information we get is, "Then we go to green screen XYZ and put an 'R' in this field, and we don't know what happens next". Then it's up to us to track down how it actually works, backtrack WHY it's done that way, and figure out what WE need to do in the new app... all within the original deadline. Very often in medium and large companies, users have the *final* word when it comes to in-house applications, and very headstrong non-technical people end up making those decisions, so whatever those people want GOES -- and IT gets the blame if those people don't guess correctly. I've seen it at several large companies -- as far as I can tell, it's just The Way.
On the flip side, IT is to blame (sort of) because we are often in the position of having to deny requests, reduce functionality, or take other shortcuts just so we can meet immutable deadlines and budgets. The real world often does nasty things to Dream Projects, and IT is usually the ones who have to deliver the bad news. Time to wake up, your dream is over, and your budget isn't big enough to buy what you've requested.
Finally, there is a nasty bit of hidden overhead that users rarely take into account. When it comes to writing custom in-house software, IT must wear two hats. We need an intimate undestanding of programming, databases, networks, and more esoteric things like good UI design, various levels and types of architecture, the available frameworks and libraries, OOP theory, and so on... but then on top of that, we have to learn the user's job, too. In fact, since our "work product" has to CORRECTLY support, improve, emulate, and/or reproduce their "work product", we often have to learn their job BETTER than they know it. Little details they can ignore, or track down when it becomes an issue -- all must be accounted for UP FRONT before you can safely build a new system to do that job. This requires serious effort, no small amount of brains, dedication, and talent, and often receives no recognition whatsoever. The user thinks IT overstates the difficulty of our jobs (because after all, THEY do their job every day, and "all" we have to do is what they do every day), and consequently their opinion of us goes down at every turn.
This reminds me of my current project. I asked the users how they wanted the software to handle a rare but financially serious condition which I discovered was a possible case given a certain series of inputs. The user was baffled. "But that almost never happens," was the best reply I could get for several *weeks*. They had a very difficult time understanding that we still had to account for these rare cases. I could have taken the easy way out and just thrown up a warning (or some equivalent shortcut), which in this case would have caused a minor disaster at some point in the future -- but instead we eventually (slowly) tracked down the right way to handle the condition, and now it's a documented process which the application addresses transparently. Yet the user's frustration with IT inched up another notch in the process, and somehow, it's *our* fault.
I believe *this* is the kind of scenario that lead to the newspaper article we are discussing, not the occasional MS Office update.
Microsoft's Nathan Myrrhvold made a hilarious statement in an interview recently. When asked for details about Microsoft's processes for changing features in Office, he replied, "Software sucks because users demand it."
It's sad, but true.
Christ, if the guy had any sense at all, he'd ask her friends or other women before coming to slashdot, which is about the least likely place possible to get a helpful answer when it comes to romance. (Cue some closet-thespian Star Trek junkie to tell us how geekery and romance don't have to be mutually exclusive -- again missing the point.)
Maybe he should try the Turbo-Diesel Registry forum next, those guys are REAL smooth with the ladies.
Personally I don't understand why we couldn't replace floppies with Compact Flash slots. They're a very popular and well-understood standard, they aren't any slower than floppies (and if you spring for the more expensive cards, they can be a lot faster), it would be cheap to manufacture the "drives" because in CF the "brains" are on the card (which is why CF is far more interesting than Smartmedia or Sony's MonopolySchtick), and an 8MB card as Decimal craves is only about $15... but the same "drive" can easily accept any size device (1GB cards are available today). Seems like a win/win all the way 'round.
I really, really wish CF cards would replace floppies...
But until that day comes, I think it's stupid to get rid of floppy support. I install floppy drives in every machine I build because sooner or later, it comes in handy. Sometimes I'll mount it farther back so I can use the front panel to cover it up -- I admittedly use them THAT rarely -- but as somebody else already said, when I need it, I usually really need it.
I agree with you fully when it comes to VB and Java, but C# does not deserve to be lumped into this category. Everybody knows VB wasn't really "designed", it just sort of "happened" over the years. Java had a lot more design work behind it, but it still suffers from weird evolutionary lumps that always "feel wrong" when you're using it. However, C# went through a very long and intensive design period, with more well-defined goals than Java (the set-top-box language), and I believe with a LOT more R&D-phase input from the real world (as anybody who participated in Don Box's .NET listserv discussions can tell you).
C# is a lot like C in that the language itself is limited and well-defined, although not to the extreme basics of a 12-keyword universe like C, owing primarily to the additional keyword overhead needed to express certain modern concepts, many (most?) of which are OOP-related. In that sense it's a little like C++.
For an experienced programmer, the trick is to first understand the .NET class hierarchy (hint: avoid books that harp too heavily on web services buzzwords; web services are just a few pieces of the very large .NET puzzle). Next, understand the C# language on it's own. Most of the books out there seek to tackle both of them simultaneously, and that's a big hinderance to learning, and probably what causes people to make statements like that made by vandel405, above.
Don't judge the subject matter by the quality of instruction...
Slashdot is really going down the tubes. Sorry, using the word "geek" in your paragraph isn't sufficient to make this "news for nerds" and it certainly isn't "stuff that matters".
When I look back over the list of articles I've had rejected by the editors, this kind of pisses me off...
Our current "architect" hasn't written a line of running code in ten years and can barely keep up with our explanations, yet he's constantly "designing" things, then relying on us to correct his mistakes (in very diplomatic ways that make it look like we're merely suggesting revisions).
Several of the people in my group used to be architects here (before the powers On High decided we only needed one architect). We stayed in the code as often as possible, and consequently the things we wrote and built worked well, as designed, as long as we could keep the Now-Lone Architect's fingers out of the pie.
Now, of course, the people who are really good at both design and programming are being turned into "analysts" where we'll do neither design nor programming, but simply fight with users over poorly defined requirements. Meanwhile our actual skills slowly rust away, and we end up as useless as our architect who can't be bothered to write real code. (Yes, many of us are thinking it may be time to pull up the roots and move on.)
To me, there is no difference. In a perfect world, an architect should simply be a programmer who is really good at what he does, which is write code. To me, writing code implies you also design systems/applications/software/whatever. "Architecting" is just part of the coding process. When I say "I write programs" I don't bother to point out that "I write programs, then I debug them," because debugging is just an aspect of coding -- just like designing or architecting or whatever you want to call it.
I suppose a caveat might be that in very large systems, the design portion can occupy so much time and effort that it warrants people spending most of their time on it, but I can't see any justification for making it an exclusive full-time role. However, some of the most important architectural changes I've seen in systems like this are a result of the top-level guys trying to build their ideas in code (often as a mock up or prototype), so I think even the dedicated architects should be writing code in some capacity. (For reference, to date the largest system I have worked on had a budget in the neighborhood of $42M, so I do have real experience with complex large-scale software projects.)
The traditional answer is that they'll use sound vibration as a power source or possibly vibrations from the natural Brownian motion of the other nanoscale moleclues and dust motes bouncing around alongside them. A power source is definitely one of the major open questions that threatens the concept of free-roaming nanotech (for better or for worse).
See generally the Foresight Institute, but in particular: Drexler's books. Very specifically, Engines of Creation mentions this in Chapter 11 and it was first published back in 1986:
"States could become more like organisms by dominating their parts more completely. Using replicating assemblers, states could fill the human environment with miniature surveillance devices."
Nice, huh?
Meanwhile, those of us still doing development are watching in horror as we receive awful newbie-grade code from these off-shore super-genuises, projects slip as communications fail (verbal and connectivity-wise) or the foreigners simply go missing for hours or days at a time, delivery dates come and go and the apps still don't work right -- the stories go on and on.
Now, this isn't a simple case of us having just chosen the wrong company to contract with. As I noted above, we're an enormous company (Fortune 50). We have contracts with many companies in India, and in some cases contracts with American companies who employ off-shore resources in turn. So far, I haven't been able to dig up any success stories. I have been personally involved with (although thankfully not responsible for) quite a few ridiculous failures -- none of which would have occurred if we hadn't been chasing this magical off-shore solution. However, the trend will continue in big companies because middle management has no choice but to show (and therefore report) success, and upper management has no connection with what's really going on day-to-day which means they only rely on the falsely-rosy middle managers' reports.
I should point out that nothing I said about our experiences with the off-shore effort was even a little bit exagerated, either. I have personally been involved in these problems for the last seven or eight months. Here are a few examples I've seen in just the past 45 days or so:
Again, those examples all involve completely different off-shore contracting comapies, unrelated projects, and very different skillsets and responsibilities -- yet they are all characteristic of every report I've heard from co-workers and colleagues at large companies who are enduring this fabulous new technique for managing the bottom line, and similar examples are not hard to find if you go digging around on-line.
In a nutshell, so far it appears the only positive stories come from managers, and they mostly appear to focus on up-front costs -- not quality, or long-term costs. (And in a company this big, believe me, even the worst little application can have a lifespan measured in many years.)
I'll say this much -- it makes me miss working for smaller companies. Sure the pay wasn't as good, and the risk was greater, but at least mid- to small-sized companies simply don't have the option of sustaining the massive waste of exercises like the great off-shore push.
Now before somebody goes and labels me racist or a nationalist or jingoistic or whatever thesaurus.com spits out next, please understand I don't blame these off-shore guys in the least. If I could live on a few bucks a day (I read recently that the average programmer in India makes about $12K) I'd be undercutting the big boys too, and my skillsets be damned -- at that point I'm competing purely on price, and even the shittiest hack-job code still has a chance of running right; certainly business managers aren't going to review it. But so far, in my experience and in the considerable experience of many people I know, the basic quality and skills are sorely lacking, and success stories are few and far between. This is my opinion based on real experience. If my experiences change (and by god I hope it does, given the way our current project is spinning out of control and requiring the stereotypical "heroic efforts" of our now-scorned American programmers) then I'll gladly sit back and agree with the Wisdom of Management. But I've just seen too much failure to deliver in the Great Off-Shore Push, so far.
And what if we just write a nice fast fat Windows client? By which I mean to say, I choose not to support retardedly old *NIX-based operating systems.
Before you label this flamebait (I know the trigger fingers are itchy), pause to consider that I believe my statement isn't any more flippant than the assertion made by the parent. If you're going to introduce arbitrary limits, you might as well take the easy one and build something that will run fast and smooth on 95% of the machines on the planet -- good old Win32. Indeed, someone is more likely to know that "I run Windows" or "I run Linux" than "I run a JVM which is compatible with Swing 1.24"...
http://www.urbanlegends.com/products/beta_vs_vhs.h tml
Quote from the page linked above:
Comparisons between VCRs with similar features showed no significant differences in performance. In fact, most of the differences could only be seen with sensitive instruments, and likely would never show up on most consumer grade television sets. [5] In particular, the qualitative differences between the two formats were less than the differences between any two samples from the same manufacturer. [8]
Just a pet peeve of mine. :)
What I saw was 1.3 megapixels -- 1280 x 1024, with an optional 640 x 480 mode. Where did you see 320 x 240?
The camera add-on is here: JBM Camera 100
Total cost would be about $490.
Sadly .NET is one of the least-understood and most inappropriately-maligned collection of tools and technologies that I have seen in many years. I mostly blame Microsoft marketing, but I reserve quite a bit of blame for people like the typical /.er who jumps to a conclusion, then defends it with his life.
And since this discussion is actually mostly about Java, I'll say this -- sure .NET has it's problems, but overall is FAR better thought-out and implemented than any Sun has done with Java so far. Again, as I just noted, it does have problems, and I can show you a shopping list of things I don't like about it -- but that pales in comparison to the three miserable years I spent dealing with Java. (Admittedly, I was mostly doing client-side Java, which is an order of magnitude worse than server-side -- but then, client-side Java is the subject under discussion, isn't it?)
And since I dared to cross that line and suggest Java isn't all that, I should close with a plea for you to save your Java flames. This wasn't a "religious" commentary -- I've been there and written tens of thousands of lines of Java code, and I won't go back. I was just expressing an opinion about the quality of the implementation, and I already know full well that many /.ers will disagree with me completely -- and a lot of them will do so without actually knowing anything about .NET.
In any case, I hope my blurb about C# vs. the IL helped clarify that C# is not simply a front-end for IL...
A friend of mine does a lot with GIS at all scales (national region down to cm point sizes), and they rely heavily on GPS. I shot him an e-mail. He isn't aware of any orientation issues (and they're WAY into GPS... they own several of the big $25,000 backpack rigs and so on). If I solved the GPS problem, drop me a line and I'll send your employer a bill. :D
Ah! I didn't realize it was a "we" thing... it sounded like it was a story you had just heard about somewhere... But as I understand it, it isn't antenna orientation, it's antenna "visibility" -- having a clear path between the antenna and the satellite(s) -- so when it's flying sideways, both antennas should have a lock, right?
Seems like they'd just add a GPS antenna on the bottom of the plane, too. You could probably get your "very fast" lock with the bottom antenna before you lost your lock with the top one, and vice-versa coming out of the roll.
Many cars -- American, European, and Japanese alike -- have some kind of "trick" for reading codes. Often it's something like a pattern of flicking the ignition between off/run several times. Then the car will either honk or blink turn signals or something like that to indicate the codes that were set. A different pattern usually clears them. These tricks are less likely to be available on newer cars now that OBD is so ubiquitous (and now that consumers/home-tinkerers have caught on) but some models still have them.
Everyone except we poor bastards who actually have to use the phone system, that is...
As many people have noted, just having the tag inside the tire wouldn't identify you in itself, but "They" already have license-plate camera systems. Combine it with a pair of sensors separated by a hundred feet of road, and you have a totally undetectable, fully automated, highly reliable speed trap.
The only real problem would be the well-known "it wasn't me driving" argument, but they can easily address that with a wave of the legislative wand.
Read into it whatever you want, but it's really as simple as that. It's FUN. Period.
DOH! Somebody's been spending a little too much time in UBB forums... :)
Incidentally, OBDIII is something to fear. They've proposed things like remote-kill capability. I don't trust cops that much...
Besides, Real has always sucked. I've never been able to figure out their popularity. From what I've seen, over the years they seem to consistently have the lowest-quality streaming out there at any given time.
You're right about critical mass, and I can only hope the same marketing blunders that resulted in them mis-judging .NET adoption time on the desktop has also clouded their Palladium projections. I get the feeling their marketroids don't learn very quickly.