Leopard memory woes...

I am in a state today. Out of necessity, I added a third GB of memory to my MacBook Pro last week because (IMHO) there is a memory issue in Leopard. This screenshot shows what has become the normal state of affairs memory-wise since I upgraded to Leopard.

Uploaded with plasq's Skitch!

I may find myself working away with the usual cadre of programs running on my desktop (Mail, Twhirl, iChat, Adium, Preview, Eclipse, iTerm, TextMate) and expect that a fair amount of system resources are being taken up. Fine. However, after shutting everything down I would expect that most of the memory occupied by the running programs is reclaimed by the OS and is available for reuse. That's definitely not the case. WTF is kernel_task doing with a quarter of a GB of memory? Why is Finder holding on to 80 MB?

I have been generally very happy with the Leopard upgrade. Feature-wise, it is an improvement on what was already a fantastically strong platform. However, efficient resource utilization is not an unreasonable expectation for a modern operating system and Leopard totally fails in this area.

Apps Daddy Likes...

I have been asked more than once by friends and associates about what applications I use or recommend for OSX. I am sure this is not an uncommon occurrence for folks who enjoy sharing the positive experiences they have had on the Apple platform. This morning I remembered a site I came across many months ago that allows people to track the applications they use (and I believe it also notifies you when updated versions of applications you use are available). For anyone interested in the applications I use, here is my profile. The site has a utility that rifles through your Applications folder and uploads everything it finds there. I then went through the list it uploaded to the site and selected the applications that I use daily (or at least frequently). The site has an RSS feed for my profile if you are interested.

JDK 6 Source/Documentation install on Leopard

Sadly, Alex Miller's instructions for getting Java source files for Java 5 didn't work for Java 6.  Apple has cleverly hidden the Java 6 source/docs on the ADC.

Many thanks to Eric Burke for knowing which nook this resource was hidden in.

Getting Eclipse to Run on Leopard (with Java6)

Over the weekend, I finally upgraded to Leopard. The upgrade experience was very good; it sucked my backup files (that I had created using SuperDuper) from my attached USB drive and created all the appropriate accounts. WIN! Apart from the impression that since the upgrade I am seeing greater memory consumption than what I saw with Tiger, the Leopard experience has been pleasant. Java 6 installed itself sometime after the upgrade, but it wasn't made the default JDK. Setting that was as easy as creating a symlink:

/System/Library/Frameworks/JavaVM.framework/Versions> ln -s 1.6 CurrentJDK

However, Eclipse wouldn't launch after making this change.

Uploaded with plasq's Skitch!

With Dean Wette's help, I was able to sort this out. I edited:

[eclipse_home]/Eclipse.app/Contents/MacOS/eclipse.ini

And added:

-vm
/System/Library/Frameworks/JavaVM.framework/Versions/1.5.0/Home/bin/java

Launching Eclipse now uses the 1.5 version of the Java executable, and everything works. While I was trying the above, I had it as '-vm=/System...', but this did not work. For some reason, the newline between -vm and the path was important.

A redneck poll

I had a debate with friends over the weekend about whether rednecks outnumbered non-rednecks in the United States, which unfortunately ended inconclusively. So in the interest of gathering more data, I would like to pose the question to anyone with an internet connection. The following is a two-part poll (asked as one two-part question because the free polling system I am using distinguishes between polls and surveys by the number of questions allowed and only polls - which are restricted to a single question and answer - are free and allow unlimited responses). Please answer according to your best judgement.

Screencasting...

Over the past year, I have been working (in my free time) on a screencasting site that is finally out there: http://screencastic.com. My intention for the site is to offer high-quality screencasts on par with the great stuff coming out of Railscasts.com, peepcode.com, and elsewhere. The initial content includes JRuby/Swing screencasts, one on the Cheri library for JRuby and the other on Monkeybars, though the site will add content over time in a lot of different technical topics.

Polyglot Heaven

With a "just go for it" attitude, Nate Neff and I took a road-trip on Thursday to attend the first Polyglot Programmers meeting at the Obtiva offices in Chicago's financial district. Well worth the trip! Dean Wampler gave a very evenly balanced and informative overview on the history and concepts of polyglot and poly-paradigm programming. He has made the slides for the talk publicly available (if you missed the talk, you can find an audio recording here).

