Francis Hwang's site

Vim

2012-11-25T16:48:12Z

So I switched to Vim, and now I love it.

For years, I was actually using jEdit, of all things, even in the face of continued mockery by other programmers. My reasoning was well-practiced: TextMate didn't support split-pane, all the multi-key control sequences in Emacs had helped give me RSI, and Vim was just too hard to learn. jEdit isn't very good at anything, but it's okay at lots of things, and for years it was fine.

But eventually, I took on a consulting gig where I was forced to learn Vim. And, as so many have promised, once I got over the immensely difficult beginning of the learning curve, I was hooked.

Beneath the text, a structure

I'm now one of those smug Vim partisans, and one of the cryptic things we like to say is that Insert mode is the weakest mode in Vim. So what the hell does that mean? It means that if you accept the (lunatic, counterintuitive) idea that you can't just insert the letter * by typing *, what you get is that every character on the keyboard becomes a way to manipulate text without having to prefix it with Control, Cmd, Option, etc. (In fact, the letter * searches for the next instance of the word that is currently under the cursor.)

When you edit source code, or any form of highly structured text, this matters, because over the course of your programming career you're far more likely to spend time navigating and editing existing text than inserting brand new text. So the promise of Vim is that if you optimize navigating and editing over inserting, your work will go faster. After months of practice, it does feel like I edit text far more quickly--that hitting Cmd/Ctrl/etc less often compensates for the up-front investment of learning these highly optimized keystroke sequences.

But it's definitely a strange mindset. In most text editors, you think of the document as a casual smear of characters on a screen, to be manipulated in a number of ways that are all okay but never extremely focused. But Vim assumes you're editing highly structured text for computers, and in some ways it pays more attention to the structure than the characters. So after a while it feels like you're operating an ancient, intricate machine that manipulates that structure, and that the text you see on the screen is just a side-effect of those manipulations.

Investments

Is it worth the time? To answer that question you have to get almost existential about your career: How many more decades of coding do you have in front of you? If you're planning on an IPO next year and then you're going to devote the rest of your life to your true passion of playing EVE Online, then maybe keep using your current text editor. But for most of us, a few weeks or more of hindered productivity might be worth the eventual gains.

As is often the case, it's not about raw, straight-line speed--it's about fewer chances to get distracted from the task at hand. Nobody ever codes at breakneck speed for 60 minutes straight. But when you're in the middle of a really thorny problem, maybe you'd be better off with a tool that's that much faster at finding/replacing/capitalizing/incrementing/etc, which might give you fewer chances to get distracted from the problem you're actually trying to solve.

As somebody who's used Vim for a little less than a year, that's what it feels like to me. Most of the time. I have to admit that once in a while the Vim part of my brain shuts down and I stare at the monitor for a few seconds. Those moments are happening less and less, though.

Beginner steps

When it came to learning Vim, here's what worked for me:

Practical Vim

Drew Neil's Practical Vim is, uh, the best book about a text editor I've ever read. It does a great job of explaining the concepts embedded inside of Vim. I skim through this every few months to try to remember even more tips, and can imagine myself doing that for years.

MacVim

As Yehuda recommends, I started in MacVim and not just raw Vim. At first you should let yourself use whatever crutches you need--mouse, arrow keys, Cmd-S--to help you feel like you can still do your work. I agree with Yehuda that tool dogmatism is going to be counterproductive if it makes the beginning of the learning process so painful that you give up.

And I still use the arrow keys, and don't really buy the argument that it's ever important to unlearn those.

Janus

As with Emacs, a lot of the power of Vim is in knowing which plugins & customizations to choose. Yehuda and Carl's Janus project is a pretty great place to start for this. I'd install it, and skim the README so you can at least know what sorts of features you're adding, even though you won't use them all for some time.

vim:essentials

Practical Vim is great for reading when you're on the subway or whatever, but you'll need something more boiled-down for day-to-day use. For a while I had this super-short vim:essentials page open all the time.

Extra credit: One intermediate step

After I got minimally familiar with Normal mode, I started hating the way that I would enter Insert mode, switch to my browser to look up something, and switch back to Vim forgetting which mode I was in. I entered the letter i into my code a lot.

I suspect many Vim users just get used to holding that state in their head, or never leaving the Vim window without hitting Esc first, but I decided to simply install a timeout which pulls out of Insert mode after 4 seconds of inactivity:

au CursorHoldI * stopinsert

As explained in Practical Vim, the best way to think of Insert mode is as a precise, transactional operation: Enter Insert mode, edit text, exit Insert mode. The timeout helped me get into that mindset quickly, and live in Normal mode, which is the place to see most of the gains from Vim.

This is an intermediate step, and you shouldn't try it right away. If you're a beginner you're probably not going to benefit from being in Normal mode all the time--if anything the frustration would be likely to make you give up on it. But once Vim starts feeling less disorienting, and you're ready to really learn what Practical Vim has been telling you, I'd give this a try.

Hope that's helpful. And I hope that after a month or two of this, you become as smug and self-assured about your text editor as I am today.

The law of constant testing hassle

2012-10-09T23:28:59Z

