30 October 2008

Developing on iPhone and Android

When the iPhone SDK came out early this year, I was one of the first to sign up for the beta program. I was excited by the possibility to develop on the platform and quickly started reading through the documentation and watching developer videos as I began development of what was to be my first iPhone app. Unfortunately, Apple put one too many roadblocks in place, making the iPhone an undesirable platform for me to work on:
  1. Apple prevented all discussion of iPhone APIs by developers. I tried to ask a simple API question on an Apple developer board, and although a nice explanation why no one could answer me was sent to the board (see the mailing list archive), I actually received obscene emails attacking me for having the audacity to break the SDK's non-disclosure agreement. The draconian NDA clause was removed a few weeks ago, but even then was long after the beta period was over.

  2. Apple charged a fee just to get the developer kit working on an actual device, but then never gave many developers, including me, the unlocking codes to do so until long after the beta period ended.

  3. Apple is still playing games with developers by occasionally pulling legitimate applications off the App Store.
In the end, I gave up and decided to work on Google's Android instead. First of all, Google got Android right by making the tools free and the restrictions few. Another nice benefit was the rich tools available to Android developers due to the Android SDK's use of Java (which has the added bonus of letting me use Scala for Android development!). So far, developing for the Android has been great-- straight-forward APIs, good tools, good documentation. Maybe someone got mobile OS development right.

Related Links:

25 October 2008

Bad Code

Every programmer has experienced it. Code that is so bad, you have to share it with someone. Here are some recent gems I have encountered.

