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
I said it before and I’ll say it again. Don’t like the new Facebook? Tough. Suck it up.
I’m so glad that I’m not just getting started as a web developer these days. Facebook is the main example I give to people when talking to about this. It has set the standard for what and how people think a web app should behave. Move forward or backwards through photos and they are dynamically loaded without refreshing the page. Send someone a message and a modal box appears with autocomplete on the textboxes. You can browse the site, chat to friends and do all sorts of stuff without ever having to experience a page refresh. I even remember when they added AJAX to their photo albums. I mentally flipped as it made the site so much more usable. I showed it to someone going “Look! Look! There’s no page refresh.” while they just shrugged and went “I don’t see what you mean.”, D’oh… exactly! The sort of stuff no one even realises is happening. But I’m sure they’ll feel the difference if they use functionality on your site that’s similar to something Facebook does, but which requires a refresh where as Facebook doesn’t. Even I feel the pain of moving forward and backwards through photos on Flickr. After the third or fourth page refresh, I just give up.
When I got started, web stuff was so new and so simple that in hindsight it was amazing what you could get away with. You could just fly by the seat of your pants. I know I did. The first piece of web development I ever did was back in the mid nineties two days before my first interview. I wrote a Java servlet that simply took a single text parameter and queried a MySQL database using JDBC. I showed it at the interview and got a job as a web developer using Perl. I didn’t even know the Perl but still got the job. All I had to do, day-in, day-out was write HTML and scripts that responded to clicked links or submitted forms. Submit, refresh and display the result, job done, I can go home now. Creating a site wasn’t hard, almost anyone could do it and almost everyone was at the time. Life was simple and it was pretty much a level playing field. Now though, it is a totally different ball game. You’ll need good knowledge of at least a couple of languages, HTML, CSS (Yes we need it to work across all the major browsers), SQL, Javascript + a framework like jQuery + how to use AJAX.
There is just so much that you need to know that if you’re not doing this in your spare time, how are you supposed to ever compete with the kids nearly half your age who can already do this stuff with their eyes closed. Even me, who does this stuff every day as a job has to learn more and more if I even want a chance of staying relevant and employable. I love learning, so it doesn’t bother me. Programming still turns me on and it has to if you ever want to make a go of doing this for a living. Sometimes you can be in the fortunate position of working for a company that really loves this stuff, so you can learn and grow, but I suspect the majority of IT related jobs are done in companies where IT is a second thought to their overall business goal. Where managers prefer to say “no” to your ideas rather then say “ZOMG we could totally awesomely AJAX dis bitch up!!!11!”. And the learning doesn’t just stop at work related subjects. There’s a lot to be said about learning new languages and techniques totally unrelated to your work. Not only for the mental stimulus but also how they can teach you to approach a subject in a new way. I admit this is perhaps one area where I don’t spend enough time, but I’m trying. So go forth and learn. Be totally fucking awesome.
After reading the Jeff Atwood’s arrogant post on IMVU’s brilliant technical success’s, reading this was the final straw in clicking the remove button on his Twitter feed. What does arrogance have to do with making a business decision not to do a netbook? Sometimes things just don’t make business sense. When you brand yourself in a certain way, why would you want to potentially harm that perception with a bad product. It only takes one bad decision to unravel years of good ideas and brilliant execution.
They’ve learnt well from their own past and other people’s mistakes of trying to do everything and be everything to everyone. They’re not a “me-too” company, and becoming one would probably be the end for them. They don’t need to do X and they don’t need to do Y just to satisfy investors or the public at large. They owe no-one a netbook.
It’s been a day with Safari 4 and I’ve yet to find a reason to switch back to Firefox. With it’s new developer tools, my discovery of FoxMarks for Safari and the Delicious Library bookmarklet I’m pretty much where I was with Firefox. The only thing I am currently missing is adblocking. I’m not sure if PitHelmet currently supports Safari 4, but Glimmer Blocker looks really good. It’s interesting that it works on the network level rather then as a browser plugin.
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.
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.
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.
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.
Over Christmas I read a post on Wirehead Arts which got me thinking about digital cameras again. I tend not to give the digital realm of photography much thought as I’m deeply in love with film. And while I’ve looked into the Canon 5DmkII and Leica M8 a bit, ask me about the rest of the Canon line, any of the Nikons or about any compact P&S and I’ll be a total blank. But after some thinking and research I thought that perhaps a small digital P&S wouldn’t be a bad addition. To begin with I looked into the Canon G10 and Leica D-LUX 4. With the D-LUX4 being a Leica, I couldn’t help being instantly lured in, but I was very surprised to find it’s basically a re-badged Panasonic Lumix LX3 which is £300 less. What do you get for your extra £300? a custom firmware and a leather strap, no thanks. The G10 is very highly regarded and use as the work horse or plenty of “pro-amateur” photographers, not to mention having the advantage a built in viewfinder. I’ve never been a fan of framing with a screen when I’ve tried it, personally I find it slow and cumbersome, so the G10 was instantly interesting, but the LX3 has a hotshoe onto which an external one can be fitted. In the end it was the combo of the hotshoe, wider and faster lens and HD video recording abilities of the LX3 that won me over. So now I have a digital P&S. I haven’t had a chance to test it outdoors, but immediately I’m highly impressed the breadth of functions and overall tweakability of it. I’ve uploaded a test HD video here.
I recently saw a great video showing Daido Moriyama shooing on the street so I’m going to try shooting without the viewfinder for a bit and see how I get on before deciding if I really want one or not.
One of my biggest flaws is I’m a complete gear head. If I see a great photo, I always have to know what equipment or what film it was shot with. My brain just seems hardwired to do it. There is this belief that somehow, if I had the same equipment I would capture the same beautiful moments, which is of course totally false. As said by Nobuyoshi Araki in the video. It doesn’t matter if you write a romantic love letter with a pencil or a ballpoint, and as Moriyama says himself, any camera is fine, it’s only a means of taking a photograph. Damn, it still hasn’t stopped me watching his video and the immediately checking the price of used Ricoh GR1s.
I also updated my personal photography site over the weekend:
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.
I 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?
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.
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 ;)