The long wait is over. Ronin 0.3.0, code-named “big-push”, has finally been released.

DataMapper 0.10.0

Ronin was probably one of the first big Ruby apps to upgrade to DataMapper 0.10.0. As a result of this, we had to postpone the release of Ronin 0.3.0, until DataMapper 0.10.0 had finished it’s rigorous two month Q/A cycle.

Once DataMapper 0.10.0 had been released, the two months of Q/A and almost a complete rewrite of the code-base really showed itself. I think @dkubb, @dbussink, @snusnu, @xshay, @myabc, @rsim, @namelessjon, @knowtheory and everyone else who helped with 0.10.0 deserves applause for their hard work and dedication.

YARD

As of 0.3.0, Ronin has successfully moved to YARD based documentation. The new Ronin API docs can be found in the usual location. YARD really helped improve the detail of the Ronin API docs, allowing developers to specify method arguments, accepted object-types, yield arguments, possible exceptions and return-types.

Additionally, YARD handlers were added to Ronin that parsed and regenerated documentation for DataMapper properties/relations. These additional YARD handlers helped improve documentation coverage for Ronin models, such as Ronin::Arch or Ronin::Exploits::Exploit.

Ronin::UI::CommandLine

Ronin::UI::CommandLine was almost entirely refactored in 0.3.0. Ronin::UI::CommandLine::Command was rewritten to use Thor. Switching to Thor greatly simplified the ronin commands, making it easier to write new commands. A good example of this, is the source-code for the install command from before and after 0.3.0.

Another benefit to using Thor, albeit cosmetic, was being able to use Thor’s ANSI color-output. Normal output will now appear in green, warnings in yellow and error messages in red.

New convenience methods were also added to Ronin::UI::CommandLine::Command to help format and print various data: indent, print_title, print_array and print_hash.

Ronin::UI::Output

As of 0.3.0, Ronin::UI::Diagnostics and Ronin::UI::Verbose were replaced with the brand new Ronin::UI::Output module. Ronin::UI::Output is designed to delegate how output is handled. By default all output is sent to Ronin::UI::Output::Handler, which prints the output to the terminal. One can override the default output handler by using Ronin::UI::Output.handler=, to specify the new handler module; which must define print_info, print_debug, print_warning and print_error methods.

Ronin::UI::Output also provides the Helpers module, which can be included into any class and adds the print_info, print_debug, print_warning and print_error methods.

New Convenience Methods

New TCP and UDP networking methods were added to 0.3.0. Now one can easily create TCP/UDP servers using, Net.tcp_server, Net.tcp_server_session, Net.tcp_single_server, Net.udp_server and Net.udp_server_session.

Ronin::Network::HTTP::Proxy was also added to 0.3.0. The Ronin::Network::HTTP::Proxy helps parse and represent HTTP proxy addresses, and is now used by Ronin::Network::HTTP.proxy and all :proxy options.

proxy = Network::HTTP::Proxy.parse('148.233.239.24:80')
# => #<Ronin::Network::HTTP::Proxy: 148.233.239.24:80>

The Proxy class can also be used to test a proxy.

proxy.valid?
# => true
proxy.lag
# => 0.003881

Ronin::Platform

The overlay.xsl file got a make-over in 0.3.0. overlay.xsl is a XML StyleSheet, which helps render ronin.xml files from Overlays into proper XHTML when they are viewed in a web-browser. Now ronin.xml files should appear more like a standard "About" web-page.

Reloading Overlays/Extensions while ronin is running became possible with the addition of Ronin::Platform.reload!. Now if an Extension is modified, one can simply call Platform.reload! and get the updated version.

Ronin Extensions gained convenience methods for defining reader/writer methods to instance variables: attr_reader, attr_writer and attr_accessor. They can be used in Ronin Extensions, just as one would use them in a class.

ronin_extension do

  attr_accessor :var
  attr_reader :result

  setup do
    @var = 5
    @result = nil
  end
  ...
end

Ronin Extensions also gained their own on-demand temp directory. When Ronin::Platform::Extension#tmp_dir is called, a temp directory specifically for the extension will be created within ~/.ronin/tmp/, and the path of the new temp directory will be returned.

Upgrading

As always, the rubygem files for Ronin 0.3.0 are available on rubyforge.org. One can update Ronin using rubygems by simplying running:

$ gem update ronin

Likewise, one can also install Ronin using rubygems:

$ gem install ronin

Also, as of Ronin 0.3.0 all releases of Ronin will also be made available on gemcutter.org.

Outro dia, tive um problema chatíssimo com o ActiveRecord: eu precisava criar um código de autenticidade, que conteria várias matrículas, que conteria várias disciplinas. O problema é o seguinte: Essas matrículas só seriam válidas se, por exemplo, o total de créditos das disciplinas não ultrapassassem um determinado número. Logo, resolvi fazer a validação no modelo de autenticidade, da seguinte forma:

class Autenticidade < ActiveRecord::Base
  MAX_CREDITOS = 40
  has_many :matriculas
  has_many :disciplinas, :through => :matriculas
  validate :credito_alto?

  def credito_alto?
    total = disciplinas.inject(0) { |r, v| r += v.creditos }
    errors.add(:disciplinas, 'créditos acima do permitido') if total > MAX_CREDITOS
  end
end

class Matricula < ActiveRecord::Base
  belongs_to :disciplina
  belongs_to :autenticidade
end

class Disciplina < ActiveRecord::Base
end

