All righty then. Recent silliness aside, things have been going on here. Big things; exciting[*] things.
- I've gotten a job
at Hypertext Solutions,
who are building a pretty nifty product. It's kind of disorienting
being dropped into a mostly-Java team since right now I know
more Javanese
than Java, but I'm getting up to speed. More and more Ruby is being
used day-to-day, so I'm finding that as the resident Ruby guru I'm
being asked almost as many Ruby-related questions as I'm asking
about crazy stuff like Tomcat and
(shudder)
Ant.
- I've also been recently rethinking the way things have been going
with Rinari, the Rails
environment for Emacs. I had a lot of grand visions shared with
some really
great
folks, but it seems that
there just isn't enough energy and effort to keep it alive. It's
also hard to get traction with new users.
Rinari appeals to Emacs veterans because it follows time-honored conventions and doesn't... go overboard, but someone new to Rails and Emacs is just going to go out there and search for 'Emacs for Rails' and come across rails.el instead. At first glance it seems more featureful, and newbies aren't put off by the ways it deviates from convention; they just see a lot of resulting inconsistency in Emacs as a whole as time goes on. On top of that, it makes it seem like mmm-mode was the best way to support ERB views, which is simply not the case any more.
It seems to me that a discouragingly high percentage of rinari users have just found about about it because they happened to be asking about how to get rails.el working while I was in #emacs, and I was able to direct them to Rinari. So: there's a definite mind-share problem on top of the "nobody has time to hack it" problem.
Anyway, to make a long story somewhat shorter, I decided that it'd be best to join forces with the rails.el team. I contacted them, and it turns out I'm really the only one who wants to actively develop it right now. So I got added to the committer list and started a separate branch to add in all the good Rinari stuff and remove all the stuff that IMHO is ill-advised. Key bindings stomp all over the place and require finger-contortions that would shoot chills down the spine of an ergonomicist. All that is on its way out in my new version, available here:
svn co svn: //rubyforge.org/emacs-rails/branches/rinari-merge
- That's not all the Emacs goodness in town; not by a long
shot. I've been having a lot of fun
with test-unit.el.
The basic idea is that rather than having tests run in a terminal,
(even a terminal within Emacs) you'd rather have them run in the
test buffer itself. With test-unit-mode, whenever you save the
tests, Emacs kicks off a subordinate process that runs them and then
will highlight the methods in the buffer based on the output. That
way you're instantly notified of any failure (faster than with
autotest even, though autotest has other advantages
to be sure), and the feedback loop is as short as possible.
There are still a few issues to work out. The trickiest thing is figuring out a heuristic for when to run which tests. This is a problem that autotest has more or less solved, so the thing to do could be to make test-unit-mode a frontend for autotest but use save-hooks to kick off autotest rather than polling directories every five seconds and have stuff highlighted if the buffer's open rather than just dumping output to the shell. I definitely have plenty more to do in this direction.
- On a similar note, Ryan Davis of Seattle.rb just released flog, a tool that analyzes the parse tree to let you know how much pain your code is in. Clearly this kind of information is also very useful to see live in your buffers to minimize breaks in your workflow, so I'm working on another library called flog.el that shows you the pain levels for your methods as you code them. Again there is room for improvements due to the fact that what I've got so far works only on a buffer-level rather than a project level, but it's definitely a start.
It's pretty cool to be up in the Northwest enjoying the greenery and the second-best city in the US for software work. Doesn't hurt that it's also the home of the most badass Ruby Brigade[**] in the country as well.
* For some value of "exciting".
๛