How many times you were left high and dry after a very promising technology or product that you so much believed in just vanished in front of your eyes?

inversely, how many times you felt that joy when you made sure that this emerging technology you embraced or evangalized is actually gaining real momentum?

For me, my path in the technology sector has been a mix of both. Does that mean anything? does it say anything that every technology you adopt booms/busts?

In my silly 10 years of following the computer industry in general I had the following adoption failures:

1. Cyrix, the little company that could! I was amazed by the capacity of their small team of engineers. But they just couldn't stand the tough fight. Bye Bye Cyrix.
   
   
2. BeOS, a piece of engineering beauty. At least in the usability dept. I learnt my C++ by carefully studying the BeOS AP. I did almost all my low level coding attempts on BeOS. I even learnt bash on BeOS. I wasn't grasping why not every body on earth is using it! Silly people I thought (and still think :P). BeOS is no more, RIP BeOS (would be happy to see it ressurected one day though)
   

Not a long list, what about successes?

1. Hibernate the ORM man, I knew it was a hit the day I saw their documentation, those guys new their stuff! I joined the ranks in the early version 2.0 days (Gavin's rewrite of the thing). You can still see me grin each time I see a developer using Hibernate at the place where I work.
   
   
2. Javascript for semi-fat clients, it was the year 2000 and the use of Javascript for more than form validation was a taboo for many (browser compatability hell). Not for me, at the place where I work we fully embraced Javascript, and it (almost) never failed us!
   
   
3. Ajax, we've already had such functionality, but since reading adaptive path's article, I really saw what I was missing by avoiding the XMLHTTPRequest object. In a week or so I had an ajaxified wroking protoytpe of our flagship application.
   
   
4. Ruby on Rails, not really an early adopter (managed to use it for production in the pre 1.0 days). I still get this feeling of joy whenever I hear about another success (many of those these days). Rails has come out of age, that's for sure.

Wow, that's 100% more than the failures list, I am glad that this is case though I dont think it proves anything

Now what about the products/technologies I'm looking at now?

1. Ubuntu? Debian was already great. Ubuntu is the icing on the top of the cake. This one might boom.
   
   
2. Offline web apps (sometimes connected apps, discussed here). These are just around the corner. If they manage to break the chasm before wireless technology covers the whole planet they will enjoy great success (for a while at least).
   
   
3. The new wave of falling back to the forgotten REST API. I beleive we have a winner here. Specially when you see something like this coming out of it
   

Things that I hate/think will fail/would like to see fail

1. JSF, I believe one day people will realize that building interfaces is not like building a brick wall. That's the day JSF and the likes will be burnt for witchcraft!
   
   
2. PHP, combine an ugly inconsistent sytanx with a terrible extension API and you've got yourself a PHP clone. Even though I managed to write decent apps in PHP but wouldn't like to live this experience again.
   

That's enough for a wish-to-fail list, 2 items and I already feel the high blood pressure, I just don't want to get started on the giants now.

Every body will have his own pattern of failures/successes in following trends. Would be interesting to see what others think.

I was amused to read Rob William's take on a Ruby article in SD Times. Aside from his sarcasm, he scores home with most of the arguments though I beg to differ with some of them. I will highlight some of my opinions and respond for Ruby :)

1. Our tools do that.!! The article was pointing to how Ruby follows the Unified Access Principle where you only have one interface to the class data members, whether it is a simple storage operation or a complex one. But, as Rob points out, having such support in the language is useless because current tools do that. I bet Bertrand Meyer wouldn't roll on his grave because Ruby is trying to offer UAP even when there are such tools around.
   

   # initial class
   class Plan
      attr_accessor: owner
   end
   
   plan = Plan.new
   plan.owner = rob
   plan.owner                      #  => rob
   
   # we now need to upgrate to a full fledged setter
   # rather than the one dynamically generated for us above
   class Plan
      attr_accessor: owner, assigned
      def owner=(owner)
          @owner = owner
         @assigned = true     
      end
   end
   
   plan = Plan.new
   plan.owner = rob
   plan.owner                        # => rob
   plan.assinged                 # => true
   

   
   
2. Long code is like short code is like medium code! Rob is picking at the author for mentioning that Ruby produces less lines of code. He's arguing that the tool is producing those verbose Java lines for us too!. As if we should accept garbage only and only if it is spit at us by our favourite tool! Why don't we all ditch the use of annotations for Hibernate mapping when our eclipse XML editor does autocompletion for the .hbm files? it is not about too many lines of code, it is about clutter and organization. I long for the day when i used VisualAge for Java, It was really anti clutter! (written in SmallTalk, no less!)
   

   # neat example on short code
   session.time_out = 48.hours.from_now
   

3. Rob rightfully accused the author to have poorly written the testing section and dynamism. The author was seemingly speaking about mock objects and how using them in a dynamically typed system is easier than a statically typed one. In a dynamic setting, identifying a mock object and using it is seamless. Also writing the mock object itself is seamless, no interface or contract of some sort, you only code the methods that you intend to handle and the others are handled by a common method. It's rather interesting to see that almost all the Java guys would praise AOP and tell stories about the wonders that they achieved using AOP (many are actually finding their way around the static nature of Java through AOP)
   

   class Person
      def can_run?
          # some tedious operation
      end
      def can_jump?
          # some other operation
      end
   end
   
   # person mockup
   # returns true whenever the method called has the character ?
   class PersonMockup
      def method_missing(method_id)
          method_id.to_s["?"]
      end
   end
   
   # or for some dynamic magic
   class Roman
      def roman_to_int(str)
          # do conversion here
      end
      def method_missing(method_id)
          roman_to_int(method_id.to_s)
      end
   end
   
   roman = Roman.new
   roman.V            # => 5
   roman.IV            #  => 4
   roman.VII          #  => 7
   

4. "ActiveRecord is simplistic". Here Rob doesn't justify why he thinks AR is rather simplistic? may be he is commenting on the simple example given by the article author? AR is rather a simple interface for a stunningly powerfull engine that provides you with a wide variety of DB constructs, the has_many and sisters, are actually defined in the AR module and when invoked they add methods and functionality to the invoking class at the class definition time. And due to Ruby's syntax flexibility they fit naturally in the class definition you don't even notice that they are function calls but rather some seamless annotation of some sort (which actually affects the class being declared and adds methods and attributes dynamically to it). Ruby provides you with the ability to add even more of those to AR. By excercising this feature you can build very complex relations between your domain models and still keep your code clean and clutter free.
   
   

   class Person < ActiveRecord::Base
      has_many       :plans
      has_many        :tasks,    :through    => :plans
   end
   
   class Plan < ActiveRecord::Base
      has_many        :tasks
      belongs_to        :owner, :class    => "Person"
   end
   
   class Task < ActiveRecord::Base
      belongs_to        :plan
      acts_as_tree     #defines parent/child relation ship among tasks
      acts_as_taggable #for folksonomy aware objects (AR plugin)
   end
   
   #get all completed tasks for rob (involves one hit to the database)
   completed_tasks = rob.tasks.select{|task| task.completed?}
   
   #get all completed tasks that are parents for other tasks
   completed_prent_tasks = completed_tasks.select{|taks|!task.children.empty?}
   

   
   
5. On DSLs. There are many ways one can solve a problem, but if you can shape your language around the domain you're attempting at that makes for much clearer code (wich is evident by looking at the above example) DSLs are abundant in Ruby code, mainly because the language has enough metaprogramming constructs and syntax flexibility that promotes such an approach to problems. Here are a few examples on how you can shape your code around your specific problem domain in a way that a domain expert will naturally understand the code.
   

   # using a dsl suited for representing a workflow
   workflow "default" do
    step "scan"
    step "ocr" do
      when_error "manual"
    end
    step "cleanup"
   end
   
   workflow "manual" do
    step "correction"
    step "distribute"
   end
   
   #or a dsl for meal recipes
   recipe "PBJ Sandwich"
   ingredients "two slices of bread",
              "one heaping tablespoon of peanut butter",
              "one teaspoon of jam"
   instructions "spread peanut butter...",
               "spread jam...",
               "place other slice..."
   servings 1
   prep_time "2 minutes"
   
   #another dsl from rspec
   target.should.equal 7
   target.should.not.equal 5
   target.should.be Fixnum
   target.should.contain 'a'
   target.should.be.empty
   target.should_respond_to :quak #for the love of the duck!
   
   #or from the poignant guide :D
   class Dragon < Creature
     life 1340     # tough scales
     strength 451  # bristling veins
     charisma 1020 # toothy smile
     weapon 939    # fire breath
   end
   

   
   
6. camelCaseVariablesLookPrettyNeatAndAreSoSweet , on the other hand underbar_variables_look_terribly_ugly_and_dull . That's what Rob thinks I suppose. I wont comment on Rob's taste, to each his own. I used to think like him, not any more.
   

   testHasThreeClientsAndOneSupplierAndTwoStores()  //pretty java
   
   test_has_three_clients_and_one_supplier_and_two_stores #ugly ruby :)
   

   
   

I have to stop before this turns into a Ruby vs. Java thing (a typical my daddy is bigger than your daddy duel) or did it happen already? Anyways, Rob was complaining from the poor quality of the article, which is largely true (I bet he'd complain from the poor quality of my writeup too, but would that stop me?). My issue is that harm was done to Ruby the language in the exchange, that's why I tried to shed some more light on the issues mentioned. I dont hate Java, I just think I had too much coffee ;)

To each his tools, to each his rules

oldmoe

"My opinion is right, though it could possibly be wrong. Your opinion is wrong, though it could possibly be right", Imam Shafey

This article covers what environments in Ruby on Rails are, how they are configured, and how you can create custom environments outside of the stock development, test and production.

read more | digg story

It's been a while since I wrote any update on that topic, but I'm glad that I will be reporting good progress this time.  The acts_as_taggable_tag (AATT from now on) plugin is shaping up nicely (along with my Ruby and Rails knowledge).

Currently the AATT is a real plugin that lives in /vendor/plugins in your rails app. The plugin enables you to do that to any of your models

class Person < ActiveRecord::Base
    acts_as_taggable_tag
end

This simple invocation adds the following to your model class

    #These methods are called to define the relations
    has_many :tag_joins, :class_name => "Tagging", :as => :tagged_one
    has_many :tagged_one_joins, :class_name => "Tagging", :as => :tag
       
    #These instance methods are defined for your model
        tags                   #returns a list of objects that tag yours
        tagged_ones            #returns a list of objects that are tagged by you
        tag(tagged_one)        #tag this object by yourself
        remove_tag(tag)        #remove this tag from you
        clear_all_tags         #delete the relations between you and your tags
        clear_all_tagged_ones  #delete the relations between you and objects tagged by you


If you look at the implementation of the above methods you'll notice how inefficient they are (a select call for each tag on a certain object for example). Performance is not my primary concern at this point in time, I am just trying to get the concept right.

A class is created for the  dual polymorphic join model (name Tagging). Currently the name and the table mappings are not configurable (you have to use what I give you, period). The table structure is available in a migration format and can be invoked by:

    rake import_aatt_schema

and it can be dropped from the database using:

    rake drop_aatt_schema

I will be preparing a .zip file containing the plugin. To install it you only need to unzip it in the vendor/plugins directory. A great guide to using plugins can be found here

acts_as_taggable provides a very easy means for tagging various objects in your Rails application. By using this plugin you can now add a tag to every object and even look at those objects from the tag's point of view; thanks to :polymorphic => true.

I was entertaining the idea of using tagging in a system that I am intending to build. There would be a very generic framework that consists of a certain basic element that can be tagged by different types of tags. I then realized that this was actually the opposite of what acts_as_taggable does!. acts_as_taggable defines a single tag type that can be applied to any object. This lead me to thinking, why not join both ideas? And hence the acts_as_taggable_tag.

acts_as_taggable_tag is not yet a module, but I couldn't resist the name ;). What it does is that it simply enables any object to act as a tag for another object even if it was of the same class or even if it was tagging itself! Thus implementing dynamic many to many associations across all your persistent domain objects through tags

The caveat though is that has_many :through does not play nicely with polymorphic associations as explained here . I ended up using only the join table (taggings in my case) and adding methods for retrieving both the objects that act as tags for the current object and the objects that are tagged by the current object

This implementation is a bit lacking when it comes to performance. What would make it sweet though is to enable :polymorphic associations with a has_many :through, looks like the next thing to dig into :)