Ok, o problema agora é o seguinte: Se eu crio uma autenticidade, com o parâmetro :disciplina_ids => [1, 2], por exemplo, e a autenticidade não é válida, nenhuma nova matrícula é criada – como deveria ser. Agora, se eu atualizo uma autenticidade, com o  autenticidade.update_attributes( :disciplina_ids => [1, 2]), e essa autenticidade não é válida, o ActiveRecord salva as matrículas. Nesse caso, eu tenho uma inconsistência na base de dados feia – e precisava encontrar uma alternativa que não envolvesse muitos hacks, coisa que ainda não encontrei. Mas isso me estimulou a pesquisar o DataMapper.

O DataMapper é um ORM assim como o ActiveRecord – porém com um diferencial que (para alguns) é interessante: Ele só lança os comandos SQL quando você precisa. Nossa autenticidade (fora as validações) ficaria assim:

class Autenticidade
  include DataMapper::Resource

  MAX_CREDITOS = 40
  property :id, Serial
  property :codigo_autenticidade, String
  has n, :matriculas
  has n, :disciplinas, :through => :matriculas
end

Para alguns, é uma vantagem declarar as propriedades no próprio código – dizem que é mais simples de ver o que há nas suas tabelas. Eu, discordo categoricamente disso – o código-fonte não deveria fazer o que a documentação faz (se você não tem um dicionário de dados, é culpa sua, não do ActiveRecord). Mas uma coisa legal é: Se vc fizer, por exemplo: a = Autenticidade.all[0], o DataMapper gera apenas o SQL que você precisaria (nesse caso, SELECT * FROM autenticidades LIMIT 1). Isso funciona, de acordo com a documenação do DataMapper, inclusive para relações:

autenticidades = Autenticidade.all #Não gera nenhum SQL ainda
autenticidades.each do |autenticidade| #Gera um SELECT * FROM autenticidades
  p autenticidade.matriculas #Gera um SELECT para listar TODAS as matrículas de TODAS as autenticidades, apenas na primeira iteração
end

Ok, isso elimina o tal do problema n+1 (No ActiveRecord, isso geraria um SELECT para cada autenticidade). O problema é: isso funciona muito bem, mas no has n, :through, o problema do n+1 existe! E, para piorar, um Autenticidade.all :include => :disciplinas simplesmente não existe, logo eu não tenho como sair desse erro. No fim, a vantagem virou uma desvantagem.

Outra vantagem que eu tinha visto era a possibilidade de criar adaptadores para coisas que não são bases de dados relacionais – imagine, por exemplo, você usando o DataMapper como um ORM para LDAP, MySQL, REST e YAML, tudo ao mesmo tempo – fazer associações com isso seria uma maravilha, falar que seu usuário do MySQL tem uma entrada LDAP, usando as associações do próprio DataMapper. Porém, mais uma vez, as coisas não funcionaram muito bem: has n só funciona quando as bases de dados estão no mesmo adaptador, talvez para otimizar os SQLs com JOINs, etc. Logo, mais uma vantagem que eu vi foi sub-utilizada.

No fim, a única vantagem que o DataMapper me deu foi a possibilidade de fazer isso aqui:

autenticidade = Autenticidade.first
autenticidade.disciplinas << Disciplina.get(:id => 1)
autenticidade.disciplinas << Disciplina.get(:id => 2)
autenticidade.save #Se for falso, NÃO salva as disciplinas

Pois é, eu gostaria mais de ver as vantagens do DataMapper no ActiveRecord do que o inverso…

What is DataMapper?

DataMapper is Ruby Object/Relational Mapper that is similar to ActiveRecord (component of Ruby on Rails) but still it handles several things differently than ActiveRecord.

I got interested in DataMapper because I liked better some of its design decisions when compared with ActiveRecord. And in particular DataMapper architecture can suite better if you need to work with legacy Oracle database schemas – that is the area where I use Ruby on Rails a lot and for these purposes I also created Oracle enhanced adapter for ActiveRecord.

But as there were no Oracle adapter available for DataMapper I needed to create one I started to work on Oracle adapter for DataMapper after the RailsConf and now it is passing all DataMapper tests on all Ruby platforms – MRI 1.8, Ruby 1.9 and JRuby 1.3.

Why DataMapper for Oracle database?

If you would like to learn main differences between DataMapper and ActiveRecord then please start with this overview and this summary of benefits.

Here I will mention specific benefits if you would like to use DataMapper with Oracle database.

Model properties

In DataMapper you always specify in model class definition what Ruby “type” you would like to use for each model attribute (or property as called in DataMapper):

class Post
  include DataMapper::Resource
  property :id,         Serial
  property :title,      String
  property :post_date,  Date
  property :created_at, DateTime
  property :updated_at, Time
end

The main benefit for that is that you can explicitly define when to use Ruby Time, Date or DateTime class which is stored as DATE (or sometimes as TIMESTAMP) in Oracle database. In addition you can define your own custom DataMapper types and define how to serialize them into database.

Composite primary keys

DataMapper core library supports composite primary keys for models. If you use ActiveRecord then there is an option to use additional composite_primary_keys gem but it regularly breaks with latest ActiveRecord versions and quite often it also might break in some edge cases. In DataMapper composite primary keys are defined quite simple:

class City
  include DataMapper::Resource
  property :country,   String, :key => true
  property :name,      String, :key => true
end

Legacy schemas

