Take the following example code for instance:

All three examples illustrate the same concept: using a Groovy closure to call a method on and arbitrary string instance. You could of course be doing much more in that closure, but for purposes of illustration i’ll keep it simple.

What we’re doing in examples 1 and 2 is changing the scope that the closure gets evaluated under. Normally, a delegate will resolve this to the scope that it was defined in. By setting the resolveStrategy and delegate, we tell it to look for a delegate first and resolve this to the delegate object. The delegate can be any Groovy/Java object. In doing so, when we invoke the closure, the split() method gets called on the splitMe object we assigned to delegate.

Example #2 is simply a Groovy convenience method for the same. You can either pass the closure as an argument or define it inline.

Example #3 probably looks familiar if you’ve ever used Groovy’s extensions to Object. By using Closure.call(), we can pass in an arbitrary number of arguments. Since we’re only passing in one, we gain the convenience of the untyped “it” property that you normally expect to be passed to a closure.

Closure.call() is an extremely powerful method that you can use to define your own Groovy iterator methods!

I’ve seen a lot of talk about MVC in Flex/ActionScript circles over the last year or so and wish I had voiced my opinion a little earlier, so I apologize if the timing of this seems misplaced.

I’ll start with the particular impetus for writing this article (from an article today on InsideRIA):

The biggest problem facing Cairngorm is the apparent lack of documentation. It can be argued that Cairngorm is a highly flexible architecture that is poorly represented by a few meagre examples.

Counter argument here would be that the biggest problem for a framework like Cairngorm is not the lack of documentation; it’s the fact that the documentation that exists advocates design patterns and code behaviors that would make a seasoned developer cry. Frameworks like this cause too many developers to stop thinking about their code design.

There are situations where a pattern such as MVC should be followed, it helps your code flow and everything runs smoother, but I get the sense that there are far fewer developers who question why they are doing MVC than there should be.

How many question “Is this a good use case for MVC?” or are you just coding that way cause thats the only way to cram it into your classes? I see too many developers get stuck in cookie-cutter solutions: singletons, reinvented event management, 100s of files of boilerplate code. What became of good software architecture?

My attitude these days is that I’ll use whatever is good for the job and stays the hell out of my way when I do it and doesn’t make me fight the framework when I try to implement a modified architecture. There is one particular framework that does this for me for now, until something better comes along.

I’d love to hear others opinions on this as well.

I’ve come to believe that the main culprit of this is the HTTP protocol. It’s inefficient and encourages uses of technologies such as HTML, XML, and JSON. These technologies had their time, but I would think by now that time should have passed.

To give a comparison, the web is in the same technology state as the automotive industry. Over the years cars have changed in appearance to fit the times and consumer appeal, and thus have websites changed. Sure some new technological offshoots have occured to support these changes, but these changes have been at best iterations.

Now we’re here in the year 2009 and the automotive industry is facing consumer pressure to find alternatives to expensive fuel consumption on diminishing fossil fuels. So the automotive industry has begun to respond with more fuel efficient vehicles, but that only delays the fact that we won’t be able to run on fossil fuels forever.

Similarly, the web continues to run on HTTP, all the while seemingly not realizing that this protocol and behavior is simply not maintainable if we ever want the web to move on.

Personally, I think binary protocols are the future of the web. Now I know the majority of web developers would cringe at that, saying they like plain text protocols, but really, why does the data need to be transfered in plain text as long as a binary transfer can be transcribed to a human readable format on the client end?

The problem lies in the transition and that problem is threefold: browser compatibility, site compatibility, and search indexing. Current browsers have a hard enough time with HTML and CSS, so a new protocol would need extremely strict compliance standards. Everyone is aware of these issues but consumers really don’t push back like they should.

Site compatibility covers the issues of existing sites that this new system would need to be backwards compatible with. Sites like this would probably be phased out gradually (when was the last time you saw a ‘96 era site that was popular? )

