Reduce eye fatigue when browsing at night

I browse a lot at night and the white background on most pages starts to get annoying very fast. I've found a way to fix this using Frefox, the Greasemonkey add on and a Greasemonkey script I wrote.

Screenshot of Google with this turned on.

Deploying JRuby on Rails Exploded War to JBoss

I've been writing a lot of small apps in JRuby lately, packaging them with warbler and deploying them to JBoss.  These war files average around 10MB I am usually working remotely so these take a few minutes to upload via my 4 mbps/512 kbps ADSL.   Occasionally for small stuff I cheat and edit the code directly on the server so that I don't have to upload the entire war just to change one file.

In addition to the typical compressed war files JBoss allows for applications to be deployed as an exploded directory.  That makes it even easier to modify the application on the fly.

The only issue I've found with this is that I have to be a bit more careful to  manually ensure that the deployed application is in sync with my local workspace.  One way I've been doing that is to use 

xcopy /d

which copies only those files whose source time is newer than the destination time.

Using a revision control system (we use subversion or mercurial) for these projects and deploying from it would probably take care of this but there are two reasons I haven't been doing that up until now.

• The guys who do the front end design don't use revision control so I keep having to manually apply their changes.  It's more efficient if I can just point them to the css, images, and rhtml files on the server.
• These projects are very small and temporary.  Some of them only take a couple of hours to implement.  It often seems like unnecessary overhead to create the whole Trac + Subversion/Mercurial projects for them until they become more permanent.

However, I do need to sort this out before someones changes get overwritten so I think I'm going to try and get them to use tortoiseSVN and make a script that deploys the latest revision to the exploded directory. That should let me deploy almost as quickly as I do now but still take care of the synchronization issue.

How long will it take you to get US Visa interview if you are in say....Jamaica?

A couple of weeks ago my wife was robbed and her passport was in the bag. So now we have to go through the process of reapplying. Same cost ($131 US), same wait as if it was a brand new application.

After filling out a bunch of online forms and paying for a voucher we are supposed to use their online scheduling application to make her appointment. To my surprise there were no openings on the schedule between April and August.

Think about that for a second, their schedule is booked solid for 5 months. The application actually didn't allow any bookings beyond August...too far in the future I guess (with global warming and such who knows what could happen by then the US could be under water! :) ).

