Pat Eyler has been asking some folks for their thoughts on the Merb/Rails merge. Basically, he’s putting the same three questions to a number of people, with interesting results.

He asked me, and has published my response.

BTW, the observation that adding Merb into Rails could mean that people will get to use Merb (or some form of it) while claiming to be doing Rails (and so avoiding the dread “but why use @foo? Why not Rails?” challenge) was copped from a post by David Koontz to the Phoenix Ruby User Group mailing list.

Now that JotBot has been released, I wanted to get more feedback for the application. I posted to Hacker News and solicited comments.

I have to say that I’m really pleased with the results. I’ve seen a jump in the number of people requesting trial keys; I can’t be sure (maybe Google Analytics can help me here) but I’m assuming the post prompted folks to try it out. So that’s good.

But the comments have been really useful. Not everyone is falling all over the app, of course. But there have been some good observations, some good questions about how JotBot works and how it effects the user.

I really appreciate the comments from Tony Wright of RescueTime. RescueTime was a Y Combinator startup, and I’ve been hearing good things about it ever since they launched.

Among other things, Tony’s comments made me realize that some may think of JotBot in terms of a productivity app, while others see it as a pro-active record-keeping tool. Hence, what works for some does not work for others, or work so well. (I, of course, secretly want it to be all things to all people. More realistically, I do not want to downplay its value as a productivity enhancer, but I do see how it differs from RescueTime and other “stealth” behavior tracking tools, and JotBot was born of a need to track activity details. Yes, it can make you more productive, but its “pull” model may be the wrong kind of disruption for some people. I just hope people try it before passing judgment)

Aside from Tony’s points, one comment really got me thinking: To use JotBot, you need a key, even for the free trial. For some, this is too much of an annoyance. Indeed, it would be much nicer if people could just download and run the app, while the time-limit still held. More thought needs to be given to that. I want it to be as painless as possible for people to see if JotBot works for them. On the other hand, I’m not a fan of crippleware or nagware. Suggestions welcome!

So, thanks again to the HN community. I’d love it if everyone who commented went and tried JotBot and then decided to buy it. But, no matter what, I’m really grateful that people take the time to offer their observations.

Happy Camper Studios has released what is, as best I can tell, the first commercial desktop application written in JRuby.

JotBot is time tracking done right. It aims to be minimally disruptive, but it uses a “pull” approach so that you don’t have to remember to go log your time. Instead, you get reminded at a configurable interval to record what you’ve been doing.

There’s a quick tour video on the JotBot home page that shows off most of the features and give you a feel for how it behaves.

I’m super proud of this release and the amazing work put in by my fellow campers, David Koontz and Logan Barnett.

You can read the back-story on the development process at David’s blog.

You can try JotBot for 30 days free, so give it a whirl.

His CV.

I forked the Monkeybars repo so I could safely experiment with some things. My repo is monkeybars-with-inline-ruby-swing and that’s pretty much it in a nutshell.

Often, when people talk about Monkeybars, they compare it to some other similar tool that uses inline code (often using a “builder”-style syntax) to define the UI. The typical Monkeybars demo, in contrast, shows the use of WYSIWYG UI editor to create a binary Java Swing class; this file is then used in the Monkeybars app.

Not surprisingly, showing how this is done can take some time, even for a basic Hello, World! demo app. The sad truth of conference talks and demos is that you can get screwed from both ends in trying to properly explain anything non-trivial. You want to point out the details (because your tool is powerful), but that eats up the limited time available. You also want to actually show something, ideally something complete, so you end up with something simplistic.

If done well, then everyone gets the point: robust, sophisticated tool presented in overly-simplistic app for demonstration purposes. However, you can often end up with people seeing it the other way: lots of detailed steps needed to get to skimpy results. What’s then not grasped (or not well explained) is that the details are there to convey the breadth of possibilities; the skimpy app is there to simply demonstrate that this is something real. You still have to apply some imagination to understand the implications for larger, far more complex applications by extrapolation.

Demos using hand-written code to define a GUI have a real edge here because the speaker never has to leave the code editor, never has to switch views or tools, never has to explain much more than “here’s some more Ruby.” What’s often not mentioned, though, is that the inline-style of GUI definition does not scale well beyond the typical demo program. What you see really is what your get. (Trust me; I would not want to have to work on JotBot hand-coding the UI.)

