Things I googled for but didn't find

How to list all filenames except those in git repositories

2011-03-29T13:22:00.000-07:00

I wanted to see the names of all Vim source files in my ~/.vim directory. Because I use pathogen and submodules, there are a lot of .git directories under there, and I didn't want to list those. So I learned how to use the find command's 'not' operator, and it was easy:

find . \! -path "*.git*"

If you're curious, the reason I wanted to do this was to see if Vim authors typically use dashes or underscores to separate words in filenames. The answer: dashes (usually).

Your product is not as important to us as it is to you

2011-01-15T21:10:00.000-08:00

I own a Mint. Is that a stupid name, or what? Especially when there's another hot product by that name which predates it. There's no way Mint will ever achieve the brand loyalty of Roomba, because its aficionados don't have a special word to use. I own a Mint. What's that??

A Mint is a Roomba for swiffing hard floors. And it's a great gadget, if pricey ($250). It quietly goes about its business, using a fixed infrared navigation beacon to build a map of your floor, chairs, stairs and other obstacles while it swiffs up the dust and cat hair. I really love it.

The other day, the power went out. And the Mint, which was recharging, went berserk. It started beeping and flashing its lights in a realistic display of a machine frightened out of its wits. "I'm without power! Saaaaaave me!!!"

Because, of course, in a major power outage, my first concern is whether my cleaning robot has enough charge left to swiff the bathroom.

This behavior obviously made sense to the machine's designers. They reasoned that if you were recharging your Mint, you'd want to know if that function failed. But imagine if all rechargeable appliances behaved this way. You'd go around from appliance to appliance, calming them down, unplugging their chargers, whispering reassuring words...

How does a design flaw like this happen? My belief it's because of the tunnel vision caused by working day and night on a product, putting your heart and soul into it. To you, it's the most important thing in the world. So you tend to forget that for other people, it's just a minor aid to keeping floors clean. It's just not that important to us.

But that's not what prompted this blog post.

It was this:

This is the output from a Ruby on Rails upgrade tool. It checks your project to see what you might need to change to upgrade it from Rails 2 to Rails 3. An excellent utility.

But you can see that its designers too got caught up in the importance of their own work. If a message is important, why, let's display it in red! If it's less important, a subtle grey is best. And then let's use two more colors for other categories of information.

