-
API-first & Native Apps for Start-ups
I have an Android, and that means that I’m typically the last to get the coolest new apps or to be able to use the latest IoT devices – because they all start with iOS first. It makes me wonder why many of these companies don’t start with a responsive web app first, and do native apps later – that way, they’ll be able to support all platforms out the gate. There are some obvious restrictions to web apps, like not having quite the same access to the platform’s hardware and not being able to easily pass wifi credentials to an external device: for example, if you buy a bridge or hub for your smart home system and it needs to connect to the wifi, as far as I know, the best user experience requires a native app so that your phone’s wifi settings can be passed seamlessly through the app to the device.1
-
API versioning doesn't matter
Let’s face it: you will at some point have to introduce breaking changes to your API. Most of us plan for this, and try to mitigate the consequences, by versioning. There are loads of ways people out there are versioning – introducing a new subversion with every minor change, bundling changes into major version releases, using content negotiation to manage different versions of resources, etc – and people bicker to no end about the best way to do this. But if one thing is becoming clear,1 it’s that the way you version your API doesn’t matter – the way you communicate does.
-
in pursuit of making SDKs suck less
This is a follow-up from a previous post on SDKs being crap. My points in that post still stand for the most part, because, well, most SDKs suck. But being in the business of designing and building APIs, I can’t escape them, and soon I’ll have to be building and maintaining them at notion. In other words, for me, the question is no longer why do I have to keep using SDKs that suck,1 but how do I make them not suck?
-
document early, document more
Recently at work, we were discussing risk management for start-ups — specifically, for our start-up. When each of us laid out what we saw as our risks on the whiteboard, a couple things became apparent. First, there were a ton of risks. What if one of our supply-chain partners had to delay? What if a tool we decided on at an earlier stage got too expensive, or turned out not to be the right one? What about all the extra hands we were foreseeing we would need — in marketing, customer service, engineering? What if — knock on wood — one of us got hit by a bus?
-
APIs for IoT
A couple weeks ago I wrote a post on Notion’s blog aboutAPIs for the Internet of Things – specifically, three major points I’m thinking about a lot as we design the API, iterate on it,and plan for scaling.
-
new groove
A lot has changed between my last post and now. The most obvious thing is that I’ve got a new look for this site. This past week I finally sat down and made the move to a Jekyll blog hosted on github pages. Really unoriginal for a developer, I know. But I had tried a more unique route – using Middleman and hosting on Bluehost with some extra hosting credit I had leftover from a previous start-up venture. It was awful. I mean, I’m sure I could’ve figured out how to get some semi-automatic deployment going on with FTP or something, but who’s got time for that? It was such a hassle just getting a blog post up and running that I dreaded the thought – and, as a result, stopped posting.
-
SDKs suck, so why do they exist?
This past weekend, I was innocently attending RESTFest in Greenville, SC, along with some of the biggest API geeks and fanatics I’ve ever met.1 Things were going smoothly — people were arguing about The One HyperMedia Type To Rule Them All, some devs from Apigee did demos of their new ZettaJS with LEDs and arduinos, and “state machines” kept gaining momentum as the conference’s actual topic (um, move aside HTTP RFCs) — when someone innocuously mentioned in their talk a truth that I had yet to admit to myself: SDKs suck.
-
intentional programming
I have a confession to make. I never typed “rails g scaffold” until I taught a RubyOnRails course.1 I knew what scaffolding was, of course, but it had never occurred to me to use it. I didn’t generate models or controllers either. This probably has a lot to do with the project I really learned Rails from — a large, already existing app that had no place for generating full scaffolds for any resource.
-
preparing for ruby
I've been getting some emails from students asking how they can prepare for my Ruby class starting in three weeks (three weeks?!), and it's definitely time to start talking about pre-work. It's an interesting topic because yes, it'd be ideal if every student came into the class with a strong foundation, but on the other hand, what pre-work will provide a solid preparation without being way over newbies' heads and without giving them the wrong ideas about the “right” ways to do things?
-
front-end or back-end? not that i'm biased or anything...
I recently had an email from someone I'll be teaching at The Iron Yard in Atlanta who was interested in the difference between the Front-end Engineering course and the RubyOnRails course and which might be more suitable for him. He admitted he's more inclined towards UX1 and also plans to build his own applications from the ground-up. I was really stoked to talk about it because the decision between Rails and front-end is something that comes up a lot, especially with all the hot JS frameworks that help facilitate more completely javascript applications. Here's a slightly modified version of what I came up with and wrote back to him:
-
how my "impractical" humanities degree prepared me for a career in programming
When I tell people what I do, and then answer the inevitable “What was your major in college?” I'm usually faced with exclamations of surprise, bewilderment, or just plain confusion.1 My answer to the latter question usually garners some semblance of that response anyway, even though I always thought that Anglo-Saxon, Norse and Celtic was a totally normal university course that anyone in their right mind would elect to take.2 But what most people can't seem to piece together is how I went from a degree where I learned medieval Welsh, recited Latin and Irish poetry,3 and studied Anglo-Saxon kings,4 to a career that seems so deeply rooted in modern technological culture: programming.