method="post" target="_blank">
| Fahrenheit to Celsius: | |
method="post" target="_blank">
| Celsius to Fahrenheit: | |
| Fahrenheit to Celsius: | |
| Celsius to Fahrenheit: | |
Here is a list of my favorite Google advanced search operators, operator combinations, and related uses:
So here’s a list of some things I do online when my mind is set on avoiding ‘real work.’
What kind of semi-productive things do you do online in your off-time? Please share them with me in the comments section below.

The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks, whose central theme is that "adding manpower to a late software project makes it later". This idea is known as Brooks's law, and is presented along with the second-system effectand advocacy of prototyping.
Brooks's observations are based on his experiences at IBM while managing the development of OS/360. He had mistakenly added more workers to a project falling behind schedule. He also made the mistake of asserting that one project — writing an Algol compiler — would require six months, regardless of the number of workers involved (It required longer). The tendency for managers to repeat such errors in project development led Brooks to quip that his book is called "The Bible of Software Engineering", because, "everybody quotes it, some people read it, and a few people go by it."[1] The book is widely regarded as a classic on the human elements of software engineering.[2]
The work was first published in 1975 (0-201-00650-2), reprinted with corrections in 1982, and republished as an anniversary edition with four extra chapters in 1995 (ISBN 0-201-83595-9) with the essay No Silver Bullet and commentary by the author.
While working for an auction website, somebody got the idea to solve the site’s scaling problems by creating a database server for a group of users and running those servers on cheap Linux boxes. In this scheme the data for User A is stored on one server and the data for User B is stored on another server. It's a federated model. Groups of 500K users are stored together in what are calledshards.
The advantages are:
How is Sharding different from traditional architectures...?
Sharding is different than traditional database architecture in several important ways; following are the key factors -
Data is denormalized. Traditionally we normalize data. Data are splayed out into anomaly-less tables and then joined back together again when they need to be used. In sharding the data are denormalized. You store together data that are used together.
Data is across many physical instances. Historically database servers are scaled up. You buy bigger machines to get more power. With sharding the data are parallelized and you scale by scaling out. Using this approach you can get massively more work done because it can be done in parallel.
Data is small. The larger a set of data a server handles the harder it is to cash intelligently because you have such a wide diversity of data being accessed. You need huge gobs of RAM that may not even be enough to cache the data when you need it. By isolating data into smaller shards the data you are accessing is more likely to stay in cache.
Smaller sets of data are also easier to backup, restore, and manage.
Data are more highly available. Since the shards are independent a failure in one doesn't cause a failure in another. And if you make each shard operate at 50% capacity it's much easier to upgrade a shard in place. Keeping multiple data copies within a shard also helps with redundancy and making the data more parallelized so more work can be done on the data. You can also setup a shard to have a master-slave or dual master relationship within the shard to avoid a single point of failure within the shard. If one server goes down the other can take over.
It doesn't use replication. Replicating data from a master server to slave servers is a traditional approach to scaling. Data is written to a master server and then replicated to one or more slave servers. At that point read operations can be handled by the slaves, but all writes happen on the master.
Obviously the master becomes the write bottleneck and a single point of failure; and as the load increases the cost of replication increases. Replication costs in CPU, network bandwidth, and disk IO. The slaves fall behind and have stale data. The folks at YouTube had a big problem with replication overhead as they scaled.
Sharding cleanly and elegantly solves the problems with replication.
The most recommended approach to implement database shards is using the Hibernate Shards framework. The said framework offers critical data clustering and support for horizontal partitioning along with standard Hibernate services. Which enable the businesses to keep data in more than one relational database without any add-on complexity whilst building the applications.
Other than Hibernate; shards can also be implemented with any of the following toolkits –
This is a guest post from Larry Dignan of TechRepublic’s sister site ZDNet. You can follow Larry on his ZDNet blog Between the Lines, or subscribe to the RSS feed.
Google has been awarded a U.S. patent for its floating data centers that are powered by waves and cooled by sea water.
The patent award was spotted first by SEO by the Sea. As noted previously, the floating data center idea is quite novel and makes a ton of sense. For Google these floating data centers could be a boon because there are no real estate costs or property taxes.
The offshore data centers would site 3 to 7 miles offshore and float in about 50 to 70 meters of water.

According to the abstract Google was awarded a patent (7,525,207) for:
A system includes a floating platform-mounted computer data center comprising a plurality of computing units, a sea-based electrical generator in electrical connection with the plurality of computing units, and one or more sea-water cooling units for providing cooling to the plurality of computing units.
Inventors were listed as Jimmy Clidaras, David Stiver and William Hamburgen.
The general idea is to move computing power closer to users. The larger question is whether Google will actually deploy these data center barges. Rich Miller at Data Center Knowledge writes:
Does Google have any intention of actually building these floating data centers? Many in the data center community are deeply skeptical about the concept, and find it difficult to believe that Google would ever pursue such a project.
So here’s the interesting precedent: In December 2003 Google applied for a patent for a portable data center in a shipping container, which was awarded in Oct. 2007. At last month’s Efficient Data Center Summit, we learned that Google deployed its first container data center in the fall of 2005, less than two years after filing its patent application.
Hmmm......................... :)