Google Charts API and E. E. Cummings

Today I was working on some charts using the Google Charts API and I decided to take a look at some of the documentation. Many of the X-axis labels on the chart I have are overlapping and I’m trying to fix it:

So in the process, I started looking at the data scaling section of their documentation, and they had a nice graph with a lot of data points but only a couple labels:

I wanted to see exactly how this was done and so I viewed the source of the image, which when using the Google Charts API tells exactly how the chart is being rendered.

That’s when I came across E. E. Cumming’s poem “i thank You God for most this amazing” embedded in the URL.

http://chart.apis.google.com/chart?cht=lc&chs=200x100&chd=s:ithankYouGodformostthisamazingdayforthel&chxt=x,y&chxl=0:|Apr|May|June|1:||50+Kb

You can read the poem in its entirety at poetry-chaikhana.com.

A First Shot At Using Google Closure Tools

Just recently, Google made public their Google Closure Tools. The Google Closure Tools are a set of three tools that can be used to write fast loading and executing JavaScript, animated UI elements, templated DOM structures, and more. The three tools are: Closure Library, Closure Templates, and Closure Compiler.

I recently wrote a Pearson Correlation calculator in Python and decided to port it to JavaScript for use on a webpage. I thought this would be a good opportunity to try out some of the Closure Tools.

I used the Closure Library and the Closure Compiler for this little exercise.

After the development was completed, I used the Google Closure Compiler to reduce the size of the JavaScript. The pre-compiled JavaScript size was 634kb. The compiled JavaScript size is a mere 33.96kb.

I am very impressed with the tools. First, the documentation is superb, and I am amazed at the number of demos that are available for most of the UI components. Second, there is finally a way to evaluate JavaScript in a ‘compile-time’ fashion.

These two alone make these tools worth checking out. I hope to gain more experience with the Library soon, and should have more to post about it.

Ordering of Include Statements to Reduce Hidden Dependencies

The Google C++ Style Guide says that #include statements should be ordered in the following way (if you are writing foo2.cc):

1. dir2/foo2.h (preferred location — see details below).
2. C system files.
3. C++ system files.
4. Other libraries’ .h files.
5. Your project’s.h files.

The goal of this is to reduce hidden dependencies within header files. My question is, shouldn’t system files be included after library/project files? I would think that there is a guarantee that the system files aren’t going to include other library/project files, so wouldn’t the following order make more sense to find hidden dependencies?

1. dir2/foo2.h (preferred location — see details below).
2. Your project’s.h files.
3. Other libraries’ .h files.
4. C system files.
5. C++ system files.

Using Google Mock outside of Google Test

I’ve just finished getting an implementation going of MSTest with GMock, and I wanted to document all things neccessary to use GMock in a testing framework other than GTest.

To get GMock to build in VS2008, I had to install the Visual Studio 2008 Feature Pack. This was so I could get full TR1 support, specifically std::tr1::tuple. Other coworkers of mine haven’t needed to install the Feature Pack, though I presume that they didn’t need to because they had SP1 installed (which I thought I had installed). After installing the Feature Pack, I then had to reinstall SP1 due to some odd compiler errors that were occurring due to mismatched compiler versions.

Now some quick gotchas with GMock:

• If you use the included gmock_gen.py script to generate your mocks from your pure abstract classes, then you will need to make sure that there are no default arguments in any of your mock’s methods.
• When you add expectations to a mock, you should call VerifyAndClearExpectations at the end of your test method. You should assert that this method returns True. If you don’t include this method call, then your testing framework won’t be able to catch the GTest exceptions that will get thrown if the GMock’s expectations aren’t met.

Those are the only points I wanted to put out there at this point. When I run in to more bumps in the road I’ll be sure to publish them.

Omaha aka Google Update

I just set up my environment and built Omaha, the open-source codename for Google Update. Google Update is used within Google Chrome and Google Earth.

Omaha’s functionality allows us to automatically update software without interrupting or distracting the user, which makes for a better user experience. Omaha checks for updates in the background, when it won’t interfere with the user, even if an application isn’t running. Doing so means that we avoid using a computer’s resources when it first starts, avoiding a common bottleneck in computer performance experience. Omaha does not perform updates when an application launches, because we understand people want to use the software when starting it up, not perform maintenance tasks first.

This is very cool technology. It would be nice if I opened up Firefox and instead of it telling me to run through a installer when there is a new version, I was just running the latest. Currently, the server that this software talks to can only be a Google server. I’m interested to see if there is a way to have it talk to third-party servers, or get your application registered with Google’s server.

An interesting use-case to want it to talk to a third-party server would be for enterprise software that has a client-server relationship. Let’s say you install a server on your network and users download a client from that server to use the software. Currently, there is a lot of work for that administrator when it comes time to update the server as they would have to update all the client machines (whether that means updating an image file or physically walking to all the machines).

How nice would it be for that administrator to update their one server and then have all the clients automatically updated! This would have to talk to the local server on the network, since it is up to the admin to update their server when they see the most stable time.

Any other ideas/uses?