In regards to my last post, while the majority of content on my upcoming new website will not be WordPress-generated, there may still be times when I require something more flexible. The main reason for my original decision to abandon WordPress is I no longer had the time to deal with upgrades and keeping to multitude of plugins up to date (not to mention one point where PHP/Apache brought my server to its knees running just WordPress).

As such, I’ve moved my posts over to this wordpress.com account I created a while back and never used. The interface here is much better than the old copy I had on my site. The content here will be aggregated at my website alongside other content and that site will truly come to represent what I’m doing on the web (Twitter, GitHub, WordPress.com).

Keep an eye out for the new site in the coming weeks:

natanlevesque.com

I’ve decided WordPress no longer meets my needs. I tend to do more micro-blogging these days, and am no longer interested nor want to spend the time posting article-type blog posts.

So from this arose my weekend project: a new website that incorporates my activites on various other websites. Initially it will probably just be Twitter + Github (possibly Facebook and LinkedIn later). It’ll probably initially be more or less a social aggregator, but I intend on making it a bit more useful than that, but the basic idea is that I will have a lively site with new content daily without having to actually visit it.

If you’ve read some of my previous posts, me and the current state of web technology have shared a love-hate relationship, more so on the latter side of things recently. Frankly I think the web has reached the pinacle of it’s current incarnation. Sure, there are lots of companies out there working hard, but for all the effort, little progress has been made.

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.

So after my initial negative reaction to the announcement of the merger, I’m slightly less worried about it, but still not at all happy about it. I have no doubt that this initial release of Rails 3 will be a big win for Rails programmers, but I’m very worried about Rails slipping back into the depths of bloatware. If that happens, all this merger will have accomplished is to get rid of or (best case scenario) demote the popularity of Merb or any subsequent forks.

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.

I didn’t realize until the other night that comments have likely been hidden since I first made this design. I’ve fixed that now, anyone should be able to comment now.

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

My first reaction to this news was pretty much to scream “NOOO!!!” I’d recently really been getting to love the Merb framework. No one ever likes change but this is one that I still honestly can’t fathom. It’s not that I lack faith in the Merb team to do their integration, it’s that I lack faith in Rails. Anything that comes with that name comes with a lot of stigma, because honestly, I have never had a positive experience with any framework that was Rails or an offshoot of it.

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.

I have to say, I had the most enjoyable experience tonight taking a 5-year-old HP Pavilion laptop and tearing it’s evil Windows inside out to replace with a more loving Linux. My flavor of choice was Ubuntu, mostly due to more experience with that OS.

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…

It’s been nearly two months since my last post and I can honestly say it wasn’t for lack of wanting to. The last six months has become increasingly busy for me. Six months plus ~1 week ago I graduated from college. 6 months ago I started my first career job at My Perfect Gig, Inc. I work with great people there.

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.

This is a somewhat obvious tip, but in the past when sending PureMVC notifications I’ve sent them with an Array as the body. This is nice for simplicity, but requires you to more or less remember what the order of parameters are and what type each is. My solution is simply to create a single value object class for notification bodies (that phrase sounds weird) sending complex data. Then you can cast the body of the notification back to its type and maintain type safety, as well as having access to any code completion.

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.

The last few releases of WordPress have been buggy at best, not to mention you have to bloat your install just to get some decent features. I liked WordPress the first time I used it but as of late it has become more of a bane than a boon.

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.