As well as the Scala introduction classes, there were interesting talks on Akka, Simple Build Tool and Specs….

Akka

I attended a lecture by Jonas Boner on the Akka library. Jonas believes that it is simply too hard to write correct concurrent, scalable applications and that the threads and locks approach to concurrency taken in Java is far from the ideal approach. So, he created the Akka project to provide a better solution.

Akka is an opensource library ,with a Scala and Java API, whose MO is “Simpler Scalability, Fault-Tolerance, Concurrency & Remoting”. It achieves this through the use of the Actor Model. As well as actors, Akka provides Fault tolerance (inspired by the approach used in Erland) using a Let It Crash approach. Akka also makes use of Software Transactional Memory.

It seems like a well written project with a lot of good ideas. I would like to learn more about it (and perhaps hear of it being used in some enterprise apps) before I would attempt to use it in anger, but definitely one to keep an eye on…

Simple Build Tool

The second interesting talk was by Mark Harrah on SBT (Simple Build Tool).

SBT is for building projects. It is all about Scala: written in Scala; builds scala; defined in Scala.
It uses Ivy for dependency management, can be run in interactive mode or via triggered execution (~) to run when the source code changes.
The tool seemed neat and effective when he demoed it and this was reinforced by the other Scala presenters giving it a very big thumbs up. If I ever get a chance to start developing Scala in anger, this will be the first tool I would look at…

Specs

The final talk of interest was on Specs, by Eric Torreborre.

Specs is a is a Behaviour-Driven-Design framework which provides a simple and typed language to create specifications. It seemed to be a way to create specifications as tests (with integration with JUnit and JMock) in a way that is understandable by both business and technical folks alike, in a DSL like manner.

The talk was in 2 parts: Mechanics and Practice.
Below are my notes from the first part of the talk (see here for part2), but you can also get the original slides form here. The talk is based on his book of the same name, The Productive Programmer. Which is similar in theme but not to be confused with the “The Pragmatic Programmer” book.

Part1: Mechanics

1. Acceleration
2. Focus
4. Canonicality (applying the DRY principle)
3. Automation

1. Acceleration

The basic premise of ‘acceleration’ is that typing is faster than navigation and that tools, especially for repetitive tasks, are your friend.

Operating System accelerators

For o/s accelerators, he pointed out several useful tools:

• Windows: explorer address bar (alt-d shifts focus to the address bar)
• Apple: In Finder, use apple-shift-g to go to Folder; There are also a bunch of other shortcuts like apple-shift-h = go to home directory
• Firefox: Use the numberfox plugin – I looked in to this. I think it is this plugin, but unfortunately, it is only available for Firefox 1.5-2.0
• He also suggested using smart help on Mac Leopard, but I’m not sure what this refers to…

Clipboards

Neal pointed out that having only 1 clipboard with 1 entry is very limiting and suggested these tools to help:

• Windows: clcl (infinite/100 clipboard history)
• Mac: iClip ($)
• Mac: Jumpcut

Directory Switching

‘There and back’ for directory switching

• pushd – pushes a directory on the stack
• popd – pops it back off

(Note that these tools are also available on Windows)

Command Prompts

Graphical explorers better for some things, but the command line is better for others. The following are some tools to easy command prompt use:

• Windows: ‘Command prompt here’ power toy
• Windows: Command prompt explorer bar – This looks very cool!
• Cygwin: bash here
• Mac: Path finder ($)

Prefer Keyboard to Mouse

When coding, always prefer keyboard to mouse

Learning shortcuts

• Make yourself use the shortcut, even if you’ve found it via the menu!
• Have someone else pester you about it – e.g. pair programmer
• There is an app called KeyCaster than displays what keys were pressed
• Key promoter plug in for IntelliJ
• mousefeed for eclipse
• Try turning off menu options! Forces you to use keyboard shortcuts
• Use flash cards & cheat sheets

Java IDE Examples

All of our hierarchies are too deep, including in the file system & in code.
He suggested the following tools for IntelliJ:

• goto class (like ‘Open resource’ in Eclipse?)
• Can also open based on capital letter patterns
• goto symbol (opens a class based on a symbol (e.g. var name) in it
• introduce variable (does left hand declaration for you)
• introduce variable redux
• escalating selection

Templates

All major IDE’s and coding text editors support templates in some form.

• Use templates, for example in IntelliJ or Eclipse for things like parameter substitution, default values, repeating values
• Learn the language of your templating engine e.g. Velocity in IntelliJ
• Every time you type something for the 3rd time, templatize it!

Key macro tools

Key macro tools are like templates, but at the operating system level. Use them to avoid typing the same commands over and over again.
Windows: AutoHot key
Mac: TextTxpander ($)

Focus

Try to avoid distractions by doing simple things like:

• Get a comfortable chair
• Use dual monitors (google dual monitors and productivity to see proof!)
• Have monitors sitting immediately in front of you
• Use a good keyboard & mouse
• Don’t get carpal tunnel! (http://en.wikipedia.org/wiki/Carpal_tunnel_syndrome)
• Try moving mouse to your ‘bad’ side, or use on left AND right side (Using the mouse on your ‘bad’ will force you to use keyboard more and will also make you ambidextrous!)
• Motivate yourself to learn keyboard shortcuts
• Have admin privileges for the O/S (If you are not given permission, start a spreadsheet of all the time you waste because you can’t do what you need to due to lack of admin rights; Show your boss how much time it is wasting)

In general, offices are terrible environments (too many distractions) – War rooms work better.

Locus of attention

Anything that happens outside your locus of attention breaks flow.
Flow is when you have total concentration and time disappears (‘in the zone’).
It is hard to get in to and easy to break (like sleep in that respect).

To avoid breaking flow/concentration, try:

• Tweak UI – A tool that allows you to easily manipulate your Windows environment. For example, you can turn of balloon tips for ever.
• Screen dimmers – Allow you to automatically set you background to dark after a set time
  • Windows: Jedi Concentrate
  • Mac: Doodim
• Internet blockers
  • Mac: Concentrate – Have to reboot machine to unblock. Can configure to only block certain sites.
  • Windows: Jedi Concentrate

The higher the level of concentration, the denser the ideas, so to maintain concentration:

• Turn of notications
• Don’t keep email open – email is best done in batches (e.g. deal with at 9, noon and 3)
• Put on headphones
• Create office “quiet time”

Focus techniques

Search beats navigation

Search is (increasingly) better than navigation, so try to replace file hierarchy navigation with search

• Desktop search. e.g. Google Desktop search(aka quick search box)
• Larry’s “any text file” indexer

Rooted Views

A rooted view is a specialized explorer view with a base folder that is ‘rooted’ at the folder you specify.
(on Mac, this is simply the directory shortcuts on the left hand side)

Use virtual desktops

• virtual desktop manager power toy
• VirtualWin (better?)
• Spaces (built into leopard)

Canonicality

DRY – Don’t repeat yourself

ORM

A database schema can be made up of DDL + xml + pojo
Choose 1 and generate the others from that
e.g. generate xml & Pojos classes from schema
(If you need to add to a class’s logic, make the generated code Abstract, and the class that extends it is where the extra, custom code gets added)
Or, generate the schema & POJOs from Hibernate mapping files

DRY Documentation

e.g. generating wiki pages from subversion check in details (see SVN2Wiki)
DRY Diagrams – Generate based on code
DRY Schemas – Schemaspy

Automation

In general, don’t do by hand what you can automate!

• You should have a one command build (if, on a brand new machine, you can’t issue one command to get build, and another single command to build, then you have a flawed build process)
• Continuous Integration (good for building, metrics reporting)
• Version Control (Essential!) – Do not comment out code! Remove and use VCS.

Subverting other tools

Selenium (open source tool for UAT)
Includes a side project called selenium IDE
Side use: Allows you to automate debugging wizard style web apps! (you need to test one page, but you need to navigate through 10 pages to get to it – use Selenium)
Record your interaction the FIRST time you walk through the page
Cuts debugging time!
Selenium defines an interaction API for web apps
Have your Q/A dept record bug discoveries

You almost never do anything just once

• Work like a craftsman, not a laborer
• Build shims & jigs
• Building a tool takes longer, but you are building assets
• Develop Bash-fu

Why Automate?

• Time sent automating can take multiple times longer but can be used multiple+ times. And can accidentally can become a major part of project!
• Allows throw-aways to grow into assets
• Allows unit testing, refactoring, support
• Solving problems by hand makes you dumber!
• Steals concentration
• Squanders focus

Justifying automating

• Timebox! – Set a reasonable amount of time to POC
• Evaluate @ end of timebox
• Abandon if it is not working out

Analyze the ROI

• How long does it take to do X times?
• What are the consequences of doing it wrong?
• Automation is about time saving and risk mitigation

Last and by no means least – Don’t shave yaks!

What does that mean? Basically, it allows you to access your bug tracker from inside Eclipse and then for each task/bug you are working on, it remembers what files you have been using most. The result is that when you switch back to a task you were working on before, the important and most relevant files you were using will be reopened and so at any given time, the files you need are close to hand.

The ‘tasks’, in my case, are defects/enhancements assigned to me in Trac (or specifically DevJaVu), but it has integration with Bugzilla, JIRA and others.

It’s not exactly ground breaking or revolutionary, but it is definitely useful (although the integration/synchronisation with Trac does seem to be a bit flaky, but maybe that is an issue with DevJaVu).
Next up, I would like to start making more use of the change set support.

See some reviews here and here.

Overall, interesting and I’d like to use it some more, but I still have no plans to stop using Eclipse as my main IDE.