Entries Tagged 'Ruby' ↓

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.

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?

I’m not at Railsconf this year, but before he left I asked my coworker Krishna to beg for, borrow, or steal a copy of the Maglev alpha code and bring it back to the office. Unfortunately, it looks like that’s not going to happen (in an email he says “They don’t have anything to share at the moment”), damn it.

Still, as Obie says, this is a huge deal. Even without the stated performance improvements that they’re already seeing (I’m hearing 5x to 100x in microbenchmarks vs the MRI), it would still be a huge deal, because this might be our best chance ever to move people to a real object database. And not just any object database, but one of the best object databases out there.

Once you use it, you won’t ever want to go back.

As far as I’m concerned though, the bigger news about this is that the Maglev VM “does retain the ability to run Smalltalk code.” As long time readers of this blog know, I’m a big fan of Smalltalk and the Seaside framework, and being able to start a project in Rails and then use the same data to build a Seaside app will knock down another huge barrier as far as getting people to try Seaside goes, (see my my post from a year and a half ago about sneaking Smalltalk in through the Ruby backdoor).

In my experience, Seaside makes writing web applications faster and easier than even Rails does.

Paul Graham is well known for saying that their secret weapon while developing Viaweb was Lisp, because it let them develop software faster than any of their competitors.

Ruby + Smalltalk + Gemstone is your secret nuclear weapon.

Not only will it let you develop software faster than any of your competitors, it will also let you scale that software in an easier manner than ever before.

I’ve been dead in the water all day here because Apple changed something in the underlying Socket/Networking implementation in Mac OS X 10.5.3 and now Ruby doesn’t correctly handle sockets. I’ve been looking at it, but haven’t figured it out so far.

My thread on ruby-talk is here http://www.ruby-forum.com/topic/154556 if anyone wants to weigh in on it.

I’m assuming something has to be patched into getaddrinfo.c in the ruby distribution, but my C is more than a little rusty, so it’s slow moving for now.

Really, how hard is it release a document along with an OS upgrade explaining the low level changes made. Isn’t that what we have the Apple Developer Connection for?

It seems like every time I post something bad about a programming language, or compare one language (A) to another (B), at least one commenter lets me know that they like language B better, and furthermore, some aspect of my post has convinced them that language A is so bad that they won’t even try it anymore.

The thing is, I don’t care.

I’m not a consultant anymore. I’m not trying to sell you anything (unless you need drug discovery software). I’m no longer actively involved in open source community. If you don’t want to ever try Ruby (or Smalltalk, or Python, or whatever) it really doesn’t matter to me.

When I point out something about a language, I’m just doing it because I genuinely think that it is better than something else.

So how do I really feel about languages?

Well, over the last couple of months I’ve written code in Ruby, Smalltalk, Javascript, Python (if you haven’t read Programming Collective Intelligence you should), Java, and even PHP (SearchMonkey is seriously cool, if you haven’t checked it out).

So what language do I think that you should program in?

All of the above, and as many more as possible.

Learn about functional programming. And iterator methods. And closures And continuations.

Even more importantly (from my selfish point of view), learn about things that other programming languages can do that I don’t know about.

Then hopefully someday we’ll be able to have a discussion about programming languages without resorting to pointless statements like “I still prefer braces over keywords for blocks” and instead we’ll get comments that we can all learn something from.

While reading yet another article on why PHP Sucks (today’s witty twist, “but It Doesn’t Matter”) I realized yet another reason that I’m glad to be programming in Ruby.

Ruby, to me, is like a big open playground, while languages like PHP remind me of big industrial factories. I don’t think that any of us would argue that industrial factories are more efficient for most things, but they also suck the creativity and life out of the people working in them.

For instance, why would you ever want to write code like this:

class DescribeNewBowlingGame extends PHPSpec_Context
{
    private $_bowling = null;
    public function before()
    {
        $this->_bowling = new Bowling;
    }

    public function itShouldScore0ForGutterGame()
    {
        for ($i=1; $i<=20; $i++) {
            $this->_bowling->hit(0); // someone is really bad at bowling!
        }       $this->spec($this->_bowling->score)->should->equal(0);
    }

}

when instead you can write this:

describe Bowling do
  before(:each) do
    @bowling = Bowling.new
  end

  it "should score 0 for gutter game" do
    20.times { @bowling.hit(0) }
    @bowling.score.should == 0
  end
end

You wouldn’t. The first case is, at best, a bastard representation of the second case.

Of course, being out on the playground means that people get hit in the face with a ball once in a while, and everything isn’t as neatly laid out for you as it is in a factory, but you also have the option to be creative, and not just do things like everyone else does.

And, sure, the playground is far more full of assholes than the factory, but these assholes are also more creative and entertaining to work with than people who just put widgets in place in a factory.

Plus the playground has that weird kid in the corner who’s doing something totally crazy, but that just might be a genius, and if you get enough of these kids together, you’re going to produce something that’s much cooler and more creative than anything that gets built in a factory.

So you can talk all you want about big boring websites being written in PHP (or Java, etc).

As for me, I’ll keep working in a language that encourages people to be creative.

Yesterday, I finally got around to upgrading HAML in our Rails app to the newest stable version and the first thing that happened was that 20 completely unrelated specs broke.

Why, you may ask?

A monkey got into our code, that’s why.

You see, Ruby allows you to redefine any method of any class on the fly (monkey patching) and it turns out that the old version of HAML had the following code in it:

  unless String.methods.include? 'old_comp'
  class String # :nodoc
    alias_method  ld_comp, :<=>

    def <=>(other)
      if other.is_a? NilClass
        -1
      else
        old_comp(other)
      end
    end
  end

  class NilClass # :nodoc:
    include Comparable

    def <=>(other)
      other.nil? ? 0 : 1
    end
  end
end

This, in turn, snuck into our codebase in all sorts of little unexpected places. In one instance a test was comparing sorted Arrays of nils and returning true. Not good.

Luckily, in all of our cases this ended up being more of an irritant than anything else, but I can easily imagine any number of ways in which relying on the assumed behavior of these methods could have broken our app in any number of subtle and terrible ways.

So I’m only going to say this once:

Don’t modify core Ruby functionality in your plugins or Rubygems.

You will break your users’ codebase.

If you do modify core functionality you deserve to be slapped around by those around you.

With the news today that Rails is moving from Subversion to Git, here are some helpful links for those of you that have never used Git before:

• Git homepage
• An introduction to git-svn for Subversion/SVK users and deserters
• Git for Computer Scientists
• Braid (A Piston clone for Git)
• Git Sake Tasks (Rake tasks for performing git operations)
• The Power of Git: git stash
• The Power of Git, Part 2

Feel free to add more in the comments and I’ll update the list above as they come in.

Whenever I start a new Rails project, one of the first things I do is install Rspec and delete the Rails default test directory. Even with that directory missing, however, Rails continues to waste my time by trying to run its various testing tasks.

To make it stop, just add the following:

Rake::Task[:default].prerequisites.clear
task :default => :spec

to the bottom of the Rakefile in the root application directory.

Obviously, if you want to have a default task other than spec, just change the right side of the second line to whatever task you want it to run.

At CDD we use Selenium RC and spec_selenium to run our acceptance tests. Selenium is a slow way to test in general, but lately for us it’s become excruciatingly painful.

For some some unknown reason under Leopard, our tests would seem to randomly slow to a crawl. Tests that usually take 4 seconds to run would suddenly be taking 170+ seconds.

Even worse, this would persist across reboots, and then suddenly go away while we were trying to diagnose the problem.

It was at the point this morning where we were using DTrace to try to figure out what was going on.

Luckily, it doesn’t seem to have anything to do with our code, and it looks like I’ve solved it (or at least worked around it) for now.

Selenium RC communicates over network sockets. It appears that Ruby network communication performance under Leopard is, in a word, terrible.

This problem can be most easily seen when doing a ‘gem update’ and then waiting forever while the metadata updates.

There seems to be a problem with DNS resolution somewhere in the chain that pops up intermittently.

For now, our workaround is:

1. Turn off IPv6
2. Use OpenDNS for lookups.

as suggested by the Ruby Forum thread linked above. That seems to fix things on all of our machines here.

I would file a bug report for this, but I’m not sure if this is a Ruby thing or an OS X thing. If anyone can shed some further light on this issue it would be appreciated.