Now for the code:

Person Class

class Person < ActiveRecord::Base
has_many :tag_joins,
:class_name =>"Tagging",
:as => :tagged_one
has_many :tagged_one_joins,
:class_name => "Tagging",
:as => :tag

def tags
self.tag_joins.collect { |tj| tj.tag }
end

def tagged_ones
self.tagged_one_joins.collect { |tj| tj.tagged_one }
end
end

Message Class

class Message < ActiveRecord::Base
has_many :tag_joins,
:class_name =>"Tagging",
:as => :tagged_one
has_many :tagged_one_joins,
:class_name => "Tagging",
:as => :tag

def tags
self.tag_joins.collect { |tj| tj.tag }
end

def tagged_ones
self.tagged_one_joins.collect { |tj| tj.tagged_one }
end
end

Tagging Class

class Tagging < ActiveRecord::Base
belobgs_to :tag, :polymorphic => true
belongs_to :tagged_one, :polymorphic => true
end

The code in the Person and Message classes is identical, now each of them has a list of tags and a list of tagged_ones each containing whatever objects of whatever classes that happen to tag or be tagged by the current instance of Person or Message

The Tagging class represents the double polymorphic association between the tagging object and the tagged one regardless of the Class. This approach can be used to implement all sorts of hierarchies among your persistent objects through tagging. I am using it to build a multi process project management tool, which through tags can create different views of the same data like an Iteration/Story one for something like XPlanner or a TodoList one for the BaseCamp style.

