[gist id="172116"]
Great find by andhapp.
Read Moreprogramming
For some reason my rspec fixtures were not loading into my development database when doing spec:db:fixtures:load. An extra parameter to db:fixtures:load is all that’s needed.
>: rake spec:db:fixtures:load
rake aborted!
uninitialized constant Fixtures
Fixed by:
>: rake db:fixtures:load FIXTURES_PATH=spec/fixtures
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 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
It’s amazing how easy it is to be a programmer/developer/code monkey without having to do it properly. I got my first programming job when I was 17, a whole ten years ago, and now after recently reading Clean Code and Refactoring to Patterns, I can’t help but wonder what the hell I’ve been doing all this time. I’ve been writing code, but I sure as hell haven’t been programming. Looking at the code I’ve written as recently as only a few weeks ago now makes me cringe. “Why am I calling this method here?”, “What the hell is this comment?”, “Is this a joke?!?”.
I took a job as a developer for a mobile phone voicemail to email provider four years ago. I was only there for a few months but I still feel like I learnt more about programming while there then I had previously and ever have done since. I’m a firm believer in the notion that you’re only ever as good as the people around you. If you come in at a lower level you’ll soon pick up the pace, and if you come in over those around you, you’ll soon slow down to match your co-workers. As always there are exceptional circumstances. Sometimes if you’re too low, you’ll never be able to perform to the same standard, and if you’re too high, you probably won’t stick around long enough to get bogged down. I’m in a bit of a unique situation in my present role, because I work in pretty much complete isolation from other developers. Which means I have to set my own benchmark. I remember when I started, I was still so full of energy from my previous job (the one mentioned above) that I wrote some pretty cool code, which even impresses me when I look at it four years on. But as time went by I became more and more rusty and the quality of my code decreased dramatically. I stopped reading computing books altogether and took more of an interest in general business subjects. I took an interest again when Rails came on the scene, but none of the coolness or wow factor of doing Ruby could be applied to my day job doing Java, so that area of my life still continued to dwindle. The discovery of Grails changed that to a large degree, but by then I had lost the sparkle for Rails and my code became the same mess, just in a different language. I constantly think to myself that there has to be a better way. Rails and Grails felt like an answer to a certain degree, but the same underlying issues of design and brittleness remained. While features were quick to implement, changes were slow and painful to make. Simple requests became complicated hacks built upon other hacks to fill in holes left by other feature requests. Rails and Grails, while eye openers and moral boosters, didn’t solve my problems.
I was naive and blamed the language, the framework or the previous developer for my issues. I felt that my designs were sound and the code of a high standard. It “felt” tidy and the functionality all there, neatly sectioned off into different places. But Clean Code and Refactoring to Patterns showed me how wrong I had been. Regardless of the language or the framework, without well designed, robust and agile coding practices, you eventually hit a very hard brick wall. To say they were an eye opener is an understatement. It felt more like a programming re-birth. In hindsight, all the signs of bad code were there, I had just become totally blind to it.
Not very long after reading both books, I tasked with making some changes to an old legacy Java system. In the past I had absolutely detested working on it. Everything felt like a mess and that the slightest change would bring the whole system to its knees. But I felt confident this time. I started writing tests, which I had never done before, and started using the absolutely brilliant refactoring capabilities of IntelliJ. I spent a lot of time refactoring code so that the new functionality existed, wrapped up, in a state that it should, rather then in a shoehorned/hacked state. No doubt it too me longer then if I’d just shoved it in, but the system became better as a whole for it. The long reach of the masses of refactorings I performed have left parts in a greatly improved state. Perhaps in some cases, with added complexity – a small price to pay for better testability, design and extensibility. I would rather have an added degree of complexity over a brittle design any time
Anyone can knock out code, anyone can cut-and-paste a system together if they tried hard enough, but writing code alone is a solution to a small fraction of the overall problem. Anyone can churn out new features for a v1 release, but what about v1.1 or v2 or v3. As developers we dig our own graves. Clients don’t understand why things used to happen so fast, but now it’s sometimes weeks before anything new is ever shown. Fast – Slow – Slower.
This is where good, clean code starts to come into it’s own. Code that’s light on it’s feet. Code that’s easy to move in and out. Code that isn’t a brick wall and requires you to code around. Good design and good coding practices are at the heart of delivering a robust solution. If you are a developer you need to read the books I mentioned above, or at least just Clean Code. Heck, as a developer you need to read books. FULL STOP. I know many developers who don’t read at all, which to me is just unthinkable. You maybe one of the few that shrugs their shoulders after reading something like Clean Code and says “Yeah, I know all this already.”, and if so, good for you, but even you will probably know someone who could do with reading it, probably more then once ;)
Read More <mx:series>
<mx:CandlestickSeries>
<mx:boxStroke>
<mx:Stroke weight="1" color="black"/>
</mx:boxStroke>
</mx:CandlestickSeries>
</mx:series>
One thing not mentioned in the Flex CandlestickSeries documentation is how to change the border colour of each candlestick. So you end up with a horrible orange border by default. This can be removed with the boxStroke tag.
Read More int {
NSAutoreleasePool * pool = ;
for(int i = 0; i < 100; i++) {
NSMutableString * fizzbuzz = ;
if(i % 3 == 0) {
;
}
if(i % 5 == 0) {
;
}
NSLog(fizzbuzz);
;
}
;
return 0;
}
We have lift off!
Read More
I’m not talking about being a Domain Specific Language, I’m talking about being a Domain Specific Loser. These are they people who don’t go to the trouble, and it is trouble, of broadening their skills and learning new things. They are the people who don’t care about anything that doesn’t have anything to do with what they are working on.
Hey, I didn’t sign up for this!
Technology is such a fast changing industry, that if you don’t keep up, you’re going to get left behind pretty fucking quickly. I had a load of things listed as points that every developer should be doing and then came across a post by Jay Fields which summed it all up perfectly:
- Have you tried Test Driven Development? Can you name something you liked and something you disliked?
- What language(s) that are gaining popularity, but not yet mainstream, have you written Hello World in?
- Do you read books or blogs looking for new ideas at least (on average) once every two weeks?
- Do you at least attempt to learn a new language every year?
- If you don’t understand a requirement, do you IM, phone, or go talk to the business?
- Have you ever run a code coverage or cyclomatic complexity tool against your codebase?
- and so on…
On average, 50% of the people I’ve worked with cannot answer those questions correctly. If you can’t answer them correctly
- You’re junior and could use a good mentor.
- Or, it’s time to find a new profession.
Developers go stale. It’s just a fact. I was stale and then I discovered Ruby on Rails and I was born again. I don’t mean that to say that Ruby on Rails is the light, but rather that Rails opened my eyes to doing things ‘better’. It got me excited about technology and programming again. It got me constantly thinking “How can I improve?”. And since then it’s been a long steady stream of new ideas, new techniques and new tools. Groovy, Grails, Git, Proper CSS, TDD, Agile, Scrum and of course OSX, etc. I am spending increasing amounts of time buried in blogs or books. Clean Code was a complete eye opener and my current read, Refactoring to Patterns, has me feeling like I am attaining programming Zen.
I think a lot of developers kid themselves into thinking they are developers. Even after working as one for nearly ten years I still feel like I’m a scraping off the bottom of a very deep barrel. Being a shit programmer is easy, anyone can cut and paste some code together, but where is that going to get you? When you hit 30+ are you really going to have the skills necessary to start jumping into to the £50k+, £75k+, £100k+ salary bracket? No, you’re not. Sorry. At that point, we’re playing for high stakes, and they don’t hand those jobs out to just anyone. If you’re a developer and reading this post, take a look at those Jay Fields’ questions again and be honest with yourself. If you can’t answer them correctly, you should seriously take a long hard think about what you’re doing with your career. You should be doing something you care enough about, that you want to be as good as, if not better than, the people at the top of the game.
Being shit is easy, being good is hard. We live in a world where no one wants to do anything for themselves, but that’s not how the world works. So do the right thing. Step outside the comfort of your regular language, read some books, read some blogs, try some new techniques. That’s all you need to do. Don’t allow yourself to become stale by working within the confines of your 9-5 job, its codebase and the developers around you. You need to step out of that mentally to really see what’s going on in the world of technology. I’ve probably learnt more from developers I’ve never met, then those that I’ve sat next to for years! If I hadn’t stepped out of such a silo, I’d still be developing applications in Struts, forever re-compiling and restarting the server, wishing there was an easier way. Now that I’m using Grails, I don’t know how I ever got by before. And with all the lessons and techniques I’ve learnt over the past six months, going back to those old Java/Struts applications is a joy, as it’s a chance to flex my muscles and do some fun refactoring and sprinkle some syntactic sugar around (Nothing is more satisfying then sweetening some smelly code).
It’s hard for some people to swallow. Being a developer today is not what being a developer was 5 or 10 years ago. A lot of people don’t want to adapt, and that’s fair enough, but that’s how species become extinct. They don’t adapt. Being a developer today is about so much more then just developing code. It’s about delivering solutions. From soup to fucking nuts. We should be able to interact with customers, spec out pieces of work and participate in groups to ultimately deliver on a customers’ need. It’s a bitter pill to take but that’s what the job is. It’s a far cry from what it was before, where writing software was like a holy quest, and the crusaders could never be questioned for fear of ever increasing budget and timing overruns. These days there are companies delivering software of such high quality and at such a high pace that customers become understandably agitated when their developers fail to do the same. There used to be a time where you could deliver a piece of shit and get away with it because people still didn’t really understand the web and what it was capable of. But you’re damned these days as clients want the same small features that make sites like Facebook, Gmail or Yahoo a pleasure to use. “What do you mean you can’t do it? XXX does! How hard can it be?”. *Ouch* I hope you’re up-to-date on your skills when that question comes around.
Read More