Giving Vim a Go

Monday, March 30, 2009

So I'm in the process of trying out Vim as a Rails IDE. I've been using Textmate (and the e text editor on Windows before it) for some time now, and while there are a lot of things I really like about both editors lately I've been running into some things that are really bugging me. The biggest has been slowness on large projects - Textmate in particular really seems to bog down when you have a lot of files in your project. I'm trying a few different things to help it out (this for instance) but those come with their own drawbacks. Nothing I've found yet solves the issue of inadvertently opening a giant log file and having Textmate bring my whole system to a grinding halt. I used Vim in college doing some systems programming, so when I decided to try out another programming editor Vim was the first one that came to mind. It's certainly not as pretty as Textmate, but it's about as efficient as you can get once you learn the shortcuts - usability isn't always about looking pretty. I've also used Emacs and Netbeans before and while they're both nice, Emacs is a bit more involved than I'm willing to attack right now, and Netbeans suffers from many of the same slowness problems I'm trying to get away from in Textmate. That goes double (or triple) for Rubymine.

Since I'm on a Mac, I decided to try out MacVim, which seems to have generally positive reviews. It's free and easy to install, and the Rails.vim plugin has been getting a lot of press lately. I took the plunge and installed the whole shebang - MacVim, Rails.vim, Project.vim, and the Vividchalk color scheme. I liked what I saw a lot at first. MacVim is easy to integrate with both the command line (the mvim command a la Textmate's mate command) and Quicksilver, Rails.vim has a lot of nice shortcuts, Project.vim has a more than adequate project view, and Vividchalk is easy on the eyes. About the only things I'm missing are the Ruby/Rails docs from Priit Haamer's Rails Dictionary, the Cmd-T file finder (which had gotten unbearably slow in Textmate anyway) and the Cmd-R functionality to run a single unit test. I'm sure all of these exist in the Vim world, but I haven't quite gotten to setting them up yet. One of my co-workers pointed me to Spicycode's Bringing Vim to the People, which is a handy bundle of Vim plugins and configuration for Rails developers. So that's where I'm at now - fighting with BVTTP's config. I like that it includes a lot of the configuration for common Rails-Vim functionality (including FuzzyFinder for replacing Command-T) but there are definitely some wrinkles. For one, I can't get :Rproject to open the current directory as a Rails project anymore, and can't for the life of me figure out why this command has just gone away. Installing ctags support for drilling into code and docs has also been a bit of a challenge. The bundle requires the exuberant variant of ctags (not the vanilla ctags included in OS X), and while that's readily available in MacPorts, it's also necessary to set the ctags binary path in your vimrc explicitly with a

let Tlist_Ctags_Cmd = '/opt/local/bin/ctags'
lest you get strange and vague ctags usage errors like
Taglist: Failed to generate tags

The long and short of it is that the jury's still out for me on vim. Despite its wrinkles, Textmate is still a nice editor, and it's likely to remain my primary editor for when I'm pair programming due to Vim's notoriously steep learning curve. I'm going to keep at it and see what happens. At worst, it'll give me a better appreciation for the qualities of different programming editors. With a little luck, I'll be able to get a setup that addresses a few of my Textmate gripes without introducing too many new ones of its own.

Have some editor feedback of your own, good or bad? Hit us back in the comments.

State of the blog

Tuesday, March 24, 2009

To start out restating the obvious, this blog has been pretty dead for the last 6 months or so. There are a variety of reasons why that's happened, but in all honesty most of them are too long or boring to explain here - suffice it to say that there have been a lot of posts started, but none have been finished. This is not due to a lack of good material to write about. Rather, the cycle seems to be that an interesting but overly broad post idea turns into a half-written outline, which then becomes a half-written post, which then sits in the queue for months on end waiting to be finished because the effort required to fully expound on the original topic is way more than anticipated. While topic selection is important, topic focus is even more important. There's a delicate balance that needs to be struck to end up with a topic that's both interesting to read and feasible to write about in a meaningful way. What this means is that we're going to try to post more short and specific posts. The general topics of technology, usability, design, and Inkitecture news will stay the same, but hopefully the posts will become both easier to write (for us) and easier to digest (for you).

Oh, and we've also been working on some new sites. Stay tuned, we'll post more about those shortly. And this time I mean it.

Craigsmonitor.com Apple Iphone Staff Pick

Saturday, August 23, 2008

Check It:



We submitted Craigsmonitor under the advice of Adam Williams after his site, Online Italian Help and his other language sites blew up with traffic after posting it to the Apple iPhone Webapps site. We did the same, and guess what? Staff pick.

Bangin’. We couldn’t be happier.

Railscasts, User Mistakes, and Embarassing E-mails

Monday, August 18, 2008

While I was sitting on the airplane tonight I watched a Railscast episode about adding session-based edit capabilities to a comment form. Put simply, it's a way to let users edit their comments for a brief period of time after they've posted them without requiring all the overhead of signing up, creating an account, etc. At the very end of the episode, Ryan Bates mentions looking at systems that you may have in your own web apps and evaluating how well you let users deal with and correct their own mistakes (I'm paraphrasing here, but you get the idea).

This really resonated with me - good user experience is something of a passion around here, so it's nice to see some love for UX, especially from the technical side of things. I started thinking of other places this sort of scenario comes up and the case that immediately came to mind was e-mail. I think most folks have had that moment of panic and the resulting dread after sending an email they didn't quite mean to. Maybe it was addressed to the wrong person (as in the classic reply vs. reply-all mistake), maybe you said something you didn't mean, maybe you forget to edit the subject (or didn't include a subject), or maybe you made an embarrassing typo that you didn't notice until after you hit send. Whatever the reason, wouldn't it be nice if you had a ten second buffer between when you hit send and when the message actually left the confines of your own computer, giving you a short window in which to cancel and correct your mistake? For me anyway, whenever this has happened, the realization of the mistake has been immediate, so the buffer need not be very long. From a user experience perspective, it needn't (and probably shouldn't, for that matter) be intrusive or attention-grabbing either. Just a simple pop-under or status bar type message with a countdown until the message is released from the queue and sent on its merry way would be perfect for me.

