Jim's Ramblings - Programming

How I Learned to Appreciate and Enjoy Groovy

nospam@example.com (Jim Jagielski) — Mon, 09 Feb 2009 10:48:00 -0500

As most people who know me know, I am a big fan and user of scripting languages. There are just so many places where they not only make sense, but are the only logical solution to the problem. My recent preferences have been Python and Ruby and PHP and Perl, and they've been enough. At least, up until now.

At SpringSource, I and my team been working quite busily on software products, and one area which tied all the pieces together was a front-end installer and various post-installation scripts that provide additional capability. Now historically we would use Perl for these scripts, but an additional requirement was on the product: assume a bottom-line dependency of a Java JVM. This meant that Perl was out.

Now of course, I could still do this in Python or Ruby (the languages) but that the implementations would need to be the Java versions (Jython and JRuby, respectively). So I could still script in one of these languages, I would simply compile them and ship the class files for the scripts (jar-ed up, of course). So there was no real problem. I did some prelim testing and was somewhat disturbed to fine that Jython was somewhat old but happy to find that JRuby was quite up to date and, from my testing, very, very robust.

But SpringSource had recently acquired G2One, and so, in the logical interests of eating our own dogfood, decided to take a look at Groovy.

I'm glad I did.

My first mistake, unfortunately, was looking at it as a "version" of Ruby. Although there are numerous similarities, there are also enough differences that programming Groovy requires you to, at a very low level, keep your Java thinking-caps on. For example, you need to concern yourself more over actions that would cause an Exception in Groovy, whereas Ruby would just "do the right thing". In this way, I discovered my 2nd mistake: ignoring the fact that Groovy wants to maintain a Java-like consistency. In other words, I was looking at Groovy from the standpoint of a "traditional" script monkey, and not from that of a Java-monkey would wanted an extremely robust scripting language that removed like about 98% of the normal pain in programming in Java. When I got my head around that, then foo = new Fee() made more logical sense than foo = Fee.new() for example.

So I've added new language to my scripting belt. And, I'll be honest here, it's made me enjoy Java programming more than ever.

Spring Python

nospam@example.com (Jim Jagielski) — Fri, 05 Sep 2008 10:36:28 -0400

Lots of people like Spring. The only trouble is that a lot of people also don't like Java. They would love to be able to use Spring but don't want to make the leap from their favorite scripting language.

Well good news, especially for us Python fans. The latest version of Spring Python is now available. The real cool thing about this is that Spring Python is now an official Spring Extension with this latest release. Spring Extensions are a way of extending and enhancing Spring and Spring-related addons with the official help of SpringSource. It's sort of like a mini-Incubator for SpringSource.

Anyway, I'm looking forward to diving into Spring Python. Looks like fun!

Enterprise worthy

nospam@example.com (Jim Jagielski) — Sat, 16 Aug 2008 10:11:07 -0400

Due to both my interests, as well as projects at work, I go thru phases of using various languages. Lately, it's been a C, PHP and Java cycle. It's amazing that of the 3, Java is the only one that most people consider "enterprise worthy".

For PHP, I think it's mostly due to its association of being "just" a server-side language. People forget that you can write standalone PHP applications, which is a darn shame. I'm not saying that PHP is better suited for such tasks than Python or Ruby, but it is pretty rare to see PHP apps that aren't assumed to be running in a web environment. Be that as it may, as anyone even remotely familiar with various social networking sites (and others) know, PHP is certainly more than capable of being a cornerstone of an enterprise worthy implementation.

Now C is very different. Most people don't write applications (web applications, that is) in C, and yet most of the entire service infrastructure (OS, various protocol daemons, utilities, etc...) is programmed in C. So how can C not be enterprise worthy, if it provides the underlying foundation for enterprise apps? And yet people deride C, as if it is somehow quaint and yet also stupid to "dirty your hands" with C, simply because C requires the programmer to have a better understanding of how hardware is actually implemented and how software and hardware interacts. I've met many "professional" programmers who have no idea what "native word size" or "indirect addressing" means, and yet optimal and efficient programming depends on these, and other, constructs so much. Instead, the glory is saved for precious "programming patterns", which have their place, to be sure, but are not the be-all and end-all.

And so we come to Java. IMO, there is nothing within the actual language itself which makes Java enterprise worthy. Instead, it is the vast supporting infrastructure which does so, as well as the results of years and years of external forces "convincing" people that Java is the (only) way to go. Unless you think otherwise, consider how crucial RoR was to bringing Ruby to the forefront. Now imagine if Ruby (or Python or whatever) had the same sort of supporting infrastructure that Java enjoys, and Java had none; in that case, Java would be considered the "toy", the "fringe player" as far as enterprise apps.