This is the equivalent of using <blink> on an HTML page. Dudes, it's a commandline console. We're not playing Nethack here. We can read simple black and white. But we can't read this because it assumes it's being run on a terminal with a black background! (It doesn't look any more attractive on such a terminal, but at least you can see what it says).

This mistake by the utility's designers arises, I think, from the same sense of the work product's self-importance shown in the Mint. In both cases, they were so focused on making their product useful that they didn't take a step back to consider it in the context of all the other products out there, of which their baby is just one.

Remember, it may be the most important thing in your life while you're working on it. But it's not the most important thing in our life.

Why I love solo programming (and why I hated working for Pivotal)

2010-12-05T13:17:00.000-08:00

About a year ago, I wrote a post about why I don't like pair programming (and why I left Pivotal). This is the flip side.

I've been working for the California Academy of Sciences for the past five months. I'm creating an NSF-funded website for ant taxonomists: antcat.org.

It's the best job I've ever had in 25 years as a programmer.

There are a number of reasons: I get to work at a museum where I can go and look at amazing fish, lizards, and butterflies every day, on a greenfield application in Rails, for an intelligent and easy-going boss, for an audience of scientists, in Golden Gate Park, ten minutes from my house. The pay is "only" 100K, which is less than I've made in quite a few years. But there's health insurance, and I get to work the tidepool exhibit a couple of times a week.

But the #1 plus is that I work alone.

I'm not proud of enjoying this so much. I'd much prefer it if I liked being part of a vibrant and innovative team - even pairing with them. But I don't.

Quite simply, at this job I get to do things the way I want. That means 95% test-driven. It means agile - doing the simplest thing that could possibly work. It means adding Solr when I want. It means really learning Javascript for the first time. It means applying the lessons learned over a quarter of a century of experience in my field. And it means not having to argue about it.

Maybe it's just been my bad luck, but I've never seemed to have worked with people who share my views on lean development, agile methodology, OOP, database design, or even structured programming. Views I've learned from reading people like Martin Fowler and Kent Beck. Obvious things that these guys just take for granted, like avoiding premature optimization, or following the single responsiblity principle.

So my interaction with my fellow developers has always seemed to involve a lot of arguing. I've become much more diplomatic and polite over the years, and I'm much quicker to concede a point (after all, I might be wrong). But there comes a point where you get tired of being the OOP "purist" (I'm not). You just want to do it right.

Now, I'm very aware of what I'm missing out on by working alone. My way may not in fact be right. I might not learn about other ways that I would end up embracing. I no doubt create more bugs. I sometimes make bad design decisions that cost me time. All these things would be tempered by working in a team, including pairing. And as far as pairing is concerned, I know for a fact that I'm not as productive as when I pair-programmed at Pivotal. We got some amazing results, just chugging through the feature list. The only problem is that I hated it.

I also know that I seem to be arguing for the "cowboy coder" style of development. These guys are a real pain to deal with on a team. But what if there's no team?

I know too that you'll hear this argument more frequently from members of my generation than the young pups who grew up on agile methods. All I can say is that I do tend to embrace the more leading-edge ideas - OOP in 1989, TDD in 2000, lean today. That's been the cause of many of my disagreements!

When it comes down to it, I believe that the only intelligent criterion for behavior is happiness. The only reason for a person to do something is because it makes them happy (in the long or short term).

The bottom line is that this way makes me happy.

FOLLOWUP: There are a couple of things I mentioned in the original post that might have been missed if you just read this one: 1) I think pair programming is a great way of doing software development (just not for me), and 2) Pivotal Labs is an awesome place to work.

Two modifiers in one statement (Ruby)

2010-12-04T16:32:00.000-08:00

I never tried this before, but I like it:

return if shows.empty? unless show_if_empty

Beware of RSpec's before :all

2010-11-23T11:53:00.000-08:00

When you add data in an RSpec before :all, it's not inside the transactions RSpec places around each test. rake spec clears the database before running all the specs, but the data created in before :all will hang around after it runs. This introduces an order dependency between specs. A spec that assumes the database (or one table) is empty will run fine if it runs before the before :all, but can fail if it runs after. Your specs can start failing just because you reorganized them, which changed their run order.

I've been bitten by this three or four times. The moral is to not create data in a before :all if other code assumes that data isn't there.

Code gets cut off in blog posts

2010-08-08T11:14:00.000-07:00

When you put code inside <pre><code> in a Blogger post, if it's too wide for its column, the excess just gets cut off. The solution is to use <pre style="overflow: auto;">.

The Hidden Meaning of Christmas?

2009-12-26T10:20:00.000-08:00

This video purports to show that stories of the birth and death of Jesus Christ were based on astronomical events. I was not convinced.

The first tip-off is when the narrator says "Sirius...on Dec 24th aligns with the three brightest stars in Orion's belt." Stars don't line up with each other on particular days of the year. They are fixed (for all intents and purposes). There's nothing special about Dec 24th. Also, the stars in Orion's Belt don't point directly to Sirius, as the video implies.

The narrator then says that Orion's Belt and Sirius point to the rising sun on that day. This is just not true. The image below shows the relation of these bodies at sunrise on Dec 24, 300AD (around the time when the Christmas myth was created) at Jerusalem. The image is not substantially different on Dec 25, or even in the year 2009.

Sirius and Orion's Belt on the right clearly point nowhere near the Sun on the left.

The other main inaccuracy of the video (which is in fact its entire point) is that on Dec 25 the Sun rises in Crux, the Southern Cross. Apart from the fact that Crux is hard to see from the Northern Hemisphere, the image shows that the Sun is nowhere near the Southern Cross (center) at that time.