DataMapper is quite useful when you want to put Ruby models on top of existing Oracle schemas. It is possible to provide different database field name for property or provide custom sequence name for primary keys:

class Post
  include DataMapper::Resource
  property :id, Serial, :field => "post_id", :sequence => "post_s"
end

You can also define one model that can be persisted in two different repositories (e.g. databases or schemas) and use different naming conventions in each repository:

class Post
  include DataMapper::Resource
  repository(:old) do
    property :id, Serial, :field => "post_id", :sequence => "post_s"
  end
  repository(:default) do
    property :id, Serial
  end
end

As a result DataMapper can be used also for data migration between different databases.

Bind variables

ActiveRecord always generates SQL statements for execution as one single string. Therefore Oracle enhanced adapter always initializes Oracle session with setting cursor_sharing=’similar’. It instructs Oracle always to take all literals (constants) from SQL statement and replace them with bind variables. It reduces the number of unique SQL statements generated but also it is some overhead for Oracle optimizer.

DataMapper always passes all statement parameters separately to corresponding database adapter and therefore it is possible for Oracle adapter to pass all parameters as bind variables to Oracle.

CLOB and BLOB values inserting and selecting

As for ActiveRecord all inserted values should be passed as literals in INSERT statement it was not possible to insert large CLOB and BLOB values directly in INSERT statement. Therefore ActiveRecord Oracle enhanced adapter did separate call-backs for inserting any CLOB or BLOB data after INSERT of other data. In DataMapper it is possible to insert all data at once as CLOB and BLOB data are passed as bind variables.

DataMapper also handles better lazy loading of large columns. So if you define property as Text then by default it will not be selected from database – it will be selected separately only when you use it. Typically it could reduce amount of data that needs to be sent from database to application as Text properties are quite often not needed in e.g. all web pages.

Wny not DataMapper?

If you are fine with ActiveRecord default conventions and you don’t have any issues that I listed previously then probably ActiveRecord is good enough for you and you shouldn’t change to DataMapper. There are of course much more Rails plugins that work with ActiveRecord but not yet with DataMapper. And DataMapper is still much less used and therefore there might some edge cases where it is not tested and you will need to find the issue causes by yourself.

But if you like to try new things then please try it out – and also DataMapper community is quite friendly and helpful and will help to solve any issues

Installation of DataMapper Oracle adapter

So if you have decided to try to use DataMapper with Oracle database then follow the instructions how to install it.

Oracle support is done for current development version 0.10.0 of DataMapper – therefore you will need to install the latest versions from GitHub (they are still not published as gems on RubyForge).

DataMapper with Oracle adapter can be used both on MRI 1.8.6 (I am not testing it on 1.8.7) and Ruby 1.9.1 as well as on JRuby 1.3. And currently installation is tested on Mac OS X and Linux – if there is anyone interested in Windows support then please let me know.

MRI 1.8.6 or Ruby 1.9.1

At first you need to have the same preconditions as for ActiveRecord:

• Oracle Instant Cient
• ruby-oci8 gem, version 2.0.2 or later

If you are using Mac then you can use these instructions for installation (but instead of compiling ruby-oci8 library just install ruby-oci8 gem).

Now at first it is necessary to install DataObjects Oracle driver – DataObjects library is unified interface to relational databases (like SQLite, MySQL, PostgreSQL, Oracle) that DataMapper uses to access these databases.

At first validate that you have the latest version of rubygems installed and install necessary additional gems:

gem update --system
gem install addressable -v 2.0

As I mentioned currently you need to install the latest version from GitHub (at first create and go to directory where you would like to store DataMapper sources):

git clone git://github.com/datamapper/extlib.git
cd extlib
git checkout -b next --track origin/next
rake install
cd ..

git clone git://github.com/datamapper/do.git
cd do
git checkout -b next --track origin/next
cd data_objects
rake install
cd ../do_oracle
rake compile
rake install
cd ../..

Now if DataObjects installation was successful you can install DataMapper. UPDATE: Oracle adapter is now in “next” branch of DataMapper so now you need to install it form there:

git clone git://github.com/datamapper/dm-core.git
cd dm-core
git checkout -b next --track origin/next
rake install

Now start irb and test if you can connect to Oracle database (change database name, username and password according to your setup):

require "rubygems"
require "dm-core"
DataMapper.setup :default, "oracle://hr:hr@xe"

and try some basic DataMapper operations (I assume that you don’t have posts table in this schema):

class Post
  include DataMapper::Resource
  property :id,     Serial, :sequence => "posts_seq"
  property :title,  String
end
DataMapper.auto_migrate!
p = Post.create(:title=>"Title")
Post.get(p.id)
Post.auto_migrate_down!

JRuby

At first I assume that you have already installed JRuby latest version (1.3.1 at the moment).

Then you need to place Oracle JDBC driver ojdbc14.jar file in JRUBY_HOME/lib directory (other option is just to put somewhere in PATH).

All other installation should be done in the same way – just use “jruby -S gem” instead of “gem” and “jruby -S rake” instead of “rake” and it should install necessary gems for JRuby.

In addition before installing do_oracle gem you need to install do_jdbc gem (which contains general JDBC driver functionality):

# after installation of data_objects gem
cd ../do_jdbc
jruby -S rake compile
jruby -S rake install
# continue with do_oracle installation

Other DataMapper gems

DataMapper is much more componentized than ActiveRecord. Here I described how to install just the main dm-core gem. You can see the list of other gems in DataMapper web site.

To install additional DataMapper gems you need to

