Google Online Storage System rumours
Wednesday, December 12, 2007
Online Storage is not something new, but Google can monetize it to a scale that only them, Microsoft or Yahoo can do. 50Gb of storage for free is a lot of storage and I can guarantee you I have a lot of old stuff I could put there, saving space in my disks, in my house (physical space is relevant) and of course is more accesible than DVDs or CDs.
Using the Google Chart API from the server side
Sunday, December 09, 2007
You can include a Chart API image in a webpage by embedding a URL within an <img> tag. When the webpage is displayed in a browser the Chart API renders the image within the page.There are some references about how to encode the information in the URLs in javascript. And I was wondering: Can I use it from the server side in my Java applications? Is it difficult? JFreeChart is a good API Chart but it consumes a lot of resources, can I save money in hosting servers delegating the rendering of my charts to Google?
So I wrote this little example about how to use the Google Chart API in Java with the Apache Jakarta Commons HTTP Client. It is very easy, and I wrote a little helper class to avoid the crazy encoding implemented by Google. You can download the source code of the class here. Remember to include these libraries:
- commons-logging.jar
- commons-httpclient-3.1.jar
- commons-codec-1.3.jar
http://chart.apis.google.com/chart?It returns an array of bytes with the image in PNG format. You only need to push it into the output stream of a servlet, or save it in a file like I do. Ok. here goes the snippet:
private String url_ = "http://chart.apis.google.com/chart?";The rest of the class includes some helper methods that wraps the crazy encoding made by Google. The reason for this crazy encoding is to avoid the use of POST parameters normally harder to use in the client side. I have coded the class quick and dirt, so if you think it's possible to do it better you are probably right!
private int timeout_ = 30000; // milliseconds
public byte[] create(String postUrl) {
HttpClient client = new HttpClient();
client.setConnectionTimeout(timeout_);
String url = url_ + postUrl;
HttpMethod method = null;
method = new GetMethod(url);
method.setRequestHeader("accept", "image/png");
byte[] image = null;
try {
client.executeMethod(method);
image = method.getResponseBody();
} catch (Exception e) {
e.printStackTrace();
} finally {
method.releaseConnection();
return image;
}
}
I have performed some tests and the latency of the service is excellent: it never took more 2.5 seconds to render a chart, taking from 300ms to 800ms on average. Normally the network latency of Google is very low (less than 100ms), so the time it takes to render a chart is excellent considering this is a very CPU time consuming activity. As a rule of thumb you should cache the requests made to the Google Servers to avoid requesting twice the same chart. You will respect the Terms of the Service (50000 request per day and user, remember!) and your users will be happy because they will get the charts without any delay.
Finally, I think it's worth to use this API instead of JFreeChart if you need to render a lot of charts with a very high granularity that impacts in the performance of your servers.
Google Chart API or how Google gives raw performance for free
Friday, December 07, 2007
A first look at the API shows a very simple API, with a very limited set of functions. The documentation is very oriented to HTML and Javascript developers, but looks easy to implement something in the server side. So think twice before considering changing JFreeChart with this API. Moreover, the number of request per day is 50000 maximum, so if your site has a lot of traffic you will probably need to implement some kind of server side caching strategy. I will make some tests to test the latency of the API, one of the issues with any chart render engine.
Google, now you have started creating APIs for tipically CPU intensive tasks, why don't you try something with PDF and document generation? My Hosting provider will hate you, but my budget on dedicated servers will have a relief!
The ball and chain of iPhone was not Java: it's Google Android
Monday, November 12, 2007
Sometimes you only need to wait to understand why things happen. When Steve Jobs said 'Java is not worth building in. Nobody uses Java anymore. It's this big heavyweight ball and chain', we were surprised and disappointed because like me a lot of people think that there is still room for Java in the mobile platforms. Of course we have J2ME, but we can do very few things with it. What we need is a full J2SE stack for mobiles. And the iPhone could do it... if Mr. Jobs wants. But he does not want because Java has become the flag of Google to do developers to follow them. He chose to keep Java out of the iPhone to keep a strict control of the platform, to keep Google out of his business.
I have just reviewed what Google Android is, it's architecture and the SDK and I think it's much more than a smart mobile platform: it's a philosophy. Think of what SWT is to the Java User Interfaces and apply it to the Android Architecture. The access to the physical layer has been developed in C/C++ on top the Linux OS, and on top of it there is a pseudo-Java Virtual Machine called Dalvik virtual machine. As they say, "Dalvik has been written so that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) format which is optimized for minimal memory footprint. The VM is register-based, and runs classes compiled by a Java language compiler that have been transformed into the .dex format by the included "dx" tool."
J2ME is very similar in the approach, but what looks new is the tight integration with the OS and the use of Java 5 extensions of the language. J2ME is almost JDK 1.0, but if you read the source code of the samples, you can recognize some coding practices of Java 5. I still don't know if the Dalvik VM can do reflection or annotations, I will need some time to test it.
The access to the physical elements of the mobile device are performed thanks to the set of android.* packages. So, it will be a task of the device manufacturer to migrate the C/C++ libraries layer for their devices. I have tried to find some information about how to certificate that the libraries has been migrated correctly. This was one of the key elements for the success of J2ME on the mobile phones, and should be done the same way.
The Java applications are what they call 'Third party applications'. It's not possible yet to develop or modify the underlying Linux OS and the C/C++ libraries. Again, Java runs in a sandbox -sounds familiar, eh?-.
I will continue playing with it. Just some random thoughts, will Sun Microsystems get some money for the licensing of Dalvik VM? How much? Will J2ME be replaced by the Dalvik VM?
Massive refactoring of Gmail breaks my Greasemonkey scripts
Tuesday, October 30, 2007
This evening I was surprised with a message in my GMail screen: in red and bold the application advised me to switch off Firebug to improve the performance of the application. First I thought it was another update from Google, but when I saw at the top left 'Older version' then it was clear: Google has just released a new version of GMail.
And here comes the bad news: my own developed Greasemonkey scripts stopped working because of the massive changes in the inners of the application. The ids of the tags have changed, there is not frames any more, and the application do tricky things with the events. But the worst of all is the fact that Gmail is not working properly with my scripts!!! The 'Compose' link does not work, and this is only after 30' of testing!
Google Phone OS Java based?
Tuesday, September 04, 2007
I have just read this post in Engadget about rumours of the Google Phone. I will highlight this: '...the phone will run on a Linux variant (which is nothing new), and will be Java Virtual Machine-capable. Additionally, the OS of the phone will be Java-based (as well as the all phone apps itself), and performance is said to be "very responsive."'
It seems the GPhone will look like a Palm Treo or Blackberry with a screen smaller than the IPhone.
If these rumours are true, Google will become a big supporter of Java for interactive devices something the device market needs desperately to set free of the Windows Mobile and CF.NET slavery.
GPay: Google Patent for Mobile micropayments
Monday, September 03, 2007
Today in several RSS feeds I have found the same news: Google has a new patent for mobile micropayments. Micropayments using a cell phone is not new at all. I have seen some projects in Europe, specially the Spanish Mobipay. It's a mature technology, but it's not very successful. There are several reasons but it's not clear why mobile micropayments are not growing. In my opinion:
- The fee is charged directly to the customer. If you buy a Coke in a vending machine and you pay 1€ with a coin, you have to pay 1.10€ with mobile micropayments. So the micropayment is the last option.
- For more expensive goods Credit Cards or Cash are preferred. Why? Again because the Credit Card fee is charged to the seller, not to the customer.
- With mobile micropayments your credit is given by the Mobile Operator. The Mobile Operator needs to cover the risk, and this is an overhead compared to the credit card model (everybody knows how a Credit Card works, isn't?)
TouchGraph: a tool to graph how Google connect your website with many others by affinity
Sunday, September 02, 2007
Recently I have discovered TouchGraph, a tool that reveals the network of connectivity between websites, as reported by Google's database of related sites. I have tested it with this blog and the result is this:
The www.javablogs.com looks like this:
This tool can reveal how google see your website. Analyzing this information you can find out if your site is seen as a Java Blog or a Wireless network Blog, which is my case. 
VMWare challenges Google for developers
Wednesday, August 22, 2007
Since the successful IPO of VMWare, it seems everybody is talking about them. Today we can read in Bloomberg that they are competing with Google for the best programmers. VMWare is paying $120.000-$130.000 plus stock ops to talented developers. Compared to the spanish salaries that's really a huge amount of money. They have right now 500 open positions in Palo Alto offices.
YouTube comprises 10% traffic on the Internet
Wednesday, June 20, 2007
I have just read this report from ellacoya networks. It explains how http traffic has overtaken p2p traffic thanks to video and audio streaming. And YouTube comprises 10% of whole internet traffic, and more than 20% of http!
I could never imagine that YouTube is so big. But what it makes me wonder how much time people waste in YouTube daily, and how it affects productivity.
Meraki: Mesh networks can kill Wimax
Thursday, April 19, 2007
One of the most interesting technologies to come are mesh networks. In Amplia we are making some prospects on these technology applied to the M2M (machine to machine) communication. Zigbee fits perfectly for small amount of data, but it's not good when dealing with mobile communications (PDAs, laptops, MP3 players... anything interactive and portable).
The only real ubiquitous networks today are the mobile operators networks. GPRS has an acceptable deployment, closer to 100% of the population in developed countries, but 3G technologies are still far from being everywhere. And probably they will never replace the GSM/GPRS in some areas. 3G networks let the users enjoy of the "mobile experience", providing connectivity anywhere. The problem? The concept of flat fee is out of the scope of the mobile operators, and they charge per use (ok, they give flat fee with a traffic cap). This means that mobile operators cannot attract to the mass of users that use the Internet to share media content, 80% of the Internet traffic in Spain, for example. They only attract business users.
A couple of years ago, Wimax looked like the perfect technology for mobile operators (or alternative operators) to reach out the average Internet user. The deployment was cheaper because of the operation range of the stations and the speed of communication was higher than 802.11G. But we are in 2007 and Wimax has not exploded. Why? There are several reasons:
1) it seems that the deployment of the network is not so cheap,
2) Wimax was sold as a replacement of Wifi, but actually is a replacement for Cable and DSL, very mature technologies.
3) Wimax hardware is not very popular, and it's expensive compared to DSL+Wifi solutions, for example.
4) The spectrum limits the amount of data guaranteed per users. So, depending the density of the area, the size of the cell can be like the size of standard mobile networks.
So basically if you want to deploy a Wimax network in metropolitan areas, you will have to compete with Mobile Operators and Internet Service Providers. The niche where Wimax can beat other technologies are:
- non very populated flat areas, here Wimax is a winner.
- metropolitan areas with flat-fee of traffic data, for mobile users.
I read in Linux devices that Meraki was selling a Wifi mesh router for less than 50$ (37€). There are also discounts per volume. We have tested mesh networking with OpenWRT and it works, the problem was the cost of the devices. The cheapest one was three times the cost of the Meraki's gadget. If we take the budget of the Wimax base station, we can buy 2000 routers, and we still have 20000$ to pay the installation of the devices (10$ per device... a bit low). If we deploy the network in a grid of 5Km x 4Km, we can cover 20 sq-Km, assuming a distance between nodes of 100meters. That's 4-5 times the area covered of by the Wimax base station!
May be I'm making some naïve assumptions, but the point is: may be Wimax is dead because Mesh Networks are cheaper to deploy. Wimax follows the 'mobile operator' approach: complex centralized infrastructure. Mesh networks follows the opposite approach: simple distributed infrastructure. In the wired world, internet has proven that the distributed approach is the right one. Google is the perfect example of the success based upon the concept of distributed computing. And do you know who is backing up Meraki? Google, of course...
Mobile operators and ISPs, Google is going to take over your business soon!
Is Google going to fire Isabel Aguilera soon?
Monday, April 16, 2007
Today an online Spanish newspaper congrats Isabel Aguilera (Google Spanish CEO) for not screwing up the purchase of DoubleClick by Google. Besides the sarcasm of the headlines, the newspaper says that the time of Isabel Aguilera in Google is running out, and she could leave the company very soon.
It's not a surprise that she will leave the company (the surprise is she has not been fired yet). Reading the profile and curricula of this women, I wonder myself if Google contracted the wrong headhunter.