I find the notion of polyglot programming very appealing because it aims to exploit the strengths of different development languages/technologies within a unifying architecture. Ola Bini has written several times about polyglot programming and layered architectures that leverage high-performance (typically statically-typed) languages for some parts and high-productivity (dynamic) languages for others, in an attempt to achieve the "best of both worlds". This idea makes a lot of sense to me, coupled with the "use the right tool for the job" strategy rather than the "use as many tools for the job" one.

In the talk, Dean gave examples of polyglot programs that are in wide use (I'm looking at you, Emacs), reinforcing the idea that this is not a new concept (even though it may be one that internet pontificators seem to be talking about at the moment). Considering that most web-applications fall into the polyglot category by virtue of their including CSS, HTML, XML, SQL, and Java/C#/ASP/PHP/Perl/Ruby/Groovy/Python/etc as parts of the same application, the idea that shifting our approach to organizing application architecture to (for example) throw Java or C# at the message queue processing portion of the application while utilizing a dynamic language of your choice to organize/control the components of the system, a glue (if you will), isn't radical at all. In fact, it seems quite natural (to me). Though my own preference these days is developing with Ruby, much respek to the clever folks in the Groovy camp for adopting the polyglot paradigm in the Grails architecture. Booyakasha! That same "leveraging strengths" goodness is what makes working on and with the Monkeybars framework so much fun.

The discussion among all attending after Dean's presentation was enjoyable, as was the great beer and Chicago-style pizza provided by our hosts, Dave Hoover, Joseph Leddy, Tyler Jennings, Renzo Borgatti and the rest of the Obtivians that I met that night.

Phun

The trifles that most of us call computer programming pale in comparison to the awesomeness that is Phun.

You can download the engine and waste your day by following this link.

Giles Bowkett: Why I Program In Ruby (And Maybe Why You Shouldn't)

Giles Bowkett: Why I Program In Ruby (And Maybe Why You Shouldn't)

Hooahh.

Rails Macro for JEdit

I have written a macro for JEdit that allows you to jump around from one related file to another in your Rails project. The behavior mimics some of the capability of the TextMate Rails bundle. This screencast shows the macro in action:

***Update - 07/04/08***
At long last I have finally decided to post this macro to a highly-available public repository. For the longest time, I have been hosting the zip file for this macro on my home network and many times the server was unavailable when someone needed it. No longer! You can download the macro from this github repo.

You'll want to copy the 'Rails' directory into your <home_dir>/.jedit/macros directory. You will need to have the Ruby and SideKick JEdit plugins as well as the "ruby" executable for your platform visible in the "path". This macro has been tested on Windows and Linux (OS X users will have to settle for TextMate ;-) ).

My Ruby Stub

Being new to Ruby, one of the first things I wanted to do was figure out how to apply the testing style I am comfortable with in Java.  Several years ago, Bob Lee and I wrote an IDEA plugin to generate stub-object source files from interface definitions.  For a given interface:

The stub generator would create a class that looks like:

The generated stubs are useful in testing because I can set them up with a return value or exception to simulate some condition that I am trying to test. The methods of the stub keep track of whether they were called and any parameters that were passed to them. This approach follows the state-based testing that Fowler describes, and is central to my own programming style.

In Ruby, the same kind of thing can be accomplished at runtime in a very dynamic way. This unit test demonstrates the kind of thing I am looking for in a stub generator:

The Ruby Stub implementation was tricky to figure out until I learned how to use define_method:

So in my first real foray into a Ruby utility, I was able to create something that does what I need and learn a little about the API in the process. Of course, after savoring the feeling of learning and having written something that I thought was cool, I had a closer look the Stubba API from the Mocha library and realized that I still had a long way to go. Still, the exercise was a useful one; the more I use Ruby the more I really like it.

STL RUG

Last night, I attended a meeting of the St. Louis Ruby User Group. I was impressed by the size of the turnout. There were easily 30 people there in the empty, nondescript office space. Though the space was crappy, it felt more community-like than the Java SIG that is held every month in the much nicer CityPlace auditorium. As well, the attendence at the few JavaSIGs I have been to in the last year has been comparitively anemic - though the Java "community" is much larger in St. Louis, it doesn't have the continuing interest that this group seems to. I think of it like a new relationship with a pretty girl - everything feels new and interesting and there are is a lot to learn and talk about. At this point, Java is the spouse the community has had a relationship with for a long time and we have covered so many things that new conversations are harder to come by.