Because I maintain several open source projects on Github I'm constantly getting emailed questions or issues, or people are always opening up tickets with bugs, issues, complaints, etc... And I really appreciate the feedback on these projects, I really do. What I would appreciate more is if instead of just opening a ticket, or sending an email, why not fork the project, fix it, and then contact me?
Now, I know that sounds like a lot of work, but honestly it's really not.…
For the last few years every project or company I've worked for has started the same way, by setting up Basecamp, Lighthouse and Hoptoad (or similar ones anyway). Why? Basecamp - so we could share documents and todos. Lighthouse - so we could track our issues and bugs. Hoptoad - so we could track the errors our application was generating.
These are all very good applications and have served myself and my clients well, but they've suffered from several very big flaws. The …
In case you've been living in a cave this week you've probably heard that Ruby on Rails is going to be including both the CoffeeScript and SASS libraries, it will also make jQuery the default framework, replacing the Prototype framework.
I would like to start by addressing my experiences with. My opinion of it is of ambivalence. I've used it on a project, I've played with and in the end I've …
" Testing is painful."
" Testing is hard."
" Testing is complicated."
" Testing is not fun."
I hear those sorts of things all the time when I talk to people about testing. I agree that sometimes testing can be all of those things, but if you choose the right tools, the tools that best suite you, testing doesn't have to be. Let me give you an example of what I'm talking about, how choosing the right tools can make a huge impact on how you feel about testing.
In Java anis a basically a blueprint of methods that the class who implements the Interface needs to implement. For example:
Last week I received an email from someone who used to work at a company that I used to work with. I didn't know him, but he knew me through my work at the company, and my other exploits. He sent me an email to say that after a short time with the company he had been laid off, along with half of the development team. He wasn't looking for pity, but rather advice.
What kind of advice was he asking for, well, he quite simply needed to know how could he become an ‘expert' Ruby on Rails…
In a previous post, Testing Is Not An Option , I talked a lot about why you should write tests, and the arguments you can put forth to your client, manager, or whoever it may be as to why you should write tests. What I didn't talk about was how to start writing tests. So let's talk about that for a bit, shall we?
When I'm talking with a potential client, well at least a client that has an existing code base, I always ask what their code coverage stats are. Now, I know …
In August I announced CoverMe a code coverage tool for 1.9. Well, today I announce that it has hit it's first release candidate! I've very excited by the fact it's getting close to an ‘official' release.
The response to CoverMe has been great and through feedback from the community I've made a lot of improvements and fixed a lot of issues.
While quite a few things have changed under the hood, not much has changed in how you use CoverMe.
Testing in Ruby on Rails is incredibly easy. I mean stupidly easily. So easy that if you're not doing it, you are a very, very bad developer and should re-evaluate your career choices. (Yes, I believe in testing that much!) One thing that is not all that easy, however, is object creation and populating your test database. Five years ago when I first started working with Rails the only options we had to get data into the database were fixtures, or hastily written ‘factory'-esque methods custom to each application.
Ruby 1.9(.2) is an amazing language to develop applications in. It's faster, more powerful, cleaner, and a huge improvement over1.8.x. Because of those reasons every Ruby developer should move to this exciting new version of our language.
When making a move of this size it's important to have the right tools to help us along. Unfortunately, one of the most useful tools as a Ruby developer, RCov , does not work with .