Skip to main content

Random Comments from Google Developer Day

I went to Google Developer Day. Yeah, yeah, I know, that was weeks ago, and I'm only finally blogging about it now. Better late than never! Here are some random, sparse comments:

Keynote

There were about 1500-5000 developers world wide attending this event. A ton of APIs were launched in 2006. He mentioned Yahoo Pipes. Google Mashup Editor is a mashup of mashups. I felt pretty overwhelmed pretty quickly. Gears is about offline access for Web apps. It supports all major browsers and all major platforms. It's pretty weird to see SQL in JavaScript. It's based on SQLObject. There is a managed "sync" process. Google Reader will soon work offline. They're working closely with Adobe (e.g. Apollo). It was weird to hear the Adobe guy say, "Works on Linux". Sergey has a great sense of humor.

Gears Talk

You can configure a set of URLs for it to capture for use offline. This stuff is stored in a place separate of the normal browser cache. I saw a bit of code, "rs.getFieldByName('name')". Ugh! Why must people force JavaScript to look like Java? Don't they know that they could do "rs.name"? They implemented a worker pool so you can run JavaScript in the background. These are processes, so they don't have shared state. You can pass code as strings between the processes. They're adding full text search to SQLite.

Google Infrastructure Talk

Google was still at Stanford in '97. In their current design for servers, they went back to not using cases for the servers. They're still using low end hardware. Note that GFS is not at the kernel level. They have 200+ clusters. MapReduce is not used for user search. It's more for heavy duty tasks like indexing. BigTable is pretty amazing. It's a distributed, multi-dimensional, sparse map. They have fine-grained load balancing and fast recovery. They have distributed locks and a locking service. Their largest [BigTable?] is 3000TB on several thousand machines. I asked, and he said that open sourcing GFS "isn't unthinkable".

Google Web Toolkit

Ajax lets the server be stateless. The Java IDE they're using works with Google Web Toolkit even though the Java is being compiled down to JavaScript. Even setting breakpoints works, although to do this they're using a "hosted Web browser". A big benefit of GWT is that the IDE's refactoring support can be used on code that is getting compiled to JavaScript. All the compiling is done behind the scenes, so it feels more like editing a scripting language than editing a compiled language. In general, they prefer functionality over "bling". Hence, they prefer native UI elements rather than recreating all elements from scratch. GWT does the right thing with browser history. They use property files for I18N. They can catch errors in the property files as compile time. They do have nice advanced widgets. Font size changes are handled gracefully. The functional demos were pretty impressive. GWT takes care of managing the image cache really nicely. The compiler only puts in the JS libraries you actually need. Cute quote: "Even though it's open source, we decided to document it." If you're using GWT, you don't need to be an expert in browser quirks, you just need to know Java. GWT supports inline JavaScript.

Alex Martelli's Design Patterns in Python Talk

This is the third time I've seen this talk, and this time I was able to understand everything he said ;)

Theorizing the Data: Avoiding the Capital Mistake

This was a great talk about statistical approaches to linguistics. Probability stats papers were really big at the ACM in 2006. Everyone is fighting the spam problem. The speaker emphasized that more data results in better results, which is why he went to Google. Lots of data results in good machine learning which results in more useable language translations. In trying to do automated translations, nothing matter more than statistics. Getting hints from linguists wasn't all that helpful when they tried it. It would appear that humans may learn language by having a statistical understanding of patterns; after all, there are too many rules with too many exceptions.

Comments

Popular posts from this blog

Ubuntu 20.04 on a 2015 15" MacBook Pro

I decided to give Ubuntu 20.04 a try on my 2015 15" MacBook Pro. I didn't actually install it; I just live booted from a USB thumb drive which was enough to try out everything I wanted. In summary, it's not perfect, and issues with my camera would prevent me from switching, but given the right hardware, I think it's a really viable option. The first thing I wanted to try was what would happen if I plugged in a non-HiDPI screen given that my laptop has a HiDPI screen. Without sub-pixel scaling, whatever scale rate I picked for one screen would apply to the other. However, once I turned on sub-pixel scaling, I was able to pick different scale rates for the internal and external displays. That looked ok. I tried plugging in and unplugging multiple times, and it didn't crash. I doubt it'd work with my Thunderbolt display at work, but it worked fine for my HDMI displays at home. I even plugged it into my TV, and it stuck to the 100% scaling I picked for the othe

ERNOS: Erlang Networked Operating System

I've been reading Dreaming in Code lately, and I really like it. If you're not a dreamer, you may safely skip the rest of this post ;) In Chapter 10, "Engineers and Artists", Alan Kay, John Backus, and Jaron Lanier really got me thinking. I've also been thinking a lot about Minix 3 , Erlang , and the original Lisp machine . The ideas are beginning to synthesize into something cohesive--more than just the sum of their parts. Now, I'm sure that many of these ideas have already been envisioned within Tunes.org , LLVM , Microsoft's Singularity project, or in some other place that I haven't managed to discover or fully read, but I'm going to blog them anyway. Rather than wax philosophical, let me just dump out some ideas: Start with Minix 3. It's a new microkernel, and it's meant for real use, unlike the original Minix. "This new OS is extremely small, with the part that runs in kernel mode under 4000 lines of executable code.&quo

Haskell or Erlang?

I've coded in both Erlang and Haskell. Erlang is practical, efficient, and useful. It's got a wonderful niche in the distributed world, and it has some real success stories such as CouchDB and jabber.org. Haskell is elegant and beautiful. It's been successful in various programming language competitions. I have some experience in both, but I'm thinking it's time to really commit to learning one of them on a professional level. They both have good books out now, and it's probably time I read one of those books cover to cover. My question is which? Back in 2000, Perl had established a real niche for systems administration, CGI, and text processing. The syntax wasn't exactly beautiful (unless you're into that sort of thing), but it was popular and mature. Python hadn't really become popular, nor did it really have a strong niche (at least as far as I could see). I went with Python because of its elegance, but since then, I've coded both p