Seven Steps

Martial Arts & Technology, oh my!

Choosing the Right Editor for You

Choosing the right editor

Intro: My editor history

Here are my “credentials”. You know, establishing why you should be reading this at all.

When it comes to editors, I’ve honestly fumbled around quite a bit in the past fifteen years or so. I had not encountered an editor until some dude taught my Comp Sci 6/9 class and straight-up went to the GNU webpage and downloaded emacs for Windows. That looked really badass. Unfortunately I had no idea how to use it, so I stuck to whatever C++ IDE I was using for my homework.

After college I worked in IT and played with a lot of Linux distributions. So I got familiar with SCiTe for writing scripts (starting with VBScript and eventually Ruby) and nano for editing config files on Linux VMs.

When I decided I wanted to try and write Real Programs (trademark pending), I tried Eclipse, which I found too unwieldy, Netbeans, which I liked, and then Rubymine, which was awesome.

When I did become a developer, I became quite good at Rubymine because many around me used it. I also decided to get quite good at Vim, because a few around me used it, and in late 2013 I decided to … Go full-circle and try emacs (though that was not how I thought of it at the time).

So, as you can see, I have been around the block, as they say. Let’s take a look at the three main players in my life as a developer, chronologically. There will be an honorable mention for Sublime Text at the end, since I have just started using it and it’s, like, the cool kid on the block.


I went from Netbeans to Rubymine because I was looking for IDEs that did completion. This was back when Rubymine was around version 2.0, and it has come a very long way since then. Rubymine works very well out of the box. The configuration is fairly well organized, and about 95% of the options are good out of the box. It has options for keymaps which are similar to other standard mappings, and extensive keyboard mappings. The keyboard mappings allow for good control of the editor without a mouse, which allows for quicker editing. There is an output window, and a pretty neat way of handling test result displays, which allows for a pretty good TDD cycle. There is good completion out of the box. The devs are responsive to bug reports and suggestions for improvements. It is also great for navigating code and refactoring.

Rubymine is a great tool for serious Ruby/Rails developers. It works fantastically well out-of-the-box, and you know what you’ll get on any machine on which you run it.


Vim is part of the Linux standard. You’ll find it in every Linux distribution. Well, some of them have vi, but if the machine has vi, you’re probably looking at a server, and you shouldnt be doing development there anyway. If you do that, you’re a bad person and you should feel bad. But I digress.

Vim is everywhere. It has extensive history, and is meant to be navigated with a keyboard. You can enable mouse interaction, but it is a bad idea. The keyboard bindings can be found in most terminal apps like more, less or tig. You can even see some of those in the Gmail and Facebook web interface. That’s how omnipresent they are.

Vim’s main power to you is in the thought process. It is a text editor, and it prides itself in being just that, therefore it took text editing to an extreme. Learning how to think the way Vim wants to work teaches you to start making abstraction of the letters and words you see and start considering things in terms of the modifications you want to make to the text. Vim had a rebirth a few years ago, and a host of plugins came out. As a result, it is very usable for development on many things, such as Ruby, Scala, Haskell, even Android development.

In my mind, Vim will remain the standard text editor. I would recommend everyone learn to use it and learn to use its text objects, even if you do not keep using it.


Emacs, like Vim, has a way of thinking about things. Unlike vim, though, it doesn’t really care about what’s in the buffer. Emacs has guidelines. These guidelines apply to any and everything that you can put in an emacs buffer. And you can put just about anything in an emacs buffer. Including a terminal, or random text, like output from your test suite. This is amazingly powerful. I don’t really ever have to leave emacs, so once I have the keybindings down, they’ll work all the time. Like Vim, emacs has plugins for many of the newer languages out there, so it is also a safe option for modern development.

For me, the power of Emacs lies in one’s ability to create one’s own workflow. This wasn’t possible for me until Vim had taught me some discipline.

Honorable mention: Sublime Text

Sublime Text is fairly easily configurable and has reasonable documentation. It has a package manager you can install, and a number of fairly good plugins. I haven’t figured out how to do a proper TDD workflow, so it doesn’t do much for me at the moment. It is however a super-easy starting point, since the keys will do basically what you expect them to do if all you’ve ever used before were other non-text-editor-ish software.

Configuring your editor: howto

This is worth an entirely different blog entry, but the short of it is, use the scientific method. Change the variables one at a time. That means only add one plugin at a time and try using it for a while. If you don’t like it, uninstall it. If you like it, keep it. Then wait until you have another need. And go back to square one.

