Schrade.Blog :

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.

Django Testing Framework == Fail

Fri, 27 Jun 2008 12:20:00 -0700

I was reading on a plane recently, and was about halfway through the Django book, when I realized that I hadn't seen anything about how to test my application yet. I tend to be a test first developer and use lots of mocks to play with things, especially at the beginning of a project, so I flipped to the index, turned to the test page, and saw the following:

Testing was still under development when this book was being written, so to learn more you’ll need to read the documentation online at http://www.djangoproject.com/documentation/0.96/testing/

Not a whole lot of help when you're on a plane.

Still, I was willing to give them the benefit of the doubt. Maybe they could create a bolt-on testing framework that would really be something.

Unfortunately, it's just not very good.

Perhaps I'm spoiled by Rails and Rspec, but to me, the Django testing framework feels like something that they put in place just because someone told them that they needed a testing framework. It's not an integral part of the system.

Let's look at their test types.

First of all we have doctests. These emulate the output of the Python interactive interpreter exactly inside of your test code. All this does is to encourage the bad practice of writing some code, firing up your your interpreter, running a few cases, and then cutting and pasting the results into a file. There's no need to think through all of the cases or what you're really doing here. It's just an after the fact, feel-good, safety check.

Second, we have Unit tests. Not the most sophisticated testing framework in the world, but these look like a better choice, very much like any sort of xUnit tests.

The biggest problem I have with these, and the Django testing framework in general, is that the tests don't look to be compulsory. Why, in this day and age, don't we make the generation of a test automatic, and make the user decide to remove it if they really, really don't want to test, not the other way around?

Testing as an afterthought inevitably leads to poorly tested code.

I certainly hope that, as Django continues to grow and mature, testing take a more central role in the future.

Innovation, Or the Complete Lack Thereof, In the Start-up Community

Tue, 24 Jun 2008 01:47:00 -0700

You can't just ask customers what they want and then try to give that to them. By the time you get it built, they'll want something new. - Steve Jobs

I was at a networking event out here in the Valley a few weeks ago where a bunch of companies went up on stage and presented their companies to the audience. I'm fairly certain that at least one of them might have been interesting, but to tell you the truth, I don't really know because I didn't really pay attention to any of them.

I already knew about the ones that mattered and a quick glance at the program showed me that the others weren't worth listening to because they were me too clones of other start-ups.

After the presentations were over, a friend asked me what I though of them, to which I replied, "Don't know, didn't pay attention" and he responded, "yeah, but are you actively a hater like me yet?"

I think that I got his point, and that is that there are times lately where I just want to slap people when they tell me what their company is doing.

I know that innovating is one of the hardest things in the world to do, but lately, I've been disappointed in 99% of what I see. As far as I can tell, there seem to be two main reasons for this:

The first reason is because of what I call the "me too" start-up. For example, when I first moved to SF, Flickr was the big thing out here, so for a few months everyone seemed to have a crap photo sharing site. Then this changed to Youtube/crap video sites, Facebook Platform/crap widget sites, and on and on. Some degree of competition is a good thing, but it's all a little much. If you have a substantial improvement to an existing product then, by all means, go for it. However, if you're just doing a feature for feature copy of a competitor's website then, please, invest those resources in doing something else. Or at least don't try to pitch it to me as something new and exciting.
The second reason, and the one that bothers me more, is the "aim high, fall fast" start-up. This is the start-up that has lofty goals, and falls into the trap of selling them out to meet some sort of smaller and less interesting short term target. This is all too common (hell, I did it at my last start-up), and I think that a big part of it comes from the fact that it's so cheap to start a company now that sometime it's easy to forget just how hard you really have to work to make something great. These are the companies that VCs need to fund at their "aim high" stage to keep them from plummeting. Sure, they might have an idea that's way off in left field, but companies like that are usually the ones that grow into something huge and interesting.

So, I guess that I'm asking everyone out there for one thing, and that is to think bigger than we are right now. Think outside the box, don't water it down in the early stages or once a little revenue starts to trickle in the door.

When I run into you at a networking event, make me say "damn, that's a crazy idea, but it just might work" and when I run into you 6 months later don't make me shake my head at you because you've turned it into a clone of another idea.

Perhaps if we all start using our heads, the innovation will start flowing freely once again.

Exposure to New Things, Still Good (More on Maglev)

Tue, 03 Jun 2008 10:20:00 -0700

I'm somewhat taken aback by all of the negative reaction to Gemstone being a closed source product in the wake of the Maglev announcement.

Look at this:

Do you really think that the people that own this ship care about paying for software?

I doubt it, but they probably care about things like development speed. And software reliability. And the ability to get someone on the phone immediately if something goes wrong with the software.

That's the world the Gemstone comes from. I would bet that if the software running the shipping platform for this company falls over, it would lose more money over the course of a few hours then it would cost them to license Gemstone for an entire year.

Here's another example where JP Morgan has a system built on top of Gemstone that they can not afford to shut down or migrate to another language because it would cost them too much money.

How is being exposed to the toolset that powers things like that going to be a bad thing?

Sure, it's closed source, but if enough people use it and benefit from it then the community will just do what we always do:

Some of us will pay for it, some of will find clever ways to subvert the license, and the rest of us will get to work on building an open source clone of it.

That's what always happens, and when it does happen some people will continue buying the closed source supported version (Oracle) and others will move to the free version (MySql).

What makes anyone think that something different is going to happen here?