Dreams of a Rarebit Fiend

A few weeks back a longtime Rails developer by the name of Zed Shaw wrote a post in which he declared Rails is a ghetto. If you haven't already read it I would suggest that you probably not bother. It's likely not going to be very interesting to you unless; a) you've been involved in Rails since almost it's very beginning and thus you probably already read it or b) you're planning to become a consultant in Rails. See, a lot of it is kind of like the guy telling you how much the party sucked because a bunch of people showed up and ruined it before you got there. Except, because you only showed up at the party very late to begin with, you had a completely different experience. The people who ruined the party are gone or at least aren't ruining anything anymore. And the people who had their party ruined... Well, they've moved on to another party. A really boring one that started in 1991 that never really caught on and isn't going to.

Those of us who only really showed up to the Ruby and Rails party in 2007 (and viewing the build a weblog in 15 minutes video the year before doesn't count) are happy to show up to the party. There's plugins to do everything under the sun, good books on interesting topics are showing up regularly, user groups are either already established or are popping up everywhere, it's a great party. Especially if you're a serial entrepreneur like myself and you're looking to build websites with lots of features quickly and you aren't going to get a lot of help from a huge crew of people to do it.

So maybe Rails is a ghetto. Maybe it would suck to be a consultant in it right now because there's not enough jobs yet or rates aren't where they should be. Maybe I would have developed strong animosity between myself and some other developers/writers because I got in too early. But frankly I didn't and I love it. Working on LOL.com was truly the first web development experience I have ever really enjoyed. Yes, Enjoyed. Oh, I still love Java and it's my go-to language for heavy data lifting. But Rails is it for my web development. I can go to a web development project and like it and then come back later and not wince at what's I did. Sure, I'm making novice mistakes, but even those aren't proving that bad to clean up.

Before I clam up again, there's two other things I'd like to say:

1. Zed Shaw singles out Dave Thomas for a lot of vitriol in his rant. I can't speak to any of that. Maybe he is a horrible person, maybe the Ruby book he wrote sucked horribly. But, I have read his Rails book and it's not a bad book at all. I've gone back to it many times already. I have a lot of other Rails books at this point. Several of them aren't very good at all, so it's not just my ignorance of what other Rails books are like. Nor is it my inexperience with programming books. I've been a professional developer for 20 years now. I know programming books both bad and good. I can stand up and say that Agile Web Development with Rails is pretty good.

2. Everybody who has seen the explosive growth of Ruby and Rails over the last couple of years eclipse their favorite language/framework (e.g. Python, Groovy, PHP, etc.) seems to be blogging or commenting this idea that Ruby and Rails isn't really that great, it's just hype. It's only a committed few who have something to gain from you adopting Rails (i.e. a book to sell, consultant hours, etc.) who are promoting something that is snake oil.

   Seriously, how stupid do you think we all are? I've been doing professional development since 1985 and doing it full time since '87. Do you really think that I and thousands of others can't tell when something works and it doesn't? I did HTML when the only browser was NCSA Mosaic and ASP websites to build DevGames.com and then later GameDev.net in 1999. That was painful. I can tell the freaking difference people. This works and it works well. I might not pick it for building the next version of eBay because it wouldn't stand up to the load, but I would pick it for building the early versions of the next site that will become as big as eBay because it will offer that site lots of fast growth and flexibility.

Posted by John Munsch at 9:58 PM | Permalink | Comments (2) | TrackBacks (0)

Google has a regular internal lecture series on mostly technical topics with guest speakers and some of their own employees. This is their TechTalks Series and the best part of it is that you and I can see them too. They record and digitize the talks (close to 300 of them to date) and make them available on Google Video, using a consistent tag on each one so you can easily search for them and see if any interest you. The link above will do the search and show you all the videos so far.

Some of the titles that caught my eye:

Privacy Preserving DataMining

Turning Email Upside Down: RSS/Email and IM2000

Strike Up The Brand: How to Design for Branding

Ruby And Google Maps

Ruby Sig: How To Design A Domain Specific Language

Note: I'm not endorsing any of these, I haven't had a chance to view them yet. They just looked interesting to me.

Posted by John Munsch at 3:54 PM | Permalink | Comments (1) | TrackBacks (0)

Recently, there was a very popular weblog entry detailing the use of acts_as_ferret for adding search to your Ruby code. For a variety of reasons I detail below, I had considered acts_as_ferret and had decided to instead try acts_as_solr for the new version of LOL.com I'm writing.

Unlike Ferret, which is a port of the Lucene search engine to Ruby & C, Solr actually is Apache Lucene. It's a separate server which runs under Java and your application sends XML requests to it in order to add new data, remove data, or make queries. acts_as_solr hides all the details of that so searching appears as seamless as if were all inside your application.

Installation of the plugin is as simple as:

script/plugin install http://opensvn.csie.org/acts_as_solr/trunk

You can include "acts_as_solr" in model objects you want to be searchable. You can even use similar syntax to what you would use for acts_as_ferret to perform basic operations:

Model.find_by_solr(query) or Model.find_id_by_solr(query)

The acts_as_solr page I linked to above will give you all the details but it's hardly any different from acts_as_ferret in either installation or actual use and getting and installing Solr is quite easy (launching the server is no more difficult than "java -jar start.jar"). The difference is all in how it is written and details behind the scenes.

Some Advantages I See To acts_as_solr Vs. acts_as_ferret

• I first looked into Solr and acts_as_solr when I heard from an acquintance that the project he was working on was using acts_as_ferret and their 3Gb database of search information had gotten corrupted. To my knowledge at least twice since then they have attempted to fix their problems but have still had corruptions occur. Lucene is used a lot of places and it's pretty well tested chunk of technology. Solr is simply a wrapper for existing Lucene technology so it should be pretty stable.
• I posted a small bug with the installation to the Trac site for acts_as_solr a week or so ago and it and another that someone else posted have both been fixed since. Clearly it is in active development as are Lucene and Solr so you are depending upon projects which seem to be getting some development love. I have heard some complaints about Ferret not being updated in a while, though I have not confirmed that independently. The reason I haven't been able to confirm it is because the Ferret website at http://ferret.davebalmain.com/trac has been down every time I tried to hit it in the last day or so. Hmmm...
• Because searching is a web service in this system, other websites or tools which need access to the same search database don't have to be written in Ruby and you don't have to graft a web service onto your own application to offer up remote queries. Just hook them up to the search server like you would hook them up to the same database.
• You can you can more easily move search onto another machine to transfer the searching load off the web servers running your main Ruby on Rails application. Again, this is treating your search engine as a self contained unit like your database server.

If you have had good or bad experiences with acts_as_ferret or acts_as_solr, particularly in environments with large numbers of individual items being put into the search engine or large amounts of data overall going into it, please post them as comments to this entry. I'm hoping to get this on Digg and DZone so people are aware that there are alternatives and those with some experience with either one or the other can speak up.

Posted by John Munsch at 7:14 AM | Permalink | Comments (3) | TrackBacks (0)

I had never really learned regular expressions. Oh sure, I could use * and ? as well as the next guy, but throw [0-9]+ at me and I had no idea what it meant. That is, until the last year or so. Regular expressions can be very helpful in pattern matching against file names or user input and I dislike having gaps in the overall toolset of things I'm comfortable using.

So I set out to correct it. I'm still pretty ham-handed when it comes to typing in a regular expressions and I end up having to consult cheatsheets in order to remember the syntax to do a lot of things, but I discovered online tools and websites that helped me overcome the gap in my knowledge. Here are my favorites:

• txt2re: headache relief for programmers - This lets you input a piece of text you want to match against using a regular expression and it displays different expressions you could use depending upon which parts you want to match against. It can give you a quick start on matching even if you aren't yet very regex savvy.
• RegEx: online regular expression testing - This is the other handy part of the equation. Here you can input several items of sample text and a regular expression you wish to test. Hit the test button and it will show you which test text matched, what parts were matched, etc. It's somewhat Java oriented but might be as useful for any language with fairly standard regex syntax. I've found it very helpful for iterative development of complicated regular expressions.
• Regular Expression Library - A library of already crafted regular expressions (with various levels of complexity and robustness) to validate things like email addresses and telephone numbers.
• Regular Expression Tutorial - A tutorial capable of teaching you enough to be dangerous in a fairly short time. Good info and it's not intimidating.

Posted by John Munsch at 3:44 PM | Permalink | Comments (0) | TrackBacks (0)

Peter Cooper has developed a simple source code snippet repository with tagging that I like. It's far from perfect, the syntax highlighting is often squirrelly and if you enter in a multi-word tag like this "unit test" when you go to edit the code you get your tag back as two separate words so you always have to put the quotes back in place. Nevertheless, it works and it's a good start. Plus people aren't being shy about putting code out there.

What we need at this time are a small army of Java developers putting their code snippets into this repository. In no time it could be the place to go for a quick routine to fix a problem.

Here are my snippets thus far:

• Ant 101
• Getting A Data Source From Tomcat
• Data Source 101
• Velocity 101
• Velocity 101 Unit Tests
• Email 101
• Email 101 Unit Tests

They will even give you a feed for when I post new snippets. Unfortunately they don't have feeds for individual tags (e.g. Java) working yet. That's a shame and it's actually one of several glitches I've noticed. But even with the bugs this is still a more believable code snippet repository than many I've seen over the years. The tags go a long way towards making it really searchable and usable. But it will only be really useful if _everybody_ enters in some of their favorite utility functions and classes. So go sign up this minute and put in just three Java code snippets! It will take you less than 15 minutes and we will all benefit.

If there aren't any more improvements or he never releases the source code or it never gets full text search then maybe I'll move my snippets to another repository in the future. But it needs to be one with syntax highlighting, an easy framework for inserting the code in the first place (this is very very easy), and tagging.

Posted by John Munsch at 10:03 PM | Permalink | Comments (0) | TrackBacks (0)

I usually don't get to attend conferences, but given the significance of Waterfall 2006 - International Conference on Sequential Development I'm positive I'll get to go.

Clearly their lineup of sessions, keynotes, and workshops eliminates the need for JavaOne, No Fluff, or any of the other big conferences.

Posted by John Munsch at 6:01 PM | Permalink | Comments (0) | TrackBacks (0)

I've rewritten this entry because I was told by multiple people not the least of whom was my wife (a person who can actually write sentences that make sense) that an instant message chatlog between myself and Don Thorp didn't make for a readable weblog entry.

It all started when Don pointed me to this entry about what should and should not go into Ruby on Rails: http://www.loudthinking.com/arc/000407.html. The way he put it, it gave him heartburn.

I read it and agree. The position of the author is that higher level constructs have no place in Rails and that in general it's futile to try and construct higher level software components for websites. I consider that to be a big mistake. They are missing is that the underlying model of, for example, ZWNews and MovableType and Wordpress is fundamentally the same. Most blogging software, forums, comment software, link counting, polls, etc. can be reduced to a basic subset of features which are in just about any of the software that various sites are using. If there's that much commonality then you can produce that subset of functionality, offer a few simple hooks into it so it can be extended in a couple of places and it'll probably serve the needs of 80% of the people who are building sites.

I would argue that they make this mistake because:

• They don't spend their time building one weblog after another or five or six forums in succession so they don't see the common elements which underly all of them. This is similar to the fallacy of so many game developers who start off by building a "reusable" sprite library or 3D engine before they begin their first game. They either fail completely or they succeed at building something but pronounce it impossible when they cannot then reuse it themselves later for another project or persuade anyone else to reuse it. It's a poor fit because they didn't grow the API based upon the needs of multiple projects, they instead attempted to divine the interface and capabilities based upon what they thought it would need.


• They imagine both a model and a UI which goes with it. That never works. You can have a UI which is a starting point or an example but the focus of the code has to be on the model and the administration for that model.

Kasai is an excellent example of this. It's design is a good one for an authentication and authorization system which will serve the needs of 80% of all web applications. I know what I've needed in the past and I can look at it and assess whether this would have met the needs of a large number of sites I've worked on and the answer is yes. In fact it really could stand to be reduced or simplified in a few areas and it would still have served my needs.

I think what most people fail to see is what is really a reusable component in real life. In the world of IC components a digital micromirror is a reusable component. It's not a TV all by itself. It has no tuner, memory, light source, etc. etc., yet it's a reusable piece. It's going into all manner of TVs today, all different in subtle or large ways, and for all I know somebody is building a huge array of them for a high resolution video wall.

So when I switch to the world of software, specifically, web applications I should be able to identify reusable pieces that occur over and over again with variations. In the world of websites you frequently have comment systems that have the following characteristics. There are a large number of unique conversations. The conversations are not linked to each other. Each one is a straight linear series of comments. Each comment needs to be attributed to an individual which could easily be referenced via a unique ID. Each comment may have some numeric rating associated with it or a pointer to another set of properties. That is a reusable component. I can build it and you could drop it into the user ratings at the bottom of Amazon products or the file comments at Stock.Xchng or Fark or half a dozen other places and you wouldn't notice that it had changed. Even if the first generation of the component isn't a great fit and needs work (like Kasai) the second or third will be because it was adapted to the real needs of a lot of users.

It's good that there is a major emphasis on making the infrastructure solid in Rails but saying that there shouldn't be a set of libraries that go with it to provide some reusable components for counting links clicked on, comments, authentication/authorization, etc., etc. is like saying that Java would have been better off being just like C++. A language without its huge supplementary library. That library, a well designed one which provided pieces we use every day for things like collections, XML parsing, regex, etc. determined well what some "high-level" components were which could be widely reused. Rails doing the same would only strengthen the framework not weaken it.

Posted by John Munsch at 3:54 PM | Permalink | Comments (0) | TrackBacks (0)