Why I Don't Like Pair Programming (and Why I Left Pivotal)

2009-12-07T19:40:00.000-08:00

First, I want to say that I think pair programming is fine - for other people. Based on pairing fulltime for a month at Pivotal Labs, I've been exposed to both its good side and its bad side.

First, the good side. I think the production of good code with two people working together is greater than with two people working apart. It's not hugely greater. The pair has to generate twice as much code as one programmer just to break even. That's helped by the fact that pairing forces you to spend the day programming instead of goofing off.

But where pairing wins is the "good code" part. From my experience, stupid little bugs (which accounts for the great majority of bugs) are caught much more frequently at coding time. That's a big win.

I also think that there is way less "bad code" produced. "Bad code" can happen when someone makes the wrong design choice and spends time going down a rathole patching and fixing the code.

Those are the good parts of pair programming. I've no doubt left out others. Now for the bad parts.

When you pair program, you're effectively joined at the hip with your pair. You can't pair if only one of you is there. This means that you both come into work at the same time, you both take lunch at the same time, you both take breaks at the same time, and you both leave at the same time. The work is so concentrated that you work 8-hour days (which is good). But you can't take time off without affecting your pair. Working from home is possible, but it's obviously not as pairy as sitting beside one another. This is an aspect of pair programming I hadn't considered until I tried it.

You have to be able to think out loud - 8 hours a day. Then you have to type in code while someone is watching you. They'll catch your typos (hopefully after giving you a chance to spot them yourself) and they'll see when you're floundering for how to do something. This turned out to be my own personal biggest problem with pair programming. When I was at the keyboard, I got dumber. It could be simple nervousness, or it could be that gaps were being exposed in my knowledge - gaps I felt shouldn't exist. Either way, I was not comfortable, and I was definitely less productive than if I were on my own. This is a personal reaction. I don't consider it a failing of pair programming, but a failing of me.

I may have been able to work through this handicap. I certainly learned more in one day than in a whole week of solo programming. And there might have come a time when I was comfortable programming in front of other people. But there was an even bigger problem.

Pair programming doesn't encourage quiet reflection and exploration. You can't just sit back and read some code. You can't just sit and think. I mean, you can, but then your pair is just sitting there. If you both agree that such contemplation is necessary, that's fine, but what if your pair is perfectly happy with an existing way? You don't want to waste their time. You don't want to argue (unless the other person wants to as well). You give in more often than if you were working alone.

This can be a good thing. When each of you have veto power, that reduces the chance of bad design. However, I think it also reduces the chance of truly innovative design (unless you both agree to explore it).

An example might help. We needed to display a graph of the relationship between entities. The models contained the names of the entities and the names of their relationships. The graphing "little language" needed to be generated for each entity and relationship. My pair's idea was to give each model a method to generate the graphing code. I felt that graphing code was for viewing the models - not part of the models themselves. I proposed a Presenter to translate models into views. This certainly sounds more complicated than putting the code in the models, which is what what my pair wanted to do, and so that's what we did.

The design was perfectly workable, but it lead to its own complications as the work progressed. For example, when you click on a node, that node becomes selected. In order for the model to create the graphing code for it, it has to know which node is selected. This meant adding a 'selected_node' parameter to each call to the model graphing code. That wouldn't have been necessary using a Presenter who was in charge of graphing the model tree.

There were other small problems, and I believe more problems would be found as we worked with the code. The reason is because we were violating MVC.

I made this point to my pair (who was an extremely intelligent guy), but he disagreed, so we did without a Presenter. Big deal, right? But when you multiply that scenario by ten or twenty, you'll get some idea of my experience working with pair programming.

TDD? Well, we do it when it's easy. It's not worth testing views, after all. And what difference does it make whether you test before or after you write the code, anyway? Database normalization makes things too slow. MVC requires writing additional classes. Cucumber is only valuable when clients write features. Fixtures are faster than factories and mocking.