The thick of the matter: the workflow

I’ve touched on workflow before. “Saving keystrokes” is a micro-optimization. The key here is examining the work you do, what steps you need, and how you want to do them.

I have friends who like Rubymine. Some who like Vim. Some who like Emacs. It doesn’t matter. As long as you get done what you need to get done effectively, and you’re using a tool that doesn’t get in your way. So, if you are following a strict TDD workflow for instance, you need to do the following:

  1. Write a failing test, presumably in a test file.
  2. Run the failing test, see the failure.
  3. Write some code to make the test pass, presumably in a proper source code file.
  4. Run the failing test, watch it pass.
  5. Refactor the code, which is the most nebulous of all the steps.

As long as you can do all these steps, you’ve got a TDD workflow. Did I mention you ought to be able to do this several times a minute? If you can go through these steps several times a minute, you’ve got a TDD workflow. So, examine your workflow. Ready, get set, go! If you don’t have such a workflow going (for whatever it is you do, doesn’t have to be TDD), my point of view is that it is your responsibility to do what you need to do to have the best workflow possible. As a side bonus, that actually is good practice for you too.

Being happy

This is the final reason to use an editor. It makes you happy. If you’re not happy, you should take steps to fix it. Maybe it means fixing a problem with a plugin, or maybe it means changing editors entirely.

Shu Ha Ri and Evolution of a Skill

Shu Ha Ri comes from the world of Japanese Noh theater, and has been since attached to the world of martial arts and Agile development. Roughly, “shu ha ri” means “learn / detach / transcend”. The link has some words about that meaning. I’d like to talk about my particular take on Shu Ha Ri, which came out of a parking-lot conversation with a martial arts teacher friend of mine:

  1. Shu. Do the damn technique.
  2. Ha. Vary the damn technique.
  3. Ri. You don’t need the damn technique.

And here is the slightly longer interpretation.

SHU: right foot in front, grab the left wrist from the front with the right hand. Study the particular wrist escape that has been taught in this situation. In Agile words: be rigorous about your Agile practice. Do it “dumbly” until you get good at it and everyone in your team is OK with it.

HA: grab some wrist in some way, and play with that wrist escape. Add footwork. See what works and what doesn’t. In Agile words, now’s the time to see when is a good time for standup, what should be said, how long the standup should take. Or maybe change the beginning of the iteration; or how you do story breakdown. Pick ONE variable, change it, and learn from what happened, whether it worked or it didn’t (“worked” is a variable term, at this point of your growth, you’ll know it well enough when you see it).

RI: It’s not about a wrist grab anymore, but about much more fundamental principles. Detached from the technique, or the labels of “wrist grab” and “wrist escape”, it simply becomes about the right movement producing the right result (“right” is a variable term, at this point of your growth, you’ll know it without seeing it). In Agile words, you understand why a standup is just one example of a practical application of the Agile principles, and you are able to create custom applications of the principle for your teams, so that they can be Agile in the way that works best for them.


You may notice that HA and RI seem just a little similar from the point of vagueness: you’ll know it when you see it. It takes a long time to work through HA, and the line between the two is fairly definite, but hard to find. So practice, practice, practice. Or rather, perfect practice, perfect practice, perfect practice. And check your ego at the door.

Learning and Fear