Finally, every search engine out there relies on theese plain text protocols for indexing, so some considerations would need to be made for them. Take for example the Flash format, which was not originally designed to be indexable, and now there are efforts to go back and make it indexable without majorly rearchitecting the format. It’s proven to be difficult so far.

There’s only so much HTTP can do, and while it does have it’s uses, there are better routes to go in the future.

It’s absolutely great that the Rails team had finally realized that opinionated software isn’t a win-win situation. But now there won’t be any major competitor for Rails. By that I mean, Rails will once again be the “best” option especially as there won’t be competing frameworks that are as flexible as Rails will be. I have a very bad feeling that lack of competition will lead to another stagnation of the framework. Just look at what Merb has done for Rails, made it look at itself and realized it needed to change.

At this point my options are few: get out of Ruby and find a web framework in another language, fork Merb, roll my own, or use Rails 3.

Option #1: Leave Ruby for a Framework in Another Language

I’m not at all favoring option 1 since I absolutely love Ruby and no matter how disappointed I am in these recent events, I won’t hold it against the language.

Option #2: Fork Merb

Definitely possible, although it’s not like I could maintain an entire framework like Merb as a lone wolf. Also a lack of community is a little disheartening.

Option #3: Roll My Own

Obviously this would be a tremendous effort of time and energy, although it could be a massive learning experience. Not necessarily the best option if I actually want to accomplish web projects in the next year.

Option #4: Rails 3

I would have to say that at the very least, in order for this to happen it would have to be proven to me that in at least 90% of cases that Rails 3 will at least as good as Merb 1.x was. That means performance, volume of code, quality of public APIs, lightweight, flexibility, etc. Suffice it to say, Rails 3 will have a lot to prove to me before I could condone using it.

Conclusion

My conclusion is that for now I’m going to focus on pure Ruby / Merb projects running with a forked version of the 1.x line. I probably won’t be altering any of the forked code for now, but using it as a stable copy. When Rails 3 comes out I’ll probably give it a try, but it’s going to go through quite the gauntlet for me to accept it as a viable production technology.

How embarassing to have that be like that for months and not notice…

Merb made me fall in love with programming again, I loved the community on IRCand to be able to listen in for merbcamp and to be honest this news was pretty much like hearing “I’m seeing someone else.”

If anyone involved in Merb is reading this, I’m not trying to fault you in your decisions. I know you’ve been stressing over the last few days that Rails 3 will be better than Merb 1.x and that it will be good for the Ruby community. I honestly hope so. But there was one major pull from Merb for me that this merge kills: Merb isn’t Rails. Merb community isn’t Rails community.

There was a substantial appeal to working with a technology that was on the cutting edge and Merb was a niche technology. Now that’s going away and Merb no longer has any appeal to me since it doesn’t have the “underground” feel that it had a month or two ago for me.

This hurts a lot honestly, because I was beginning to really get into it, but I just can’t get the bad taste out of my mouth at the moment.

So Merb guys, please prove me wrong.

Seriously though, Linux was more of a technical choice than a philosophical one.

Still feels good to be rid of one more digital devil though…

The side effect of that is my free time quickly dried up (all that life stuff got in the way) and I haven’t really had any time to do what I love to do: learn. The past few years have been a fury of learning new technologies or programming languages.

To change that I’ve decided to learn a) a new programming language and b) a new framework to use it in. My choice was Ruby and Merb. I’ve decided to take some time during this next week to focus more on that and also to hopefully come up with something more practical than a blog to add to this site.

It’s not an end-all solution, I wouldn’t expend time coding a class for simple notifications, but it certainly helps keep your command code clean and readable when you’re send more complex data.

So I figure I might as well do something about it and write some blog software specifically for me. Yes, everyone between here and the sun has written blog software and why can’t I just fall in line and not reinvent the wheel?

Reason is, none of the wheels out there give me as smooth a ride to where I want to be without costing me an arm and a leg in server performance. If I’m going to spend the amount of time I’ve spent recently fixing things, I might as well be spending that time in constructive ways.