jslint from the terminal

Once you get into the habit of using jslint it’s hard not to, it’s just so satisfying when it passes and all the lint has been cleared away. The first few times I used I went to the web application and pasted the file in there and looked at the results, fixed what was wrong and pasted it back into the original file. This is especially inconvenient if you use vim or emacs since pasting from an external environment has always been a bit of a challenge. But fear not, Douglas Crowford, best known for his work on the json spec, has an extended version that works with rhino the java javascript interpreter. The advantage of using jslint through rhino is that you can inspect your javascript files from the terminal. Installing it on a mac is trivial just follow Peters Michaux Install instructions

Here is the short version:

$> curl -O ftp://ftp.mozilla.org/pub/mozilla.org/js/rhino1_6R7.zip
$> unzip rhino1_6R7.zip
$> cp rhino1_6R7/js.jar /Library/java/Extensions/

Download the jslint file

$> curl -O http://www.jslint.com/rhino/jslint.js

And then you should be able to:

$> java org.mozilla.javascript.tools.shell.Main jslint.js your_program.js

Object of the Day

It has been a while since I have added a game to the Office Games section. This one is very simple and entertaining.

Object of the Day can be played with virtual object such as photographs and also with actual physical objects.

The game requires two or more players. One player brings an obscure object for others to guess the purpose of that object. The goal is to bring an object that is obscure enough that it will take the others a while to guess what it is and what it’s used for.

The rules are very simple! don’t bring an object that is too obscure or from a field that is very specialized, and people will have to understand what it is after it is explained. The object has to be intact and cannot have been tempered with. Here are two examples of great objects.

Now try to guess what these objects and what their purpose could be?

11/14 2007

Two things in my .bash_history today.

file merging and resolution conflict tools

vim has an answer for every problem
vimdiff file1.txt file2.txt

FileMerge looks promizing also

the ever lasting quest for decent terminal

the screen app. see
http://jmcpherson.org/screen.html

11/12 2007

One cool thing I learned today was that you can set the columns when you generate the rails migration from the terminal. The prepopulates the tabel generation code with the table names and datatype. This isn’t such a big find since it’s well documented in script/generate model—help. But here is how it looks.

 script/generate model members name:string age:integer
 script/generate model portfolio member_id:integer body:text

Another thing I just came to realize is that defining explicit foreign_key constraint to the database is probably a good idea. I don’t know too much about database administration but if I understand it correctly it helps with dataintegrity and probably performance if the table grows big. Adding indexes is also a plus. A little specifity never hurt anyone. This example is for MYSQL with the InnoDB engine which I believe is the default for rails now.

. . .

def self.up

  create_table :members do |t|

    t.column :name, :string

    t.column :age, :integer

  end

end

. . .

def self.up

  create_table :portfolios do |t|

    t.column :member_id, :integer

    t.column :body, :text

  end

  execute 'ALTER TABLE portfolios ADD CONSTRAINT fk_portfolios_member \\

     FOREIGN KEY (member_id) REFERENCES members(id)'

end

. . .

			 

		

11/8 2007

Here is one neat little vim trick

def some_method
   return bla
end

These vim mappings allow you to quickly comment a block of code in VISUAL mode by pressing ,# or any other key command you prefer

#def some_method
#  return bla
#end

And pressing ,c removes them again.

def some_method
   return bla
end

Helma, server-side Javascript

When you’re on a Ruby on Rails binge, it’s healthy to sober up every once in a while and checkout other things. Not necessarily because you want to re-saddle somewhere else rather to get a chance to learn new tricks and get fresh ideas. I’ve been been playing with Helma the javascript server-side project that was featured in the November issue of Linux Magazine.

The Helma server is build on the rhino javascript interpreter and the java based jetty server. Which means that it’s possible to use java libraries by placing .jar files into the lib/ext directory on the server, and it will automatically get added to the classpath. For example if you need a JDBC driver for MySQL you just get the jar file for Connector/J which is the official JDBC driver for MySQL, and place it in the lib/ext and configure it.

File: db.properties

myDataSource.url      = jdbc:mysql://localhost/blog
myDataSource.driver   = org.gjt.mm.mysql.Driver
myDataSource.user     = user
myDataSource.password = password

There is an obvious benefit by having the client-side code in a interpretive language like javascript, Ruby or any of the others out there, it gives the developer the flexibility of writing code rapidly. There is also a benefit of having it sit on java especially if you need to boost performance or accomplish something that javascript cannot handle. Using javascript on the server-side, presents an interesting opportunity in sharing code base both on the client-side and the server-side, which could, if done right, prove to be a powerful concept.

Using the same language on both the server-side and client-side should help with keeping the applications code base dry. It’s easy to imagine being able to slip a javascript functions or modules through a xhr request at runtime similarly to how ruby on rails delivers the output of rjs templates or simply host the javascript modules you want shared in a place where both the server and client can reference them.

There is a downside as well, you can’t perform all tasks you might want on the server with javascript. Which means any utility scripting such as those that either needs access to the filesystem or for any other things that javascript is unable to do requires using Java or dynamic language such as Perl, Ruby, Python or bash scripts. But if there is a real possibility to sensibly share code on the server and client-side, that seems trivial.

I have been cobbled together some helma code in preparation for an actual tutorial. Where the objective is to develop a little application and explore how sharing of javascript between server and client can be accomplished. To do this I have written a very simple blog post engine where one can enter a posts, comment on posts anonymously. If you practice vigorously you can probably pretend you can code the blog application in a 15 minutes

Keep in mind that this is just a rough draft.

11/7 2007

It’s educational to watch other people at work! especially if they are really good at what they do. I had such luck today. I was clever enough to make sure I had a backup of my .bash_history file so I can go through his actions and try them myself in the hopes that I would remember them later on when I needed them again and that’s where I had this idea of maintaining a page where I can put down those tricks for me to remember and help others that happen to stumble upon it.

The fist thing I learned was that when you are in vi on the terminal and you want to quickly go out of it and get to the console you can hit control+z and that brings you to the bash shell and then you type fg to get back and if there is more than one buffer open you can do fg1 fg2 etc, pointer you can also get to the shell via the :sh command.

Here are some other things.

svn status | grep "^?" | grep -v tmp |   \\
      sed -e 's/^? *//' | xargs svn add
svn diff > changes_to_patch

svn diff -rHEAD:999 > changes_to_patch
patch -p0 < changes_to_patch

svn log --stop-on-copy