Xavier Defrang

I have finally released that plugin I have been hapilly using for almost a couple of years now.

Say hello to acts_as_tree_with_dotted_ids!

I'm usually all for readable instead of "clever" code but I can't help to find this Ruby* one-liner pretty sexy:

This cute piece parses the given text and extract all "Key: Value" pairs into an associative array.

This is the kind of simple joy that Ruby brings. Right in the middle of the implementation of some larger feature, you figure out you need to parse some text, you just write a single line of code and it just works.
This is worth mentioning because It does not happen that often, to say the least. :)

* this code requires Rails for the &:symbol shorthand to work.

Because directly invoking methods on objects is so 2000...

Things have been very quiet down here and hectic everywhere else. As a proof that this is no lame excuse, my first Rails patch was just committed into the trunk.

For the record, it addresses an issue in ActiveResource which could not locate resources defined in nested modules.

I've been using ARes a lot in my current project in which I've built a rich client-side API packaged into a Rails plugin. To be honest, I'm into a love-hate relationship with ARes and things were not as smooth as initially advertised.

I've experienced some severe hiccups with nested resources, inflected collection names, attributes vs prefix hashes and some nasty XML (un)marshalling oddities. If I find some time, I will document here the problems I encountered during this wild ride...

Even though it has given me some serious headaches, I still think this REST approach is better than dealing with a huge black box supposedly implementing some funky flavor of SOAP.
ARes is not totally mature in its current state but the size of its code base still allows a mere mortal to dive into it and see what's happening.

If the popularity of REST services keep on rising, ARes will need some real refactoring and internal plumbing work to bring it to the same level as ActiveRecord in the ORM field.

The bottom line is: ARes is a neat library you may want to play with but you must be warned that things are not as simple as they seem and it may require some significant tweaking on both sides of the wire...

If you ever talked face to face with a computer or if you just want to take a stroll down the memory lane with some anonymous heroes, I highly recommend you to take a look at Halcyon Days, a collection of interviews with bytes counting and cycles saving übercoders from the golden age of videogaming.

It looks like some folks in Javaland are pissed at Apple because Leopard did not ship with Java 1.6.

I still doesn't understand why Apple should be held responsible in any way for the port of a third party technology such as Java to its operating system.
Isn't Sun supposed to make sure the JDK works on all major operating systems or are they too low on cash to afford their ADC renewal?

Sure, OS X ships with some popular open source programming tools as part of its UNIX layer, but I just see it as freebie which saves me a few minutes of compilation and surely not as some human right.

It's not like it should come as a surprise neither since Apple has been continuously shying away from Java which used to be one of the languages of choice to build Cocoa applications.
The Java/Objective-C bridge has been discontinued since Tiger while Leopard saw the addition of this technology for Ruby and Python, including Xcode integration.

As usual, John Gruber sums it up nicely (or on a more serious tone).

It's been too long since I have learned a new programming language. I had a swift look at the Flex framework but XML is not a programming language, is it?

Nowadays, it seems to be all about the lambda calculus hippies reinventing the wheel in Haskell or thread happy ruffnecks playing with Erlang... I'm probably a bit too down to earth to jump on those bandwagons at the moment so I thought It was time for me to go back to the roots of object oriented programming: so I'm finally going to learn Smalltalk.

If you are curious, you can find some freely available PDF versions of out of print Smalltalk books.

Now the worst difficulty wont be to grasp the language but actually get over the horrendous and sluggish user interface of Squeak. Wish me luck!

UPDATE: We are not quite there yet but it looks they somehow acknowledged the GUI issue...

If you are looking for a lightweight and elegant single sign-on solution for your Rails applications, you may want to have a look at the rubycas-server project.

As the name implies, it's a Ruby implementation of the Yale University CAS protocol which is open, standard-based (HTTP, SSL and a pinch of down-to-earth XML) and already available for a wide assortment of other platforms (Java, PHP, Python, ...). The setup of rubycas-server is straightforward, it supports several authentication back-ends out of the box (SQL, ActiveDirectory, LDAP) and writing a custom authentication handler is a breeze.

