Estonian E-Residency and refactoring government

Estonian E-Residency and refactoring government

Marshall McLuhan once said “Our Age of Anxiety is, in great part, the result of trying to do today’s jobs with yesterday’s tools”. There’s not a lot of technology that we interact with on a day-to-day basis that’s stayed in continuous operation for 230 years. The faculties by which we interact, gather, and exchange ideas in social and professional realms have dramatically evolved in this span of time. Yet our system of government, at both philosophical and practical levels, largely has not.

Every day I work with teammates in Germany, New York, California and British Columbia. “Presence” means something quite different today than it has for much of human history. It is now a divided concept. We have physical presence, and we have a another notion of presence that has nothing at all to do with physical location – our virtual presence.

Optimizing for less code with UJS and data-behavior

UJS is a small javascript library that manages interactions with endpoints implementing SJR (Server-generated Javascript Responses), in addition to providing a few behaviors such as non-GET HTTP verbs for links, simple confirm UIs, and the disabling of elements with optional loading text while remote requests are processing. UJS and SJR are a fantastic solution for keeping a web application’s frontend code minimal, in an age where wild over-engineering in this area is increasingly the norm.

UJS behavior binding is declarative, and happens via data attributes (for instance you can use the attribute-value pair data-disable-with='Processing' to disable a submit button with the loading text “Processing” during a form POST).

For all that is great about UJS, one thing that it does not offer is any formal suggestion of a practice for introducing your own custom unobtrusive javascript behaviors to your application. For this we need to look beyond the library and to the broader developer community surrounding Rails and UJS.

Be proudest of your under-engineering
The Technics SL-1200 MKII turntable has had the same mechanically simple design for 37 years, yet its quality, performance and reliability are considered unmatched.

Be proudest of your under-engineering

I am an under-engineer-er. The default lens through which I approach problems is one that prioritizes Less Code.

Usually the highest-leverage additions to your app are not complex ones, though having already increased your complexity surface area for nebulous ends or a distant vision will quickly make them so.

I am a student of Martin Fowler’s First Law.

I am also a strong believer that the documentation of any mature framework you may lean on inevitably proves an order of magnitude more comprehensive and approachable than that which your team may draft for any home-grown framework.

Rails 5’s best feature is one you may not have noticed

Rails 5’s best feature is one you may not have noticed

I noticed something curious when I booted my first project atop Rails 5 in development mode: that when the development server was idling, the title bar on Terminal.app would read “fsevent_watch”.

Finishing Is Credibility

Finishing Is Credibility

One of the things I am most proud of, and that I am most surprised to find distinguishes me when I look around at other people in my professional circles, is how often I finish things. To me, finishing is credibility, and a person’s record not just of starting or working on projects, but of finishing them, should be a factor in the weight you give to their opinions or the degree of leadership you entrust them with.

On Boring Stacks

A good friend sent me Jason Kester’s article Happiness is a Boring Stack a few weeks ago. The friend knows me well and knew the words of the piece would resonate strongly. The piece is worth a read. Its essential point is that while Hacker News,  Medium, or certain of your colleagues may give you the impression that you have woefully mis-stepped if you aren’t building your application atop the latest and greatest JavaScript framework and containerization solution, from a perspective of pragmatism and quality of life this is often not at all the case:

Practice

I recently read Chad Fowler’s The Passionate Programmer, a book broadly concerned with finding fulfillment through work in software development. The book had an unexpectedly strong impact on me. Many of Fowler’s key points aligned uncannily with recent experiences and observations of my own. One section that leapt out in particular to me concerned practice.

Document-Centric Thinking

Document-Centric Thinking

Most websites are functionally and spiritually a collection of inter-linked documents. Gathering user input or generating portions of content that are unique to certain users does not itself change this. We have had faculties for both of these things for nearly as long as the HTML and the World Wide Web have existed, with the form element and server-scripting interfaces like CGI.

There is a certain zen and empowerment in approaching projects with this understanding, but it is becoming sadly fringe to do so these days.