Adam Keys is Thinking

Microservices? I’m not entirely sure what they are. The term seems to exist on all parts of the hype cycle simultaneously. It’s on the ascent of excitement, the descent of disillusionment, and the plateau of productivity for different people, simultaneously. Some folks know exactly what it means, others know entirely nothing about what it means. Weirdness ensues. People talk past each other.

It’s a mess. Grumpy old man mode is in full force. (FWIW, I am the grumpy old man in this metaphor. I can not speak to the stature of Fowler or Feathers at this time.)

If I’m pessimistic, I nod along with Michael Feathers. He’s on to something when he observes the use of microservices as a blunt weapon against failures of encapsulation. Microservices become SOLID principles using units of deployment and even teams as a barrier between concerns. I feel that’s rather draconian.

If I’m optimistic, I cite Martin Fowler. To his credit, Fowler is doing the best work sifting through the noise and sensibly organizing what microservices might, in fact, be about. They’re probably not distributed objects, if you do it right. But you should understand the details, lest you get swallowed by the novelty and forget to realize the benefits. Make sure you’re tall enough for the ride your operations team is about to endure.

I get the feeling that radical approaches to working with Rails and microservices are tilting at the same windmill. You won’t fix the human tendency to build complicated structures with more software. Employing more buckets, or smaller buckets, in which to put your software doesn’t solve it either. You need a human factor to jump in and say “Hey, this is complicated! It might even be essentially complex. Let’s manage that complexity.” If you’re actively managing complexity, microservices or monoliths, Rails way or your own way, microservices and decoupling are a lot more of a detail than a foundational principle.

I see lots of “should designers code?” articles and introductions to coding for designers. I see far less interest in the converse. So what’s a designer think? Cap Watkins, a designer; Should Engineers Design?:

If you think design is 100% about creating “design artifacts”, I’d say your scope is too narrow and has the potential to stunt your personal and professional growth.

There’s so much to designing that isn’t about choosing colors, fonts, producing icons, or drawing. Developers can, and should, get involved in how the applications works, how copy guides the user through workflows, when to prompt about invalid data and when to fix it automatically, and how to help users through interactions. That’s design!

To wit:

Throughout my entire career I’ve had engineering partners deep in the design process with me. I show them sketches, bounce ideas off of them, have whiteboarding sessions to figure out what we’re going to do. I trust engineers I work with to let me know when something seems confusing, when there’s an edge case I haven’t thought of and to push on my ideas to find where they break and help me make them even better.

Developers often don’t even realize they’re designing when they’re building libraries and tools for other developers. Writing a good README so developers know why your project is awesome and how to use it? That’s design. Sweating the details of an OO or REST API? That’s design. Opting to remove a feature or solve two problems with one feature? That’s design!

The design was in us the whole time, and we didn’t even know it!

I leave you with this excellent wisdom:

When you look at design as a process and not an artifact, everyone on your team becomes a designer. We have different areas of expertise and skill, no doubt, but the product experience belongs to every member of the team. The more familiar you are with each other’s responsibilities, the more you’re able to participate with and help each other out when needed.

Here’s a fun thing I do that you should try: when you read articles about design, squint a little bit and pretend it’s about designing programs. You might find something you want to try the next time you sit down to work on some code.

Is Rails well positioned for where the web (on all devices) is going? Pal Dave Copeland asked that on Twitter. Turns out I had plenty of opinions!

• I buy into the notion that the majority of applications don’t need much special in the way of browser-side functionality. SJR, a little bit of CoffeeScript, and SCSS will do you fine.
• For the rare team building ambitious applications, an opinionated framework like Rails is probably the last thing you want. Ambitious applications, perhaps by definition, are going to cut against the grain in one or more places. An opinionated framework is only going to get in the way of the opinions that make the application ambitious in the first place.
• The web is in a weird place. I think it’s a somewhat risky environment to build for browsers right now. The combinatorial explosion of devices and browsers means that you’re almost certainly giving some non-trivial class of user a suboptimal or buggy experience. Choosing where to spend your effort seems like a non-fun process.
• There isn’t a high-quality, well supported, well conceived ecosystem that currently exists for browsers. Rails and iOS both succeeded with a combination of smart conception, (mostly) excellent execution, and supportive communities or vendors. Front-end technologies are deeply splintered right now.
• I suspect there’s no opportunity for Rails to crown a winner in this space until the Cambrian explosion of JavaScript and CSS practice coalesce into something coherent that most developers can relate to and execute.
• But, if I had to wager, my money is on Rails choosing Ember as a default choice. This would happen on the trailing edge of fashion though, in the same way that jQuery didn’t become the default for Rails until long after jQuery became the go-to choice for most front-end developers.
• Even if the Rails core team could pick a winner on the leading edge of fashion, I don’t think it would work out. The Rails core team has much less experience with the front-end than the back-end. Historically, the choices have been OK (CoffeeScript turned out well, Prototype+Scriptaculous was an excellent early choice) with a recent trend towards provoking wild disagreement (e.g. CoffeeScript and Turbolinks).
• I think a lot of this comes down to Sprockets’ ability to gracefully grow to support front-end practice. It already does a pretty good job. Adding better support for browser components (e.g. Bower) would be good, as well as keeping up with SVG, web fonts and other somewhat special asset types.

