Nevercertain.com

Android Scala Installer

2012-01-02T00:00:00-05:00

Using Scala on Android

I'm a big proponent of Scala for Android development. Scala is a modern JVM language with great Java interopability. This makes it ideal if you're tired of writing Java. I enjoy writing elegant code and I appreciate how Scala helps me in this regard. Scala has a number of features that enable me to write better code, such as pattern matching, functions as first class citizens, a powerful type system, a very comprehensive collections library and many others. the features that Scala brings to the table.

With that said, using Scala with Android is not without its problems. Those include:

Increased binary size (100kb to a few megs)
Worse IDE support than Java
Slow build times (thanks to the need to run ProGuard)

The last one, slow build times, is by far the most pernicious of these. The increase in binary size is usually pretty small. IDE support is improving every day and it's really not in a bad place right now with good support now in both IntelliJ and Eclipse. However, waiting about 2 minutes from clicking 'Run' in IntelliJ to seeing the application run on your device is awful.

Building a Scala application for Android takes so long because of the need to run ProGuard against your application. Because of limitations in the dex file format, the Scala library jar can't be convertted to a dex file. So, ProGuard is used to strip out unused parts of the Scala library every time you compile your Scala code. This process is very very slow.

There are ways around this. The Scala Android SDK from EPFL contains a script that will break the Scala standard library up into small enough chunks to be dex'ed. From there you have a couple options.

Jan Berkel details how to add the dex'ed Scala library to your device's boot classpath so that they'll always be available. Unfortunately this is a manual process with a few scary steps. I've put off doing it myself for some time.

Another option that I don't see anyone doing is modifying their build tool to include the dex'ed Scala library in your Android application every time. This would make your APK about 8megs larger, but would let you skip the ProGuard step and you could just use the normal Scala library + ProGuard when building for the market.

Lastly, Johannes Rudolph came up with another option which Macarse blogged about here. The idea is to install the Scala standard libraries on the device as a shared library in the same way that the Google Maps SDK is installed. This works best for me since it's repeatable and straight-forward.

I converted the original installer to Scala and added the Scala 2.9.1 libraries plus an uninstall option. Details for referencing the shared libraries in your project can be found on GitHub.

The best place to get the installer is from the Android Market. The installer is published under Mobile Magic Developers. We will provide bug fixes and updates to include new versions of Scala.

The installer requires root permissions and will be creating files in system directories on your device. Use it at your own risk.

What TDD is and is not

2012-01-01T00:00:00-05:00

Let's define "practicing TDD"

Test driven development itself is well defined.

However, since software development methodolgies are like religions you can't be considered a practitioner unless you follow the practice 100% of the time. Just like religion. Right?

