The modules and mixins in Ruby are a good way to implement AOP in Ruby. Typical AOP examples are debugging and logging. Modules allow you to weave in aspects of code in different classes – exactly what you need for AOP. Ruby offers full support: “extend” is used to add methods from modules as class methods to other classes, “include” to add methods from modules as an instance method to another class.
In typical Ruby on Rails applications you will find a lot of “AOP-like” code, especially in plugins (for example plugins for adding tags, attachments or permalinks). Plugins usually extend Rails with modules: especially the popular ActsAsSomething plugins work this way. The Plugins in Ruby on Rails are therefore also a good example of AOP. Again, Ruby on Rails shows that is has an advantage over other frameworks – it offers a very powerful ORM famework, a built-in support for testing and TDD, and easy use of AOP.
4 Lines of Code 
Sorry to burst your bubble, but these tools are not AOP. To call this AOP is to call putting all related functions in the same include file together with their variables object orientation.
Here is a blog post two years before yours that explains very well what is going on here: http://debasishg.blogspot.com/2006/06/does-ruby-need-aop.html
Sorry to burst your bubble Adrian, but mixins in Ruby are indeed a perfectly viable way to do AOP. You can get academic all you want with semantics but at the end of the day the purpose of AOP is simply cross-cutting concerns, which mixins do just fine.