Wednesday, October 29, 2014

The Curl Pipe

If anything deserves to be called an anti-pattern it is probably the common and worry-inducing practice of documenting your installation process by asking asking users to copy and paste a line into their shell that will snag some file off the internet and pipe its contents directly into your shell to execute.

Sometimes this is even done as root.

This is something known to be awful, but which remains a cornerstone via its use by some of the most important tools in our belts. Homebrew does it. NPM does it, too. And some projects look better, but are they? Pip asks you to download get-pip.py and run it to install, which isn’t practically any different than piping from curl, just less efficient.

But worst of all, we might as well be doing this even more often, because our most depended about tooling is all just as guilty even without doing the curl pipe sh dance. What do you think happens when you pip install your favorite Python package, anyway? Pip downloads a file from the internet and executes it. Simple as that, for the purposes here. Sure, these days we have saner defaults. It has to be HTTPS and it has to be from PyPI by default, but its not like these packages are screened.

For all our concerns about security and frets over SHELLSHOCK and POODLE vulnerabilities, doesn’t it seem like the developer community does an awful lot of executing random files off the internet?

Wednesday, October 22, 2014

Dead To Me! DomNomNom

DomNomNom was a toy templating tool for front-end web applications I built during a long ride in the passenger seat. The idea was to build a templating system that required minimal, and in many cases, no template at all. I wanted to see if it was possible to map data directly into markup structures based purely on semantics.


For example, instead of some mark up that rendered a title into the page like {{ title }} we might just map the <h1> tag to the title in the data binding.


$(“body”).domnomnom({
“h1”: “This is the title”,
})


And it was really easy to get this basic setup in place quickly. I began to take it further. I allowed mapping lists of data, which would clone an element instead of simply inserting the text contents into it. Suddenly I could render tables and lists with ease.


“ul”: {
“li”: [“one”, “two”, “three”]
}


And the markup’s original <li> would function as a template to clone for this content. It was very clean to write templates for, because they were just mark-up with dummy data and content in them. This meant a designer could build the templates with whatever tools they wanted and the data could just get pumped into it.


DomNomNom in its final state supports mapping syntax that can handle attributes and properties, so you can map into form fields and the like. There are also controls capable of changing the order cloned elements are inserted and allowing the clone templates to be controlled better. If I removed the empty lines for formatting, the whole thing would come in under 100 lines of Javascript.


I built this on jQuery, but if I re-did this based on modern browsers with querySelector it probably wouldn’t grow by more than a dozen lines, and would be a lot faster.

Check it out, if just to see.

Monday, October 20, 2014

The Problem with Coders' Technology Focus

Coders focus on code. Coders focus on toolchains and development practices. Coders focus on commits and line counts. Coders focus on code, but we don’t focus as well on people.

We need to take a step back and remember why we write code, or possibly re-evaluate why we write code. Many of us might be doing it for the wrong reasons. Maybe you don’t think there can be a wrong reason, and I’m not entirely sure. What I am certain of is that some reasons to code lend themselves to certain attitudes and weights about the code and other motivations might mandate that you take yourself more or less seriously.

We’re taking the wrong motivations seriously and we’re not giving enough attention and weight to the reasons for code that we should.

The most valid and important reason we can code is not what hackers think it is. A good hack isn’t good for its own sake. No programming language or tool is inherently better than another. The technical merits of the approach or of the individual are not the most important factors to consider.

Our impact on people is the only thing that truly matters.

Twitter isn’t great because they developed amazing distributed services internally to support the load requirements of their service, but because they connect millions of voices across the globe.

RSS isn’t great because it encapsulates content in an easily parseable format for client software to consume, but because it connects writers to the readers who care most about their thoughts and feelings and ideas.

The amazing rendering tools built in-house by the likes of Disney aren’t amazing because of their attention to physical based light simulations and the effort required to coordinate the massive render farms churning out frames for new big budget films, but for their ability to tell wonderful stories that touch people.

The next time you find yourself on a forum chastising someone for writing their website in PHP, pause and ask yourself why that was the more important question to ask them than “Does this fulfill something important to you or your users?”

When you are reviewing code and want to stop a merge because you disagree with a technical approach, take a step back and ask yourself if the changes have a positive impact on the people your product serves.

