Showing posts with label google. Show all posts
Showing posts with label google. Show all posts

2010-07-09

Three Small Ideas

I was glad to be interviewed by DZone a while ago. The second interview was on my current Open Source work and I gave what is probably a non-traditional answer on why Open Source contribution is important for a developer. The google appengine project I'm talking about is the qrcode linkulator. And, for the record, I've got a better hair-cut now.



My statistics are from this article on Functional Fixedness at wikipedia. The over-lapping concept I'm trying to tease out is that there are problem solving exercises that are not served by tightly focused environments like business. As a developer you need to be able to work in spaces that allow for creative freedom and the lessons you learn there (for better or worse) translate back into your "high pressure" environment. The result is a better developer that is able to think outside the parameters of the problem.

A nice animation covering the idea popularized by Daniel Pink (who is an infinitely better speaker) is on youtube:


My contribution is: not only is open source a product of intrinsic motivation... it creates intrinsic motivation to improve yourself as a developer. These improvements translate back to your "day job" ... so for purely selfish reasons you *should* create open source code. You will be forced to learn. You'll get interaction with other developers. You'll learn much more than if you stay locked in your office and never get challenged by people who never would think like you do and have no reason to pretend they do.

Even if the project is a failure and your contributions are insignificant... you'll learn something.

2010-03-30

QRCode Linkulator the interesting bit.

For me the interesting bit about writing QRCode Linkulator was creating a PNG on AppEngine. The JRE Class White List doesn't include any Graphical libraries. Notice that most of java.awt.* is missing?

Why would Google do that? Well, try downloading a copy of the OpenJDK. Go ahead. I'll wait. Got it now? Great. Now look in openjdk-6-src/jdk/src/share/native/sun/awt ... what do you see? A mess of native C code.

So key components of OpenJDK are written in C. Key components of AWT. That means if you want to do graphics (server side) in Java you need to hit some chunks of C code. I bet that's dangerous in AppEngine.

Combine this with the fact that pngj is the only project I could find that had a pure Java implementation of the PNG specification and the challenge of doing the "impossible" and the temptation to pull this off was irresistible. Consider how many programs rely on those classes and there is NO pure Java solution in existence.

At my current workplace we do a lot with cloud computing. Because of this I've got a special sympathy for the guys working on AppEngine. They probably have some technical infrastructural reason they can't let you get at those AWT classes either directly or indirectly. My guess is it has to do with how they implemented the custom JRE that your app runs in.

That combined with an interesting socio-economic constraint they placed on AppEngine applications makes me think that AppEngine isn't just "free" as in beer hosting but really an interesting way for Google to codify their chief aesthetic concerns about how applications function.

This aesthetic is born of cloud computing on a scale no other company gets close to. At this scale, apparently, an aesthetic similar to that found in embedded systems starts to come through. Which in my mind is extremely ironic. See... I've been doing some Android development lately.

Consider that your app-engine app may be sitting cold with no one using it. Then the user hits the application for the first time... perhaps deep linking into your application. The deep link re-activates the app. It's cold, dark, and if you are a scripting environment... not compiled requiring an interpreter to fire up, load your script and then interpret it.

Huge penalties in that environment. So I hear some clever developers have kept their applications hot by writing Google AppEngine Cron Jobs which hit the web application in some low cost way to keep it warm. That's pretty clever. But only works until your application scales.

Yes. That's right. It works until your application becomes really really popular. Why?

When your application scales your application is going to get provisioned with another "machine" on the Google Cloud. That application will be cold. You'll pay the warm up penalty for that application and that first user gets the raw deal having to wait while your app spins up. Bad news. This happens every time your app scales up one "machine" and the net effect can be Fail Whale like badness.

Besides, inflating your own app's "popularity" by "hitting yourself" seems a tad... well... evil. So please. Stop hitting yourself.

The "right" answer is to somehow mitigate that first page hit cost. You get that first page view cost down as close to zero as you can... then take it a little farther.

How? Anyone have ideas?

2006-11-30

Bi-Tek

Johnston County in North Carolina has gotten a temporary court order to get Google to remove a page from cache. The page contained the personal information of county residents including social security numbers and cell phone numbers. The news has focused the fact that Google did not respond instantaneously causing Johnston County to seek a court order from an NC judge and not the fact that one of the county's contractors was negligent in its handling of sensitive data.

While it is disturbing that Google doesn't respond faster to requests to clear Personally Identifiable Information from its cache... Johnston county did leave the information languishing on the Internet for six weeks. And, how did this information make it to the web anyhow?

The News and Observer Article states that Bi-Tek creates a file that is posted to the Johnston county website and this file is supposed to contain only names, addresses, and non-private account numbers. Bi-Tek made a mistake that instead posted private data to the Internet.

Earlier this year the VA had its own incident where it potentially exposed the personal information of millions of veterans. Proving that large and small organisations alike have to fight employee ignorance, malice, and indifference regarding sensitive data. The questions that the press should really be asking might be:
  1. What is going to happen to Bi-Tek for this mistake?
  2. What are they going to do at Johnston County to make sure this never happens again?
  3. Will Google be motivated to create a special "Oops! I posted my credit card number on a bulletin board!" call center?
  4. Should software companies that handle sensitive banking, tax, and accounting data have to be certified? And, would an incident like this revoke the license of such a company? Should they ever get it back?
If you pay taxes in Johnston County, North Carolina you should be concerned about the security of your tax information and you should be asking questions about Bi-Tek, Johnston County's website, and what they are doing to safe guard your personal information that they have stewardship over.