“Life is going to present to you a series of transformations. And the point of education should be to transform you. To teach you how to be transformed so you can ride the waves as they come. But today, the point of education is not education. It’s accreditation. The more accreditation you have, the more money you make. That’s the instrumental logic of neoliberalism. And this instrumental logic comes wrapped in an envelope of fear. And my Ivy League, my MIT students are the same. All I feel coming off of my students is fear. That if you slip up in school, if you get one bad grade, if you make one fucking mistake, the great train of wealth will leave you behind. And that’s the logic of accreditation. If you’re at Yale, you’re in the smartest 1% in the world. […] And the brightest students in the world are learning in fear. I feel it rolling off of you in waves. But you can’t learn when you’re afraid. You cannot be transformed when you are afraid.”
- Junot Diaz, from a recent speech at Yale
If you spend more than an hour with me in person, the chances of me mentioning Dune increase asymptotically. So it shouldn’t be any surprise that this quote brought to mind two quotes from Dune, and here they are.
Muad’Dib learned rapidly because his first training was in how to learn. And the first lesson of all was the basic trust that he could learn. It’s shocking to find how many people do not believe they can learn, and how many more believe learning to be difficult. Muad’Dib knew that every experience carries its lesson.
And the other one, well, I wrote a blog entry about..
I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.
    I hadn’t really thought of connecting these two before, even though to me they are some of the most important quotes in the entire work.
    It does make sense though. It takes a fundamental trust in oneself to learn, and when you are afraid, you are basically robbed of that fundamental trust. So if Junot is right, and he probably is, since he lives in the educational system, there is a deep flaw in the system which is in fact making it harder for students to learn.
    When a system grows, sometimes a madness creeps in. Like Terry Pratchett wrote, ”[a dangerous thought is that] while all important enterprises need careful organization, it is the organization that needs organizing, rather than the enterprise.” So, after a while, it’s less about the students learning and more about the grades, and then it’s more about making sure the teachers do their work. But how do you make sure teachers do work? Ah-ha! There’s a thought. Let’s organize THAT. And the students? Well, they’re in school, they’ll learn, right? And so it begins. Subtly. Insidiously.
    As students, resisting that pressure is very difficult, but if you can, if you’re able to put it out of your mind, if you’re able to recognize it and not let it crush you, then you can truly learn, truly get an education. Truly be transformed, as Junot puts it. And the result will always be a marvel.

The Litany Against Fear

So, the litany against fear goes like this:


I must not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration. I will face my fear. I will permit it to pass over me and through me. And when it has gone past I will turn the inner eye to see its path. Where the fear has gone there will be nothing. Only I will remain.


And here’s my attempt at an interpretation of its meaning.

I will not fear. Fear is the mind-killer. Fear is the little-death that brings total obliteration.

    While it is a natural thing to feel fear and be afraid, I will not give in to it and become the fear. Becoming the fear means to revert to the basest instincts that we have, usually fight-or-flight, and then one’s actions are only concerned with survival. There is none of the higher reasoning left. This can be expanded slightly by adding another quote from Dune, from the scene where Paul meets the Gom Jabbar. The Reverend Mother says,

“You’ve heard of animals chewing off a leg to escape a trap. There’s an animal kind of trick. A human would remain in the trap, endure the pain, feigning death that he might kill the trapper and remove a threat to his kind.”

    We’re talking, fundamentally, about a different level of perception. Your existence is not about yourself, it is about survival of your species.

I will face my fear. I will allow it to pass over me and through me.

I will accept that I am afraid. This means recognizing that emotions are a part of one’s self, and not refusing to acknowledge a single part of one’s identity. I will look to my fear with compassion and kindness, for it is a part of me. Looking to any part of me with less than compassion of kindness is much like hating myself, and that’s just not productive.
    I will allow my fear, as an emotion, to wash through my body and run its course, so that the hormonal and nervous systems in my body do not get overworked or damaged by unnatural resistance to a normal behavior. I will also allow the fear to talk to the brain, so I can communicate with the fear, examine where it came from and, if necessary, figure out why it came up, so that the origin may be extirpated if necessary.

And when the fear has gone, I will turn the inner eye on its path. Where it was, there will be nothing. Only I will remain.

Just like death, fear leaves a mark on the ego, on the self. A person can end up damaged, responding only to the behaviors implanted by the fear response, instead of responding to the actual situations with which they are faced. 
    Once the fear is done, and the situation is resolved, I will examine my self, and realize that my self is still there, and did not get damaged by the fear. I will realize that the fear, like the tide on the beach, came and went, and like the ocean, I am unmoved by the tide.
    Thus, I will reinforce the behavior, so that next time, this is even easier, because I have even more trust in how this works, until it becomes an automatic response.


This is a deep and powerful mantra, which hints at tremendous self-control and self-awareness. As always, the first step is awareness.

Ruby Is Alive and Well

I’m back from Rubyconf.

Some people say Ruby is dead. We can probably gloss over Zed Shaw’s famous rant, since it’s from roundabout 2007. My understanding is that the thought came about because of the many new trends in programming languages: first node, then Erlang’s comeback and the birth of Elixir. Evented programming, non-blocking IO, all the fancy buzzwords, and everyone craps on Ruby’s Global Interpreter Lock.

Given the talks at Rubyconf, Ruby is most likely not dead (and our internal rubylist has an ongoing recent conversation about this if you’re curious). There were talks on API design, on fault-tolerant data, on machine-learning, on parallel execution and concurrency, a talk on Raft (an algorithm to obtain consistency)…