Every time you find yourself valuing the technical contributions of team mates and community members, make sure those contributions translate into enriching and fulfilling the lives of that community and your workplace, before the technical needs.

Nothing that is important can be so without being important for people first.

Sunday, October 19, 2014

Farewell to XMLHttpRequest; Long live window.fetch!

The days of XMLHttpRequest and weird choices for capitalization are numbered. WhatWG has a spec ready for some time now to replace it: window.fetch. Just look at how easy it is.



Just look at how nicer that is all with soon-to-be native APIs. But you don't have to wait, because there is a polyfill available. Start using the Fetch Polyfill in your projects today.

Thursday, October 16, 2014

I Want to Write More Often

I want to write more often. I’ve been writing more lately and I hope to continue that, and I think expressing why this is important to me is valuable so here is that post.

I want to explore my thoughts more concretely and have a record of how I came to my stands on the positions I believe in, and I want to keep track of the ideas for stories I have. Rather than have some bothering me constantly, I want to feel safe that I can forget things.

Writing ideas can also get them out of your mind. The act of writing about it can often free your mind from the burden of so many thoughts. You can be more confident in an idea, or let it go out of your mind now that you’ve written it somewhere safe and permanent.

I like the idea of turning my thoughts into essays. A thought is ill-defined. A thought is hard to grasp, even inside your own head. Thoughts are connections between so many points in your mind, but a well written essay is a single coherent position. It is a statement at a time and place that expresses a piece of yourself succinctly and I really appreciate that about writing.

Writing makes creative endeavours more accessible and helps keep my brain active and healthy. This practice of expressing thoughts in writing also gives you the practice in patterns of thinking that are better structured. The more of your thoughts find their way onto paper (literally or virtually) the easier they’ll come because your mind will learn to organize them better.

I’ve begun the practice of Morning Pages again after years of allowing the habit to lapse.

Morning Pages are three pages of longhand, stream of consciousness writing done first thing in the morning. *There is no wrong way to do Morning Pages*– they are not high art. They are not even “writing.” They are about anything and everything that crosses your mind– and they are for your eyes only. Morning Pages provoke, clarify, comfort, cajole, prioritize and synchronize the day at hand. Do not over-think Morning Pages: just put three pages of anything on the page…and then do three more pages tomorrow.

I use a version of morning pages called 750words.com which is a fantastic tool that helps you write every day by tracking your words (750 words is roughly three pages) and each month provides a challenge to fill every day with these words.

It has helped a lot. I start every day writing between 750 and 1000 words with as little pausing as I can. In this time I get lots of stressful and worried thoughts out of my mind, or get a chance to think harder about them and settle on decisions that have been bothering me. I begin each day by clearing from my head many of the distractions that would keep me from the things I enjoy and the things I need to focus on.

My work and my happiness have both improved as a result, I believe. I find myself focusing on work easier and I find myself able to enjoy my relaxing and hobby times, as well.

What is most interesting, perhaps, is how much more I have written in this same time. On top of writing every morning, I find myself feeling drawn every day to sit down and write even more and I do. I’ve written, roughly, 20,000 words in the last two weeks. And other creative interests have become easier, as well. I’ve been drawing and (digitally) painting more for the first time in years, and I cannot express how happy that makes me.

monsters.jpgmonsters_jpg___166___color_fill_4_copy__layer_mask_8___-copy.png

I hope that I do not let up on these changes any time soon.

Top Articles

Along the side of my blog, for many years. I've had a section called "Top Articles". I don't remember when I put it there, but I know that it included all of the most popular posts I had written at the time and I wanted to make them more prominent. They were obviously popular topics people wanted to find. These were the things I was writing about that people found most interesting or useful.

I haven't thought a lot about this list for a few years, until I just noticed it today. Top Articles is a time capsule. This was a snapshot of my interests and knowledge from a previous version of myself. It doesn't reflect me as well today. I'm equally interested in the things that no longer worth keeping on that list as I am of the things that are still very important to me.

I'll make a point to clean things up around here. What was on that list so long ago?


Of no surprise, I had a number of posts about Python which still draw a lot of new readers to this day.

