Schrade.Blog :

So I Wake Up and Merb is Rails?

Tue, 23 Dec 2008 12:49:00 -0800

If you haven't already heard, Rails is now Merb, and Merb is now Rails.

I'm a bit torn about how to feel about this, having dedicated a lot of time lately telling people to use Merb and why I think that it's superior to Rails.

On the one hand, it'll be good for Merb usage, as people using Rails 3 in big projects will now essentially be using what Merb 2 would have been.

On the other hand, I'm concerned with the technical hurdles that the core teams are going to have to deal with in order to make this actually work. There's a lot of old crufty code in Rails that needs to go, although I'm not sure what removing it would do as far as backwards compatibility is concerned.

I've been talking in IRC all morning about this, and I'm sure I'll have more thoughts as things move forward, but for now I'll just post some of my favorite quotes from today's IRC session here:

  <devjj> Modular meaning, what, not included by default, gem install rails-bad-ideas
  <gruntruk> this is like biggy n' pac hugging each other
  <bitbckt> so, I presume the quality of conversation in #merb will disintegrate into #rubyonrails :-/

Certainly should be an exciting couple of months as this merge happens...

(Credit goes to an IM from my friend Will for the title of this post.)

The Open Source Merb Book

Fri, 12 Dec 2008 01:25:00 -0800

Just a quick note to let people know that the Merb community is finally starting to address the lack of good documentation on Merb. I'm personally helping out with the open source Merb Book.

A preview version can be found here: Open Source Merb Book

The source can be found here: GitHub

We've got 20 plus people working on it, and considering that it's only been up on GitHub for 12 days it's pretty amazing what we've already accomplished.

If you want to learn more about Merb you should definitely check it out.

GitHub Takes the Pain Out Of Sharing Your Code

Thu, 11 Dec 2008 01:07:00 -0800

A long time ago, I did a more than a little bit of open source work. Unfortunately, I always found the process of being a part of an open source project to be a pain.

The process usually went something like this:

Fix a bug in the code.
Post patches to the dev list.
Bug people to get your patches accepted and committed.
By the time they are accepted, someone else has committed something that breaks them.
Wash, rinse, repeat

Once you do this enough times, you get commit rights and you don't have to deal with the process anymore.

I've never enjoyed it. Far too much overhead and bullshit.¹

So for the last (more than a) couple of years I've taken to forking code when I needed to and then never bothering to give the patches that I wrote back to the maintainers.

Clearly not the best situation, but it worked for me.

GitHub changes all of that.

On GitHub, I can fork anyone's code, patch it, push my changes back, send a pull request, and then not worry about it.

I can share my code with no overhead.

Example: I fixed a bug in the merb cucumber bindings last week. I pushed my changes to GitHub and sent a pull request to the maintainer. My changes haven't been pulled into the main tree yet, but I don't really care.

One look at the GitHub merb cucumber network graph should show any prospective users of the library that development has happened on my tree beyond that of the original tree. Hopefully they'll take the time to look at it and use the most up-to-date code.

Either way, I don't have to worry about it anymore.

Also, I love that GitHub lets me share my half finished projects.

I recently posted a partially done Merb based blog called Gutenberg on GitHub.

Will I ever finish it? Who knows.

At the very least it's a simple Merb example project for people to learn from, and I already know people who have looked at it to learn more about how Merb works. That already makes it worthwhile to me.

Again, no overhead.

Just push code onto GitHub and it's live to the world.

No pain. No overhead. Just code.

As an aside, I really like commit policies like one that Rubinius has, namely, "anyone who submits a patch for some part of the Rubinius project and has the patch accepted will be given commit rights to the mainline repository." We need more projects with commit policies like that.

The Simplicity of Merb

Wed, 22 Oct 2008 10:39:00 -0700

As some of you know, we're building our new startup on top of Merb. One of my favorite things about Merb is how much easier it is to understand than Rails is when you need to hack on something that's outside the realm of what the framework expects you to use it for. I think that Ezra Zygmuntowicz put it best in his recent tech talk on Merb:

A lot of people tend to end up treating Rails as a blackbox because it is eighty thousand or so lines of code and it's a little bit hard to step into and figure out what's going on because there's so much advanced Ruby meta-programming going on inside of there. I kind of feel like the place for meta-programming and that kind of stuff is in your own application code. I'd rather have the foundation that you're building on top of be as simple and as easy to understand as possible so that when you do hit the wall and you need to look inside the framework you don't get grossed out and you can get in there and actually do stuff with it.

Amen.

Datamapper (or Just Say No to Active Record)

Thu, 09 Oct 2008 18:24:00 -0700

I was having a conversation with a friend the other day who said something along the lines of "lately at work, we've pretty much just been rewriting Active Record to make it not suck as much".

I was thinking about it, and I've never really heard anyone say anything good about Active Record. It's slow, it uses a ton of memory, it's not thread-safe, etc.

Luckily, the community is starting to tackle those problems with a couple of new projects aimed at doing a better job of OR mapping.

The one that I've used the most, and that we're building the software for my new company on, is Datamapper.

