Examining the code needed to read a file line by line is a a common way to examine the hoops a programming language makes you jump through. While Perl certainly has some one-liners for this, let's start with Ruby, which presents an elegant and clear way of doing it:

File.open("some_file.txt") do |file|
  file.readlines.each do |line|
    puts line.upcase
  end
end
It really doesn't get any clearer than that.

Here's the canonical Java way of doing it, complete with plenty of places to introduce bugs:

import java.io.*;

public class ReadFile {
  public static void main(String args[]) throws IOException {
    File file = new File("some_file.txt");
    BufferedReader reader = new BufferedReader(
      new FileReader(file));
    String line = reader.readLine();
    while (line != null) {
      System.out.println(line.toUpperCase());
      line = reader.readLine();
    }
    reader.close();
  }
}
Yech. The need to call readLine() twice kinda sucks. We could use a do-while, but that requires a second line != null check. Personally, I like to forget the second readLine() and wonder why my code runs forever :) That being said, this was extremely easy to figure out, even the very first time I did it in 1998. The class names are obvious, and the documentation is excellent.

Scala to the rescue, right?

import scala.io._

object ReadFile extends Application {
  val s = Source.fromFile("some_file.txt")
  s.getLines.foreach( (line) => {
    println(line.trim.toUpperCase)
  })
}
This was a slight pain figure out. I looked in scala.io and, of the few classes that were there (including a curiously named BytePickle), it appeared as though Source was the class to use. Of course, there's no easy way to create one from the constructor, and the scaladoc doesn't just say "Dude, look at the Source object". Once I looked through the Source object's scaladoc, the solution presented itself.

Of course, unlike every other line-traversing library in the known universe, Source leaves the line endings on. This is thankfully fixed in 2.8 (by which I mean 2.8 breaks 2.7's implementation, which is a strange thing for a point release to do). The real question is: "Is this how I'm supposed to read files in Scala?". With a class called Source?!. The scaladoc says that this class represents "an iterable representation of source files". That might explain the strange methods like reportError and reportWarning. I guess this is only for writing the Scala compiler? If so, scala.io seems an odd place to put this.

So, my answer is "No, this cannot be how to canonically read files in Scala". Since the Java way kinda, well, sucks, what alternatives are there? There's scalax.io, which seems to implement this as a class called, curiously, FileExtras. I'm not sure if this code is actively maintained, but it's documented in classic Scala style: terse and full of loaded terms like "nonstrict". Nevertheless, there seems to be some code here to easily read a file "the easy way" (despite some distracting names).

This points out a big difference between "Scala the language" and "Scala the library". Scala the language is very interesting and has a lot of potential. Scala the library is schizophrenic at best; it's not sure if it wants to be OO, functional, or what. The documentation ranges from sparse to absent, and the overall designs of the classes and package range for sublime to baffling. Years different from Java 1.1.

 
 

Got a few questions about how I set up ❺➠.ws (which is powered by Shorty, my Scala-based URL shortener), so I thought I'd write up how I got it working. Short answer is that it was pretty easy.

I got the idea from John Gruber, who made a similar thing for his site to post entries on @daringfireball. The trickiest part was figuring out what this was called so I could find out who could sell me a domain with unicode characters in it.

It turns out, this is called an IDN (short for Internationalized Domain Name), and not everyone will sell you one. Couple that with the need to get a non-.com domain, and I had to hunt around for a while.

I ended up going with DynaDot as they could provide the wacky hostname that I wanted as well as a .ws TLD registration. I was amazed at the number of domain regstrars whose web forms could not handle Unicode. It's been almost 7 years since Joel Spolsky wrote his screed on dealing with Unicode, so I don't know what the deal is.

At any rate, the tricky bit in actually using the domain, because a) entering ❺➠ into vim is nontrivial, and b) I doubt that Apache's config file would work with unicode characters in it. Enter Punycode, which is an asciification of any IDN. Fortunately, the domain host provides the Punycode for your IDN, so configuring apache was a matter of:

<VirtualHost XXXXX>
ServerName xn--dfi5d.ws
ServerAlias www.xn--dfi5d.ws
DocumentRoot /home/webadmin/xn--dfi5d.ws/html
<!-- whatever else goes here -->
JkMount /s* ajp13
JkMount /s ajp13
  <Directory /home/webadmin/xn--dfi5d.ws/html>
    Options Includes FollowSymLinks
    AllowOverride All
  </Directory>
</VirtualHost>

At this point, it pretty much worked, although it was sometimes difficult to get curl to work with the non-punyied name.

One thing that was weird was that I found that a lot of domains I wanted to try were taken or not available (with no explanation). Often it seemed like the punycode version was a normal looking URL that was taken; I tried several IDNs that had a unicode character with a wierd "5", and they punyied to an ascii 5. Not sure what the deal is there, but I eventually found the one I wanted.

 
 

