The new mac has arrived! I haven’t had a chance to really use it (that’ll all change next week) but wow is it a nice machine. I don’t need to gush over it as everyone knows how amazing these machines are. All I’ll say is my favourite feature so far is how cool all the available multi finger gestures are, not so cool is how obvious oil from your fingers appears on the black keyboard.
Read More
I spent this morning playing around with autotest, but was getting really flaky results with the Growl notifications. I tried about four different autotest configs, but none of them seemed to consistently worked. I remembered that the Growl notifications at Thursday’s Coding Dojo worked pretty well, so after some digging around I found the config on their github. After a tiny tweaking I was even able to get it to work with Przemysław Kowalczyk’s Doom Guy. I’ve packaged it all up and put it on Github. Enjoy.
Read More
It finally came time to un-subscribe from all the Grails feeds I used to read. As I’ll no longer be doing any Grails it makes little sense to really keep up with what’s going on in the Grails world. Grails has a lot going for it, but even after over a year of doing it, it just never felt as smooth or dreamy as Rails always has. It managed to replicate some of the core that made Rails so wonderful to begin with and did a good job of it most of the time. Perhaps if I had more experience of the Spring and Hibernate core I could have got more out of the Framework, which is fine and that is on my head, but in the end it just got more and more frustrating as features available in Rails were just impossible at the time in Grails. I’m not saying that Grails is lacking, as at the end of the day, there’s nothing you can do in Rails that you can’t replicate in Grails.
In hindsight I was perhaps the wrong audience. Groovy/Grails is the perfect Java answer to Rails. I chose it to stay consistant with our other apps, so that everything ran on the same JVM and was all containted within the same application server. There were no constraints on the technologies that had to be used. Consistancy, perhaps, was the wrong reason to choose it. Maybe I should have chosen it if I had more knowledge of Spring and Hibernate. Maybe I should have chosen it if I had to to run in the same server and on the JVM. Who knows. I wish the Grails team all the best. Who knows, I may end up coming back to it one day. Stranger things have happened.
Read More
No matter how many times you click cancel, this dialog won’t go away. You’re left with no choice but to click run. Can someone explain the point? If I click cancel, don’t run the embeded Java application, simple, don’t spawn the dialog endlessly.
Read More
Normally when I come across something “beautiful” on the interwebs, I’d bookmark it in Delicious. The only problem is doing so isn’t entirely practical when looking for ideas or inspiration. Opening each site in a new tab and then browsing through them. No thanks. An alternative is to take screenshots of everything, but it’s just hassle keeping them organised and available somewhere. Problems be gone! LittleSnapper handles all your snapshots and makes it extremely easy to browse through past snapshots. It even knows what site each snapshot is from, so you can choose to visit if you wish to explore some more. It makes all your snapshots uniform and allows you to snap a whole page (even when it scrolls off the bottom), just a portion of a page and also the regular full screen and window variants. This is just another one example of an application that I wish existed on Windows.
Read More
Recently it would seem that everyone is jumping ship from Textmate and making a move to Emacs. Seeing as Peepcode just released their Emacs screencast, I thought I might as well have a look. I’ve used Emacs quite a bit as it’s my preferred *nix editor over Vim, but I’ve never bothered really learning any commands beyond Open/Save/Quit, which is surprising, as my first job as a Java developer was spent coding in Emacs. Looking back, I don’t know how I ever survived (Heck, I even remember not having syntax highlighting).
I’m not one for bandwagons, but, I’m very quick to move/try new technologies to see if they are better. It’s hard to ignore droves of developers saying they are moving to Emacs and to not wonder if it really has more to offer. On the surface, it’s not all that different to Textmate. At the end of the day they are both just text editors. Textmate, being Mac only, has more of a polished feel, but on the other hand becoming a master of Emacs would mean you could code away on nearly any platform, (then again, how much time do I really spend coding away from my main machine?). One thing that is funny though is that a lot of people making the move are installing commands that make Emacs more Textmate like, which seems to defeat the purpose of taking the time to actually learn Emacs.
I’m very 50/50 about the whole thing. People say you should stick to an editor and really master it and that’s what makes me so in-decisive about the whole subject of IDEs and editors. I never really take the time to get really deep enough into mastering them.
My head says Emacs but my heart says Textmate.
Read MoreI could tell you how I still continually fight the demons that encourage me to rush instead of following a disciplined course. I could tell you about all the tests I don’t write. I could tell you about the constant allure of shortcuts and my imperfection at avoiding them. I could tell you how often I look at that green band on my wrist and shudder at how imperfectly I follow it’s urgings.
Robert Martin – Glory and success are not a destination, they are a point of origin.
Reading that even the masters feel the same way that I do about developing sometimes, must mean I’m on the right track?
Read More
TDD is hard, seriously hard. Perhaps that’s a bit of an overstatement, but for me, after years of “skill neglect”, it’s been a real struggle to pick up and get right.
The problem isn’t writing the tests, it’s writing code that’s testable. I’ve dabbled a bit with unit testing in the past but never really got the “unit” part of it. My tests would dive into a class that relied upon other classes and I would assert some value passed all the way through the call stack. In hindsight this is totally wrong (unless we’re talking functional testing) but at the time, my only concern was getting a passing test, which I was successfully achieving. It was testing, but not as I now know it.
So now I know better. Now I know that a unit test should only really concern itself with the class at hand. The results returned should be a direct product of the method called and should not have been meddled with by a third party class/library/what-have-you. Before really taking some time to learn the subject of testing, I would have looked at my testee, thought “Well this class relies upon this other class here, what can I do but let the call happen.” and as such my unit tests turned into functional tests. But now I know I can substitute those called classes out for fakes, dummies, stubs or mocks.
I started out by writing tests for some existing legacy code (TDD arse about face really) and really struggled with working out how to use my mocks as callees for my target testee. I was instantiating classes inside methods and then making calls out to it. There was no way of substituting the concrete class out for my mock. But now I know I can substitute classes using dependency injection.
The nice thing about mocks and dependency injection, is that you’re not just able to verify the result of your testee, you can also verify it’s interaction with the mock. If your testee is only supposed to call getAmazingValue() once, you can fail if the method is called more times than that, or perhaps even called with the wrong parameters. I would have taken it on almost blind faith that the interactions I had been creating were correct. But now I know I can record, replay and verify these interactions. *
The hardest part for me was writing code I could test. TDD forced me to think about the design of my classes all the time, every time. When doing TDD I start with the test. I think about how I would like the call to work and then I code up something just to make the test pass. Then I’ll think about how my class relies upon a call out to some other class. So I’ll create a small mock for the testee, go about injecting it to get the test working again and then make sure the interaction between the testee and mock happened exactly as it should of. TDD is a beautiful thing, but it has its thorns. Just like everything in computing, on the surface the concept is deceptively simple. But when you really start to look into it and try and do it properly, what seemed like just a piece of floating ice is really the tip of a huge iceberg. The pain of doing it right is well worth it with the reward of less bugs and easier changes. It’s a hard concept to keep going and feel like it’s worth it, as the benefits sometimes might not be seen for some time. It’s only in that moment of changing something that you see straight away that it’s broken other pieces of implementation, do you really feel glad that you made the effort.
* While mocks allow for the testing of the interaction between the testee and the mock, this doesn’t always mean the relationship is correct. If I mock a class and expect a call to getAss() but the real concrete class expects a call to getArse(), then the whole thing falls apart when run in the wild. This might not be such a problem when the mock is derived from a common interface, but in dynamic languages, there is that margin for error.
Read More
