This is a shameless self-promotional post.
I just started working at Zendesk.com, we provide SAAS Help Desk software that is dead simple to use. It costs nothing to try. Learn not to hate answering tickets! :)
http://zendesk.com
Wednesday, July 1, 2009
Sunday, April 19, 2009
Ruby 1.8 and 1.9 living together on Mac OSX
What you first want to do is, of course, install Ruby 1.9.1 (your tarball name might differ)
> wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.gz
> tar xvf ruby-1.9.1-p0.tar.gz
> cd ruby-1.9.1-p0
> autoconf
> ./configure --prefix=/usr --enable-pthread
> make <== This will take some time
Now before you install you should backup your current Ruby's bin files...
> sudo cp /usr/bin/ruby /usr/bin/ruby-1.8
> sudo cp /usr/bin/irb /usr/bin/irb-1.8
> sudo cp /usr/bin/gem /usr/bin/gem-1.8
Okay, let's continue with the install
> sudo make install
After this is complete confirm that Ruby 1.9.1 is installed
> ruby --version
> irb
> RUBY_VERSION
> exit
Now, because we're assuming that you'll most likely be usining 1.8.6 most of the time still let's restore it and backup the bins for 1.9.1
> sudo mv /usr/bin/ruby /usr/bin/ruby-1.9
> sudo mv /usr/bin/ruby-1.8 /usr/bin/ruby
> sudo mv /usr/bin/irb /usr/bin/irb-1.9
> sudo mv /usr/bin/irb-1.8 /usr/bin/irb
> sudo mv /usr/bin/gem /usr/bin/gem-1.9
> sudo mv /usr/bin/gem-1.8 /usr/bin/gem
Now if you want an app to run with Ruby 1.9.1 just replace the first line of the script:
#!/usr/bin/ruby
with
#!/usr/bin/ruby-1.9
Happy Hacking!
> ./configure --program-suffix=19
The End
Friday, January 30, 2009
Going back on Mocking & Stubbing with RR (kind of)
Almost 2 months ago I wrote an article called A case against Mocking and Stubbing. In it I outlined why I think mocking & stubbing is a bad idea. I still maintain some of those beliefs but since I've been playing with the mocking framework RR I have changed my tune some.
RR allows for a much cleaner and faster way to write mocks and stubs. There is a whole lot more to the framework that I won't get into here. What I will say is that I have started to use RR in my functional tests. And not just to mock outside resources.
In my cited post I described my development process: start at a very high abstraction level (user stories) work my way down the stack until you get to the unit tests, then go back up making each level pass. This creates a high level of integration into the app and makes certain that if you change something in a lower level the change is felt at the higher levels.
So, my argument previously was that if you mock your models and stub out their methods in the functional tests then you lose that level of integration between your models and controllers. If you changed something in your model your functional tests would still pass because the behavior has been stubbed out.
There should be no reason to change the behavior of Active Record. Monkey Patching is generally a bad idea. So if we can assume that we will *never* change the behavior of Active Record then there is no reason why we cannot stub out that behavior.
For the sake of my fingers I have pretty much limited my stubbing to any AR methods that hits the database. AR#save, AR.find are of course the two big ones. I think I'm settling upon this testing scheme for the time being.
RR allows for a much cleaner and faster way to write mocks and stubs. There is a whole lot more to the framework that I won't get into here. What I will say is that I have started to use RR in my functional tests. And not just to mock outside resources.
In my cited post I described my development process: start at a very high abstraction level (user stories) work my way down the stack until you get to the unit tests, then go back up making each level pass. This creates a high level of integration into the app and makes certain that if you change something in a lower level the change is felt at the higher levels.
So, my argument previously was that if you mock your models and stub out their methods in the functional tests then you lose that level of integration between your models and controllers. If you changed something in your model your functional tests would still pass because the behavior has been stubbed out.
There should be no reason to change the behavior of Active Record. Monkey Patching is generally a bad idea. So if we can assume that we will *never* change the behavior of Active Record then there is no reason why we cannot stub out that behavior.
For the sake of my fingers I have pretty much limited my stubbing to any AR methods that hits the database. AR#save, AR.find are of course the two big ones. I think I'm settling upon this testing scheme for the time being.
Tuesday, January 27, 2009
One Month No TV Challenge
So, continuing with my productivity thread I've decided to completely cut out TV for an entire month. I've given this some thought and here are my current TV viewing habits:
Now, when I break down the pre-recorded programs I watch I would easily say that anywhere from 50% - 75% of my TV viewing time is dedicated to watching episodes of shows I've *already seen*. I find it easy to toss on an episode ofScrubs or Star Trek (anything except Voyager!) that I've seen a million time. Much easier than reading one of the many books I have piling up. This ties into my theory I have that most people will always choose the Path of Least Resistance for spending their time. TV is the easiest way to do this. The only way to overcome this is self-discipline.
Okay, so here is what I'm cutting out starting today:
Instead I'm going to dedicate that time towards reading on different subjects I'm interested in, maybe try to learn a new programming language (Schema here I come!) and get more exercise.
It is so strange to actually write about this. It seems that cutting out TV completely would be simple. Go cold turkey, but thinking about it you begin to realize just how ingrained within our society TV has become. It is probably one of the most powerful and influential forces around today. So, let's see how this 1 month goes!
- I would say that most of the TV I watch consists of pre-recorded shows. Something that I could easily catch up on at a later time. With such services as Hulu and NetFlix I really shouldn't have to bother watching regularly scheduled programming. True, I do have Comcast DVR but for some reason I feel compelled to watch whatever shows I have recorded asap.
- If I'm watching live TV it is usually Boston sports. I'm mostly a Boston Red Sox fan. And of course, they're out of season right now. I do enjoy watching the Celtics and Bruins from time to time but I'm going to stick to my guns on this challenge.
Now, when I break down the pre-recorded programs I watch I would easily say that anywhere from 50% - 75% of my TV viewing time is dedicated to watching episodes of shows I've *already seen*. I find it easy to toss on an episode ofScrubs or Star Trek (anything except Voyager!) that I've seen a million time. Much easier than reading one of the many books I have piling up. This ties into my theory I have that most people will always choose the Path of Least Resistance for spending their time. TV is the easiest way to do this. The only way to overcome this is self-discipline.
Okay, so here is what I'm cutting out starting today:
- All TV programs
- All YouTube.com or other similar videos (unless they offer some type of benefit to me, educational)
- Movies (both theater and broadcast)
- Any video games (although I haven't really played any in a while)
Instead I'm going to dedicate that time towards reading on different subjects I'm interested in, maybe try to learn a new programming language (Schema here I come!) and get more exercise.
It is so strange to actually write about this. It seems that cutting out TV completely would be simple. Go cold turkey, but thinking about it you begin to realize just how ingrained within our society TV has become. It is probably one of the most powerful and influential forces around today. So, let's see how this 1 month goes!
Friday, January 23, 2009
Increasing My Productivity II
More productivity increasing:
1.) The multi-touch MacBook touchpad is VERY useful. Learn all of the finger strokes.
2.) (this is from Bryan Liles) This kind of goes against #1 but don't use the mouse for an entire day. Try to memorize all OSX keyboard shortcuts You'll be surprised how much faster you'll be working.
3.) Purchase and watch the Peepcode Productivity Screencast.
1.) The multi-touch MacBook touchpad is VERY useful. Learn all of the finger strokes.
2.) (this is from Bryan Liles) This kind of goes against #1 but don't use the mouse for an entire day. Try to memorize all OSX keyboard shortcuts You'll be surprised how much faster you'll be working.
3.) Purchase and watch the Peepcode Productivity Screencast.
Friday, January 9, 2009
Increasing my Productivity
In my never ending attempt to increase my productivity I've started printing cheatsheets and hanging them up around me. I have a terrible memory and spend a good amount of time bouncing between RDocs looking up methods that I've used 100 times before. Next step: master Textmate... then probably go back to VIM. (or Emacs)
Rails Testing
Shoulda 2.0
TextMate for Rails
Please let me know of any other favorites in the comments! :)
Rails Testing
Shoulda 2.0
TextMate for Rails
Please let me know of any other favorites in the comments! :)
Tuesday, January 6, 2009
Testing Your Helpers Sucks (but necessary)
Lately I've been really focusing on getting 100% code coverage and keeping my views free of all logical statements. This means moving all of the logic that would be in a view into a helper and testing that helper. In a previous post I spoke about testing your helpers. Here are some things I've learned since then:
1.) Helper testing is very much like Unit Testing (hell, it *is* unit testing). When I first was getting into helper testing I thought that the Rails test directory should have an extra folder called "helpers". I now think that the "helpers" should be under the "unit" folder. In fact, there should probably be a "models" folder in there too to keep everything separate.
2.) Testing your helpers can be a real pain in the ass when your helper calls any regular ActionController#base methods. For example, a few of my helpers might make a call to render a partial. Good luck on getting this to work in your helper tests. Because the helper is just a module that is being included into the unit test you don't have access to everything that you normally would. Instead I had to mock out the render method. Saying this of course really makes me look like a dickhead.
3.) The expected results from your helpers is most likely HTML. Testing against this SUCKS! The HTML can be very verbose sometimes, and I feel like I am just wasting a lot of time hard coding expected HTML from my helper. And most of the time the tests fail because the spacing or order of the tag elements are off. I have recently been cheating and just pattern matching against expected HTML params. I think this is okay to do because I use Rails' content_tag method to generate the elements so there should be no chance of illegal HTML being generated.
In the end, is it worth it to test helpers? I'm not entirely sold to tell you the truth. I believe that you should be TATFT but there comes a point when the cost outweighs the benefit. I feel that helper testing is just view testing in disguise. The only thing keeping me testing my helpers is that there is logic in them.
1.) Helper testing is very much like Unit Testing (hell, it *is* unit testing). When I first was getting into helper testing I thought that the Rails test directory should have an extra folder called "helpers". I now think that the "helpers" should be under the "unit" folder. In fact, there should probably be a "models" folder in there too to keep everything separate.
2.) Testing your helpers can be a real pain in the ass when your helper calls any regular ActionController#base methods. For example, a few of my helpers might make a call to render a partial. Good luck on getting this to work in your helper tests. Because the helper is just a module that is being included into the unit test you don't have access to everything that you normally would. Instead I had to mock out the render method. Saying this of course really makes me look like a dickhead.
3.) The expected results from your helpers is most likely HTML. Testing against this SUCKS! The HTML can be very verbose sometimes, and I feel like I am just wasting a lot of time hard coding expected HTML from my helper. And most of the time the tests fail because the spacing or order of the tag elements are off. I have recently been cheating and just pattern matching against expected HTML params. I think this is okay to do because I use Rails' content_tag method to generate the elements so there should be no chance of illegal HTML being generated.
In the end, is it worth it to test helpers? I'm not entirely sold to tell you the truth. I believe that you should be TATFT but there comes a point when the cost outweighs the benefit. I feel that helper testing is just view testing in disguise. The only thing keeping me testing my helpers is that there is logic in them.
Subscribe to:
Posts (Atom)
