Everybody who works on a big project or in a big team and uses magic methods/properties should say thank you to Roy Ganor. He added code completion support for PHP's magic methods and properties to Eclipse PDT.

Actually, as far as I know makes this bugfix PDT the only one which supports code completion for magic properties and methods.

Sources:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=235108
http://manual.phpdoc.org/HTMLSmartyConverter/PHP/phpDocumentor/tutorial_tags.property.pkg.html

Posted by Enrico Stahn in IT at 15:56 | Comments (0) | Trackbacks (0)

The company I'm currently working for has one of those TextDrive life time accounts. We moved one of our projects from a dedicated server to this account which results in some errors based on the different ferret versions. The pragmatic way was to rebuild the index (<Modelname>.rebuild_index) which I did but without success because I straight run into the following error:

NoMemoryError (failed to allocate memory):
    (eval):3:in `each_hash'
    (eval):3:in `all_hashes'
    /vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:396:in `select'
    /vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all'
    /vendor/rails/activerecord/lib/active_record/base.rb:424:in `find_by_sql'
    /vendor/rails/activerecord/lib/active_record/base.rb:994:in `find_every'
    /vendor/rails/activerecord/lib/active_record/base.rb:415:in `find'
    /vendor/acts_as_ferret-0.4.0/lib/local_index.rb:219:in `reindex_model'
    /vendor/acts_as_ferret-0.4.0/lib/local_index.rb:217:in `reindex_model'
    /vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:59:in `transaction'
    /vendor/rails/activerecord/lib/active_record/transactions.rb:95:in `transaction'
    /vendor/acts_as_ferret-0.4.0/lib/local_index.rb:216:in `reindex_model'
    /vendor/acts_as_ferret-0.4.0/lib/local_index.rb:47:in `rebuild_index'
    /vendor/acts_as_ferret-0.4.0/lib/local_index.rb:46:in `rebuild_index'
    /vendor/acts_as_ferret-0.4.0/lib/local_index.rb:23:in `ensure_index_exists'
    /vendor/acts_as_ferret-0.4.0/lib/local_index.rb:14:in `ferret_index'
    /app/models/place.rb:59:in `find_storage_by_contents'
    /app/models/place.rb:54:in `full_text_search'
    /app/controllers/places_controller.rb:38:in `search'
    ...

Well, I was a bit surprised as it worked fine on the dedicated server and we'd the same version of act_as_ferret on both machines.

Let's test