What's next is to look at how to modify AR so it will accept polymorphic associations with a has_many :through. But that can wait, I'm already glad that I can tag with such a flexible structure.

Happy tagging :)

This is not a whining post (at least I dont intend it to be so). I'm just trying to think out of the box for a change.

For the past few months I was surrounded by more white collars than ever in my life. Mr. IT Manager this and Mr. IT Manager that, even Mr. Director of Technical and Non Techncial Economic Hyper Relations at PSGCD (their names happen to puzzle you somtimes, dont they?).

And guess what? meetings to these people are like water to a fish, they can hardly survive out of the meeting room. We need to change a label? let's throw an ultra high level management meeting for three companies and let everyone and his brother join in. Now after 3 hours of brain trashing everyone agrees that the label really needs changing, and a follow up meeting is set to decide on the actual label to be used (ofcourse that's an exaggeration so take it with a grain of salt,...or two!)

I just heard a comment saying the I should be doing more meetings and less programming! I beg your pardon, programming is MY WATER! I dont imagine myself laying back and moving things by pointing a stick at them. I'm not an ivory tower type of a manager either. And I dont like the constraints that conventional management and white collar cultures are putting around me.

The joke is, after all that, those white collars are COSTING US MONEY! you'd imagine that working with multinationals is like having a cash cow, rather it's like having a fake cow for display (and no milk at all). You only have to deal with complicated requirements (that dont even make sense sometimes), very eager expectations, very slow payment and very limited technical assistance (up to the level of requiring us to travel between cities to install files).

I bet you're asking now: "why are you putting up with all of this?", I just asked myself the same question, and hence that (seemingly whining!) post :)

I'm still pondering it all in my mind, where should we (or I?) be directed, how can we be happy? and I mean HAPPY!

I'd quote DHH here, "so be happy"