My Stuff

2010 Conferences

OSGi DevCon @ JAX London

February 23 - Keynote titled OSGi in the Enterprise: Agility, Modularity, and Architecture’s Paradox


March 22 - 25 - Tutorial on Modular Architecture

Über Conf

June 14 - 17 - Sessions titled Turtles and Architecture and Patterns of Modular Architecture


July 26 - 30 - Two sessions on rich mobile applications and one on agile development. Half day tutorial on software process improvement.

Tweets @ Twitter

re: #apple event "We sold more iPads than any PC manufacturer sold of their entire PC line." 2012-09-12

re: #Apple Event ""Our notebooks now rank #1 in the US in Market share in the last three months." 2012-09-12

Right on. I just won a Best Buy drawing worth $1000. Either that or I won a shiny new virus by clicking the link. Hmm...what to do. 2012-08-29

The #osgi alliance response ( to the @mreinhold #jigsaw announcement ( 2012-08-29

Good Q&A with @mreinhold on project #jigsaw. Modularity will change the way we design and run apps! 2012-08-28

LinkedIn Profile

The opinions expressed on this site are my own, and not necessarily those of my employer.

Language Type Systems

Filed Under Development, Java, Ruby | 3 Comments 

All programming languages have a type system. Typically, we classify these type systems as either static or dynamic. A shift that’s taking place is to include type inference engines within a programming language that allows the developer to realize the safety benefits of static typing and the flexibility and expressiveness benefits of dynamic typing. I talked briefly about these ideas in The New Era of Programming Languages.

For many though, the whole type system issue comes down to compilation. Statically typed languages require type information because the compiler needs to verify that the type is not used incorrectly throughout the program. Dynamically typed languages typically don’t have a compiler, so the type verification is left to run-time.

So in general, we typically say that statically typed languages are safer because the compiler catches certain types of errors at compile-time, but dynamically typed languages are more flexible and expressive because we don’t need a bunch of language constructs to get us past the compilation step. A good example of this is an interface in Java. A class needs to implement an interface simply to get past the compiler. At runtime, that interface provides no value. Dynamic languages typically rely on duck typing instead of inheritance. Other interesting aspects of a language’s type system include covariance and contravariance, which are related to how types are ordered within a class hierarchy, and impact how the language deals with return types and method parameters.

But there is another dimension to a language’s type system that often goes unnoticed. A language is either strongly or weakly typed. For years, we’ve recognized Java as a statically typed language, while Ruby’s type system is dynamic. Because Java is statically typed, it’s natural to assume that is also has a strong type system, and since Ruby is dynamically typed, it’s easy to assume it has a weak type system. Not quite so true, however. Time for an example.

Let’s take the same simple program, written in both Java and Ruby. The code in Figure 1 is Java code that attempts to add a String and an int.