And at that time I was spending a lot of time helping people on programming forums, especially IRC. I tried to help explain how people can better reach out for the help they need.

I was also starting to focus a little more broadly on how people learn to code and what we can do better.


I was starting to write less about programming itself and more about managing the world of building projects. My focus was also starting to broaden from just syntax and code to what we're delivering to the user and what they're going to do with it. Signs of the holistic approach to building software that I try to take these days already forming so long ago.


This blog was started in January of 2007. That's over seven and a half years ago, nearly as old as my son, who is a third grader. I'm sure the focus and breadth of my writing has changed since then, as have my opinions and focus. I'm sure over the next seven years they'll continue to do so, and I hope over that time I'll continue to write about it all.

Firefox Users on Linux Deserve Better Downloads

If you download Firefox on a linux machine today what you get from their servers is a pretty unfriendly tarball. What are you supposed to do with this? Maybe you know how to extract a tarball. Maybe you even know what of the many files inside it you're actually supposed to run and how to run it? Maybe.

But does everyone else? Do non-developer users have any clue what they're doing with this thing? They experience is awful.

I want to see that change and followed a ticket that tracks just that. What do you think?

Wednesday, October 15, 2014

Dead to Me! Trapdoor, Prototyping web-based desktop applications

This is the inaugural post in my Dead to Me! series which I announced.

I’m not gonna lie. I’m pretty proud of this one. To say Trapdoor was ahead of the times might be a stretch, but really only a small stretch.


My project README explains


Trapdoor is a web-based desktop framework. Confused yet? The idea is to leverage how much energy is put into the web today and make developing a desktop application fun again. Again? For the first time?


Trapdoor was an exploration of how to utilize web development skillsets to build desktop tools. I wanted to experiment with how this idea would play out and if it really made any sense. I was never planning Trapdoor to become are solution. I just wanted to play with the idea, but I do think I played with the idea pretty early on and that it was an extremely successful experiment.


At the time I was still a KDE user and had been learning a little bit of Qt via the Python bindings PyQt4. I knew that Qt had a WebKit widget and quickly found that PyQt4 exposed this pretty easily.





This was a simple demo I built with Trapdoor. We have a web-app built, for this simple example, all in Javascript dumping a few simple controls to the DOM. The JS is responsible for window creation and gets access to the DOM in the new window, where it can construct an interface in HTML and use jQuery to wire it up.


What I was most proud of is that, recognizing this would only be useful if the desktop applications being built could do anything a normal desktop app could do, I made it really easy to extend the Javascript APIs with new things.


The Calculator class defined in the above calculator.py file above and registered in the manifest is able to expose methods to the Javascript API it injects into the application. Otherwise, it is just regular everyday Python and can do anything and can use any Python libraries.


I only worked on Trapdoor for three days. Vaguely I recall wondering if I could write an extension that used PyOpenGL to render 3D graphics in my web-based desktop application, a good year before the WebGL spec landed and three and a half years before work would begin on Node Webkit. Trapdoor won’t be worked on by me and shouldn’t be picked up by anyone else, probably. It will continue to sit in my Github for a while, but it stay forever among my favorite personal projects.

Check it out, if you’re curious.

Dead to Me!

Dead to Me! is a new thing I’m doing. This is not a new blog, but it is a specific series of posts within this blog. Dead to Me! is about those projects which I am only looking back on, but will not work on again. These aren’t all failed experiments, but some of them are. In each post I’ll talk about a project I’ve abandoned, sunsetted, or moved on from. Some of them will be recent and others will be things I worked on years ago. Some of them might be related to work, but most will be personal.


I’m also doing something different with this. I don’t know how well this part will work out, but I’ve already gotten some interest in it so we’ll see:


I am soliciting for guest posts to Dead to Me! and welcome anyone who would like to ask to be a part of this. If you have a project you’re no longer working on and would like to write a postmortem for, please drop me a line or a draft.


If you’d like your post to appear here, go ahead and post it on your own blog or anywhere else, as well. Perhaps we can cross-link them.

I think this will be fun. Will you join me?

You can read the first post of the Dead to Me! series right now, about Trapdoor, a prototype platform for web-based desktop application development.

On Atheism Plus

