Archive for September, 2006
These guys don’t seem to be your typical conservatives (as examplified by little Georgey).
Despite the failures, one had the sense that the party at least knew in its heart of hearts that these were failures, either of principle or execution. Today one has no sense, aside from a slight lowering of the swagger-mometer, that the president or the Republican Congress is in the least bit chastened by their debacles.
George TenetÃ¢â‚¬â„¢s WMD Ã¢â‚¬Å“slam-dunk,Ã¢â‚¬Â Vice President CheneyÃ¢â‚¬â„¢s Ã¢â‚¬Å“we will be greeted as liberators,Ã¢â‚¬Â Don RumsfeldÃ¢â‚¬â„¢s avidity to promulgate a minimalist military doctrine, together with the tidy theories of a group who call themselves Ã¢â‚¬Å“neo-conservativeÃ¢â‚¬Â (not one of whom, to my knowledge, has ever worn a military uniform), have thus far: de-stabilized the Middle East; alienated the world community from the United States; empowered North Korea, Iran, and Syria; unleashed sectarian carnage in Iraq among tribes who have been cutting each othersÃ¢â‚¬â„¢ throats for over a thousand years; cost the lives of 2,600 Americans, and the limbs, eyes, organs, spinal cords of another 15,000Ã¢â‚¬â€with no end in sight. But not to worry: Democracy is on the march in the Middle East. Just ask Hamas. And the neoconsÃ¢â‚¬â€bright people, allÃ¢â‚¬â€are now clamoring, Ã¢â‚¬Å“On to Tehran!Ã¢â‚¬Â
My fellow Republicans, it is time, as Madison said in Federalist 76, to Ã¢â‚¬Å“Hand over the tiller of governance, that others may fuck things up for a change.Ã¢â‚¬Â
Update: Link fixed thanks to Trent.
My theory is: iterative development + daily stand-up meetings + frequent retrospectives +a culture that supports learning = eventual invention of a home-grown fully Agile approach.
The extended version: IF you have a project and a project team in an organizational culture that supports learning, and IF the project team is made up of people of good will, doing their Ã¢â‚¬Å“prime directive bestÃ¢â‚¬Â* on an ongoing basis, and IF the project leaders (coaches, engineering leads, PMs, scrummasters, etc.) structure the project with 1) iterative development, 2) daily status meetings (preferably short stand-ups), and 3) retrospectives at the end of every iteration, release, and other significant project milestones, THEN sooner or later you will have a project that aligns around Agile values and begins to adopt a variety of other Agile principles and practices. It might take longer than if you start with a value-driven charter and TDD and a lot of other practices, but youÃ¢â‚¬â„¢ll get there.
Source: Fundmentally Agile.
Via Stacy, PicoUnit presents us with a different style writing tests. While I don’t like all of it’s features (take this with a grain of salt as I’ve only read the examples on the site), it takes a radical step away from the traditional XUnit testing frameworks. I’ll dissect it’s features below.
- Mocking framework – This looks similar to JMock combined with the BDD styles of Ruby mocking RSpec. The syntax is a little confusing, also not sure how it’ll stand up to refactoring.
- Test discovery – This looks like something I write on most projects (now in Boost). Doesn’t look like there is a way to narrow down the test aggregation, to only pick unit tests as opposed to acceptance tests for example.
- Injection – This is a neat idea, basically all dependencies are injected (looks like setter & test class constructor are supported). I don’t think this is as clean as the EasyDoc/Boost automocker, though as the code is more explicit, less “magic” is involved.
- Testing lifecycle – Splitting the idea of a test lifecycle out of a base class is neat. As LifeCycle claims to be a marker interface, I’m assuming that the methods in the implementing class can be named whatever you wish. Not sure how it them differentiates for setUp() tearDown(), etc.
- Ignore – Not sure how much simpler this is than sticking a couple of letters in front of a test case, or adding an empty suite. Nice idea though.
All in all, PicoUnit is a very healthy thing for the current crop of testing frameworks, a sprinkling of annotations can only get you so far.
While I’m on the new mocking framework bandwagon, here’s another I didn’t know about, Mocha.
There are many lessons along the way to a RESTful system. These are only a few, from the perspective of BenjaminCarlyle.
Benjamin has worked at translating commercial software to a REST model, and developing frameworks for the support of new REST software. His work is proprietary, but his lessons are not. These are the steps he has taken.
The movie “United 93″ shows how American heroes take on the hijackers — but only after a German passenger has tried to persuade them not to. The movie is described as “meticulously researched” and “fact-based”, but there is not any indication that Christian Adams, deputy directory of the German Wine Institute and a Fulbright Alumnus, acted in the cowardly appeasing way he is portrayed in the movie.
Anthony Kaufman writes in his review in AlterNet: “a German blond businessman who turns out as a stereotypically weak-kneed Euro-pacifist (an obvious non-American who is eventually neutralized).”
We might all say that career success should be measured by how fulfilled you are on the job, but in practice, most people and companies still measure success by how high you climbed the corporate ladder. Clawed yourself near the top of the org chart? You ARE successful. But if you’re not on a leadership track, playing the “my number of direct reports is bigger than yours” game, you’re probably not. We all know this is lunacy, especially in the tech world, so why do so many companies still have only a single path for promotions? You either move into management or your career (pay, benefits, perks, control, etc.) stands still.
Isn’t it about time we quit measuring professional success in one dimension, vertically, and start considering how much your actual work matches your desired work?
I’ve spent the last two afternoons helping friends with their introduction to all things agile course: Boost Kickstart. This is an excellent learning opportunity for all involved (students & coaches) and usually brings out some lively discussions. This course was no exception.
Towards the end of the first day I got to speaking with one of the students who turned out to be responsible for maintaining some code I wrote at a previous employer (this is always a good test of character!). He asked me a good question about using interfaces, when & why should he use them. I drilled down a bit and he was basically lamenting the fact that I had developed most of the code with an interface for every class. To him, this was very confusing as it meant he had to drill into the interface first, then the implementation in order to discover what the class was doing. This problem can be quickly overcome with decent tool support, the Command-Option-B trick in IntelliJ is one such feature.
Apart from having two classes that represent the same concept (in the worst case – anyone remember .c & .h files?), using interfaces on every concrete class is something I consider a good idea. The most practical reason for this is that when you are testing a class that uses an another class, the collaborator can be mocked out, while its concrete implementation can be closed off (using final in Java) to prevent concrete inheritance (we’ll have the close/open discussion another time).
This scenario brings out the usual reason interfaces are used in Java, when you have to implementations of something that represent the same “type”. In the testing example, the first implementation is the real one and the second the mock (probably constructed dynamically).
de Alfaro and Henzinger  comment on interfaces as follows:
Good interface design is based on two principles. First, an interface should expose enough information about a component as to make it possible to predict if two or more components are compatible by looking only at their interfaces. Second, an interface should not expose more information about a component than is required by the first principle [SourceInterface-based Design].
Here are some of the good points about using interfaces:
- Flexibility – Tests can use mock implementations. IoC containers can proxy implementations with transactions, logging etc. ORM tools (e.g. Hibernate) can proxy implementations that do lazy loads, etc.
- Limits the amount of behaviour you expose to only what is visible on the interface.
- Testing becomes easier. If you have a complex domain model for example, you don’t need to create large and cumbersome test data in order to create test objects, this becomes especially important if you have interdependencies between those objects at different levels in the graph.
- Classes that use DI to obtain dependencies don’t need to care what implementation they get, just its type. This may be the most important thing about interfaces, you only care about type not implementation.
Some would argue that f you’re doing the simplest thing, you should always just create the concrete class and then when you need it, pull out an interface. In my experience, you always need the interface, so it’s easier to always do it right off the cuff. Even someone I generally disagree with goes as far as saying that “a piece of code is completely “pure” if all the type names it uses start with I” (where an I represents an interface).
Languages such as Ruby don’t have interfaces (and also don’t allow final access modifier on classes) and hence avoid the interface argument altogether. This has its good points if you are into testability, but if you are looking for interfaces as contracts, this is arguably worse than Java.
I’ve conveniently avoided the whole contract debate (i.e. you should never be able to instantiate a concrete class directly & instead should get everything only by interface) for now, we can come back to that one later. We could also go further with the use of interfaces if Java allowed dynamic type composition, but alas it doesn’t…