Posts tagged ‘Ruby’

S.O.L.I.D. for dynamic and functional languages at SoCraTes 2011

At the SoCraTes 2011 conference I facilitated a session about applying the S.O.L.I.D. design principles to dynamic OO languages and to functional languages.

I prepared some Flipcharts with the SOLID principles (Slideshare), code examples for Java, Ruby, Scala and Clojure (GitHub) and a paper with a description of the SOLID design principles and some thesis about their application to dynamic OO and functional languages (PDF).

I am not sure if the session can be counted as a success. We had three groups. One was working on the application of SOLID to dynamic OO languages with the Ruby code examples. The second group was working on the application of SOLID to statically typed functional languages with the Scala code examples. The third group worked on the application of the SOLID principles to dynamic functional languages with the Clojure examples.

The results were ambiguous and we didn’t find final answers. What became clear is that the SOLID design principles can be applied to all these types of languages. What stayed fuzzy was the question if that application would be useful for the everyday work with these languages. While I tend to think that in fact not every principle is useful in every languages there were others having the opposite opinion.

One of the problems within the workshop was that today OO thinking is baked into out heads. And so the Scala and the Clojure group created designs in OO style. And if you do that with a functional language of course SOLID is applicable and at least to a certain degree useful 🙂

In the end of the session we had a discussion in a smaller group of people if it may be to misleading to apply SOLID to functional programming. Perhaps it drives our thinking in the wrong direction. Perhaps it would be better to go back to the underlying principles of cohesion and coupling and creating new design principles for functional languages on top of these. And perhaps such design principles already exist and I am just to blind to see them.

So: There is still a lot to learn and a lot of experiments to do. If you like to contribute I would really much appreciate it.

 

 

September 9, 2011 at 3:12 pm 2 comments

Lernen im dritten Quartal 2009

Damit habe ich mich im dritten Quartal 2009 beschäftigt:

  • Ich habe das Buch Subject to Change gelesen. Meine Eindrücke habe ich bereits im Blog beschrieben: Es geht darum, wie heute Produkte und Services entwickelt werden müssen. Das ganze passt wenig überraschend mit agilen Ansätzen wie Scrum ganz wunderbar zusammen.
  • Dann habe ich mich ziemlich intensiv mit Prolog beschäftigt und einige Beiträge in diesem Blog darüber veröffentlicht. Das war allemal horizonterweiternd – Prolog ist eben doch sehr anders als andere Programmiersprachen. Ich finde es nach wie vor Schade, dass Prolog heute ziemlich tot zu sein scheint und die Sprache nicht ernsthaft weiterentwickelt wird. Relektionen über Prolog.
  • In Prolog habe ich ann auch gleich ein kleines BDD-Framework gebaut und damit mein BDD-Verständnis verbessert.
  • Joseph Pelrine ist dafür verantwortlich, dass ich noch etwas über Teamdynamik gelernt habe: Hochproduktive Teams kochen.
  • Von einem Kunden habe ich mich belehren lassen, was die mögliche Produktivität verteilter Teams anbelangt.
  • Ein ganz kleines bisschen Perl habe ich gelernt. Und zumindest für kleine Skripte kann ich nicht erkennen, was an Perl schlecht sein soll.
  • In einem Projekt habe ich Selenium RC eingesetzt und den designierten Nachfolger Google Web-Driver.
  • Ich habe meine Rails-Kenntnisse deutlich vertieft. Dazu habe ich das Buch Rapid Web Development mit Ruby on Rails gelesen. Das ist nicht mehr ganz aktuell, aber ich hatte es ohnehin noch im Bücherregal stehen und für einen Überblick war es OK. Anschließend habe ich begonnen, eine echte (kleine) Anwendung in Rails zu programmieren und bin davon ganz angetan. Nur mit der Installtion unter Ubuntu hatte ich anfänglich einige Probleme.
  • Im Rails-Zusammenhang habe ich mich auch mit RSpec, Cucumber und Webrat beschäftigt. Auch das sieht für mich alles sehr schön und elegant aus. Das Oberflächentesten mit Webrat ist z.B. sehr schön einfach und schnell.
  • Bei einem Kunden habe ich mich etwas mit TestNG beschäftigt. Naja. Für TDD kann ich gegenüber JUnit keine Vorteile erkennen.
  • Ich habe mit dem Buch SOA in Praxis ein weiteres Buch aus dem Regal geholt, dass dort schon eine Weile stand. Mein Review dazu habe ich im Blog beschrieben. Das Buch war durchaus lohnenswert, auch wenn ich kein SOA-Fan bin.
  • Bei einem Kunden durfte ich erleben, wie Kanban in der Praxis eingesetzt wurde – zumindest anfänglich auch mit interessanten Schwierigkeiten.
  • Neben CSM-Kursen biete ich inzwischen auch CSPO-Kurse an. Bei der Vorbereitung des CSPO-Kurses habe ich viele Dinge über Product-Owner-Arbeit reflektiert und neu gelernt.
  • Und zum Beweis, dass ich noch nicht vollkommen Plem-Plem bin, habe ich auch etwas im Bereich außerhalb der IT gemacht. Ich habe beim Windsurfen Racejibe und Sinkerwende gelernt. OK, Racejibe geht bisher nur rechtsrum, aber das wird noch. Ich hoffe, auf einen milden und windreichen Jahresausklang.
  • Und dann habe ich mir von meinem kleinen Bruder zeigen lassen, wie Brustschwimmen und Kraulen richtig funktioniert. Und siehe da: Das einzige, was ich bisher richtig gemacht habe, dass ich eine Badehose anhatte. Immerhin erklärt es, warum ich so ein schlechter Schwimmer bin. Jetzt muss ich die richtige Technik “nur” noch üben.