If you look at the client-side, it's at least as good: the rubycas-client plugin for Rails is simply amazing. The code is clean and ut just handles everything for you. I basically added 2 lines of configuration, changed 5 lines of code in a base controller and the whole authentication layer of my application was delegated to the CAS server.

Those two projects are definitely worth checking before you start rolling out yet another proprietary SSO architecture...

The beauty of Ruby on Rails never cease to amaze me:

# Oneliner split for layout purpose 
now = Time.now
qc = QueryCounter.find_or_create_by_date_and_hour(now, now.hour)
qc.increase!("count_#{query_type}")

Yes, this snippet does exactly what it reads: no more no less. It just works.

...including the long awaited XML Digital Signature at field level!

Now it's going to be really hard to get more enterprisey than this!

I just had a talk about WordPress with a colleague so I thought I should finally publish this draft I wrote a few months ago...

Being a lucky full time Ruby on Rails developer for more than a year, I've got used to readable code and a clear separation of concerns.

Nonetheless, I recently had to customize a WordPress installation. Installing the software was a breeze and the administrative interface looks reasonably good and comes with all the bells and whistles one may expect at this point in time. WordPress being an extremely successful and popular open source project, I actually had some hope about the code being somehow structured to offer a proper level of customization.

I had never been so wrong.

Let's play to find out the extent of the disaster: will you spot where in the world is the actual code that retrieves the content for the list shown in the Manage posts screen? Hint: in the version I was working with, the function is called without any parameters.

Yes, it's that bad. It seems we've got all the cons of PHP focused in one, massively deployed, application. Do I really need to line up the usual suspects?

• Global variables everywhere. Globals even seem to be part of the whole design.
• SQL queries everywhere. Same queries performed at multiple places.
• Extremely poor object-oriented design. Somebody please buy those guys a copy of PoEAA.
• Lots of serialized "stuff" in the database (btw, what are those cached RSS feed objects doing in the table which stores the application settings? WTF!)
• No view helpers of any kind, let's build those dropdowns the hard way every time
• Coding conventions strictly follow PHP's own no conventions methodology. The wp_ prefix seems to be used erratically through out the code.
• Some functions libraries contain more lines of code than fully functional Rails applications of average complexity.
• Strictly no automated testing.
• Criminal use of syntax such as mixed style if statements (C-like Vs Python-like), omission of curly braces, non-semantic indentation, ...
• And of course, the whole thing is SQL embedded in PHP embedded in HTML embedded in PHP embedded in ...

I know it's possible to write clean, object-oriented and well designed PHP applications but let's face it, we are not even talking about 5% of the global code base deployed worldwide.

WordPress certainly doesn't represent the State of The Art in term of PHP code but if you care about your platform, the last thing you will ever want is a flagship product or killer app with a code that looks so bad. WordPress is definitely not an exception, just take a peek under the hood of some of the most popular PHP apps...

This excruciating experience has led me to think that PHP as we know it must die. It's been helpful but its learning curve has been steadily acting against its very own community. We've all been rookies but what's the future of a platform for which 95% of the code consists of large balls of sticky spaghetti? When I see such an amount of crap in such a popular open source application I actually wonder how anyone can go down the slippery road leading to code rot for such a long time. I see two possible answers: utter stupidity or freshman's naiveness. We've all been there and I for one knows that newbies usually have plenty of time to write plenty of code they will be ashamed to look at a couple of years later if they eventually turn into grown up software craftsmen.

Call me an *sshole but the code zealot I am fully agrees with the crystal clear elitist stance of DHH when it comes to building tools and frameworks.

The only hope for PHP is to break up with its legacy, Zend should start to think about something else. They already missed the ubiquitous web framework era so why don't they focus on something completely new? Why not dreaming about a major overhaul of the language with a magnitude similar to Python 3000?