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.

Rubymine

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

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

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 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.

“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

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.

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.

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.”

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.

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

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.

Collapse this post

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.

Why are these things always so weird? Someday I’ll understand why OSX is set up that way. And on that day, I’ll probably weep.

$ sudo /usr/bin/dscl . -append /groups/wheel GroupMembership username

This was found here : https://discussions.apple.com/thread/1230828?start=0&tstart=0

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.

EASY!

sudo ln -s /usr/bin/gcc /usr/bin/gcc-4.2

That’s it. You can now install ffi 1.5.