First, Godin claims that “textbooks don’t make change”. It is difficult to be sure exactly what this means, but here is my interpretation. Textbooks are written for undergraduate students — typically 18-20 year olds who are taking their first look at the subject in question.

“Making change” is not the job of the textbook — rather it is to teach the fundamentals in a sound fashion. So if the hippest textbook that Godin could find makes no mention of Google, Twitter, or Godin’s own permission marketing, then perhaps it is a good sign. A textbook should be looking beyond the latest implementations, and instead explaining the core concepts in depth. Marketing might be a fast moving area, but I don’t believe that its very essence requires re-writing every three years. And if it does, then perhaps marketing is not a topic that’s suited to academia in any case.

Secondly, Godin claims that textbooks “don’t sell the topic”. The truth is that that’s not the job of the textbook, and every textbook author knows it — especially since their target audience have already committed to 3+ years studying the topic in depth. Perhaps Godin means that they don’t make it sexy enough, but most of the process of learning any topic in depth is not even remotely sexy. It’s about getting your head down and learning the details, studying the history and considering how it can be applied in the world you. I dare say that this even applies to marketing as well.

Want sexy? Why not talk to your professor, who probably wrote the textbook anyway, in person. Or read the papers published by the research students in your department. Or failing that, read Seth Godin’s blog. Either way, you’ll surely be getting the freshest cuts. Textbooks are for teaching the basics, not learning about the cutting-edge.

Thirdly, are textbooks really as expensive as Godin claims? Not in my experience. A typical undergraduate textbook ranges from £20 ($33) at the low-end, to £50 ($80) at the high-end. (Disclosure: I know little about marketing, and am not from America).

Godin claims that an author in Toronto made $20m from a calculus textbook. Assuming this book cost  $75, and the author made a generous 15%, or $11.25, per sale, this adds up to sales figures of 1.75m copies. Reliable sales figures for books aren’t easy to come by, but Stephen Hawking’s worldwide bestseller “A Brief History Of Time” is thought to have sold 10m copies. Clearly, whichever way you look at it, making $20m from an undergraduate textbook is the exception — and not the norm.

So to move on to Seth’s solution. Academics should freely publish their findings online — because that’s their job. But hang on – isn’t that what they do already?

The post was accurately labelled — it was a rant — but it didn’t do what a good rant should do. It didn’t strike a nerve in me even remotely, even though I’ve been a long-time reader (and purchaser) of academic books. Perhaps I’ve been lucky to avoid the worst, or maybe marketing is particularly afflicted with dross books. But either way, I don’t agree with Seth’s conclusions.

This could be done manually, but it’s a huge timewaster, if it gets done at all. Implementing it automatically, however, is complicated because of the inherent un-linearity of Git. Our first attempt was to use the Grit library to count the number of commits that had been made, and generate a version number from this. It fails because different versions of the repository, on different development machines, contain different numbers of commits. For example, some experimental branches are never pushed to the staging or production machines, or even shared between developers.

This means that the version number changes, dependent on whose machine the application is running on. This is confusing for clients and developers alike, and quite frankly pretty useless.

It became pretty clear that a version number would have to be explicitly stored in some place, and updated. The next question was, when to update it? Incrementing once per commit, a la subversion, seemed like the obvious answer (and Git offers the use of hooks to perform arbitrary callbacks on post-commit, and other events). But upon deeper thought, it is obvious that this problem suffers from the same faults as the first attempt, because committing on experimental branches will still increment the total.

The solution, so far, is to reject the idea of basing the version number on the number of commits altogether, and instead base it on the number of deployments. This makes a lot more sense, because it hooks into the visible product actually changing: when a deploy is carried out, one can reasonably expect the finished product to have changed in some significant way. During this time, any number of commits could have been made or reverted, or branches created or destroyed; but the version number will still only increase by one.

The code to do this is pretty simple. Since our project uses Capistrano for deployment, it is easy to create a task in the deploy file like this:

task :after_deploy, :roles => :app do
  run "cd #{shared_path} && ruby increment_release.rb"
  run "ln -s #{shared_path}/RELEASE #{release_path}/RELEASE"
end

Then save the following file as increment_release.rb in the shared directory on your deployment server.

