Text

· · to read

Over the last week I’ve been learning how to quickly develop simple applications in Rails without looking at API documentation. Each day I’ve been starting from scratch and seeing what I can create in an hour, only consulting documentation when I really need help. The first day I didn’t use scaffolds and I only got creating, reading, and deleting working with a single model. From the second day until today I’ve been using scaffolds. On Friday I got two models with a has_many association and image attachments (using paperclip) working. Each day I start from scratch, not copying or referencing the code from the previous day (though I do save the code). I think starting from scratch each time has helped me learn more quickly than I would if I were to use the last code each time.

Today I went back to working without scaffolds. Since I’ve been trying to read the documentation as little as possible while developing, I had to figure some things out for myself. One thing I had to think of was the list of actions to type when generating a controller. Here is what I came up with:

script/generate controller Planets index new show edit create update destroy

I’m obsessive-compulsive, so not only did I try to remember what actions are used in scaffolds, I tried to put them in an order that makes sense to me. I put index first because index is special. After that, there were two sensible approaches I could think of to order the remaining actions. I could either order by CRUD or order by whether or not the actions have views. Either way, I would use the other ordering technique within groups. I went with ordering first by whether or not actions have views, and then by CRUD. I started with the actions that have views because it’s nice to have them at the top when jumping from a view to its controller.

Here’s my thought process in a tabular format:

Create Read Update Delete
Has View new show edit *
No View create ** update destroy

Notice that there are a couple of holes in the table. The first one (*) is missing because the interface for deleting is built into the index. It doesn’t have to be this way, and in fact varies widely on the web. It could have its own page, or it could be on the show or even edit page (Side note: I think it’s bad UI to put the delete button on the edit page because the edit form doesn’t fit into the workflow of deleting an item. The user may want to look at an item before deleting it to make sure it’s something they don’t need, but they’re unlikely to want to edit an item). The second one (**) is missing because in the simple case reading is achieved entirely through GET requests.

One thing that’s convenient about having the ones without views at the end is that it makes it easy for me to remember which skeleton views to delete after running the generate command. It’s the last three.

It used to take me a minute or a few to remember what actions I need, but now that I have this mnemonic it should only take a few seconds.

Now, I place a certain level of importance on conventions. After I came up with this mnemonic I looked at a scaffold to see how rails orders things. The only difference between my ICRUDCRUD ordering (index, CRUD with views, CRUD without) or ICRUCUD ordering and the standard scaffold ordering is that the show and new actions are swapped. So rails uses the RCUD ordering. Fair enough. I have pontificated on whether the ordering in CRUD makes sense or is a bacronym. Create and read are pretty useless without eachother. Below is the table with the RCUD ordering. I threw index into the empty cell. If you read the first line left to right, then move down, like a book, the order is the same as it is in a scaffold:

The order of actions in a scaffold
index Read Create Update Delete
Has View show new edit *
No View ** create update destroy

Now, how to remember RCUD? Well, remembering to swap C and R is one way, but I prefer to think of a Rails cow chewing its CUD.

rcud

Original image from cerulean5000 on flickr. Used by Creative Commons license.

Text

· · to read

I just watched Corey Haines’ lightning talk from this year’s acts_as_conference:

He makes a lot of really good points in a short amount of time. One of the things he says is that if we have to look at documentation for a technique, we’re unlikely to use that technique when we’re in a time crunch. I think this is a very good point. Another time when I might not use the documentation is when I’m just dabbling.

To learn things, he suggests doing arbitrary tasks repetitively to get them engrained into our minds.

I spent a number of hours doing arbitrary tasks with vim, and I’ve gotten pretty good at using vim IMHO. I wish I could say I was as good at jQuery, but I haven’t got it down as well despite doing real projects in it. I think perhaps it’s best that I pick an arbitrary task, or at least do a real, but small, task repetitively, or keep trying to improve it, until I start to really get the hang of it.

On a side note, Corey Haines’ has quit working a regular job and started traveling around and pair programming with people in exchange for room and board. He calls himself a Software Journeyman. It will be interesting to hear what he learns from the experience. I hope his journey takes him to Arizona at some point!

Text

· · to read

This is just a quick update on how I’m using the enter key in vim. The sticky shift-enter key configuration didn’t work out for me. After pressing shift-enter once, I found that I would press shift-enter again, expecting it to create a newline. I wound up just remapping <CR≫ to <Esc>, and using shift-enter to insert newlines, or pressing enter and then “o” or “O” to create a new line above or below the current line. I use the latter option most. The only time it doesn’t work is when I need to split a line into two. For that I use shift-enter.