These were the sorts of issues that came up during my one month of pairing. And I lost on every point. That, to me, is the greatest drawback to pair programming (at least when I'm doing it). You just want to get the story done. Innovation can be stifled. Programming according to generally recognized principles is cast aside, as long as one of the pairs (especially the dominant one) "doesn't see the need" for it.

And that's the kind of stuff I'm good at. I reckon that 95% of my code over the last 10 years has been written in response to a failing test. I keep view code out of models (and vice versa). I program from the UI in, because I think what happens on the screen and the keyboard is the only truly important part of an application (everything else is implementation details). My database tables are in third normal form. I believe I write well-factored code that is simple because it puts responsibility in the right place. Of course, I know there are exceptions to every one of the preceding principles. But you start by doing it "right."

So that's why I don't like pair programming. My weaknesses are exaggerated and my strengths are vetoed. For me, pairing doesn't work. For plenty of others, it very clearly does work. But not me. And that's why I quit the best company I've ever worked for: Pivotal Labs.

Jane Eyre and feminism

2009-07-03T14:57:00.000-07:00

I read Jane Eyre recently. This was necessary because I'm reading Simon Callow's excellent biography of Orson Welles, and I'd got to the part where Welles appears in that movie. I had to see the movie before reading that section of the biography, and I had to read the book before seeing the movie. So it fit in well with my desire to enjoy some of these famous works as I get on in years. Call it a literary bucket list.

For most of the book, I found myself laughing at Jane and the rest of the characters. It's hard for me to imagine real people speaking and thinking in this way. I'd love to hear how they talk after the collective stick had been removed from their asses.

But at some point, I simply accepted the style, and I enjoyed the book far more. The plot was just as ridiculous, however. Mr Rochester goes from talking about marrying Blanche and sending Jane away to clasping her in his arms in the space of a paragraph or two. I never did understand the reason for or in fact any evidence of a transition in his intent. One sentence Blanche - next sentence Jane. We were all expecting it, of course, but it certainly made no sense.

Then there's the amazing coincidence of the house Jane stumbles upon, which just so happens to contain her nearest relatives. She's apparently half-dead by this time from exposure and hunger, but as near as I can tell, she was only away from a soft bed and a hot meal for about three days. Not very stern stuff, one feels.

But the reason I wanted to make this blog post was to react to the statement in the (modern) introduction that Jane Eyre is "one of the most intensely erotic books in the English language." First, it's good of the writer to concede that there are eroticer books in other languages (too bad she doesn't mention what they are, or I would by all means start a course of study in those languages). Second, what the fuck? It is impossible to imagine Jane even possessing a clitoris, much less any kind of erotic feeling.

The writer of the introduction is from feminist school of the 1980's. I am all for feminist schools. I consider myself a feminist and have done since the age of 12. I am so feminist, in fact, that I know that I'm sexist. But besides being erotic, this novel is, according to the writer of the introduction, a triumph of feminism and female power. How can it be, when all Jane does is serve and obey? True, she twice obeys her God over her male masters, but this is hardly empowerment. Throughout the book, Jane is either a slave or trying to become a slave.

I still enjoyed the book. The character was foreign enough to make her interesting. And I did read on, wondering what would happen next. As for the movie, it was fun to see Orson Welles play Mr Rochester. He certainly played the part in my imagination as I was reading the book.

And now I've moved on past that part in Callow's biography of Welles. Tonight I watch The Lady from Shanghai.

It's hard to make a game easy

2009-06-27T18:36:00.000-07:00

I'm just getting to the end of Prince of Persia. It's considered by gamers to be an easy game - too easy, some say. For me, it's just hard enough to make it rewarding but not so hard as to be frustrating.

The first computer game I ever played was Zork. Now there was a frustrating game. I spent literally hours getting nowhere, simply because I didn't use the right combination of words to get something to happen. That, of course, was the challenge of the game. It was a difficult puzzle to solve. It wasn't particularly fair, either. Logic took a back seat to obscurity sometimes. On the other hand, finding one of those obscure combinations of words was tremendously satisfying.