This was originally published on That Liberal Extremist, a blog on social and political issues I began with my wife Heather.

"Atheism Plus" has been making rounds for a while now.

The basic premise seems to be Atheism, plus a lot of social justice movement elements. And, completely, I support that. And I'm glad for the wide support from others I see from that. We should support women in the Atheist community, and gays and bisexuals and the transgendered among us. And those outside of us, who are still marginalized even by religions they're a part of. We should support people of color, and the poor, and immigrants and single mothers more. Intersectionality is the word.

I came across this idea first from Greta Christina's post

But, I don't think we need a label for this. That doesn't mean there isn't a reason for it, and maybe I should phrase it "I don't think we should need it.", so let me explain.

...the rest of the post continues at That Liberal Extremist. Please subscribe if that's the kind of writing from me you're interested in.

Monday, October 13, 2014

Alternate Computer Science History

I'm basically putting a giant sign on me by even saying this in public, but for a while now I've been sketching notes on the side for a series of writing I call Alternate Computer Science History. The idea is to envision alternate histories for how we may have developed computers over the years, both in how those differences would have played out in the past and the impact it would have on what we've built on top of all these things since then.

What makes this so fascinating? Legacy. Computers are so steeped in legacy to such a remarkable degree, but they're still so young. What kind of boxes are we putting ourselves in? So I find it fun to explore what could have been different. What we have today, built on so many layers built up over the decades, is really nothing short of accidental. We could have ended up with a lot of other paths these developments could have taken over the years... couldn't we have?

So maybe I'll just keep these private, or maybe I'll publish some of it if I ever polish any bits of it in an interesting format. Have any thoughts? Do you think this sounds fun? Let me know.

Hexel Art: Brain Pulse

I've been playing with "hexels" and doing some <canvas> art this evening.


CARDIAC: The Cardboard Computer

I am just so excited about this.


CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 

One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only register was an accumulator.

The simple instruction set would have made for a very easy understanding of how complex programs are able to be built out of simpler sets of operations and data.

Opcode Mnemonic Operation
0INPRead a card into memory
1CLAClear accumulator and add from memory (load)
2ADDAdd from memory to accumulator
3TACTest accumulator and jump if negative
4SFTShift accumulator
5OUTWrite memory location to output card
6STOStore accumulator to memory
7SUBSubtract memory from accumulator
8JMPJump and save PC
9HRSHalt and reset

There is a much longer write up that anyone interested in the beginnings of computers should take a read over. I am hoping to make up my own DIY CARDIAC and try writing some fun programs and if I do I'm going to be sure to post about it.

Caktus Ship It! Day 2014 Q3 Post-Mortem - Part 2: Playlists and Peers

As of my first hour playing around I was able to share and synchronize play of any MP3 between multiple users with a simple drag and drop interface. Things were going pretty well for my project, but I had some work to do getting from there to the collaborative playlist I had in mind.

I was already just assuming we were only caring about one file, because that worked well to get things up and running fast. My next step was to remove that assumption and start keeping a list of songs. This was pretty easy, in fact. I started writing a simple list of songs as they were downloaded, each with a play button which performed the <audio> tag set and play that previously done automatically. Each user could now play any song that was shared and to restore the previous synchronized playing that happened when they only dealt with a single done I incorporated broadcast changeTrack messages. I added two other broadcasts, pause and play, which would allow any users to pause and play the songs on all users simultaneously.

This was working well, and I had roughly scaled my previous prototype to a multi-song version. Unfortunately, this version was even more rough and bug-ridden than the first. Most importantly among its faults: I couldn't really predict the order different clients would receive each track, so the playlists wouldn't remain in the same order for everyone. I wasn't really ready to tackle the actual collaborative playlist problem. This is probably the most difficult problem the project will face. It is a lot harder because I'm determined to keep the entire thing peer-controlled with no central decided or coordinator.

After banging my head on the simplest way I could provide this editing for the initial version, but coming up short, I realized it was a waste of my time. I didn't really need to do collaborative editing for a prototype, I just needed to make sure they all kept the same order.

So I alphabetized the songs for all users.

The simplest solution to some problems is not to have them

At this stage I could play any song on the shared playlist and hear it on any connected machine. Things continued nicely.