Shift-enter doesn’t work when using vim in a terminal, so the remapping doesn’t work quite as well in the terminal. I use it anyway, though. I should remap something to split a line into two, but so far I haven’t. I use vim in the gui (MacVim) most of the time. The couple of times I’ve had to split a line in the command line, I’ve hit:

  • D to delete the rest of the line and yank it
  • o to open a new line
  • Enter to get out of insert mode (since it’s remapped to Esc)
  • p to paste the rest of the line, that I deleted earlier

…which is terrible. If I start using command-line vim more often I’ll add a mapping for it.

This might seem like a pain, but for me it beats reaching for the Esc key. YMMV.

Update: zenzike pointed out in the comments that if you remap CR (the enter key) in the terminal, Control-CR still inserts a newline. So you could use Control-CR to insert a newline if CR was remapped to Esc. Unfortunately, this doesn’t work for me in OS X’s terminal or in iTerm by default. It does, however, work in gnome terminal running under Ubuntu on VMWare Fusion. I’m not sure why it doesn’t work in either of the two OS X terminal programs. I would be curious to learn why it doesn’t work and how to fix it, though, as this otherwise a very nice solution.

Text

· · to read

A few weeks ago, I started using vim as my main text editor. Soon after that, I installed the vimperator Firefox extension on my main computer. A few days into the use of these two tools, I was really excited about both of them. It takes more than a few days for me to know whether I’m comfortable with using a particular piece of software regularly, though.

I’m still using vim every day, and I like it. It’s powerful, ergonomic, and customizable. There are a few annoyances. I still haven’t figured out how to properly configure Firefox to use MacVim as an external editor. Vim doesn’t support having multiple frames for a single instance of vim (emacs does). The official wiki, hosted by Wikia, has horrible ads, and I refuse to install an ad blocker, because I don’t want to turn a blind eye to virtual blight like the maintainers of vim have. Nevertheless, I’ve become quite comfortable with vim and will continue using it. While I’d like it much more if it didn’t have these annoyances, it has relatively few annoyances compared to some other editors I’ve tried, and the good things about it outweigh the bad.

My experience with Vimperator was different. As with vim, I really enjoyed using it at first. Over time, though, I found myself growing tired of it, even though it enabled me to browse faster. The biggest problem for me was that the commands only work if I’m in the normal mode, and it’s very easy to get thrown out of the normal mode. The two things that most often put me in the wrong mode were full-page Flash files and JavaScript that placed the focus in text boxes. Another issue was that I couldn’t easily use the keyboard to scroll in a div. I can’t easily do that with normal Firefox either, but Vimperator is supposed to make browsing with the keyboard easy, and it does it for the most part.

I uninstalled vimperator, but I miss its functionality. I’d like a lightweight extension that makes it easy to click links or jump between form fields with the keyboard. I don’t think that the vim input model is suitable for keyboard navigation within a browser, because the browser environment is too unpredictable. I’d like to see a couple of multi-key combinations that activate keyboard input, though. These would work inside of text fields. Flash would probably still break them some of the time, but to deal with that I could install FlashBlock.

I really enjoy trying out new development tools. I think the next thing I’ll try out is a visual CSS editor. Any suggestions?

Text

· · to read

I just went to BIL. It was a fantastic conference. I met a lot of interesting people and saw a wide variety of talks. It was my first BIL. The first BIL was last year and about a third of the people at this BIL were there last year. Repeat attendance is always a good sign. It’s quite likely that I’ll go next year.

The first talk made the greatest impression on me. It was Brad Templeton of the Free Software Foundation talking about the problems with Cloud Computing. I always felt I was giving up flexibility and privacy by having most of my computing take place on an application service provider’s service, but this talk helped solidify that feeling. I’m going to see about getting my email under my control soon (I use GMail right now).

Of the rest of the talks, these ones really stood out:

  • Seasteading: how to homestead the high seas and why it will make politics work better by Patri Friedman – Really interesting idea. But could it actually work? After hearing the talk, I think it might.
  • California’s Water Crisis – What YOU can do! by Ryan Arroyo – As a future California resident and connoisseur of Californian produce this is really close to my heart. He gave lots of good water-saving tips. I asked him what the impact of the water shortage might be on farmers and he said that it looks like it will be tough for small farmers. I’d like to get involved in making sure the organizations that control the water supply are fair to small farmers.
  • Secrets of Social Influence (How to get a Date) by Francisco Dao – I finally got a good definition of what “hovering” is, in the context of flirting. I have done that in the past and will avoid doing it in the future.
  • The art of Conference Crashing by Chris Axton – It turns out that the easiest way to crash a conference is to volunteer. Go figure. Lots of great photos and stories, though.
  • What’s Funny about the Interwebs by Ben Huh of icanhascheezburger.com and failblog.org fame – Even though his work (taking user-generated content for free and slapping absurd quantities of ads on them) annoys me, it was great to hear him talk. And I can’t blame him too much. He talked about the lifecycle of a meme, using RickRolling as the example. Good stuff.
  • Color by Numbers – The Wonders of Algorithmic Art by Matthew Shultz – A fractal art demonstration using both visual tools and code.