Poor man's comments.
If 1 = 0 Then
End If
Is nameString empty?
if (nameString + "x" != "x") {
Hmm, is the comment wrong, or the code?
// Comma-separated list of numbers
string configurationIds = "254:762:2:236:23:5:21";

20 October 2008

JUnit Testing Scala in Eclipse

Being a fairly new convert to agile development methods, including test driven development, I knew the first thing I would want to get up and running with Scala was a unit testing framework. The NetBeans plugin has built-in JUnit support which served me very well. But I also wanted to get some unit testing working with the Eclipse plugin. It took me a while to get JUnit testing setup with Eclipse, mainly due to my lack of experience in the Java ecosystem. To help future explorers down this path, here are a few lessons I learned.

Put the your tests in a separate source folder. See this tutorial on setting up JUnit in Eclipse for more information.

Add JUnit to your project's build path. Select the project and choose "Build Path" -> "Add Libraries...". Then choose the JUnit jar.

Add the output directory of your project to your build path. See this short guide from the makers of Spec.

To get you started, here is a simple test:
package tests

import junit.framework._
import org.junit.Assert._

class FirstTest extends TestCase {
override def setUp() = {

override def tearDown() = {

def testOne() = {
assertEquals(1, 1)

17 October 2008

October's Bay Area Scala Enthusiasts Meetup, Part 2

I promised some technical notes on the Bay Area Scala Enthusiasts meetup earlier this week, so here we go.

Coding Guidelines

As I mentioned previously, the presentation by the Twitter folks focused on the informal guidelines they have been using internally for Scala coding (PDF of their presentation). I like their guidelines generally. Something that may be controversial in the guidelines is their policy not to use implicits. DSLs especially can make good use of implicits, so I would imagine that would have to be the exception to their rule. Maybe someone should take their coding guidelines as a starting point to make a coding guidelines page on the Scala Wiki?

Structural Types

One of the topics mentioned at the meetup was structural types, which I hadn't used before, so I checked them out. Structural types seem to be a way to accomplish the same sort of "duck"-typing that you can do in Ruby and Python. Let's say you don't care about what the inheritance hierarchy of a parameter is, just that it can perform some operation. There are at least two ways to do this: traits or structural types.

Using traits:
trait Jumpable {
def jump() : Unit { print("Jumping!") }

class Bunny extends Jumpable { ... }
class PogoStick extends Jumpable { ... }

class Controller {
def makeThemJump(jumpers: List[Jumpable]) = {
jumpers.foreach { jumper =>
Using structural types:
class Bunny { def jump(): Unit { print("Jumping!") } }
class PogoStick { def jump(): Unit { print("Jumping!") } }

class Controller {
def makeThemJump(jumpers: List[{ def jump(): Unit }]) = {
jumpers.foreach { jumper =>
The Twitter guys pointed out that it might be a good idea to avoid structural types due to their use of reflection, which may be slow.

Dependency Injection

How to use dependency injection (DI) with Scala was brought up. There was some argument on how applicable DI was in Scala, with developers coming from a Java background supporting it and those with a Ruby background questioning its relevance to Scala. Either way, this in depth article by Jonas Bonér was brought up.

Development Environment

There was a short discussion on what ide/editor people were using for Scala. The Twitter guys were using TextMate or Emacs, and a few people in the audience mentioned Eclipse and NetBeans. I am really curious what luck developers have had with the different environments. I am using NetBeans right now, but I am not completely happy with it. Can anyone make any recommendations?

15 October 2008

October's Bay Area Scala Enthusiasts Meetup

Tonight I attended a meeting of the Bay Area Scala Enthusiasts, a user group focused on the Scala programming language. The meeting was held at Twitter's office in San Francisco, only a few blocks from my company's office, so it couldn't have been more convenient for me. I expected to encounter around 5-10 people there, but I was surprised when around 30 had gathered. The Scala community is definitely growing!

Alex, Steve, and Robey from Twitter hosted the meeting, and explained how they are using Scala at Twitter. They are using it both in middleware and in front-end code and seem to be committed to expanding its use in Twitter-- good things for Scala and Twitter both. Their main presentation focused on establishing a set of coding conventions for the Scala community, which I think could be a really good help for new programmers to have some structure. Robey showed us some of his open source code up on github, including configgy, which I plan to take a serious look at soon.

Some other interesting discussions at the meeting included preferred development environments and strategies to deal with the paradox of being paralyzed by having multiple ways to accomplish the same thing in Scala, usually at least a functional and an object-oriented way of doing things. The concensus seemed to be that each group will ultimately end up with their own style or Scala programming, somewhere between the extremes of writing Java in Scala or Haskell in Scala.

We also learned that there are no less than three Scala books in the works:
  1. Programming in Scala by Odersky, Spoon, and Bill Venners (who was also present and shared some good stories about his experiences in the language as well as the origin of the "/:" operator)
  2. Programming Scala: Tackle Multi-Core Complexity on the Java Virtual Machine by Venkat Subramaniam
  3. Programming Scala by Alex Payne and Dean Wampler, published by O'Reilly
Notice a pattern in the titles?

All in all, a great meeting where I meet some very interesting people. It's great to see the community of Bay Area Scalists so... well, Enthusiastic :)

Added exact authors of the new O'Reilly Scala book.

10 October 2008

Reflections on Scala

In my professional programming career, I have been a mostly object-oriented programmer, programming in C#, Java, Python, and C++. Throughout this time, though, I researched functional programming languages from Scheme to Haskell. While I was frequently fascinated by them and they definitely stretched my mind, I never found them to be as practically usable as the relatively new language Scala.

Scala describes itself as a fusion of object-oriented and functional programming languages, and while that is true, it certainly does not give the language justice. Scala has let me leverage my familiarity with object-oriented languages like C# and Java, but add in functional elements as I go along. This has been great for me since I am most comfortable developing real-world applications in an object-oriented style, as I suspect most professional developers are these days. After I have the basics of my program done in an object-oriented style, I can start adding in more functional features. I have never found a language that makes this easier.

To me, the biggest stumbling block for programmers new to Scala is that most of the official documentation describes Scala's functional features very well, but lacks in depth discussions on how to transition to Scala from an object-oriented background. My advice if you are new to Scala and you're an object-oriented developer, learn how to program Scala in a object-oriented way first, then add in functional stuff.

Finally, I have tried two IDE plugins that offer Scala support: one for Eclipse and one for NetBeans. Of the two, I find NetBeans to be more stable, faster, and better able to deal with Scala syntax than Eclipse. There are definitely still some bugs for them to solve, but I'll be sticking with the NetBeans plugin for my Scala development in the near term.

03 October 2008

Scala's Community

I am studying the functional/object-oriented language Scala right now and I thought I'd share a few observations about this language and the community around it:

Last night I was having some issues getting Eclipse's Scala plugin to work correctly. Frustrated, I went on Scala's IRC chat room and made an off-hand comment on my problems. The maintainer of the plugin just happened to be in the room at the time, and pointed out my problem, quickly setting me on the right path. My first "technical support" question solved!

A great little tutorial for getting someone familiar with Scala from the Java/C# school of object-oriented programming is Daniel Spiewak's Scala for Java Refugees. Highly recommended.