Implementing playlist progression was pretty easier. Along with progression I added highlights on the list to show which song was currently being played.

I decided at this point to do a bit more seriously testing and increased my test set of songs I was drag and dropping from 3 to 8.

I crashed Chrome. How I did that and how much of this work I had to completely throw out the window? Read Part 3 (Coming Soon) to find out.

Part 1: Proof of Concept in Under an Hour

Part 2: Playlists and Reseeding Songs

Part 3: Two Steps Back and Three Steps Forward

Growing Up With Your Long Lost Brother

I grew up with my long lost brother, but that fact does not make the label any less true. I don't know much about him. There are people I worked with at short retail jobs in my teens who I got to know better than I ever knew my little brother. There was not a drifting apart and there was not any kind of animosity that kept us apart from the start. I care for my brother and love my brother like anyone would.

But I do not know my brother.

If you think it is disingenuous of me to call him a "long lost brother" when we grew up together and I remember him smiling from his crib, please understand. If a man reached my age of thirty and only then learned they had a brother they had never met, never spoken with, never heard of before they would know that brother better than I know mine. They would know at least that he, too, had a long lost brother.

It is not accurate to say that I miss my brother, because you cannot really miss those who you don't know. I missed by brother, the way you miss a fly ball.

Death by Drawing

A while back I joined the effort of my friend Russell Hay to draw more often by way of a blog dedicated just to posting our drawings. I'll be honest and say we haven't made the best habits so far. I'm not giving up, so when I draw it will be posted there. Every now and then I'll post a few things here, just to remind you that I do that.

Tonight I draw a bunch of monsters! Enjoy.


Friday, October 10, 2014

Caktus Ship It! Day 2014 Q3 Post-Mortem - Part 1: Proof of Concept in Under an Hour

Today was one of our very fun Ship It! Day events at Caktus Group and the first in our new office. It snuck up on a lot of us, what with the busy move we're still settling down from, but it also is a great chance to unwind and to really enjoy our new shared workspace.

I'm going to start ending these events with a personal post-mortem on what I worked on. I decided to learn about WebRTC by building a tool I'd love to have with friends: a shared music player. The problem is simple: some of us think the room is to quiet and some of us like quiet. What we need is a way to play music together with headphones.

The goal was a simple app that can play MP3s. Everyone with the app open should be able to play songs and everyone connected would listen at the same time. We all hear the same thing. If someone leaves, they'll take their music with them.

So, I set about this yesterday afternoon (when our Ship It festivities officially begin) and I had a vague idea where I wanted to start. I had seen an interesting proof-of-concept called instant.io which provided file sharing in the browser. What made it novel from other demos was its use of BitTorrent as the sharing mechanism, so it could be used to effectively distribute a large file to a large number of recipients efficiently!

My starting theory was
BitTorrent combined with Winamp, in your Browser
So I set on this task by cloning the instant.io repository and running it locally, which was a little more trouble than I expected. The actual setup of the project was pretty odd, and depended on things specific to the owners machine. What I did learn from instant.io was to find my way to the WebTorrent project, on top of which instant.io was built.

I cleaned up the repository I had cloned to run a bit easier on my machine and started pulling examples from the WebTorrent website. I quickly got the file sharing working locally, dropping files onto one browser and seeing download links appear in the second.

So far, so good!

The next step was rudimentary music playing. I dropped a simple HTML5 audio tag into the page
<audio controls />
And took a look at where the instant.io code was rendering its download links after completing the transfer of a file from one peer to the next. It was easy enough to find where it looped through the files of a completed torrent and wrote the links into the page.

torrent.files.forEach(function (file) {
    file.createReadStream().pipe(concat(function (buf) {
      var a = document.createElement('a')
      a.download = file.name
      a.href = URL.createObjectURL(new Blob([ buf ]))
      a.textContent = 'download ' + file.name
      log.innerHTML += a.outerHTML + '
    }))
  })

A torrent can contain multiple files, and that was a fact that I had neglected, but for the current testing I just assumed that I'm only dropping one file at a time and I just take the first file in the torrent. It was very easy to assign the Data URI being generated here to the audio tag and trigger playback.
  var file = torrent.files[0]
  file.createReadStream().pipe(concat(function (buf) {
    var a = document.querySelector('audio')
    a.src = URL.createObjectURL(new Blob([ buf ]))
    a.play()
  }))