Another way games like this can be hard is to not permit escape from prior bad choices. You didn't pick up that item in the room you were in three weeks ago (in real time)? Too bad - now you're stuck. You have to go back to that point (if you even have a saved game from then) and do it all over. This is not fun by anyone's definition.

But both kinds of game design are easy for the designer. It's actually quite easy to make a game hard. What's hard is to make it easy.

Which is where Prince of Persia comes in. I don't have a lot of time for gaming. I spend perhaps an hour a day, and a few more on weekends. If I choose to stick out a game to the end, it's because it consistently gives me more fun than doing something else. Prince of Persia does that by having puzzles that are just hard enough to make me think (a little bit, at least), but allowing me the freedom to swing across vines without worrying about painting myself in a corner.

Of course, the game is famous for "not being able to die." If you fall off a ledge or get beaten in combat, your companion Elika saves you and you start again from a checkpoint that's usually not too far before the point when you died. Some would say that this isn't challenging enough - that there's not enough "penalty" for doing something wrong. Good! I don't play games to inflict pain on myself, and I don't like having to repeat a sequence of events over and over until I get it right. (This does happen in Prince of Persia, but it's nothing like one situation I was in in Halo 3, where I would spend at least a minute gathering weapons, spend another couple of minutes killing Brutes, die, lather, rinse, and repeat.)

But easy resurrection is just a part of it. Much harder, it seems to me, is the ability Prince of Persia gives you to follow paths wherever and whenever you want, without fear of being unable to get back to where you are. Although the game is essential a platformer, with narrowly-defined places you can go, there are usually at least two ways to get to every important place.

And doing this without making it obvious takes design skill. I suppose one could win the game merely by trying every path in every combination. But it doesn't seem that way. I really feel like I'm exploring, not just following a script.

Assertion as argument

2009-06-22T15:37:00.000-07:00

I saw a thread today in which someone asked whether they should add NilClass#to_s to return an empty string instead of raising an exception.

A well-respected member of the Rails community answered by talking about concatenating strings with +. He said

First off, don't do that. String#+ is generally the worst thing you can choose. Second [...]

I had to wonder whether that member would accept a statement like that himself. Don't we programmers tend to examine assumptions and reject arguments from authority?

What he could have said is "String#+ creates a new string by concatenating its argument, so if you're doing it thousands of times a second, it can create problems because of memory consumption. In ordinary practice, it makes no difference."

Discovering OOP

2009-06-21T10:33:00.000-07:00

Before I'd ever really heard of OOP, I was simulating polymorphism by using dispatch tables in structs. I'd define a struct for a listbox, e.g. This would have members for the size of the list, the width, the position on the screen, etc. There would also be a linked list of the items to display. I'd pass these structs around to functions that operated on them. I believe this was called module-based programming. The data was encapsulated in that only certain functions in a certain source file (or module) were allowed to operate on it. So far, so basic.

But sometimes, I'd want to have different functionality on a single listbox (or on a group of similar listboxes). For example, when the user selected an item, maybe I'd want to display information about that item somewhere else. So I'd define a function that was called by the main listbox code when an item was selected. But this function didn't belong with in the main listbox module, since it might be particular to only one application or even only to one screen. So I added a function pointer to the struct. The main listbox code would call that function if the pointer was nonnull. Different listbox clients could define their own functions to get the behavior they needed, without cluttering up the main listbox module.

This is essentially polymorphism - using indirection to select a function to execute at runtime, based on the inherent "nature" of the struct, rather than its incidental contents. Of course, there could be many such function pointers in the listbox struct. Today, we'd recognize this as a dispatch table, implemented in C++ to support virtual functions. But this was 1985, and I'd never heard of C++ or polymorphism. I just knew that I wanted to paramaterize this data structure not only with data, but with behavior. And it worked really well. (This is all obvious to anyone's who's programmed in the last 20 years).