What do you folks think? Is this potentially useful, or just another annoying affordance for people like me who tend not to read their messages as thoroughly as they should before they hit send? Are there mail clients out there that do this already? Please, if you're willing, sound off in the comments. I'd be very interested to hear other perspectives on the same topic.

Last but not least, mad props to Ryan Bates of Railscasts - the screencasts he does are second to none. They've been a great influence over the course of my maturation as a Rails developer. Plus, they're free and there's a new one every week! What more could you ask for?

Now twittering

Sunday, August 10, 2008

Just a quick heads-up - Inkitecture is now on Twitter (@inkitecture). It's long overdue, especially considering how much time we spend working with Twitter on a regular basis. Visit http://www.twitter.com/inkitecture to take a look or to follow us.

Posted by Jay Zeschin at 2:42 PM 0 comments Links to this post  

Craigsmonitor

Thursday, August 7, 2008

As a soon-to-be grad student, I will additionally soon-to-be broke. This means that I will be using sites like Craigslist a lot more. That being said, I have a problem with Craigslist.

My problem with Craigslist is that if you’re looking for something specific, for example “2002 Ford Escape” and you want to be competitive on the buy, you have to return to Craigslist several times each day, every day, to keep up to date. And if you're looking for something in a rural area, like Bloomington, IN, you need to return day after day to see if there were any updates. Bummer!

This is where Craigsmonitor comes in. Aptly named, Craigsmonitor monitors Craigslist for any updates to a product you desire. If there are any updates, it will email you a list of fresh posts on an hourly, daily, twice daily or thrice daily basis.

Also, no passwords or registration – you make a list and get an email. That’s it.

Please let us know what you think about Craigsmonitor.

Posted by Drew McKinney at 12:28 AM 0 comments Links to this post  

Introducing Bag vs. Bin

Saturday, June 21, 2008

We have a fun announcement today - we're releasing our second app into the wild. It's called Bag vs. Bin, and you can check it out at http://www.bagvsbin.com/.

I know what you're thinking (or at least I think I know what you're thinking. I know what I'd be thinking if I were you) - what exactly is it? That's probably best answered with a story. All 3 of us Inkitecturers (Inkitecturites? Inkitecturians? Inkitects? There we go, that's the one) have day jobs that require us to travel at least 4 days a week, every week, as long as we're not on one of those vacation things everyone keeps talking about. We typically travel by plane, and to save time and hassle we only use carry-on bags whenever possible. The way service standards are plummeting in the airline industry today, the fewer opportunities you give the airlines to touch your stuff and mangle/lose/steal it the better off you'll be. The problem is that even if you're trying to be a considerate flyer and get reasonably-sized bag that fits easily in the bin and doesn't monopolize the entire freaking space, it turns out that it's not that easy a task. Every airline, aircraft, and luggage manufacturer seems to have their own standard for what fits in a bin, and of course they're all slightly different. The linear inches measurement seems to be a common one, and it's not a bad idea, but it doesn't account for the different shapes and sizes of bags, nor the often-weirdly-sized doors on the bins themselves that can make it impossible to actually get your bag *inside the bin*. Plus, have you ever tried to measure the dimensions of your bag? Most bags have curved surfaces, rounded corners, weird bulges, etc. that make it hard to figure out the true linear measurements. The primary alternative, the "big metal box" (I guess they're actually called "sizers", but I like my term better) is more foolproof, but it doesn't do you any good when you're trying to plan a trip, buy a bag, or pack. You can check before you get on the plane, and that's great, but it's a classic instance of "too little too late".

So in frustration with this whole mess, we decided there had to be a better way. What if you could look up ahead of time whether your bag would fit on a given airline/aircraft? It would save a lot of hassle, both time and money. No more struggling to fit your bag overhead because you didn't know ahead of time, or buying a bag that looks great but turns out not to fit in 95% of overhead bins. Personally, I'm a big fan of SeatGuru for getting the inside scoop on the best seats, especially for long flights when the difference between a good seat and a mediocre one is multiplied many times. That site provided a lot of inspiration for Bag vs. Bin.

I guess that was a pretty long intro, so let's get down to brass tacks. Bag vs. Bin is like SeatGuru but for your baggage instead of your butt. You can either write or search for reports of passenger experiences carrying bags onboard different airlines and aircraft. Search by bag/manufacturer, airline, or aircraft, and you'll see a list of reports with handy little red/yellow/green icons indicating whether the bin battle was successful or not. You can drill down further and see comments on the experience, maybe even handy tips or notes, depending on what the writer has chosen to share. At the same time, you can share your own experiences and make them available to other travelers who are in the same boat. It's a community driven site, but we're hoping to turn it into *the* place to go for this sort of information. We're starting out trying to scratch our own itch here, but the hope is that others will find it useful as well.

So please, check it out - http://www.bagvsbin.com/. We'd love to hear what you think. Feedback, questions, comments, concerns, whatever. Feel free to comment here, use the feedback link in the header at Bag vs. Bin, or shoot us an e-mail at info@inkitecture.com.

Thanks and happy flying!

Posted by Jay Zeschin at 2:09 PM 0 comments Links to this post