Success! I had, in less than an hour, built a simple tool that lets a bunch of people drop any MP3 into their browser window and all be listening to the same song in just a few seconds. It worked great, but I had a lot of work ahead of me.


Part 1: Proof of Concept in Under an Hour

Part 2: Playlists and Reseeding Songs

Part 3: Two Steps Back and Three Steps Forward

Thursday, October 09, 2014

The Flying Fish: Learning to Balance Passions

I'm not a fish flopping around on the boat, struggling to pull through my gills water that isn't there. That's the image Jon Morrow would have you imagine for people like myself: writers who don't get to write. In his very poignant piece, Morrow talks about the nightmares and pain stuck in a life he didn’t really enjoy, until he let go and gave himself to wordcraft.


I think anyone with a passion they’ve stifled can sympathize, but I don’t agree with his conclusions of advice to writers-who-could.


Contrasted to Morrow’s do-or-die struggles and deep dive to arguable save his life, I’m reminded of the always articulate Matt Gemmell’s announcement at the start of 2014 that he would be shifting to writing full-time and no longer continuing his successful programming career or his seven year self-employed stint in the Apple universe.


Look at the different ways these two writers describe their life away from writing.


My subconscious was trying to warn me that I was suffocating, just like a fish.


and


all fell by the wayside when I became really interested in programming


There is an frantic nature to Morrow’s history before going at writing full-time that contrasts immensely to the gradual realizations Gemmell reveals. But beyond this, the difference I notice most is a projection that screams from Morrow and is completely absent from Gemmell.


Jon Morrow doesn’t write about his own realizations of purpose except as a backdrop addressing “Writers struggling to find their courage”. I find this characterization presumptuous and quite possibly reaching. Maybe he needs to share this feeling of imprisonment with others, so that a shared appreciation of escape can be had?


Instead, I find myself connecting far more with Gemmell’s position and path. That isn’t to say that I’m not going to code anymore, or that I’m turning my life into something new and becoming a writer first and foremost. Just the opposite, in fact. It is not Gemmell’s decision to leave programming and write full-time that I relate to, but the casual nature by which he seemed to come to it that I relate to.


Instead of the frantic fear I read from Morrow, in Gemmell I see someone who is not diving in head first, but is taking stock of his surroundings and just being honest about where he already is. I see someone who is able to bridge two different kinds of lives with a grace that is refreshing among advice that such change requires risks that many of us really can’t afford to take.


And that’s okay.


I am a firm believer that there is no inherent value in those kind of big risks being taken. They hold a position of esteem that, to me, just hides the problems that push people to this edge in the first place. (But this is for another discussion)


So I’m not here announcing some big life change, just a small one I’m observing. I’m writing more again, lately. I like that. I’ve been writing more every day, and I feel happier for it. I’m not letting it take over my life, and I’m happy for that, too. I don’t think I need to give up everything else I love to pursue writing more seriously. I’m a firm believer that dedicating your life to one pursuit, while often seen as noble and honorable, is a waste of potential.


The breadth and depth of a human life is perfectly sufficient for being passionate of many things.


The the flying fish that soars through both ocean and sky, there are many people who have deeply engaged lives filled with creativities beside their office jobs and they like their office job, too. There are people who write and publish and wonder when they’ll have time to paint, so they do that on the side. There are people who spend all day getting tired in labor intensive jobs and really genuinely enjoy them and come home and hack on open source.

I reject the falsehood that passion requires isolation.

Wednesday, October 08, 2014

The "Cost" of Diversity

We use the word “diversity” and when we use a word we are packing up some concept as a thing. We can put that thing on a shelf and analyze it, talk about it, and use it like a hammer when we find a nail. Diversity, in this way, is defined as something other than the natural order. That is the result of labelling something: we define it as something that needs pointed out as distinct from the normal assumptions. Not that it is positioned as bad but we conceptualize things as the normal every day we’re used to and then diversify as this extra step we can take.