IMO, enterprise worthiness is more a measure of the talent of the programmers, developers and architects, and not the language itself.

To understand a language

nospam@example.com (Jim Jagielski) — Thu, 26 Jun 2008 15:08:12 -0400

Each language has its own personality, advantages, warts and inconsistencies. But each also seem to have an almost singular aspect that, if you really wish to be proficient in the language, you must know really, really well. Here's my list on my top 4:

C: pointers
Python: name space rules
Java: Interfaces
Ruby: Ducking

Of course, this is far from complete, and "expertise" in each topic doesn't imply expertise in the language itself, but without getting your head around these, I feel that you are limited by what you can do.

Irony and Self Reflection

nospam@example.com (Jim Jagielski) — Sun, 18 May 2008 14:19:33 -0400

From Bileblog:

Were you so unloved as children that youre so desperate to squeal out your emotions to every inanimate object you come across? Are you THAT insecure that you so desperately plead for attention whenever you sense sentience nearby?

Most likely crafted during an instance of clarity whilst looking in a mirror.

Evolution of a script

nospam@example.com (Jim Jagielski) — Tue, 25 Mar 2008 10:25:59 -0400

Two of the more useful pages on my http://people.apache.org/~jim/ site are my ASF Projects and ASF Committers pages.

These are autogenerated pages which look at various resources and files to determine the "current" list (and status) of the ASF projects and their committers. The script that generates these pages actually has a pretty interesting heritage. The initial version was written by Sam Ruby in Python. I decided to take that as a starting point and ported it to Perl since, at the time, I didn't like Python all that much (that, of course, has changed greatly). Along the way, people started using and referring to the pages more and more, and so the script itself gained some increased functionality.

After awhile though, I tired of doing the script in Perl and decided to rewrite it in Ruby, resulting in the current version. What is interesting, I think, in reviewing all 3 "main" versions is that the original heritage of the script still is apparent in certain sections. If instead of simply "porting" to a new language, if I instead had "rewritten" it, I think the structure would be different, maybe even vastly different in some areas. Also note that in some sections I do things very Ruby-like, and in others, take a more "traditional" approach... This is something I tend to do in all my coding, to reinforce the fact that there are always different ways to code things, and to keep myself, and my code readers, on our toes.

proxy hooks

nospam@example.com (Jim Jagielski) — Wed, 27 Feb 2008 09:20:59 -0500

In the Apache httpd 2.2 development, I've spent a lot of time on the proxy module, especially on the load balancer aspects of mod_proxy. This is an area which interests me and, based on the feedback and popularity of various presentations and webinars I've done, interests others as well.

Not that long ago, on the httpd development list, we were discussing ways of enhancing the load balancing mechanism, with possibly a separate process/thread which periodically verifies the health of backend servers and maybe even providing information on their CPU load, stuff like that. With all that in mind, I started working on some additional load balancing (LB) implementations but ran into a snag. See, right before the proxy module runs the actual scheme handler (that is, "what to do with this request"), it calls a special hook: proxy_run_pre_request. The problem is that this hook is implemented as RUN_FIRST/DECLINED, meaning that all functions registered with this hook will run in order until one returns something other than DECLINED. Now this makes sense for a lot of hooks, but really thinking through the proxy module, it doesn't make sense for this one. Adding insult to injury, the one mod_proxy registers is also noted as APR_HOOK_FIRST, making this hook pretty much useless for other modules/submodules to be able to use if you want to also do "other things" at the same time. This is also the same for the proxy_run_post_request as well.

So what I proposed was "fixing" these hooks instead be RUN_ALL, allowing other modules/submodules from using them (eg: OK, we've found a balancer, now do some checks against them, or create a timestamp or even bypass that selected balancer all together). Unfortunately, this can be considered an API change, which would make it unsuitable for inclusion in 2.2. In other words, this is easy to address/fix in trunk, but I also want to see this functionality in 2.2.x as well, and a major API change would forbid that.

We haven't decided yet, conclusively, if, in fact, it is an API change, or, if it is, how "dangerous" it is (due to the way it's implemented, I'm pretty confident that no one is using it, but that doesn't carry too much weight). So what I'm looking at are adding 2 more hooks: proxy_hook_pre_shandler and proxy_hook_post_shandler, which runs before and after proxy_hook_scheme_handler (that's what the 'shandler' means). This would provide the hook opportunites that I think mod_proxy requires around this stage of processing, as well as being suitable for both trunk and 2.2. The disadvantage is that it adds some cycles to "work around" what is really (IMO), a design/API flaw. The overhead, from all my testing, is pretty much a non-issue, but it still seems an in-elegant solution.

But it's likely the one I'll be pushing for...