public class TypeSystemTest {
	public static void main(String args[]) {
		System.out.println("4" + 2);

Figure 1

Interestingly, Java performs an implicit type conversion, the program runs successfully, and the resulting output is seen in Figure 2.

> 42

Figure 2

An identical Ruby program can be seen in Figure 3.

puts "4" + 2<br />

Figure 3

Ruby, however, does not perform an implicit type conversion, and results in a TypeError. This output can be seen in Figure 4.

> TypeSystemTest.rb:1:in `+': can't convert Fixnum into String
             (TypeError)	from TypeSystemTest.rb:1

Figure 4

In some cases, Ruby is actually more strongly typed than Java, but the dynamic type system of Ruby delays discovery of the problem until runtime. Java, on the other hand, is a statically typed language that uses implicit type conversion in special situations. This implicit type conversion results in a weak type system, meaning the program can suffer from undesirable side affects if the implicit conversion is not the desired conversion, yet no runtime error results.

The point here is that while Java is statically typed and Ruby is dynamically typed, we cannot categorically say that Java is safer and Ruby is less safe. The runtime type system has the final say in making that decision.

My Ruby Kata

Filed Under Development, Ruby | Leave a Comment 

I was browsing through some older directories and stumbled across a Ruby programming kata I had done a couple of years ago. This is a simple kata where I calculate the payment for a loan based on interest rate, number of months, and loan value. I typically practice this code exercise for new languages that I’m learning, and I go through a progression of steps that help me understand the language sytanx and semantics first, before moving onto improving my design, using other features and frameworks of the language, and making it accessible via the web.

I was actually pretty surprised that the exercises still worked, save for a few scripts I had to change. The code hasn’t been touched for about two years, and I was very shocked I didn’t experience the phenomena where code that goes untouched for prolonged periods of time tends to somehow break. Strange, isn’t it? Anyway, I’ll walk you through the four versions. You can find the code for each of the versions in my Google code repository. To checkout all versions of the kata, simply do the following:

svn co

Version 1

It doesn’t get much simpler than Version 1. Just two files. Input.rb manages the command line interaction, and prompts for the rate, months, and value. Loan.rb performs the calculations. To run this sample, just type

ruby Input.rb

and enter values, such as 6, 60, and 15000. There is also a testcase, named LoanTest.rb.

Version 2

The second version has some minor enhancements over the first.

  • Multiple output formats - In addition to the showing the monthly payment amount for the loan, this version adds the option to also print the complete payment schedule, including principle and interest paid each month, along with the remaining balance of the loan.
  • Incorporate a test suite - I added another test for the payment schedule.

To accommodate printing the payment schedule, I modified Input.rb to prompt the user to choose to print either the payment schedule or monthly payment. I also added a new method to Loan.rb called calculatePaymentSchedule. To address the running total that I need to keep track of when calculating the full payment schedule, I also added PaymentSchedule.rb to represent the complete payment schedule. Within the PaymentSchedule instance is a collection of Payment.rb instances - one for each monthly payment.

You can run the sample in the same manner as before. Just be sure you’re in the V2 directory when executing.

Version 3

The third version is virtually identical to version 2, except here I figured I’d experiement with rake. So the only change you’ll fine here is the rakefile.rb, shown below for convenience.

require 'rake/testtask'

task :default => [:unit_test] do | tsk |
 tsk.libs << "./app:./test"
 tsk.test_files = "AllTests.rb"

There is a pretty lengthy discussion of my initial struggles with rake in the trouble.txt file included with this version. Suffice it to say that at the time I performed this kata, I had trouble finding good documentation that showed me how to do what I wanted. The only real change I’ve made recently to the rakefile was to use the PATH_SEPARATOR constant in lieu of hardcoding the separator (”:” or “;”), which I struggled with for a while when I got my Mac.

Version 4

Here, I wanted to take the code and transform it into a REST service. I wound up making it work by replacing Input.rb with Server.rb. It didn’t really wind up all that RESTful, but oh well…it works. I also added something else I’m pretty fond of, which is test coverage using RCov. My trials and tribulations with making this accessible via the web can be found in V4.txt.

To run the sample, just type the following in the terminal from within the V4 directory.

ruby Server.rb

You’ll see the server startup, then you can access the sample at http://localhost:8181/loan. In doing this, you’ll get back a response that shows you the URL parameters you’ll need to add. You can also click right here to the fully customized URL with sample parameters. Pretty simply really.

I also suggest you take a look at the rakefile.rb included with V4 because it uses rcov. As you can see from the rake tasks that have been commented out, at one time I had this working with CruiseControl.rb, though I no longer do because that bit of funtionality did succumb to the phenoma of code that isn’t exercised eventually breaks. Invoking the build with CruiseControl.rb would be a good exercise, as would the numerous other improvements that could be made to the code. But I’ve been done with this Ruby kata for about two years, and don’t intend to do anything else with it. I’m only sharing it as an example of what I like to do when learning a new language. Time for a Scala kata, Clojure kata, Fan kata, and more.

Rake TestTask Hangs

Filed Under Development, Platforms, Ruby | 11 Comments 

Here’s the test task in my rake file. Works on Windows, but not on my Mac. It just hangs. What’s the problem? do |t|
  t.libs << "./app;./test"
  t.test_files = FileList['test/test*.rb']
  t.verbose = true

Two hours later, I tell you that I need this on my Mac. do |t|
  t.libs << "./app:./test"
  t.test_files = FileList['test/test*.rb']
  t.verbose = true

See the difference? Semi-colon…colon…Wow…