this layer will have to be read, parsed and then the file run with some controls deactivated in Microsoft Windows Media Player(tm) and nothing else. Any other software will gladly ignore it (unless MS intercepts this at the OS level) and burn it just fine.
No, I think the intent is that an audio CD player sees one "layer" of bits, and a CD-ROM drive sees an entirely different "layer" of bits. The latter would be a bunch of files in WMP format, safely readable by anyone... so long as "anyone" listens to the music on only one machine, and runs what Microsoft considers to be a mainstream operating system. A PC would never see the "real music bits" an audio system sees (and an audio system would never see the WMP bits).
... in my experience, good use of forward declarations (to avoid unrequired chains of #include), combined with simply putting less in each.c file is a lot more effective than adding the complication of precompiled headers into your build process.
My experience is just the opposite.
Putting less into each.c file (so that changing a.c file requires less to be recompiled) is only useful if most of the code you need to compile is in.c files. Unfortunately, even with forward declarations, every.c file is likely to have thousands (or tens of thousands) of source from all the.h files that are (recursively) included; that's where the bulk of the compiled code is. Unless each of the smaller.c files can include significantly fewer.h files than the larger.c files could (which, in my experience, they can't), then doubling the number of.c files roughly doubles the amount of source code (.c files plus all the.h files per.c file) needed to compile a product.
I haven't had a lot of luck with precompiled headers, either. (Context: a project with a hundred source files spread across a dozen directories, totalling about fifty thousand lines of source.)
Best solution I know of for C++: Use as many forward declarations as you can, periodically trim your include directives, and have relatively large.c files. Each includes a lot of.h source, but this reduces the total bulk of what comes out of the preprocessor.
I know of C++ systems that take a CPU week to build because of these issues!
Note that Java doesn't have this problem, or the problem of teaching your makefile about header file dependencies. (Not important enough to get all projects to switch from C or C++, but among the reasons that some projects should.)
Bell Telephone Laboratories was issued a patent in 1979 for the setuid (set user ID) bit in the Unix file system. This patent was no doubt transferred along with the rest of "Unix," from AT&T to Unix International to Novell to SCO.
This patent was never enforced, and should have expired by now. Hypothetically, there could be some other similar intellectual propery "landmines" in the very specification of Unix-like systems.
Recently I was given some Java code and asked to port it to C++. At the time, my knowledge of Java was pretty much at the "Where is the bathroom, please?" level. In particular, I could see where the reflection package was being used, but not how the program went from one particular bit of client code to another. I loaded the code into the debugger, started the program, set a few breakpoints at the really puzzling parts, and ran through it a few times. At that point, the student achieved enlightenment.
As I've gotten more skilled at software development, I've become better able to read a bunch of code and analyze it... and become more likely to run the darned thing and see what it really does. Sometimes, in this job, inspection is theory, and debugging and testing are experimentation.
An MIT animal physiologist is said to have told his students, "The animal is always right. When in doubt, ask the animal." Ask the code; the code is always right. (It may be right in knowing what the bug is, but sometimes that's what you need to ask.)
P.S.: I've learned more Java since then. Running some programs through its debugger was one good way to help learn it.
Meyers: "... we have templates in C++, but there's no way to write user interfaces or talk to databases. Java has no templates, but you can write user interfaces up the wazoo and you can talk to databases with no trouble at all."
NetMeeting doesn't work through NAT or firewalls
on
Online Tutoring?
·
· Score: 4, Informative
NetMeeting is a software implementation of an H.323 (voice over IP, "VoIP") endpoint. That protocol opens UDP ports dynamically (e.g., part of the session says, "okay, the next part of this session will happen on my port 1923"). Firewalls hate that. NAT routers do even worse, since the IP address and port of the new connection get translated (i.e, munged).
Why would this be a problem? What if the dorm rooms are behind a firewall? What if the whole university is behind a firewall, and someone (a commuter, not a resident student) wants to connect from home? What if university doesn't have a firewall, but the commuting student does at home (cable modem + Linksys)? NetMeeting won't work in those situations. There are descriptions of how to make it work, but they're complicated enough to be useless to almost everyone. The Windows XP VoIP platform is based on SIP, which has similar problems.
The only solutions are: use a firewall and/or NAT router that understands your VoIP protocol (I only know one that handles H.323, and I know of work on SIP for this but haven't heard of any solutions), avoid firewalls, or avoid VoIP.
Source: Four and a half years developing a major commercial H.323 gatekeeper (call control software), which interoperated with terminals (including NetMeeting) and gateways.
Is the degree of customer involvement that they expect.... How many clients are willing to assign an employee to work with/at the software/website vendor full-time?
It makes more sense for in-house development projects, where the "customer" already has an office in the building, and just reports to the programming bullpen* rather than to his/her own office/cube/whatever. The first serious XP development effort was an in-house project called Chrysler Comprehensive Compensation; the "customer" was the payroll department, and relatively easy to get "on site." XP has been strongly influenced by the patterns from that project.
*A lot of XP gurus like open space plans for development teams. YMMV.
The most common alternative to Customer On Site is Victorian Novel Requirements: the customers write hundreds (thousands) of pages of requirements (which can take as many staff hours as Customer On Site), throw the book "over the wall" to the development staff, and then complain when they didn't want what they originally asked for.
I agree Customer On Site may not always work. Lots of constant communications with the customer, in some form or another, is necessary for any successful software project, XP or otherwise.
I've always found the whole "buddy programming" concept (part of XP), where one person watches the other code and points out errors, to be incredibly annoying.... you're wasting a good programmer having them sit there and call things out
Right, that would be dumb; but that's not what XP calls for.
Pair programming calls for two people working together. At any given instant, only one person has the keyboard and mouse; but they get passed back and forth, and the person who's not typing is doing a lot more than "watching." It's as natural as two people designing together on a blackboard, once you get the hang of it.
Does it work? There's lots of evidence it's worked for a lot of people who've tried it (including me).
Does it always work, for everyone, in every project? That's an open question. The only way it'll be answered is if more people try to program in pairs.
The definitive book on the subject is Pair Programming Illuminated by Laurie Williams and Robert Kessler (Amazon.com, BN.com); recommended.
Pair programming is not the first XP practice a project should try. Could a project get a lot of value out of XP without doing pair programming? I think yes, and I'm an advocate of programming in pairs; the question is open to debate.
"We're not locked into these rules... We're just testing them out."
Translation: "We're just seeing how we can push consumers before they start pushing back... and whether we have enough power so they can't really push back."
Whether it does or doesn't... if you think inheritance is the biggest advantage of C++ over C, then you are (as politely as I can put this) completely ignorant of the language. Take a look at Koenig and Moo's Accelerated C++ (Amazon.com, BN.com); they don't even talk about defining classes until chapter 11, and inheritance is delayed until chapter 13 (in a total of sixteen chapters plus two appendices).
C++ provides:
a string class that's far more resistant to buffer overflows than char*s;
powerful data structure mechanisms (built in variable sized arrays and linked lists you no longer have to code yourself, plus sets and associative arrays likely better than you'd throw together),
lots of help with memory management,
and good ways of abstracting data (and operations) so the design is fairly well communicated by the code itself.
These can all be big productivity boosts.
If I want to pass around function points, I'll pass around function pointers
C++ does not prevent you from doing so. But if you want to do something other than pass around function pointers, there's no way to do so in C that clearly expresses your intent. There are several ways to do so in C++, not even counting inheritance.
You think inheritance is a fatal disease for software? Fine; don't use it. Don't define a single member as virtual or protected, and it'll be pretty tough for anyone to usefully inherit from your classes.
[From another posting you made:]
I have yet to see anything which can be done with templates which can't be done with either preprocessor code or more function pointers.
That's an admission of your ignorance, not a valid criticism of the language.
Can it all be done in C? Sure. Can it be done in assembler? Of course. Can it be done in C++, with less effort, and in a way that better communicates the programmer's intention? In my experience, absolutely.
People and projects sometimes stumble when moving from C to C++... or when adopting any new technology. There are strategies that often work, and others that always fail. Want to talk about them?
I've read what you've said (here and elsewhere) about C++. You don't see how it can give programmers an advantage. Okay; but then you attack it as if no one should use it, rather than as if you tried to use it and failed. (Honest, there's a tone of aggressive defensiveness in your postings that makes your position come across as more emotional than rational. That tone seriously undermines your arguments.)
No one's going to force you to program in C++; but no one's going to force managers to hire you for projects using C++. You won't succeed in getting others to be restricted by your limitations. Your choice, your consequences.
There's some web site somewhere that has been keeping track of this ever month (week?) over the past few years. (Sorry, I've forgotten the URL, and can't find it with Google.)
My recent experience is that, for every C++ job, there are between two and two-and-a-half Java jobs.
Joel is about 50% of the way to inventing Extreme Programming (or yet another Agile methodology) on his own.
Not really. Since my posting, I've been thinking more about what Joel says there:
Your tasks should be measured in hours, not days.... it forces you to design the damn feature.
It's very close to, "Do all the analysis, do all the design (down to the level of specifying subroutines), do a little estimating on top of that, and you're done."
Traditional methods would say you spend more than 50% of your time doing analysis and design; do you want to get that far into the project before you know how long it's going to take?
XP would say Big Design Up Front doesn't work, but the Planning Game (with "user story" cards as you describe) does. I understand how that works for a single iteration, but not how well it works for a substantial (more than ten staff years) project.
I need to think more about this. (Check my Slashdot journal to see if I follow up there.)
(2) Your e-mail system administrator (and mine) need to keep beefing up the servers because the sheer volume of e-mail is growing so quickly.
To a first approximations, filters solve (1) but not (2), and black hole lists solve (2).
whirlycott summarizes the problem with (2) in two words: "collateral damage." How much of the e-mail network do we need to destroy in order to save it?
We need to move past first approximations. We need systems that work at the server level, but that somehow address the problems of collateral damage and false positives.
This is only the tip of the iceberg. Any network messaging medium is vulnerable to abuse by spammers. The problem started with Netnews, it continued with e-mail, it's happening now with instant messaging. We need at least high level solution that helps solve the problem regardless of prototcol.
Executive Summary: Any measure for stopping spam must ensure that all non-spam messages reach their intended recipients.
For the past several years, the Electronic Frontier Foundation (EFF) has watched with great interest the debate regarding what to do about unsolicited bulk email from strangers, or spam. We have been asked to lend our support to bills that have been introduced in Congress, and we have been approached in various other ways to help lead the fight against this annoying intrusion into people's email mailboxes.
While members of the EFF staff and board find this unsolicited email to be as annoying as everyone else, we believe that the two most popular strategies for combatting it so far--legislation and anti-spam blacklists--have failed in their fundamental design. Anti-spam bills have been badly written, are unconstitutionally overbroad, and frequently wander into areas where legislators have no expertise, such as the establishment of Internet standards. And anti-spam blacklists, such as the MAPS RBL (Mail Abuse Prevention System Realtime Blackhole List, the most popular), result in a large number of Internet service providers (ISPs) surreptitiously blocking large amounts of non-spam from innocent people. This is because they block all email from entire IP address blocks--even from entire nations. This is done with no notice to the users, who do not even know that their mail is not being delivered.
The focus of efforts to stop spam should include protecting end users and should not only consider stopping spammers at all costs. Specifically, any measure for stopping spam must ensure that all non-spam messages reach their intended recipients. Proposed solutions that do not fulfill these minimal goals are themselves a form of Internet abuse and are a direct assault on the health, growth, openness and liberty of the Internet.
Email is protected speech. There is a fundamental free speech right to be able to send and receive messages, regardless of medium. Unless that right is being abused by a particular individual, that individual must not be restricted. It is unacceptable, then, for anti-spam policies to limit legitimate rights to send or receive email. To the extent that an anti-spam proposal, whether legal or technical, results in such casualties, that proposal is unacceptable.
Also old news are the Posix subsystem within Windows, and Microsoft claiming Posix compliance; the first in support of the second, and the second to get around U.S. government requirements for Posix-compliant solutions. For example (I think):
Previously, most of Microsoft's Unix-like stuff has been standalone, unable to integrate with the rest of "the Win32 subsystem"; maybe that's changing.
P.S.: I accidentally discovered that the native command line interepreter in Windows XP has a decent filename completion feature. Without thinking, I hit tab to complete a file name, and it took me a minute to notice that it worked even though I wasn't using bash.
I would probably enjoy playing The Sims Online. I would probably temporarily feel good after a hit of crack cocaine. I don't have time for a new vice, let alone an addiction.
I did last night and it consisted of me going to a house called "Mechanical Haven" or somesuch and sitting around studying mechanical skill in a room full of about 6 people for about 30 minutes. Meanwhile no one said anything. What a snoozefest!
Some of what you said is EQ specific. Some is coporate greed and indifference.
At the moment, The Sims Online has just jumped from beta to production, and is "the hot thing" for Electronic Arts. I've got to believe indifference will be minimized at this point; maybe greed, too. The "mob" and "timekiller" stuff doesn't seem to apply.
Should EQers move from pikes to pizza, from dungeons to decorating, swords to Sims?
And the big question for Sony, since any individual player has time for at most one online addiction: How many will switch?
Employee of contract house; hourly rate vs. salary
on
Contractors on Salary?
·
· Score: 3, Interesting
It sounds as if you're in the same situation my wife has been in (and is about to be in again). You're an employee of a contract house; your employer turns around and bills the company you'll be doing the work for (the "client").
As others have said, you're an "exempt employee"; the belief is that your hours are somewhat flexible, and that you are not guaranteed overtime no matter how many (or which) hours you work. (But you should be able to take a couple of hours off for a doctor's appointment without a lot of fuss.)
On the other hand, it's very likely that your contract house will bill the client for the number of hours you work. So you could be in a weird situation: the client could ask you to work 60 hours a week, your contract house makes 50% more than they'd expected, and you don't make an extra penny.
If everyone's reasonable, things will work out fine. The situation's ripe for potential abuse, though no more so than any other exempt employee situation.
My advice? Take the job, get what you can in writing, set expectations verbally when you can (and then take notes of what was said), don't talk about "40 hours per week" as if it's an entitlement... and keep looking for something even better. The best time to look for a job is when you have a job. Don't jump ship at the first sight of something shiny, but do keep an eye out for great opportunities.
P.S.: My wife was offered a choice of salary or hourly. She took hourly (and will bill 40 hours per week but work whatever hours are required), at a rate corresponding to two paid weeks off. That way, if she wants to take more time off (without pay), she's able to do so. She got the position with the client (her old employer) first, and then shopped contract houses. It was great to find a supportive and flexible one.
My first call to jury duty, I sat on a jury where the charges were assault and felony murder*. Three or four of us were computer professionals. Turns out an ealier jury heard the case and was deadlocked. We were, too. (How did I vote? None of your business.)
*Commission of a felony which resulted in a death. You and your roommate hold up a drugstore; your partner shoots the clerk. Both of you are accused of armed robbery. In addition, you'd be charged with felony murder, and he faces more serious charges of homicide or first degree murder. If no shots were fired, but the clerk had a heart attack and died during the robbery, you'd both faced with charges of felony murder in addition to armed robbery. Your milage may vary in other states. This does not consitute legal advice. IANAL. HAND.
My second time, I came close to being seated on a (six week!) medical malpractice case. No one cared that I programmed computers. The plantiff's lawyer didn't like that a close friend of mine was a family practitioner fighting a malpractice case.
Lupin III is a third generation French thief with a heart of gold; sort of a cross between James Bond and Bugs Bunny. He has two sidekicks, a Chicago hitman and a Japanese samuri (who were both sent to kill him and teamed up with him instead), and is constantly chased by an Interpol inspector and an army of Japanese police in riot gear.
The Castle of Cagliostro is one of my favorite movies, and probably Lupin at his best. It was directed by Hayao Miyazaki (Spirited Away, Princess Monokone, My Neighbor Totoro, Kiki's Delivery Service, Castle in the Sky, Nausicaa of the Valley of Wind); several of his animated films have set records for biggest theatrical release of any films in Japan, live action, animated, whatever.
Warning: There was a great dub of The Castle of Cagliostro, and that translation is used for the subtitle; but the Americal release uses a really inferior dub instead (more swearing, completely missing the point of most jokes), so stick with the subtitled VHS release, or play the DVD with subtitled Japanese.
Holocron addresses the desire of families to have one account (and presumably one simultaneous user per account) but multiple characters, one for each family member:
I don't know if you have any idea how much a pain in the neck it is to deal with a family whose account is cancelled because the 14 year old harassed somebody, thereby forcing us to ban grandma, two aunts, six sisters, mom and dad, and his elder brother who is away at college. Arguing this issue with the poor people involved over the phone probably not only eats up their entire monthly fee, but that of a half dozen other people, just in the CS [customer service?] costs....
Good point.
The fact is, if I want cable TV in another room, I have to pay for an additional cable outlet. If I want a phone for my daughter or heck, for myself in my office, I have to pay.... I have multiple computers on my home network, and I pay for the extra IP addresses....
Bad points. In theory, maybe. In practice, we have cable and phone drops all over our house, and a residential broadband router; and I don't pay the service providers involved for any of those, and I like it like that!
I'm actually impressed with (1) their insistence on a good business model, and (2) their serious cluefulness and proactivity about online gaming in general and MMORPGs in particular.
And I'm very nervous about what a time sink (read: addiction) Galaxies could be, at least for me. For that reason, I probably just plain won't buy it.
It seems it's about time for IBM to demonstrate their loyalty to Free Software and Open Source by open sourcing Rational Rose...
Counter-example: IBM all but bought Object Technology International, turned OTI's Envy product into Visual Age (for Smalltalk, and then for Java), and released the latest version as a free / open source product called Eclipse. Why? Because (IMHO) every Java program written is a program that's not tied to Microsoft's apron strings, and thus might be available to run on IBM hardware. Is that the case for every program designed using UML? Probably not.
Note also that IBM sells a high-end, "supported" version of Eclipse called WebSphere Studio Workbench. This is aimed squarely at the big-bucks* enterprise software development market, the same folks who buy Rational Rose. There's huge money to be made in that market, and IBM wants it.
Don't give people a method that does something error-prone. Give them the method that allows them to do the subset that is not error-prone. Suppose you have a file object on which you can call open and close. You can only close an open file. You shouldn't be able to call close on the file object, because it may not be open. The open method should return something on which you can invoke close. Therefore, you can't invoke close on something you have never opened, because the only thing you can invoke close on you get from open. Now you can't express the error. So you don't have to catch the error of attempting to close an unopened file, because you can't even write that.
[first quoting Arnold and Gosling:]
"Marking an entire class final prevents anyone else from extending your class, limiting its usefulness to others...." By contrast, in his book Effective Java, Josh Bloch suggests we should design and document classes for inheritance or prohibit inheritance, either by providing no accessible constructor or marking the class final....
Here's the discussion: There are abstract classes (as per the Java keyword) and concrete classes. You can make instaces of the latter but not the former. (You can create a Porshe911 object but not a Car object.) There are also leaf classes (which no one's derived any subclasses from) and non-leave classes (which have subclasses). Java has the final keyword to force a class to be a leaf class. (For example, String is a final class; a String is a String is a String, not some sort of customized String-like object.)
So... should all non-leaf classes be abstract, and all leaf classes be final? Or should you be able to subclass a concrete class?
It's an interesting discussion to have. I'm not committed to either side.
Slashdot Mirror
I don't think it will fly. I hope it won't fly.
Putting less into each
I haven't had a lot of luck with precompiled headers, either. (Context: a project with a hundred source files spread across a dozen directories, totalling about fifty thousand lines of source.)
Best solution I know of for C++: Use as many forward declarations as you can, periodically trim your include directives, and have relatively large
I know of C++ systems that take a CPU week to build because of these issues!
Note that Java doesn't have this problem, or the problem of teaching your makefile about header file dependencies. (Not important enough to get all projects to switch from C or C++, but among the reasons that some projects should.)
Bell Telephone Laboratories was issued a patent in 1979 for the setuid (set user ID) bit in the Unix file system. This patent was no doubt transferred along with the rest of "Unix," from AT&T to Unix International to Novell to SCO.
This patent was never enforced, and should have expired by now. Hypothetically, there could be some other similar intellectual propery "landmines" in the very specification of Unix-like systems.
Just FYI; the story sounds like FUD to me.
Recently I was given some Java code and asked to port it to C++. At the time, my knowledge of Java was pretty much at the "Where is the bathroom, please?" level. In particular, I could see where the reflection package was being used, but not how the program went from one particular bit of client code to another. I loaded the code into the debugger, started the program, set a few breakpoints at the really puzzling parts, and ran through it a few times. At that point, the student achieved enlightenment.
... and become more likely to run the darned thing and see what it really does. Sometimes, in this job, inspection is theory, and debugging and testing are experimentation.
As I've gotten more skilled at software development, I've become better able to read a bunch of code and analyze it
An MIT animal physiologist is said to have told his students, "The animal is always right. When in doubt, ask the animal." Ask the code; the code is always right. (It may be right in knowing what the bug is, but sometimes that's what you need to ask.)
P.S.: I've learned more Java since then. Running some programs through its debugger was one good way to help learn it.
Meyers: "... we have templates in C++, but there's no way to write user interfaces or talk to databases. Java has no templates, but you can write user interfaces up the wazoo and you can talk to databases with no trouble at all."
NetMeeting is a software implementation of an H.323 (voice over IP, "VoIP") endpoint. That protocol opens UDP ports dynamically (e.g., part of the session says, "okay, the next part of this session will happen on my port 1923"). Firewalls hate that. NAT routers do even worse, since the IP address and port of the new connection get translated (i.e, munged).
Why would this be a problem? What if the dorm rooms are behind a firewall? What if the whole university is behind a firewall, and someone (a commuter, not a resident student) wants to connect from home? What if university doesn't have a firewall, but the commuting student does at home (cable modem + Linksys)? NetMeeting won't work in those situations. There are descriptions of how to make it work, but they're complicated enough to be useless to almost everyone. The Windows XP VoIP platform is based on SIP, which has similar problems.
The only solutions are: use a firewall and/or NAT router that understands your VoIP protocol (I only know one that handles H.323, and I know of work on SIP for this but haven't heard of any solutions), avoid firewalls, or avoid VoIP.
Source: Four and a half years developing a major commercial H.323 gatekeeper (call control software), which interoperated with terminals (including NetMeeting) and gateways.
*A lot of XP gurus like open space plans for development teams. YMMV.
The most common alternative to Customer On Site is Victorian Novel Requirements: the customers write hundreds (thousands) of pages of requirements (which can take as many staff hours as Customer On Site), throw the book "over the wall" to the development staff, and then complain when they didn't want what they originally asked for.
I agree Customer On Site may not always work. Lots of constant communications with the customer, in some form or another, is necessary for any successful software project, XP or otherwise.
Pair programming calls for two people working together. At any given instant, only one person has the keyboard and mouse; but they get passed back and forth, and the person who's not typing is doing a lot more than "watching." It's as natural as two people designing together on a blackboard, once you get the hang of it.
Does it work? There's lots of evidence it's worked for a lot of people who've tried it (including me).
Does it always work, for everyone, in every project? That's an open question. The only way it'll be answered is if more people try to program in pairs.
The definitive book on the subject is Pair Programming Illuminated by Laurie Williams and Robert Kessler (Amazon.com, BN.com); recommended.
Pair programming is not the first XP practice a project should try. Could a project get a lot of value out of XP without doing pair programming? I think yes, and I'm an advocate of programming in pairs; the question is open to debate.
C++ provides:
- a string class that's far more resistant to buffer overflows than char*s;
- powerful data structure mechanisms (built in variable sized arrays and linked lists you no longer have to code yourself, plus sets and associative arrays likely better than you'd throw together),
- lots of help with memory management,
- and good ways of abstracting data (and operations) so the design is fairly well communicated by the code itself.
These can all be big productivity boosts.C++ does not prevent you from doing so. But if you want to do something other than pass around function pointers, there's no way to do so in C that clearly expresses your intent. There are several ways to do so in C++, not even counting inheritance.You think inheritance is a fatal disease for software? Fine; don't use it. Don't define a single member as virtual or protected, and it'll be pretty tough for anyone to usefully inherit from your classes.
That's an admission of your ignorance, not a valid criticism of the language.Can it all be done in C? Sure. Can it be done in assembler? Of course. Can it be done in C++, with less effort, and in a way that better communicates the programmer's intention? In my experience, absolutely.
People and projects sometimes stumble when moving from C to C++ ... or when adopting any new technology. There are strategies that often work, and others that always fail. Want to talk about them?
I've read what you've said (here and elsewhere) about C++. You don't see how it can give programmers an advantage. Okay; but then you attack it as if no one should use it, rather than as if you tried to use it and failed. (Honest, there's a tone of aggressive defensiveness in your postings that makes your position come across as more emotional than rational. That tone seriously undermines your arguments.)
No one's going to force you to program in C++; but no one's going to force managers to hire you for projects using C++. You won't succeed in getting others to be restricted by your limitations. Your choice, your consequences.
There's some web site somewhere that has been keeping track of this ever month (week?) over the past few years. (Sorry, I've forgotten the URL, and can't find it with Google.)
My recent experience is that, for every C++ job, there are between two and two-and-a-half Java jobs.
Traditional methods would say you spend more than 50% of your time doing analysis and design; do you want to get that far into the project before you know how long it's going to take?
XP would say Big Design Up Front doesn't work, but the Planning Game (with "user story" cards as you describe) does. I understand how that works for a single iteration, but not how well it works for a substantial (more than ten staff years) project.
I need to think more about this. (Check my Slashdot journal to see if I follow up there.)
(1) You (and I) get too much spam.
(2) Your e-mail system administrator (and mine) need to keep beefing up the servers because the sheer volume of e-mail is growing so quickly.
To a first approximations, filters solve (1) but not (2), and black hole lists solve (2).
whirlycott summarizes the problem with (2) in two words: "collateral damage." How much of the e-mail network do we need to destroy in order to save it?
We need to move past first approximations. We need systems that work at the server level, but that somehow address the problems of collateral damage and false positives.
This is only the tip of the iceberg. Any network messaging medium is vulnerable to abuse by spammers. The problem started with Netnews, it continued with e-mail, it's happening now with instant messaging. We need at least high level solution that helps solve the problem regardless of prototcol.
I wish I had one.
P.S.: I accidentally discovered that the native command line interepreter in Windows XP has a decent filename completion feature. Without thinking, I hit tab to complete a file name, and it took me a minute to notice that it worked even though I wasn't using bash.
Some of what you said is EQ specific. Some is coporate greed and indifference.
At the moment, The Sims Online has just jumped from beta to production, and is "the hot thing" for Electronic Arts. I've got to believe indifference will be minimized at this point; maybe greed, too. The "mob" and "timekiller" stuff doesn't seem to apply.
Should EQers move from pikes to pizza, from dungeons to decorating, swords to Sims?
And the big question for Sony, since any individual player has time for at most one online addiction: How many will switch?
Joel Spolsky on "Painless Software Schedules"
Yeah, it's a lot of hard work. Deal with it.
It sounds as if you're in the same situation my wife has been in (and is about to be in again). You're an employee of a contract house; your employer turns around and bills the company you'll be doing the work for (the "client").
... and keep looking for something even better. The best time to look for a job is when you have a job. Don't jump ship at the first sight of something shiny, but do keep an eye out for great opportunities.
As others have said, you're an "exempt employee"; the belief is that your hours are somewhat flexible, and that you are not guaranteed overtime no matter how many (or which) hours you work. (But you should be able to take a couple of hours off for a doctor's appointment without a lot of fuss.)
On the other hand, it's very likely that your contract house will bill the client for the number of hours you work. So you could be in a weird situation: the client could ask you to work 60 hours a week, your contract house makes 50% more than they'd expected, and you don't make an extra penny.
If everyone's reasonable, things will work out fine. The situation's ripe for potential abuse, though no more so than any other exempt employee situation.
My advice? Take the job, get what you can in writing, set expectations verbally when you can (and then take notes of what was said), don't talk about "40 hours per week" as if it's an entitlement
P.S.: My wife was offered a choice of salary or hourly. She took hourly (and will bill 40 hours per week but work whatever hours are required), at a rate corresponding to two paid weeks off. That way, if she wants to take more time off (without pay), she's able to do so. She got the position with the client (her old employer) first, and then shopped contract houses. It was great to find a supportive and flexible one.
My first call to jury duty, I sat on a jury where the charges were assault and felony murder*. Three or four of us were computer professionals. Turns out an ealier jury heard the case and was deadlocked. We were, too. (How did I vote? None of your business.)
... is next month.
*Commission of a felony which resulted in a death. You and your roommate hold up a drugstore; your partner shoots the clerk. Both of you are accused of armed robbery. In addition, you'd be charged with felony murder, and he faces more serious charges of homicide or first degree murder. If no shots were fired, but the clerk had a heart attack and died during the robbery, you'd both faced with charges of felony murder in addition to armed robbery. Your milage may vary in other states. This does not consitute legal advice. IANAL. HAND.
My second time, I came close to being seated on a (six week!) medical malpractice case. No one cared that I programmed computers. The plantiff's lawyer didn't like that a close friend of mine was a family practitioner fighting a malpractice case.
My third time in the jury pool
Lupin III is a third generation French thief with a heart of gold; sort of a cross between James Bond and Bugs Bunny. He has two sidekicks, a Chicago hitman and a Japanese samuri (who were both sent to kill him and teamed up with him instead), and is constantly chased by an Interpol inspector and an army of Japanese police in riot gear.
The Castle of Cagliostro is one of my favorite movies, and probably Lupin at his best. It was directed by Hayao Miyazaki (Spirited Away, Princess Monokone, My Neighbor Totoro, Kiki's Delivery Service, Castle in the Sky, Nausicaa of the Valley of Wind); several of his animated films have set records for biggest theatrical release of any films in Japan, live action, animated, whatever.
Warning: There was a great dub of The Castle of Cagliostro, and that translation is used for the subtitle; but the Americal release uses a really inferior dub instead (more swearing, completely missing the point of most jokes), so stick with the subtitled VHS release, or play the DVD with subtitled Japanese.
I'm actually impressed with (1) their insistence on a good business model, and (2) their serious cluefulness and proactivity about online gaming in general and MMORPGs in particular.
And I'm very nervous about what a time sink (read: addiction) Galaxies could be, at least for me. For that reason, I probably just plain won't buy it.
Note also that IBM sells a high-end, "supported" version of Eclipse called WebSphere Studio Workbench. This is aimed squarely at the big-bucks* enterprise software development market, the same folks who buy Rational Rose. There's huge money to be made in that market, and IBM wants it.
(*Freudian slip: I originally typed "big bugs".-)
So ... should all non-leaf classes be abstract, and all leaf classes be final? Or should you be able to subclass a concrete class?
It's an interesting discussion to have. I'm not committed to either side.