mod_site_utime

nospam@example.com (Jim Jagielski) — Mon, 11 Feb 2008 09:06:53 -0500

I've used proftpd as my preferred FTP server for quite awhile now (although I do have a few sites running mod_ftp as well). I've also been baselining Transmit as my main OS X FTP client as well, supplementing the various CLI FTP clients as well.

In any case, I've noticed that Transmit, after uploading files, tries to reset the timestamp on those files. The rub is that, except for the IETF draft, there really is no standard way to do this under FTP. There is overloading the MDTM FTP command, which some clients and servers support. There is also the SITE UTIME command as well. Unfortunately, there appears to be 2 popular formats for SITE UTIME:

SITE UTIME YYYYMMDDhhmm[ss] path

and

SITE UTIME path YYYYMMDDhhmm[ss] YYYYMMDDhhmm[ss] YYYYMMDDhhmm[ss] UTC

What is even more unfortunate is the proftpd doesn't support the MDTM overload and only supports the 1st flavor of SITE UTIME, whereas Transmit (and others) use the 2nd SITE UTIME flavor.

So using the mod_site_misc.c proftpd contrib module as a starting point, I've crafted mod_site_utime.c. It's designed to just implement SITE UTIME (not other SITE commands, like mod_site_misc), and to add some extra flexibility on what is provided in mod_site_misc, like supporting timestamps with seconds values, supporting both format flavors and some basic error checking.

I hear that later versions of proftpd will support the IETF drafts, but until that time, mod_site_utime just may be quite useful for a number of people.

Happy belated birthday, Donald Knuth

nospam@example.com (Jim Jagielski) — Fri, 11 Jan 2008 09:50:47 -0500

It wasn't until I read Yoav's blog post that I realized that I had missed Donald Knuth's birthday. Mr. Knuth is on my short list of programming and computer science giants. And it goes without saying that his seminal work, The Art of Computer Programming, holds a place of honor on my bookshelf... it also goes without saying that it is an incredibly worn and dog-eared copy...

Perl 5.10

nospam@example.com (Jim Jagielski) — Wed, 19 Dec 2007 10:54:03 -0500

Even though other scripting languages like Python and Ruby (and even Erlang) seem to be getting a lot more press recently, Perl5 is still very much a real workhorse in use all over the place. So the release of Perl 5.10 is very good and welcome news! Congrats to the perl5-porters team!

Why community matters

nospam@example.com (Jim Jagielski) — Mon, 17 Dec 2007 09:29:12 -0500

As mentioned previously, one core fundamental of the ASF which is often misunderstood is the idea of "community over code".

Some people take this to mean is that as long as the community is healthy, then it doesn't matter whether the code is good or not. This is, of course, total crud. The phrase does not mean that at all, nor is that the intent of the ASF as well. Instead, the slogan refers to a basic truth that has long been proven, time and time again within the ASF (and elsewhere); That a healthy community creates world-class code. It also implies the necessary corollary: That unhealthy communities do not create sustainable world-class code. The key word is "sustainable".

There are, IMO, 2 main variants of unhealthy communities: one with poisonous people, and others which lack diversity and/or collaboration. My good friends Ben and Fitz explain the impacts of Poisonous People in Open Source, so I won't go into a lot of further detail about that. I will say that the impacts of poisonous people depends greatly on whether they are committers on a codebase or whether just nasty skunks on a list. The former is much more dangerous since the end result is driving away other developers within that codebase, as well as preventing other developers from even considering joining ("That project is a zoo... I can't stand that guy..."). So you devolve the project into the 2nd variant: no diversity and/or no real collaboration. The only people left in a project are either those who don't care or are simple "Yes men" to the poisonous person.

But I can hear people asking "Well, except for the purist aspects, why is that bad? The guy is a coding machine! The code he's producing is really good! So what is the big deal?"

The big deal is that there will come a time, sooner or later (and most of the time it is sooner) that the person burns out, is forced out or changes jobs or whatever that causes him to leave the project. It happens... it happens a lot. And when it does, you are left with a codebase which is basically now left fallow. There are no people left around to "fill in". The codebase suffers, the development community (what is left of it) suffers and the user community suffers.

The ASF sees all that as an event to be avoided. The ASF wants to see code survive and even prosper with the changeover of developers, even super studly ones. The ASF wants to see code as a long-term resource, one that continues to attract users and developers. And by creating an environment where merit is rewarded, the expectation is that talented developers will be drawn to those projects that interest them, and will share their talents by helping that project along. And all this with the end result of a much better codebase.

The code and the project are more important than the whims of a single developer... A healthy community is the antidote against poison and antagonism. A healthy community fosters and creates good, viable, sustainable code. Ergo: community over code.