Of course, maybe you don’t want much more than a handful of buttons and some text fields. Maybe all you want is the desktop equivalent of HTML 3.2.

Sometimes that’s all I need for given screen in some larger app, and having Monkeybars provide this would make it that much sweeter. Best would be that it would not alter how one uses the full power of the library.

So here’s what my fork of Monkeybars adds:

• Some code to the base View class to aid in detecting when the Swing UI class is in fact created via Ruby, so that the appropriate reflection/meta-programming can be done
• An additional app generator that gives you an MVC tuple, with a basic view UI class, written in Ruby, in place.

Because I’m interested in getting people to play with this, I renamed the key files from monkeybars to jimpanzee. Now if you install the code as a gem you won’t stomp on any existing Monkeybars installation. (The code should be completely compatible with the current actual Monkeybars API, but the renaming is cleaner.)

With jimpanzee, you can do this:

james@james06:~/tmp$ jimpanzee MyCoolApp :demo
Creating directory MyCoolApp
Copying jimpanzee project structure
Creating  default code for MyCoolApp ...

Final steps:

  1. Place a copy of jruby-complete.jar in the MyCoolApp/lib/java directory
  2. cd into the MyCoolApp/src directory
  3. Run the code using jruby:

       jruby main.rb

Happy hacking!

and if you follow those final instructions you’ll have a simple cross-platform GUI app running. Toss in rawr and you’re three steps away from having redistributable executables ready.

You can see it here (except for the Rawr part):

There’s more to be done, not the least of which is ensuring that my approach is robust. The generator needs improvement; it’s pretty brain-dead. (For example, :demo is a hard-coded flag for the generator code, and you can’t tell it what to name the generated tuple. But these are not difficult things to change. The real issue is what to change them to.)

There’s a certain “gee whiz” factor in this, because there’s a low limit on what such generators can buy you, and how much inline UI code you’ll want, but the flip side is that it does lower the barrier to entry, and it is of practical value when coupled with Monkeybars’ other killer features. The best part is that it is in addition to, not in place of, all the power the best GUI toolkit offers for creating robust GUI apps of all shapes and sizes.

Please keep in mind when you see any demo that looks a bit too good or too easy that maybe the cool comes with a cost. The most common is that what makes some things easy ends up making other things hard. Always try to ask the presenter what the limits are, if a tool will grow with you if the size your application expands, or if will you find yourself stuck once the gee whiz has worn off.

Whatever tools you pick, consider the long view.

That’s not actual code; I made that up.

Here’s something not made up: Stellar talent Daniel Davis has challenged me to present seven random facts about myself.

I’m not a fan of anything that smacks of a chain-letter, but Daniel rules so I’ll at least spew out some unneeded detail. (But I won’t be inflicting this on on seven other people. Feel free to take up the challenge on your own if you feel so inclined.)

0. Favorite color: Plaid
1. Born and raised on an island
2. First cat was named George Sand
3. First 45 RPM vinyl single bought: Frankenstein by Edgar Winter Group
4. Learned FORTRAN in college by coding cellular automata for a semester. Still do not understand how I passed the Numerical Analysis with FORTRAN course since, oddly enough, CA were not on any test or assignment.
5. Have never skied
6. Favorite movie is Metropolis, unless it’s Citizen Kane or Animal House

RubyConf2008 videos are now going up.

First one you should watch: David’s talk on Monkeybars: easy cross platform GUIs. Learn about making commercial desktop apps in Ruby.

Monkeybars means Ruby GUI apps done right.

Some people write to say what they believe. I write to see what I believe.

It’s the difference between creative acts to express yourself, v. creative acts to explore and provoke yourself.

Self-expression tends to be pretty tedious all around, but self-exploration (leading to self-invention) is essential.

MountainWest RubyConf, among the most super cool awesome Ruby gatherings around, is looking for sponsors for the 2009 event in Salt Lake City, UT.

You can read the prospectus here. (PDF)

If you or your company is looking to support the Ruby community, and get some solid advertising in front of some of the best geeks in the world, this is for you.

If you know someone or some company who would be interested in sponsoring the conference, please pass this information on.

There’s a nice write-up about recent events at Ruby Manor that describes a talk involving Monkeybars.

