Gems not getting attached on Windows (7) with RubyMine 3

This night I had a frustrating problem. I bought RubyMine the other day for usage when learning Rails.

After 20 minutes I was ready to tear my hair out. No matter what I tried RubyMine kept saying that I needed to attach the rails gem. It also couldn’t execute tests since test-unit was not attached and so on. Gem install worked fine from the command prompt and bundle install did was working too.

Ended up being that I had set up both GEM_PATH and GEM_HOME last week when installing rails (I had trouble with windows permissions..). They pointed to different (non-standard) directories.. Setting up only GEM_PATH to the correct path worked wonders. For me this was ruby install dir\lib\ruby\gems.

E.g:

I:\Ruby192\lib\ruby\gems

After that life was fine again and the cortisol levels were dropping. :-)

TLDR: don’t change defaults on a poor development platform.

Lessons Learnt After Developing a Web Application – Coding

Yesterday I talked about how the project was executed in both the design and implementation phase. Today I’m ranting a bit more in detail about how we coded the thing in PHP (v5).

Database Access

Our Approach

When coding started, we agreed on (or rather, I pushed the view) that we should use the DAO pattern for our database access needs. To work easily with the database, and also to have the possibility of prepared statement we used Creole, a PHP database API that’s very similar to Java’s.

Soon, we had our DAOs. Though, all was not good. Eager to get going we started coding using our new functionality and didn’t bother coding up the corresponding service layer for them. This was alright to begin with since the application only had some basic CRUD functionality. The problems (or future problems if you want..) became obvious when we started adding functionality that cut across the model objects. Code cutting across the DAO layer was made. And this in turn led to duplicated code.

At that point, I guesstimate that our application was ~70% done. So, to go back and change everything into using a Service Layer wasn’t an option with the deadline closing up and the code was delivered with those nice dependencies within the layer.

Alternative Approaches

Looking back, I see that the Active Record pattern probably could have been a good choice.

The View (and Controller)

This was probably the hardest part to get done right. And there’s no real consistency in the approach here.

Some places the code for handling form data and get requests were in the same file, and the page posted to itself. I guess this is fine for smaller scripts, but some of ours were starting to get big quick, and doesn’t look very maintainable.. In other places there was sort of a controller. They took POST data and redirected with a header(“Location: foo”) call. This is a much more maintainable approach, and very MVC.

I think the issue would have been better solved using perhaps the Front Controller pattern or a good MVC implementation. Both coupled with a template language such as Smarty.

Summing up

Creole was a good experience. We lacked a good approach from the data layer and up. Using a framework like CakePHP or symfoni would probably been the best thing to do.

I think I have learnt a thing or two now.