Subscribe to this blog

Follow by Email

Posts

I went to a tutorial on web performance at HTML5DevConf. These are my notes:

Daniel Austin was the instructor.

He worked down the hallway from Vint Cerf when he was creating the world wide web, and he was the manager of the team at Yahoo that created frontend performance as a discipline. He was the manager of the guy who created YSlow. A lot of the books on web performance are from people he used to manage. He was the "chief architect of performance" at Yahoo.

He's writing a book called "Web Performance: The Definitive Guide".

He started by asking us how many hops it took to get to Google (per traceroute).

I've been an Android user for several years. I have also written Android apps. About 9 months ago, I decided to switch to iOS in order to learn how to do iPhone development.You might be wondering what I think of iOS after switching. Ok, you probably weren't wondering, but I'm going to tell you anyway. I think it doesn't really matter very much. There are huge differences when it comes to developing for Android or iOS, but when it comes to usage, not so much.Sure, there are differences between the OSs. Each has a few features that the other doesn't have. But how do they impact my life? Pretty much all of the apps I personally care about are on both platforms. There's a huge difference between having a modern smartphone and not having one. However, I think the choice of which one to have isn't really that significant.

Don't you ever get tired of everyone in the world demanding your attention?It's like we're caught up in some vicious cycle of co-dependent attention slavery. There are a million apps and companies notifying you all the time that you have to pay attention to them. If it isn't a notification, it's an email. You spend countless wasted minutes every day clearing these notifications and dealing with these emails.On the other hand, companies are desperate to get your attention. They track things like monthly active users, views, likes, etc. The financial success of various companies is directly connected to how many users they can get to log into their products, and how often they can get them to log in. Furthermore, a linear growth in usage is not acceptable. Everyone wants a hockey stick of exponential growth. Yes, I'll admit the hypocracy in my complaining about this considering I worked in developer relations for two years, and I worked at a social media company f…

I left Twitter several weeks ago. It looks like I need to not only decide where I want to work next, I might also need to decide what I want to specialize in as a programmer. Apparently, there's less and less demand for full-stack web developers or generalists. Most open positions are for specialists.I've always been a polyglot. I really like learning new languages. Even though I'm mostly a Python expert, I love to learn as many new languages as possible. For instance, I accomplished the following just while I was at Twitter:I built a custom supply chain management system in Python.I technical edited two Scala books.I learned Go fairly well.I learned Android at a beginner to intermediate level.I learned Objective-C and iOS at a beginner to intermediate level.Another thing that sets me apart from most programmers is that I'm a friendly extrovert, and I like giving talks. Given the above, developer relations is a natural fit for me. I did that for two years at Google.How…

During the first year of a typical Google datacenter, there will be five rack-wide outages, three router failures large enough to require diverting processing away from connected machines, and eight network scheduled maintenance windows, half of which cause 30-minute random connectivity losses. At the same time 1 to 5 percent of all disks will die and each machine will crash at least twice (2 to 4 percent failure rate).Dean, J. (2009), Designs, lessons and advice from building large distributed systems.

Over the years, I've read a lot of books on software engineering. Agile books in particular like to refute the "Waterfall Model". Every time I read about the Waterfall Model, I think to myself: I'm sure there must be companies out there that have tried this approach, but I have a hard time believing some software book would seriously propose it as the best way to write software. It must be the boogie man of software engineering methodologies.
I was reading The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems, and I came across this quote:Royce’s 1970 paper, which is credited with “inventing” the model, actually identifies it so Royce can criticize it and suggest improvements. He wrote it is “risky and invites failure” because “design iterations are never confined to the successive step.” What Royce suggests as an alternative is similar to what we now call Agile. Sadly, multiple generations of software developers have had to …

I wanted to try out Google Compute Engine, but I wanted to build something other than a simple web app. Hence, I setup a virtual server that runs tetris when you log into it, and I gave everyone the credentials :)
$ ssh -o UserKnownHostsFile=/dev/null -o CheckHostIP=no -o StrictHostKeyChecking=no tetris@104.154.80.84 # Password: tetris
Here's the code. I set it up so that gotetris is the login shell, and the user doesn't have permissions to modify any files. Hence, it should be relatively safe to share with the world ;)

I implemented a console-based version of Tetris in Go.In general, it was a pleasant experience. I made use of the termbox-go library for console graphics, and it was enjoyable as well.I've been reading a lot of blog posts recently about Go, and I think this blog post is the one that captures my opinions best. It's also a treasure trove of useful links to various other blog posts and tidbits.Anyway, as I said, it was a fun experience :)

In Go, the append function reallocates the underlying array if there's no more room. Hence, if you have two slices that point to the same array, after you append to one of the slices, the other slice may or may not point to the same array. This can lead to some unexpected behavior:
package main
import "fmt"
func main() {
// Create a slice of length 1 and capacity 2.
a := make([]int, 1, 2)
// b "aliases" a
b := a
// If I set something in a, you see it in b.
a[0] = 1
fmt.Println(a[0], b[0]) // Prints 1 1; they're equal.
// append returns a new slice, but with the same array.
// Hence, if I set something in a, you still see it in b.
a = append(a, 2)
a[0] = 2
fmt.Println(a[0], b[0]) // Prints 2 2; they're equal.
// I'm doing the same thing as last time. However, this time,
// append has to allocate a new array because there's not enough
// space. Hence, if I set something in a, you don't see it in b.
a = append(a, 3)
a[0] …