The development philosophy behind Datamapper tries to keep everything as fast and as lightweight as possible. It does this by being as lazy as possible in what it loads to keep memory usage down, and by breaking out as much functionality as possible into plugins, so that you only need to include what you're really using in your application.

In my stress tests here using my new application, I've seen significant speed increases across the board compared to ActiveRecord. (I'm writing a Merb app, and it's relatively easy to switch back and forth between the two of them at this early stage in development.)

Datamapper also has most of the major ActiveRecord plugins ported to it (as well as a CouchDB adaptor that we're using for some of our models).

If you're starting a new Ruby web application, I strongly suggest checking it out instead of just settling for the default choice of Active Record.

Running Merb on Edge

Sun, 17 Aug 2008 14:29:00 -0700

The easiest way to run Merb from edge:

$ sudo gem install sake
$ sake -i http://github.com/wycats/merb-more/tree/master%2Ftools%2Fmerb-dev.rake?raw=true
$ sake merb:clone
$ sake merb:install:all

This will install the edge versions of all of the merb gems.

To keep things up to date, navigate to the directory that you ran the commands in and do:

$ sake merb:update
$ sake merb:install:all

Why Not Just Fire All Of Your Programmers?

Wed, 06 Aug 2008 10:49:00 -0700

Then no software would get written, but at least we wouldn't have any crap software...

My friend Jay posted two blog entries yesterday on the subject of raising the standard for programmers in our industry. I left a comment about it on his blog and talked with him about it on IM, but I figured I'd expand a bit on my thoughts on it here.

First things first, I completely disagree with him.

I don't think that 50% of programmers should leave the profession. I've worked on a lot of projects with a lot of different teams and I can't ever remember thinking "man, this project would be a lot easier if I got rid of half of this team."

I can also only think of few Net Negative Producing Programmers that I've worked with and most of them usually leave pretty quickly.

Most of the time, I've found that when a person isn't performing up to par, it's because of a management failure. I think that it's up to the development leads to analyze their teams and figure out how everyone can best contribute and make sure that people are performing at the top of their game.

Too often I've seen people fall into the trap of always being assigned to, or always choosing to work on, the easiest features in the project. They then do a half-assed job because they're always working on the boring part of the project and don't feel like a valued part of the team.

Maybe, for a change, we should assign those people the hardest part of the project for a few weeks. Sure, they might not so the best job, but they will work harder because, for once, what they're working on is challenging and exciting. Plus they know that the entire team is depending on them and is there to help them. That's how you bring people back into the fold and make them a productive, happy member of the team.

The point that's neglected in Jay's arguments is that experienced programmers shouldn't just be responsible for writing code. It should also be the job of experienced programmers to take those who are less experienced or interested and pull them up to our level.

Forcing them out of the profession is just as much of a failure on our part as it is on theirs.

Moving On

Tue, 05 Aug 2008 11:46:00 -0700

Things sure have been quiet around here...

As some of you may already know, I've left the relative safety of my job at Collaborative Drug Discovery to have another go at starting a company.

I'm currently working with a friend to once again create something out of nothing and bring yet another crazy idea into the world. Therefore, if you see me and I look like I just got finished working for 18 hours straight, please buy me a beer and put me to bed.

As for the new company, I'm not ready to talk about what we're doing yet, but I'm sure that I'll be writing about it here as it comes together.

Don't Forget to Clear Out Your Rails Session Data

Tue, 01 Jul 2008 00:01:00 -0700

For the last year or so, this blog has been running slow, slow, slow.

From time to time, I tried to figure out what was going on, but I figured that Typo upgrades were just causing things to slow down and use more and more memory.

Until tonight.

Tonight I did a database dump and it came to 44 MB.

There is no way I have 44 MB of content in this blog.

So I had a look at the dump and realized that I had close to 100000 sessions in the sessions table, and that there was a table for Sitealizer plugin that's no longer part of typo.

So after a drop of the Sitealizer table and a

rake db:sessions:clear

Typo is now using 20% of the memory it was using before, running much, much faster, and the database dump comes to a slim 476 KB in size.

So this is my reminder to myself (and everyone else) to be sure to clear out your sessions table from time to time.

Omnifocus Interface == Fail

Mon, 30 Jun 2008 12:40:00 -0700

I use Omnifocus everyday to track what I'm doing, and I love it, but there are tons of UI problems with it that drive me absolutely crazy. There's a good article about some of the failings of the interface design here (with a video showing some of them), but there's one interface decision that's been absolutely driving me nuts lately.

Look at this picture:

See anything wrong with it?

If you said, "There's no way to set the due date for a project to Tuesday without clicking the little arrow at the top left to go to next month" then you're right.

What a horrible failure of UI design. I end up up dealing with this at the end of every month, and everytime it's a pain in the ass. Compare it to the iCal day chooser:

See that? Much better. They just grey out the days in the upcoming month. (They even go above and beyond the call of duty and show two upcoming weeks.) This is what the Omnifocus date chooser should be.

Hopefully there will be an Omnifocus update soon that addresses most of the problems with the interface. I expect more at the price point ($89) that they've positioned it at.