Resize existing images when using attachment_fu

If you use the attachment_fu plugin and want to resize all your existing image files after changing any of your thumbnail formats, write a littler runner script like this:

    1 # resize_images.rb
    2 only_this = ARGV[0]
    3 classes = [
    4   'Photo',
    5 ]
    6 classes = only_this.blank? ? classes : [only_this]
    7 classes.each do |klass|
    8   puts "resizing all #{klass.to_s.tableize}"
    9   Kernel.const_get(klass).find(:all, :conditions => 'parent_id IS NULL').each do |image|
   10     puts "...#{image.public_filename}"
   11     temp_file = image.create_temp_file
   12     image.attachment_options[:thumbnails].each { |suffix, size|
   13       image.create_or_update_thumbnail(temp_file, suffix, *size)
   14     }
   15   end
   16 end
   17 

which you can call with

./script/runner ./script/resize_images.rb 

if you want to resize all images stores with attachment_fu. Or if you only want to resize your Photo model images:

./script/runner ./script/resize_images.rb Photo

How to call a common deploy task during the deployment?

For example, if you want to clean up your releases directory on every deployment (using Capistrano), simply add the following lines to your deployment script:

#deploy.rb
after 'deploy', "deploy:cleanup"

That's it :-)

The X and the P, and the RoR in my mind

Fast könnte man meinen, Ruby on Rails sei für eXtreme Programming geschaffen worden. Oder XP sei die Grundlage bei der Entwicklung von Rails gewesen. So sehr ergänzen und fördern sich die beiden gegenseitig. Kaum vorstellbar, die spontanen Richtungswechsel und Systemänderungen sollten in einer Java- oder - schlimmer noch - in einer C++ Umgebung realisiert werden.

Schön schlank, überschaubar und vor allem erlebbar muss Software-Entwicklung sein, und damit das Ergebnis der Arbeit. Ruby on Rails ist und bietet genau das. Dicht am Kunden und seinen Bedürfnissen sein (on site customer), die nächsten und damit wichtigsten Änderungen und Erweiterungen mit dem Kunden durchsprechen (planning game), einen kleinen Prototypen basteln, schnell und effektiv (small releases, iterative/incremental), mit allen Vorteilen einer modernen Programmiersprache, direkte, spürbare Unterstützung bei der Arbeit durch integriertes Unit- und Funktionstesting (continuous testing and integration) oder O/R-Mapping, descriptives Programmieren (simple design) und Unterstützung durch moderne Werkzeuge. Was braucht man mehr?

Jeder, der die Chance hat, mit Ruby on Rails zu arbeiten und dieses Framework in einem agilen Projekt einzusetzen, der sollte diese Chance nutzen! Kent Beck und Ward Cunningham haben den Grundstein gelegt, David Heinemeier Hansson hat die tragenden Wände gebaut. Jetzt sind wir dran!

Stand up and fight

Extreme Programming ist nicht neu. Und doch irgendwie zu neu. Und zu anders. Kaum vorstellbar. Vor allem nicht, dass es auch funktioniert. Pair Programming? Da machen ja dann zwei Leute das, was sonst einer könnte... Test First? In der gleichen Zeit kann man doch richtigen Code schreiben... Extrem ist nicht gut. Wir bleiben lieber beim normalen. "Für Spielereien haben wir keine Zeit." "Universitäre Spinnerei." All das habe ich schon gehört. Und Stand-up Meetings? Leute werden für's Rumstehen und Labern bezahlt...

Apropos Stand-up Meeting. Mal abgesehen davon, dass sie tatsächlich im Stehen abgehalten werden, sind sie ziemlich sinnvoll. Und selbst das Stehen hat seinen Sinn. Es gibt keinen schnelleren Weg, um sich einen Überblick zu verschaffen. Über das, was die anderen machen und gemacht haben. Und auch und vor allem darüber, was man selber macht oder gemacht hat. Forcierte Reflexion. Sofort wird nachvollziehbar, warum so viele Manager XP ablehnen.

Und warum jeden Tag? Weil an einem Tag so irre viel passiert. Carpe diem.

Ein Wort über Pair Programming

Hab's heute gemerkt. Pair Programming ist gut. Und wichtig. Und es macht auch mehr Spass. Viel wurde schon geredet über Pair Programming. Viel Positives, und auch viel Negatives. Angezweifelt wird es immer noch. Auch ich bin nicht immer überzeugt. Arbeite auch gerne mal alleine. In Ruhe. Hmm... Welche Ruhe meine ich denn damit? Meine innere jedenfalls nicht.

Vielleicht ist das aber auch der entscheidende Punkt. Das ultimative Pro, wenn wir denn eins gebraucht haben. Ruhe ja, Konzentration auch. Aber auch Ausreden, Faulheiten und halbgare Ideen. Und irgendwie spürt man diese Löcher, die man alleine produziert. Die innere Ruhe? Der Schein trügt. Man stimmt sich nicht ab, man übersieht und überblickt nicht. Die innere Ruhe braucht man schon alleine deshalb, weil man sonst den Faden komplett verliert, wenn man alleine auf ein paar Zeilen Code schaut.

Seit heute bin ich endgültig überzeugt. Habe heute ohne meinen Partner programmieren müssen. Du hast mir gefehlt, Kumpel. Ein Wackeldackel reicht halt doch nicht.