This is just a sampling of the interesting talks I saw. I also missed some good talks. I can see many of them online, though.

I took this week off and am going to travel up the coast to San Francisco. I’m in Santa Monica right now. It’s been a wonderful vacation so far!

Text

· · to read

I set up vim to use enter to get out of insert mode. This prevents frequently having to reach for the escape key or use a multi-key combination. To insert a new line while in insert mode, I now use shift-enter.

An idea I had this morning is to make shift-enter swap the shift-enter and enter bindings. This way, if I’m in the mode of writing something new without manipulating text, I can push shift-enter once to enter a newline, then push enter for each additional newline, and push shift-enter when I’m done to get out of insert mode.
shift-enter

To implement it, I created a function that toggles the bindings, and added a call to the function to my bindings for <S-Enter>.

function ToggleEnterMappings()
  if mapcheck("<CR>", "i") == "<Esc>"
    iunmap <CR>
    inoremap <S-Enter> <C-o>:call ToggleEnterMappings()<CR><Esc>
  else
    inoremap <CR> <Esc>
    inoremap <S-Enter> <C-o>:call ToggleEnterMappings()<CR><CR>
  endif
endfunction
call ToggleEnterMappings()

Time will tell whether this is a good setup for me. I think if I do single-line inserts much more often than I do multi-line inserts it might.

Text

· · to read

After a friend recommended it, I gave Twidge a whirl. Twidge is a command-line microblogging client written in Haskell. It works with twitter and identi.ca.

Installing it on my mac was tricky at first, because I didn’t have instructions for installing it on Mac OS X, but once I figured out how to do it, it turned out to be really easy. I posted the installation instructions for OS X on the Twidge wiki.

So, how does it work? If you put twidge in your path, you can type twidge and it will provide a help screen. You can type twidge lscommands to get a list of commands. Of particular interest to someone who’s starting out is twidge setup, which asks for your username and password and puts them in ~/.twidgerc for later retrieval. Once it has your username and password, you can type twidge lsrecent for a list of recent updates by people you’re following, twidge lsreplies for a list of replies, and twidge update to post an update.

If -asu is specified on the command line to lsrecent, twidge will show all the updates since lsrecent was run. The -asu option has the same effect on lsreplies. In the Twidge HOWTO it shoes how to pipe lsrecent and lsreplies to less to enable checking all tweets with one command. I reversed the order so the replies would show up first, so I’ll see the replies even when I decide not to read all of the tweets. The command I put in ~/.bash_profile is here:

alias twidgecheck='(twidge lsreplies -asu; twidge lsrecent -asu) | less'

Now if I run twidgecheck, I can see all my updates. Nice! And once I’m done with them, I don’t have them showing up next time I turn to twidge. Update zero, if you will!

My main dislike with this system is that links are harder to visit with my terminal. If I was using the gnome terminal, I could just click them. Maybe I can find a way to make iTerm do that.

Text

· · to read

The other day I went back to an old branch that had about five files that were changed and I only wanted to incorporate two of them into my master branch. In order to just merge in a couple, I used git merge with the –no-commit option.

git merge --no-commit planner

This merges in all changes but doesn’t commit it. Since it isn’t committed, it’s easy to roll back individual files. I ran git status to get a list of files and rolled back several files with git checkout. When I was done, I had only the two files I wanted to merge showing up when I ran git status.

Text

· · to read

Yesterday I started trying out Vimperator, and so far I’m impressed. It’s a Firefox extension that puts a vim-like keyboard interface on top of Firefox.

After using it for a while, I wanted to turn the bell off, because I find it to be distracting. I turned to the documentation. I quickly found a visual bell option, but I find visual bells to be even more distracting. Then I saw the visual bell CSS style option, which can be set to an empty string for no bell at all. Bingo! Or so I thought.

It turns out that the page flickers when the bell is triggered. This is not the desired effect. So after searching the docs one more time, I unpacked a jar and poked around in the source code of Vimperator.

