Skip to main content

Benjamin Oakes

Photo of Ben Oakes

Hi, I'm Ben Oakes and this is my geek blog. Currently, I'm a Ruby/JavaScript Developer at Liaison. Previously, I was a Developer at Continuity and Hedgeye, a Research Assistant in the Early Social Cognition Lab at Yale University and a student at the University of Iowa. I also organize TechCorridor.io, ICRuby, OpenHack Iowa City, and previously organized NewHaven.rb. I have an amazing wife named Danielle Oakes.

Filtering for the month February, 2015. Clear

How to Set Up GitHub Pages with a Custom Domain

by Ben

Setting up a custom domain with GitHub Pages – GitHub Help.
Tips for configuring a CNAME record with your DNS provider – GitHub Help.
How to Set Up Github Pages with a Custom Domain on Gandi – Daniel Spector.

Some useful resources if you only have to think about DNS a few times a year, like me.

Why Wesabe Lost to Mint

by Ben

Why Wesabe Lost to Mint – Marc Hedlund’s Blog.

I’ve come across this blog post a number of times, and it always makes me think. (Wesabe is also notable for having open sourced their code after failing, though it hasn’t gotten much continued development.) Regardless, more companies should share stories like these so others can learn from them.

From the post:

Mint focused on making the user do almost no work at all, by automatically editing and categorizing their data, reducing the number of fields in their signup form, and giving them immediate gratification as soon as they possibly could; we completely sucked at all of that. Instead, I prioritized trying to build tools that would eventually help people change their financial behavior for the better, which I believed required people to more closely work with and understand their data. My goals may have been (okay, were) noble, but in the end we didn’t help the people I wanted to since the product failed. I was focused on trying to make the usability of editing data as easy and functional as it could be; Mint was focused on making it so you never had to do that at all. Their approach completely kicked our approach’s ass. (To be defensive for just a moment, their data accuracy – how well they automatically edited – was really low, and anyone who looked deeply into their data at Mint, especially in the beginning, was shocked at how inaccurate it was. The point, though, is hardly anyone seems to have looked.)

Why open source and open standards matter on Android

by Ben

Google has a mixed history with their product offerings. Though they were once the poster child of open source contributions and open standards, they are now shutting down well-liked, standards-based services to move users to applications that are more tightly integrated in the Google ecosystem, allowing them to more closely track users and collect more data for advertising purposes. As examples, Google Reader (which used the RSS and Atom standards) was shut down in favor of Google+, CalDAV access was limited for Google Calendar (though I think they partially reversed that decision), and they’re in the middle of shutting down Google Talk (which uses XMPP, the same as Facebook and others) in favor of Google Hangouts. The writing is clearly on the wall for FeedBurner and maybe even IMAP access to Gmail. The idea of Google killing off IMAP seemed far fetched a couple of years ago, but now that “Inbox by Gmail” is their vision for email’s future, it certainly seems possible in a few years.  All of this means that Google will have much more control over how and when we can use our data.

It’s no secret that Google is continuing to migrate Android from being an open source smartphone to an OS to host its proprietary apps and services. That said, Android is still the most open of the mainstream mobile platforms. Compare that to Apple’s iOS, which is very unlikely to ever receive a version of Firefox that isn’t just a skin for Safari and specifically bans code from the App Store if it uses certain types of open source licenses, like the General Public License (GPL).

Thankfully, open source and standards-based solutions are available on Android. They don’t have a “kill switch” for any one company to flip.  The important thing is to use them.

Given the above, if you’re not the fondest of relying on Google for yet another service and would like to know if open source, standards-based apps exist for your need, these are some good sources to consult:

Should you only use open source applications? Well, it might not be that enjoyable of an experience on mobile today… and although open source matters, open standards might even be a more important distinction to consider as we move more and more towards cloud computing, considering that products will continue to appear and disappear over time.  Certainly, if you have a choice between a closed-source app that uses open standards and a closed-source app that uses the opposite (i.e., proprietary APIs), it would likely to be in your own best interest to strongly consider the former, given the long term.

The list of sources is just a starter set, but worth a look the next time you’re looking for software.  If open source and/or open standards aren’t on your list of considerations, there might not be much software that use either in the future.

Update: I’m happy to know I’m not the only one who feels this way.  Dan Bernier shared this related post with me: Your App Is Not Better Than An Open Protocol.

Bringing asm.js to the Chakra JavaScript engine in Windows 10

by Ben