fname = File.expand_path(File.dirname(__FILE__) + '/RELEASE')
curr  = File.read(fname).to_i rescue 0
f=File.open(fname, 'w')
f << (curr + 1)
f.close

The version number increments once per deployment, per environment, and being symlinked into your current directory, it can be accessed from your Rails app with something like:

current_revision = File.read(RAILS_ROOT + '/RELEASE').to_i

Does a web service already exist that could be hit as part of a Capistrano deployment, and keep track of your release number remotely?

I ended up with intuitive and easy to use dial controls, in a Logic Pro/Ableton style, courtesy of Matt Mower’s LMDial NSView subclasses. They’re perfect to use in a musical environment – clearly laid out, easy to operate and consistent in their behaviour.

They can improve the usability of any music-oriented SuperCollider GUI.

Here’s the finished result running in SuperCollider.

This how-to involves getting your hands dirty, and assumes you can already successfully build SuperCollider in Xcode [download source code], as well as a basic understanding of both Cocoa’s NSView class, and SuperCollider’s own GUI system.

The altered SuperCollider source files SCView.M, SCCocoaView.h and SCCocoaView.M, containing the changes described below, can be downloaded here. Matt Mower’s LMDial framework is here.

1. Import NSView classes

I imported the NSView classes into the SuperCollider Language Xcode project.

Matt’s LMDial controls are conveniently packaged as a framework, so it was a simple task of dragging the framework into the Xcode project. To link the framework, it also needed dragging under the “Link binary with libraries” build phase, and I also had to create a “copy files” build phase to copy the classes into the Frameworks directory of the compiled application.

You can safely skip this step if you’re using classes which are part of the standard Cocoa/OSX distribution.

2. Work out what the hell to do with them

I had really had no clue how to incorporate these controls into SuperCollider. Without any better ideas, I decided to emulate the changes in Scott Wilson’s recent SCLevelIndicator commit, which also added another custom NSView control to SC. This turned out to be a wise move.

SCLevelIndicator was a pretty similar addition to the one I was trying to make. By following the same conventions myself, I was confident that I would end up with some stable code at the end.

Some careful examination of Scott’s code showed that adding Cocoa elements to SuperCollider involves the definition of both an Objective-C class – which subclasses the NSView class we are importing – and a C++ class which slots into SuperCollider’s wider (cross-platform) GUI and messaging system.

Now I could proceed to define the headers and implementations for both of these classes.

3. Defining the Objective-C class

In Headers/app/SCCocoaView.h, I defined an Objective-C interface SCLMDialView, which subclasses LMDialView. This is itself a subclass of NSView.

I placed the corresponding implementation in Source/app/SCCocoaView.M. Only a handful of methods were required: in particular, I needed to implement (void)mouseDragged:(NSEvent *), which LMDialView relies upon to update itself.

@implementation SCLMDialView

- (void)mouseDragged:(NSEvent *)theEvent
{
    int oldValue = value;
    [super mouseDragged:theEvent];

    if(value != oldValue) {
        mSCViewObject->setValue(value, true);
    }
}

- (void)setSCView: (struct SCDialView*)inObject
{
	mSCViewObject = inObject;
}

- (void) mouseDown: (NSEvent*) event
{
    [self setFocusRingType:NSFocusRingTypeNone];
}

- (struct PyrObject*)getSCObject
{
	return mSCViewObject->GetSCObj();
}

- (void)setFrame:(NSRect)frameRect
{
	[super setFrame:frameRect];
	[self setNeedsDisplay:YES];
}

@end

4. Define the C++ class

The C++ class is where the main action is. This class subclasses SCView, which is an internal SuperCollider C++ class but directly reflects the SuperCollider class of the same name. I followed the naming conventions set by the other classes in SCCocoaView.h/.M, and named the class SCDialView. The implementation is too long to post in it’s entirety here, but the header declaration is shown below.