git clone git://github.com/datamapper/dm-more.git
cd dm-more
git checkout -b next --track origin/next
cd dm-some-other-gem
rake install

Questions?

This was my first attempt to describe how to start to use DataMapper with Oracle. If you have any questions or something is not working for you then please write comments and I will try to answer and fix any issues in these instructions.

Introduction

We all know that in Domain-Driven Design it is good to express our domain with simplicity and “pureness” and for that we usually go for a POxO (Plain Old {fill_with_your_preffered_language} Object) approach. The problem is that the ORM solutions I’ve found for Ruby make us either inherit from some base class or do the mappings directly into our classes. By no means am I saying that they aren’t good, but we are talking about DDD and the idea of having a pure domain layer without distractions is something we should embrace.

My first thought was to write about a full blown example, comparing side by side a common C# / Java implementations to my Ruby implementation but then I realized it would probably have some unnecessary and “boring” information. It’s better to focus on writing about my approach and have some comments here and there to explain how things would be done in other platforms. What I’m going to show here is something that is really common in other languages but not in Ruby I believe, all classes from my domain will be implemented as POROs – Plain Old Ruby Objects, totaly decoupled from any tool that we might use.

There was a talk by Eric Evans called “What I’ve learned about DDD since the book” that has been commented out here and here (slides here). Even though the building blocks of Model-Driven Design mentioned in the book (and the other one mentioned on the talk) are not essential, they are important and will be the subject of this series.

So, to illustrate my ideas I’ll use the common Customer/Order/Product for my examples with some requirements from Jimmy Nilsson – Applying Domain-Driven Design and Patterns:

• List the orders when looking at a specific customer
• Orders have an acceptance status that is changed by the user
• The total value of an order must be lower or equal than one million US$
• A Customer has a credit limit and cannot owe us more than a specified amount of money

Part I – Customer and Products

If you are not familiar with DDD and its building blocks I suggest that have a look at this glossary of DDD terms.

This is our really simple model for this part:

Entities

There’s no big deal here so I’ll just provide some code:

class Customer
  attr_reader :id
  attr_accessor :name
  attr_accessor :credit_limit

  def initialize(name, credit_limit)
    @name = name
    @credit_limit = credit_limit
  end
end

class Product
  attr_reader :id
  attr_accessor :price
  attr_accessor :description

  def initialize(price, description)
    @price = price
    @description = description
  end
end

Repositories

Statically typed languages like Java and C# would have an interface in order to decouple our domain from infrastructure but Ruby doesn’t have interfaces. But still… I believe that we need some kind of contract for the repositories and instead of having a class with empty methods I’ll create in-memory repositories as the pattern definition:

class CustomerRepository
  def self.store(customer)
    customer.instance_variable_set(:@id, next_id) if customer.id.nil?
    customers[customer.id] = customer
  end
  def self.find(id)
    customers[id]
  end
  def self.all
    customers.values
  end
  def self.delete(customer)
    customers.delete(customer.id)
  end  

  private  

  def self.customers
    if !defined?(@@customers)
      @@customers = {}
    else
      @@customers
    end
  end
  def self.next_id
    if !defined?(@@next_id)
      @@next_id = 1
    else
      @@next_id += 1
    end
  end
end

class ProductRepository
  # ... similar code ...
end

Maybe this code could be factored out somewhere but let’s just leave as it is for now.

Right now you might be thinking “This guy is crazy, static methods are evil!!”. Well, I think that it’s not true when it comes to Ruby class methods. Just below I will show you how we can easily add persistence to our domain.

Even if we want to set up a IoC container I don’t think it would be a problem since Ruby classes are objects as well. For example these repositories could be easily injected into a Rails controller instance variable.

Adding persistence

If we use (N)Hibernate, we would probably have the mappings file into a different package / assembly, but in Ruby I think it would be enough to just have persistence related code in another file that redefines the classes.

Mappings

class Customer
  include Clipper::Model

  orm.map(self, "customers") do |customers|
    customers.key(customers.field("id", Clipper::Types::Serial))
    customers.field("name", Clipper::Types::String.new(200))
    customers.field("credit_limit", Clipper::Types::Float(8, 2))
  end
end

class Product
  include Clipper::Model

  orm.map(self, "products") do |products|
    products.key(products.field("id", Clipper::Types::Serial))
    products.field("description", Clipper::Types::String.new(200))
    products.field("price", Clipper::Types::Float(8, 2))
  end
end

Repositories

module ClipperRepository
  def self.included(klass)
    klass.instance_eval do
      include Singleton
      include Clipper::Session::Helper

      def self.orm
        instance.orm
      end
    end
  end
end

class CustomerRepository
  include ClipperRepository

  def self.store(customer)
    orm.save(customer)
  end
  def self.delete(customer)
    orm.delete(customer)
  end
  def self.find(id)
    orm.get(Customer, id)
  end
  def self.all
    orm.all(Customer)
  end
end

class ProductRepository
  # ... similar code  ...
end

Here I’ve used Clipper but for these examples we could probably rewrite it to use DataMapper as well. Unfortunately, with this approach both DataMapper and Clipper will redefine our already defined accessors and that would be a problem if we have some business logic there. For this example this wouldn’t be a problem but I’ve checked with one of Clipper developers and they are willing to have this feature implemented in the library, I’ll have to check if DataMapper folks have something like this in mind as well. I’ve already hacked Clipper in order to have something like Hibernate property access config that defines the strategy for accessing the property value but it still lacks the feature for associations.