Been working with Spring MVC recently. My enthusiasm has waned somewhat, as I've discovered that for all of it's tweakability and configurableosity, it omits what I believe to be incredibly obvious things:

  1. Simple, 80/20 conventions by default - While the phrase "convention over configuration" appears numerous times in the Spring documentation, it is still unable to call the foo method of the class BarController when I request the url bar/foo without a lot of configuration, some of which subtly conflicts and causes silent failures. The default configuration is useless
  2. Debugging the Routing - I shovel angle bracket after annotation after angle bracket into Spring and it simply can not tell me what URL patterns are mapped to where, and why a given URL isn't mapped, nor what to do to get it mapped. It's whole purpose is to map URLs to controllers. Shocking.
  3. Simple internal routing without magic strings - If I've mapped FooController's bar method, shouldn't I be able to redirect/route to that in code via route(FooController.class,"bar"), regardless of the specific URL that FooController and bar respond to? Instead, I've got magic strings everywhere and if my urls ever change, god help me. And don't get me started about accessing this stuff via tests.
  4. Simple web-testing - Adding a dependency on JWebUnit doesn't cut it. Jetty and Tomcat cannot hot deploy. How do people test these things??!?!
  5. Test Fixture Support - I had to hack this up with DBUnit. With maven in the mix, it's a huge hit to productivity, but at least I have it. What project doesn't need this??!?!

 
 

If you haven't checked out Prezi as a means to create presentations, you really should. They have rethought the entire user experience, and it's totally awesome. To give you a flavor of it, I created a presentation of my blog on Deconstructing Scala's Map Literal. I can't create audio in the format Prezi requires, so there's no voice over, but I think it still works.

 
 

I finally got around to finishing Shorty, my url-shortener for my vanity short-domain, ❺➠.ws. I did the whole thing in Scala as a way to create a fully-functining application that I would use and that I could finish in my non-work time. Scala unequivocally made this task enjoyable and quick. J2EE, on the other hand, did not help one bit.

The Good

Scala

My Scala code is so much shorter and easier to follow than the Java equivalent. Consider this code that, given the request path, finds a controller to handle it, and then calls the appropriate method based upon the HTTP method:

route(path) match {
  case Some(controller) => {
    val result = determineMethod(request) match {
      case GET => controller.get(params(request))
      case PUT => controller.put(params(request))
      case POST => controller.post(params(request))
      case DELETE => controller.delete(params(request))
    }
It's highly readable, and very concise; the Java version would've required a lot more variables, some noisier control structures, and a lot more braces and parens.

ScalaTest

ScalaTest resulted in a lot more readable code than JUnit or TestNG would've. Because of Scala's syntax, the tests are also free of weird dots and "literate" syntax that isn't quite that literate.

it ("should respond to get for a URL that is known") {
  val controller = new OneUrlController(hasher,"738ddf")
  val result = controller.get(Map())
  result.getClass should equal (classOf[URL])
  result.asInstanceOf[URL].url should equal 
    ("http://www.google.com")
}
The delineation between "expected" and "received" could not be more clear. assertEquals just isn't the same. The latest version of ScalaTest has some BDD options that look really great.

The Bad

SBT

I really wanted to like SBT, and, while it's a billion times better than maven, it's still not as easy to use as I'd like it to be.

I like:

  • Building code and downloading dependencies are separate
  • The save/run-tests loop is very handy
  • JavaRebel + re-deploying the webapp on file save is very handy
However:
  • The test output is horrid; big huge stack traces
  • Constant OutOfMemory errors that it traps and then doesn't exit. I had to kill -9 SBT a lot
  • Still more complicated than shell scripts
I believe that a build tool should be a DSL for automating software development tasks, which means it should be more concise and easier to use than UNIX shell scripts. Ant, Maven, and SBT fail miserably at this.

While SBT is light-years ahead by using an actual programming language, I found it very difficult to customize. Part of this is that the scaladoc tool gives developers no help in documenting their API, but, when it comes down to it, Scala and Java are not system automation languages.

scaladoc

Scaladoc is nowhere near as powerful as Javadoc. It makes it very hard to document how to use your code. Scala should have a more advanced documentation system than Java, but it actually has a much more primitive one; even RDoc is better. Hopefully, as Scala's popularity increases, the tools surrounding it will improve.

The Ugly

J2EE Deployment

Deployment is an underappreciated aspect of why Rails is so easy to use; copy/push your code to the production server, tell it you are running in production, and go. With J2EE, you get NONE of this.

If you want to alter configuration based upon environment, you are entirely on your own. J2EE, Ant, Maven, and SBT give you no real help or support; you have to roll it yourself. I'm just shocked at this omission; J2EE is ten years old and still has not provided a solution for something that every project needs. Amazing.

Servlet Spec

Java 5 is at end of life. The latest released Servlet Spec still doesn't support generics and is still completely schizophrenic about it's API (some methods use Enumeration, some use arrays, some use Iterable. Ugh).

The 3.0 spec looks slightly more sane, but it really doesn't do us any favors. web.xml is a trainwreck of stupidity, there's zero support for conventions, and the whole thing just feels like a solution designed for a problem that few of us ever have.