Compose and manage domain logic and data persistence separately and intelligently, Datamappify is loosely based on the Repository Pattern and Entity Aggregation.

Datamappify is built using Virtus and existing ORMs (ActiveRecord and Sequel, etc). The design goal is to utilise the powerfulness of existing ORMs as well as to separate domain logic (model behaviour) from data persistence.

Attributes lazy loading has just been implemented, check it out: https://github.com/fredwu/datamappify

Right now there's providers for ActiveRecord and Sequel. But imagine having support for Redis and even remote web services in the future. Domain logic just got a lot tidier. :)

Please check it out: https://github.com/fredwu/datamappify

This is still an experimental project, I'd love to hear your thoughts!

Over the past few days I've started experimenting with the idea of implementing the repository pattern on top of ActiveRecord (yes, it sounds scary). The motivation came after we were about to kick start a relatively large scale system. It would be great to retain the powerfulness of ActiveRecord as well as making our app easier to maintain and test. It is basically a compromise, a stop gap, if you will.

I've always liked the Datamapper library but unfortunately ever since the Merb/Rails merge it has stepped outside of the spotlight. Datamapper 2 is shaping up nicely but it is still a far way away. So I decided to base my experimentation on top of utilising both ActiveRecord and Virtus, the attributes component of Datamapper 2.

You can check out what I've been doing here: https://github.com/fredwu/datamappify

It is an experiment, and it's still too early to see how useful and practical it'll become, but I'd love to get some feedback from you guys!

A week ago I went to Shanghai, China to attend and to give a talk at RubyConf China. The day before the conference’s first day a bunch of us were invited to a VIP dinner where we met with Matz and got to play with a device running MRuby. And I heard that earlier on that day Matz was ‘adopted’ by a book publisher to do an interview.

I have found the interview (in Chinese), and found it to be really useful. So I translated it to English. Hope more people will like it. :)

I wrote this as a small practice for some ruby meta-programming fun: Ruby Decorators. The implementation is imo a little simpler than some other similar ruby decorator projects.

API Taster is useful for visually testing your Rails application's API. Version 0.5.0 has just landed with support for describing and adding metadata to API endpoints. Adding metadata is useful for say, adding response expectations so that your test suite could tap into them. :)

API Taster - A quick and easy way to visually test out your application's API.

There are already many awesome API clients (such as Postman), so why reinvent the wheel? API Taster compared to alternatives, have the following advantages:

- API endpoints are automatically generated from your Rails routes definition
- Defining post params is as easy as defining routes
- Post params can be shared with your test factories

Bustle - Activities recording and retrieving using a simple Pub/Sub architecture. The advantages:

- It is lightweight and simple to use
- It is largely self-contained and separated from you core app logic
- It works nicely with ActiveRecord out of box
- It is ORM-agnostic therefore can be extended to use with other databases
- It has full unit test coverage

Here's the repo (please read the project readme): https://github.com/fredwu/angel_nest

You are welcome to tear it apart and do whatever you want with it. :) This is probably the last time I'm going to be sucked into building something for nothing. Oh well. At least it was fun to test-drive rails 3.1. ;) Somebody buy me a beer!!!!!1 :P

Ssync was born to solve one problem - to backup/sync to Amazon S3 efficiently without too much compromises and complexity. Give it a try and see if it works out for you. :) Check out the source code here.

ActiveRecord is without doubt the de facto ORM library for Rails and many Ruby web frameworks. Many developers however, do not like database migrations and prefer to use DSL for data mapping. Datamappify is created with the sole purpose of getting rid of the DB migration headaches.

Check out the source code on Github.

Sometimes just DRY the controllers is not enough, a lot of the resources often share the same views, wouldn’t it be nice to have view files DRY’ed too? You can! Inherited Resources Views is an extremely easy to use plugin to DRY the views associated with your inherited resources controllers. It is library-agnostic (it only depends on Inherited Resources) and it supports generating both erb and haml templates. Source code available at: http://github.com/fredwu/inherited_resources_views