However, the solution wasn't perfect. I eventually came to want to be able to further refine the behavior. I wanted one listbox to act just like another listbox, but also do something additional when an item was selected. This is where inheritance comes in. I ended up adding another function pointer for these cases, that pointed to the original function, and that I could call from the new function. The new function could call the old function before, during or after the new code, or could even completely ignore the old function altogether.

However, this solution never seemed as clean as the first solution of using dispatch tables for polymorphism. It was too obviously hacky having to maintain these chains of function pointers, and too easy to screw up and create bugs.

So imagine my delight when, soon after, I got a job with Sierra On-Line, then (1989) the most prominent adventure game company. They had actually created their own language, SCI, that was a very pure implementation of OOP. I'll never forget that first night reading the documentation on my bed and just being consumed with this language that did things I wanted to do and even things I didn't know I wanted it to do.

Ever since then, I've run into lots of people who talked about the difficulties of making the paradigm shift to OOP. But not me. It was love at first sight.

Listing the contents of your git stash

2009-05-04T16:32:00.000-07:00

I had a feeling there was something in my git stash that I'd forgotten to apply. But I couldn't figure out a simple way to list the contents of each of the stashes.

git stash list -p should work, I think, but it just lists one line for each stash, not the diff with the parent.

git stash show stash@{0} shows the contents of one stash, but I don't want to have to do that for each one in the list.

My coworker at Rupture, Rick Fletcher, came up with this, which works a treat:

git show $(git stash list | cut -d":" -f 1)

Rails MySQL adapter and tinytext

2009-04-22T16:53:00.001-07:00

Ruby on Rails's MySQL adapter doesn't grok the tinytext datatype. The following code will use that type when a text field with limit 255 is defined in schema.rb (which is what the adapter generates when it sees a tinytext in the database).

class ActiveRecord::ConnectionAdapters::MysqlAdapter
  original_type_to_sql = self.instance_method(:type_to_sql)
  define_method(:type_to_sql) do |*args|
    return 'tinytext' if args.first == :text && args.second == 255
    original_type_to_sql.bind(self).call(*args)
  end
end

Put this code in config/initializers/mysql_extensions.rb.

Going back to OS X

2008-12-14T17:56:00.001-08:00

I recently discovered that the ruby on my Mac was outdated. I had installed it from macports and never updated it.

It seems to me that if OS X comes with ruby, it should also take care of updating it when necessary, automatically, the same as it does with other software. So I nuked the macports version.

I also nuked all my ruby gems, which were installed somewhere under /opt/local. I've been gradually reinstalling them to /usr/local, where the gods of Unix intended them. I had trouble installing the mysql gem, however, and the various blog posts I'd seen about this related to macports.

The following command installed the gem:

sudo env ARCHFLAGS="-arch i386" gem install mysql -- --with-mysql-config=/usr/local/mysql/bin/mysql_config

QuitTime

2008-11-22T16:03:00.000-08:00

More for the vast historical significance than anything else, I hereby announce the start of a new project. QuitTime is a "quitmeter" that helps you quit smoking by showing you how many cigarettes you haven't smoked, how much money you've saved, and (theoretically, at least) how much longer you'll live as a result.

I wrote the Windows desktop version of QuitTime in 1997. It's still getting downloaded, over ten years later (mwilden.com/QuitTime). I'll say one thing for Windows, it does at least try to maintain backwards compatibility.

This version of QuitTime will be a Ruby on Rails web app. It's hard to imagine a simpler application. You tell it when you quit smoking (and a few other things) and it tells you how great you are.

For example, I quit a 3 1/2 pack a day habit (yes, really) in 2000. As of 2003, I'd not smoked 84,000 cigarettes and saved $15,000. I'd love to see those numbers as of 2008, but I'm on a Mac now.

Hence the plan to whip out a quick little application that will let me have some Rails fun, show me how great I am, and maybe help other people quit smoking, too.

Why do people...?

2008-11-22T15:59:00.000-08:00

Why do people post blog comments like "I'm going to try this out right away," or "I haven't used this yet, but it looks great!"

Why do they think anyone in hell cares what their personal plans and intentions are? Or is it just because they want to say something - anything - and that's all they got?