Ruby’s ecosystem is certainly doing a lot of hard work to stay current. If you use Rubinius or JRuby, you can leverage a ridiculously powerful library called celluloid, plug in celluloid-io and use reel, a webserver based on celluloid-io. Here’s the quick blurb on celluloid-io: Celluloid::IO provides an event-driven IO system for building fast, scalable network applications that integrates directly with the Celluloid actor library, making it easy to combine both threaded and evented concepts. Celluloid::IO is ideal for servers which handle large numbers of mostly-idle connections, such as Websocket servers or chat/messaging systems.

Oh, and I haven’t mentioned the cherry on top of the cake yet! Opal is a ruby to javascript source-to-source compiler. It also has an implementation of the ruby corelib. It has come a REALLY long way. It passes a large amount of tests from the Ruby specs. You can write jquery with it. You can write CSS with it. In short, it is pretty close to making Ruby into the one-stop-shop for web apps: it allows you to create objects which are representations of what you see on the screen. No more do you have to separate your HTML from your CSS or your Javascript. Check out slide 339 of the Rubyconf presentation to see an example. And feel free to check out the entire presentation, there’s lots of goodies.

In short, Ruby’s doing pretty well.


What Sparring Is

Sparring is a playful and explorative interaction.

Sparring is an exercise, a drill. The Japanese use the word KUMITE – which basically means “grouped hands” or “pair hands”, “joined hands”, “hands together” (the Wikipedia article suggests “grappling hands”).

Sparring is a two-person free-form exercise wherein you get to examine scenarios involving combinations, footwork, distancing, rhythm, controlled power, and focus to improve yourself and your partner.

Combinations: you get to play first-hand with things you have learned and put them in an environment where there is no set response. You learn what the combination does and what it does not do. You get a feel for when to use it, when not to use it. You will also learn not to stop after a single strike. WOOHOO you got a strike in! So what? Get in another one and another one! Learn how to use feints and setups for your combinations.

Footwork: sliding along a line, stepping around. When to change your front foot, when not to. When to step, when not to. This is harder than it sounds when you only have a split-second to make the decision.

Distancing: You can draw two concentric circles around an immobile person, representing the reach of their arms and legs. You learn how far your strikes go depending on your stance, you learn when the opponent is entering your zone and when they’re dancing just outside of it. You learn where your partner’s zone is. You will learn to enter and leave the opponent’s zone, and when to do so.

Rhythm: people have a rhythm (let’s leave the no-rhythm stepping of the Fremen out of this for a second). Controlling the fight can be done by means of controlling this rhythm. Anything you do between those beats is either invisible or unavoidable to the person. Someone who is jumping up and down is most vulnerable right before they land. Someone who takes a step forward is vulnerable when they are transferring the weight to the foot if it’s still up in the air.

Power: sparring is not about power generation, because unless your partner is much better than you are, you’re eventually going to hurt your partner, and they’re not going to want to train with you again, which probably defeats the whole purpose, because when you run out of training partners, you’ve got no one to spar with. If both players have a solid understanding and agreement, then you CAN use power. I’ve been in a few very fun sparring matches like that, very exhilarating experiences where the speed and the power was way up. Because both of us were playing and exploring, and we had a clear agreement and understanding on the goal of the drill, it was fine. You can and should develop power – however, this is done with other drills.

Focus: Alright, so we are not going to use full power. We’re still going to throw quick and precise strikes and we’re still going to make solid contact. While we’re not doing point-sparring, we’re still sparring, and a solid strike counts as a strike that could have been much more powerful; in proper point sparring, that’s a point – not touching someone with your toe. So, you should always honor the strike as being a real strike if it had the proper focus/kime, etc. It’s of course OK to smack down a round-house that made contact weakly, because it would have just been a touch. That is part of the contract. ‘Contact’ does not mean ‘hit’ if it does not have focus.

Now, having said all this, full-contact sparring has all the same things, but they don’t limit the power. Full-contact, full-speed sparring is practiced in systems where significant body conditioning occurs. This is not a coincidence.

What Sparring Is Not

Sparring is not a fight. Sparring is not a competition. If you or your partner try to win, then the purpose of the drill is defeated.

If you consider sparring to be a practice fight, then all of a sudden it’s OK to hurt someone – because that’s what you’re practicing. Sure, it’s not knitting class, but sparring is not about hurting someone. And it’s not about winning.

