What makes Ruby/Rails Development Fun

I have been a full-time Ruby programmer for about a year now. I used ruby/rails before then but I didn't really "get it". Considering that I was a Java/J2EE guy before and never worked with dynamic languages, it wasn't surprising. Now that it has been a transformation and a worthy evolution, it is about time to review what makes ruby development fun. Yes, Ruby is known for its dynamism, expressiveness, malleability. But today I hope to list a few tools, techniques, concepts that make my programming experience fun these days. Here they are:

Continue reading »

Review of fixture_replacement2 plugin - Update

UPDATE:

So, after working on my project for months, and getting other developers involved, I need to change my mind.  I still like fixture replacement, but most of my tests require such an elaborate data set, that my tests are PAINFULLY slow.   What was I thinking back in November?  I guess I wasn't focused due to the Obamathon that was running through the nation at the time.

My application is an internal tool we use for staffing our projects, and is going to manage time entries and invoicing.  There are many other features in the pipeline, but I'm making sure that we keep our eye on the ball, and releasing the most important features first.  The problems I run into, are that most of my model methods are doing complicated queries on a data set that has a lot of possible values.  To test some of my reports, I need to test the cases where there are people on various projects, vacations, holidays, out of office, etc.  To ensure that the method responds correctly with all of these possible values, my data set is complicated.  I have a number of test helper methods that set up some or all of my data set depending on what I am testing.  This has effectively replicated fixtures, and I have lost my speed.

What are my issues:

1. Fixtures are wicked fast.  Fixture replacement is not when you have large data sets.  Why?  Fixtures essentially load the data in the tables, then start a transaction before each test and rolls it back after each test.  Fixture replacement does not get this benefit, as all data is loaded after the transaction is started.  So my tests take forever....

2. Because I need complicated data sets that are reusable, My test helpers set up the data in stages, and I only load what I need.  One of the problems I had with fixtures, was I always had to go the fixture files to see what data was loaded.  When using fixture replacement, my test data is normally defined in a setup context of at the beginning of each test, so i can see exactly what data is on the model I'm testing.  Due to my test helper setup methods, I now am constantly referring to them instead of the fixture files.

My plan:

As my project takes a few minutes to run the tests, I need to fix this, as my application will begin to be used by the entire company for time tracking, and the features will need to roll out quickly.  I can't have any developer waiting minutes before each check in.  This will only lead to test mutiny (checking in without running rake).  So, my plan is:

1.  Create a new data set in fixtures that includes an updated view of my projects (the current one is stuck in July of last year).  Use mocks to mock out Date.today.  I was setting an effective date as a member variable in my tests, but I like the idea of mocking it out better.  I will also create some sort of visual depiction of my data set, as I am constantly trying to figure out what the application should generate, as I created my data set months ago, and generally don't have any idea of what it looks like when I am adding new features.

2. Slowly convert my tests to use my new data set.

3. Kill my old fixture replacement setup helpers

4. Only use fixture replacement for small unit tests.  Most of my simple model methods can use a very simple setup with fixture replacement.  The model methods that are crazy complicated can use the fixtures and date mocks.

So - I still like fixture replacement, but It is not good for large data sets.  I think fixtures are still useful and their speed only sweetens the deal.....

Original blog post:

We have been using fixture_replacement2 on some of our Ruby on Rails projects. I am writing an internal application and finally switched over from using fixtures. It took a bit of time to get the tests that I had written modified to stop using the fixture data, but now I am completely fixture free. The tests are a lot easier to write, and I created a few helper methods that setup common datasets. This way, I can call a setup method to configure my data, and then - it's all good. At first I called the method test_data_blah, and was wondering why I was getting an error running any test, so now it's called data_blah.  Doh!

At first I didn't like the fact that I needed to explicitly create the data for what I was working on, but then I realized that (especially for unit tests)  you don't need much dependent data; usually it's one or two records. For functional tests, I found that the data setup methods rocked, as I could quickly get the data set up that I needed.I could quickly assert the content of the response, based on the data in my setup. I missed fixtures at first, but now realize that over time, they are a pain.

Continue reading »

acts_without_database: Leverage ActiveRecord with Non-Database Backed Objects

ActiveRecord comes with a lot of nice things that aren't really dependent on having a database backed model. The most obvious example of this is the validation framework baked into ActiveRecord. Also, there are several plugins which add some useful behavior to ActiveRecord objects but don't rely on having a database.

In the future, I believe the rails team aims to make certain things more modular and easier to pull out and use separately from ActiveRecord (validation being one of those). However, if you are working on a project which is locked into a certain version of rails or you're impatient, there is a very simple plugin which can solve your needs.

Enter acts_without_database...
Continue reading »

Firefox Plugin Malware ‘Trojan.PWS.ChromeInject.A’

You knew it had to happen. Malware for Firefox. It happens all the time with IE (so much so that my 17-year-old niece needs a fresh install of Windows every 3 months), but Firefox has been a little less prone -- though not imune -- to malware. See the BitDefender blog post and the Infoworld article which has a bit more detail.

Now Firefox 3 does contain Malware protection, but apparently this plugin is delivered via other system compromises to the filesystem, and apparently Firefox doesn't question already installed plugins.

BTW, the malware registers itself as GreaseMonkey. If you care to, you can follow the Slashdot food fight on this topic.

More as I find out more...

Five jQuery plugins that are a joy to use

Yesterday I discussed how to separate the jQuery plugin wheat from the chaff. Today, I offer a completely subjective and biased list of jQuery plugins to know and love.

Continue reading »

jQuery plugins: Five tips for separating the good from the bad and the ugly

I opined recently that jQuery plugins can be more trouble than they're worth. That said, they're often indispensable. True, the worst plugins suffer from bloated code, confusing APIs and too many features. But the best provide instant black-box functionality with just a little configuration. The trick is figuring out which plugins are worth the effort and which ones aren't. Here are five tips for doing just that.

Continue reading »

About Pathfinder

Follow the Blog

    Get a monthly update on best practices for delivering successful software.

    Subscribe via email

      

    Subscribe via RSS      RSS icon

Topics

Search

WordPress

Comments about this site: info@pathf.com