If, tomorrow, I did have to build a Rails app whose web experience was crucial, I’d be as conservative as possible with my library choices. I’d stick with the oldest, boring-est, best-tested JS and CSS tools until it wasn’t feasible anymore.

I’ve been programming, as a full-time job, for more than ten years. I started doing Ruby, and Rails, nearly ten years ago. I’ve been at LivingSocial for a two and a half years now. If you add these numbers up you will find that I am, improbably, an old hand.

As I try to explain and contextualize our organization, technology, and culture inside LivingSocial, I often catch myself delicately dancing around saying “it’s always been this way”. It sucks to hear this. It’s easy for this to sound like a deflection. “Don’t worry yourself, just accept it and let me get back to whatever I was doing before you asked that foolish question.” Crawl back to your desk and grind away.

Beginner’s mind is crucial and fleeting, so every person new to our communities and teams are invaluable. I want to extract as much information about how we’re confusing or mired in our legacy of stupidity. A beginner’s mind can help us improve our organizations, but only when it’s open and the experts aren’t marked as institutional damage to route around instead of engage with.

So I’m explaining organizational history and I find myself hand waving around “it’s always been this way, bask in despair!” At this point I (try to) profusely apologize and restart my explanation or answer. I need to get at that beginner’s mind before it becomes jaded in foregone conclusions.

But sometimes I don’t stop. I forget. I get wrapped up in accurately and concisely explaining how it got this way and why it’s this way. I forget to actually answer the question or suggest how it might be made better.

Allow me apologize to everyone out there on the internet. Sometimes it might seem like I’m saying “it’s always been this way”, but really I got so wrapped up in giving a vigorous history lesson that I lost my train of thought. It might help to restate the question. I’m an old hand, after all, with a frail brain.

I came up in the days when Microsoft and Linux were mortal enemies. Back when “Borg Bill Gates” was the icon for stories about MS on Slashdot. Back when Slashdot was the cutting edge.

Thus, I’m always slightly surprised when I come across some really solid work done by Microsoft. The people at Microsoft are capable of really great work, but it often doesn’t escape The System in place between the hands on keyboards and the public face of the company.

Microsoft Research, in particular, produces surprisingly good research papers. The recent paper on Orleans is a great example.

Orleans is an opinionated “virutalized” actor framework MS developed that runs on their .NET and Azure frameworks:

• The design is single-threaded, small timemeslices, no preemption; not unlike Go’s goroutines (when considered on only one host)
• Orleans has its own runtime for activating, deactivating, locating, and dispatching to actors
• Semantics end up looking like a combination of queue-workers, actors, and Promise-based systems

Implementing Orleans instead of a three-tier (web, app, DB) system allowed them to eliminate the need for a caching layer once they reached scale. Actors encapsulate state and caching thereof instead.

• Virtualized actors become analogous to virtual memory, raising the level of abstraction programmers can work at
• Virtualized actors don’t require management by operators or developers; failure and load-balancing behavior is managed by the runtime instead of prior specification
• Currently implements at-least-once message semantics, which works for developers; considering added only-once message delivery

Orleans is currently in use in the Halo 4 presence and statistics services. I bet you’ll see clones and shallow carbon copies of these ideas in a language or conference near you. Read the paper, it’s quite accessible as distributed systems papers go. There are some nice ideas in there.

Ed. Let me know if you like reading notes on papers I’ve read. I’d like to do it more often if folks find it useful.

RailsConf 2014 having wrapped up a few weeks ago, now seems like a good time to try and unpack what I saw, heard, and talked to others about. Bear in mind I skipped RailsConf 2013 (but I’ve been to all the others), so I may construe something as new that I simply missed last year.

I’m going to break it down, as is my puzzle-solving wont, by technology and people.

Technology

Lots of people are excited about a few central topics.

JavaScript. They want to build ambitious apps, with Ember, Lineman, and other tools. Developers seem somewhat concerned that building apps this way is swimming upstream. Or that it’s early days and things are changing quickly. Or they think it’s awesome to work in a growing field. It’s all of those things.

Service-oriented Architecture. I went to talks about extracting services, designing services, implementing authentication/authorization across services, and how to write the client side of your various services. The talks felt like they were past the “look at this novel thing!” phase and into the “well here’s the nitty gritty” phase. I didn’t happen upon any sessions of the “here’s how this thing punched me in the face!” sort, which is the kind of thing I, personally, want to learn about right now.