At ApacheCon US 2007

nospam@example.com (Jim Jagielski) — Tue, 13 Nov 2007 10:33:20 -0500

So yesterday I arrived in Atlanta for a week (well, almost a week) attending ApacheCon... It was actually a not-bad flight and it was nice, for a change, to fly somewhere and not have to worry about timezone changes.

By the time I got in, there was little time for coding at the hackathon, but, as always, sufficient time for socializing...

As I type this, I'm sitting at a hackathon table with Henri, Justin, Garrett, Sander and David. The room itself is about 2/3s full... Not bad for 10:40 in the AM!

Telaen 1.2.0

nospam@example.com (Jim Jagielski) — Tue, 30 Oct 2007 09:50:48 -0400

Today we released version 1.2.0 of Telaen, a very simple but powerful PHP-based webmail system. The reason why I like it is that it requires a very bare-bones PHP installation and is really designed to be as straightforward as possible. If you've read my previous posts about Telaen, you know that it is an offshoot of Uebimiau. We've been contacted by several organizations and projects (including web-host control panels) that will be dropping UM for Telaen.

Language bigots and aficionados

nospam@example.com (Jim Jagielski) — Thu, 11 Oct 2007 09:46:00 -0400

I've been following for quite some time now the various blogs and articles regarding Erlang. In general, the ones by David Welton I've found the most enjoyable. But one thing I've noticed whenever new languages are discussed are that one tends to bring out of the woodwork language bigots instead of language aficionados. The bigots are those who refuse to see anything good in any language other than "theirs"; that their language is suitable for any and all projects; that it is both general and yet specialized. I much prefer listening to the aficiandos, since they can inform me about the reality of their language. When programming, I tend to worry about the reality of programming languages.

As anyone who knows me, or regularly reads this blog knows, I have an affinity for scripting languages. Some mistakenly interpret that as being "anti-Java" when nothing could be further than the truth. The reality is, of course, that Java does not need my help in the least in making a name for itself. The huge marketing forces behind Java have done their job incredibly well, almost too well, since now there is this misconception that Java is the only language that matters, especially in enterprise application development. And that is something that I do hope to clear up. In fact, I'm actually co-presenting with Rod Cope a webinar on this very topic.

I think that languages always have a basic design premise behind them; there is one area which they want to shine. The trick is, of course, whether that is a focus of the language or the focus. Consider FORTRAN; its focus was on engineering and mathmatical calculations. That focus was so intense, however, that it made it extremely unsuited for almost any other application. Now compare that with C that was designed from the onset to be a "general purpose" language, but ideally suited to systems programming. In this case, the specialization did not destroy the generality.

Which brings us back to Erlang... for me, the measure of success for a language is how well it does what it was designed to do; And Erlang appears to do that very well. The fact that it doesn't do such a good job on things it wasn't really designed for does not strike me as a fault or failure at all. After all, would I complain that I can't use my hammer to saw wood well? Or that my saw sucks at driving nails? Of course, if I had some fancy hammer-saw in my toolbox, and it does an awful job at both sawing and hammering, then the generalization is useless no matter what.

Languages, all languages, have warts; As a programmer, I want to know, heck, I need to know, what they are. But only if they are real, honest and true warts.

PS: Regarding the webinar mentioned above. A few days ago someone emailed us back saying:

Haha what a joke this is. No one wants to use a scripting language over java for web applications. This is a sad old Unix guy's last attempt to save perl or something. Give me a break.

I kind of liked the "sad old Unix guy" phrase... And I kind of feel sad for those "young Java guys" who feel so threatened... and are so out of touch.

A URI by any other name...

nospam@example.com (Jim Jagielski) — Thu, 04 Oct 2007 12:13:05 -0400

Many people are buzzing about Amazon's Dynamo, and for good reason. But the buzz is almost dual in nature, because not only is it very cool technology, but also because of the real and perceived impacts on other architectural designs. After all, as noted by others as well, what we're really seeing is a RESTful DB, and how it maps to a RESTful web architecture as well. The key is the URI and the data is the resource; it is a very natural fit. And when the "DB" is better, faster and more scalable due to its simplicity, we see a mutual self-validation between the two. The success of REST implies that Dynamo is the right approach, and the power and capability of Dynamo indicate that RESTful architectures should, of course, continue to be taken seriously (if not more seriously).

Of course, one can pretty much claim that the web itself is a key/value distributed DB implementation, and they'd be right.

I don't agree that RDBMs are going away anytime soon, but mostly it's because that I don't believe in one-size-fits-all solutions. I like having a wide range of tools in my utility belt, so I can use the technology that works, instead of shoe-horning something in, which is the real danger, IMO, with tunnel vision technology.