Diversity is an added step.
Diversity is optional.
You should take this extra step, of course, but it isn’t inherent.
But, here is where I’m finding I might disagree with the way we use this language because...

Diversity is inherent.

We live in a world reaching seven billion people and we are nothing close to  homogenous. The human race is colorful and varied and constantly surprising. You will never meet every kind of person there is in this world, no matter how hard you try. You will never have the opportunity to work with every viewpoint and understand the vast possibilities of perspectives on life and love and work and happiness. The people of the world are more diverse than we can ever really conceptualize.

Yet, you look around you and the people you see are more likely than not more like you than different from you. In ways both conscious and non, ways both purposeful and accidental, we have crafted communities, towns, circles of friends, and entire civilizations to weed out the diversity inherent in our species. In the darkest of times we have eradicated it with a prejudice usually only reserved for disease and rodents.

If you look around yourself and see a lack of diversity, this is not normal. This is not the normal way humans exist. This was centuries and beyond of calculated and meaningful separation.

The next time you hear something, even yourself, contemplating the “cost of diversity” please take a step back and ask yourself first: what have we already paid to remove the diversity before me and is any cost to restore our spectrum even comparable?

Diversity does not cost. Diversity was the cost of our society. We have a debt to pay.

Tuesday, October 07, 2014

The Lessons of Vim

Full Disclosure: I’m no longer using Vim as my full-time editor. I’m giving Atom a shot, because I really do like the energy around it and every once and a while I like to mix things up. (I even became an Emacs user for a year, just to see what the other side looked like!)


I while back I really enjoyed reading Mike Kozlowski’s piece Why Atom Can’t Replace Vim, and I completely agree with the sentiment 100% (even considering the above disclosure!). Emacs is an editor I have enormous respect for, and not just for what it is but the heritage it serves as for so many editors to come after it.


Emacs’ big idea has been thoroughly learned — and how vi’s big idea hasn’t.


From TextMate to SublimeText to Atom, modern editors have all adopted the extensibility lesson so much to heart that it is, essentially, a part of the fabric of what it means to be a (decent) text editor. More or less, you’re either notepad or you’re extendable.


Thank you, Emacs, and all you stand for, for the influence you’ve had on for more developers’ editors than those who use your.


Emacs’ big idea was that it could be modified and extended cleanly.


But, it seems that while the balance between Emacs and Vim in their respective camps has remained steady, there is an obvious place where Emacs won out, even among those who don’t care about either.


Vi’s big idea hasn’t been nearly as influential.


And this is a hurtful truth to agree with, but truth it is. If you aren’t a Vim user, and even if you are, it might be hard to articulate exactly what that Big Idea really is. Mike sums it up nicely.


Vi is fundamentally built on command composability. It favors small, general-purpose commands that can be combined with objects to compose larger commands.


And he wraps up with a note about what is needed to really replace Vim, if any editor ever really will.


A new, shiny, modern editor could one-up Vim by fixing some (or hopefully all) of these issues. But before an editor can replace Vim, it needs to learn everything that 1976 has to teach — not just the lesson of Emacs, but also the lesson of vi.


The lesson I really took from this is something that isn’t entirely obvious at first, but grew out of absorbing this writing and letting it stew with other thoughts in my head about tools like LightTable and the research of Jonathan Edwards.


What I think will really take off is when we are able to reproduce the composable nature of Vim in a tool that is less bound to the limits of ASCII flat files. The composable nature of Vim is perfectly suited to working with scopes of code at levels that really only exist as rules of syntax, and would likely be better bound not in a text editor but an AST editor. I imagine tools that parse and export between source and AST, but never actually give you access to edit text directly. I imagine beyond that formats that serialize ASTs and are never intended for direct editing in tools other than AST editors that parse that binary format.

And I think we’re headed to places where this starts to creep into our world, and the lessons of Vim will be waiting. I am tempted to use the phrase “ahead of its time”, but I won’t. Not because i think it cliche or untrue, but because the more true framing is that it was we who were behind our time.
I write here about programming, how to program better, things I think are neat and are related to programming. I might write other things at my personal website.

I am happily employed by the excellent Caktus Group, located in beautiful and friendly Carrboro, NC, where I work with Python, Django, and Javascript.

Blog Archive