I think that this book should be read by all new software developers as well as all junior or mid-level developers. There’s plenty to be learned by the senior developer types too. Even if you’ve been doing these things for a long time, this is a good read to make sure you’re keeping your feet planted firmly on the ground.
For more reviews, see Debug It! Review Roundup.
The dust is finally settling after the second Formula Jedi meeting at Croft, and I can take stock of the beginning of the season. On the face of things, it’s been a disaster – 4 races, of which I’ve only managed to start 3, no finishes, no points and a car that’s currently back at Jedi being repaired.
But actually, I’m really encouraged by how things have gone. I failed to finish the first couple of races due to the kind of teething problems you expect with a new car, and I was in the battle for 4th place before having to stop. I failed to finish the race at Croft because I clipped some tyres on the apex of one of the corners, but I was in 4th place at the time, right on the pace of the leader.
What I wanted this year was to have a car capable of running at the front of the pack, which I clearly do have. And, even after 3 years out of the driving seat, my driving doesn’t seem to have got quite as rusty as I feared. So, all I need to do now is actually finish some races 
Many thanks to the guys at Texperts who bought me a video camera as my leaving present. Here are the first fruits. I’ve ordered a rollbar mount so that I can mount the camera above my head for the next race
Recently I found myself trying to find a definitive list of the options supported by scalac, the Scala compiler. It turns out that I could have just asked the compiler itself (the -X option lists all “advanced” options and the -Y option lists all “private” options). But this is very difficult to find via Google.
So I thought that I’d create this page and hopefully save anyone else looking for the same information some time.
$ scalac -version Scala compiler version 2.8.0.RC1 -- Copyright 2002-2010, LAMP/EPFL
$ scalac -X Usage: scalac <options> <source files> Possible advanced options include: -Xassem-extdirs <dirs> List of directories containing assemblies, defaults to `lib' -Xassem-name <file> Name of the output assembly (only relevant with -target:msil) -Xassem-path <path> List of assemblies referenced by the program (only relevant with -target:msil) -Xcheck-null Emit warning on selection of nullable reference -Xcheckinit Add runtime checks on field accessors. Uninitialized accesses result in an exception being thrown. -Xdisable-assertions Generate no assertions and assumptions -Xelide-below Generate calls to @elidable-marked methods only if method priority is greater than argument. -Xexperimental Enable experimental extensions -Xfuture Turn on future language features -Xgenerate-phase-graph <file> Generate the phase graphs (outputs .dot files) to fileX.dot -Xlog-implicits Show more info on why some implicits are not applicable -Xmigration Warn about constructs whose behavior may have changed between 2.7 and 2.8 -Xno-forwarders Do not generate static forwarders in mirror classes -Xno-uescape Disables handling of \u unicode escapes -Xnojline Do not use JLine for editing -Xplugin-disable:<plugin> Disable a plugin -Xplugin-list Print a synopsis of loaded plugins -Xplugin-require:<plugin> Abort unless a plugin is available -Xplugin:<file> Load a plugin from a file -Xpluginsdir <path> Path to search compiler plugins -Xprint-icode Log internal icode to *.icode files -Xprint-pos Print tree positions (as offsets) -Xprint-types Print tree types (debugging option) -Xprint:<phase> Print out program after <phase> or "all" -Xprompt Display a prompt after each error (debugging option) -Xresident Compiler stays resident, files to compile are read from standard input -Xscript <object> Compile as a script, wrapping the code into object.main() -Xshow-class <class> Show class info -Xshow-object <object> Show object info -Xshow-phases Print a synopsis of compiler phases -Xsource-reader <classname> Specify a custom method for reading source files -Xsourcedir <directory> When -target:msil, the source folder structure is mirrored in output directory. -Xstrict-warnings Emit warnings about lots of things. -Xwarninit Warn about possible changes in initialization semantics -Y Print a synopsis of private options
$ scalac -Y Usage: scalac <options> <source files> Possible private options include: -Ybrowse:<phase> Browse the abstract syntax tree after <phase> or "all" -Ybuild-manager-debug Generate debug information for the Refined Build Manager compiler. -Ybuilder-debug:<method> Compile using the specified build manager (none,refined,simple) -Ycheck:<phase> Check the tree at the end of <phase> or "all" -Yclosure-elim Perform closure elimination -Ycompact-trees Use compact tree printer when displaying trees -Ydead-code Perform dead code elimination -Ydebug Output debugging messages -Ydetach Perform detaching of remote closures -Yfatal-warnings Fail the compilation if there are any warnings. -Yide-debug Generate, validate and output trees using the interactive compiler. -Yinline Perform inlining when possible -Yjenkins-hashCodes Use jenkins hash algorithm for case class generated hashCodes. -Ylinearizer:<which> Linearizer to use (normal,dfs,rpo,dump) -Ylog-classpath Output information about what classpath is being applied. -Ylog:<phase> Log operations in <phase> or "all" -Yno-completion Disable tab-completion in the REPL -Yno-generic-signatures Suppress generation of generic signatures for Java -Yno-imports Compile without any implicit imports -Yno-predefs Compile without any implicit predefined values -Ypmat-debug Trace all pattern matcher activity. -Ypmat-naive Desugar matches as naively as possible.. -Yrangepos Use range positions for syntax trees. -Yrecursion Recursion depth used when locking symbols -Yrepl-debug Trace all repl activity. -Yself-in-annots Include a "self" identifier inside of annotations -Yshow-trees Show detailed trees when used in connection with -print:phase -Yskip:<phase> Skip <phase> or "all" -Ysqueeze:<enabled> if on, creates compact code in matching (on,off) -Ystatistics Print compiler statistics -Ystop:<phase> Stop after phase <phase> or "all" -Ystruct-dispatch:<method> Selects dispatch method for structural refinement method calls (no-cache,mono-cache,poly-cache,invoke-dynamic) -Ysuppress-vt-typer-warnings Suppress warnings from the typer when testing the virtual class encoding, NOT FOR FINAL! -Ytailrecommend Alert methods which would be tail-recursive if private or final. -Ytyper-debug Trace all type assignements -Ywarn-catches Emit warnings about catch blocks which catch everything. -Ywarn-dead-code Emit warnings for dead code -Ywarn-shadowing Emit warnings about possible variable shadowing.
For an updated version of this post that covers Scala 2.9.1 and sbt 0.10, go here.
I spent quite a bit of time beating my head against the details of getting Scala 2.8.0.RC1, sbt and ScalaTest to play nicely with each other. So here’s a step-by-step guide which will hopefully save others time.
$ mkdir aproject $ cd aproject/ $ sbt Project does not exist, create new project? (y/N/s) y Name: aproject Organization: com.example Version [1.0]: Scala version [2.7.7]: 2.8.0.RC1 sbt version [0.7.3]:
project/build/AProject.scala containing:
import sbt._ class AProject(info: ProjectInfo) extends DefaultProject(info) { val scalaToolsSnapshots = ScalaToolsSnapshots val scalatest = "org.scalatest" % "scalatest" % "1.0.1-for-scala-2.8.0.RC1-SNAPSHOT" }
This tells sbt that you will be using the pre-release snapshot version of ScalaTest for Scala 2.8.0.RC1.
sbt update. After running this, you should see that you have a lib_managed directory containing the ScalaTest jar.src/main/scala/Widget.scala containing:
package com.example class Widget { def colour = "Blue" def disposition = "Awesome" }
src/test/scala/WidgetSpec.scala containing:
package com.example.test import org.scalatest.Spec import com.example.Widget class WidgetSpec extends Spec { describe("A Widget") { it("should be blue") { expect("Blue") { new Widget().colour } } it("should be awesome") { expect("Awesome") { new Widget().disposition } } } }
sbt test. You should see:
[info] == com.example.test.WidgetSpec == [info] A Widget [info] Test Starting: A Widget should be blue [info] Test Passed: A Widget should be blue [info] Test Starting: A Widget should be awesome [info] Test Passed: A Widget should be awesome [info] == com.example.test.WidgetSpec ==
src/main/scala/Main.scala containing:
package com.example object Main { def main(args: Array[String]) { val w = new Widget() println("My new widget is "+ w.colour) } }
sbt run. You should see:
[info] Running com.example.Main My new widget is Blue
Update: Use the pre-defined ScalaToolsSnapshots repo (thanks to Erick Fleming).
Update: Fixed a typo in step 8 (thanks to Jason).
I’ve recently started working on a new project (SwiftKey), and my immediate priority is to get our testing sorted out. To that end, I’m constructing a fuzz test suite. Partly because I think that it’s the right tool for the job, and partly because it’s a good opportunity for me to learn more about the language, I’m writing it in Scala.
A fuzz test interacts with the System Under Test in a random, yet structured manner. The object of the exercise is to construct sequences of API calls (or network traffic, or whatever) that flush out the kind of bugs that are less likely to be discovered by unit tests tests and the like. Fuzz tests are particularly good at finding things like security problems, buffer overruns, memory leaks etc.
Clearly randomness is a large part of a fuzz test, so I’m creating some utilities that make it easier to randomly choose between several different actions. I thought that I’d publish them just in case anyone else finds them useful, and also to solicit feedback to help me improve my use of Scala (bear in mind that I’m still finding my feet, so be gentle!).
So, here’s my first attempt:
val random = new Random def oneAtRandom(actions: () => Unit*)() = () => actions(random.nextInt(actions.length))()
oneAtRandom takes a set of functions and returns another function which, each time it’s called, executes one of them at random. For example:
val randomAction = oneAtRandom( () => print('a'), () => print('b'), () => print('c')) for(_ <- 1 to 10) randomAction()
Which gives the following output:
aabaacbbcc
So far, so good. But what if we want different functions to be executed with different frequencies? We might have some actions that we want to only happen occasionally? Here’s another version of oneAtRandom that takes a weighted set of functions and calls them in proportion to their relative weights:
def oneAtRandom(actions: (Int, () => Unit)*)() = { val totalWeight = actions.foldLeft(0) {_ + _._1} () => { val r = random.nextInt(totalWeight) var w = 0 val (_, action) = actions.find { case(weight, _) => w += weight; w > r }.get action() } }
Here’s how it’s used:
val randomAction = oneAtRandom( (1, () => println("rare")), (10, () => println("occasional")), (50, () => println("frequent")) ) for(_ <- 1 to 100) randomAction()
And to prove that it’s doing what it claims:
$ scala random2.scala | sort | uniq -c 88 frequent 11 occasional 1 rare $ scala random2.scala | sort | uniq -c 82 frequent 12 occasional 6 rare
So I’ve got it working, which I’m happy about. But I’m sure that it could be improved. I’m sure, for example, that there must be a “nice” functional way to implement the loop inside the weighted version (instead of using var w as an accumulator), but each of my attempts to do so have ended up being considerably more complex than the current version.
I’d also love to use the -> notation to pass the arguments, for example:
val randomAction = oneAtRandom( 1 -> () => println("rare"), 10 -> () => println("occasional"), 50 -> () => println("frequent") )
But doing so results in a parse error—the only way I’ve found to avoid it is to add additional parentheses:
val randomAction = oneAtRandom( 1 -> (() => println("rare")), 10 -> (() => println("occasional")), 50 -> (() => println("frequent")) )
which is starting to feel a bit too much like Lisp for my taste
Finally, I’m really missing some of the handy little utilities provided by Ruby. In Ruby, for example, I could write the loops that call randomAction like this:
10.times { randomAction }
I know that it’s trivial to create this kind of utility, but one of the nice things about Ruby is that they all come as standard out of the box.
In any case, I’d be very grateful for any and all feedback on the above. Thanks in advance!
Today, I took the Jedi to Rockingham for a shakedown.
The point of the day was to run the engine in and sort out teething problems, and from that point of view it was very successful. Nothing major went wrong or fell off, and the teething troubles fixed include:
The only outstanding problem we have is that the water temperature is fluctuating rather more than we would like—I could almost use it as a rev-counter, so much does it increase with revs and so quickly does it drop when I back off.
It’s gone back to Jedi so that they can take a look at the water system and put it on a rolling road to get the power commander set up.
The conditions (rain or drizzle all day, resulting in a very greasy circuit, not helped by the fact that I was using rock-hard 4-year-old wet tyres) and the fact that I could only use full revs in the final session, meant that I learned next to nothing about my driving. I did remind myself just how forgiving the car was – it was getting sideways on 20% throttle in every gear apart from 5th or 6th, and yet I could balance it without really having to think about it—while everyone else was spinning all around. One particular F3 car managed to spin right in front of me on 4 separate occasions.
And f**k-me it’s fast. I could only use full throttle on the banking, but once the revs get above 10k it just takes off like a scalded cat. Can’t wait to get it somewhere where I can really lean on it…
I was at Jedi for a seat fitting on Friday (sitting in a plastic bag full of expanding foam – a sensation very similar to having wet yourself ) and I’ve just got around to uploading the photos:
http://www.facebook.com/album.php?aid=154574&id=522871533&l=b23b84a19c
Very little’s changed from the car that I wrote off, so it shouldn’t take me too long to get used to it. But there is a *scary* amount of plumbing and wiring compared to the old R1 
The days of being able to get the engine out and back in again in between qualifying and the race are definitely behind me!
It’s clear that the author’s years of debugging experience were superbly distilled into this collection of high impact advice.
A must have book for anyone writing programs.
Perhaps it’s the fact that it’s Paul Butcher’s first book that gives Debug It! its remarkable charm and conviction. The fact that very few other books cover the theme on such an intellectual and psychological level undoubtedly helps set it apart from the few books currently out there too. Either way you look at it, Paul’s take on debugging is certainly essential reading for those looking to clean up their act and, more importantly, their code.
Overall, this book is going to be a huge win, and I think it’s a worthy successor to the Release It! reputation. Development managers and team leads should get a copy for the junior developers on their team as a Christmas gift, but only after the senior developers have read through it as well.
Excellent discussion of the strategy of debugging. Buy, it read it and kill bugs.
I feel like armored with all this knowledge I am ready to become a one man Anticimex army for software bugs. Now it has been a while since I read the book but I remember solving bugs with a new confidence while reading it and after. Strongly recommended for everyone doing software development in any form.
Frankly, I wish this book would be read by a lot of developers
This book is highly recommended as it contains a whole lot of wisdom and experience from the field of software engineering. It’s only 190 pages, so you should be able to get through very quickly. So, you can’t lose on this one.
I think that this book should be read by all new software developers as well as all junior or mid-level developers. There’s plenty to be learned by the senior developer types too. Even if you’ve been doing these things for a long time, this is a good read to make sure you’re keeping your feet planted firmly on the ground.
With my many years of experience in supporting and debugging large existing enterprise systems, I have to say that Paul Butcher summarize and structure all the knowledge (and more) that I have, sometimes painfully, accumulated during this activity. This is therefore an excellent book that I will recommend to everybody that is involved in software development in general and maintenance activities specifically.
I know that this book influenced the way I work now, and there aren’t many books I could say something like this about.
All in all, there is just a lot of tremendously valuable information in this book. And it’s only about 190 pages so it definitely won’t take you a long time to read it. I’ve frequently been amazed at the inability of developers to efficiently debug issues when they occur. And i’m not just talking about bad developers. I’ve seen plenty of good or even great developers having trouble with debugging efficiently. This book would definitely get them on the right track, with just a little bit effort.
Understanding is everything: that is at the heart of Paul Butcher’s comprehensive study of the science and psychology of debugging.
The book does a great (and truly pragmatic) job of covering all these aspects and addressing a wide range of topics related to debugging software.
If you are too busy to read this delightful book in its entirety, then at least read the final chapter whilst mandating that your entire development team read “Debug It!” from cover to cover.
As usual, the publisher has an excellent book on a practical subject that answers oractical qustions on debugging.
I would highly recommend Debug It! to any junior-level programmer who’s interested in developing a more disciplined approach to debugging. If you’re not a junior-level programmer but still feel like you waste a lot of time debugging, you will probably find this book helpful as well. It’s like having a mentor sitting there with you, teaching you how to take your debugging game to the next level.
It’s really good seeing these ideas in words because it’s quite easy to forget about the best way to approach problems in the heat of the moment and the approaches suggested by Paul certainly aren’t done everywhere in my experience.
While I was familiar with many of the practices discussed in the book … I learned quite a few new things.
It does a great job of setting the scene for debugging and getting you into the right mind set, while also talking about the complications that can arise once the bug is found and squashed. It’s almost worth looking at for the anecdotes alone, to understand the lengths that you sometimes have to go to when trying to understand some truly bizarre defects.
This is a recommended read for anyone who works closely in the software industry, be it a developer, a tester or even a product manager.
Subject to change, but I’m assured that no changes are expected. All meetings are double-headers:
10/11 April – Silverstone National
8/9 May – Croft
29 May – Rockingham (single qualifier)
12/13 June – Brands Hatch
14 August – Oulton Park International (single qualifier)
11/12 September – Cadwell Park
23/24 October – Snetterton
Apparently there’s a chance that we might get an extra meeting at Mallory sometime in July as well.
Debug It! is making its way around the world, as this review by Luiz Marques in Brazil demonstrates.
Luiz is kind enough to say:
While I was familiar with many of the practices discussed in the book … I learned quite a few new things.
He goes on to say:
Well worth the time, specially as it is not very long.
Many thanks, Luiz.
