Posted by Peter Morris
Fri, 20 Jun 2008 13:34:00 GMT
My platform of choice is Ruby on Rails.
In an early project, I implemented some reports by coding special purpose sql statements embedded within model methods. This worked well, and allowed the reports to run reasonably speedily.
As I continued to maintain the application and requirements changed, I found that I was reluctant to change the way the model objects interacted as it would require not only changing the model code, but sifting through the mounds of complex and convoluted sql.
What had been an efficient way to handle a problem (generating the reports quickly but in coding time and in runtime) had resulted in ‘scar tissue’, or maybe a fossilisation of my object model structure within the body of the sql.
Over time, this caused me to change the way I was altering the design, by forcing me to add layers around classes instead of refactoring within them.
After I finished on that project, I reviewed what I had done and vowed never to create sql ghettos again.
I think it is an apt term ‘sql ghetto’. An area in your application that you almost dare not go. that hinders future development, forcing it to work around it.
Resist the temptation to make ghettos, for they will surely come back to haunt you.
Posted in Coding | Tags ghetto, rails, ruby, sql | 2 comments
Posted by Peter Morris
Wed, 30 Apr 2008 13:45:00 GMT
Ok, so I have been using to_xml to handle generating xml serialised lists for a restful xml interface.
I came across this interesting situation.
If you are serialising a collection which is implemented as a set of subclasses using STI, the to_xml will generate different xml depending on which class of items it sees first.
For instance, if you start the list with an instance of the base class, it will generate a list encapsulated with the plural name of the class name, and each element will be a singular of the class name for the base class, irrespective of which classes each of the objects are.
BUT, if the first item in the list is one of the subclasses, the to_xml call will see that it is a heterogenious list (presumably because the successive items don’t all return ‘true’ for .kind_of? of the class of the first item, and will generate a xml list encapsulated as <record> entities within a <records> list.
Oh, that makes me SOO happy.
Posted in Coding | Tags coding, rails, xml | no comments
Posted by Peter Morris
Mon, 14 Apr 2008 07:18:00 GMT
I am quite a proponent of TDD/BDD, my framework of choice being RSPEC within Rails
But, I also understand that for people unused to TDD, the upfront investment seems daunting. So, I was very interested to be told about…
DOCTEST
This seems to be a nice light introduction into TDD. I can see that for extensive test coverage it is going to be a bit of a problem, there being no concept of fixtures etc. But I can definitely see someone adopting DOCTEST and then moving on to Unit testing or RSPEC later.
If you do not already embrace TDD, and recoil at its apparent heaviness, give doctest a look, but remember, tdd can be habit forming.
Posted in Coding | Tags bdd, coding, rails, tdd | no comments
Posted by Peter Morris
Mon, 22 Oct 2007 06:50:00 GMT
I am a stalwart follower of the PEEPCODE screencasts.
I particularly liked the series about RSPEC.
But, in reviewing the code for it, and using the code subsequently, I found this little gem.
class Hash
def except(*keys)
self.reject{|k, v| keys.include?(k || k.to_sym)}
end
end
Now, I don’t know where this code came from, but its wrong.
WRONG, WRONG WRONG…
that “keys.include?(a || b)”, I see that, and know exactly what it WANTS to do, but it does not do it.
it will NOT return true if either a or b is in the keys, it WILL return true if a is in keys or a is null and b is in keys.
to get the desired effect you would have to
‘keys.include?(a) || keys.include?(b)’
not as pretty, and my mind says that it likes the other version, but that does not stop it being WRONG.
Anyway, go to Peepcode, buy screencasts and marvel at the information density.
Posted in Coding | Tags bug, peepcode, rails | no comments
Posted by Peter Morris
Mon, 22 Oct 2007 05:41:00 GMT
Rails is nice. Rails is REAL nice, but, you would expect me to say that, I am a rails developer.
One thing that rails is not nice about is efficiency.
It’s elegant, its compact, but, the simplest things can have unforseen consequences unless you understand at a fundamental level, whats going on.
The persistence layer of Rails is a class called ActiveRecord (Specifically, most of it is tied up in ActiveRecord::Base)
When you want to do something with every row in a table, or with a subset of rows, you want to do something like this…
ModelClass.find(:all).each do |item|
... do stuff ...
end
Take it from me, that would be bad.
What it would do is instantiate every row in the table as an object and build an array of those objects in memory. Thats fine if you have 10, 100, 1000 rows in that table, but what happens when you have 100000 or a million? Well, we would be in for a long wait.
Read more...
Posted in Rails | Tags coding, dry, rails, ruby | no comments
Posted by Peter Morris
Thu, 06 Sep 2007 08:48:00 GMT
... it’s about GOOD.
Using Agile techniques, Rails for instance, or any of the other new frameworks popping up more quickly than mushrooms on a cowturn in a darkened room, and things like TDD, BDD, SPEC driven whatever, is NOT about writing code FASTER than previously.
Its about writing code in an acceptable timescale that is maintainable, extensible and more easily supportable.
Sure, if you develop in rails and forgo all the speccing, test script converage etc, you can write code more quickly than the guy in the next cubicle, but what about the poor bloke (possibly you) who has to support it into the future.
Writing in Rails with good test/spec coverage, and careful design, takes time. But the framework itself saves you enough time with respect to other platforms that this extra time is actually saved from other activities.
Expecting a well written RAILS development to be VASTLY quicker than using some other set of tools AND to expect it to be better quality and easier to support is wishing for your cake and eating it too.
Good code takes TIME, it takes THOUGHT.
Posted in Coding | Tags bdd, moaning, rails, rspec, tdd, testing | 3 comments
Posted by Peter Morris
Thu, 06 Sep 2007 07:52:00 GMT
Nudge Nudge, Wink Wink, Say NO MOWER!
or so the old sketch goes.
Well, here is a peepshow that even a mother could love.
Read more...
Posted in Coding | Tags peepcode, rails | 1 comment
Posted by Peter Morris
Thu, 06 Sep 2007 07:42:00 GMT
Rails uses MVC.
Its important to correctly partition what each section does.
Views and Controllers should NEVER make decisions.
Models should make decisions, and controllers and views should ask models for permission.
For instance, if you have a a User model and some other model like, for instance something that remembers it position and is owned by a user, the view can ask the model whether it allowed to alter the object before it puts the user interface to allow movement.
in the view…
<% if @moveable_thing.editable_by?(@logged_in_user) %>
... interface to move the object …
<% end %>
Well, thats ok, BUT, it embeds a decision in the view.
What decision? well, whether an editable object is moveable of course. Later on, a user may be able to edit the contents of the object but not its position, and to make that change you have to now scan all controllers and views.
Better by far…
<% if @moveable_thing.movable_by?(@logged_in_user) %>
Now, we have removed ALL decision making from the view.
If this means we have to do silly things in the model like….
def editable_by?(user)
...
end
def moveable_by?(user)
editable_by?(user)
end
then, so be it, its a small price to pay.
Posted in Coding | Tags coding, mvc, rails | 2 comments
Posted by Peter Morris
Tue, 28 Aug 2007 21:56:00 GMT
The classic way in rails of implementing model behaviour control of controllers and views is to decorate your model classes with methods which expose behavioural information.
For instance, for this message, we will consider an application which has users and meetings.
Now, my question is, which direction is best?
Read more...
Posted in Coding | Tags ood, oop, rails | no comments
Posted by Peter Morris
Wed, 22 Aug 2007 13:41:00 GMT
I just had a nice idea for how to make my current application prettier.
Instead of stopping what I was doing (an item on the critical path, not ‘fluff’) and doing it, I added it as an unimplemented expectation in the appropriate place in the RSPEC files.
Which brings up a nice idea, I am going to capture the user requirements from my next meeting with the client in RSPEC.
Hmmmm, is this a spec too far?
Posted in Coding | Tags bdd, rails, rspec, tdd | no comments