Testing

With this approach I believe testing becomes more simple. I’ve created tests for the pure domain and just by including a different file I can test everything hooked up with infrastructure without rewriting the tests. To make things easier, I created two Rake tasks for testing: ‘rake test:domain’ and ‘rake test:infrastructure’. I think they look a bit ugly at the moment but here we go:

namespace :test do
  task :enviroment_domain do |t|
    ENV['DDD_EXAMPLE_HELPER'] = Pathname(__FILE__).dirname + 'tests' + 'domain_helper'
  end

  task :enviroment_infrastructure do |t|
    ENV['DDD_EXAMPLE_HELPER'] = Pathname(__FILE__).dirname + 'tests' + 'infrastructure_helper'
  end

  Rake::TestTask.new(:domain => :enviroment_domain) do |t|
    t.libs << "tests"
    t.test_files = FileList["tests/domain/**/*_test.rb"]
    t.verbose = true
  end

  Rake::TestTask.new(:infrastructure => :enviroment_infrastructure) do |t|
    t.libs << "tests"
    t.test_files = FileList["tests/domain/**/*_test.rb"] + FileList["tests/infrastructure/**/*_test.rb"]
    t.verbose = true
  end
end

Test Case

require ENV['DDD_EXAMPLE_HELPER']

class CustomerRepositoryTest < Test::Unit::TestCase
  # ...
  def test_create
    customer = Customer.new('customer', 1500)
    CustomerRepository.store(customer)
    assert_not_nil(customer.id)
  end
  # ...
end

I believe this approach increases experimentation because we are free to work with our domain without worrying about persistence issues as if we were using Rails ActiveRecord. Rails AR need us to set up DB tables by running migrations in order to use the entities and have access to the properties.

Project Structure

Conclusion

This whole thing might seem weird if you are used to Rails AR, but the fact that we have our domain totaly decoupled from infrastructure issues is important because as technology changes and shifts, and as our domain layer is burdened with complex computer science problems, things will most certainly change.  Keeping the heart of the software decoupled from tools allows those changes to be easier (XP ?).

That’s it! I’d like to thank Michael Brennan and Guilherme Chapiewski for reviewing and contributing with ideas for this post and Sam Smoot for also reviewing and helping me out with Clipper.

Tout travail mérite le respect, la réflexion et le temps passé à concevoir et implémenter une solution ne peuvent être directement et gratuitement fustigés.

Il en va différemment lorsque les auteurs s’exposent eux-mêmes en lançant une information agressive et fausse (aka F.U.D) avec d’autres produits.

C’est ce qu’il s’est passé ici où l’on nous ressort un DataMapper basé sur des patterns anciens voire du millénaire passé comme commenté sur la page:

Honestly, the approach is old. I know that I’ve used similar approach going back to 1999 and it was old back then.

Reprenons depuis le début, le produit présenté n’a rien d’un ORM (Object Relationnal Mapping) dès lors qu’il impose d’énormes limitations au modèle objet, comme la non prise en charge de l’héritage et surtout qu’il ne propose pas de mapping… ben oui forcément. Ici il s’agit en fait d’imposer, via un framework, une organisation/une structuration du code dans des classes stéréotypées. L’idée est louable, toujours meilleures que d’avoir du JDBC pur non organisé et explosé partout dans un projet.

Cependant, c’est assez préhistorique et très franchement pénalisant sur beaucoup de points, lisons entre les lignes :

No lazy loading. Just eager loading because you can expect whatever you want during coding. Eager loading removes n + 1 queries.

Mouais, c’est un peu beaucoup n’importe quoi. Le lazy loading peut effectivement entraîner un soucis de n + 1 requêtes mais uniquement si le développeur est un lazy développeur (= développeur fainéant). Avec un ORM et hibernate en particulier, tout est fait pour pouvoir optimiser les modes de récupération de graphe d’objets. En passant “just eager loading” tend à forcer le chargement entier des graphes d’objets. Ceci est purement unitle et simplement consommateur de ressources. D’où l’existence d’une fonctionnalité comme le lazy loading qui permet de charger uniquement la portion de graphe nécessaire à un cas d’utilisation. Le lazy loading bouchonne le reste du graphe avec des proxies qui permettront eux-même le chargement transparent du reste du graphe en cas de nécessité, comprende? … la boucle est bouclée

an entity object which extends POJO

Comme le dirait un de mes bons amis:  “namuf ?” (= quoi?, kékidi? ou encore C’est une blague?). Pour faire court, simple et pour ceux qui n’ont pas tilté, un POJO est un objet pur, qui ne dépend d’aucun framework, encore moins technique. Un POJO est libre et peut être exploité par un client sans que l’on ait besoin de déployer une quelconque armada de jars de frameworks techniques au risque de se prendre une ClassNotFoundException.

Notre ami nous explique donc que les classes persistantes utilisées avec son framework doivent étendre une classe technique, présente dans son framework, classe qui se nomme très intelligemment POJO. C’est fantastique! Forcément et probablement sans même savoir pourquoi, il a du compléter son framework de convertisseurs:

built-in converter that can be used to convert a Java Object into a frontend String or a frontend String into a backend Java Object. The converter prevents data conversion from scattering different pages and layers.