(Also, who cares if you're considered a practitioner? Why does that matter?)

This is absurd anyways. I take baths. I am not, however, taking a bath right now. Does that mean I do not bathe?

Let's get rid of this ridiculous notion of saying when and how often you should practice TDD. Just do it when you can imagine a net benefit to doing so. How's that? If you don't THINK there is a reason to TDD a particular piece of functionality then DON'T! Do not make TDD a dogma. It's that simple.

Like any practice, as you continue to write tests and write them before actual code you'll get better at it. You'll think more about how you'll test the software you're going to write. Over time a new skill will develop and you'll find yourself covering more kinds of functionality with tests.

Sometimes you don't have much choice

You'll also find social pressure on teams pushes the practice of TDD. This is an unfortunate reality that I do not know the answer for. Teams adopt practices for the sake of quality and consistency. Individuals do not always agree with team decisions. My suggestion here is to try TDD for a reasonable amount of time, ask questions, give it a fair shake. If you really cannot find any value in TDD afterwards, then you should do what you can to leave that team.

While I'm sure they are out there, I've not met someone who has learned and practiced TDD from someone else that did not find value in it. Having team members experienced with TDD is crucial here. Simply following the TDD cycle will not result in good tests. This takes time and experience.

What TDD is NOT

These are a collection of myths and strawmen about TDD. They come up from time to time in various forms. None of them present a reason to ignore the practice.

A means of changing software with zero impact.

High automated test coverage with good unit tests reduces the delay of some feedback regarding the impact of changes. Writing tests first encourages both high test coverage by ensuring the tests actually get written. It also forces the developer to think about clients of the code before writing the code which helps reduce coupling. Higher coupling, by its nature, increases impact of changes so reducing this helps as well.

Unfortunately nothing can remove the impact itself. The impact of changing software fans out along many different axis, only some of which are even partially covered by automated testing.

A practice that yields benefits when followed blindly

Unit tests can be a source of problems. Test suites that are full of brittle tests which are just reverse implementations of the actual code provide no benefit. Tests which take so long to run that they only get executed once a day or once a week aren't helping you reduce delays in feedback. Both of these can arise from a team practicing TDD without reason.

This point is actually quite obvious. After all, why would you follow any practice blindly?

Dictating that a developer practice TDD when that developer isn't convinced of any reason to do so will result in exactly that. If your team isn't convinced of the benefits of any practice that it employs then you have a very serious problem. That is the problem that should be addressed first. Doing otherwise is a crucial mistake.

An end

The practice of TDD itself is not a benefit. If you can achieve the benefits that TDD provides without the practice then there's no reason to employ the practice. There are also scenarios where you do not need the benefits that TDD provides.

But WHY does it matter if you write the tests FIRST?

Frequently asked, seldom answered clearly.

If you do not practice TDD then the idea of writing tests before writing code may sound absurd. Why on earth would you do that? I'm used to writing CODE first! This is amplified by the fact that we (humans) are really bad at estimating the time-cost of things we don't do regularly. Ok ok, I'm rambling without answering the question. Why write tests first?

Writing tests first yields benefits that writing tests after does not.

Those benefits are:

Better test coverage. I'm human, I will inevitably fail to cover branches of code with tests if I write them after the fact. I am less likely to do this with the TDD cycle.
I end up thinking more about the code I'm going to write before I write it. The reason this is good is that once code is written and working then I'm less likely to change it. Code that hasn't been written is cheaper to change than code that has.
I know immediately if the code is difficult to test and can evaluate whether or not this is incidental or inherent difficulty. This relates to the previous point but is more specific.

Conclusion

I and many others have found TDD to be an extremely useful practice. It helps ensure high test coverage, it provides you with early smells about bad design. Writing tests first feels foreign and this makes us feel like it's silly and could only work for the trivial examples you see in books and screencasts. This feeling is WRONG. I have been on large (30+ developer), medium and small teams which have employed TDD successfully. Our code coverage was always high (85% is the worst coverage number I recall, usually higher than 90%). TDD ONLY works when it is employed thoughtfully with intent. It WILL be a net loss on productivity otherwise. TDD is not a silver bullet, a dogma or an end. TDD is simply a useful practice.

Scala and Ruby Rosetta Stone

2011-08-17T00:00:00-04:00

I write a lot of Ruby at work and Scala in my spare time. I thought others who know one language but not the other might find a rosetta stone for the two languages useful.

For a more thorough rosetta stone for a variety of languages check out Rosetta Code.

The scope of each example is short so that it is easier to jump from one language to the other to compare specifics. There are a lot more things you can do in each of these categories in both languages. However, if there are other examples you think should be added then fork the gist in question and let me know about it in the comments.

Classes
Mixins
Collections
Hash maps
Case statements and pattern matching

Classes

Here are a few examples of how you might define some basic classes in each language. You can see here that Scala manages to be a bit more concise than Ruby.

Ruby

Scala

Mixins

Both Ruby and Scala support the idea of Mixins. They are known as modules and traits in Ruby and Scala respectively.

The examples below are mixins that specialize the results of an existing method on the target class. Classic examples of this are Enumerable in Ruby, and Seq in Scala. Each of these depend on one or more methods in their target class. Since Scala is statically typed the trait must specify something about the class it will be mixed in to. You can do this with both nominal (named) types and structural types (similar to duck typing). I show both of these in the Scala example below.

Lastly, the Ruby example depends on in_groups_of which comes from ActiveSupport (part of Rails).

Ruby modules

Scala traits

Collections

Below are a few of the things you can do with collections in each language. Scala has a bit more flexibility here when it comes to allowing you to pick the kind of performance characteristics you want. However, when in doubt, just use an IndexedSeq.

Scala also provides mutable and immutable versions of their collections. Ruby collections are mutable but that doesn't mean that each of the methods on a Ruby array will mutate the array. Enumerable#map, for instance will return a new array. The convention in Ruby is that if a method ends in ! then it will mutate the object and otherwise it will not. This convention is mostly observed in the core and standard libraries, but not entirely. Array#delete, for instance, is a Ruby core library method that mutates an object but does not end with a !.

Ruby collections

Scala collections

Hash maps

Each languages' core library comes with a hash map implementation. Ruby calls theirs Hash and Scala theirs Map. Great.

Ruby has hash literals which is convenient. Scala's flexible syntax allows a really close approximation of hash literals, syntactically, without the addition of specialized syntax for them.

Ruby hashes

Scala maps

Case statements and pattern matching

I don't care much for mentioning case statements in Ruby on their own. They are, however, the closest corollary to pattern matching in Scala. Scala's pattern matching support is very powerful. I'll present how you would accomplish some similar tasks in each and then show a few more powerful pattern matching examples in Scala.

Ruby case statements

Scala pattern matching

RoboSpecs - Android testing with Scala

2011-05-04T00:00:00-04:00

I recently published Robospecs. Robospecs helps you write Android applications.

Robospecs doesn't really do much itself. The real work is done by Robolectric and Specs2.

Robolectric

Robolectric lets you TDD your Android applications by giving you a way to run Android unit tests outside of an Android emulator. Normal Android "unit" tests have to be executed inside an emulator. The android.jar files that Google provides as part of the Android SDK cannot be used to actually execute code such as unit tests. Every object's constructor merely throws an exception. Google suggests you write all of your tests using their test case which executes your code inside of an emulator inside a real Android environment. This is appropriate for some levels of testing, but makes a TDD workflow quite onerous.

Robolectric provides an implementation of much of the Android components you would normally interact with and always a means to add additional implementations yourself for Android classes which aren't covered. Robolectric also sets up an Android environment so your code can inflate layouts and access other resources. See pivotal.github.com/robolectric for more information.

Specs2

Specs2 is a great testing framework for Scala. Specs2 provides a elegant DSL for writing tests and assertions. It's a fantastic framework to use to test either Scala or Java code. See specs2.org for more information.

Robospecs

What Robospecs does is bridge the gap between Robolectric and Specs2. Out of the box Robolectric provides support for JUnit via a custom JUnitRunner. During test runtime this JUnitRunner executes your tests using a custom Robolectric class loader. Robospecs provides a trait which you can mix into your specs that performs the same function. Robospecs is very non-invasive to your existing specs. Check out the project page at GitHub for more information.

Example Project

You can find a working, albeit very simple, sample Android project on GitHub at https://github.com/jbrechtel/robospecs_example. This project uses SBT to build.

XCode - Some thoughts

2011-03-19T00:00:00-04:00

Warning: This is a bit of a rant. It's mostly intended to be therapeutic for myself.

Our team has recently started down the road of writing a native iPhone app. I'm very happy about this. I've been wanting to have write an iPhone app for some time and haven't had the opportunity to. Having done a fair amount of Android work and really enjoyed the platform's API I wanted a first hand account of how iPhone compared to that.

So far, I have no major issues with Cocoa applications on iOS. Building the UI is, for the most part, much more straight forward here. Apple has taken great care to make it easy to build pretty UIs on iPhone. This shows. However, I haven't yet written enough code yet to compare the two platforms SDKs. One reason I haven't written enough is XCode....

XCode 4

So, fate would have it that XCode 4 got released a few days before we started to play our iPhone app cards. On the surface, this seemed opportune because it's supposedly a big improvement over XCode 3. Unfortunately we quickly learned that also means that most of the help we could find on the internet for common tasks were not applicable to XCode 4.

Zombies (AKA: Night of the living option key)

Very soon into our Objective-C foray we discovered we were calling methods on an object whose memory had been freed. In hindsight the solution is obvious: retain the object then release it once we're done with it. However we wanted a general way to combat this problem so we quickly came upon the idea of turning on Zombies. Zombies are a neat feature of Objective-C that allow you to find out exactly where you're talking to objects that have been freed. This is super useful to a budding Objective-C developer.

How do you turn them on? You simply set the NSZombieEnabled environment variable to YES.

That sounds easy enough, environment variables are pretty straight forward and it can't be THAT different from XCode 3 to 4 can it?

We spent a few minutes hunting for the word 'Environment' in the GUI to no avail. We googled for this issue and found almost nothing but directions for doing it in XCode 3.x. Then we finally found this post on StackOverflow.

http://stackoverflow.com/questions/2190227/nszombieenabled-in-latest-xcode

Already frustrated, imagine our reaction when the instructions say 'Click the Product Menu and HOLD DOWN THE OPTION KEY'.

Granted we later found a more direct way to get to the menu in question, but from this changed our opinion of XCode's UI from 'frustrating' to 'comically bad'.

Schemes, Configurations, and Targets, oh my!

This morass of concepts for building a project is maddening. Apple could really take some direction from the Ruby world here and adopt/create a humane build configuration tool like Rake.

Building projects does not require this much complexity. Adding this Scheme concept which is only configurable in the GUI does developers a disservice. GUIs are fine when you're manipulating graphical things, but they are outright hostile to editing text. Schemes are essentially a grouping of targets and build configurations, which themselves comprise text settings. If Apple wants to provide some GUI editor for these settings, then fine, but at least separate them into different files that are each human editable and mergeable by my VCS tool!

Is configuring the build for an application really this hard? I've done .NET, Java, Scala, and Ruby projects in the past and we've never needed this many concepts. We generally have a single build, with some customizations for different environments (development, testing, production, etc..). Introducing complications beyond this has never yielded any fruit in my experience.

Now, I understand that there's a fundamental difference between XCode projects and the others that I mentioned. XCode projects may target a variety of architectures while the others I mentioned all run in a VM. However, that's the only fundamental difference from what I can tell and it's pretty easy to address with a build flag or an environment variable, IMHO.

Merging

Maybe I'm missing something, but XCode's project config file presents a really annoying hurdle to collaboration.

Any change to it by multiple people causes merge conflicts
It occasionally changes without you explicitly changing any project settings
It's not something you should attempt to merge by hand
XCode crashes immediately when the file becomes invalid (say, you do a "git pull" and there's a merge conflict)

I don't know if these problems have always existed in XCode or if they're new to XCode 4. Hopefully they're new to XCode 4 and Apple will fix them in an update.

xcconfig files, some hope

Thanks to the super useful (and not at all obvious) info presented by Rob Napier here we were able to abandon the terrible XCode project file for most of our build settings in favor of configuration specific xcconfig files. This improved our situation a fair amount. Now there are fewer settings in the amorphous blob that is the XCode project file.

xcconfig files let you specify build settings in a simple NAME=VALUE format. You can associate them to specific build configurations (Release, Debug, etc...). To do so in XCode 4:

Click on your project in the Project Navigator (this should be the root of the project tree)
Select your project in the resulting window
Expand the desired configuration
There should be a dropdown showing all of the xcconfig files in your project. Select the appropriate one.

XCode 4 is pretty

One final thing that I actually like about XCode 4 is that it's pretty. Apple puts nice graphical touches on their products and XCode 4 is no exception. I appreciate the smooth and polished animations for things like highlighting [ ]'s as you type them. The transition effect used for displaying the auto-complete is also quite pleasant. While I can't put my finger on a specific benefit of these features I must say that I do like them.

No draggable and dockable tool windows??

I really like the way XCode handles tool windows. There are 3 of them (the ones on the left, bottom and right ). You always know where they are and hiding/showing them is done using a few easy to see buttons on the toolbar. I think Apple really got this right whereas most other IDEs seem to allow you infinite flexibility in this area and that tends to hurt. You'll never wonder where that stupid tool window went in XCode or why the hell it's docked on the top of the screen instead of the middle. +1 XCode.

Conclusion

While I do dislike XCode, it isn't the worst thing in the world and it even has some positives over others. I've tried worse IDEs (pretty much anything built on top of Eclipse that isn't just plain Eclipse), but I've also used much better ones that enabled rather than stifled modern development practices. In the end I can live with XCode and appreciate some of its niceties. However, I find it unfortunate that XCode lacks some of the things I've come to find really valuable.

Building Android Apps with Scala - IntelliJ

2011-02-18T00:00:00-05:00

note to the reader This is the third in a series of posts about getting started with Scala, Android and IntelliJ. The content here assumes that you already have a working install of IntelliJ and the Android SDK plus a project created using simple-build-tool. If you don't have these things then please check out Part 1 - Prerequisites and Part 2 - simple-build-tool)

IntelliJ Plugins

Before we get started we need to install some IntelliJ plugins.

In IntelliJ click File -> Settings
Scroll down to Plugins
Click the 'Available' tab
Install the Scala, Sbt, and Android plugins
Right click each plugin and select 'Download and Install'
Allow IntelliJ to restart after installing the plugins

After the plugins are installed we have to configure the Sbt plugin so that it can find the Sbt jar file. Go to File -> Settings -> Sbt to do this.

Creating the IntelliJ project file

Unfortunately, this part of the process requires a bit of hackery. My intent is to modify the Android Sbt plugin to create projects that are more suitable from the outset and combine that the work done in the sbt-idea plugin to automate this entire process. Until someone does that, these are the steps required.

Also, as I said in Part 2, nothing we do here will prevent us from building, packaging, deploying or testing our project using sbt from the command line. You should always be able to do that regardless of the IDE you are using.

Now, let's fire up IntelliJ and create this project.

Create Java project from existing sources
Enter a name for the project
In the 'Project files location' field, enter the path to the root of the project.
- This should be $project_path
- IntelliJ should find source files in $project_path/src/main/java
Click ‘Next’ and you should see the Libraries list
- There should be lots of libraries
Find the library named ‘lib’ and rename it to ‘scala_2.8.1’
Click ‘Next’ and you should the Modules list
- There should be one module, named Main. Rename to $project_name
Click ‘Next’ and you should see the Facets list
- There should be one facet, Android
Click ‘Finish’

Great! At this point, we’ve got some IntelliJ project files created which reference the generated Java source files for the project we created in Part 2.

Now we need to change a few things. IntelliJ still doesn’t know about our Scala source files and the IntelliJ Android plugin doesn’t know what Sbt is doing. Also, a meaningful ‘Run’ configuration from the IDE is nice.

Hacking up the IntelliJ project

Let’s get our source tree in order first.

Right click on 'Scala' folder.
Mark directory as Source Root
Right click on Scala and add package, 'com.test.myproject'
Rename Activity.scala to MainActivity.scala (we're trying to make IntelliJ happy)
put MainActivity.scala in com.test.myproject package just created

Configure the IntelliJ Android plugin

The Android facet expects some things to be in different places

Right Click on the project in the project tab and select Open Module Settings
Select Facets
Select Android
Select Compiler
In the section 'AAPT Compiler'
Change '$project_path/src/main/gen' to '$project_path/src/main/java'
In the section 'Android Packaging Compiler'
Change APK Path to '$project_path/target/scala_2.8.1/myproject_2.8.1-0.1.apk'

Also in the project settings make SURE that the Scala dependecy is set to to ‘Provided’ (NOT compile, test or runtime) so that if you ever let IntelliJ (instead of Sbt) build the project then it won't also try to generate Dalvik bytecode for the Scala library. The Scala library contains classes which have more functions in them than the Dalvik bytecode conversion tool can handle.

This issue is circumvented by the Sbt build process because Sbt uses ProGuard to remove unused classes and functions from the Scala library before converting it to Dalvik bytecode.

Now, let's show IntelliJ how to build our project

(Adding a Run configuration that uses Sbt)

In the IntelliJ menu, click 'Run'
Click 'Edit Configurations'
Click the + in the top left and select Android application
Enter ‘DeployRun’ in the Name textbox where it says 'Unnamed'
In the Module drop down select your project. (There should be only one item in the list)
Uncheck 'Make'
Check 'Run Sbt Action'
Click the ellipsis next to 'Run Sbt Action' and in the dropdown list/text box type 'package-debug'
Click OK to close that dialog
Click OK to close the Run Configuration dialog

You can now rebuild and run your project from IntelliJ by executing the DeployRun configuration.

You can setup other build configurations to execute additional Sbt targets.

Next time we’ll cover running your tests with the awesome ScalaTest framework from inside IntelliJ.

Building Android Apps with Scala - simple-build-tool

2011-02-03T00:00:00-05:00

This is part 2 in my series on getting started with Android development in Scala using IntelliJ. If you haven't already then check out Part 1 - Prerequisites. This post will cover getting your project created and using simple-build-tool to perform various tasks such as compiling, testing, packaging, and getting your app on a device. By the end of this post you'll be able to deploy your app to an Android device or package it for the market each with a single command.

A quick aside before we begin

This part of the series purposefully leaves out IntelliJ. I strongly believe that a GUI tool should not be required to compile, test, or deploy your code. My principal reason for this is so that I am always able to practice continuous integration. Requiring a GUI to build my software would prevent me from automating that process in any manageable way. The secondary reason for eschewing dependency on a GUI is so that I am free to pick whichever GUI or plain editor I want with as little hassle as possible. You can apply everything in this post whether your IDE/editor is IntelliJ, Eclipse, Vim, Emacs, or .

Creating our project

To create a new Android project, we’ll use the create_project script from jberkel’s android-plugin. This will create the initial simple-build-tool project structure including our project and plugins files. The create_project script has two required arguments: and

name: The name of the project and ultimately the name of the directory where the project will reside.
pkg: The Java package name to be used for our Android project.

Let’s call our project awesomepad and the package com.kickass.awesomepad Execute the following commands from our OS’s command line:

cd $root
./opt/android-plugin/script/create_project awesomepad com.kickass.awesomepad

Now that we've got an Sbt project setup. Let’s update the project dependencies next.

cd $root/awesomepad
sbt update

(Note: If the ‘sbt’ command is not found then please follow the instructions on the Sbt wiki Setup page first) At this point, it would be prudent (but not required) to familiarize yourself with how Sbt works. The BuildConfiguration page of Sbt’s wiki is a good place to start. For the rest of this post, all commands should be executed from the $root/awesomepad directory.

Using simple-build-tool

In this post I’ll often tell you to execute an Sbt task from a shell like this

sbt <task name>

That’s not the optimal way to interact with Sbt while we're actually working. The Sbt console provides a shell from which we can launch tasks. If we use the Sbt console then we won’t have to wait for the JVM or Scala compiler to start each time we execute a task. To start the Sbt console just execute ‘sbt’ by itself from the project root. Once inside the console we can start a task by just typing the task name and hitting enter. Also, check out TriggeredExecution. Very cool. Ok, now for more Android stuff

Some Android specific simple-build-tool tasks

jberkel’s android-plugin comes with several very handy tasks to help with Android development.

package-debug - Builds a debug APK that we can deploy to our phone.
start-emulator - Starts the app on an emulator, if one is running.
reinstall-emulator - Reinstalls the app on an emulator, if running.
reinstall-device - Reinstalls the app on an attached Android device.
start-device - Starts the app’s default activity on an attached Android device.
sign-release - Builds a signed APK that is suitable for publishing to the market.

Here are some non-Android specific Sbt tasks that are also good to know

clean - Deletes any compiled files and other artifacts.
compile - Compiles the project
test-compile - Compiles the tests
test - Executes the project's tests

When running all of the above tasks Sbt will automatically recompile if relevant source files have changed. However, it doesn’t know that changes to AndroidManifest.xml should cause a repackaging so when we change that file we'll often want to perform another package-debug or clean.

Deploying to our Android device

To deploy the project to a device just run the start-device task while a device is connected over USB.

sbt start-device

This will cause the project to be compiled, packaged, installed on an attached device and then its default activity started. If we were writing a widget, live wallpaper or something else without a default activity then we'd just use the reinstall-device task instead.

When this doesn’t work...

On Linux commands that interact with attached Android devices may report the following error

**[error] error: insufficient permissions for device**

This means our Android Debug Bridge (adb) daemon does not have the right permissions. There are two ways to fix this.

Option 1) We can Google “adb udev insufficient permissions” and find the correct udev rules to possibly make this work then update our udev rules and reboot. Find out something is wrong with our freshly updated udev rules and repeat the cycle until we give up and select Option 2.
Option 2) Just run adb as root. Execute the following commands

$root/opt/android-sdk/platform-tools/adb kill-server sudo $root/opt/android-sdk/platform-tools/adb start-server

IMHO it's best to execute the second line during boot.

To do this on Ubuntu just put this in /etc/rc.local. Everything in rc.local runs as root so 'sudo' isn't needed there.

Once adb is running with proper permissions then the start-device and reinstall-device tasks should work fine.

Running Tests

At this point the project has two separate directories for tests. One is an Android test project used for functional testing that can be found in $root/awesomepad/src/tests. The other is a ScalaTest project for unit testing that is located at $root/awesomepad/src/tests. I’m going to cover running the unit tests and skip the Android test project for another post where I’ll cover Android testing in depth. To run the unit tests just run the test Sbt task.

sbt test

This will cause the project to be compiled and the ScalaTest specs in $root/awesomepad/src/tests to be executed with a command line test runner. This test runner has rather crude output with very long stack traces when things fail. The formatting isn’t as nice as something like RSpec, but don’t worry because it will get better whenever we’re running these in IntelliJ.

Packaging for the Market

Preparing the app for the market is pretty straight forward. Before we actually release the app on the market it's important to should read the Preparing to Publish checklist over at the Android Developer site. The only step we’re concerned with right now is: Obtain a suitable private key. If you don’t have a private key already then follow those instructions until you get to step “2. Compile the application in release mode”. At this point you should have .keystore file. We’ll assume the name is awesomepad.keystore. Now we need to tell our Sbt project about this file so that the Sbt tasks for signing the app know where to find it.

Copy awesomepad.keystore to $root/awesomepad/awesomepad.keystore
Edit $root/awesomepad/project/build/Awesomepad.scala
Inside MainProject, override the keystore method to return “awesomepad.keystore”
- override def keystore = “awesomepad.keystore”
Set the keyalias val equal to whatever keyalias you used when creating the key earlier
- val keyalias = “myKeyAlias”

Note: My instructions here run somewhat counter to the conventions provided by the android-plugin. By default the AndroidProject sbt plugin, specifically the MarketPublish trait, assumes that the keystore is a file in our home directory name “.keystore”. This way there's can have one keystore for all of projects and our project file only needs to specify the key alias we want to use. This is all well and good, however it means that our project source tree does not contain everything we need to release or update our app in the market. I’d rather everything be in a single source tree so that I have less to keep up with. You say potato, I say potato...well you get the idea. Now that we’ve gotten a private key and told our Sbt project about it we can run the sign-release task and Sbt will create an apk signed with that key.

sbt sign-release

After running that command we'll be prompted for the keystore password. Enter the password for the keystore and then a signed apk is waiting for us in $root/awesomepad/target/scala_2.8.1.

That’s it for this time, check back later for part 3 where I’ll talk about setting up IntelliJ to use all of these wonderful Sbt tasks and then finally part 4 where we will use IntelliJ’s test runner to run our project’s unit tests.

Building Android Apps with Scala - pre-requisites

2011-02-03T00:00:00-05:00

This is the first in a series of blog posts about getting started with Android, Scala, IntelliJ and simple-build-tool. Hopefully this will help people who are interested in building Android apps, but don't want to write Java get started. Also, if you're already building Android apps, but would like a more expressive language while staying close to the metal then Scala is a great alternative to Java. By the end of this series, you should be able to build, deploy and package your Scala Android apps both from the command line and IntelliJ. My primary development environment is Ubuntu Linux but I will provide platform specific instructions where appropriate. These instructions assume that you have Java 1.6 installed and its environment variables setup. We'll be putting everything (except for IntelliJ on Windows and OSX) into the same directory on your system. On my development machine that directory is /home/jbrechtel/opt. Throughout this post I'll refer to this directory as $opt. I would suggest the following locations for $opt, by platform

Linux	/home/username/opt
OS X	/Users/username/opt
Windows	C:\Users\username\opt

Ok, let's start with..

Getting Scala

Head over to http://www.scala- lang.org/downloads and download the package for your platform.

Extract the Scala package to $root/scala.
Set the SCALA_HOME environment variable to $root/scala
- Linux: Add “export SCALA_HOME=$root/scala” to your .bash_profile
- OS X: See http://snipurl.com/apple_environment
- Windows: Start -> Run -> “setx SCALA_HOME=$root/scala”
Add $root/scala/bin to your system’s path

Now, that’s it for Scala. You should now be able to start a command prompt on your OS and type ‘scala’ to get a handy Scala REPL for testing things out.

Getting IntelliJ IDEA

Next we’ll get our IDE. IntelliJ IDEA has pretty good Scala support though it’s not without its flaws as we’ll see throughout this series. First, point your browser at http://www.jetbrains.com/idea/download/index.html and download IntelliJ for your platform. As of version 10.0 the Community Edition (read: Free) of IntelliJ IDEA supports both Android and Scala development. For great justice! Install the IntelliJ IDEA package. For Windows and OSX, IntelliJ installs like a normal application which I presume you already know how to do. For those of you on Linux:

Extract the tar.gz for IntelliJ to $root/opt/idea
To launch IntelliJ just execute $root/opt/idea/bin/idea.sh

I suggest creating a menu shortcut in Gnome, KDE, or XFCE to the idea.sh script. There are a number of IntelliJ icons in that bin folder which you can use for the menu icon. The files are named idea_CE{16-128}.png.

Getting the Android SDK

Let’s go get the Android SDK. Obviously we need this to build Android applications. We’ll only be grabbing the Android 2.1 platform here, but the Android SDK manager makes the other platform versions easy to get and install. The Android SDK can be found here:http://developer.android.com/sdk/index.html. Download the package for your platform from that site.

Note for Windows users: It looks like Google has made things easier on you by providing an installer. I’m not familiar with the installer, but it probably does everything you need it to do. However, the instructions below are written with the zip package in mind.

Extract the downloaded file to $root/opt/android-sdk
Set the ANDROID_SDK_HOME environment variable to $root/opt/android-sdk
- See the ‘Getting Scala’ section above for instructions per platform.
Launch the Android SDK Manager
- Linux: $root/opt/android-sdk/tools/android
- OSX: $root/opt/android-sdk/tools/android
- Windows: $root/opt/android-sdk/SDK Manager.exe

The Android SDK Manager is used to download the various Android platforms and other third party addons such as the Google Maps SDK and the Samsung Galaxy Tab SDK. For now we're just concerned with the Android 2.1 platform. Once the SDK Manager is running follow these steps:

Click 'Available Packages'
Expand 'Android Repository'
Check the box that says 'Android SDK Tools, revision 7'
Click 'Install Selected'
Click 'Accept All' to accept all licenses
Click 'Install'

Now the SDK Manager will download the Android 2.1 platform (also known as revision 7 or API Level 7 in Android parlance). If you receive a prompt about ADB needing to be restarted then just click ‘Yes’. Afterwards you can close any dialogs and the SDK Manager. Once that is complete, move on to the next section.

simple-build-tool

simple-build-tool / SBT is a (as the name suggests) build tool for Scala. It provides all the things you might expect from a modern build system such as:

dependency management (both managed and unmanaged dependencies are supported)
a DSL (in Scala) for configuring your targets and other aspects of the project
testing integration

simple-build-tool has a few things that I consider killer features:

A console/REPL with your entire project at your fingertips.
Triggered task execution (e.g. run tests automatically when source changes)

Download SBT by going http://code.google.com/p/simple-build-tool/ then download the latest version in the ‘Downloads’ section on the right side of the page. SBT has really good instructions for getting started on their project site. Check it out http://code.google.com/p/simple-build- tool/wiki/Setup

jberkel’s android-plugin for SBT

Once you have SBT installed, you should grab the awesome android plugin for SBT. This plugin primarily provides two things

A script for creating a new Android project that SBT can compile
Several handy SBT targets for doing things like packaging your app for the market and deploying to your device.

You can find this plugin on GitHub https://github.com/jberkel/android-plugin. Go there then click on 'Downloads'. Download verion 0.5.1 (newer version should work if available).

Go to https://github.com/jberkel/android-plugin
Click Downloads
Download the latest version (at the time of writing that was 0.5.1)
Extract it to $root/opt/android-plugin

Then you'll have the latest version of the Android project plugin locally. We'll use this in the next post to create our Sbt project with Android support.

That’s it for now!

Now, at this point you've got all of the required software installed. Let's review.

IntelliJ
- If you're using OS X or Windows then IntelliJ is installed as a regular application.
- If you're using Linux then IntelliJ is installed in $root/opt/intellij
Scala 2.8.1 is installed to $root/opt/scala
Android SDK (and the Android 2.1 platform) is installed to $root/opt /android-sdk
simple-build-tool is installed according to the instructions on their site
jberkel’s android-plugin for SBT

Next time we’ll cover creating the Android SBT project using jberkel’s fantastic android-plugin and also doing things like deploying the app to your phone and packaging it for the market. In the third post we’ll talk about setting up IntelliJ to edit the code in that project and launch your SBT targets. In the final post of this series we’ll go over how getting started unit testing in IntelliJ with ScalaTest. See you next time

The Mind of a Mnemonist

2010-10-12T00:00:00-04:00

I just finished reading The Mind of a Mnemonist by A.R. Luria. The book is an intriguing glimpse into a different way of thinking. Luria describes several sessions and written exchanges with Solomon Sherashevsky. Sherashevsky had synesthesia and an incredible memory. The book covers Luria's interactions with Sherashevsky over the period of about 30 years.

Memory

While Luria describes Sherashevsky's memory as eidetic (photographic), it isn't anything like what I imagined a photographic memory would be. For example, when given a list of words or numbers to memorize Sherashevsky would not merely take a mental picture of the list. Instead, he would construct a scene, often on a road near where he grew up, and place each item in the scene. He relied so completely on the vividness of the mental image he constructed that if he were to place an item somewhere that it would be hard to see, such as an egg near a white wall, then he might miss it during recall. Luria also mentioned throughout the book that Sherashevsky was able to recall lists of various items from their sessions decades prior.

Reality and Imagination

The mental imagery that Sherashevsky created were so real that they were able to trick both his cognitive processes and bodily function. Sherashevsky related accounts of how when he was a child he frequently fooled himself into thinking that time had stopped because he pictured that the hands on his clock had not moved. Even more intriguing was when Sherashevsky demonstrated under controlled conditions his ability to both raise and lower his heart rate and to change the temperature of his two hands at will. Sherashevsky's method for these feats was simply to picture himself in situations which called for it such as running to catch a train or holding a block of ice.

Control

Unfortunately for Sherashevsky, he didn't have much control over his rich sensory experience. When reading a story or listening to someone talk his mind would be flooded with images, sounds, and smells of all kinds. While it is likely that this extra sensory information contributed to his fantastic memory, it also made it very difficult for him to understand many things that we take for granted. A simple conversation would force his mind to wander in whatever direction his synesthesia directed him. It required great effort for him to focus on a single topic.

Conclusion

The book covers more topics than I have mentioned here such as Sherashevsky's personality and the challenges that abstract thought presented him. Luria's account of Sherashevsky is a very personal one for a patient and I'm thankful for that dimension of the story. It helped me having a real person I could relate to throughout the story. This made me wonder about how someone who can picture such convincing mental representations of people and places would cope with the loss of a loved one. It's a wonder to me how he was able to keep his sanity at all. Luria has a similar work, also in the genre of 'Romantic Science', titled 'The Man with a Shattered World: The History of a Brain Wound' that is probably also worth a look.

Evolutionary purpose

2010-09-26T00:00:00-04:00

I am really interested in how our minds work. Not having a background in neuroscience, neurobiology, or neuro-anything for that matter, I'm currently limited to reading lighter material on the subject until my understanding goes deeper. I've read books that cover the social side of how our minds (fail to) work (e.g. The Drunkard's Walk) and some that are more technical (but still light) such as How We Decide and On Being Certain.

At the moment I'm reading Seeing Red: A Study in Consciousness. In it Nicholas Humphrey, the author, aims to present an evolutionary purpose for consciousness which he argues is independent of perception. At one point in the book Humphrey writes the following regarding sensations: It is fair to assume the capacity has been designed in by natural selection.

I take issue with the assumption. I've always had a problem with this approach to reasoning about any single element of a species. Why must everything be 'designed in' by natural selection? It seems just as likely to me that any given attribute we or any other species posses could simply be a side effect of some other positive attribute which actually was 'designed in' by natural selection.

To be clear, my issue is not with the notion of human evolution specifically favoring sensations. A number of reasons come to mind in support of this point of view. My problem is really the order of the reasoning. To say that 'This attribute exists, therefore it must have an evolutionary purpose' seems absurd to me. I find it hard to believe that random genetic mutations are so delicate as to change only one thing at a time or that natural selection is so precise to weed out everything except the bare minimum needed to win.

Unless I'm missing something fundamental with evolution and natural selection, I suspect that Humphrey only presented his reasoning in this order for dramatic effect. After all, it is his stated goal to give an evolutionary purpose to consciousness.

However, it's still disconcerting how often I see that logic being used to reason about how we got in our current evolutionary state. It seems to be quite common among these light-neurosciency books I've been reading.

My HP Envy 14 is 'meh'

2010-09-04T00:00:00-04:00

I recently bought an HP Envy 14. I followed news about the laptop before it was release and was pretty excited. It's a nice size for me (14.5 inches), has a really good screen, was touted to get something like 6 hours battery life, solid build for a non-Macbook, and decent internals. Even with all this, I KNEW that a Macbook would suite me better. You see, I’m a recovering .NET developer. I’ve grown to really appreciate the flexibility of a Unix-based development and deployment environment. I’ve also had a fair number of laptops. Some Dell, some HP, and some Macbooks. My work-issued laptop is a Macbook Pro 15 and I’ve owned a Macbook Pro 13 (but sold it shortly after getting the MBP 15 from work). The Good

Beautiful screen. The screen on this is a little brighter than my MBP 15 and has a higher resolution (1600x900)
Good keyboard. Has chic-let style keys that I really like.
Touchpad is pretty good after installing this (though not as good as my MBP)
Nice size, 14.5inches. Very portable.
Looks nice IMHO
Can drive 2 external monitors. Mine won’t power the laptop display and 2 monitors at the same time, but others can.

The Bad

Battery life. I get 3 hours normally. This sucks and is nowhere near HP's original claims. I know that everyone says you should cut advertised battery life in half but this is getting more and more ridiculous as advertised battery life is going up.
Switchable graphics. Most of the time, in Windows, you can’t switch to the integrated graphics. You press the button in their cheesy switching app and nothing happens. It really just shouldn’t be this hard. In Linux, however, I can always make it switch cards. Unfortunately the ATI drivers aren’t there yet in Linux.
Can’t drive any external monitors unless using the discrete graphics card. This wouldn’t be so bad for me if I could use the discrete graphics card in Linux.
USB peripherals cannot wake the computer up from hibernate, or sleep (unless they were plugged in when it went to sleep). My MBP 15 can do this and I really appreciate that ability. Without this, I have to open the lid just to get it to wake up, then close it, then subsequently wake it up all over again with the peripherals.
Linux support isn’t quite there yet. The Linux ATI driver support for the discrete card in this laptop is a work in progress. You can see the progress that Alex Deucher is making here. That branch is for acceleration support for this line of cards from ATI….not this specific card.

In the end, while I’m not thrilled with my purchase of this laptop, I can’t say that I’m super let down. This is still the nicest laptop that I have owned. It is serving its purpose of giving me a good place to work on side projects outside of my work laptop and to sharpen my .NET saw. None of the problems I have with the laptop are show-stoppers, though if I were still travelling a lot then the battery life would be a bigger downside.

Plant Test Factory for .NET

2010-09-01T00:00:00-04:00

Plant is a test factory for .NET 4.0. I created Plant because factories like this are something that I've gotten very used to in Ruby. As I started writing more and more tests in my C# projects, I noticed that I was writing more and more helper test methods to create commonly used model objects in my tests. This would often lead to ad-hoc and abused chunks of code that became harder and harder to maintain. The Ruby ecosystem has good answers to this problem, there’s factory_girl and machinist. I couldn’t find anything like that for .NET. NBuilder is in that area, but feels too heavy handed for what I wanted.

Goals

The primary goal of this tool is to allow you to write smaller and more focused tests. I find this beneficial because, like most other things in software, tests with fewer concerns tend to be easier to maintain and provide more value. Tests which test less are more resistant to illegitimate failures. A secondary goal of mine is to keep Plant’s syntax as lightweight and concise as possible. Code with less noise is easier to understand and code that’s easier to understand helps you get your job done. C# doesn’t always make this easy. Not being able to assign a delegate to an anonymous type forces me to require users to use a special class for some things (i.e. LazyProperty). As this project grows, I’ll do my best to keep the syntax readable.

Direction

The only client of the Plant project at the moment is pretty small and will likely never use all of Plant’s features. However, instead of dreaming up features that I think will one day be useful for Plant I decided to copy factory_girl’s feature-set. I’ve used factory_girl quite a bit in the past and found almost every one of its features useful at some point or another. So far I’ve got several of factory_girl’s features implemented, one it doesn’t have (creation via constructor parameters), and there are several Plant is still missing.

Plant’s features at the time of this writing are

Object creation via properties
Object creation via constructor arguments
Overriding default property and constructor argument values
Module object definition
Lazily evaluated property and constructor argument values

Upcoming features

Allowing multiple named definitions for one object
Sequenced properties (you can do this today with lazy properties, but I want to make it easier)
Lazy associations (again, something you can do today with lazy properties, but the syntax can be more concise and explicit)
Allow user to specify after-creation actions to be taken on created objects (like saving them to a database)

Scenarios that Plant does not support

Constructor arguments whose names differ only in capitalization.
Indexed properties
Refactoring. Since properties are passed around using anonymous objects, refactoring tools will miss them. This can be fixed for properties but not for constructor arguments. I’m not sure what the right answer is here.
Open generic types (You can tell Plant how to create a Foo, but not a Foo where T is specified at time of creation.

Find it on Github here: http://github.com/jbrechtel/plant (the current release is tagged 0.1.0 here) It will be available on Nu shortly.

Anti-Agile flak

2010-03-07T00:00:00-05:00

There were a couple of interesting posts on InfoQ last week about problems with Agile. First, a few points from Mark Lines' post Here's one of his 'common sense improvements' to Agile:

...the Unified Process breaks a project up into 4 distinct Phases, after which the iterations are named. In this way, stakeholders can know how the project is progressing...Other agile methodologies simply number their iterations sequentially. Being in iteration 4 tells me nothing about the progress of the project towards completion of its initial vision.

Here Kai is mostly making an informative statement about his flavor of Unified Process, but ends it with a dig at Agile iteration numbers. Agile projects provide other artifacts for getting a high level picture of the status of the project such as burn down charts. Iteration numbers are more useful as historical markers. If you want a detailed view of an Agile project's status then attend an iteration planning meeting. His point here is like saying "My new car is better than yours because I put the blinker at the top of the steering column. You don't have anything at the top of your steering column!" Mark also lists many issues that Agile projects have to face such as resistance to pair programming, mandated bureaucracy, insistence that projects cannot be executed independently, and perceived difficulty in frequent deployments. He claims that Agile projects often trivialize or ignore these realities. In my experience we will fight against these issues. If the fight cannot be won or is not worth it then we give up. There are times when some of these issues cannot be overcome. Some projects must take a dependency on other ongoing projects and sometimes you can't deploy frequently. But to fight against these issues is not trivializing or ignoring them, quite the opposite: we are acknowledging and addressing them. Now on to Kai Gilb's post Kai makes two claims (so far, his post is only at part 2 of 7 as I write this):

Agile does not focus on stakeholder value

To make this point he shows a diagram that represents a Scrum workflow (from here: http://en.wikipedia.org/wiki/File:Scrum_process.svg) Nowhere on this diagram does it mention stakeholder value. It's just a product backlog going into a sprint backlog, going through development and producing working software. To assert that this means Scrum doesn't focus on delivering value you would have to intentionally ignore the creation of the product and sprint backlogs. It's almost as if he stumbled on to this lone diagram and said "Hey, there's no mention of value here, I can use this to say Scrum doesn't focus on value!"

Agile 'baby talk' kills developer creativity

For this point he uses the following user story as an example: "As a buyer, I want to place a book in the shopping cart" While this story does come from some Scrum training materials it is used in the context of describing a product backlog, not how to create a story. So, I'd agree with him if this were your typical user story, but it isn't. At best this is the kind of story crafted and accepted by an inexperienced team. It doesn't talk about the business value it would provide. Doing so would serve to both justify its existence and help developers think of appropriate solutions. Also, the story goes too far by prescribing an implementation of a desired function instead of stating the desired function. I suppose these kinds of posts are common (both the ones I'm responding to and mine) so I probably won't make another post like this. However I would gladly continue a dialog along these lines if anyone is interested.

Ask the right questions

2010-02-22T00:00:00-05:00

A few months ago, my friend Patrick Caldwell started a series of blog posts about how to land a programming job (Part 1, Part 2, Part 3, Part 4, Part 5, and Part 6). I like his advice and think that it's quite helpful to aspiring developers. However, he did miss one aspect of the job hunt: finding a job you'll like. Since "like" is a subjective term I'll just describe the questions I ask prospective employers during interviews. Currently I work at ThoughtWorks and I love it. I researched the company very thoroughly before joining. I either asked or discovered the answers to all of these questions before I accepted their offer. I'm glad to say that working here has met all of my expectations and more. Here are the questions that I need answered before I'll work somewhere:

Can I use Open Source Software?

I recently witnessed a project where the team had to move off of Git for source control because the client had a policy against using GPL software*. This was rather absurd because they had no plans to distribute Git or anything using it. It was merely their source control system. Policies like this cause a number of problems for developers and the team as a whole.

They limit personal freedom by constraining you to a smaller set of tools than you would have otherwise. They hinder productivity because, for certain classes of software libraries and tools, the best options are open source (Web Browsers, Source Control, ORMs, IoC, etc).
These policies limit your experience and growth. To take this idea to an extreme consider if you could only use a proprietary language and framework invented by the company you work for. How useful is that experience to you or your future employers?
Policies such as these typically demonstrate a lack of maturity in the organizations software development practices. Unless your goal is to bring that maturity to the company then this would be a reason to stay away.

* The funny thing is that their dev severs ran Linux. *

How many different projects will I work on in a typical week?

My motive behind this one feels like a personal preference but I have yet to meet another developer who doesn't feel similar on this topic. Before ThoughtWorks, I've had multi-month stretches where I'll have to work on more than 5 projects a week. Often multiple in one day. This makes work feel like such a grind. It's unproductive and harmful to both you and the projects themselves. Task switching constantly might make you a little better at multitasking, but it will never be as effective as single tasking. You will also likely develop some nasty habits:

You'll likely goof off more because you'll seldom be very engaged in what you're doing.
Switching tasks will be the norm so as soon as a new one becomes available you'll be more likely to hop right on it thus losing all the context you've built up for your current task.
Since you'll be more error prone (multi-tasking increases your error rate) this will make you more accepting of errors in your work.

I would be very hesitant to take another job where I'll typically be working on more than one project in a week.

How do you estimate the time needed to complete work?

Let's face it: there are better developers than you. There are faster developers, there are more thorough developers, there are slower developers and there are sloppier developers. Couple that with the fact that any estimate is just that: an estimate. Be wary of places where the developers doing the work are not the ones doing the estimating.

What is your software development process?

You should definitely know and be comfortable with how they develop software. If they have a process, how that process works, how you as a developer fit into that process, and how flexible they are with that process. I almost titled this question "Are you Agile?" but decided that would be too vague. Many companies will claim to practice Agile, XP or Scrum, but without the details of what they're actually doing you risk making some incorrect assumptions about how they interpret those labels. Ask specific questions around this topic.

Can I talk to someone else? Lastly, you should ask to talk to other people you'll be working with. Ideally that would include developers, BAs, QAs, PMs or team leads of any kind. Find out how much they like their jobs and try to get a feel for how you'd like to work with these people. Your instincts know more than you may think so you should probably trust your gut on this one.