Damit habe ich von dem, was ich mir für das dritte Quartal vorgenommen habe, fast alles geschafft. Nur Scala habe ich mir nicht angesehen. Ich fand es dann doch spannender einfach Rails zu programmieren und aus demselben Grund werde ich wahrscheinlich auch im vierten Quartal nicht dazu kommen, mir Scala anzusehen.

October 14, 2009 at 5:45 pm Leave a comment

Terminplaner in Prolog

Ich habe meine Prolog-Kenntnisse aufgefrischt und dazu das Terminplaner-Beispiel in Prolog implementiert. Die geringe Anzahl Lines of Code (LoC) der Prolog-Lösung finde ich ziemlich beeindruckend. Ich habe die Größe der Lösung in den verschiedenen Programmiersprachen mal gegenüber gestellt (LoC: ohne Leerzeichen und Kommentare).

Sprache LoC LoC Tests
Java 187 109
Groovy 155 79
Ruby 141 90
Lisp (CLOS) 63 77
Prolog 34 93

LoC ist sicher kein besonders gutes Maß, um die Mächtigkeit einer Programmiersprache zu bewerten. Wenn man allerdings nur 34 Zeilen braucht, wo man sonst 150-200 Zeilen braucht, finde ich das schon ziemlich denkanstößig.

Der Code steht unter github bereit: http://github.com/stefanroock/Terminplaner/tree/master (Achtung: Die Python-Lösung funktioniert noch nicht).

July 13, 2009 at 7:30 pm 5 comments

Terminplaner in Ruby

Ich habe den Terminplaner, den ich bereits in Java, Groovy und Common-Lisp programmiert habe, auch mal in Ruby programmiert. Die Line-of-Code habe ich für den Vergleich mal etwas professioneller ausgewertet. Hier das Ergebnis:

Sprache Anzahl Dateien Line of Code (ohne Kommentare)
Java 7 296
Groovy 7 230
Ruby 7 236
Common-Lisp 6 140

Die Ursachen dafür, dass die Lisp-Lösung so wenig Zeilen hat, habe ich hier bereits früher erklärt.

Die Lösungen in Groovy und Ruby sind erwartungsgemäß ungefähr gleich lang. Neben der Länge fallen aber noch viel mehr Ähnlichkeiten auf.