Why are we wearing gloves? Headgear? A mouthpiece?  These aren’t excuses to hit someone harder. They are there to protect YOUR body, not the opponent’s. They are worn by both people because you are training something dangerous, in which mistakes happen. The Pavlovian response to putting on gloves should not be “Yeah! Time to waste something!”, it should be “Time to make sure I am fully alert.”

There are two excellent articles coming from the world of the Russian martial art called Systema. The first is called The Kickboxing Trap. It talks about the following three traps:

  1. Trying NOT to lose (which is not exactly trying to win, but equally dangerous and much more subtle)
  2. Trying to move faster than the opponent (in Systema, sparring is done at a slower speed)
  3. Having undefined goals (WHY are you sparring? Which aspect of your practice are you working on improving?)

You should go read it.

The second article is called Slow Sparring Game Of Russian Martial Arts. I will give an excerpt here to give you an idea of a particular and very effective method of sparring (I know this from experience). In the following excerpt, emphasis is mine.

The basic premise of the Slow Sparring Game (SSG) is to create an environment where all technical aspects of hand to hand combat can be explored in relative safety, while providing the body a chance to execute and cultivate true spontaneity. To facilitate this, the SSG must be viewed as a slow motion representation of combat.

Here are some things it talks about:

  1. Changing speed, whether speeding up or slowing down during the movement
  2. Changing trajectory, just because you can when you’re going slow
  3. The defender moving faster than the attacker

You should go read it.

How to get good at sparring

There’s no secret, no magic formula. You gotta spar. You have to spar while being fully alert and cognizant of all those things. What if you’ve learned to spar already, but what you really learned was how to beat down (or how to be afraid of the other person) ? Then you have to spend time being extra-aware, with partners who will be understanding, and you probably should slow down even more than you otherwise would, because I can guarantee you from experience that you’ll speed up, because you’ll get afraid or uncomfortable or angry or competitive. It happens. And it’s nothing to be ashamed about. People make mistakes. We all do. But you have to be in there with the intent of improving and helping your partner improve, with an open mind.

What if someone breaks the agreement?

This, for better or for worse, depends on the culture in your environment. If they break the agreement because they are trying to fix their habits, be patient, take breaks, talk to them. Be aware of when they get scared or uncomfortable and ease up on the pressure. If they break the agreement because they don’t believe in it, then I would say, don’t spar with them. Have them read this blog post and have a conversation with them about it. Send them to a Systema school for a little while so they learn that speed and power aren’t the main elements in a fight. Or, if you’re much better than they are, let them get frustrated and angry and beat themselves against the wall. Eventually they’ll get tired of fighting. Every once in a while, people meet a problem and they have to burn all their Yang before they realize that it’s easier to be Yin.

Other Valuable Information

Teacher-student relationships when sparring

Sparring can be a very effective teaching tool: you can give students the proper positive feedback for a good strike, and the proper feedback (or lack thereof) for an improper strike. You can teach them to find openings, to think in circles (or spheres), to recognize rhythm. And if you’re really good - you’ll do it without speaking. You can choose to interrupt the sparring regularly to examine the current situation at more leisure. Sometimes it’s necessary to slow things down.

Differences in experience levels

The more-experienced player should only ever answer with 80% of the power of the less-experienced player. The more-experienced player should not be punishing or otherwise bullying the lower-experienced player. There are further lessons to be learned there by the more-experienced player, which I will not discuss here, because it might be a spoiler, and some of this stuff you really should learn by doing.

What not to learn from watching high-experience players

Higher-experience people who are sparring together may seem to be ignoring such strikes, most likely because they’re working on other things, like the focus, the rhythm, the continuity of motion, etc., it does not mean it is OK to ignore these strikes. They are (or should be) acknowledging the strikes, storing the experience in memory to learn from it later, and continuing.


Sparring is, or should be, a very enjoyable activity. It is a time where you can learn much about yourself and about your opponent (cue Matrix reference - I was the only one laughing in the theater when this happened…). It is a time where you drop all pretenses, drop your ego, and just get to be, along with your partner. My best friends are my best sparring partners, and this is not a coincidence. Proper sparring requires a set of agreements between all parties, and tremendous mindfulness. Thankfully, the payoffs are huge. With proper sparring, you will grow intellectually and emotionally and, if that’s not enough for you, your martial skills will also improve Much can be learned during sparring. Usually after the fact. I can think of a handful of occasions where something happened and, during a pause, one of us said “Oh, that move came from kata X” or “I’ve been practicing Y and I had no idea what it was for - now I do!” So, to steal unashamedly from a great man… Understand? Good. Play!

