Search This Blog

My First Days at Google

It's day two of my new adventure as a Developer Advocate for Google. I have joined the Chrome Developer Relations team based in Mountain View, California, but more on that later.

Day One was a full day of Orientation. We are affectionately called Nooglers, and Google did a good job of introducing us to the culture, business, food, forms, tips, and even safety and security. My Noogler class was not small, and they run this every week! It's clear they are growing fast and have this orientation process down pretty well.

For those wondering, some of us were able to choose Windows laptops. Although, easily 75% or more of my Nooglers had a MacBook Pro on their desk. I heard from at least one PC user that they wanted to switch to Mac after seeing so many out there.

We received breakfast and lunch. As you can imagine, food is no joke to Google. I believe I dreamt about food last night! Feeding the Googlers is serious business, and I look forward to trying all 19 or so cafes on the Mountain View campus.

We received our badges, activated our accounts, received and updated our laptops, and listened to presentations for most of the day. I found the business one the most interesting. I look forward to the two week training period, where engineers learn about the Life of a Search Query, Server, Data Center, and other topics like logging and testing. Normally, the first two weeks are taken up by the training and just settling in, but because I'm headed to RailsConf 2010, I've got an accelerated schedule.

At RailsConf, I will be there representing the Chrome Web Store, among other technologies such as HTML5. Chrome Web Store, announced at Google IO 2010, is a new initiative from Google to help developers of web applications distribute and monetize their apps.

The details are scarce, even for me, but I'll be taking a crash course on Chrome Web Store this week before RailsConf. I think Rails developers are going to love Chrome Web Store, because they can more easily monetize their web apps.

I'll write more about Chrome Web Store as I learn it. If you will be at RailsConf 2010, and you are interested in Chrome Web Store or any other Chrome or HTML5 based technologies, please do look me up! I'd love to take you out for a drink so I can learn what you need from HTML5 or Chrome Web Store.

Popular posts from this blog

Now, this has to have a built-in somewhere in Scala , because it just seems too common. So, how to convert an Array to a List in Scala? Why do I need this? I needed to drop to Java for some functionality, which in this case returns an Array. I wanted to get that Array into a List to practice my functional programming skillz. **Update**: I figured out how to convert Arrays to Lists the Scala way. Turns out it's a piece of cake. val myList = List.fromArray(Array("one", "two", "three")) or val myList = Array("one","two","three").elements.toList The call to elements returns an Iterator , and from there you can convert to a List via toList . Nice. Because my first version wasn't actually tail recursive, what follows is a true tail recursive solution, if I were to implement this by hand. The above, built in mechanism is much better, though. object ArrayUtil { def toList[a](array: Array[a]): List[a] = { d

In which I port a snazzy little JavaScript audio web app to Dart , discover a bug, and high-five type annotations. Here's what I learned. [As it says in the header of this blog, I'm a seasoned Dart developer. However, I certainly don't write Dart every day (I wish!). Don't interpret this post as "Hi, I'm new to Dart". Instead, interpret this post as "I'm applying what I've been documenting."] This post analyzes two versions of the same app, both the original (JavaScript) version and the Dart version. The original version is a proxy for any small JavaScript app, there's nothing particularly special about the original version, which is why it made for a good example. This post discusses the differences between the two implementations: file organization, dependencies and modules, shims, classes, type annotations, event handling, calling multiple methods, asynchronous programming, animation, and interop with JavaScript libraries. F

In which the virtues of automated mechanical arboreal pruning are extolled over quaint manual labor, as applied to web development build processes. The setup Ever notice how the primary bit of marketing for many traditional web programming libraries is their download size? Why is that? Check this out: Why does size matter so much for these libraries? Your first instinct is probably, "because the more bytes you shuttle across the wire, the slower the app starts up." Yes, this is true. I'd also say you're wrong. The primary reason that size matters for these libraries is because traditional web development has no intelligent or automated way to prune unused code so you can ship only the code that is used over the wire. The web is full of links, yet web dev has no linker The web development workflow is missing a linking step. A linker's job is to combine distinct project files into a single executable. A smart linker will only incl