# ruby script/console production
>> Place.find(:first).nil?
=> false
>> Place.find(:all, :limit => 10).nil?                                                                                                                                       
=> false
>> Place.find(:all, :limit => 100).nil?                                                                                                                                      
=> false
>> Place.find(:all, :limit => 1000).nil?                                                                                                                                                          
(eval):3:in `each_hash': failed to allocate memory (NoMemoryError)
        from (eval):3:in `all_hashes'
        from ./script/../config/../config/../vendor/rails/activerecord/lib/active_record/connection_adapters/mysql_adapter.rb:396:in `select'
        from ./script/../config/../config/../vendor/rails/activerecord/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in `select_all'
        from ./script/../config/../config/../vendor/rails/activerecord/lib/active_record/base.rb:424:in `find_by_sql'
        from ./script/../config/../config/../vendor/rails/activerecord/lib/active_record/base.rb:994:in `find_every'
        from ./script/../config/../config/../vendor/rails/activerecord/lib/active_record/base.rb:415:in `find'
        from (irb):8:in `irb_binding'
        from /usr/local/lib/ruby/1.8/irb/workspace.rb:52:in `irb_binding'
        from /usr/local/lib/ruby/1.8/irb/workspace.rb:52

Fetching 1000 rows causes the error which is the default reindex batch size of acts_as_ferret.

so far so good

Let's change the batch size as the documentation describes, it shouldn't be a big deal. Well, shouldn't be, but the current documentation seems to be build for the trunk and not for the stable version (0.4.0), so we have to change one line of the acts_as_ferret sources.

Open local_index.rb and change line 210 so that it fit your needs. I got good results with 100.

207    def reindex_model(index, model = aaf_configuration[:class_name].constantize)
208      # index in batches of 1000 to limit memory consumption (fixes #24)
209      # TODO make configurable through options
210      batch_size = 100
...      ...
228    end

Posted by Enrico Stahn at 15:29 | Comments (0) | Trackbacks (0)

You're using the Grid of yui-ext and you're loading the data with XMLDataModel, JSONDataModel or any other kind of LoadableDataModel, right? Well, did you tried to use the remoteSort configuration and got worried about this feature as you're recognize it sends the column index instead of the field name?

Instead of rewrite parts of yui-ext, use the following code after you loaded yui-ext. Now, you should get the field name.

YAHOO.ext.grid.LoadableDataModel.prototype.createParams = function(pageNum, sortColumn, sortDir) {
        var params = {}, map = this.paramMap;
        for(var key in this.baseParams){
            if(typeof this.baseParams[key] != 'function'){
                params[key] = this.baseParams[key];
            }
        }
        params[map['page']] = pageNum;
        params[map['pageSize']] = this.getPageSize();
        params[map['sortColumn']] = (typeof sortColumn == 'undefined' ? '' : this.schema.fields[sortColumn]);
        params[map['sortDir']] = sortDir || '';
        return params;
}

Posted by Enrico Stahn at 06:50 | Comments (0) | Trackbacks (0)

I had a wonderful Christmas and an impressive New Year's Eve with a lot of friends. None of all photos I took can reflect what kind of impressions and feelings I got. I'm thankful that I could spent my time with these people in this country.

Christmas

1th and 2nd Christmas Day

End Of Year BBQ in Peakhurst

New Years Eve 2006/07

City of Sydney: New Year's Eve Syndey 2006/07

Posted by Enrico Stahn in Australien, Privat at 05:29 | Comments (0) | Trackbacks (0)

Ich hatte eigentlich vor den Artikel mit dem Titel "Neues Spielzeug" zu publizieren, aber als Spielzeug kann man Ruby on Rails, trotz seiner derzeitigen Version (1.1.6), nicht bezeichnen. Ich persönlich komme aus der Perl und PHP-Ecke, habe mit Ruby oder dem Framework Ruby on Rails erst durch meine jetzige Firma angefangen. Nach 2 Tagen Einarbeitung und dem ersten Programm, war ich schlichtweg begeistert wie einfach und logisch doch alles ist.

Was ich an Ruby on Rails so toll finde ist:

• Strukturiert: Ich bekomme eine feste Struktur vorgegeben, in der ich entwickeln kann.
• Koventionen: In Ruby on Rails gilt "Konvention über Konfiguration". Im Gegensatz zu diversen Java-Frameworks wie z.B. Spring, muss man nicht erst ein paar Seiten XML schreiben, bevor es mit der Problemlösung losgeht.
• Modellierung: ORM ist bereits enthalten (genannt ActiveRecord) und die Klasseninhalte (das Mapping) wird automatisch erstellt.
• Deployment: Es wird anfänglich zwischen 3 Systemen unterschieden (development, test und production) und es können weitere hinzugefügt werden. Das macht es sehr einfach bestimmte Sachen zu Testen. Über Capistrano kann man dann ein das deployment zum Produktivsystem anstoßen.
• Migrationen: Für die Datenbank gibt es eine Migrationsstruktur. Wenn wir also eine neue Softwareversion mit Datenbankänderungen haben, so können wir Migrationsdateien (Up-, Downgrade) erstellen, die dann automatisch bei einem Deployment ausgeführt werden können.
• Dokumentation: Für sein System kann man eine komplette API-Dokumentation erstellen lassen. Hat man Graphviz und den Rails Application Visualizer installiert, gibt es sogar grafischen Relationsdiagramme.

Alles in allem, bekomme ich also eine komplette und vor allem durchdachte Entwicklungsumgebung an die Hand, in die ich mich nicht umständlich einarbeiten muss und die sich auf praktische Probleme konzentriert.

Hilfe

Die Ruby Community ist groß und es gibt reichlich Dokumentation und auch fertige Plugins wie z.B. den SaltedLoginGenerator mit dem man in 5 Minuten (oder weniger) ein komplettes Authentifizierungsystem fertig hat.

Nachteile

Nachteile von Ruby on Rails sind mir bis jetzt noch nicht so aufgefallen. Es ist lediglich etwas schwierig deutsche Provider zu finden, die Rails-WebHosting (nicht Ruby WebHosting) anbieteten. Ich selbst kann es verstehen, da die Konfiguration im ISP Umfeld ggf. etwas schwierig ist. Meiner Meinung nach, liegt das Problem unter anderem am Einsatz von Apache als Webserver. Ruby on Rails + FastCGI haben bekannterweise Probleme unter Apache stabil zu laufen. Einen guten Artikel mit mehreren Lösungsvorschlägen gibt es von James Duncan Davidson.
Vor dem durchlesen dieses Artikel hatte ich ebenfalls daran gedacht, das Apache einfach als Proxy zu Lighttpd fungiert. Ein ISP braucht dann ggf. nicht die gesamte Infrastruktur umstellen oder Angst um die Stabilität des Apache zu haben.

Ruby versus Java

Ich halte generell nichts von solchen Glaubenskriegen und überlasse Euch die Meinungsbildung. Hier ein paar "Ruby versus Java"-Links.

• Ruby vs Smalltalk vs Objective-C vs C++ vs Java vs Python ...
• Is Ruby Replacing Java? — Not So Fast
• Ruby vs. Java: A matter of taste

Videos und Potcasts zum Thema

• http://www.rubyonrails.org/screencasts
• Tonabnehmer #8: Thomas Baustert, Ralf Wirdemann - Ruby on Rails

Posted by Enrico Stahn at 07:22 | Comments (0) | Trackbacks (0)