Rails - ActiveRecord
ActiveRecord is a database mapping framework that makes a bunch of assumptions about how the Database should be built and then lets you connect that up to a database in the quickest most direct way imaginable while still allowing you to drive your application from a Domain Modeling perspective. (is that sentence too long?)
- Convention over Configuration - Rails uses [XP-practice]coding standards [/XP-practice] to help speed development efforts. For instance if you name database fields according to the standard, the framework will give you extra functionallity. Or you can ignore the standard, and write more code yourself.
- Macros provide a Modeling language. ActiveRecord provides many macros to help with validations and association mapping. like: has_many, belongs_to, validates_uniqness. These really help make the Domain model expressive of your intentions. And they speak a language that clearer than other kind of mapping.
- The challange is to extend these tools to develop Domain language for your application problem space
- Simple Design verse Too Many Pieces. Afterwards we talked about the various pieces if J2EE architecture that we all use to deliver applications. So many issues occur because of the many frameworks and servers that need to fit together to deliver value. Are these peices really part of the solution, or have vendors just been selling us all stuff we don't really, actually need?
- Developing Domain Language, what if we could extend the modeling macros in ActiveRecord to help us develop our own domain specific macros? This would allow domain level rules to be expressed more directly. At this point it's just a question.
- Projects - Let one thousand flowers bloom. In the past we built a single project for xp-cincinnati. We all worked on the same code base. However, this time around we would like to code more between the meetings, too. So we talked about not one, but many projects that we could work on in smaller, non-exclusive groups. The meetings would be a forum to share our work, and brag about our accomplishments, and of course to hang-out afterwards.
---------------------------------------------------
Thanks to all who attended the April meeting, it was great. We had 4 or 5 new people attending this meeting. They said they were attending to hear more about:
- Design-Patterns - and this month we talked about the ActiveRecord pattern as implemented in Rails
- New Stuff - well that sure was new wasn't it?
- Rails - did it too
- XP - the project we reviewed was an XP tracker written in Rails.
Some of the topics we ended up talking about
- Planning and Justifing Big refactorings - Some big refactorings may need to be scheduled. (Think about replacing frameworks). It's hard to explain to the Customer so how do you get it on the schedule. The perfered approach is to try to do the refactoring incrementally. perhaps over a number of iterations or releases. Otherwise, you need to get a good level of trust with the customer to the point where they are willing to accept that most of the Velocity budget will be spent on a refactoring. Big refactorings require some combination of trust and justification and incremental changes.
- Tracking vs. Fixing defects is bug tracking good or counter-productive? Tracking defects is itself work. And work that does not move the product forward. It's best to either fix the code, or reject the defect report as not meaningful. As Yodda told Luke: "Do or Don't Do". Alex and Ed pointed out that some defects don't fit that model, and I wish I had written down Ed's exact formulation of which types of defects that was. When he tells me again I'll update this part of the post.