Folgender Code steht im Groovy-Beispiel:

public Collection getTermine(String besitzer, boolean zeigeAuchAbgelehnte) {
	return termine.inject([]) {result, termin ->
		termin.fuegeZuTerminlisteHinzu(result, besitzer, zeigeAuchAbgelehnte)
		result
	}
}

Im Ruby-Beispiel finden wir den entsprechenden Code:

def termine(besitzer, zeige_auch_abgelehnte)

	@termine.inject([]) { |result, termin|

		termin.fuege_zu_terminliste_hinzu(result, besitzer, zeige_auch_abgelehnte)
		result

	}.sort

end

Natürlich ist die Syntax unterschiedlich, aber diese Unterschiede halten sich durchaus in Grenzen. Die Syntax für Closures ist beispielsweise fast identisch und das API der Collections ebenfalls. Auf jeden Fall finde ich, dass Groovy und Ruby größere Ähnlichkeiten aufweisen als Groovy und Java – jedenfalls, wenn man in Groovy auch mit Groovy-Style programmiert.

Diese Medaille hat zwei Seiten: Der Umstieg von Java auf Groovy ist fast so schwer wie von Java auf Ruby. Wenn man allerdings Groovy oder Ruby beherrscht, ist der Umstieg auf die jeweils andere Sprache relativ einfach.

Den vollständigen Quellcode zum Beispiel kann man sich bei github herunterladen.

June 3, 2009 at 7:20 pm 4 comments

Ruby goes Lisp

Mit ParseTree kann man zur Laufzeit die Struktur eines Ruby-Programms analysieren. Das was da rauskommt sieht sehr nach Lisp-S-Expressions aus, was Grahams These stützt, die Programmiersprachen würden sich mit der Zeit immer mehr Lisp annähern. Dass mit ParseTree bei weitem nicht die Flexibilität von Lisp erreicht ist, kann man auf der ParseTree-Homepage lesen: Es funktioniert nicht für die Ruby-Core-Klassen und verändern bzw. generieren kann man so einen ParseTree wohl auch nicht. Dennoch wahrscheinlich eine sehr nützliche Geschichte.

December 28, 2006 at 6:18 pm Leave a comment

IDEs und der K(r)ampf zwischen Statik und Dynamik

Für Java existieren heute mit Eclipse, IntelliJ IDEA und Konsorten sehr mächtige Entwicklungsumgebungen. Cross-Referencing, Refactoring und Auto-Completion sind Features, die man nicht mehr missen möchte.
Dass diese Features für die aktuellen Skriptsprachen a la Python, Ruby oder Groovy nicht oder nur eingeschränkt existieren, wird häufig als Argument gegen diese Skriptsprachen verwendet.

Aber wird über diese Features wirklich reflektiert?

Cross-Referencing
Mit den Cross-Referencing-Möglichkeiten der IDE kann man auf Tastendruck oder Mausclick von einer Codestelle zum referenzierten Element gelangen (z.B. von einer Variablendeklaration zur Klasse, von deren Typ die Variable ist).

Natürlich sind die Cross-Referencing-Möglichkeiten in den IDEs deutlich mächtiger als eine Textsuche über Dateien. Aber ist der Unterschied wirklich so groß? Und ist die Textsuche häufig nicht sogar schneller?

Refactoring
Refactoring ist eine der großen Errungenschaften in der Neuzeit der Softwareentwicklung und ihr Automatisierungsgrad ist wirklich erstaunlich hoch. Aber welche automatisierten Refactorings nutzen wir überhaupt bei der täglichen Arbeit und wie häufig? Viele Entwickler verzichten sogar absichtlich auf bestimmte einfache Automatisierungen (z.B. “Introduce Variable”), weil sie von Hand schneller sind – die Mächtigkeit der IDEs führt bei großen Projekten leider dazu, dass die Arbeit mit ihnen mitunter doch etwas zäh wird.
Viele Refactorings kann man in der Tat mit vertretbarem Aufwand und Risiko auch von Hand durchführen. Einige andere (z.B. “Rename Class”) lassen sich auch auf anderem Wege automatisieren (Find&Replace über Dateien). Natürlich kann man sich dann oft nicht 100%ig sicher sein, dass alles korrekt geändert wurde. Man muss anschließend die Tests ausführen. Dass muss man in Java aber auch, weil es immer mehr untypisierte Referenzen in XML-Dateien (Struts, Spring, EJB etc.) gibt, die den IDEs auch mal durch die Lappen gehen.