Bringing asm.js to the Chakra JavaScript engine in Windows 10 – IEBlog – Site Home – MSDN Blogs.

Second but more importantly is the fact that asm.js is a pure subset of JavaScript and guarantees interoperability across platforms and browsers. This means that engines that support asm.js light up the new features, while engines that don’t will simply run with degraded performance. Since the beginning of Chakra, our team’s focus has always been to prioritize this approach to new functionality.

The future of the browser just got a little more interesting. That Firefox and IE are both supporting asm.js is a clear step towards eventual standardization. This development goes to show the cleverness of the asm.js approach over, say, Google’s Dart.

HTTP/2 finished, coming to browsers within weeks

by Ben

HTTP/2 finished, coming to browsers within weeks.

HTTP/2 is based in large part on Google’s SPDY. SPDY did some things that HTTP/2 does not. It required the use of TLS (Transport Layer Security) to enhance privacy and security. HTTP/2 makes this optional; it can operate over TLS or over plain TCP. Some vendors, however, have said that their implementations will only support HTTP/2 over encrypted TLS connections to regain these privacy benefits.

Okay, so some browsers will require TLS and others won’t? No wonder I’m confused. If I were to guess, I’d imagine we’ll see most browsers support unencrypted HTTP/2 in a few years, provided enough of them support unencrypted connections initially. (Who would want to be the vendor of the only browser that’s forced to use the slower HTTP/1.1 on some sites?)

That’s not to say TLS is a bad idea. I just don’t think this requirement will stand the test of time given that it’s already giving way.

Iowa considers banning conversion therapy

by Ben

Iowa considers banning conversion therapy.

Iowa could become only the third state in the country to outlaw therapy techniques designed to change the sexual orientation of gay and lesbian youth.

Iowa has a history of firsts for human rights. This is a very good thing.

Code Rush, a documentary about Netscape circa 2000

by Ben

I happened upon Code Rush today, which is a documentary about Netscape becoming Mozilla. It’s freely available on the Internet Archive and YouTube (Creative Commons-licensed, CC BY-NC-SA 3.0 US).

From the Wikipedia article:

Code Rush is a 2000 documentary following the lives of a group of Netscape engineers in Silicon Valley. It covers Netscape’s last year as an independent company, from their announcement of the Mozilla open source project until their acquisition by AOL. It particularly focuses on the last minute rush to make the Mozilla source code ready for release by the deadline of March 31, 1998, and the impact on the engineers’ lives and families as they attempt to save the company from ruin.

It’s interesting to see this in retrospect. The web wouldn’t be what it is today if it weren’t for Netscape open sourcing their browser. It’s also interesting to see how little has changed in the startup community. However, I was surprised to find a good chunk of the film is dedicated to the Netscape developers trying to pay down their technical debt (fixing bugs). If memory serves me though, Mozilla was pretty rough when it was first released.

In any case, it’s free, only about an hour long, and documents some important history of the web, so it’s worth a look.

Doctor Who game helps kids to learn to code

by Ben

Doctor Who game helps kids to learn to code (Wired UK).

The BBC has revealed its fiendish side — tricking kids into learning how to code with a free Doctor Who game. The Doctor and the Dalek is available now on Android, iOS, and Amazon app stores, and combines a platforming adventure with an introduction to Boolean logic-based programming.

How unfair that this is limited to residents of the UK.

Google announces SPDY’s coming demise as HTTP/2 approaches

by Ben

Google announces SPDY’s coming demise as HTTP/2 approaches | Ars Technica.
Chromium Blog: Hello HTTP/2, Goodbye SPDY

From the Ars article:

Today the company announced that it would soon be removing SPDY support from Chrome. That’s because the Internet Engineering Task Force (IETF) has been working to update HTTP to produce HTTP/2, an updated revision of a protocol that has not seen any major changes since its introduction in the early 1990s. […] To reduce latency, it included support for multiplexing—making multiple requests and responses over a single connection, with prioritization for different requests—and for security, it makes the use of TLS compulsory.

Multiplexing and compression just make sense… but compulsory TLS? That’s quite a hurdle for the entire web to jump over. I’ve seen some arguments that there might be free certificates, but I wonder how that would be managed. Without having read much of the working draft, a natural question is how potential vulnerabilities in TLS would be handled over the next 15 years, especially considering recently discovered issues in SSL (POODLE, namely).

Regardless, I guess a server could always fall back to HTTP/1.1. It’s gotten us this far.