Something had to be wrong with those wait times though...right? Fortunately they provide a way to view the average wait times per city (http://travel.state.gov/visa/temp/wait/tempvisitors_wait.php). A couple of clicks and I found out that on average it takes "113 Days" to get an interview for a Visitors Visa in Kingston. A couple more clicks and it seemed like 113 days was waaaay above most of the other countries.

I decided that what I really wanted to see was a list of all the countries and their average wait times so I could see how disenfranchised I should feel.

I managed to cobble together this Ruby script.

#requires
require 'watir'
require 'watir/contrib/ie-new-process'

#includes
include Watir

ie = Watir::IE.new_process
ie.set_fast_speed
ie.goto('http://travel.state.gov/visa/temp/wait/tempvisitors_wait.php')
ie.bring_to_front
wait_until{ !ie.select_lists[2].getAllContents.nil? }
all_cities = ie.select_lists[2].getAllContents

all_cities.each do |city|
ie.goto( 'http://travel.state.gov/visa/temp/wait/tempvisitors_wait.php')
wait_until{ !ie.select_lists[2].getAllContents.nil? }
sl = ie.select_lists[2]
sl.select city
btn = ie.button(:src, 'http://travel.state.gov/images/gettimes.gif')
btn.click!
wait_until{ ie.text.include? "local mail system."}
m = ie.text.match /Visitors Visas: \d* Days/
m2 = m[0].match /\d+/ unless m.nil?
puts "#{city}, #{m2[0]}" unless m.nil?
end

The result? I'm not going to include the full listing here (run it yourself) but regarding my original question....how does Jamaica stack up....well it turns out we are not quite at the bottom of the barrel. Cuba at 731 days (Wow!) takes that "honor", Venezuela is next at 177 Days and Haiti slides in at 137 Days. Nothing like knowing there are other poor bastards out there to lift your spirits :-D

Call Hierarchy for Ruby, Finally!!

I updated my installation of Aptana today after reading that RadRails milestone 7 had this feature. I have been waiting a long time for this.

In case you don't know what Call Hierarchy is or why you should care. It allows you to see every place in your code that is calling a particular method. This is indispensable when you are trying to refactor and can't remember everywhere you used this method.

JBoss Seam

After searching for a Java web framework that comes as close to Ruby on Rails as possible I've settled on JBoss Seam. It is still more complex than I would like since right now the applications I need to deliver in the coming months are very simple.

The appeal of Seam (for me anyway)

• Annotation on the model for O/R mapping. No more hibernate XML mappings.
• Generates the DB from the model. The reverse of how Rails does it but it's still DRY so I'm happy.
• Annotations on the model for form validation. They don't seem as flexible as the Rails validations, e.g. I can't find a way to do the equivalent of validates_uniqueness_of or other complex validations using model annotations in Seam.
• Testable. Hopefully unit testing the applications will now painless enough that I can get into the habit of doing it.
• Automated builds out of the box. Comes with ant build script for common tasks.
  

New Job

Starting new job today to do Java web development at a local Telecoms provider.

The Bad

• Their web framework stack is a little stale i.e. ibatis/J2EE/struts/jsp/tiles
• They are primarily using IBM tools Websphere Developer, Rational, WAS
• They aren't open to using dynamic languages (Ruby) or the frameworks built on them (Rails)

The Good

• They are interested in improving their web framework stack (as long as it's Java)
• There is some interest in XP/Agile (don't scoff. This is pretty rare in Jamaica, in fact I don't think there is a single development shop in the entire country that is doing it)
• They have the infrastructure to support telecommuting and they allow it! (Again very rare here)

Exciting times ahead, look for future posts related to the work I'm doing here.

DSLs and Computer Graphics

The use of Domain Specific Languages in Teaching Computer Graphics Courses

Gordon DuQuesnay
ID#9613644





Analysis of Programming Languages, Assignment 1
Wessel Thomas
February, 2007

Abstract:

Domain Specific Languages (DSLs) are limited forms of computer language designed for a specific class of problems. This approach to programming has been used for some time, for instance, it is very common among LISP and Smalltalk programmers. In spite of their having been around since the dawn of programming they have only recently become a hot topic for discussion in the industry. In this paper I will examine a particular a subset of DSLs referred to as Internal DSLs (Fowler 2006), and how they can be implemented in the Ruby language. I will further show how they could be used in computer science courses such as the "Computer Graphics" course as taught at the University of Technology's School of Computing and Information Technology.

Problem Statement:

Computer Science courses often attempt to deliver very challenging, technically complex content. While some complexity is unavoidable the level of complexity in a course is often compounded by the need to also teach topics that introduce incidental complexity along with the core topic. For example consider the Computer Graphics course, the core complexity of this course involves the various algorithms for producing complex shapes in two and three dimensions by building upon graphic primitives, the most basic being the displaying of a single pixel. However, in addition to this the students must also master C++ and OpenGL, each of which introduce additional incidental complexity. The use of a DSL for graphics could allow the course to focus on the essentials of graphics without having to also concurrently deal with the complexities of C++ and OpenGL.

Research Questions:

• How can DSLs help to reduce complexity?
• What type of DSL would be best suited for use in the compter graphics course?
• What language would be best for writing the DSL?

Literature Review:

How can DSLs help to reduce complexity?
In his paper No Silver Bullet, Brooks explains why he feels the software industry is unlikely to experience orders or magnitude increases in productivity. At the core of his argument is the idea that the complexity of any system can be divided into two parts, the essential and the accidental or incidental. The essential complexity is that which is inherent in the problem. The incidental complexity on the other hand is a function of the difficulty of adapting a general purpose language and platform to be able to solve that problem. Vanderburg asserts a third kind of complexity that arising from the dissonance due to mixing code addressing incidental and essential complexity and suggests DSLs as a way of minimizing this complexity.

What type of DSL would be best suited for use in the Compter Graphics course?
According to Freeze there are two ways to create a DSL. One is to invent a syntax from scratch, and build an interpreter or compiler (External DSL). The other is to tailor an existing general-purpose language by adding or changing methods, operators, and default actions (Internal DSL). The advantages of Internal DSLs as opposed to External make them well suited for use in computer science courses. In particular the speed of development would allow the lecturer to develop and modify the language as the course progresses tailoring the DSL as needed. The main disadvantage of Internal DSLs, that their syntax is constrained by the language they are written in(Fowler), is not insurmountable since the target users are programmers.

What language would be best for writing the DSL?
Internal DSLs, since they are limited by the syntax of their host language are best expressed in languages that have terse, flexible but expressive syntax. This makes dynamic, interpreted languages such as Ruby ideal (Fowler).

Conclusion:

To illustrate the advantage of using a DSL for teaching graphics consider the following OpenGL program in c++:

#include <gl/glut.h>

const int width=640;
const int height=480;

void display(void)
{
	glClear(GL_COLOR_BUFFER_BIT);
	glBegin(GL_LINE_STRIP);
		glVertex2f(50,50);
		glVertex2f(50,-50);
		glVertex2f(-50,-50);
		glVertex2f(-50,50);
	glEnd();	
	glFlush();
}

void reshape(int w, int h)
{
	glOrtho(-300.0, 300.0, -200.0, 200.0, -1.0, 1.0);
}

void main(int argc, char **argv)
{
	glutInitWindowSize(width, height);
	glutCreateWindow("Graphics Programming Basics");
	glutDisplayFunc(display);
	glutReshapeFunc(reshape);
	glutMainLoop();
}

Notice the complexity of even this simple program, also notice the mixing of the essential and incidental complexity. With words and symbols like "void", "int", "**", "}" and ";" which really have little to do with graphics sprinkled throughout the code. An internal DSL written in Ruby could reduce this complexity allowing the same program to be written like this:

window :title=>"Graphics Programming Basics", :width=>640, :height=>480

Ortho(-300, 300, -200, 200)

lineStrip do
point(50,50)
point(50,-50)
point(-50,-50)
point(-50,50)
end


References:

Brooks, F (1986) No Silver Bullet: Essence and Accidents of Software Engineering. Retrieved February 7, 2007

from http://www-inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html

Buck, J (2006) Writing Domain Specific Languages. Retrieved February 7, 2007

Web Site: http://weblog.jamisbuck.org/2006/4/20/writing-domain-specific-languages

Deursen , A., Klint , P., Visser, J. (1998)Domain-Specific Languages:An Annotated Bibliography.

Retrieved February 7, 2007

from: http://homepages.cwi.nl/~arie/papers/dslbib/

Fowler, M. (2006). Introduction to Domain Specific Languages.
Retrieved February 4, 2007, from InfoQ Web Site:
http://www.infoq.com/presentations/domain-specific-languages

Fowler, M. (2005). Language Workbenches: The Killer-App for Domain Specific Languages?

Retrieved Februery 7, 2007, from Martin Fowler's Bliki

Web Site: http://martinfowler.com/articles/languageWorkbench.html

Frecho, J. (2003) Domain-Specific Languages - An Overview. Retrieved February 7, 2007

from: http://compose.labri.fr/documentation/dsl/dsl_overview.php3

Freeze, J (2006) Creating DSLs with Ruby. Retrieved February 7, 2007
from http://www.artima.com/rubycs/articles/ruby_as_dsl.html

Graham, P (1993) Programming Bottom Up. Retrieved February 7, 2007

from http://www.paulgraham.com/progbot.html

Olsen, R (2006). Building a DSL in Ruby. Retrieved February 4, 2007,
from Russ Olsen's Weblog
Web Site: http://jroller.com/page/rolsen?entry=building_a_dsl_in_ruby

Vanderburg, G (2006) Interviewed by Geoffrey Grosenbach. Retrieved February 7, 2007
from Rails Podcast
Web Site: http://podcast.rubyonrails.org/programs/1/episodes/glenn_vanderburg_mp3

Wikipedia Article (2007) No Silver Bullet. Retrieved February 7, 2007

from http://en.wikipedia.org/wiki/No_Silver_Bullet