There’s a beep function in there. I changed the beep function to return false and Voila! It did nothing when you scrolled past the bottom or top of the page.

Rather than keep the code patched, though, I figured out how to implement my change in my ~/.vimperatorrc file. There’s a javascript command for executing a line of javascript. Vimperator’s beep function is in a global “liberator” object. Combining these two bits of knowledge, I came up with the following line which can be added to ~/.vimperatorrc:

javascript liberator.beep = function() { return false; }

It’s simple but it works. It would be nice if completely disabling the bell (including any visual artifacts) were built into Vimperator, but being able to fix it with a one-liner in the configuration file is the next best thing! Kudos to the Vimperator developers for writing code that’s easy to modify.

I’m not sure how often I’ll use Vimperator. I need to learn how easy it is to pass the input through to the current web page first. But it certainly seems to do a difficult job remarkably well!

Update: I started a Silencing and Disabling Bells WikiBook and put instructions for disabling bells in Vimperator, MacVim, and iTerm in it. Contributions welcome!

Text

· · to read

I’m at the Merb and Rails 3 community forum with Yehuda Katz and Matt Amionetti right now. It’s an event with no agenda; they just opened the floor to questions. I asked them a couple of questions about Merb slices.

First, I asked them what would happen with slices in Rails 3. They explained that slices are going away in future versions of Rails and Merb, but the functionality will still be there. Instead of having slices, applications will simply be “mountable” within other applications.

I then asked if components such as models could be shared between slices. Yehuda said that their goal was to give all applications a namespace by default. He then went on to say that hopefully there will be no need to refer to an application’s namespace from within the application.

This sounds great! With a few contributions from the community, it should be at least as easy to install multiple apps into a site and get them sharing stuff as it currently is in Django.

Text

· · to read

After watching the Meet Emacs screencast on Peepcode and talking to a few local developers who use emacs, I’ve started using emacs again. Since I started playing around with it several weeks ago, I’ve learned about a number of useful features I either hadn’t used before or had just barely scratched the surface of. These include the following:

  • ido-mode – A tool for quickly finding files that uses a combination of history and intelligent name searching.
  • hippie-expand – Intelligently completes part of a word to match another word in the current buffer.
  • text macros – I’d seen this before but didn’t realize how often it can be done in place of a regex search-and-replace. Much more intuitive, too.
  • C-x C-v – Unlike the more commonly used C-x C-f, which loads a file in a new buffer, visit-file (C-x C-v) loads a file in the current buffer. This solves a common annoyance for me of opening the wrong file in the right directory, and having to choose between leaving the wrong file open or navigating back to the right directory after closing the wrong file.

These are things I wouldn’t have noticed if I had still been blindly following the Pragmatic Programmer tip, Use a Single Editor Well. The problem with picking an editor and sticking to it is that there really isn’t a way to learn how good an editor is without actually using it.

I’m also starting to think that maybe, even after I’ve gained a pretty good understanding of most editors, I still won’t want to pick a single editor. Maybe I’ll use emacs for some things and TextMate for others. Using more than one editor might not be for everybody, but for people who take a serious interest in editors, it might be a good idea.

I put my emacs dotfiles directory up on GitHub, if anyone is curious about the customizations I’ve made to it.

So far I like my new setup, and I’m using Emacs most of the time. I’m getting to be quite comfortable in it. I’ve dealt with a couple of things that used to annoy me most about emacs, which are confusing indentation and inaccurate syntax highlighting. I dealt with the former by setting the tab key to go to the next tab key, rather than use the current mode’s indentation code. To deal with the latter, I just turned off syntax highlighting. I’m actually quite comfortable without it most of the time, and if I really want pretty syntax highlighting, I can always fire up TextMate.

In the future, I may continue to use emacs as my primary editor, or I may not. If not, I don’t think my time learning Emacs will have gone to waste, as I’ll have learned new editor features and I’ll know what to look for when I explore the advanced features of whichever editor I’m using.

Text

· · to read

As stated before on this blog, I’m a heavy twitter user. I tried to quit twitter and found that it was hard to leave. Eventually I just gave in. Now I’m following somewhere between 100 and 200 accounts.

Sometimes I want to say or quote something that’s just below 140 characters, but I feel obligated to provide some context. In those situations, I usually wind up cutting out some punctuation or text in order to fit a shortened URL. Not anymore—if it’s searchable.

I created a new twitter account called @srch. If you click on the twitter ID, it takes you to @srch’s twitter profile. On that page are instructions that will let the savvy user know that if they have decent searching skills, they can probably find where the text came from.

Please let me know what you think of this idea.