You see, Brian's JRuby example was ported directly from the original how-to screencast created by David Heinemeier Hansson, the creator of Rails. The techniques in the screencast were state-of-the-art back then, but a lot has changed in the two-plus years since it first hit the internet.
One of the major changes is that Rails now prefers Mongrel as its application server. The script that starts the server (script/server) looks for an installation of Mongrel first, then for LigHTTPD to serve a Rails app. If neither of those is available on your system, Rails will fall back to using WEBrick, which comes bundled with Ruby. WEBrick works great for local development and testing, but it's not suitable for use in production. So using WEBrick for development can lead to one of two problems:
So ideally I would like to be able to make NetBeans aware of Mongrel, since it doesn't come as one of the bundled gems in the Ruby Feature. And that's where the fun starts.
NetBeans thoughtfully provides an interface for managing my Ruby Gems (at Tools/Ruby Gem Manager). Once there I click on "Install New...", wait for the "Available Gems:" area to populate, scroll down to the entry for mongrel, select it, and click Install. On the "Gem Installation Settings" screen I accept the defaults (install the latest version of the gem and include dependencies) and click OK. Which brings me to:
Showstopper #1
Mongrel, like many other gems out there in RubyLand asks (actually, requires) me to select a specific gem for my version and platform. Unfortunately, the NetBeans interface does not (currently) allow me to interact with the gem install process, so I'm stuck. By the way, philosophically I consider this a flaw in the gem installation process, not in the NetBeans interface. I don't like having to make this input on the command line either. But since this mechanism isn't likely to change soon, it's unfortunately up to the NetBeans team to provide an interface to it. Which I know is on their List of Things To Do.
Back to installing mongrel. As it happens I'm used to manually installing my gems anyway, so it shouldn't be too much trouble for me to locate the NetBeans gem repository and install mongrel by hand. I just need to know where the 'gem' command lives relative to my NetBeans/JRuby installation. It happens that there's a setting for this, under Preferences.../Miscellaneous/Ruby Installation. On my machine (running Mac OS X), the major executables live in the ~/.netbeans/dev/jruby-0.9.8/bin/ directory. A quick inspection of this directory verifies that the 'gem' command lives there too. So I just need to define a JRUBY_HOME that points to that jruby directory, and add $JRUBY_HOME/bin to the front of my PATH.
(Note to Windows users: Sorry for all the Mac/Unix-isms. All of this stuff is directly analogous to setting environment variables via the usual Control Panel/System/Advanced dance that you get to do. Hopefully you're used enough to it by now that you can just figure it out.)
Now with my PATH set properly I can do 'gem install -y mongrel' by hand. I get the same list of options, and I respond by selecting the latest and greatest. Which brings me to:
Showstopper #2
Mongrel, like a bunch of other "Ruby" gems actually requires access to native C libraries, which get built as part of the installation process. Which causes the JRuby gem installer to fail miserably. Bummer. To make things worse, according to the JRuby FAQ, native library access will never be available from JRuby. Double bummer.
The punch line? No Mongrel on JRuby, at least until someone implements the C-specific stuff in either Java or Ruby (or JRuby, I guess). The good news is that some gem providers are starting to re-work their gems and provide JRuby-capable versions for them.
The other good news is I can still use good old WEBrick in JRuby. It's not the end of the world. But it'll sure be nice to have access to Mongrel, whenever that happens. And the install-gems-by-hand trick works nicely for gems that don't involve native libraries. Try it with 'gem install gem_plugin' if you need proof. The only downside is that the NetBeans Ruby Gem Manager doesn't become aware of any hand-installed gems until you restart. Again, this is more of a nuisance than an actual hindrance.
]]>
Just
click this link and you'll read a tale,
A tale of a fateful slip
For Java geeks who went to work aboard an old cruise ship.
The goal was a mighty savings plan --
To make their jobs secure,
They'd give up pay and sail away
For an entrepreneur.
(An entrepreneur.)
Employers here have found it rough
To overseas the cost.
If not for the virtues of this simple plan,
More money could be lost.
(More money could be lost!)
This ship sets sail and it drops its anchor once it's gone three miles
With Java geeks, (doo doo doot doot doot!)
A doctor too, (doo doo doo doo doo doo doo!)
A laundry room
And some booze.
Ten hours a day
Gets you one point eight grand a month.
How could anyone lose?
]]>
Computer programs for playing chess have long been a subject of research in the field of Artificial Intelligence. Quality strategies and algorithms for automated chess playing are rightly seen as a hallmark of programming prowess and computational ability, since a brute force approach, while technically feasible now more than ever, can still be overcome by a sufficiently skilled human player.
Advanced Chess aims to combine the best of both worlds -- the sheer computational ability of the computer providing an exhaustive analysis of the quality of individual moves, and the innate strategic and reasoning ability of the human mind providing the guidance and overarching tactical selection of moves. Oddly, it seems that this combination creates a symbiosis that results in a team that plays better chess than either of its component members. According to the article, human players that are stronger than their teammate-program get stronger still. Human players that are weaker than their teammate-program end up playing better than the program would on its own.
This is a fascinating subject in its own right, but it also raises interesting questions of what exactly we're trying to accomplish with our use of computers in the enterprise. I think we tend to use the computer more as a slave than as a partner. What if we approached the development of web applications (or applications in general) as the development of "brain partners", facilitators that could be designed to augment the natural inner workings of our brains, shoring up the weaker areas and playing to our strengths? What would be a natural way of expressing such programs that would take advantage of the strengths of both sides?
We already do this, in some problem domains. Modern-day weather forecasting relies on sophisticated computer simulation of the elements that shape our climates. Stock traders use similar analytical tools that help inform their decisions of when and what to sell. Military fighter pilots as we know them today could not function without GPS and HUD and other computer-intensive aids.
What about our Java apps (had to work in a Java reference in here somewhere)? Do they facilitate, or do they impede? How can we make them do a better job of partnering? Is Java even a good language for the task? What about the alternatives like Python and Ruby? Is any existing computer language up to the task?
Enquiring minds want to know...
]]>Yes, I know he's talking about Ruby, as well as unit testing, two topics that are pretty much guaranteed to raise the ire of some of the regulars on this site. After all, we're supposed to be about Java right? Java, Java, Java! And Unit Testing? Please. That is sooo 2003!
Well, it seems to me that the technique Mike is using to learn Ruby could be applied to any language, including Java. You might even call it "Test Driven Learning", if it weren't for the unfortunate fact that the phrase "Test Driven" in front of anything is sure to send the zealots (pro and anti) into a fruitless frenzy of name-calling and acrimony. And it's not really about unit testing; it just happens that Ruby has a built-in unit testing framework that makes it easy to setup and run these kinds of tests.
The principle behind all of this is very similar to "Exploration Tests", an idea that Stuart Halloway has been talking about for a few years now. Exploration tests aren't meant to be as robust or foolproof as unit tests. In a way, they're complementary -- they don't tell you what to expect in the future, they tell you what you've already learned (or are in the process of learning). They don't tell you how the system should behave, they tell you how it does behave.
Most importantly, they give you a way to learn the way your brain is built to learn, by experimentation. For more (and better) information on this topic, take a look at Kathy Sierra's blog, and particularly this post about just-in-time learning versus just-in-case learning.This technique is the moral equivalent of hauling out your chemistry set and mixing chemicals together at random, just to see what happens. Or focusing your magnifying glass on that pile of dead leaves. Or adjusting the angle of the ramp to see if it helps you jump your bicycle over your brother, your sister, and three of your friends. [P.S.: Yes, these are actual childhood experiences. No, I am not necessarily proud of them. I blame my parents for giving me too much unstructured time.]
So take a little time to think of some ways you can express some knowledge and/or curiosity about Java in the form of a test. Think of an API you're not quite sure about and go make yourself sure about it. And know that you'll be able to save that snippet of knowledge so you can come back to it later and verify it at will. Now that's an activity worth investing some time and effort into. ]]>public class MyIncredibleClass implements Runnable {
public void run() {
try {
doSomethingBrilliant();
} catch (UnthinkableException neverGonnaHappen) {
respondAuthoritativelyAnyway();
}
}
// etc.
}
blah, blah, blah; L R1,$1000; SLL R1,2; ST R1,$1000; NOP; NOP; NOP; blah, blah, blah,...
Then, just for fun, they unleash their Web Tools Platform on an unsuspecting (yet hopefully appreciative) world. It seems unjust to call this thing a 'plugin' -- it's an uber-plugin. The main bundle is about 55MB, which is almost as big as the Eclipse 2.1 SDK release was. (Remember Eclipse 2? Ah, the good ol' days! ) Eclipse 3 isn't quite 90MB. So this is a massive contribution.
What do you get in exchange for tying up your bandwidth for a 50+ MB download? I was just looking for a good, free JSP syntax-coloring plugin. The WTP provides that and a whole lot more. See the above-referenced website for all the details.
The Getting Started document will help you, well, get started. It has a full list of the plugins you'll need to install before installing the WTP. Installing any plugin to Eclipse is pretty easy -- unzip the plugin, copy everything from the 'features' directory into your Eclipse installation features directory, do the same for the 'plugins' directory, restart Eclipse, and you're good to go.
There is a small gotcha here -- Eclipse 3.0 caches plugin information to provide quicker startup. To make sure it picks up the new plugin(s), you need to start Eclipse with an argument of '-clean'; this tells Eclipse to flush its plugin cache and load everything fresh this time. This is detailed in section 2.2 of the Getting Started document.
Here's a rare example of a thing that's more complicated on the Mac than it is in Windows. In Windows, you right-click on the Eclipse executable and add the '-clean' option to the command in the 'Target' input field. Apply your changes, run the executable, and you're done. Not so the Mac.
On the Macintosh, the executable (Eclipse.app) is really a package -- a bundle of executable and resources that's actually an integrated directory structure. This bundle structure is what makes it pretty easy to plop an application down anywhere on your filesystem and not have to worry about a central registry or any arbitrary restrictions on where executables can live. You can even move it around and be pretty sure of not breaking anything. Try that on a Windows machine!
So, in order to set the '-clean' option for Eclipse on the Mac, here's what you do:
You can use this sequence to modify the command-line arguments to any Java executable on the Mac that's bundled as an application.
I'm posting this entry from a Windows machine, so I don't have access to screenshots at the moment. If anyone thinks it'd be helpful, I'll try to update later with some images.
]]>The API is strictly RESTful (sorry, SOAP fans), so it's fairly easy on the eyes. The site is missing some important documentation as of this writing (e.g., a list of valid "metadata abbreviations" for making specific category queries), but the maintainers seem responsive and eager to please. There is a minimal set of examples to get you started.
The largest problem I can see so far? Not a single example is written in Java! Perl -- yes. PHP -- yes. VBScript -- yes. Java -- no. Sounds like a challenge to me. Who will accept?
The coolest thing about this for me is that I can finally write the app I've been hoping the Safari team would write for me -- a waitlist manager. You see, I try keep my bookshelf chock full, no empty slots. I always have a book I can remove, but I try not to until one comes along that I just have to read now. This app will help me track the books that I don't have to read today, but would like to keep in mind as a potential leisure read later.
What a great time to be a geek!
]]>Jerry Seinfeld talks in his stand-up routine about a survey that claims the number one fear of Americans is "public speaking". Number two is "death". His conclusion is that at a funeral, more people would rather be in the casket than delivering the eulogy. He may be right. I've seen perfectly normal human beings, people who can laugh and crack jokes and speak in full sentences at, say, lunch time, turn into stammering sweat-machines when standing in front of a group of people talking about their latest project.
It doesn't have to be this way. With a little practice, you too can stand proudly at the podium while delivering that eulogy, not crawl into the casket. Unless your presentation totally bombs, in which case be my guest.
Here's a small sampling of tips that can help you on your journey from Gibbering Mass to Zen Speaking Master:
1. Take a class.
Your local community college probably offers a class or two in public speaking. An "Intro to Acting" type of course would give you a solid grounding in the elements of stage presence. For those who can't make that kind of time commitment, another good resource is Toastmasters International. Lots of companies sponsor (or at least tolerate) Toastmasters clubs. If yours does, you can lunch-hour your way to a happier, less-sweaty, public-speaking you.
2. Organize your thoughts.
Think of your presentation as a little five-minute story -- give it a beginning, a middle, and an end. Jot down an outline of the key points. You don't have to (nor should you) write down the entire text of your presentation, to be read verbatim when the time comes. Chances are you're developing some slides to display -- if so, they can serve as your outline. However...
3. Never, ever simply read your slides bullet-for-bullet.
Ever. The medium is not the message. Your slides should be for us what they were for you -- an outline, providing enough visual cues to help us keep track of where you are in your talk. Here's another way to think of it -- you went through all the trouble to write those slides -- let us go through the trouble of reading them. Then you can show us how brilliant you are by amplifying on them.
Speaking of slides -- have someone proof-read your slides. This does not mean run spell-check in PowerPoint. It means get a living, breathing human being to read them, preferably that obnoxious guy in your office who grades all the memos that come across his desk. In red pen. (In my office, that obnoxious guy would be me). Trust me, you'd rather suffer his (relatively) private ridicule than broadcast your typos, misspellings, and questionable grammar to the Board of Directors.
4. Pretend to be someone else.
Sounds silly, I know, but it's surprisingly effective. I have a friend who will not sing a solo at our church, but when I cast him as Linus in "You're a Good Man, Charlie Brown" he was turning cartwheels and waltzing with a blanket. Oh, and singing solo. Any kind of performing can be less threatening if it's "not really you" up there.
5. Observe other speakers.
Learn good technique from people who practice good technique. One of the best places I've found to do this is at a No Fluff, Just Stuff Software Symposium. I'm always impressed (with some minor exceptions) with just how good these uber-geeks are at speaking. And yet they're geeks! So you know it can be done.
Now get out there and do it!
]]>In keeping with recent developments in the Java article-writing space, here's my take on a folksy, hyper-extended, EJB-tweaking metaphor (thanks to Bruce Tate and his People of the Elephant for the inspiration; I hope the rumors of a major movie deal all turn out to be true).
When I was a kid, the local network affiliate aired "The Bugs Bunny/Road Runner show" for three whole hours every Saturday morning. I would no sooner miss a minute of this show than I would donate half of my Halloween candy to my brother. Of course, it meant having to get up at the ungodly hour of 7:30 to get ready, but this was Bugs Bunny. No sacrifice was too great. Getting ready consisted mostly of showering hastily, dressing sloppily, pouring my first bowl of over-sugared, turn-the-milk-chocolate cereal (adding sugar as necessary), and staking out my territory in front of the TV.
Then, at 8:00, it happened: that wonderful theme song ("Overture, dim the lights, ..."), followed by the first of dozens of cartoons that I could pretty much recite from memory. If I'd had any artistic talent whatsoever, I probably could have drawn out detailed storyboards as well. Now that I'm a parent, I look back on this time in my life with appalled fascination and wonder what (if anything) my parents were thinking by permitting this weekly ritual that had no redeeming value whatsoever.
And yet, having made the deliberate effort to relate this particular childhood experience to EJB programming (don't try this at home), I think a case could be made that it did have some redeeming value. As it turns out, I did learn a few things from watching Bugs, Daffy, and friends. To wit:
1. Leave the singing frog alone.
You remember this one: man finds frog, frog starts singing, man sees dollar signs, frog stops singing whenever anyone else is around, man doesn't give up, man's life is ruined. All this without a single word of dialogue (except the frog's singing, which is actually pretty good). Ever feel like EJB is singing a song that no one else can hear?
Even if they could hear it, consider this:
2. The Road Runner is probably not worth the effort.
Poor Wile E. Coyote. Endlessly resourceful, ever in hot pursuit, yet he never manages to catch the darn bird. But what if he did? Would the sustenance he received from that scrawny framework (er, "frame") justify the expenditure of energy required to achieve it?
And, speaking of good ol' Wile E.:
3. ACME = CRAP.
Wile E. Coyote must have had really good credit (or a sizable trust fund). Rocket-powered skates, flying batsuit, instant holes; all supplied by ACME, all consistently and hilariously ineffective. Mostly they ended up getting W.E.C. folded, spindled, mutilated, blown up, or crushed by something heavy. Further proof that vendor lock-in can be A Bad Thing.
4. An umbrella provides very little protection from falling anvils.
Those anvils (boulders were also popular) had the Road Runner's name written all over them, but it was always W.E.C. left standing squarely in their rapidly spreading shadows, with nothing but a spindly umbrella to keep him from being turned into a walking accordion. All that heavy equipment changes from asset to liability at the speed of gravity when something goes wrong.
And, finally, one of my favorite Daffy Duck quotes:
5. Consequences, schmonsequences, as long as I'm rich.
This is from "Ali Baba Bunny", wherein Daffy, along with Bugs, finds a cave of treasure, including the requisite genie in a lamp. Daffy (in typical Daffy fashion) screws up and incurs the wrath of the genie, who threatens to make him "pay the consequences". The above is Daffy's reply. And it costs him. The lesson here: before you set the genie free, make sure you can keep him happy...
Tune in next week, when we attempt to extend this metaphor even further (and risk a lifelong ban from publishing) by attributing deep significance to the weekly antics of "Hong Kong Phooey" and "Scooby Doo".
]]>