class SCDialView : public SCView
{
public:
    SCDialView(SCContainerView *inParent, PyrObject* inObj, SCRect inBounds);
    virtual ~SCDialView();
    virtual void setBounds(SCRect inBounds);
    virtual int setProperty(PyrSymbol *symbol, PyrSlot *slot);
    virtual int getProperty(PyrSymbol *symbol, PyrSlot *slot);
    virtual void setVisibleFromParent();
    double value() { return mValue; }
    bool setValue(double inValue, bool send);
    virtual NSView* focusResponder() { return mDialView; }
protected:
    SCLMDialView *mDialView;
    double mValue;
    int mMinimum, mMaximum, mStep;
};

This class deals with a number of important functions.

• The constructor is called when a SuperCollider user creates a new SCDialView. It creates a new instance of our Objective-C class SCLMDialView and adds it as a subview to the parent view.
• The setValue method is called when a user sends a value_ message to the SuperCollider object. It clips the value to a minimum and maximum and updates the NSView object. If necessary, it also sends a message back to the SuperCollider object – which is acted upon by any actions associated with it.
• The setProperty method receives any requests to change attributes of the GUI element – background colour or font face, perhaps. In my case I had to deal with a long list of possible attributes here, but all had the same basic structure: check the value the user is presenting, and if it is valid then update our SCLMDialView object. If the attribute is not one we are interested in, we call the superclass method and pass it up the hierarchy of GUI elements.
• The corresponding getProperty method is much simpler, simply returning any requested attribute to the user.

5. Write the SuperCollider class file.

In scdialview.sc, I wrote a SuperCollider class SCDialView. It subclasses SCView and simply defines a list of attribute getters and setters which allow the user to control the look, feel and position of the dial.

SCDialView : SCView {
  value {
    ^this.getProperty(\value)
  }

  value_ { arg val;
    this.setProperty(\value, val);
  }     

  valueAction_ { arg val;
    this.setPropertyWithAction(\value, val);
  }     

  minimum_ { arg val;
    this.setProperty(\minimum, val);
  }

  etc

}

6. The final hurdle

I spent several hours trying to work out why the SC crashed every time I tried to create an instance of my new GUI element. I eventually discovered that the new classes must be registered in Source/app/SCView.M.

extern SCView* NewSCDialView(SCContainerView *inParent, PyrObject* inObj, SCRect inBounds);
...
void registerSCViewClasses()
{
  ...
  new SCViewMaker("SCDialView", NewSCDialView);
}

And it finally worked!

Conclusions

This process was a real mission, but I learnt a lot about Objective-C and SuperCollider’s inner workings. And I’ve got some seriously cool GUI dials.

Don’t forget you can download the altered SuperCollider source files here.

I haven’t worked out how to get it back into the normal shell window just yet, but using xterm does basically the same job here’s the shell command.

tail -f log/development.log

Validations are themselves a presumably well-tested part of Ruby on Rails, but their usage in an application significantly changes the behaviour of your objects.

This means their usage should be spec’d like anything else.

Spec’ing out every single attribute on every single model is pretty repetitive though. So I rolled my own custom matcher to speed this up. It takes advantage of the fact that I follow the convention of using a valid_attributes method somewhere in my model’s spec, which I use to create a basic object for testing. For example:

describe "Comment" do
  def valid_attributes
    {
      :commentable_type => 'Item',
      :commentable_id => 1,
      :content => "This is a comment!",
      :user_id => 1
    }
  end

  before(:each) do
    @comment = Comment.new(valid_attributes)
  end

  it "should ..."
end

it "should validate with exactly the specified attributes" do
    @comment.should validate_with_exactly(valid_attributes)
  end

• The object is invalid with all the specified attribues
• Any one of the attributes is missing and the object is valid

The spec code is available at http://pastie.org/230565 – pastie it into your spec_helper.rb.

This is still so hot off the press it’s positively steaming. Do you have any comments, bug reports or suggestions?

It’s good to see Ruby’s boundaries being pushed, though. And there’s a reasonable chance that one or both of these projects could be the future.

And of course, Rubinius on Rails...

That will really be interesting.

My working pattern is, roughly, as follows:

1. Sketch a basic method implementation
2. Test it manually
3. Fine tune the code, improve implementation
4. Further manual testing, fix a few bugs
5. Write a test
6. Done! Make a cup of coffee.

Is there anything so bad about this process? I write a test, so I get one gold-star. And there’s nothing wrong with the end results: I write good code, which usually works. But I think I could work better. Every time I’ve written a model or controller for as long as I can remember, a little voice in my head asks: “Why haven’t you written the test first…?“

