Relational databases work well for certain types of data but to assume that tables of rows and columns work for every need is silly.
Relational databases are inherently hard to scale because they mix data together that doesn't necessarily need to be together. If there's no reason why Bob and Alice's records should be in the same table or on the same machine then they shouldn't be. You can avoid all contention by distributing each individual's records on unique or underutilized machines.
Relational databases do not work well for storing hierarchical data like a file system or an object-oriented data store. They do not work well for large blobs like movie files or for unstructured documents like medical records. Because of their rigid structure, they do not version well because copying records to older versions of the schema loses data - if the column doesn't exist there's no place to put the data (imagine if application versions 1 and 2 have to read and write to the same database).
Relational databases have their place and I completely agree that transactions are vital to data integrity, but the fixed column data model is way too limited to store all of the kinds of data used in the real world.
Don't post it to IEEE. That will guarantee that 90% of people interested in your paper won't ever be able to read it. Just put in on your blog with a note here in SlashDot.
Are you trying to monetize it? If so, you need to file for a patent instead. Naturally everyone here would prefer you publish it for free on the internet instead.
This is a great response - making sure that you can't be sued personally is a good first step. Making sure that the company has no assets is another good suggestion - nobody is going to spend hundreds of thousands of dollars suing your company if they can't get at least that much back.
Patenting some of your "inventions" in the software can help you against established software companies. They'll be less likely to sue you if you have a patent that you can sue them over. It's like Mutual Assured Destruction with nuclear weapons.
Lawyers are useful, but don't blindly listen to them. We were hit with a patent infringement threat and instead of spending more money on lawyers that suggested we settle we instead found prior art and sent a response to the company saying that if they didn't go away we'd send the prior art to everyone else they were suing. They went away. Cost us a few days of research, but nothing else.
In short, don't make it worth anyone's time to sue you.
If they look at you funny or don't have an answer, they should not be hired.
It doesn't really matter which they prefer, just that they prefer one or the other. I would even accept "BBEdit over NFS or AFS", but if the person can't edit a text file on a remote system, they are all but worthless.
I also like to always ask one question that nobody can answer. If they lie and make up an answer, don't hire them. If they say "I don't know" or "Here's where I'd find the answer to that", they can probably be trusted.
Non-compete clauses are very common in the software industry. You have a few choices:
1. Negotiate a smaller time range One year is very typical in the contracts I've seen.
2. Negotiate a lower price Offer them a lower price if they allow you to open source your work.
3. Choose which parts remain open source with the client It may make sense for them to only close source add-ons and additional functionality rather than everything, especially if you continue to work on it in your spare time.
4. Remind them that you plan on working on other portions of the project in your own time at no cost to them. This is to their advantage.
But you may just have to decide whether you want the work or not. Sometimes it all comes down to how big your mortgage payments are.
About 23 years ago, we watched a Columbia launch from the causeway. Our Senator's office was nice enough to send us tickets - the only thing I've ever received from our elected officials.
Still, we were 3 miles away, not as close as I wanted to be. We had to arrive 8-10 hours before the launch because of the traffic. And June in Florida is, well, too hot to be sitting out in a swamp for 8-10 hours. It was 100 degrees F with 98 percent humidity. If you go in the summer, bring lots of ice and a full tank of gas so you can run the air conditioner when you need it. There was an aligator about 200 feet from us, not bothering anyone although some kids decided to pelt it with rocks (Darwin candidates in the pre-Darwin Awards days).
The launch itself was indescribable. You felt it as much as watched it. It was astoundingly cool, but unfortunately lasted only a few minutes and then there was the 2.5 hour trek back through traffic to the hotel.
If I were to do it again, I would rent a motor home and wait in comfort.
> 2) Make sure you only work on things that you need to ship version 1.0 of that.
This is one of the tricks that is hard on good software engineers. I like to write code that can be used in future projects. I like to write complete code, say a generic networking class with interthread notification rather than just a few network routines. However, on a tight schedule, there is something to be said for just writing the routines you need right now without a big overblown design.
I often find that OOP is a problem when it comes to tight schedules and new code. It takes a long time to design class hierarchies, object interactions, and to write full, testable objects. Rearranging class hierarchies is also a time sink. Sometimes simple procedural code is faster to write and the end user won't know the difference. Just write code to do what you want, even if it's kinda ugly. Often this straight-forward design is easier to follow anyway.
Another important thing is to let the developers write code and STOP BOTHERING THEM WITH COMPANY BS. So what if their quarterly reports are late. If they need equipment or software get it for them in a day or less. Make sure you have testers ready to test whatever they produce whenever they produce it. Have someone write their expense reports for them, bring them lunch, and let them skip unnecessary company meetings. Nothing slows down developers more than thinking that the company isn't supporting them properly.
Most importantly, hire fast developers. Some developers are great but slow. Some developers are fast but bad. You want someone good and fast. The code won't be as pretty as it could be, but your project will get out the door at least.
Any list of the worst technical products that doesn't mention The Coleco Adam is just wrong.
AOL was great back in the day of dialup modems, before the web. Compared to its closest competitor, Prodigy, it rocked. It just hasn't aged well, once it became nothing more than an ugly advertising platform with a ridiculously slow web proxy.
The Oqo is cool. Maybe not a huge success, but still a neat device.
And the Zip drives were wildly popular, even though some stopped working. The original Canon optical drives in the NeXT machines had a near 100% failure rate over two years.
One of the stupidest early reviews of the PowerBook said that it would take most users several weeks to get used to the built-in trackball.
Of course, my generation was raised on Missile Command and Centipede so for most of us it took about half a minute. I still miss the tactile feel of a trackball over a trackpad sometimes.
I was at the WWDC where the PowerBooks were introduced.
The intro was amazing. We suspected that new portables were coming, but someone brought out a LaserWriter on stage instead. Everyone was wondering what they were up to and then a voice came over the sound system, "Check the paper tray".
The paper tray was removed to reveal a PowerBook inside. Too cool.
I paid a ton of money - even with the developer discount - for my PowerBook 170, but it was one of those leaps in technology (Betamax, Tivo, original Mac, etc) that you only see a few times in your life. Great piece of hardware. Great Ergonomics. Every developer knew Apple would sell a ton of them even though upper management did not.
> That's nuts. I'm self-employed in Arizona, and pay ~$400.00 a quarter for > single-person health insurance.
Yes, I was thinking married with family. And many medical policies these days don't include things you think should be covered, like visits to a doctor's office. Most kids spend their first two years seeing the doctor constantly and the costs definitely add up.
On the plus side, if you incorporate you can deduct just about ALL medical expenses, even those not covered by insurance. That can cut the cost of medical care by 40-50% depending on your income tax bracket.
I've been contracting for 18 years now. Boy am I getting old.:-)
My 2 cents:
1. The general rule of thumb is to charge 50-100% more than your salary was.
2. Buying health insurance is going to be a major pain if you are in the US and can't be covered with your spouse's work plan. Plan on spending $600-700/month. Prescription coverage is especially hard to get. (When I started consulting, insurance was $600 PER YEAR!)
3. Think about incorporating, probably as a LLC corporation. Buy Nolo's books on corporate structures and definitely talk to both a lawyer and accountant. Incorporating will help protect your assets if you ever get sued and can also give you more tax deductions.
4. Tax deductions are your friend. Deduct everything your accountant says you can - car (if you travel to a client), health insurance, computers, your cable modem, books, education expenses, etc.
5. You will have to pay both sides of social security taxes in the US. That means 15% of your first $80k in income is immediately gone. You may have to pay medicare, unemployment insurance, local taxes, etc.
6. Unlike what someone else said, I prefer hourly to fixed price contracts. This allows for the client to make changes (they always do) and you get paid for debugging, installers, research, testing, localization, etc. NEVER SIGN A FIXED PRICE CONTRACT WITHOUT A DETAILED, COMPLETED SPECIFICATION. Always try and make a client responsible for testing the software when possible, for liability reasons, acceptability, and because it's very hard for an individual to test software on many different operating systems, hardware configurations, etc.
7. Look for other clients. One client isn't enough. When money gets tight, contractors will be the first to go.
8. Look for other contractors and possibly join forces. Networking is vital.
9. Open a retirement account - definitely a Roth IRA and probably some other kind too (SEP IRA, SARSEP, etc). Your accountant can give you the details.
10. Never sign a contract with someone you don't trust unless they have deep pockets and even then it's probably a bad idea.
11. You are charging a lot of money. Make sure your skills stay ahead of everyone else's. When I started consulting C++ didn't even exist. I've been through new languages, new operating systems, new tools, embedded systems, server software, client software, etc. It's getting impossible to keep up with everything, so you need to predict the future and learn it ahead of time. You *will* make mistakes (I spent a year working on OpenDoc!), but hopefully you will also grab onto something new that will take off (I also spent time with early versions of QuickTime because I knew it was going to be big).
Contracting can be great, but it's definitely not as easy as sitting back and collecting a paycheck.
The calculator shipping with Tiger is a completely different product than the Graping Calculator from Pacific Tech (ie, the one that shipped with MacOS 9).
Knaster wrote two very early and excellent books on Mac programming. Both "Macintosh Programming Secrets" and "How to Write Macintosh Software" were must reads back in the day.
How can you not love a programming book whose cover resembles (and was drawn by an artist from) MAD Magazine ?!?
There was a great piece of software that did this back in 1990 called OnLocation, from On Software. It didn't use file system meta-data, but did index your entire hard disk, supported plugins for various file types, and was very fast.
Shareware CD-ROMs used to come with the OnLocation index files pre-installed, which was a pretty nice way to find something on a slow 1x CD drive loaded with shareware.
Slashdot Mirror
Relational databases work well for certain types of data but to assume that tables of rows and columns work for every need is silly.
Relational databases are inherently hard to scale because they mix data together that doesn't necessarily need to be together. If there's no reason why Bob and Alice's records should be in the same table or on the same machine then they shouldn't be. You can avoid all contention by distributing each individual's records on unique or underutilized machines.
Relational databases do not work well for storing hierarchical data like a file system or an object-oriented data store. They do not work well for large blobs like movie files or for unstructured documents like medical records. Because of their rigid structure, they do not version well because copying records to older versions of the schema loses data - if the column doesn't exist there's no place to put the data (imagine if application versions 1 and 2 have to read and write to the same database).
Relational databases have their place and I completely agree that transactions are vital to data integrity, but the fixed column data model is way too limited to store all of the kinds of data used in the real world.
"The bitterness of poor quality is remembered long after the sweetness of meeting a deadline is forgotten." -Charles Kettering
Don't post it to IEEE. That will guarantee that 90% of people interested in your paper won't ever be able to read it. Just put in on your blog with a note here in SlashDot.
Are you trying to monetize it? If so, you need to file for a patent instead. Naturally everyone here would prefer you publish it for free on the internet instead.
http://en.wikipedia.org/wiki/Port_knocking
http://www.portknocking.org/
Ann Arbor's Hands-On Museum has at least two interesting computer displays:
1. Colorful visual effects via a computer projection system which the kids can control by moving in front of a video camera. You really have to see it. Found a photo at: http://farm1.static.flickr.com/57/175283594_e5a67d0221.jpg
2. Green screen chroma key area where kids can fly, swim, deliver the news, etc, while other kids act as TV news directors at a control panel
You want a 32" TV with 720p rather than 1080 resolution.
Run the monitor at 1280x720 (native) and everything will be large and readable.
At 1080, the pixels are still fairly small at 69 dpi, but at 720 they are a large 46 dpi.
This is a great response - making sure that you can't be sued personally is a good first step. Making sure that the company has no assets is another good suggestion - nobody is going to spend hundreds of thousands of dollars suing your company if they can't get at least that much back.
Patenting some of your "inventions" in the software can help you against established software companies. They'll be less likely to sue you if you have a patent that you can sue them over. It's like Mutual Assured Destruction with nuclear weapons.
Lawyers are useful, but don't blindly listen to them. We were hit with a patent infringement threat and instead of spending more money on lawyers that suggested we settle we instead found prior art and sent a response to the company saying that if they didn't go away we'd send the prior art to everyone else they were suing. They went away. Cost us a few days of research, but nothing else.
In short, don't make it worth anyone's time to sue you.
This quote is from a writer, but applies to programmers as well:
"Plumbers don't get plumber's block. Don't be self-indulgent. A page a day is a book a year." -- Howard Fast
I find the best way to avoid programmer's block is to work with someone else and depend on each other's work.
Buy a Verizon 3G wireless USB dongle. It'll cost you $60/month, but they appear to have coverage in Mt. Pleasant.
My favorite IT question is "vi or emacs?"
If they look at you funny or don't have an answer, they should not be hired.
It doesn't really matter which they prefer, just that they prefer one or the other. I would even accept "BBEdit over NFS or AFS", but if the person can't edit a text file on a remote system, they are all but worthless.
I also like to always ask one question that nobody can answer. If they lie and make up an answer, don't hire them. If they say "I don't know" or "Here's where I'd find the answer to that", they can probably be trusted.
Morning suck anyway. Let's go on DST permanently.
Non-compete clauses are very common in the software industry. You have a few choices:
1. Negotiate a smaller time range
One year is very typical in the contracts I've seen.
2. Negotiate a lower price
Offer them a lower price if they allow you to open source your work.
3. Choose which parts remain open source with the client
It may make sense for them to only close source add-ons and additional functionality rather than everything, especially if you continue to work on it in your spare time.
4. Remind them that you plan on working on other portions of the project in your own time at no cost to them. This is to their advantage.
But you may just have to decide whether you want the work or not. Sometimes it all comes down to how big your mortgage payments are.
They aimed it towards Columbus, Ohio.
gcc and Xcode should take advantage of the extra processors nicely. Given how slow they are in general, every bit helps.
Plasma has better viewing angles than LCDs. Newer LCDs are coming close, though.
:-)
A good plasma set still looks better at rapidly moving images, like sports. Newer LCDs are coming close, though.
Plasma seems to have more color and contrast, but Sony LCDs look pretty nice too.
I suspect LCDs will win, but I'm pretty happy with my plasma right now. If prices keep coming down, we'll be able to afford a few of each soon.
About 23 years ago, we watched a Columbia launch from the causeway. Our Senator's office was nice enough to send us tickets - the only thing I've ever received from our elected officials.
Still, we were 3 miles away, not as close as I wanted to be. We had to arrive 8-10 hours before the launch because of the traffic. And June in Florida is, well, too hot to be sitting out in a swamp for 8-10 hours. It was 100 degrees F with 98 percent humidity. If you go in the summer, bring lots of ice and a full tank of gas so you can run the air conditioner when you need it. There was an aligator about 200 feet from us, not bothering anyone although some kids decided to pelt it with rocks (Darwin candidates in the pre-Darwin Awards days).
The launch itself was indescribable. You felt it as much as watched it. It was astoundingly cool, but unfortunately lasted only a few minutes and then there was the 2.5 hour trek back through traffic to the hotel.
If I were to do it again, I would rent a motor home and wait in comfort.
> 2) Make sure you only work on things that you need to ship version 1.0 of that.
This is one of the tricks that is hard on good software engineers. I like to write code that can be used in future projects. I like to write complete code, say a generic networking class with interthread notification rather than just a few network routines. However, on a tight schedule, there is something to be said for just writing the routines you need right now without a big overblown design.
I often find that OOP is a problem when it comes to tight schedules and new code. It takes a long time to design class hierarchies, object interactions, and to write full, testable objects. Rearranging class hierarchies is also a time sink. Sometimes simple procedural code is faster to write and the end user won't know the difference. Just write code to do what you want, even if it's kinda ugly. Often this straight-forward design is easier to follow anyway.
Another important thing is to let the developers write code and STOP BOTHERING THEM WITH COMPANY BS. So what if their quarterly reports are late. If they need equipment or software get it for them in a day or less. Make sure you have testers ready to test whatever they produce whenever they produce it. Have someone write their expense reports for them, bring them lunch, and let them skip unnecessary company meetings. Nothing slows down developers more than thinking that the company isn't supporting them properly.
Most importantly, hire fast developers. Some developers are great but slow. Some developers are fast but bad. You want someone good and fast. The code won't be as pretty as it could be, but your project will get out the door at least.
Copious amounts of free Mountain Dew helps too.
Any list of the worst technical products that doesn't mention The Coleco Adam is just wrong.
AOL was great back in the day of dialup modems, before the web. Compared to its closest competitor, Prodigy, it rocked. It just hasn't aged well, once it became nothing more than an ugly advertising platform with a ridiculously slow web proxy.
The Oqo is cool. Maybe not a huge success, but still a neat device.
And the Zip drives were wildly popular, even though some stopped working. The original Canon optical drives in the NeXT machines had a near 100% failure rate over two years.
One of the stupidest early reviews of the PowerBook said that it would take most users several weeks to get used to the built-in trackball.
Of course, my generation was raised on Missile Command and Centipede so for most of us it took about half a minute. I still miss the tactile feel of a trackball over a trackpad sometimes.
I was at the WWDC where the PowerBooks were introduced.
The intro was amazing. We suspected that new portables were coming, but someone brought out a LaserWriter on stage instead. Everyone was wondering what they were up to and then a voice came over the sound system, "Check the paper tray".
The paper tray was removed to reveal a PowerBook inside. Too cool.
I paid a ton of money - even with the developer discount - for my PowerBook 170, but it was one of those leaps in technology (Betamax, Tivo, original Mac, etc) that you only see a few times in your life. Great piece of hardware. Great Ergonomics. Every developer knew Apple would sell a ton of them even though upper management did not.
> That's nuts. I'm self-employed in Arizona, and pay ~$400.00 a quarter for
> single-person health insurance.
Yes, I was thinking married with family. And many medical policies these days don't include things you think should be covered, like visits to a doctor's office. Most kids spend their first two years seeing the doctor constantly and the costs definitely add up.
On the plus side, if you incorporate you can deduct just about ALL medical expenses, even those not covered by insurance. That can cut the cost of medical care by 40-50% depending on your income tax bracket.
I've been contracting for 18 years now. Boy am I getting old. :-)
My 2 cents:
1. The general rule of thumb is to charge 50-100% more than your salary was.
2. Buying health insurance is going to be a major pain if you are in the US and can't be covered with your spouse's work plan. Plan on spending $600-700/month. Prescription coverage is especially hard to get. (When I started consulting, insurance was $600 PER YEAR!)
3. Think about incorporating, probably as a LLC corporation. Buy Nolo's books on corporate structures and definitely talk to both a lawyer and accountant. Incorporating will help protect your assets if you ever get sued and can also give you more tax deductions.
4. Tax deductions are your friend. Deduct everything your accountant says you can - car (if you travel to a client), health insurance, computers, your cable modem, books, education expenses, etc.
5. You will have to pay both sides of social security taxes in the US. That means 15% of your first $80k in income is immediately gone. You may have to pay medicare, unemployment insurance, local taxes, etc.
6. Unlike what someone else said, I prefer hourly to fixed price contracts. This allows for the client to make changes (they always do) and you get paid for debugging, installers, research, testing, localization, etc. NEVER SIGN A FIXED PRICE CONTRACT WITHOUT A DETAILED, COMPLETED SPECIFICATION. Always try and make a client responsible for testing the software when possible, for liability reasons, acceptability, and because it's very hard for an individual to test software on many different operating systems, hardware configurations, etc.
7. Look for other clients. One client isn't enough. When money gets tight, contractors will be the first to go.
8. Look for other contractors and possibly join forces. Networking is vital.
9. Open a retirement account - definitely a Roth IRA and probably some other kind too (SEP IRA, SARSEP, etc). Your accountant can give you the details.
10. Never sign a contract with someone you don't trust unless they have deep pockets and even then it's probably a bad idea.
11. You are charging a lot of money. Make sure your skills stay ahead of everyone else's. When I started consulting C++ didn't even exist. I've been through new languages, new operating systems, new tools, embedded systems, server software, client software, etc. It's getting impossible to keep up with everything, so you need to predict the future and learn it ahead of time. You *will* make mistakes (I spent a year working on OpenDoc!), but hopefully you will also grab onto something new that will take off (I also spent time with early versions of QuickTime because I knew it was going to be big).
Contracting can be great, but it's definitely not as easy as sitting back and collecting a paycheck.
The calculator shipping with Tiger is a completely different product than the Graping Calculator from Pacific Tech (ie, the one that shipped with MacOS 9).
The "real" one is at: http://www.pacifict.com/
>How does one get to be a "Renowned Mac user"
Knaster wrote two very early and excellent books on Mac programming. Both "Macintosh Programming Secrets" and "How to Write Macintosh Software" were must reads back in the day.
How can you not love a programming book whose cover resembles (and was drawn by an artist from) MAD Magazine ?!?
There was a great piece of software that did this back in 1990 called OnLocation, from On Software. It didn't use file system meta-data, but did index your entire hard disk, supported plugins for various file types, and was very fast.
Shareware CD-ROMs used to come with the OnLocation index files pre-installed, which was a pretty nice way to find something on a slow 1x CD drive loaded with shareware.
Everything that's old...is new again.