Beh oui, les objets n’étant pas des POJOS, ils deviennent difficilement manipulables d’une couche à l’autre. Il faut passer par le bon vieux DTO, à savoir un POJO destiné essentiellement à des fins de manipulation de données. Et pour automatiser la transposition d’un “truc” (désolé ses trucs ne sont pas des POJOS pour moi) vers un DTO, que faut-il? Des convertisseurs, bravo. Il va forcément falloir gérer ces conversions de manière systématique, typiquement entre la couche service et la couche web.

Ces traitements sont coûteux en terme de développement et de maintenance, complètement inutile car ne contenant aucune plu value métier et forcément c’est vraiment contre productif. Mais non puisque notre ami nous affirme gratuitement:

High productivity compared to Hibernate.

Sans exagérer 70% de ce que dit l’auteur est faux et je vais arréter là, … euh, … aller une dernière pour la route, lisez attentivement le titre est les premiers mots du commentaire ici (écrit par l’auteur du framework lui-même. ):

No limitation

suivi de

There are no polymorphic queries

Comme c’est beau, il m’a convaincu!

Tout ceci ne veut pas dire que le framework est inutile ou mauvais, il ne répond simplement pas à un outil du spectre d’un ORM. En le aisant délibérement, l’auteur s’est tiré une balle dans le pied.

J’ai connu et connais encore plusieurs décideurs qui se laissent berner par ce type d’argumentation. Résultat: des applications qui utilisent des technos d’un autre millénaire (ce qui n’est pas grave) mais qui passent aussi à côté de technos pouvant résuire sensiblement les coûts de développement, de maintenance et d’évolution. Prenez une application de 50 tables avec 1000 requêtes SQL codées en dure, forcément pas le choix avec un DataMapper, il faut en coder une par cas d’utilisation. Ajoutez une colonne par ci par là lors d’une évolution, vous m’en direz des nouvelles…

Apprenez à lire entre les lignes et si vous êtes décideur sans être expert sur un sujet en particulier, déléguez à un de vos petits gars passionnés. Il vous fera gagner beaucoup d’argent à terme, croyez-moi. De même, méfiez-vous toujours des software marabous qui vous vendent une bidouille propriétaire  sortie du chapeau et qui vous certifie qu’elle est bien meilleure que les frameworks les plus robustes, matures et éprouvés.

Нашел интересную заметку у Roberto Saccon по поводу запуска Helma в GAE/J. Helma – это server-side фреймворк, написанный на Java. Языком для разработки выступает JavaScript, что делает этот фреймворк крайне интересным.

Мне кажется, GAE/J своим стартом дал дорогу многим интересным проектам, не только JRuby. Конечно все целиком зависит от задач, но Sinatra в GAE/J смотриться куда более органично, нежели Rails. А упор на BigTable должен поднять интерес к таким проектам как DataMapper. В ActiveRecord DataStore уже не влезет.

The most famous and widespread ruby ORM is undoubtly ActiveRecord, due to the fact that it comes in bundle with Ruby on Rails. But, has it often happens, that doesn’t mean it’s the best choice : DataMapper has a number of additional features (lazy loading, strategic eager loading – no need to check for possible select + 1 problems), implements the identity map pattern and it’s WAY faster than its counterpart.
First thing that you need to do is to install the related gem, so open up a command prompt, log in as root and type :

gem install data_mapper

After that you will be able to use the DataMapper module inside your Ruby application just with :

require 'rubygems'
require 'dm-core'

If you have an instance of MySql available you can connect to it using :

DataMapper.setup(:default, 'mysql://user:password@hostname/dbname')

For those of you who are acquainted to (N)Hibernate this is maybe the big point, as there’s no need to write mapping files (or attributes, or whatever). All that you need to leverage DataMapper is to include DataMapper::Resource in your class.

class Customer
include DataMapper::Resource

property :id, Integer, :serial => true
property :name, String
property :surname, String
has n, :bills
belongs_to :customergroup

end
Convention over configuration : unless you explicitly declare it, tables in the database take the plural declination of your business entity’s name (customer -> customers) and foreign key columns are in the format (parententityname)_id: in this case it will be customergroup_id.
DataMapper implements the active record pattern, so each entity is responsible for its own persistence

my_customer = Customer.new
...
my_customer.save

Data retrieval is done via class methods, like this:

my_customers = Customer.all
my_customers = Customer.get(4) #gets the customer with id = 4
my_customers = Customer.all(:name => "John", :surname => "Smith") # SELECT * FROM customers WHERE name = "John" AND surname = "Smith"

More on DataMapper’s site. A more detailed quickstart available here.

The most famous and widespread ruby ORM is undoubtly ActiveRecord, due to the fact that it comes in bundle with Ruby on Rails. But, has it often happens, that doesn’t mean it’s the best choice : DataMapper has a number of additional features (lazy loading, strategic eager loading – no need to check for possible select + 1 problems), implements the identity map pattern and it’s WAY faster than its counterpart.
First thing that you need to do is to install the related gem, so open up a command prompt, log in as root and type :

gem install data_mapper

After that you will be able to use the DataMapper module inside your Ruby application just with :

require 'rubygems'
require 'dm-core'

If you have an instance of MySql available you can connect to it using :

DataMapper.setup(:default, 'mysql://user:password@hostname/dbname')

For those of you who are acquainted to (N)Hibernate this is maybe the big point, as there’s no need to write mapping files (or attributes, or whatever). All that you need to leverage DataMapper is to include DataMapper::Resource in your class.

class Customer
include DataMapper::Resource

property :id, Integer, :serial => true
property :name, String
property :surname, String
has n, :bills
belongs_to :customergroup