Auto-Completion
Bei der automatischen Vervollständigung tippt man nur den Beginn eines Wortes ein und die IDE ergänzt die fehlenden Zeichen. Dadurch spart man Tippzeit, reduziert die Wahrscheinlichkeit von Tippfehlern und muss sich nur an den Anfang von Methodennamen erinnern.
Interessanterweise gibt es auch in programmiersprachen-unabhängigen Editoren wie Emacs oder JEdit Auto-Completion. Dabei werden viel einfachere Verfahren eingesetzt als in den Java-IDEs, die aber erstaunlich gute Ergebnisse liefern. Ein ganz einfacher Ansatz besteht z.B. darin, bei der Auto-Completion nur die Wörter zu berücksichtigen, die in der aktuellen Datei schon mal verwendet wurden. Etwas umfangreicher ist der Ansatz, die Wörter aller Dateien eines Projektes zu verwenden.
Ähnlich wie beim Cross-Referencing sind diese Auto-Completion-Features der Editoren qualitativ denen der IDEs unterlegen. Aber wie beim Refactoring sie sind schneller.

Und das ist ein Faktor, den man nicht unterschätzen sollte. Ich ertappe mich beim Java-Programmieren jedenfalls immer wieder dabei, dass ich Namen komplett manuell eintippe, weil ich damit schneller bin als die zäh reagierende Entwicklungsumgebung. Und wenn ich in einem einfachen Editor eine Skriptsprache programmiere, genieße ich es, dass der Editor immer sofort reagiert. Die IDEs sind nur Bruchteile von Sekunden langsamer, aber das reicht schon aus, um den Flow beim Programmieren zu beeinträchtigen.

August 24, 2006 at 4:16 pm Leave a comment

Ruby on Rails vs. ???

Zur Zeit ist Ruby on Rails in aller Munde. Von vielen wird es für die Technologie der Zukunft gehalten. Aber gegen wen ist Ruby on Rails eigentlich positioniert?

Ich bin kein Experte für Skriptsprachen a la PHP oder Perl, habe aber das Gefühl, dass Ruby on Rails gegenüber diesen Sprachen keinen wahnsinnig großen Fortschritt darstellt – klar ist die Sprache Ruby cooler, aber kann man dadurch seine Webanwendungen soviel schneller schreiben?

Bliebe als Konkurrent also Java. Dort dürfte Ruby on Rails nur für einen kleinen Teil der existierenden Java-Kunden interessant sein. Wer sich strategisch für Websphere als Application-Server entscheidet, kann dann schlecht wichtige Anwendungen in Ruby in einer anderen Ablaufumgebung entwickeln. Bleiben also die Kunden übrig, die heute Java-Projekte starten und die sich keine strategischen Gedanken über Transaktionsmonitore oder Application-Server machen.

Wenn sich allerdings Groovy und Grails als Java-Technologien verbreiten, ist das dann für die existierenden Java-Kunden nicht viel attraktiver als Ruby on Rails? Immerhin lassen sich ihre existierenden Projekte leicht mit Groovy integrieren.

Ich finde Ruby als Sprache cool und Ruby on Rails für eine bestimmte Art von Anwendungen auch. Allerdings befürchte ich, dass der Coolness-Faktor nicht ausreicht, um eine nennenswerte Verbreitung zu finden. Die allermeisten Entwickler suchen sich ihre Programmiersprache schließlich nicht selbst aus. Und Manager sind bekanntermaßen relativ immun gegen Coolness…

March 5, 2006 at 6:08 pm Leave a comment

Older Posts