Friday, January 27, 2006

.c( whytheluckystiff )o. -- Seeing Metaclasses Clearly

This is a useful tutorial on metaclasses by Why.

I wanted to do it all alone, but I will try to resist and see what is already available for me to build on.

Monday, January 23, 2006

Online Community Building Tools

A friend recently called me up asking my help to enhance the ties of some activist groups he is touch with, by using the web.

I have been reading a bit about the web2.0, I had a quick brush with Ning and I mused on philosophical issues.

Now, it is the right time to act.

I am pretty certain that what I want to do is to not start some kind of website project from scratch.

The group already has a small website, acting as a web frontend for the organization, but I would rather go for existing services or a mush-up rather then trying to run the infrastructure on our own.The other point is that, while I am very willing to spend time to create new stuff and put ideas together, I am not willing to put much effort into the maintenance.

I also believe this is a chore that the community itself should take care of, learning how to live their own spaces and take care of them.I can see that on the web there are plenty of web2.0 apps, but what I see missing is some kind of glue to put together what I need into a single mushup.

The lack of a single sign-on is particularly critical.

We could go around this, by gathering user subscription requests through the main site and then automate subscriptions to all the different sites of the mush-up, making sure the usernames and passwords are unique.

However this is both labour intensive and it raises some doubts from a privacy point of view. What I am doing now is to look for a all-in-one community container.

Something that provides single sign on to a number of basic services, which allows html customization and enhancements, and that allows easy administration of the system.

These are some promising links that I have found:

Friday, January 20, 2006

Software Roadmap

I have started a number of small projects, both to explore ruby's capabilities and to play with some concepts that I found hard to express in other languages.  These projects are still in their infancy, so I haven't put them on rubyforge yet, but I plan to work on releasing them soon.

The projects are:
I will show a couple of prozed intents from these projects.  If any of you is interested in any of them, let me know and I might focus my efforts on what becomes more popular and I will release it on rubyforge.


a small set of metaprogramming utilities

intent of "Generating text from a line of text and variations"

    "Dear <title>  <person>"
            "<title>"  => ["Mr", "Dr", "Mrs"],
            "<person>" => ["Smith", "Black", "Grey"],
            separator  => ", "
    should be "Dear Mr  Smith, Dear Dr  Black, Dear Mrs  Grey"

this is used as an helper to generate code for metaprogramming purposes.


smart operations on objects - spreading commands over collections, taking 'slices' from object collections

easy creation of Value Objects

class Person
   defined by name, surname, age

intent of "Reading attributes of an object using 'defined by'"
    a person = Person new "Winnie","Pooh",70    
    a person name should be "Winnie"
    a person surname should be "Pooh"
    a person age should be 70

existential quantification

intent of  "Verifying if exist any" 
    expect [1, 6, 10] exist any? |n| n>5
    dont_expect [1, 6, 10] exist any? |n| n>15

intent of  "Verifying at least one element is true" 
    expect [true, true, false] any true?
    dont_expect [false, false, false] all true?

collective action using several alias forms

people = [

story "Turning people names to uppercase"
    people to upcase should be ["JOHN","MIKE","SAM"]

intent of "Using shortcut form for collective action"
    people / reverse
    should be ["nhoj","ekim","maS"]

    people all reverse everyone capitalize
    should be ["Nhoj","Ekim","Mas"]

object slicing

intents "Object Slicing - sorting by property"
    people sort by name  every name
    should be [

and random picking... I will just give a prozed example here:

people = [ "john", "sam", "mike", "frank"]
people pick one
people pick two
people pick two different


implicit mapping of directory and file structures to object aggregates.  mapping of file types to classes

def sample smart store
    SmartStore new ("intent-files/data")

story "Opening up an order"
  repository = sample smart store 
  repository map! [child, of "orders"] => Order
  an order = repository
               order milan["20050906"]
  expect an order, 
     to be Order new 
             "Chairs"    =>  18,
             "Laptops"   =>  10,
             "Desks"     =>  7


all my intents for Clay are very poor.  I'll describe it another time.
what it does is to let you improvise the creation of objects and their attributes without needing to declare any class for them.


a small financial framework

story "Using Cashflows"  
    Let's now deal with cashflows
    with  Conventional discount =
          continuously compounded yield

    we  expect about 271.67748, as the
        present value of 
          Cashflow  [
             100 at 1 year ,
             100 at 2 years ,
             100 at 3 years 
          with interest rate at   5 percent

The other stuff is a bit more articulate and I'll leave it for another post :-)

Thursday, January 12, 2006

RSpec as a DSL

I just saw Steven Baker's code from RSpec when pointed there by Victor Cosby.&nbsp; It looks a lot like my Intent framework.

I'll need to do some code reading here

Modern Languages

Just some new languages to check out:

* Boo on codehaus

* Io , a small language

Tuesday, January 03, 2006

Let the Code DRY - later on..

I finished writing the first draft of the SnapshotEngine code that I wrote about in the previous post. I produced it by copying and modifying snippets of code from the FactEngine, rather than subclassing it.

The result is much much clearer code.

True, there is some duplication, but I am now in a better position to decide what can be abstracted. I have detected a few common methods and I might put them into a common superclass or into a mixin utility module. I might even decide to not abstract it. The two classes could still develop in quite different ways and I may not want to tie them together yet.

Monday, January 02, 2006

Let code DRY on its own: Duplicate, Scan, Refactor, Abstract

Tonight I spent several hours trying to get a piece of code of the Intent framework working. As usual these mistakes tend to be due to the wrong kind of laziness and to a false perception of coding economies.

I had this set of classes handling 'facts' - a recording of certain chosen outputs of a piece of code - and I wanted to add a new feature called 'snapshots'.

When you create a snapshot all the outputs of your program that would go to stdout are implicitly redirected to a file where they are stored and later used for a pretty raw form of regression testing. Snapshots looked to me like a specialized form of Facts, so what I did was to inherit from my FactsEngine class a SnapshotsEngine class, and I started building on that.

However as I was halfway through my top-down implementation (can I test first a test first framework? :-) I started realizing that the workflows of the two engines were not as similar as they seemed to me from an initial high level view. There were a few annoying details that kept getting in the way. Some state that should have been initialized, some step that was skipped, some more steps that needed to be added.

Soon enough the SnapshotsEngine had become an unreadable patch of the FactsEngine, that also had to be 'abstracted' to allow hooks for the SnapshotsEngine. By the way, nothing worked anymore and I started downloading Komodo so that I could use a debugger.

As I am writing I start feeling that resorting to debugging is like an admission of failure. I tried to don't repeat myself by going for inheritance, but I did it a bit too early.

DRY - Don't repeat yourself - should be interpreted in a teleological sense. The code should drift to a DRY state. Starting out DRY is not always the best way to get it right, as it is far too easy to fall into upfront design and believe that you really know things that you don't know only because you are able to generate early abstractions.

I find that the following sequence works well to produce DRY code:
What I found out is that a DRY, but bad abstraction is much much worst than duplicate code. Duplicate code can still be abstracted in a clean way, and it can also be pretty easy on the eye even if it is quite verbose and repetitive. Code that has been badly abstracted is obfuscated and hidden behind ad hoc abstractions and technical tricks that make it unreadable.

So, don't DRY your code. Apply the DuScRAb sequence and let the code DRY on its own.

This page is powered by Blogger. Isn't yours?