Walk with me
And change the world we see
We’ll cease to be
Just people passing by
Home is where we all get by
— Pain of Salvation: “Leaving Entropia”
Everybody says: “Time heals everything.”
But what of the wretched hollow?
The endless in-between?
Are we just going to wait it out?
— Imogen Heap: “Wait it out”
I’m putting together a video for our band’s 10-year anniversary party. The only software I have at hand is iMovie ’09 (that’s 8.0.5) on my Snow Leopard-equipped Macbook. The thing is, iMovie’s picky about the video formats it accepts. These are “MPEG-4 or DV file formats, and some .mov file formats.” So, you’re out of luck with DivX-encoded AVIs, for example.
The excellent VLC video player can transcode videos to a variety of formats, but being a complete n00b when it comes to these things, I couldn’t find the right flags that would’ve produced iMovie-worthy files from DivX-encoded AVIs, for example. Luckily, Handbrake was easier to use. It even had some presets for encoding files into formats accepted by iPods, for example. These are the settings that worked for me:
Format: MP4 file
Video Codec: MPEG-4 (FFmpeg)
Framerate: Same as source
Quality: avg bitrate 5000kbps (this was good enough for me — choosing constant quality (e.g. “90%”) made the videos not work in QuickTime/iMovie!)
Audio: AAC, 160kbps
After an evening of transcoding, I’m finally ready to put the damn thing together 🙂
There was a time when dealing with dates and times in Java was god-awful. With Joda Time, everything’s a breeze. Not only are date-based calculations easy, but you can also make your domain code less anemic by utilizing the library to its full extent.
Case in point: I had a method that returned objects due for removal in the next n months. Its signature first looked like this:
List<Thing> findThingsDueForRemovalIn(int months);
Using Joda, I first found a way to make the parameter type communicate the intent better. Enter Months:
List<Thing> findThingsDueForRemovalIn(Months months);
Now you can’t just call the method without thinking first; we actually had a bug in production recently due to one setXXXTimeout(...) method accepting seconds and the other milliseconds, both as primitive numbers. In the same class. Oh, the confusion.
The implementation is clean as well, something along the lines of
public List<Thing> findThingsDueForRemovalIn(Months months) {
...
final LocalDate today = new LocalDate();
someQuery.setInclusiveDateRange(today, today.plus(months));
return someQuery.execute();
}
Small victories.
If I only could I would
Change everything
Today is the day,
the moment of reckoning
— Insomnium: “The Moment of Reckoning”
Learn You a Haskell for Great Good! is a cool little beginner’s guide to Haskell (reminiscent of the legendary Poignant Guide to Ruby) while Real World Haskell is an upcoming book from O’Reilly that’s freely available online (at least for now.)
Last week, we had a spec mysteriously failing due to the following holding true:
!list.isEmpty() && list.size() == 0
That is, I had a List instance that was both… non-empty and empty?
Turns out the failing spec was faulty to begin with, and a small refactoring that didn’t change any functionality but did change the way we communicated with a certain API revealed this problem to us. The seemingly impossible state the List instance was in turned out to be a side-effect of setting up a too permissive mock object using JMock.
In JMock (and other libraries) you can explicitly state the mock interactions you care about and the ones you don’t. Let’s say you were implementing a user registration form for your website, and creating a new user would entail adding the user to the database using DatabaseService and subsequently sending an email containing the generated password using EmailService. Now, we clearly want to test that both of these things happen, but to make our specs as concise and isolated as possible, it’d be cool to test these expectations separately in their own spec methods. Enter JMock’s ignoring -construct, which enables you to state that you don’t care about the method calls a certain mock receives:
...
class WhenUserRegistersSuccessfully {
public void userIsAddedToTheDatabase() {
checking(new Expectations() {{
one(mockDatabaseService).save(expectedUserObject);
ignoring(mockEmailService);
}});
fillFormAndSubmit();
}
public void passwordReminderMailIsSentToTheUser() {
checking(new Expectations() {{
ignoring(mockDatabaseService);
one(mockEmailService).send("user@lolcats.com",
"Your password is 'secret'");
}});
fillFormAndSubmit();
}
}
...
Now, if we manage to break the interaction either with the database service or the email service, we get a clear indication of what the problem is. The scope is smaller than if we were to write a long test method packed with many assertions, in which case a failing test would – at a glance – only tell us that user registration is broken without immediately pointing out which part of it doesn’t work.
The side-effect of using ignoring(...) is that JMock returns a default value for any method calls on the mock by default. For methods with primitive return types, this is the default Java value for that type (zero for integers, false for booleans etc.) For methods that return Objects, JMock uses an imposteriser to return a Null Object of the desired type, which in turn returns default values for any methods called on it.
This leads us to why our spec started failing: the return values of a mock we had explicitly ignored were actually being used. A certain method returning a List returned a JMock-generated Null Object instead, and this returned the default values for both isEmpty() (false) and size() (zero.) Refactoring the code revealed that the scope of the spec wasn’t actually what we had thought it would be, and the rogue List had been used for real.
This goes to show that you should always keep your mocks and their expectations as strict as possible, and be aware of any side-effects using permissive mocks might have. Your code shouldn’t really touch the default values returned by ignored mocks: I’m not sure if JMock can be set up so that the Null Objects it returns for ignored methods would throw an exception if you called any method on them. This would certainly have saved us some time in this case.
Long time no post. Working instead of studying for the first time in a long while. Expect more activity here.
Apart from work, our new promo album is keeping me busy (yes, the studio blog has the same theme as this one, but hey, it’s the best looking one available at wordpress.com.)
- 1 MacBook
- 0,5 liter of a sugary liquid of your choice
Mix the ingredients. Season to taste. Witness how fixing a 1000e computer can cost over 1300e. Be thankful for a good home insurance plan.
I’ve been delving into Scala quite a bit the last couple of weeks. Coderspiel has a piece on one of the coolest features in Scala: implicit type conversions.
In theory, these conversions allow you to use an object of type X in an expression where an object of type Y is expected. To achieve this, you define an implicit conversion function that takes an X and returns a Y (f: X -> Y for the mathematically inclined), and tag it with the language keyword implicit. Now, Scala can implicitly (and transparently to you, the coder) convert X’s to Y’s, if needed. Consider an example:
class Apple
class Orange {
def hi = Console.println("Hi, orange!")
}
object ApplesToOranges extends Application {
// This is our type conversion function.
// Note that its name can be ANYTHING:
// only the type signature matters!
implicit def applesToOranges(a: Apple) : Orange = new Orange
val a = new Apple()
// the implicit conversion occurs here, as Apple
// doesn't have a method called "hi", but Orange
// does, and we have defined the implicit conversion
// from Apples to Oranges
a.hi
}
This example doesn’t make much sense, but shows you the mechanics of implicit conversions. In practice, implicit conversions allow you to do some seriously cool things, such as extending existing Java class libraries (check out the Coderspiel entry for the JDBC and Wicket examples) elegantly.
There’s more to implicit type conversions than merely forcing legacy code to behave, though. For example, now that we can convert objects between different types pretty much arbitrarily and transparently, some DSL-like constructs become easier. Consider the RSpec -style assertions found in many BDD frameworks:
product.price.should == 5 character.name.should == "Mudkip"
Now, these clearly boil down to the format of
(some expression) should (expectation)
Perhaps we could represent these expectations using a class called Expectation, and have it evaluate any conditions thrown at it. Since we want to be able to say should for any object whatsoever, we need an implicit conversion from any type to an Expectation. Drum roll, please:
case class Thing(name: String)
object Expectations extends Application with Specification {
val mudkip = new Thing("mudkip")
mudkip.name should equal("mudkip")
(2 * 3) should equal(6)
// BOOM: failure!
false should equal(true)
}
// quick and dirty implementation
// just to illustrate the mechanics
class Expectation[T](value: T) {
def should(eq: Equality[T]) = {
if(value != eq.value) {
throw new AssertionError(
"Expected " + eq.value + " but was " + value
)
}
}
}
case class Equality[T](value: T)
trait Specification {
implicit def anythingToExpectation[T](value: T)
= new Expectation[T](value)
def equal[T](t: T) = new Equality[T](t)
}
Specs, a BDD framework for Scala, seems to utilize implicit conversions in this manner to support a pretty concise way of writing specifications.
So, in inaccurate yet nerd-appealing terms, implicit type conversions are sort of like having the power of Ruby’s open classes in a statically typed language – monkey patching, wicked! Don’t over-use ’em, though: you might hit issues such as ambiguity between different conversions (though the conversion functions are scoped.) As open classes, they seem like a prime candidate for the “I don’t know what I’m doing but if I stick this here, it seems to work” -type of coding.
Btw, the PDF version of the forthcoming book on Scala, aptly named Programming in Scala, is available through Artima’s early access program.
codeflo.ws 