Over time, technological progress makes it easier to write automated tests for familiar forms of technology.

Meanwhile, economic progress forces you to spend more time working with unfamiliar forms of technology.

Thus, the amount of hassle that automated testing causes you is constant.

"-un"

2012-07-06T14:39:15Z

Looks like your Twitter bots need to be better at quote-escaping:

The Front-End Future

2012-07-03T22:57:01Z

My Goruco 2012 talk, "The Front-End Future", is now up. In it, I talk about thick-client development from a fairly macro point-of-view: Significant long-term benefits and drawbacks, the gains in fully embracing REST, etc.

I also talk a fair amount about the cultural issues facing Ruby and Rails programmers who may be spending more and more of their time in Javascript-land going forward. Programmers are people too: They have their own anxieties, desires, and values. Any look at this shift in web engineering has to treat programmers as people, not just as resources.

Francis Hwang - The Front-End Future from Gotham Ruby Conference on Vimeo.

As always, comments are welcome.

Goruco 2012 is over

2012-06-24T17:08:28Z

This isn't just the event New York Rubyists want. It's the event they deserve.

Thanks so much to all the co-organizers for pulling this off. Everybody else: See you next year, if not sooner.

Ellipsifier

2012-06-10T00:02:49Z

And there's this, too: Ellipsifier is a Javascript library that truncates HTML. It will retain the tag structure, counting only visible characters in the resulting text.

new Ellipsifier("to be or not to be", 5).result
//              "to be&nbsp;&hellip;"
new Ellipsifier('to <strong>be or</strong> not to be', 20).result
//              "to <strong>be or</strong> not to be"
new Ellipsifier('to <strong>be or</strong> not to be', 5).result
//              "to <strong>be</strong>&nbsp;&hellip;"

Another chunk of code written with the good folks at HowAboutWe.

EasyMailPreview

2012-06-08T19:17:46Z

The folks at HowAboutWe do a decent amount of HTML email, as you might expect for any site where people can send each other messages. Dissatisified with the tools for developing HTML email, I wrote EasyMailPreview, a Ruby gem that makes it very easy to see the results of an HTML email in development mode. It auto-discovers mail methods and method arguments, and lets you write them on the fly with in an admin-ish screen.

I've been using it for a while, and I find it eases the pain of developing HTML emails. Somewhat.

Goruco: Six years on

2012-05-29T00:23:46Z

I wrote a little something about Goruco on the Goruco site:

Let me make a confession: Before we hosted the first GORUCO, I kind of didn’t want to be bothered. NYC.rb had been a successful Meetup for years, and people would occasionally say “you know, we could have a great regional conference here.” Which made sense in theory, but just thinking about the work involved gave me a headache. I usually smiled politely and tried to change the subject.

It's worth a read if you're not already convinced this year will be the best Goruco evar. And if you have yet to buy your ticket.

Speaking at Goruco

2012-05-22T00:54:32Z

So, I'm speaking at Goruco this year. On The Front-End Future:

With the rise of Javascript MVC frameworks like Ember and Backbone, web programmers find themselves at a fork in the road. If they keep doing server-side web programming, they'll benefit from tried-and-true tools and techniques. If they jump into Javascript MVC, they may be able to offer a more responsive web experience, but at significant added development cost. Which should they choose?

This talk will address the strategic costs and benefits of using Javascript MVC today. I will touch on subjects such as development speed, usability, conceptual similarities with desktop and mobile applications, the decoupling of rendering and routing from server logic, and the state of the emerging Javascript MVC community. I will also discuss the impact of this seismic change on Ruby, Rails, and your career as a software engineer.

Nobody should confuse me with a Javascript expert, and that's not why I'm giving this talk. There are many talks you can see that focus on the specifics of implementation that are being hashed out today. With my talk, I will be drawing out the macro trends in our field that affect the products we build, and the careers we craft.

In particular, I feel like the move to thick-client web apps is giving the Ruby and Rails community a bit of existential paralysis--we should be talking about this far more, and meeting this change head-on. The future is uncertain, but it is also bright.

Goruco is on Saturday, June 23. This is our sixth year, and without giving away the rest of the speakers, I think this might quite possibly be our best program yet. If you want to join us, tickets are still available.

That's what she or he or Michael Scott said

2012-03-29T16:00:05Z

Awesome.

Last Friday, the bot went a bit crazy and started throwing ["That what she said"] into the conversation with no apparent rhyme or reason. Finally, I had had enough. And then it came to me: I would write my OWN bot, that responded to TWSS with a quotation from a notable woman. If they are so keen on what she said, why don’t we get educated about what she really had to say. And so the “whatshereallysaid” bot was born. It might annoy the guys into shutting off the TWSS bot, or we might all learn about notable women. It’s a win either way, in my books!

As a side note, I've always found "That what she said" to be annoying humor, not just because it can be sexist but because it's also just the dumbest, sloppiest humor you can think of. It's used by Michael Scott in "The Office" ironically, as an example of what a socially inept man-child might think of as funny. When and how it got stripped of that irony I'll never know.

But is it too much to ask people to be less stupid than Michael Scott?