As a software professional using Java since its very beginning, I have been following the case regarding Google’s using Java APIs in its Android OS. I don’t want to repeat what has happened so far because you can find these updates by searching the Internet. All I want to say is that the case is pretty educational not only on the technology itself but also on the legal side like patents, copyright.
Social networking has been the hottest area after the dot.com burst. User base is still a critical factor and far more sticky than before. It’s the connections among these users that differentiate social networking from other types of Internet services.
A connection is formed from one user to another. They cannot be on two different web sites, even though theoretically they can. Technically we can define protocols to link users, even groups, together from different sites. But it is not efficient and may not be fast enough to sync up states and discover new connections. Even more issues on business side, not to mention privacy policies.
Yesterday the VMware community noticed that the direct ESX download links were removed from vSphere download page. When I checked the download page, the ESX link is not with the bundles but at the end of the page in its own section.
To my own curiosity, I wonder what the adoption ratio of these two hypervisors is today. As an engineer, I don’t have sales data in front of me. Even I have, I am sure if I can share it here.
Instead, I tried
It’s been a while since I checked the VI Java API fling at VMware Lab last time. When I checked it again yesterday, I found something new and exciting – VI Java API on Google Android. The following comment was posted there by a gentleman called Bob:
Great framework, I used it on a recently published android application (avmcontrol – vsphere client for android), I had to tweak it a bit, however developing for android using vijava was much easier then the same for iOS4 devices.
Following the link, I found
Using GWT for Java developers is mostly
This is yet another post based on my notes taken at LISA 2010 conference. The talk is The 10 commandments in release engineering by Dinah McNutt from Google. Dinah did a great job in summarizing the basics of release engineering therefore it’s worthwhile to compile my note and share it here.
Note that although typical release engineering does not produce virtual appliances, the basic principles are the same. You will find these basics helpful as well.
Release engineering is a critical part of software engineering and should be treated as products in their own rights. But often there is disconnect between development writing the code and the system administrator who installs it. Release process is usually an afterthought.
Typical Release Process
The following steps are executed during a release run:
Last week I attended a great talk by Google Fellow Jeffrey Dean at Stanford University. Jeff talked about his first hand experience on building software systems at Google since 1999 and lessons learned. The following summary is solely based on my notes, therefore may contain my misunderstandings.
A Brief History
During the past 10 years or so, the scale of the Google infrastructure has grown exponentially: # docs 1,000X; #query, 1,000X; per doc index, 3X; update rate from months to seconds, 50,000X; query latency, 5X; computer and computing powers, 1,000X. The underlying infrastructure has experienced 7 major revisions in the last 11 years.
At the concept level, the search infrastructure is simple. It has web servers upfront taking search queries. The queries are then passed on to two different types of servers: index servers and doc servers. For the index server, the input is the query string and the output is an array of doc-id and score pairs. For the doc servers, the input is the doc-id and query pair and the output is the title and snippet of the doc. Note that the snippet of the doc is query dependent so that you can find your keywords highlighted in the result pages. How to quickly and accurately calculate the output based on input involves a lot of advanced algorithms, and is not in the scope of Jeff’s talk.