I want add a few comments. First, while it is true that using JRuby means some gems do not work, the upside is that you have at your disposal the hojillion¹ Java libraries. While it is a goal that all Ruby code, gem or not, work with JRuby (with some caveats about native code), the ability to call into Java libs is a major win. The post mentions that a particualr gem for using Twitter could not be used; I’m fairly sure this is the exact situation Logan Barnett encountered when he started on Twit-and-Twitter for the Java One Script Bowl.

Logan was able to use a Java lib for Twitter, one that (as I recall) offered a more robust API. Big win. So, not to diminish the problem JRuby may have with certain gems, but there are two ways of looking at this: Some gems don’t run (glass 99/100 empty), vs. full use of Java libs (glass overflowing onto the floor and out the door).

Second, Monkeybars was compared (so to speak) with Shoes. No mention was made of Shoes having stability issues (something I’ve seen for myself), but even were it rock-solid there is no way one would want to build a serious app of any complexity. (To fair, I don’t think Shoes was created for that purpose, though some enthusiasts mistake the ease of use as demonstrated in demo apps as something that scales to commercial-grade desktop applications. If and when there is a WYSIWYG editor for Shoes that might change.) I’m deeply skeptical that, for example, JotBot could have been made in Shoes, if only because of the lack of sophisticated components.

However, for those who really REALLY want to build GUI apps that way, good news: Work is afoot to add this to Monkeybars. We hope before too long to allow Monkeybars to offer the best of both worlds.

---

¹ This is a really big number. Really. Big.

With king of the hill Rails chugging along, and up-and-comer Merb picking up steam, why bother with Ramaze?

The number one thing that makes Ramaze stand out from the crowd is that you write very little code and you write it all yourself. No generators.

...

Before Rails, people wrote lots and lots of code when making a web app, and they did it over and over as they did web app after web app. With each new app, they would spend time “ramping up” with just the base application before they got into the real meat of the matter, the core functionality which varied from client to client, application to application. Rails and Merb and their ilk try to make your life easier by generating this “lots and lots of code” for you, so you don’t have to spend time repeating the motions of getting the skeleton of your application coded.

Ramaze takes a different approach. It asks: How about we dump the “lots and lots of code” part altogether? This way, you get the benefit of nearly nil ramp up time, without the gaping jaw effect that hits you after you run a code generator script and sit staring at the big filetree that just sprouted out of the ground (think Jack and the Beanstalk).

Ramaze by Example

Just came across this post by Lyle Johnson, where he describes his attempts to catch a talk, and subsequent video, at RubyConf.

He was, as I bet 99% of conference attendees (myself included) were, unaware that not all talks at RubyConf would be recorded. Speakers have the option of preventing their talks from being videoed. On refection this seems to make some sense; not everyone is comfortable with live recordings (ask Chris Matthieu ; he’s asked to record my presentations at the Phoenix Ruby User group a number of times, and I always decline. I ramble.)

However, it never occurred to me at this recent RubyConf that talks would not be available; I assumed all talks were recorded as a matter of agreement with being a speaker. So I felt OK with missing one or another talk on the belief that I could catch the replay.

It’s interesting to note the reason given for not allowing the recording in question. It wasn’t discomfort; it was a desire to drive traffic to a for-pay version. That’s not a bad idea, and certainly, as Lyle points out, people should be able to find compensation for their efforts. However, this leads me to two thoughts.

First, every conference that allows speakers to opt out of being recorded should have those decisions made well enough in advance that it can be clearly stated on the schedule distributed at the conference. People attending a conference should know ahead of time if a talk will be available on video or not.

Second, all speakers should give serious consideration to not allowing their talks to be recorded, and plan on making their own, more polished version. And see if they can get a few bucks for it in the process. Oh, and if you don’t tell people in advance that you’ll be making a video available later, you might be able to drive up attendance at your talk. A big win all around, no? Well, maybe for the speakers, perhaps less so for the poor schlubs paying the conference fee and struggling to catch all the talks.

So now I have a third thought: Do not make recording optional. Make it a condition of being allowed to speak. Speaking at a Ruby conference should be seen as a privilege. I understand the opportunity value for hawking one’s products or services (and JotBot was given a plug at David’s talk), but the talk itself should not be the product. BTW, this is not a matter of OSS zealotry, but a matter of deciding what conference policies work best for the communities they serve.

