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’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.
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