Anybody else get the same little voice? I suspect there’s a few of you out there.

The more I’ve learnt about TDD, the more I’ve wanted to practice it. At first, it just seemed like a way of ensuring thorough test coverage, but that is actually just a sweet, sweet bonus. For me, TDD is more about changing my entire mindset when it comes to coding. The benefits promise to run deeper than may first appear obvious.

Sure, testing first will remind me to focus on what I want my code to do, before I start coding. This is valuable, yes – and I can see it helping me avoid a few refactoring/start-from-scratch sessions when my brain hasn’t quite been in gear – but I don’t believe that it will much improve my resulting finished code, so much as make the process of getting there a more efficient.

The more precious benefit, is that the pre-written tests will tell me exactly when to stop – and that’s a time when it’s a lot easier to trip up. Especially a day later, or a month later. The habit of testing first will prompt me to keep my methods small and manageable. Small and manageable in the short-term, equates to easy-to-maintain and stable in the long-term. A method of working which virtually obliges me to create manageable, bug-free code? And as good as guarantees a working stack of tests across my application?

There’s a whole host of other good reasons too, some of which I am perhaps yet to fully appreciate, but enough already. I am convinced.

So, why aren’t I doing it? My only problem is discipline. That’s going to change.

Test-unit Zappa

How will I switch to TDD? Firstly, I will drop Test::Unit and make the switch to RSpec.

Why switch? After all, the Test::Unit framework is a proven system in itself. It’s been shown to be more than capable of providing in-depth test coverage in complex applications, and is also usable within a strictly test-driven environment. What’s more, it’s true to say that there’s little testing that can be done with RSpec, that can’t already be done, one way or the other, using Test::Unit.

Isn’t switching from a system I am already well familiar with, simply going to be a short-term hindance – and offer questionable benefits in the long-term?

There are two stand-out reasons. Firstly, working with a different testing framework will force me to throw out my old habits, and hopefully help me to break my old routines and shake up my testing in the way that I want. Old habits die hard, and sometimes need a little persuasion.

Secondly – and perhaps even more importantly – it’s about changing the the language in which I write tests. RSpec’s descriptive idioms – typically written as something.should_have – are forward-looking, and cry out to be written and defined before the method they test. This is quite different to Test::Unit, which really encourages working the other way around.

As Josh Stephenson highlights here:

Just as sociologists have postulated that the language we use to express the world around us directly affects the way we interpret it, the language we use to test applications directly affects the way we develop them.

So RSpec will force me to throw out both my testing routines, and my vocabulary. I can’t do much more to create a catalyst for change.

Of course, I will be monitoring my work-flow, productivity and the resulting code carefully. If, after a reasonable period it is clear to me that TDD is not working – back I can go. But a decent spell of practicing TDD, a good level of familiarity – a fair test, so to speak – is going to be needed before I can conquer that little voice in my head, one way or the other.

In due course, I will post my progress here.

References/Further reading

http://www.oreillynet.com/pub/a/ruby/2007/08/09/behavior-driven-development-using-ruby-part-1.html?page=1

http://www.agiledata.org/essays/tdd.html

http://blog.daveastels.com/files/BDD_Intro.pdf

There’s nothing like using two languages a lot (which I do) to get you comparing their finer details. Here’s what I have come to see differently about Ruby from coding in SC, and a few things I miss in Ruby that are present in SC. Maybe I’ll follow it up in the future, and do it the other way round.

Punctuation can be beautiful after all

Amongst a beginning Ruby programmer’s first acts, still flushed with the excitement of escaping from Java or PHP, will be to quite consciously throw away the habit of finishing each line of code with a semi-colon. And why not? They bugged me for years too, being obviously unnecessary in 99% of cases, cluttering up the page and and causing countless exceptions and failed builds when misplaced. And basically, for no good reason.

How many semi-colons do you see in Ruby code? Not a whole lot, in my experience. It’s almost like they’re omitted in order to somehow punish Java, perhaps deservedly.

