Ruby Metaprogamming Getting Started Links

1. Ruby Quiz
2. Learning Ruby Horizontally
3. Ola Bini's blog post
4. OSCON05
5. Seeing Meta Classes Clearly
6. Poignant Guide
7. Jamis Buck's blog post

Restful Rails Development Book

Excellent book on RESTful Rails Development.
It has very good explanation of the RESTful Rails concepts. It's free. Check it out.

Ruby Blocks Screencast Part 1

This screencast covers the basics of blocks in Ruby. It gradually builds on simple example and introduces the complicated concepts in a simple way. Duration : 17 mins. Dowload it here .

Domain Driven Design Quickly - Book Review

"According to Eric Evans, a domain model is not a particular diagram; it is the idea that the diagram is intended to convey. It is not just the knowledge in a domain expert's head; it is a rigorously organized  and selective abstraction of that knowledge. A diagram can represent and communicate a model, as can carefully written code, as can an English sentence."

A good domain model focuses only on the relevant details and ignores  the rest. There are several ways to communicate the model. The book explains some of the techniques covered by the book Domain Driven Design by Eric Evans.

They are :

1.  Ubiquitous Language


2.  Layered Architecture


3.  Value Objects


4.  Entity Objects


5.  Aggregates


6.  Services


7.  Factories


8.  Repositories

I am not going to explain them all here. You can download a
free copy of the book from info site. I will briefly go over some of them in the context of Rails
projects.

Ubiquitous Language

 We need to find those key concepts which define the domain and the design, and find corresponding words for them, and start using them. Some of them are easily spotted, but some are harder.

Aggregates

In the Code Review session by Marcel Molina and Jamis Buck Aggregates, they show an example where Aggregates is put into practice. They call the Aggregate as the Super Model.

I worked on a Rails project where the User model become bloated with attributes that could be extracted into its own model. For instance, address, contact info, billing info etc. So the User model is
an Aggregate.

Repositories

A good example would be ActiveRecord's find method, given an id it finds the record and returns an object that represents a row in the database.

Development Process and Domain Driven Design

"The Agile methods have their own problems and limitations; they advocate simplicity, but everybody has their own view of what that means. Also, continuous refactoring done by developers without solid design principles will produce code that is hard to understand or change."

I have experienced this on a project where the team was doing TDD and due to simplistic design the code was brittle. The team did not spend much time on design. It seemed like we were going back to
square one once every couple of weeks. The overall productivity of the team went down.

It talks about implicit concept, constraint, process and specification. It provides practical tips on how to refine and improve the initial domain model. I really liked this section of the
book.

Creating the Model

UML can lead to diagrams that are cluttered and hard to maintain. Creating a UML diagram to represent the whole system can result in a huge domain model.

The alternatives are :

1. Create a set of small diagrams with text that explains some aspect of the system which cannot be represented by the diagram. The diagrams can be hand drawn. In the initial stages the domain model
changes a lot, so this is a practical approach.

2. Communicate using code. This is the XP approach. Use well written code as the communication tool. In this case you don't have the problem of documents getting out of sync with the requirement
changes.

The book talks about the Analysis Model and the Design Model and how there is gap between these two models. The developers have to deal with the implementation issues that cannot be foreseen by the analysts.

Bounded Context

I learned this from Rails core team member Marcel Molina during the Advanced Rails studio. At that time I did not know it was explained in the Domain Driven Design book. The idea here is to create a
very cohesive model that is as small as possible.

If required, you can split your application into several applications that have its own domain model. For instance if you have a web application that is about outdoor adventure club management, you can split the billing system into a separate application. This allows the billing system to be used with any system.

I agree with other bloggers regarding the way the Rails team integrates those apps using ActiveResource. It is not a good solution. The ideal way to integrate them would be to use some kind of asynchronous messaging system. This could be as simple as a cron job.

Preserving Model Integrity

This chapter talks about large projects that consist of multiple teams. It describes how to go about applying domain driven design practices.

Conclusion

Domain driven design is not something new, it has been around for couple of decades or so. Eric Evans has documented them very well in his book. It is a must read for any developer regardless of whether you are part of a small or a big team.

In the last chapter where Eric Evans is interviewed he mentions the pitfalls of domain modeling:

1.  Stay hands-on. Modelers need to code.


2.  Focus on concrete scenarios. Abstract thinking has to be anchored in concrete cases.


3.  Don't try to apply DDD to everything.

I remember an interview couple of years ago where the company that interviewed me was very interested in hiring me as a modeler. I never felt comfortable in just being a modeler without getting my hands dirty by writing some code. I am glad that I did not accept the offer, since they never allow a modeler to code.

Living on the Edge

1. rake rails:freeze:edge
2. rake rails:update

script/about output should show value for Edge Rails Version.

xml-simple gem was giving errors when script/about was run. It is used by aws-s3 gem. Uninstalled it for now.

Domain Driven Design

I attended the one day QCon Tutorial on Domain Driven Design by Eric
Evans. It was jam packed with real-world tips on dealing with software
complexity.

Introduction

In 1990's we were aiming for reuse, productivity and flexibility by
using object oriented systems. Here we are in 2007 and we still find
it elusive to achieve these in projects.

Eric said that his book was the result of analyzing several successful
projects and identifying the common elements in them. Those elements
do not guarantee success. There will be failures. The critical
complexity of most software projects is in understanding the domain
itself.

Experimentation - Fail Cheaply

Learn to brainstorm. It is cheap to fail at this stage. Go beyond the
first idea. Suggest two mutually exclusive ideas. This is a technique
to break out of the box. It allows us to explore the system beyond its
boundary.

So, look broader. Once we get a big picture we can zoom into the
smaller system that we are considering and come up with a better
solutions. The first idea can be a simple one.

Another way to fail cheaply is to prototype. Remember that is a throw
away so that the developer is free to make mistakes and does not have
to worry about doing it "The Right Way".

Terminology

Domain

The subject area to which the user applies a program is the "domain"
of the software.

Model

A model is a system of abstractions that describes selected aspects of
a domain and can be used to solve problems related to that domain. It
serves a particular use. It is NOT as realistic as possible. He gave
an interesting example of this: NASA uses Newton's principles, not
Einstein's even though it is a known fact that Einstein model is more
accurate. So it is useful relative to specific domain scenarios.

Ubiquitous Language

A language structured around the domain model and used by all team
members to connect all the activities of the team with the software.

Context

The setting in which a word or statement appears that determines its
meaning.,

Dealing with Clients and Resolving Impediments to Software Delivery

Core Vs Generic

Have you ever had the experience where you sit with a client and you
come up with a huge list of features for the software you are going to
develop? The client knows how to prioritize but do they know what is
essential in the domain that will satisfy their mission statement or
unique selling proposition?

Ask them:

1. What distinguishes your business from others?
2. What is your mission statement?

Use the answer as the criteria to find the core domain of the system
from the laundry list of features.

Generic things would be something that we could re-use and purchase
from a third-party. It could be used by your competition too, but the
core domain separates you from the rest. It gives you some kind of
competitive edge over your competitors.

Conclusion:

This is a must attend tutorial. I felt 3 days would have been ideal.
There is still lot to learn about domain driven design from the book.

Using RJS with Rails 2.0 Preview Release

1. Change the extension from rjs to .js.rjs
2. You must use the respond_to block (format.js will call the corresponding .js.rjs file)
3. Use link_to_remote or other remote calls to make the AJAX call.