What will these *nauts do to prevent boredom or moodiness?
^^^^^ Best comment on this topic, so far ^^^^^
I agree with almost everything, except that the situation may not be so dire "out there." Things are turning around faster in IT than in other areas.
The main things I'd add are these:
1.) Agreed.... Start developing iPhone / iPad / Ruby on Rails apps independently, right now.
2.) And if you get a chance, get that CS degree, but continue to try to do job interviews while finishing your CS degree. If you are pursuing a CS degree, maybe you can get something entry-level in IT, for resume building. Perhaps, that company might even finish paying for you to complete your degree. Who knows?
3.) Join some face-to-face users' groups. Maybe you can find a business partner and develop apps together. Maybe you can network. If your apps are good, maybe you can find some VC money.
Just don't give up, if you have the interest.
> That, and attaching a device to his personal car should be considered some kind of tresspassing/vandalism.
It violates the 4th Amendment to the US Constitution, as well as the 14th Amendment, Section 1:
The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation, and particularly describing the place to be searched, and the persons or things to be seized.
Passed by Congress June 13, 1866. Ratified July 9, 1868.
Note: Article I, section 2, of the Constitution was modified by section 2 of the 14th amendment.
All persons born or naturalized in the United States, and subject to the jurisdiction thereof, are citizens of the United States and of the State wherein they reside. No State shall make or enforce any law which shall abridge the privileges or immunities of citizens of the United States; nor shall any State deprive any person of life, liberty, or property, without due process of law; nor deny to any person within its jurisdiction the equal protection of the laws.
Can you shard the same SQL data store in Chicago, London, and Tokyo? Not with standard SQL databases, unless you write your own complicated replication techniques or pay through the nose. (See CAP Theorem).
Yes, the company I work for has expressed the world-wide SQL database need, so this is not just a thought experiment.
Have you heard of GemFire/GemStone, VoltDB, or Xeround?
If you can get rid of the SQL requirement, try
XML (or other format) on Amazon's S3
or try one of the NoSQL databases, such as MongoDB, Riak, or CouchDB.
All of the above scale horizontally, most even scale in a geographically diverse environment.
Without even looking into this, I can guarantee that the 75W hotplate is -
b.) safer to your computer
c.) more efficient from plug to heat
I'm talking about USB keychain sizes, not 2.5" to 5.25" SSD's.
If the really big 128G USB devices could go to 512G or 1T, with a 20nm process, then SSD's could jump from 512G / 1T to 2T / 8T sizes, on the low and high end, according to that logic, and barring any issues.
So, my original point of raising this is: If a tiny fob grew to a 512G or a 1T device, then is the 20nm barrier a problem, really? It's true, we can't conceive of how much storage we'll want to walk around with, in the future. In 5 years a 1T USB device might seem paltry; then again, we might not need those crazy sizes, on a daily basis.
A case in point: I don't see too many complaining about not having a 64G keychain in hand. I haven't personally seen anybody sporting a 32G device. I have seen exactly one person with a 16G USB and another with an 8G fob. Most people I know have 1G to 4G keychain-sized devices, since they so cheap and they really don't even use that up.
Agreed. And, I believe that 34nm is near the best they can do today, in any kind of production.
So, if you can go from a 34nm * 34nm feature to a 20nm * 20nm feature, you can almost triple the density.
So, in the same space you can produce a 128G drive, you can then produce a roughly 384G drive, going from 34nm to 34nm.
So, if a USB Keychain is produced w/ 128G, a 384G can be produced at the same size, barring other issues.
That assumes they are even using 34nm process SSD's, today, to produce 128G USB SSD drives. If they are using a 40nm process, then expect 512G USB SSD's, as a future possibility.
This doesn't even take into consideration stacking SSD vertically and horizontally in a RAID configuration on a drive and maximizing use of space (packaging, support chips, etc.) or making larger physical USB devices.
In the future, hardware compression, deduplication, etc., may further add to storage improvements.
My best guess? 1 Terabyte uncompressed on a keychain, eventually, assuming a 20nm process.
If they can go further than 20nm or improve in other ways, all the better.
Lest you think I'm a Ruby fanboy and dismiss me out-of-hand, try this or at least read about Behavior-Driven Development (BDD), as opposed to Test-Driven Development (TDD).
Then, learn Ruby and some of the common testing methodologies, like Shoulda, Cucumber, mocks, and RSpec.
Whatever language, OS, and framework you use, you just might change how you look at non-automated tests.
Yes, agreed, a combination is good (SQL + NoSQL + filesystem).
There is no one-size-fits-all scenario, here.
However, there is utility in a NoSQL database over a raw filesystem. One feature is indexed search. Another is versioning. Another is the fact that it is extremely multiuser (proper record locking, even if there are multiple writes to the same record). Also, many NoSQL databases (especially MongoDB) have built-in replication, sharding, Map-Reduce, and horizontal scaling.
MongoDB's GridFS (especially with FUSE support) marries many of these features together. MongoDB does have some SQL DB features (such as indexing/searching and transactions) but not others.
I agree. It depends.
Yes, relational databases store and retrieve well-defined data very, very well. Do you have referential integrity needs?. If that's your situation, use SQLite (small data and very simple types but little referential integrity), MySQL (medium to large data), or PostgreSQL (medium to very large data or more complex data types) and don't look back. SQL queries, relationships, and referential integrity are very powerful.
If not, then I'd look at MongoDB with GridFS. I'd even go further and explore GridFS-FUSE (a mountable file system version of MongoDB/GrisFS).
With GridFS-FUSE, you have a crazy powerful database/file system combo. Now, since MongoDB is a NoSQL database, you cannot do SQL queries against it. You can store and retrieve key-value pairs, NoSQL "documents," and actual files with MongoDB/GridFS/GridFS-FUSE.
Also, hang on a minute. Please actually pretend that you read *all* of the link you submitted. At least be slightly even-handed, as the article seemed to be, because about 1/2 of your very article (past the title) directly contradicted you.
The 2010 is the warmest year on record link you sent *also* said this:
Marc Morano, a global-warming skeptic who edits the Climate Depot website, says the government "is playing the climate fear card by hyping predictions and cherry-picking data."
Joe D'Aleo, a meteorologist who co-founded The Weather Channel, disagrees, too. He says oceans are entering a cooling cycle that will lower temperatures.
He says too many of the weather stations NOAA uses are in warmer urban areas.
"The only reliable data set right now is satellite," D'Aleo says.
He says NASA satellite data shows the average temperature in June was 0.43 degrees higher than normal. NOAA says it was 1.22 degrees higher.
Real Programs don't use shared text. Otherwise, how can they use functions for scratch space after they are finished calling them?