Do either of the above posters have a source reference that they can cite? I know that noise-cancelling phones work by generating sound waves that are out-of-phase with the ambient noise, but it would seem that is simply adding to the sound pressure levels?
"Losing one contract is no big loss" -- it is if it's the only one in the pipeline. Many small software development shops (like mine) find it difficult to balance the sales and marketing needed to keep the pipeline full with doing the work needed to deliver on previous commitments.
That doesn't make it OK to lie to customers, but anyone who has never had to "sharpen his pencil" when coming up with a quote for a customer is simply not living in the real world.
Re:Microsofties say "sequel"
on
SQL Cookbook
·
· Score: 1
FWIW, I recently attended a webcast with Michael Stonebraker (Ingres, Postgres, Streambase, etc.) and he pronounces it as "sequel". Good enough for me...
Pray tell -- how did your employer "get into" your gmail account? Did they simply monitor your use of the account from your workplace? Or did they use monitoring to get hold of your user/password information and use that to log in to your account? Can you prove it?
Anyway, thanks for the contribution. I can think of cases where something like this would be VERY useful. Keep up the good work, and good luck.
P.S. You might want to also post a link at http://discuss.joelonsoftware.com/?design. The people there are just a bit less rambunctious than the slashdot crowd. Who knows, you might even get some useful feedback.
"the documentation for (MySql and PostresSQL) sucks pretty bad... Oracle on the other hand has a ton of documentation"
Which also sucks pretty bad, just because there's so much of it (the proverbial "needle in a haystack" problem). Just try to figure out how to use some of the advanced features (e.g., LogMiner) from the Oracle docs. More doesn't necessarily mean better.
I've had good luck buying refurbished machines from tigerdirect.com, and also got a great deal on my laptop (eMachines AMD 2800+, $600) about 15 mos. ago from bestbuy (when eMachines was about to get bought by Gateway).
I figure with refurbs they've already failed and been fixed once, so I'm ahead of the game.
If you're not too picky and can accept the "-1" generation, closeouts work well too.
The beauty of this approach is that it works for the bank too -- they don't want to have to deal with any potential legal exposure if they decide not to use your software for some reason.
Of course, BIOS was written in assembler, which tends to restrict the universe of potential ways of accomplishing the same thing. Some of these operations (e.g., subroutine calls) can only be done one way -- the way that the architecture specifies. If you factor in that BIOS writers would tend to try to keep variables in registers, that restricts things even further. With high-level languages, it would seem to be less likely to find large areas of similarity.
Here's a link to one of the seminal studies:
http://www.research.ibm.com/journal/sj/171/ibmsj17 01C.pdf
You can also check out "Peopleware" by DeMarco and Lister.
Offices are good -- if you want/need interaction, you can always invite people in, but it's hard to invite people out of a shared space.
The worst "office" environments I've ever been in:
- at one engagement (I was on-staff at a consulting co. for a big client), I actually shared a DESK (not an office), with another programmer. Seriously -- one desk, two PC's, two chairs. Can you guess how productive either of us were?
- Another time, the co. I was consulting for (independent this time) had just finished remodeling their offices, and of course as soon as that was done, they had run out of space. So, they moved all the "consultants" (read, those who actually did real work) into desks strung out along a hallway. Every other person who walked by ended up kicking the back of my chair (not on purpose, at least I dont think so), but it made for a very frustrating experience. Productivity was even less than the "one desk, two people" scenario described above -- after getting jostled a few times, it was necessary to go for a walk outside to vent some steam.
Depending on how complicated the actual system you are interfacing to is, you may need to build a simulator. This may seem like a waste of time, but you can spend a ridiculous amount of time trying to (re-)capture certain events that happen rarely, or that require a lot of other things to happen first.
I've done this several times, and it has always saved a lot of time in the long run. For one application (real-time trading), I built a small simulator for one of the exchange systems. It didn't do a lot -- just replayed canned quote data, and accepted the messages my app sent (logon, enter trade, etc.) and replied with something reasonable.
If you're really ambitious, the simulator can be driven by some kind of script (text file, XML, etc.), so you can vary what it does for the different inputs, but this may be overkill.
A simulator is also helpful for testing GUI apps, but most people don't bother -- they just play the part of a user by banging on the keyboard. (Or use a package like WinRunner, which, when you think about it, is really a scriptable simulator for a human user).
This is one of the main ideas in Robert Pirsig's "Zen and the Art of Motorcycle Maintenance". Good to see science acknowledging what many have believed for a long time.
All the other posts make good points about health insurance, taxes, etc. The gist of these, I think, is that contracting is not an easy road to financial riches.
To my mind, the biggest benefit to contracting is that you are always aware that you are the only person responsible for your own success, and so you can never let up. This is also true for employees, but I think it's easier to forget this if you have a "permanent" job.
A long time ago I worked with a guy who made furniture for his office out of stacks of 11x17 printouts.
He actually made a pretty fair imitation of a couch, but it wasn't very comfortable...
This actually happened to me once, a *long* time ago. About a year after I left this job, I got a call from old co. -- seems a system I worked on had started to crash regularly around lunchtime on Thursdays. They gently asked if I had inserted a time-bomb, which I had not (I'm not that stupid).
I went in to take a look and found the problem for them. Turns out someone had changed the operations run-book to run the db reorg job weekly instead of daily. (This was on VSAM files, which had a nasty tendency to get clogged up, at which point they just stopped working).
Moral of this story: "If it ain't broke, don't fix it." -- especially if you don't know what you're doing.
I fondly remember programming in C/C++ on x86 machines running OS/2, where attempting to write beyond the end of an allocated block of memory (incl. stack) caused an immediate interrupt. Great for debugging, and also much more secure against buffer overrun attacks.
Why? Because in OS/2 each allocated block of memory was its own segment, with its own protection levels. Windows, unfortunately, just allocates one big segment from x86 hardware, so hardware-based memory protection is effectively disabled.
This has nothing to do with whether VB is good or bad -- pay your money and take your choice.
What it has to do without is forced conversion of large numbers of apps for which VB.Net provides no added value.
Cost of conversion is significant, since VB.Net is not backward compatible with earlier versions.
VB.Net also requires.Net runtime, which is ~23MB -- adding to deployment issues.
Dropping support for VB clearly benefits MS, but just as clearly does not benefit users -- since when is this a good thing?
The problem is that not everything in a typical XML message is text, so there can be a lot of translation going on between XML text and the binary format that an application needs (e.g., double).
In our tests we've found XML to be 100x - 250x SLOWER than other approaches (e.g., JMS MapMessage). (FWIW, the 100x is using the MS parser, the 250x is with Xerces/Xalan).
For high-volume, high-performance apps that's simply intolerable.
Note that this has nothing to do with size on the wire, which is another consideration entirely.
Slashdot Mirror
Do either of the above posters have a source reference that they can cite? I know that noise-cancelling phones work by generating sound waves that are out-of-phase with the ambient noise, but it would seem that is simply adding to the sound pressure levels?
"Losing one contract is no big loss" -- it is if it's the only one in the pipeline. Many small software development shops (like mine) find it difficult to balance the sales and marketing needed to keep the pipeline full with doing the work needed to deliver on previous commitments. That doesn't make it OK to lie to customers, but anyone who has never had to "sharpen his pencil" when coming up with a quote for a customer is simply not living in the real world.
Not saying your co. could have done this, but there's an interesting article about a similar situation here: http://www.fastcompany.com/magazine/102/open_snapp er.html
FWIW, I recently attended a webcast with Michael Stonebraker (Ingres, Postgres, Streambase, etc.) and he pronounces it as "sequel". Good enough for me...
Pray tell -- how did your employer "get into" your gmail account? Did they simply monitor your use of the account from your workplace? Or did they use monitoring to get hold of your user/password information and use that to log in to your account? Can you prove it?
Welcome to slashdot!
Anyway, thanks for the contribution. I can think of cases where something like this would be VERY useful. Keep up the good work, and good luck.
P.S. You might want to also post a link at http://discuss.joelonsoftware.com/?design. The people there are just a bit less rambunctious than the slashdot crowd. Who knows, you might even get some useful feedback.
Anyone have any info on what happened to AMQ? Was supposed to be an OS messaging middleware sponsored by JPMC...
7 251
http://it.slashdot.org/article.pl?sid=05/02/08/19
"the documentation for (MySql and PostresSQL) sucks pretty bad ... Oracle on the other hand has a ton of documentation"
Which also sucks pretty bad, just because there's so much of it (the proverbial "needle in a haystack" problem). Just try to figure out how to use some of the advanced features (e.g., LogMiner) from the Oracle docs. More doesn't necessarily mean better.
I've had good luck buying refurbished machines from tigerdirect.com, and also got a great deal on my laptop (eMachines AMD 2800+, $600) about 15 mos. ago from bestbuy (when eMachines was about to get bought by Gateway).
I figure with refurbs they've already failed and been fixed once, so I'm ahead of the game.
If you're not too picky and can accept the "-1" generation, closeouts work well too.
Can you say "deprecated"?
The beauty of this approach is that it works for the bank too -- they don't want to have to deal with any potential legal exposure if they decide not to use your software for some reason.
Of course, BIOS was written in assembler, which tends to restrict the universe of potential ways of accomplishing the same thing. Some of these operations (e.g., subroutine calls) can only be done one way -- the way that the architecture specifies. If you factor in that BIOS writers would tend to try to keep variables in registers, that restricts things even further.
With high-level languages, it would seem to be less likely to find large areas of similarity.
Here's a link to one of the seminal studies: http://www.research.ibm.com/journal/sj/171/ibmsj17 01C.pdf
You can also check out "Peopleware" by DeMarco and Lister.
Offices are good -- if you want/need interaction, you can always invite people in, but it's hard to invite people out of a shared space.
The worst "office" environments I've ever been in:
- at one engagement (I was on-staff at a consulting co. for a big client), I actually shared a DESK (not an office), with another programmer. Seriously -- one desk, two PC's, two chairs. Can you guess how productive either of us were?
- Another time, the co. I was consulting for (independent this time) had just finished remodeling their offices, and of course as soon as that was done, they had run out of space. So, they moved all the "consultants" (read, those who actually did real work) into desks strung out along a hallway. Every other person who walked by ended up kicking the back of my chair (not on purpose, at least I dont think so), but it made for a very frustrating experience. Productivity was even less than the "one desk, two people" scenario described above -- after getting jostled a few times, it was necessary to go for a walk outside to vent some steam.
Depending on how complicated the actual system you are interfacing to is, you may need to build a simulator. This may seem like a waste of time, but you can spend a ridiculous amount of time trying to (re-)capture certain events that happen rarely, or that require a lot of other things to happen first. I've done this several times, and it has always saved a lot of time in the long run. For one application (real-time trading), I built a small simulator for one of the exchange systems. It didn't do a lot -- just replayed canned quote data, and accepted the messages my app sent (logon, enter trade, etc.) and replied with something reasonable. If you're really ambitious, the simulator can be driven by some kind of script (text file, XML, etc.), so you can vary what it does for the different inputs, but this may be overkill. A simulator is also helpful for testing GUI apps, but most people don't bother -- they just play the part of a user by banging on the keyboard. (Or use a package like WinRunner, which, when you think about it, is really a scriptable simulator for a human user).
This is one of the main ideas in Robert Pirsig's "Zen and the Art of Motorcycle Maintenance". Good to see science acknowledging what many have believed for a long time.
All the other posts make good points about health insurance, taxes, etc. The gist of these, I think, is that contracting is not an easy road to financial riches. To my mind, the biggest benefit to contracting is that you are always aware that you are the only person responsible for your own success, and so you can never let up. This is also true for employees, but I think it's easier to forget this if you have a "permanent" job.
A long time ago I worked with a guy who made furniture for his office out of stacks of 11x17 printouts. He actually made a pretty fair imitation of a couch, but it wasn't very comfortable...
This actually happened to me once, a *long* time ago. About a year after I left this job, I got a call from old co. -- seems a system I worked on had started to crash regularly around lunchtime on Thursdays. They gently asked if I had inserted a time-bomb, which I had not (I'm not that stupid). I went in to take a look and found the problem for them. Turns out someone had changed the operations run-book to run the db reorg job weekly instead of daily. (This was on VSAM files, which had a nasty tendency to get clogged up, at which point they just stopped working). Moral of this story: "If it ain't broke, don't fix it." -- especially if you don't know what you're doing.
I fondly remember programming in C/C++ on x86 machines running OS/2, where attempting to write beyond the end of an allocated block of memory (incl. stack) caused an immediate interrupt. Great for debugging, and also much more secure against buffer overrun attacks. Why? Because in OS/2 each allocated block of memory was its own segment, with its own protection levels. Windows, unfortunately, just allocates one big segment from x86 hardware, so hardware-based memory protection is effectively disabled.
This has nothing to do with whether VB is good or bad -- pay your money and take your choice. What it has to do without is forced conversion of large numbers of apps for which VB.Net provides no added value. Cost of conversion is significant, since VB.Net is not backward compatible with earlier versions. VB.Net also requires .Net runtime, which is ~23MB -- adding to deployment issues.
Dropping support for VB clearly benefits MS, but just as clearly does not benefit users -- since when is this a good thing?
The problem is that not everything in a typical XML message is text, so there can be a lot of translation going on between XML text and the binary format that an application needs (e.g., double). In our tests we've found XML to be 100x - 250x SLOWER than other approaches (e.g., JMS MapMessage). (FWIW, the 100x is using the MS parser, the 250x is with Xerces/Xalan). For high-volume, high-performance apps that's simply intolerable. Note that this has nothing to do with size on the wire, which is another consideration entirely.