Introducing Sindain - A JavaScript project template.

Working with Rails is nice. Not only is Rails already setting up a nearly complete environment for you, the community has created many great additions. A quite popular example is thoughtbot's suspenders. Well, here's my little template/project/BDD environment that I use for JavaScript projects (often reusable stuff that I move out of my Rails projects).

It includes:

• The BlueRidge testing framework (which in turn includes Screw.Unit, Smoke, Rhino and env.js).
• JsDoc ToolKit for documentation generation.
• Sprockets for dependency management and concatenation.
• JSLint as a code quality tool

All of it is nicely setup to be used through handy Rake tasks (from the README):

Build

To build/bundle your JavaScript source into a single, distributable JavaScript file we use Sprockets which is run from a Rake task:

rake build

Will bundle all JavaScripts in the top-level src/ directory. To require files in subdirectories, you will have to use Sprockets require statements or build:recursive:

rake build:recursive

To only build a single file, you can specify it as follows:

rake build FILE="singlefile.js"

By default the build task will strip comments, to keep the comments you can use

rake build:keepcomments

And

rake build:recursive:keepcomments

Tests/Specs

To run all your JavaScript specs/tests (based on blue-ridge's Rake tasks):

rake test

(Or just use one of the aliases if it suits you better: `spec`, `examples`, `spec:javascripts`, `examples:javascripts`, ...)

To only run an individual test file:

rake test TEST=application

To run your tests in the browser, just open the fixture associated with the test. You can use

rake test:fixtures

as a shorthand to open your fixtures directory.

To start the Rhino shell (with jQuery and env.js pre-loaded):

rake test:shell

Documentation

To generate JsDoc documentation for your project:

rake doc:build

Once the task has finished, the generated files will be located in doc/jsdoc relative to your project directory.

Code Quality

There is a Rake task to run JSLint on your current build, too:

rake lint

JSLint's rhino.js script has been modified to automatically set the option *browser* to *true*, which will predefine the standard global properties that are supplied by web browsers, such as *document* and *alert*.

I hope others might find this useful as well. Contribution are obviously welcome.

Labels: JavaScript, Programming

It has been a while since the last post of this blog series. Though, it is not over and today's post will definitely not be the last one. Previous participants have mainly been people working on the more theoretical side of computing. However, if you have followed this blog for a while you might have realized that I try to cover both, theory and practice. Therefore, today's open question is from: David Heinemeier Hansson.

Unless you have spent the largest past of your life hiding underneath a rock in the Chihuahuan Desert, you have probably already heard of dhh. Anyways, as I introduce every questioner, I won't make an exception today.

David Heinemeier Hansson is one of the partners of 37signals and most of his frame probably comes from the creation of the incredibly popular Ruby on Rails framework. He is a common speaker at Ruby, Ruby on Rails and open source conferences. But it doesn't stop there. He is also the co-author of one of the standard texts of Ruby on Rails development, Agile Web Development with Rails (together with Sam Ruby and Dave Thomas, now available in its third edition) and of many of the 37signals books, including the soon to be released book Rework. Well, it is more than likely that you already know all of this, so here is his question (short but well thought):

How can make programming less work and more fun and by extension attract people outside the traditional circles?

Ideas anyone?

Labels: Rails, Ruby, TOSOTT

Often, I do not feel like agreeing with Linus Torvalds. This is not because he is not right, but because of the very opinionated, sometimes even stubborn way he brings his message(s) across. To me one of his most interesting exploits comes from one of the messages he posted to the Linux kernel mailing list back in 2001 (which is archived on KernelTrap).

The topic of discussions was coding style and the ways of how Linux was (or was not) designed.

You know what the most complex piece of engineering known to man in the whole solar system is?

Guess what - it's not Linux, it's not Solaris, and it's not your car.

It's you. And me.

And think about how you and me actually came about - not through any complex design.

Right. "sheer luck".

Well, sheer luck, AND:
- free availability and _crosspollination_ through sharing of "source code", although biologists call it DNA.
- a rather unforgiving user environment, that happily replaces bad versions of us with better working versions and thus culls the herd (biologists often call this "survival of the fittest")
- massive undirected parallel development ("trial and error")

I'm deadly serious: we humans have _never_ been able to replicate something more complicated than what we ourselves are, yet natural selection did it without even thinking.

Don't underestimate the power of survival of the fittest.

And don't EVER make the mistake that you can design something better than what you get from ruthless massively parallel trial-and-error with a feedback cycle. That's giving your intelligence _much_ too much credit.

Many of us spend quite a vast amount of our precious time on design issues upfront. This is to make sure that our code is more maintainable, free of errors that could be avoided with a more thought through design, or just to increase our confidence in our piece of software. Every time I write a piece of code that only seems to work out of sheer luck, I very quickly loose confidence in it. I tend to read through it endlessly, refactor to see how much I can clean it up. Eventually though, I will delete it and rewrite it with what I have learned and most often I will find a way to implement the same functionality with a cleaner design. There is a mental block that disallows me from just giving it a show and trying it out in the wild. However, Linus, the maintainer of one of the largest and more successful open source projects known, seems not to have a different point of view.

What are your thoughts?

Labels: Programming

While I was refactoring a hand full of commonly used methods from a few controllers into a superclass, I was looking for a way to test that these controllers are actually inheriting from the new superclass and I won't mess up something in the future. Ruby's Class provides a superclass method which returns the superclass of the class the method is called on (obviously). Now while it is easy to simply add an assertion to each of the tests, I believe this is not very DRY, and well, doesn't look very good. I really like Shoulda macros, so I decided to write one for this particular case. Here we go:

# test/shoulda_macros/superclass.rb

class Test::Unit::TestCase
  def self.should_have_superclass(superclass)
    klass = self.name.gsub(/Test$/, '').constantize
    
    should "have superclass #{superclass}" do
      assert_equal klass.superclass, superclass
    end
  end
end

I inherited from Test::Unit::TestCase, so this should work in both, unit and functional tests. Now you can simply use it like this:

class CommentsControllerTest < ActionController::TestCase
  should_have_superclass MessageContextController
end

Labels: Rails, Ruby, Shoulda

This post in the The other side of the table series is one week late. Sorry for that. As I have mentioned earlier, it is a quite busy time for me at the moment. Anyways, this week we will hear what Lawrence C. Paulson's questions are.

Lawrence Charles Paulson is a professor at the University of Cambridge Computer Laboratory where he works on mechanical theorem proving and its applications. One of the widely known results is the Isabelle system, a generic theorem prover developed together with Tobias Nipkow from the Technische Universität München. He has used this system for his best-known work on verifying cryptographic protocols using an inductive model. Last year, Lawrence has been elected as an ACM Fellow for his contributions to theorem provers and verification techniques. Before that he has earned the Pilkington Teaching Prize. He is also the author of one of the standard books on the programming language ML, ML for the Working Programmer, and also Logic and Computation: Interactive Proof with Cambridge LCF, Isabelle: A Generic Theorem Prover, and Isabelle/HOL: A Proof Assistant for Higher-Order Logic.

I would like to know when the software industry will start taking quality seriously, with the ultimate objective of providing consumer warranties for software. Software is unique in giving the purchaser no remedies whatever; if the product won't launch, the purchaser cannot even resell it on eBay.

I don't forget the Morris Worm of 1988, a huge event that told the computing community of the destructive power of buffer overruns. Despite this early warning, the software industry continued to use unsafe APIs that made buffer overruns inevitable, writing literally billions of lines of unsafe code. Like the bankers, they pretended they were taking risks, but the only people they put in danger were their own customers.

Labels: TOSOTT