Appetite for Life, a biography of Julia Child

2008-11-14T21:30:00.000-08:00

Appetite for Life isn't terrible terrible, nor completely amateurish, self-indulgent, and scatter-brained, but it comes close. A book like this really makes you appreciate good old, everyday, professional writing. On one page, Theodore H. White is "Teddy;" on the next, he's "Theodore White." There must be a thousand people mentioned in the book, many of them including some completely Julia Child-free trivia about who their third cousin was and who he worked for. You've got to hand it to the author, Noel Riley Fitch, she's a good researcher. The trouble is that she doesn't seem very concerned with being interesting. It's like she took notes for five years then dumped it all down into the book. She loves using square brackets in quotations.

I know this isn't a very good review. But I just had to say something.

Undescribed code projects

2008-10-07T12:17:00.000-07:00

I'll never understand why some folks announce the newest release of their great software project - without once mentioning what it actually does. See http://continuousthinking.com/tags/arext for an example. I'll bet ar-extensions is a great tool, but I just don't feel like digging around to simply find out whether it does anything useful for me.

On the same note, why are there so many blogs that 1) Don't say who the author is, or 2) Don't say when the post was written, or 3) Both?

McCain

2008-07-24T15:18:00.001-07:00

John McCain wants to be thought of as a Maverick, but he's more like a Pinto.

Soundtrack Pro: "Could Not Create File" error when exporting

2008-06-01T10:34:00.000-07:00

I'm using Soundtrack Pro to digitize my collection of reel-to-reel mix tapes from the late '70s and early '80s. I edited each song out onto a different track, then tried to use File|Export to create .aif files and send them to iTunes to convert to MP3s and import into my library.

When I tried to do that, however, I got an error message "Could Not Create File", with the text "The export file could not be created. This may have occurred because there is insufficient disk space, or there might be a problem with the directory permissions." (The error monologue window had the single, inappropriate button: "OK". Clicking that button was a blatant lie; it was not OK.)

I had plenty of disk space and the file permissions were correct. I started over from scratch, and after I'd edited a few songs into tracks, I tested by exporting, and it worked. But when I finished editing out all the songs, I got the same error.

The problem? I had a / character in one of the track names ("Willin'/Don't Bogart That Joint" from a live Little Feat album - I told you this was late '70s-early '80s).

My Apple Discussions thread on digitizing tapes to MP3s, including this problem, is here.

Adding an existing Rails project to Vim

2008-05-11T08:59:00.000-07:00

It was a little unclear to me how to add an existing Rails project to the Vim Project plugin project file using the rails-vim plugin :Rproject command (if there's a less confusing way to state that, I don't know what it is!).

But it's pretty simple: just open any file in the project first "manually", then enter :Rproject.

Self-labelling debug output

2008-04-18T17:01:00.000-07:00

I probably should be embarrassed to admit it, but I often debug Rails code by inserting 'p' lines that dump the values of variables, e.g.:

a_variable = 2
p a_variable

That lets me see the value of a_variable in the console when I run the program. Sometimes there are a fair number of these lines, and sometimes it's hard to remember what value goes with what variable in the source. In these cases, I have to resort to

puts "a_variable = #{a_variable.inspect}"

That's not very DRY, and I knew Ruby must have a better way. I finally found it:

def l &block
 name = yield
 puts name + ' = ' + eval(name, block.binding).inspect
end

This lets me write

l{'a_variable'}

to get

a_variable = 2

Pretty small potatoes to experienced metaprogrammers out there, but I was pleased with myself. :)
///ark

When svn:ignore doesn't

2008-03-24T10:41:00.000-07:00

Ever since I started using Subversion, I've had trouble ignoring directories. Sometimes it works; other times it drives me mad.

In this particular case, I'm working with a Rails app, and I want to ignore the tmp folder and everything in it. So naturally, I do svn propedit svn:ignore . in the main directory, and edit the text file to include the line tmp. But sure as shootin', an svn status still shows ?'s for tmp/pids, etc. I can svn update and svn commit until I'm blue in the face, but those suckers just won't go away.