(Possible 4th thought: Disallow video opt-out, and ensure that all attendees get the full videos, but allow opt-out of public video distribution. When I spoke at the first MtWest RubyConf, I was asked to sign a release form for the video of my talk. The original paperwork was pretty vague, and I insisted on explicit wording saying that the video was to be released under a Creative Commons license. It might be workable to allow speakers to select among licenses for distribution outside of conference attendees such that speakers still had an opportunity to sell (or not) a version of their talk to those who did not attend the conference. Not what I’d really like to see, though.)

Addendum

I’m fortunate to be part of the MountainWest RubyConf advisory team. The issue of video recording speakers was raised for discussion, and it was agreed that all speakers, as part of accepting an invitation to present, must agree to being recorded and having that recording made freely available under a Creative Commons license. I expect that the conference Web site will be updated with this info before too long, and it will be made clear to all speakers who are selected for the conference.

I have, of course, been doing much work with JRuby. Most of this has been desktop development with Monkeybars but occasionally I need to do some Web work.

I’m a big fan of Ramaze, mainly because it approaches that sweet spot of strong features with minimum magic. A recent Web app needed to use some Java libraries, and since Ramaze runs fine under JRuby I set out building the site.

I really wanted to deploy to Glassfish as well. Warbler is a terrific gem from Nick Sieger that will bundle up your Rack-based app, including any specified gems, and create a WAR file that can be deployed to a Java app server.

Last time (about a month or so ago) I tried this with a Ramaze app, I was not too successful. Since my application did not have much of a UI to it I opted to write a sparse Rack app instead.

However, my needs changed and I found myself starting to add assorted framework-y features, such as routing and templating, to the site. Rather than reinvent these particular wheels I thought to give Ramaze another shot. Having had to do some amount of trial-and-error experimentation to get even my simple Rack app running smoothly I figure perhaps my earlier frustration with Ramaze was because of my Warbler ignorance.

My renewed attempt didn’t start off so well, but I saw that my JRuby install of Ramaze was bit out of date, so I updated the gem. It looked as though something has been changed in the how Ramaze is dispatching requests because my ealrier errors vanished after the gem update.

A little tweaking of config.ru and config/warble.rb, and presto, it worked.

You can create a bare-bones Ramaze app by running the generator:

$ ramaze --create myapp

This gives you (among other things) start.ru and start.rb.

I renamed start.ru to config.ru and, in config.ru, replaced the require 'start' with most of the contents of start.rb. Here’s what it looks like:

require 'rubygems'
require 'ramaze'

require './controller/init'
require './model/init'

Ramaze.trait[:essentials].delete Ramaze::Adapter
Ramaze.start!
run Ramaze::Adapter::Base

When you start out to warbleize your app, you run (assuming you have already create a config/ directory):

$ warble config

and you get config/warbler.rb. That file is, by default, full of stuff your Ramaze app doesn’t need. Here’s my warble.rb:

Warbler::Config.new do |config|
    config.dirs = %w( controller model  public view)
    config.gems = %w( ramaze )
end

I then ran

$ jruby -S warble

and copied the resulting WAR file to the glassfish autodeploy dir.

And it Just Worked.

I expect no problems adding in my own libraries and the use of a database with an ORM. My first warbled Rack app was doing all that (Sequel with MySQL), and given that Ramaze is loaded and running and handling requests then adding that in should be a non-issue.

Now we can use Ruby’s most elegant Web framework with the fastest Ruby implementation and a robust, full-featured Web application management tool.

MountainWest RubyConf 2009 will be held March 13-14, 2009, in Salt Lake City, Utah, USA.

Proposals to speak at this regional conference are now being accepted. Please send your proposal to proposals@mtnwestrubyconf.org.

The submission deadline is midnight (MST) on December 31st, 2008.

The current plan is that presentations will be a mix of 30 and 45 minutes in length, including any Q+A period. So if you’re planning a talk keep that in mind.

There are sponsorship opportunities available as well. Please contact sponsorship@mtnwestruby.org if you are interested.

Please see mtnwestrubyconf.org for more details as they become available.

Legalize freedom.

Vote Libertarian.