Just saw Google Play Music got a free, ad-supported version (blog post). I told Andrew about it:
holyshit.
Pain-free OAuth with AppEngine
I do a lot of side projects (or at least start them) and implementing authentication is always like chewing on razor blades. I started another project recently using AppEngine and, bracing myself with a lot of caffeine and “suck it up, princess” attitude, I started doing “oauth appengine” searches.
After digging through some documentation, I realized that AppEngine actually does OAuth right. All you have to do is add the following to your src/main/webapp/WEB-INF/web.xml file:
my-thing
/members-only/*
*
The <url-pattern>/members-only/*</url-pattern> means that when someone goes to any page under members-only/, they’ll have to go through the “login with Google” flow.
On the server side, there’s no annoying URL encodings to get right or tokens to keep track of. You can just access the logged-in person’s username, e.g., in Java:
public class DemoServlet extends HttpServlet {
@Override
public void doGet(HttpServletRequest req, HttpServletResponse resp)
throws IOException {
String account = req.getUserPrincipal().getName();
...
}
}
That’s it! This is such a killer feature to me, I can’t believe I never knew about about it before.
(One other thing that I can’t believe I never knew about is SimpleHTTPServer. python -m SimpleHTTPServer will serve static files from the current directory. I’m pretty sure everyone already knows about this, but just in case there’s someone else out there…)
API changes with extra cheese, hold the fear
When you make a change, how do you know what tests to run? If you’re lucky, no one else depends on your code so you can just run your own tests and you’re done. However, if you’re writing useful code, other people are probably going to start depending on it. Once that happens, it becomes difficult to make changes without breaking them. Bazel can make this easier, by letting you figure out all of the targets that are depending on your code.
Suppose we are working on the pizza library and we need some cheese, so we create a cheese library and depend on it from pizza. If we look at our build graph, it will look something like this:
//italian:pizza is depending on //ingredients:cheese, as expected.
A few weeks later, the macaroni team discovers that it could also use cheese, so it starts depending on our library. Now our build graph looks like this:
Both our team’s pizza target and the macaroni team’s mac_lib target are depending on //ingredients:cheese. However, Team Macaroni never told us that they’re depending on cheese, so as far as we know, we’re still its only users. Suppose we decide to make a backwards-breaking change (e.g., make Cheese::setMilkfat() private). We make our change, run all of the pizza– and cheese-related tests, submit it… and break //american:mac_and_cheese as well as a dozen other projects who were calling setMilkfat() (that we didn’t know about).
If we had known that other people were depending on our code, we could have let them know that they needed to update their API usage. But how could we find out? With Bazel, we can query for everyone depending on our library:
$ bazel query 'rdeps(//..., //ingredients:cheese)'
This means: “query for every target in our workspace that depends on //ingredients:cheese.”
Now we can check that everything in our code base still builds with our cheese changes by running:
$ bazel build $(bazel query 'rdeps(//..., //ingredients:cheese)')
Just because they built doesn’t mean they work correctly! We can then find all of the tests that depend on cheese and run them:
$ bazel test $(bazel query 'kind(test, rdeps(//..., //ingredients:cheese))')
Unpacking that from the innermost parentheses, that means: “find the targets depending on //ingredients:cheese (rdeps(...)), search those for targets that are tests (kind(test, ...)), and run all of those targets (bazel test ...).”
Running that set of builds and tests is a pretty good check that everything that depends on cheese still works. I mean, if they didn’t write a test for it, it can’t matter too much, right?
Right.
Have you ever looked at your build? I mean, really looked at your build?
Bazel has a feature that lets you see a graph of your build dependencies. It could help you debug things, but honestly it’s just really cool to see what your build is doing.
To try it out, you’ll need a project that uses Bazel to build. If you don’t have one handy, here’s a tiny workspace you can use:
$ git clone https://github.com/kchodorow/tiny-workspace.git $ cd tiny-workspace
Now run bazel query in your tiny-workspace/ directory, asking it to search for all dependencies of //:main and format the output as a graph:
$ bazel query 'deps(//:main)' --output graph > graph.in
This creates a file called graph.in, which is a text representation of the build graph. You can use dot (install with sudo apt-get install graphviz) to create a png from this:
$ dot -Tpng graph.png
If you open up graph.png, you should see something like this:
You can see //:main depends on one file (//:main.cc) and four targets (//:x, //tools/cpp:stl, //tools/default:crosstool, and //tools/cpp:malloc). All of the //tools targets are implicit dependencies of any C++ target: every C++ build you do needs the right compiler, flags, and libraries available, but it crowds your result graph. You can exclude these implicit dependencies by removing them from your query results:
$ bazel query --noimplicit_deps 'deps(//:main)' --output graph > simplified_graph.in
Now the resulting graph is just:
Much neater!
If you’re interested in further refining your query, check out the docs on querying.
Hello, Bazel
Yesterday, my team open-sourced Bazel, the build system Google uses for most of its software. We have been working on open-sourcing Bazel for over a year, extricating dependencies, renaming and refactoring, and jumping through legal and political hoops. We were still missing a lot of stuff we wanted to add, but we thought it would be useful to get a less complete project out there and start getting some feedback from “friends and family.” So we hit the “make public” button on Github and IM-ed some friends. “We on Hacker News yet?” someone joked. We checked. We were. Over the next half-hour, we rose to #1 on Hacker News and stayed there all day. Twitter exploded with hundreds of tweets about Bazel and we started getting a constant stream of issues and pull requests. Our “press the button on GitHub” meeting turned into an all-day war room, responding to users and fixing documentation and setup issues.
It was exhilarating and amazing. I knew that a lot of people were excited to try Bazel, but this response has exceeded all of my expectations.
I hope that everyone will bear with us as we work the kinks out. Hugely important missing pieces that I can think of off the top of my head:
- No binaries available – you have to compile from source.
- No externally available continuous integration – no guarantee the code is actually compiling.
- Terrible setup process – you have to manually add a WORKSPACE file and symlink the tools/ directory to make your project buildable with Bazel.
Please do give Bazel a try if you’re interested, give us feedback, and, if you hate it now, give it another try in a couple of months when we actually launch!
Making wedding rings
This weekend, Andrew and I made our own wedding rings. We’ve been married for several years, but we never got around to getting rings. We found out about a guy in NYC who does ring-making workshops: you come to his studio and spend a day making personalized, custom rings. It was fun, and now we have very special rings!
Here’s what we started with at 10am:
We made each other’s bands, so Andrew used the thin piece and I used the thick piece. The long strip was for the side rails.
We were using palladium, which we had to anneal (make hot) to make it bendy. When palladium gets hot it turns purple, which is interesting:
Once it was bendy, we used pliers to bend it into something roughly ring-shaped:
It was more D-shaped, but the point was just to connect the ends, which we soldered together:
After some shaping, we had to hammer the bands so that we could get the “beaten” appearance we wanted:
We had to re-anneal the rings several times while beating them, so they wouldn’t get brittle:
Then we had to create two more “rings” for rails and stick everything together with solder:
Finally we polished the things:
It took us twelve hours, but I think they came out pretty good:
I highly recommend it as a fun and romantic way to get wedding rings.
Laptops are getting smaller all the time
As a “thank you” for hosting an intern this summer, Google gave me a little Android figurine. When I took it out of its box, a little backpack fell out, too. The backpack actually zipped and unzipped, but it didn’t have anything in it. So I decided to make a Macbook Air for it.
First, I made the Apple logo at a reasonable size as a small tube:
Then I rolled out the tube to miniaturize the logo:
I didn’t roll it out quite evenly enough, so I lost the leaf. However, the apple’s shape came out pretty well:
I sliced off a piece of my “Apple tube” and dropped it into a grey rectangle for the Macbook body. Then I had to add back in the leaf. The logo was so tiny at this point that even the tip of a pin was a little big for the amount of clay I was working with:
Finally, I baked it and put it in the backpack!
Teaching CS
I taught my first AP CS class on Thursday. I was wearing a Google teeshirt (it was a “nice” one, have to dress up for the first day of school) so the first thing the students asked me was, “Do you work for Google?” Then: “Can we visit Google?” And: “Will this help us get an internship there?”
I started out with a little “why learn programming/why programming is cool” spiel. I showed them Abundant Music and let them try out my Cardboard, both of which seemed to impress them. Next week, we’re going to discuss Net Neutrality!
Sharing Programming
I’m going to be volunteer teaching AP computer science this fall at a NYC high school! Aside from actually prepping them for the AP exam, I’ve been thinking about how to share the programming culture I love with the students. Off the top of my head, I’d like to tell them about:
Stuff you can do to program for fun:
- Hackathons
- Game jams
- Project Euler
Where programmers hang out:
- Github
- StackOverflow
- HackerNews
- IRC
Programming culture and history:
- Basic security: anyone can come up with a scheme that even they, themselves cannot break.
- How the internet/websites work.
- Notables in the field: stories about Stallman, Knuth, Linus.
- Cartoons: XKCD… there must be others.
- Obfuscated C (and other languages) contests.
- Read Joel Spolsky’s blog.
I’m sure there’s loads of stuff I’m missing. Any other ideas?
I will gladly write a test Tuesday for a program today
When I started at Google last year, I was really impressed by their testing. Every C++ class had three files: a <classsname>.h file, a <classsname>.cc, and a <classname>_test.cc. Every time something new is implemented, it has to be tested. The code review tool even warns you if you add a new .h without an accompanying _test.cc.
The upside to this is that I am very sure that my code does what I want. There are, of course, still bugs, but generally they’re of the “I hadn’t thought of that case” rather than the “I didn’t implement it the way I meant to” variety.
A side effect is that writing tests forces a decent separation of concerns. If you’re throwing around singletons and hiding twenty layers of functionality in a class’s privates, you’re going to have a bad time. Conversely, if you’re making things testable, each class essentially becomes a wrapper for the resource below it: “I take a database connection and add some query logic,” “I take a storage wrapper and add some app-specific logic,” “I take app responses and present it to the user.” The whole application falls into beautiful, simple layers like a mille-feuille cake.
The downside is that writing tests is so. slow. It often takes me three times as long to write a test than it did to write the code. I think that, if you’re working at a startup, it’s actually probably not a good idea to have a culture of testing like this because it will slow down your coding so much. For most startups, getting something to market in 33% of the time that 90% works is much more important than getting it to 99%. In fact, Google hasn’t always had this culture. If you look a the dark corners of the code base, there are tons of old, untested classes.
I count myself as lucky to know the guy who actually inspired the testing culture that Google has now: Mike Bland. He’s been writing a series of articles on testing for Martin Fowler’s site. If you’re interested in testing, I recommend reading them.
Kristina Chodorow's Blog 