end
Convention over configuration : unless you explicitly declare it, tables in the database take the plural declination of your business entity’s name (customer -> customers) and foreign key columns are in the format (parententityname)_id: in this case it will be customergroup_id.
DataMapper implements the active record pattern, so each entity is responsible for its own persistence

my_customer = Customer.new
...
my_customer.save

Data retrieval is done via class methods, like this:

my_customers = Customer.all
my_customers = Customer.get(4) #gets the customer with id = 4
my_customers = Customer.all(:name => "John", :surname => "Smith") # SELECT * FROM customers WHERE name = "John" AND surname = "Smith"

More on DataMapper’s site. A more detailed quickstart available here.

Check out the great book for beginner at: http://book.merbist.com/

Merb, DataMapper and RSpec are all open source projects that are great for building kick-ass web applications. They are all in active development and although it can be hard, we’ll try our best to keep up-to-date.

Merb

Merb is a relatively new web framework with an initial 0.0.1 release in October 2006. Ezra Zygmuntowicz is Merb’s creator, and continues to actively develop Merb along with a dedicated development team at Engine Yard and many other community contributors.

Merb has obvious roots and inspiration in the Ruby on Rails web framework. If you know Ruby and have used Rails you’re likely to get the hang of Merb quite easily.

While there are similarities, Merb is not Ruby on Rails. There are core differences in design and philosophy. In many areas that Rails chooses to be opinionated, Merb is agnostic – with respect to the ORM, the JavaScript library and template language. The Merb philosophy also disbelieves in having a monolithic framework. Instead, it consists of a number of modules distributed as Ruby gems. This means that it is possible to pick and choose the functionality you need, instead of cluttering up the framework with non-essential features.

The merb gem installs merb-core, a series of plugins as well as a default ORM (DataMapper); all you need in order to get started straight away. The benefit of this modularity is that the framework remains simple and focused with additional functionality provided by gems.

Thanks to Merb’s modularity, you are not locked into using any particular libraries. For example, Merb ships with plugins for several popular ORMs and provides support for both Test::Unit and RSpec.

merb-core alone provides a lightweight framework (a la camping) that can be used to create a simple web app such as an upload server or API provider where the functionality of an all-inclusive framework is not necessary.

DataMapper

DataMapper is an Object-Relational Mapper (ORM) written in Ruby by Sam Smoot. We’ll be using DataMapper with Merb. As previously mentioned, Merb does not require the use of DataMapper. You can just as easily use the same ORM as Rails (ActiveRecord) if you prefer.

We have chosen to use DataMapper because of it’s feature set and performance. One of the differences between it and ActiveRecord that I find useful is the way database attributes are handled. The schema, migrations and attributes are all defined in one place: your model. This means you no longer have to look around in your database or other files to see what is defined.

While DataMapper has similarities to ActiveRecord, we will be highlighting the differences as we go along.

RSpec

RSpec is a Behaviour Driven Development framework for Ruby. It consists of two main pieces, a Story framework for integration tests and a Spec framework for object tests. Both these components are implemented as Domain Specific Languages which help to make the stories and specs created more readable.

Merb currently supports the Test::Unit and RSpec testing frameworks. Both Merb and Datamapper use the RSpec testing frameworks and so we will be covering some aspects so that you may use it for your own applications.

What About Ruby On Rails?

[Merb is] Harder, Better, Faster, Stronger, to quote Daft Punk – Max Williams

So what’s the big deal? We have Ruby on Rails and that’s enough, isn’t it? There is little doubt that Ruby on Rails has rocked the web application development world. You have to give credit where credit’s due, and Ruby on Rails is definitely a great web framework. However, there is no such thing as a one-size fits all solution. Ruby on Rails is opinionated software which provides many benefits such as Convention over Configuration. On the other hand, this also means that Ruby on Rails can be unforgiving if you don’t want to do things ‘the Rails way’.

Where Rails is opinionated, Merb is agnostic. For example, you can easily use your favourite ORM (ActiveRecord, DataMapper, Sequel) or none at all.
Similarly, you can choose the Javascript library and template language that you are most comfortable with, or that best meets the requirements of your specific project.

If performant were a word, Merb would be it. One of Merb’s design mantras is “No code is faster than no code”. Merb has super-fast routing and is thread-safe. The core functionality is kept separate from the other plugins and it uses less Ruby ‘magic’, making it easier to understand and hack.

Rails (and consequently Ruby) has received a lot of criticism for not being suitable for large scale web applications, which isn’t necessarily true. Merb has been built from the outset to prove that Ruby is a viable language for building fast and scalable web applications.

At the end of the day it’s about choice. There are many new Ruby frameworks springing up, undoubtedly encouraged by the success of Rails. In our opinion, Merb shows the most promise of these.

If you’d like to take a look at some other frameworks these links should get you started:

• http://camping.rubyforge.org/files/README.html
• http://www.nitroproject.org/
• http://ramaze.rubyforge.org/
• http://sinatra.rubyforge.org/
• http://halcyon.rubyforge.org/
• http://wisteria.swiftcore.org/
• http://api.mackframework.com/

Yesterday saw my first posting to the official Rails weblog. A nice step on the way to world domination, I guess.

Normally RDoc is there for you when it comes to auto-generating nice HTML documentation for your Ruby projects. But just now, it flat out failed while generating Graphviz diagrams of my code.