Collapse this post

School Creed

In the dojo where I spent my formative years as a martial artist, there is a school creed. A quick search online has revealed that many schools have a similar creed. Every class says it as we begin, after bowing in, before calisthenics. I hear it and/or say it about three times per dojo night.

It’s a simple creed, and clearly not unique. Here’s what it says:

I intend to develop myself in a positive manner and avoid anything that would reduce my mental growth or physical health. I intend to develop self-discipline, in order to bring out the best in myself and others. I intend to use what I learn in class constructively and defensively, to help myself and others and never be abusive or offensive.  

Kids and adults alike learn this creed and repeat it, together. All are taught to pronounce it powerfully, in the manner of an assertion. In that way, it is very similar to the few sentences American children have to repeat in their schools at the beginning of each day, and which sickened me for how similar it was to unadulterated brainwashing. Speaking of which, this is a very interesting and potentially disturbing read on the reading materials in school, but I digress.

Why do we make people repeat these words? We sometimes ask kids if they know what some words in there mean, like self-discipline. But certainly we’re not teaching vocabulary to adults. So what’s the point?

Well, the point is practice. These sentences are to be pronounced not only as assertions, but mindfully, pronouncing your desire to grow in that direction. They are simple precepts:

  1. Always aim for the things in life that will allow you to grow, always avoid the things that will make you shrink. Trick: sometimes you have to shrink in order to grow. Are those decisions mistakes? Are they following this code?
  2. Always try to be the best you can be, always try to allow others around you to be the best they can be. Trick: can you do both at the same time? Do you sometimes have to not be the best you can be to prod people into being the best they can be?
  3. What you are learning martially is meant for good. Possibly along the path of the Life-Giving Sword, but not necessarily. Simple application: don’t get into bar fights. Trick application: everything you do must come from Love.


This is intentionally left a little vague. Find your own questions. I’ll answer.

Is Rails Dying?

More to the point, should Rails die?

Rails brought a lot of great things – it made it dumb easy to package an entire app together. It abstracted the complexity of the storage layer. It created an entire market. Things like Heroku, Railsonfire/codeship and other companies turned a profit by extending the benefits of Rails. And things like Capistrano were born.

Everything that can be automated should be automated.


This has brought great things. And people wrote more tests, and life was good. But then, Rails apps grew, and people realized they had written them badly – because they interleaved their code within Rails, instead of using Rails as a layer and building their code on top of it, carefully segmenting the access points to that layer. Gosh, that sounds like work! Enter things like Avdi Grimm’s Object On Rails. And the Rails community re-learns things that the Java community has suffered through and grown past. Dependency Injection is making a comeback, Ruby-style. People use TDD as an indicator of design smells – if you have to boot up Rails to run your tests, you’re doing something wrong! Although of course SOME tests require the entire Rails stack, but we call these Capybara tests, because “end-to-end” is ugly, and capybaras are much prettier to look at.

And then, on the other hand, you have Sinatra, and Backbone.js, and other things that are focused on doing one thing and doing it well.

Now we have everything that Rails has taught the Ruby world – segment your logic, stay away from expensive code (the only currency here is time, and this is a very important thing to realize). Your TDD loop should be very short – you can watch some of Gary Bernhardt’s screencasts on Destroy All Software to learn mor about this. We have Capistrano, and Capybara. We have RSpec. We have Opal, a Ruby-to-Javascript compiler.

And in case Opal is too weird for you, you’ve got the Backbone.js world, where you have to make all these exact decisions over again.

You’ve got Sinatra, a wonderful “controller”. Sinatra is a great place to put your API and test it. Because that is the only thing Sinatra gives you, you feel the pain every time you add something — you have to add it.

And your storage is now distributed. Imagine … Backbone.js front-end, Sinatra in the middle, and your distributed storage of choice on the other side: Google Drive, Apple Cloud, Dropbox, MediaFire … You pick it, you store to it. Users now carry their data everywhere. Virtually speaking, of course. Gosh, sounds like you’re even reducing costs.


So now, we face the challenge the health world has been trying to solve for over a decade – how do you share information between proprietary systems? After all, the user is the one who’s suffering.

This is an entirely different blog post – how much of “your” data really is yours? How much could be shared? You know.. Like one of those virtual business cards, I suppose. You’d have a JSON object behind a secure server where the user stores THEIR information, and you ask for permission to read that one object.