End of Iteration 7

Yes!! this was a 2 weeks iteration. Going forward, I am planning to have a 2 weeks iteration. With my marathon training , I am not able to spend much time in Varcasa.

Anyways this Iteration 7 was frustrating, but it ended in a good note. In this iteration I was mainly trying to deploy my iteration 6 code in production. I was having problems with acts_as_plugin.

Problem 1) My production hosting had a old version of acts_as_plugin gem.
Solution : I thought I could freeze acts_as_plugin in vendor directory, so I do not have to worry about gem version in production environment.

Problem 2) Rails by default doesn't come with a rake task to freeze third party gems
Solution: Found rake task in web that could do that.

Problem 3) Rake task for freezing third party gems did not work.
Solution: I got the latest code for acts_as_taggable from subversion and copied into my vendor/plugins folder

Problem 4) Still for some reason I was having problem in production environment, that I was not able replicate in my development environment.
Solution: Found that I was having "require_gem acts_as_taggable" in my environment.rb.So I deleted that line and I was able to reproduce that problem.

Production Problem : My Article class does not recognize "tag" method
Solution: Added "require acts_as_taggable" in top of my Article.rb

But in the end of iteration , I felt good that I was able to deploy in production.

Next Iteration:
-> Give more information what Varcasa is to users who want to register
-> Contact Us section
-> Fix some known issues

End of Iteration 6

Finished migratating to Tags instead of categories. Still havn't allowed to edit or add tags. So there is not much change from user's prespective.

By using acts_as_taggable gem and moving away from Categories, I was able to delete so many lines of code. It is a good thing, " Less code, less chances of error" :)

The only problem, I am facing that I was not able to solve is deploying it in my production server. For some reason my database migratation fails in production server. It is looking for articles_tags table in production server, when I have table named tags_articles. It is working fine in my local system. I checked all my gem versions etc.

New Web Template

Let me know what you think.

End of Iteration 5

Nothin much has been done in this iteration.

End of Iteration 4

In this iteration was mainly working on getting rid of categories and using Tags. As I have mentioned in my previous post, I am using acts_as_taggable plugin. I thought I will be done this iteration, but I faced some problems with acts_as_taggable plugin (gem)

1) I installed acts_as_taggable as a plugin. RDoc of acts_as_taggable was having many methods that were not present in plugin code. After investigating I found plugin was installing a very old version of acts_as_plugin. Even after tryin to update the plugin it was still the same.
2) After checking in rubyforge I found out that they are exposing acts_as_plugin as a gem. So I installed the gem in my system. I checked the code and it was latest having all the methods I was expecting.
3) So I unfreezed my rails and freezed rails again. I was expecting all the gems in my local to be freezed. I found it was freezing only gems that rails was dependent on. I was looking is there anyway I could change gem spec for rails to make it dependent on acts_as_plugin gem in vain.
4) Then after googling , I found out that there are many others are tryin to freeze third party gems. I feel this task should be added as part of default rake file.

Loading Dev Database with Fixture Data

I just found abt this nice rake task, that will load ur developement ( or any environment) database with your fixtures. It is so simple,

rake db:fixtures:load