Posts from oobablog: Blog of Paul Ingles...
Posted by Paul Ingles 78 days ago
Before joining my current project I spent about 4 months working with Ruby every day, the first time I’d done so for a few years. It was a glorious time: uncluttered syntax, closures, internal iterators, and with open classes, the ability to extend the ‘core’ at will.
Today I’m working with C# and .NET, and I’ve noticed that those 4 months with Ruby have changed the way I’ve been writing code. Most noticeably, I’m using anonymous delegates a lot more. But that’s not all.
I’ve found myself aching to use the List’s ForEach method; I’m now wired to use Ruby’s internal iterators where instead of
List people = FindAllPeople();
foreach (Person person in people) {
...
}
I can instead do
List people = FindAllPeople();
people.ForEach(delegate(Person person) {
Console.WriteLine(person.Name);
});
But, frequently I’m put off by the surrounding guff that’s needed to express the same and have almost always gone back to the more traditional external iterator-based approach. It’s simply too high-a-price to pay.
One of the largest smells I’ve noticed recently (to my mind) appears driven out of not having open classes and external iterators. If they were there, I’m sure people would use them. The result: all across the codebase, whenever you need to convert from type to another you’ll see
List people = FindAllPeople();
List firstNames = new List();
foreach (Person person in people) {
firstNames.Add(person.Name);
}
This smells to me. But it really, really smells from having used Ruby where I would previously have written something as succinctly as this:
find_all_people.collect {|person| person.name}
(I’m sure other languages could do equally good things- but I’m familiar with Ruby, before the Pythonists pounce :p)
Well, turns out that you can get nearly there with C# 2.0 and .NET 2.0 with the almost certainly underused ConvertAll method (also part of List).
List people = FindAllPeople();
List names = people.ConvertAll(delegate(Person person) {
return person.Name;
});
There’s still a fair bit of accidental complexity remaining- lot’s of delegate and type declarations.
C# 3.0 introduced lambda expressions and we can use that to bubble our soup down to a nice intentional broth even more. We can get rid of the delegate bumpf and let the compiler infer the type (we are still statically typed after all)
List people = FindAllPeople();
List names = people.ConvertAll(person => person.Name);
Next step, we can also infer the types for our local variables:
var people = FindAllPeople();
var names = people.ConvertAll(person => person.Name);
Pretty nice. Most of the code is focused on the task at hand, and on expressing the necessary complexity (what it means to convert people to names). Guess learning a new language each year has it’s benefits.
I’ve got another bit of Ruby influenced C# refactoring to cover (a somewhat declarative way of removing switch statements), hopefully I’ll get that posted tomorrow!
Posted by Paul Ingles 84 days ago
I was involved in the inception work (and the resulting delivery) for a project late summer last year. We estimated the total work to be nearly 500 units- too much to complete in the time we had. So, working with the client we cut it down to a reasonable scope (this client rocked at that!) of around a third.
What was really cool, however, was that a few months in after that initial scope had been delivered, we looked ahead for what we’d do next. According to our original inception, there was still more than double left to go, but, instead what we planned to do next was radically different. What we’d believed to be important 3 months ago, no longer was. The result was we delivered about 30% more, and about 50% overall was not part of that initial (500 unit) scope.
The real key was that our client had a very definite focus on work that was important (that is, work that delivers the most value) and avoided getting drawn into unimportant but urgent work, or left valuable work to the point it was always urgent. If you’re always working on urgent things you’re working at breaking point and miss out on the opportunity on higher value items that are less urgent.
Here’s a diagram to show the two
(More can be read about Covey’s grid on Wikipedia)
The right-most two quadrants (coloured blue and purple) are the key. Both represent sections that involve working on things that are valuable, i.e. those that are important to do. In contrast, 1 and 2 (the uncoloured boxes) are relatively unimportant and should demand less attention.
The rub (of course) is that urgent things tend to be shouty and demand attention. I would also say it’s often easier to measure how urgent something is rather than how important it is; as a result, urgency is an easier (and thus more likely) benchmark for prioritising tasks - despite ignoring whether the work is worth doing at all.
Some of the best people I’ve worked with (including our sponsor at our client last year) have a remarkable ability to cut through the context and spot what’s really important now; as opposed to just reacting to what’s demanding our attention now.
Posted by Paul Ingles 108 days ago
Paul Hammant wrote a nice article about how to refactor the “nest-of-singletons design” towards using dependency injection using Google’s Guice IoC Container.
Whilst waiting for one of my many builds to finish today, I figured I’d satisfy a curiosity - roughly how many singletons are there defined within this codebase. I fired up Cygwin and used the following
find . -type f -name “*.cs” | xargs cat | grep “public static [A-Za-z]\{1,100\} Instance” | wc -l
Result:
180
Yikes!
For Java, you can always use the Google Singleton Checker which also has some nice stuff about why they’re controversial.
(Update) Paul Hammant pointed out that his article wasn’t about refactoring out singletons, rather, breaking away from using the service locator to dependency injection. Apologies for muddling it up a little :)
Posted by Paul Ingles 164 days ago
During the most recent ThoughtWorks away-day (a chance for the office to get together, catch-up, drink etc.), George and I presented on a number of Ruby and Rails lessons we learned from our (now previous) project. One of the most interesting sections (to us anyway) was on declarative programming, specifically, refactoring to a declarative design.
I guess much like DSLs, its easier to feel when you’re achieving something declarative as opposed to necessarily defining what makes it. But, I’ll try my clumsy best to define something.
Almost every language I’ve turned my hand to (save for Erlang) are imperative languages - where programs are written as sequences of operations, with changes of state. You determine the what and the how of the system - what to do and how to do it.
Declarative programming is an alternative paradigm, whereby code is expressed as what’s. How the system executes is someone else’s responsibility.
So, for the purposes of this discussion let’s consider that application code can be split into two groups
- Logic- the rules, the guts of things- that what’s.
- Control- statements about execution flow.
Interestingly, one of the principles listed in Kent Beck’s most recent book (Implementation Patterns) includes “Declarative Expression” - that you should be able to read what your code is doing, without having to understand the wider execution context.
Declarative languages are all around us, with most developers I’m guessing using them almost daily.
Think of SQL, when you write a statement such like SELECT [Name], [Age] FROM [Person] WHERE [Age] > 15 you’re making a statement about what you’d like, not how you get there- that’s up for the database engine to figure out. And a good thing to! Have you ever taken a look at an execution plan for modestly complex queries?
Closter to home - think of .NET and Java Annotations- where you can decorate constructs with additional behaviours. They look and feel like core extensions to the language, but are programmable and can be used to adapt the runtime behaviour of the system.
Before working for ThoughtWorks, I worked on a system where we used attributes to allow us to add validations to properties, allowing us to re-use code and extend easily.
[LengthMustBeAtLeast(6)]
public property string FirstName
{
get { ... }
set { ... }
}
Everything was nicely decoupled, read well, and reduced the amount of clutter in our code. More importantly, our validation code was not spread throughout every setter of every property. We could isolate responsibilities making code easier to digest and understand, and test!
Onto Ruby. A substantial part of our project involved reading lots of CSV files from different sources to update our deal information. The answer was a kind of anticorruption layer (borrowing heavily from domain-driven design) for each different feed.
Quickly, we ended up with a few concrete classes and a base class that co-ordinated effort. Dependencies were shared both ways, imagine a number of template methods that are called in sequence to accomplish their work. Over time it grew complex, and with Ruby it’s a little tougher (than with languages like Java or .NET) to navigate and browse around the code without strong IDE support.
It was starting to get a little too complex and we felt we needed to change things, so we did (bolstered somewhat by having Jay with us).
Onto the code.
So imagine we have a class representing a Feed of information (read from a CSV file), and we want to be able to ask that Feed to provide us with a number of Deals. Internally, it will iterate over the items in the Feed, creating a Deal for each one (if possible).
Our first solution looked a little like this, firstly in the ‘abstract’ base class:
def create_deal
Deal.create(:network_name => network_name)
end
and in the feed’s concrete implementation:
FIELD_INDICES = {:name => 1, :network_name => 2}
def network_name
read_cell(FIELD_INDICES[:network_name])
end
Our main feed class asks our implementation class for the network_name - a template method. Not bad, now build that up to tens of attributes, a bit longer. Since we’ve defined column indices in a constant, we also now have to navigate up and down lots to determine where we’re reading from. Add in a few other tables with look-ups for other bits that we need to do the mapping and it can get a little complex pretty quick.
Our code is not only made up of the stuff determining what it is to translate between a CSV representation of our Deals to an object model one, but also all of the code necessary to find out which CSV column we’re in, how we map that column etc. They were essentially just reading values from cells, no translation needed. Most of the code we had was infrastructural, and the logic (the what of our application) was hidden amongst the noise.
This complexity, combined with the split of flow between abstract and concrete classes, made it difficult to follow and understand. Our goal was to try and reduce each concrete implementation to a single page on our screens.
These little ‘mapping’ translation methods were our first target - reduce the amount of code for each of these to one line that described the mapping, rather than how we get it all.
Firstly, we introduced a convention - every attribute of a Deal could be retrieved by calling a deal_attribute_my_attribute style method. So, we renamed all our methods, ran the tests, and then started to make steps towards having each deal_attribute_blah method defined dynamically.
We went from:
def network
...
end
to
def deal_attribute_network
...
end
to … nothing.
Well, not quite. Instead, what we wanted was to have a method constructed by adding a class method to a module that we could mix-in. Then, we could just define the mapping and Ruby would wire up the rest. We settled on the following syntax
deal_attribute :name => 'NAME'
Neat. A little classeval and instanceeval magic later we were able to push our infrastructural code out of our concrete feed class and into the co-ordinator.
Our code is now more declarative. We’re stating what we need to do our work, rather than worrying about how we get at it. Not only that, for the common case (where we may be just moving values from one place to another) there’s no need to do anything more than describe that relationship. Declarative programming makes it much easier to express important relationships. It’s now much easier to see the relationship between the name attribute of a Deal and the NAME column for this CSV feed.
Notice also how we’re pushing our dependencies up to our caller- the coupling is now one-way. We state what we need from our caller (the main deal feed class) - our caller is able to then pass the information on. We’re just answering questions, rather than answering questions and asking questions (of our caller).
The syntax also lends itself to explaining a dependency, that an attribute of our deal is read from ‘NAME’ (for example).
That’s great, next step was to tidy up some of the slightly more complex examples where we do some additional translation. For example, where we take the name of something and we need to pull back an object from the database instead. Let’s say we keep track of the Phone that a Deal is for.
So, from
def deal_attribute_phone
Phone.find(deal_attribute_brand, deal_attribute_model)
end
to
deal_attribute(:phone => ['MAKE', 'MODELNAME']) do |brand, model|
Phone.find(brand, model)
end
We’ve extended the syntax to reveal that this translation needs values from both the ‘MAKE’ and ‘MODELNAME’ columns. From our perspective, we’re pushing responsibility up and keeping our code focused on what we need to map this attribute.
This is a little more complex to achieve since we’re also passing arguments across (and our deal_attribute translator methods also sometimes need to access instance variables) so we need to use instance_exec instead of the standard instance_eval.
The end result was feed classes that looked as follows
class MySpecialFeed
deal_attribute :name => 'NAME'
deal_attribute(:description => 'DESC') {|desc| cleanse_description(desc) }
deal_attribute(:phone => ['MAKE', 'MODELNAME']) do |brand, model|
Phone.find(brand, model)
end
...
end
In total, it took us probably just over a day to refactor the code for all of our classes. Most of which we managed to get down to some 40 or 50 lines total. We didn’t refactor all the code, so there’s still potential for exploiting it further but it was definitely a very exciting thing to see happen.
Posted by Paul Ingles 252 days ago
From across the desk, George asks “can you copy classes in Ruby?”. We talk about it quickly and reason that since everything’s an Object (even classes), you probably can. Since the constant isn’t changed or duplicated (you’re essentially assigning a new one) then it ought to be possible.
Turns out it is!
class First
def initialize
@value = 99
end
def say_value
@value
end
end
First.new.say_value # => 99
Second = First.clone
Second.class_eval do
define_method :say_value do
@value + 100
end
end
Second.new.say_value # => 199
Neat.
I’m not sure quite why you would want to clone a class to take advantage of re-use - rather than extract to a module (and share the implementation that way) or, if there’s a strong relationship that doesn’t violate the LSP etc. then look for some kind of inheritance-based design.
But, I guess you could work some kind of cool ultra-dynamic super-meta system from it. Perhaps someone with way more of a Ruby-thinking brain than me could offer some thoughts?
Posted by Paul Ingles 259 days ago
The project I’m currently working on uses both the Asset Packager and Distributed Assets to ensure we have only a few external assets, and that we can load assets across more than one host - all so that the pages for our site load nice and quick.
Unfortunately, wiring in the Asset Packager plugin caused the Distributed Assets plugin to break, and I spent an hour or two tracking it down yesterday. The cause? Asset Packager redefines the compute_public_path method.
# rewrite compute_public_path to allow us to not include the query string timestamp
# used by ActionView::Helpers::AssetTagHelper
def compute_public_path(source, dir, ext=nil, add_asset_id=true)
source = source.dup
source << ".#{ext}" if File.extname(source).blank? && ext
unless source =~ %r{^[-a-z]+://}
source = "/#{dir}/#{source}" unless source[0] == ?/
asset_id = rails_asset_id(source)
source << '?' + asset_id if defined?(RAILS_ROOT) and add_asset_id and not asset_id.blank?
source = "#{ActionController::Base.asset_host}#{@controller.request.relative_url_root}#{source}"
end
source
end
Distributed Assets works by chaining compute_public_path - decorating the calculated path, adding the asset host prefix onto the url. But, Asset Packager works by defining the method into ActionView::Base. So, when DistributedAssets::AssetTagHelper is included with ActionView::Helpers::AssetTagHelper, it chains a (now) hidden method.
But, the only places that use the new compute_public_path code inside the Asset Packager Helper (which just avoids using the query string timestamp) is within Asset Packager itself.
So, I tweaked the implementation of AssetPackageHelper to
def compute_public_path_for_packager(source, dir, ext, add_asset_id=true)
path = compute_public_path(source, dir, ext)
return path if add_asset_id
path.gsub(/\?\d+$/, '')
end
def javascript_path(source)
compute_public_path_for_packager(source, 'javascripts', 'js', false)
end
Beware the monkey patch.
Posted by Paul Ingles 263 days ago
Rails makes heavy use of a declarative style around it’s codebase- for example the has_one and belongs_to declarations inside ActiveRecord (amongst others). These are just class methods defined on modules, letting Rails wire up relationships, but they read like fully-fledged statements within a mini-language:
class Student < ActiveRecord::Base
has_many :tutorials
We can take advantage of the same in our code- letting us write in a declarative-style (hopefully revealing stronger intent) and reduce the amount of code we write (by using declarations to meta-program for us). I posted a little while ago that we’d used such an approach for marking attributes as immutable.
Anyway, back to the title of the post- #instance_exec, it’s a method defined in Ruby Facets. Like it’s documentation says, it’s equivalent to instance_eval but also lets you pass parameters- roll on the meta magic.
Let’s say we’re writing a system to calculate the monthly salary payment for an employee. We want to be able to say what the payment is rather than how it’s calculated.
class FullTimeEmployee
include Employee
bill_at {|hours| 50.pounds_sterling * hours}
In the snippet above, we’re making a declaration - defining the relationship between an hourly rate and the number of hours the employee works. We can implement bill_at in Employee as follows:
module Employee
module ClassMethods
def bill_at &block
define_method(:calculate_bill) do |hours|
instance_exec hours, &block
end
...
Our assertion could be:
assert_equal 500.pounds_sterling, employee.calculate_bill(5.hours)
Posted by Paul Ingles 269 days ago
I’d read a while back that Apple were going to include Sun’s DTrace tool in the now newly released Leopard - underpinning Instruments (formerly known as Xray).
What I hadn’t noticed was that the build of Ruby 1.8.6 included in Leopard (patchlevel 36 with some extras) also includes Ruby probes from the lovely folks at Joyent. Apple have ported everything. So, out of the box, Ruby works with DTrace! Sweet!
From Sun’s page:
DTrace is a comprehensive dynamic tracing facility that is built into Solaris and can be used by administrators and developers to examine the behavior of both user programs and of the operating system itself. With DTrace you can explore your system to understand how it works, track down performance problems across many layers of software, or locate the cause of aberrant behavior.
Joyent have got some sample scripts in their Subversion repository, and, what looks like some nice extensions for Rails (DTrace probes can be fired from within Ruby). Blimey!
For those (running Leopard) and want to just see something, try this out. It’s a script that traces the number of times a method is called. Once downloaded, all you need to do is
$ chmod +x functime.d
$ sudo ./functime.d -p
Replacing
Hash key? 25123 15 384174
Module each_object 1 390824 390824
Module included_in_classes 1 391025 391025
Module reloadable_classes_with 1 391203 391203
Module reloadable_classes 1 391835 391835
ActionController::Routin load_routes! 1 394864 394864
ActionController::Routin reload 1 398364 398364
Class reset_application! 1 398947 398947
Class reset_after_dispatch 1 400474 400474
ActionController::Routin connect 39 13192 514506
Array include? 3353 166 556605
ActionController::Routin build 47 13116 616459
ActionController::Routin add_route 47 13329 626488
Array each 874 780 682423
Object load 2 376432 752864
Module silence 2 391586 783172
Kernel gem_original_require 28 43460 1216884
Array select 316 4106 1297580
Array collect 351 4124 1447524
Module local_constants 91 17120 1557986
Module new_constants_in 25 93885 2347139
Object require 50 58495 2924783
The columns (from left to right) are: Class, Method, Count (number of times method was called) and then the average and total micro seconds. The d script was one of the Joyent examples. Arstechnica also have a very cool example showing the call stack from a system call.
What’s more amazing is this doesn’t require any recompilation, special flags, running in special environments. It’s available from the off!
If all that’s whetted your appetite (and I’m not sure how it couldn’t), head on over to the DTrace how to for a little more explanation of how it all works.
Time to get stuck in and see whether anything emerges about my current project. Very cool stuff!
Posted by Paul Ingles 296 days ago
I’ve recently had a few people email me about problems with the Mephisto Flickr plugin I wrote, that Liquid (the templating engine used in Mephisto) had changed the interface for the initializer.
I thought I’d fixed it a few times, and indeed I had. Just in the wrong repository! Sorry. I guess I’ve still not quite managed to get the hang of aliased virtual hosts on TextDrive shared hosting.
So instead you should take a look at doing
$ script/plugin install http://svn.oobaloo.co.uk/svn/mephisto_plugins/mephisto_flickr_photo_stream/trunk && mv vendor/plugins/trunk vendor/plugins/mephisto_flickr_photo_stream
Note that it’s now reading from svn.oobaloo.co.uk. Sorry for the confusion. I’ll try and figure out how to get engross.org pointing to the right location in the meantime.
Thanks again to everyone who’d emailed in with the fix, and sorry again.
Posted by Paul Ingles 316 days ago
Whilst working on a bit of code the other day we found this little nugget in the RDoc for Object#instance_variable_set:
Sets the instance variable names by symbol to object, thereby frustrating the efforts of the class‘s author to attempt to provide proper encapsulation.
Brilliant!
Posted by Paul Ingles 318 days ago
The test:
def test_cannot_change_country_name_once_constructed
country = Country.new(:name => 'UK')
assert_raise RuntimeError do
country.name = 'USA'
end
end
The class:
class Country < ActiveRecord::Base
extend ImmutableModel
immutable :name
...
The implementation:
module ImmutableModel
def immutable(attr_name)
define_method "#{attr_name}=" do |new_value|
read_attribute(attr_name).nil? ? write_attribute(attr_name, new_value) : raise(RuntimeError, "You can't change #{attr_name} once it has been set")
end
end
end
Posted by Paul Ingles 339 days ago
On a recent holiday to Brussels I got to try out my new-ish Tokina 12-24mm f4 lens. I’ve managed to get a few pictures I’ve really enjoyed before now, but, I’m so glad I had it to hand in Brussels.
After a great evening out, walking back through Grand Place to our hotel I wanted to grab a night time shot. In the past, I’ve never managed to quite land one even with a tripod to hand, so I wasn’t hoping for much. But, leaning against some steps, hand-holding and firing a few shots in succession I took something I was really happy with. At ISO 500, f4 and only 1/10.
I was stoked! To anyone sitting on the fence of going wide-angle: go get one!
Posted by Paul Ingles 339 days ago
In preparation for a Ruby project I wanted to play around with Rails’ page caching a little over the weekend. Naturally, I wanted to find a way to ensure that my controller was writing files correctly so that Apache (or any other HTTP server) can then serve the static content directly (without hitting my Rails processes). Since I’m also digging RSpec at the moment, I wanted to find a way of expressing it nicely in my specifications. This is what I ended up with.
Here’s the relevant controller’s specification:
describe UsersController, "caching" do
include CachingExampleHelper
it "should cache new users page" do
requesting {get :new}.should be_cached
end
it "should not cache the activation page" do
requesting {get :activate, :activation_code => 'blah'}.should_not be_cached
end
end
The key part is the requesting line. That’s my extension that encapsulates the request that should be cached, so that we can both make the request and check that it ended up with a file being written to the filesystem.
module CachingExampleHelper
ActionController::Base.public_class_method :page_cache_path
ActionController::Base.perform_caching = true
def requesting(&request)
url = request.call.request.path
ActionController::Base.expire_page(url)
request.call
end
module ResponseHelper
def cached?
File.exists? ActionController::Base.page_cache_path(request.path)
end
end
ActionController::TestResponse.send(:include, ResponseHelper)
end
Note that we have to expose the pagecachepath method so we can calculate the location for where the cached files will get written, and then also explicitly enable caching. When we call requesting giving a block to the request we want to make (such as get :index to invoke the index action), we capture the block as a Proc, invoke it and then read the request’s path from the generated TestResponse object. This lets us then first expire the page (in case it was cached previously), and then make the request. Finally, we then check whether the cached file exists by mixing in a cached? method to the Response.
Unfortunately, the code above will make 2 requests per assertion. But, I’d rather have it read nicely for the time being. Any suggestions on how you could tidy this up further would be well received!
I’m not sure I’d want to run these tests all the time, maybe something a little lighter to ensure that we tell Rails to caches_page for relevant actions in our controllers, but as a definite re-assurance it seems ok.
Posted by Paul Ingles 374 days ago
I’m not sure why, but I get the feeling that anonymous delegates in C# 2.0 haven’t really had much of a press and people aren’t really that aware of them.
Essentially, it lets you declare the delegate inline a la:
public delegate void MyDelegate();
...
private void DoIt(MyDelegate codeBlock)
{
codeBlock();
}
public void AddInstrumentToPrice(string message)
{
DoIt(delegate { Console.WriteLine(message); });
}
Closures!
On my current project we’ve found some great use for them, in particular, once we’d started refactoring some GUI code into the Model-View-Presenter pattern as described in Michael Feathers’ Humble Dialog paper (pdf). This tidied a lot of the code up nicely, keeping the GUI code focused, allowing us to then focus a little more on improving the behaviour of the UI.
The Windows Forms UI needed to show a progress bar indicating how far it was through pricing all of the selected trades. But, with our pricing occurring within the same thread our UI was locking. So, you push the processing out into a worker thread and then you can update both, right? Wrong, because .NET will throw an exception should you attempt do this - because Windows itself doesn’t like it when you do.
The Control class includes an Invoke method that executes a Delegate on the UI thread. So, to ensure our UI updates execute on the UI thread we can write the following
public void calculateButton_click (object m, mouseeventargs e) {
this.Invoke(delegate { resultsList.Items.Add("a result!") });
}
Testing With NUnitForms
Once we had that written, we had an additional problem - we now had code executing on different threads making it difficult to test through the GUI. Sure, we had a lot of tests that drove out the implementation of the Presenter, but, it’s always nice to know that the GUI is behaving, and you’re driving something end to end.
Our solution — use the Strategy pattern to extract out the behaviour around how code is executed in the GUI, we use an anonymous method/delegate to pass a code block to a class that either executes it on the same thread (for our tests), or, uses ThreadPool.QueueUserWorkItem.
So our end-to-end NUnitForms test might look something like
[SetUp]
public void Initialisation() {
form = new SampleForm(new SameThreadWorker());
}
class SameThreadWorker : IWorker {
public void Do(WaitCallback block) {
block(null);
}
}
[Test]
public void ShouldShowResultInListAfterCalculating() {
ClickButton("calculateResults");
Assert.IsTrue(ListContains("resultsList", "My Result"))
}
Which is handled inside the form by
public void calculateButton_click (object m, mouseeventargs e) {
worker.Do(delegate { resultsList.Items.Add("a result!") });
}
And our default worker for the GUI? Something a little like
class UserWorkItemWorker : IWorker {
public void Do(WaitCallback block) {
ThreadPool.QueueUserWorkItem(block);
}
}
Probably not the best way of doing it, but certainly better than most I could think of, and all thanks to anonymous delegates.
Posted by Paul Ingles 379 days ago
I was at lunch today with a few other ThoughtWorks folk. At the end of the meal Chris, George, and I were talking when George mentioned he’d been pondering some stuff with Mocking and Stubbing. George was questioning a suggestion that Mocks should not be used as a way of testing the edges of a system.
I replied along the same lines as my Extract Client Interface post (perhaps a little less eloquently) where I mentioned that writing code with Mocks encourages you to think about roles and interactions with collaborating objects things first, rather than getting buried under the weight of implementing everything in the world. And, perhaps more importantly, if you depend on something else, you’ve discovered an interface for what the client really needs.
If you do this for the edge of your system, you’ll end up discovering an interface that will get implemented with a facade or adapter that lets your code talk to the external system. But how do you test that? Should you never write an interaction-based test for that?
On our way out of the restaurant we carried on talking about these kinds of rules in software development - that you should never mock things you don’t own, conditionals are bad, regions are evil. Although there’s value in the statements, what’s more important is that people think about them. It’s like the agile manifesto, nobody says never write documentation, just that working software is valued more.
And, although I neglected to mention it at the time, it occurs to me that a recent experience on my current team is actually quite applicable to what we were talking about.
At present some of the code we’re working on integrates with a C++ library provided by another department. Fortunately, it exposes a couple of functions that let us dump it’s internal objects into an XML document. So, to test that we interact with the library in the correct way (across multiple function calls - state is maintained in a ‘cache’ behind everything) we assert on bits of the XML.
We’re essentially asserting on the internal state of an external library to ensure the correct interaction, and, when we updated to a new build of the library our build broke rather expectedly. We had an hour or two to fix up the tests when the schema of the XML changed. We’d depended on an external interface that we didn’t own and paid the price for testing our integration this way when the external system changed.
But, this same approach to testing (i.e. testing interaction rather than state) has also let us (to a degree) focus on implementing what’s important, and drive out what was previously considered a complex, black magic type development effort, into something more understandable and controllable. It’s by no means perfect, but as a small step on the way to development nirvana, it’ll do.
We might have done something perhaps a little evil, but the techniques and tools we use to discover better ways of writing code have helped us in a situation the rule would otherwise have prevented us. Sure we’ve had problems because we’ve been depending on things we don’t own, but, that’s a small price for the benefit we’ve gained - a clear step as we divide and conquer our way through.
Rules are important for providing insight into good ways of working. But, it’s always important to think and act intelligently. Sometimes things people say are a little over the top, but, they put questions in your head to challenge assumptions. It’s no good just looking for that next shiney pattern in a new book, or putting index cards on a wall. Those things may help, but they’re not an end, they’re a means. The key is intelligence and people (as has already been mentioned) continually adapting, learning, and improving.
There’s no such thing as a rule to rule them all. Well, except maybe that rule :)
Posted by Paul Ingles 394 days ago
I’ve had a 15” PowerBook G4 for about 3 years now, its served me well but it was proving just too slow to run Aperture and Photoshop, something I was increasingly using it for as I started getting more and more into (digital) photography.
I could no longer resist the MacBook Pro’s following Apple’s recent updates to 2.4GHz cores and machines capable of taking 4GB of RAM. So, I popped into the Apple store and picked up a shiny new 17” MacBook Pro. I know I’ve mentioned that I’d never dream of carrying around such a behemoth and that I was looking forward to see whether rumours around an ultra-compact MacBook Pro materialised, but, I’m absolutely smitten.
Performance wise, it absolutely leaves the old G4 for dead. Loading Aperture takes a split-second (no kidding), compared to a good 20/30 seconds on the G4. Editing images was more of a slog, requiring a good deal of patience to make adjustments, wait for the rendering, tweak it back, wait for the rendering. It’s almost instant now. Plus, with the 17” screen I can fit everything on the screen I need, and that’s without going for the HD option (that was a little too extreme).
The machine is a little larger than the 15”, but, not hugely and, it feels around the same weight as the old G4! The screen is large, sharp, and way brighter than the G4. Smitten I say.
Finally, I also got Parallels running so I can do .NET work on it also (and on a large display). What really impressed me was how you can just tell it to go with an express install and it runs through an unattended install for you, no need to sit and wait for it all to happen, away you go.
To complete it all off, I also bought an Apple Airport Extreme so my 320GB LaCie external drive I’d been using for the odd backup is now shared over the network and I no longer have to keep it attached. Backing up to the vault from Aperture works exactly as if it were directly attached. Sweet. It’s a little slower, but so much more convenient. And, should I need more storage, just stick another drive onto a USB hub and away you go.
Just love it all when it works together!
Posted by Paul Ingles 414 days ago
I’m yet to see the point of them. For those that aren’t familiar with them, they’re a preprocessor directive that means inside your C# code you can write:
#region Properties
public String FirstName { get { return “Paul”; } }
public String LastName { get { return “Ingles”; } }
#endregion
Then, inside the Visual Studio editor, you can expand or collapse whole regions of code.
In principle it’s the same as turning away and not looking directly at the big smelly pile of stuff, but rather cover it up in something that makes it look neater, or like not looking at your bank balance when you login to your online account.
Screen displays are pretty large these days, certainly enough for most reasonable pieces of code. So, the fact you need to put stuff in a region is not stopping-the-line, it’s a work-around. Rather than addressing the problem - you’ve got a big pile of code that could be more organised in code - by say, refactoring and improving the design, and thinking more about roles and responsibilities of classes instead of just dumping stuff places because that’s what’s being passed around). Instead, you organise your editing experience. Lovely.
It’s like Edit & Continue in the debugger, if you’re going to need to edit code as you debug, you’re spending too much time with the debugger.
Posted by Paul Ingles 416 days ago
I don’t normally post stuff which isn’t development related, but after such a fun evening I couldn’t resist.
I popped into the Virgin Megastore on Oxford Street last Friday to purchase a copy of Singstar for a barbecue and party I was going to over the weekend.
Well, just inside the store were a few small boards advertising that they now had Wii’s in-stock. I headed upstairs to the game department to buy Singstar and as I was paying asked whether they still had any. They did, and a few minutes later I’d bought a Wii, an extra controller and a copy of Wario’s Smooth Moves.
I’ve never had so much fun playing on a games console before. After a particularly stressful day I ‘unleashed the fury’ in a surprisingly competitve game of Bowling with my flatmate. It was a very cathartic experience, plus I won 3 games to 2 :). Following that, our other flatmate broke from his work and joined us to play Baseball. He howled with laughter the first time he moved the controller around to see his Wii Mii making the same movements on screen. Watching one person throw to bowl, and the other then following shortly to swing for the ball was particularly funny.
As for Wario Smooth Moves, it’s the weirdest game I’ve ever played but also insanely addictive - pumping your hands up and down to pop the balloon, and moving your hands back and forth in a sawing motion to sweep the floor during a curling game are just 2 examples of the fantastically funny mini-games.
So far I’m thrilled… I can’t wait for the second Nunchuck controller and Mario Strikers Charged Football to arrive and try it out over the Internet.
All in all, probably the games console I’ve purchased and the one which everyone (including a skeptical flatmate) has been incredibly impressed with.
Posted by Paul Ingles 422 days ago
Short positive feedback loops in software development are important.
Looking at what happened in the past, we can suggest what could be done to improve the situation in the future. It’s fundamental to lean and agile methodologies. Indeed, the methodologies themselves encourage adaptation of the methodologies by teams to adapt the practices and processes locally.
Test Driven Development (and it’s variants and corollaries) are all about this feedback, they help you think about what you’re doing immediately by showing you straight away. For instance, you can decide there and then that you don’t like the name of something (perhaps it turns out it doesn’t describe the intent). Feedback from you using your code can improve how you design your code.
People strive for fast running tests - they help keep developers upbeat. Slow builds sap the patience and take focus away from writing code and introduce unnecessary context switching. Slow tests become a pain, and people find ways to try and get around having to run them. Feedback is discarded.
To my mind, this is exactly why trying to split off the writing of tests to separate developers is costly - tests are a valuable learning tool, they provide a continuous response to you.
Write a nice clean test that results in simple and expressive code feels good, bad test phrasing feels dirty. Take yourself away from the feedback and you lose the opportunity to gain those insights. It may be that you spend most of your time working with developer tests, but having acceptance tests up-front that can direct your effort provide a great communication tool.
Keep yourself close to the feedback.
Posted by Paul Ingles 448 days ago
Inside my tests I try and keep everything I need inside the test, rather than depending on too many fixtures. That way I ensure they’re as readable as possible, and more importantly, obvious.
But, take the following example:
def test_total_is_due_now_if_return_is_less_than_14_days
booking = Booking.new(
:customer => customers(:valerie),
:collect_at => 1.day.from_now.to_date,
:return_at => 13.days.from_now.to_date,
:boxes => 2,
:collection_address => addresses(:one))
assert_equal Date.today.to_s, booking.final_payment_due_date.to_s
end
def test_payment_due_14_days_from_now
booking = Booking.new(
:customer => customers(:valerie),
:collect_at => 1.day.from_now.to_date,
:return_at => 20.days.from_now.to_date,
:boxes => 2,
:collection_address => addresses(:one))
assert_equal 6.days.from_now.to_date.to_s, booking.final_payment_due_date.to_s
end
Well, everything’s in the test, but there’s a fair bit of duplication. What would be nicer, is to take the prototype booking above and just override certain values.
Instead we might write something like
def test_total_is_due_now_if_return_is_less_than_14_days
booking = new_booking_with(:return_at => 13.days.from_now.to_date)
assert_equal Date.today.to_s, booking.final_payment_due_date.to_s
end
def test_payment_due_14_days_from_now
booking = new_booking_with(:return_at => 20.days.from_now.to_date)
assert_equal 6.days.from_now.to_date.to_s, booking.final_payment_due_date.to_s
end
private
def new_booking_with(args)
Booking.new(args.reverse_merge({
:customer => customers(:valerie),
:collect_at => 1.day.from_now.to_date,
:return_at => 15.days.from_now.to_date,
:boxes => 2,
:collection_address => addresses(:one)
}))
end
Much nicer (to me anyway), particularly once you start adding more and more tests (and especially validation related ones).