I was attempting to generate some documentation for the Ronin SQL library in order to test the formatting of README.txt. To my surprise rake docs failed without any informative error message describing which file caused RDoc to chock.

Here’s the output of rake --trace docs:

[ gist.github.com/19353 ]
Generating HTML...
Diagrams: ...
/usr/lib64/ruby/1.8/rdoc/markup/simple_markup/fragments.rb:291: warning: Object#type is deprecated; use Object#class
rake aborted!
undefined method `level' for nil:NilClass
/usr/lib64/ruby/1.8/rdoc/markup/simple_markup/fragments.rb:292:in `add_list_breaks'
/usr/lib64/ruby/1.8/rdoc/markup/simple_markup/fragments.rb:282:in `each'
/usr/lib64/ruby/1.8/rdoc/markup/simple_markup/fragments.rb:282:in `add_list_breaks'
/usr/lib64/ruby/1.8/rdoc/markup/simple_markup/fragments.rb:153:in `normalize'
/usr/lib64/ruby/1.8/rdoc/markup/simple_markup.rb:459:in `group_lines'
/usr/lib64/ruby/1.8/rdoc/markup/simple_markup.rb:255:in `convert'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:246:in `markup'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:818:in `value_hash'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:865:in `write_on'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:1293:in `gen_into'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:1293:in `open'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:1293:in `gen_into'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:1289:in `each'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:1289:in `gen_into'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:1276:in `generate_html'
/usr/lib64/ruby/1.8/rdoc/generators/html_generator.rb:1197:in `generate'
/usr/lib64/ruby/1.8/rdoc/rdoc.rb:284:in `document'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake/rdoctask.rb:113:in `define'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:588:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:585:in `invoke_prerequisites'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:577:in `invoke_with_call_chain'
/usr/lib64/ruby/1.8/monitor.rb:242:in `synchronize'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:571:in `invoke_with_call_chain'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:564:in `invoke'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2019:in `invoke_task'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `each'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1997:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1991:in `top_level'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1970:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:2036:in `standard_exception_handling'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1967:in `run'
/usr/lib64/ruby/gems/1.8/gems/rake-0.8.3/bin/rake:31
/usr/bin/rake:19:in `load'
/usr/bin/rake:19


Suddenly, all that talk about YARD replacing RDoc is sounding a lot more pragmatic. YARD has certainly worked out for DataMapper and Merb thus far. Maybe Ronin will give YARD a try.

Ronin has been my main quasi-secret (I only told people who asked what I was hacking on in GVim) project for some time now. It has also been driving most of my side projects, such as GScraper, reverse-require and R’epertoire. The code-base has finally settled down now, allowing me to release version 0.0.9 of Ronin. This is an initial beta-release, so not all of the desired features are present, although I’m always looking for user-feedback.

Ronin is a platform for information security and data-exploration tasks. Ronin harnesses the elegance of Ruby (one-liner convenience methods, sparse monkey-patching, meta-programming, Domain Specific Languages (DSL) and duck-typing) to provide the user with a robust API, an extendable command-line utility and a customized IRB console.

Ronin is considered a platform and not a framework, since it has the ability to install Overlays of code (think extensions) and data (think exploit/shellcode repositories) from any SubVersion (SVN), Git, CVS or Rsync repositories, which are then integrated into Ronin’s environment. The ability to install 3rd party code or data from any common source-code repository using just a URI is what makes Ronin decentralized.

Ronin is not bloated either, most of it’s functionality is divided between various libraries which can be selectively installed by the user. These libraries allow the user to choose what functionality they need from Ronin. Ronin currently provides the following libraries:

• Ronin SQL – Provides SQL Injection tests, exploitation methods and a DSL for generating complex SQL Injection statements.
• Ronin PHP – Provides PHP Local File Inclusion (LFI) and Remote File Inclusion (RFI) tests, fingerprinting, exploitation methods and a custom PHP Remote Procedure Call (RPC) server which can injected via RFI vulnerabilities.
• Ronin Dorks – Provides a simply API for performing common or even custom Google Dorks.
• Ronin Exploits – Provides an API for defining Exploits or Payloads which can also be distributed over the previously mentioned Overlays and cached by Ronin for later use.

Ronin is packaged as a RubyGem and can be downloaded here. To install Ronin using RubyGems, simply run the following command:

$ sudo gem install ronin

Documentation for Ronin and it’s libraries can be found here. If you have further questions there’s also a FAQ for Ronin.

Update 2: I have recently published a HOWTO covering Ronin’s convenience methods and how to perform everyday tasks in the Ronin Console (such as owning web-servers).

Update 1: An astute reader of this blog pointed out that R’epertoire 0.1.2, which is required by Ronin, was not yet released as a RubyGem on rubyforge.org. This issue has been corrected and R’epertoire 0.1.2 is now available for download.

Also expect a release of the Ronin Exploits soon (I’m in the process of adding the beginnings of Vulnerability Taxonomy to the Exploit base-class).

DataMapper (dm-core, dm-more):

rake install SUDOLESS=true

Merb (merb-core, merb-more, merb-plugins):

rake install MERB_SUDO=

oh, well.

Hello,

I just came across a new group created on FaceBook, which covers major subjects like… (1) Ruby (2) Rubinius (3) IronRuby (4) Rails and (5) Merb.

The main goal is to discuss all this major topics under on roof. This group is specially created by Indian developers, with a mission to promote Rails and other related languages/frameworks in India.

I would highly recommend joining there.

Thanks