Some googling led me to the suspicion that perhaps tmp was already under version control (maybe it was accidentally added when it was empty). Ignores have no effect on already versioned files/directories. So I did svn rm tmp immediately followed by svn revert tmp, and all of a sudden, the ignore took effect.

There's a touch of cargo-culting in this solution (why didn't reverting put everything back to the old, undesirable state?) but I'm OK with that.

///ark

Importing video into iMovie to external disk

2008-03-20T16:03:00.000-07:00

In iMovie, you can't import video from your camera and save it to a Time Capsule. This is because Time Capsule is a shared disk. The Time Capsule simply won't appear in the "Save to:" dropdown.

Neither can you import to an NTFS-formatted disk (such as one you were using with Windows).

Since my internal MacBook Pro disk didn't have enough room, and because my external hard disk was NTFS, I was hoping to import video to my new Time Capsule. So I copied the 223GB that was on the external disk to Time Capsule, then reformatted the external.

To reformat the disk, I ran Disk Utility (in Applications/Utilities) and chose to "erase" the disk with the volume format "Mac OS (extended)". As explained here, journaling is not necessary for media disks, and will make their operation slower.

TextMate is the worst program that people love that I've ever used

2008-03-15T11:14:00.000-07:00

I really gave TextMate a good try. In fact, one of the main reasons I moved from Windows to the Mac was because I'd heard that TextMate was so great for Rails programming. Here's why I disagree:

You can't split a window, so you can't look at two files (like a model and its unit test) at the same time.

You can't bop back and forth between the current tab and the last one you were on with a keystroke.

Undo is at the character level, which makes using it an exercise in frustration as you hold down Cmd-Z forever, overshoot the change you wanted to undo, then hold down Shift-Ctrl-Z until you overshoot in the other direction, etc.

The project drawer is good, but a bug prevents you from removing items from it (you have to set up a regex filter).

You can't search a subset of a project's files.

These are some of the reasons I've gone back to vi - specifically MacVim. I'll keep posting as I think of more bad things with TextMate, because it satisifies me to do so for some reason.

There are good things about TextMate:

Cmd-T. I thought ReSharper in Visual Studio made it easy to open files, but Cmd-T is utterly awesome.

Moving text directly, without cutting and pasting. At first I thought this was just Mac-ish eye candy, but it really is a good, intuitive feature.

///ark

Mission accomplished

2008-01-14T16:59:00.001-08:00

After two years of looking for my first Ruby on Rails job, I finally got one today. I'm joining Twistage, a very small startup that sort of lets you do your own YouTube.

Zed

2008-01-01T19:36:00.000-08:00

http://www.zedshaw.com/rants/rails_is_a_ghetto.html

The predominant impression I had from Zed Shaw's rant was: What a loser. Of course, I'd never tell him that to his face, because he'd hit me. He's very concerned that people know this.

How many programmers are ever homeless? We make a jillion bucks!

Did I miss it, or did he actually say anything about Ruby on Rails? Seems to me it was all about the people he had it in for. The 400 restarts/day is ancient history.

I can't wait to read how Pickaxe killed Ruby.

Fun to read his opinion of some Thoughtworks programmers. Problem is, he thinks he's talking about the whole company.

///ark

Does Rails cache helpers?

2007-12-04T17:26:00.000-08:00

I'm testing a helper using Watir and it appears that Rails is caching the helper such that it's necessary to restart Mongrel to get Rails to take note of any changes to the helper. Leastways, that's the way it looks to me.

///ark

"Please select an open Rails project in the rails navigator"

2007-12-04T08:23:00.000-08:00

After selecting another project in Rails Navigator, then Go Into it, I got the error message "Please select an open Rails project in the rails navigator" when I tried to Run All Tests. The project clearly had the Rails nature, so the results I googled weren't applicable.

The solution was to open a test file and run it (Ctrl-X, U). Then Run All Tests worked.