Getting outside of Rails. Beyond SOA, some folks are going off the golden path and finding some success. I attended one good talk on adopting ideas from Domain Driven Design and hexagonal architecture. I found Ernie Miller’s ideas about how he’s worked with Rails' flaws interesting, even though I often didn’t agree.

People

The conference started with David’s keynote throwing barbs at the attitude some people display towards TDD (an ambiguous acryonym to start with). Many speakers opened with, in my opinion vapid, jokes about this. Other people seemed to take personal offense that TDD might not be everything. These reactions were, I found, not particularly interesting. The more interesting ones were those who found it as a challenge to consider how they build applications, either through taste and intuition or through reasoning and engineering.

There’s always, at least in conversations I find myself in, some question of where Rails is now. Relative to other technologies, is it a leader, a follower, a player, a has-been? Every year, it’s more of a safe assumption that Rails is a given, that it’s not going to up and disappear. Still, there’s a desire to keep it fresh, avoid stagnation, and above all avoid becoming the demons (J2EE, .NET, PHP, etc.) that people used before Rails. A lot of this discussion seems to be happening around the size and frameworkness of Rails. There has always been pockets of interest around things that are smaller than Rails (like Sinatra, ROM, etc.) More interesting, there is some defense of largeness now, especially in the context of Ember. This is the most interesting, and at times tedious, debate, for me personally.

The attendance of RailsConf continues to grow more diverse. The inclusiveness efforts of the organizers and community at large seem to be bearing fruit. I saw more ladies and more minorities than I have at any conference of this size. Further, the crowd felt less startup-centric than years past. Plenty of folks from startups, sure, but also people at different kinds of businesses: small, big, hardware, software, commerce, marketing, non-profit, etc. What’s more, it was easier than ever to find myself in a conversation with people not entirely like myself. That’s a quite good thing.

Lots of people are concerned about Rails, its community, and such. There’s a vibe, not unlike 2008 or 2009 when some were seeking other ways to build Ruby web apps, that perhaps the framework, the community, and the leaders thereof don’t have all the answers. That may sound damning, but it’s a pretty healthy attitude. The problems developers face and the way we build our programs are, as ever, changing as we’re building them. The tension is out there, but having been through most of a technology hype cycle with Rails, I’m not worried that the community won’t find the resolution of that tension.

Conjecture: thinking about releasing software versions to users/partners/the public in dotted version numbers, e.g. “1.0, 2.1, 5.3” is a symptom of misshaped thinking. This line of thinking seems framed by the notion that only a dozen major versions will ever be released. Certainly, some software works that way: shrink-wrap software, video game consoles, etc.. Most notably, dotted release versions are very useful for software used to build software.

However, its increasingly true that software doesn’t really work until it reaches “version” two-hundred something. But maybe that’s another problematic frame of thinking…

Glenn Vanderburg on teaching developer how to use Ruby testing APIs:

For example: I hate it when APIs (or languages, or whatever) are presented as "it's just English!" That doesn't give anyone anything useful to work with; it's just trying to allay fears, and it replaces a mythical danger (the thing people are afraid of simply because it's unknown) with a real danger: you're telling them they don't need to learn anything, when in fact the opposite is true.

I’ve never liked English-like APIs either. Consider that AppleScript is, bizarrely, completely unusable by people who know how to program in any other programming language.

If you think unpack “It’s just English” a bit, it’s easy to see why you should run away screaming from anything describing itself as being English-like in a good way. English is a human language riddled with inconsistencies. Many, if not most, English speakers learned it when they were young and the brain is almost useless for anything that isn’t language acquisition. Those who have learned English later in life become literate through lots of work, a healthy dose of necessity, and probably several years where their English was good enough for humans to understand but utterly confusing to a computer.

Just say “false” to “It’s just English”, coders!

I’m currently jazzed by the idea of full stack writing:

Hi is what we call a “full stack” writing and publishing platform. Just what is a writing stack? Capture. Write. Publish. is our summary of it, but really it breaks down into five parts:

• Sudden inspiration!
• Capture
• Draft
• Publish
• Converse

Some platforms provide tools for parts of the stack. Hi gives you tools for the full stack.

All the pancakes.

Love the breakfast food metaphor! Hi’s tools and community integration seem pretty nifty. That said, the break down of inspire, capture, write, converse is what I can’t get out of my head. I don’t think you need special tools to approach it with that breakdown. WordPress, Jekyll, Medium, whatever. Always be writing, publish small ideas frequently (a thing I need to do more often!), develop the ideas that stick in your head or that lead to great conversations, repeat. Don’t let the layout of your blog template or the name of the tool limit your writing. It’s an easy mental trap to fall for!