SuperCollider requires the semi-colon at the end of (most) lines, and I used to feel it a bit of a pain. But semi-colons have kind of grown on me. Perhaps it’s because of SC’s strong functional programming paradigms, which means that it’s easier to chain multiple messages together than Ruby, even while splitting them across multiple lines.

SCWindow.new("A window!", Rect(20, 20, 300, 300))
    .alwaysOnTop_( true )
    .onClose_{ "Goodbye!".postln }
    .userCanClose_( false )
    .front

Most people seem to hide the semi-colon away. I prefer to give it pride of place, hanging it off the end of the indentation like a tear-drop.

The semi-colon is dead… Long live the semi-colon.

Syntactic sugar, SC style

Assuming iteration over a list – or range – makes a lot of sense. Actually, this isn’t syntactic sugar at all – just sensible proxying of messages – but it certainly feels like it.

Ruby:

(1..10).to_a.collect{ |num| num.squared }
# Ruby version >= 1.9
(1..10).to_a.collect(&:squared)

#=> [ 0, 1, 4, 9, 16, 25, 36, 49, 64, 81 ]

SuperCollider:

(1..10).squared

#=> [ 0, 1, 4, 9, 16, 25, 36, 49, 64, 81 ]

Also worth a mention is SC’s ! notation, as an alternative to Object#dup. This can often be used to fill an array.

Ruby

Array.new(10){ rand(10) }

SuperCollider

{ 10.rand } ! 10

Partial application

Partial application allows the creation of functions from implicit input data – that is, call a method sending less than the required number of arguments. This is a trick picked up from functional languages such as Haskell. There, however, it’s better known as currying.

It can be (vaguely) comparable, in effect, to Symbol#to_proc in Rails (and Ruby 1.9), but is endlessly more flexible and powerful.

Each pair of lines are equivalent:

(1..10).collect{ |number| number.postln };
(1..10).collect(_.postln);

(1..10).collect {|x| Polar(x, pi) };
(1..10).collect(Polar(_, pi));

Currying is cool.

Instant API

Why does coding in SC seem so quick and easy?

Maybe, its partly down to the speed of access to the language documentation. And it really is quick. Not sure how to scan each item of array? Just type Array, select it and hit CMD-D – up pops the SC documentation for Array class. Unsure of where a method you are calling is implemented in the class hierarchy? Select it and hit CMD-Y, and up pops a list of classes where the method is implemented, including extensions and plugins.

And best of all, select the name of any class and hit CMD-J. There in front of you is the source code for that actual class.

Now, it would be unfair to use this as a criticism of Ruby, as SC has an integrated editing environment which makes this sort of thing possible to build in as standard. But anybody who created a Ruby version of this system, perhaps as a plugin for TextMate, would be an instant superstar in my eyes, and I would think a good few others too.

My conclusions…

I am increasingly aware of how much Smalltalk is responsible for, and more and more interested in getting to know it a bit better in itself. Learning a new language never did anybody any harm.

global_variables.each{ |var| puts var + ": " + eval(var).inspect }

Ruby’s global variables – I have long been aware of their existence in the background, but I hadn’t realised quite how many are initialized by default. What are they all for – and what cool metaprogramming tricks can I use them for?

I actually use one of these variables very often, and it deserves a special mention. $! points to the most recently raised exception, and is a useful shortcut in many contexts. A lot of the others promise to be most useful in a shell/CGI script environment – but it’s good to know they’re there, and a little peek under the hood of Ruby usually proves instructional.

Here’s the global variables initialized by default on my system (Ruby 1.8.6 on OSX 10.5) – where I have some idea what they refer to, I’ve added that too.

References

http://www.ruby-doc.org/docs/UsersGuide/rg/globalvars.html
http://cbcg.net/talks/rubyidioms/index.html
http://www.math.hokudai.ac.jp/~gotoken/ruby/ruby-uguide/uguide20.html
Hal Fulton: The Ruby Way (2nd Edition), Addison Wesley

To me, AJAX performance isn’t so much a scalability issue, as a user interface one. The slicker and more responsive the interface, the better the user experience. And so a deeper understanding of the AJAX protocol has got to be a good thing.

http://www.ibm.com/developerworks/web/library/wa-aj-perform/?ca=dgr-lnxw01FasterAjax