29 Gedanken zu „CRE163 Ruby und Rails“

1. Dynamisch typisierte Sprachen fangen irgendwann immer an, Probleme bei größeren Projekten zu machen. Beim Refaktorisieren, wenn man beispielsweise eine Methode von einer Klasse in die andere verschieben will, dann kann man nur beten, dass man auch alle Stellen erwischt hat, die geändert werden müssen, oder dass man genügend Test-Coverage hat, um etwaige Fehler aufzudecken.

   Eine Sprache, welche viele der Vorteile von dynamisch typisierten Sprachen aufgreift, ohne die Vorteile der statischen Typisierung aufzugeben ist Scala.

   Es gibt einen sehr guten Vortrag von Bill Venners zu Scala, wo er diese Sachen auch anspricht:
   http://wiki.parleys.com/display/PARLEYS/Home#slide=28;talk=27131945;title=The%20Feel%20Of%20Scala

   (Achtung: Flash; Tipp: wenn er eine Demo vorführt kann man oben über das Icon „Player View“ die Ansicht umschalten, damit man sieht, was er da tippt)

   Scala ist übrigens sehr für parallele Programmierung geeignet, es hat das Actor-Model von Erlang übernommen. Der Fokus von Scala ist, wie der Name andeutet, Skalierbarkeit. Als Webframework gibt es Lift.

   Antworten ↓

2. Scala ist meiner Meinung nach zu kopflastig und eine kurze Syntax ist noch lange nicht lesbar und verständlich. Zudem ist Scala wohl noch auf längere Zeit nicht für den „Enterprise“ Einsatz geeignet (viele Änderungen, keine Rückwärtskompatibilität).

   Ich würde dann eher Groovy empfehlen, das integriert sich auch als einzige Lösung wirklich „seamless“ in Java (interessant ist sicherlich auch Clojure).

   Antworten ↓

3. Danke für den Podcast. Interessant wäre auch mal eine Sendung über Seaside, ein Smalltalk Web-Framework.

   Antworten ↓

4. Hihi, typischer Java-Kommentar (aber.. aber.. Refactoring!).
   Ein bisschen schade finde ich, dass Martin in dieser Episode etwas durcheinander wirkt und daher manchmal sehr unverständlich/unvollständig erklärt, vermutlich die Aufregung. Aber wüsste ich nicht, wie einfach, schnell und schön Rails-Entwicklung ist, wäre ich nun erstmal etwas abgeschreckt.
   Was mir insbesondere gefehlt hat (oder hab ich es überhört) war der Hinweis darauf, dass während der Entwicklung viele z.B. in der Java-Welt immer noch häufig notwendige Schritte (insbesondere Server-Neustart nach Änderungen in Views) entfallen, was eine Menge Frust und Wartezeit aus der Entwicklung nimmt.

   Manches hätte vielleicht einfacher mit Beispielen erklärt werden können:

   – Foreign Key? Ein Verweis einer Tabelle auf eine andere, z.B. könnte die Calendar Tabelle eine Spalte „user_id“ haben, die auf die „users“ Tabelle verweist. Rails weiß bei dieser Bezeichnungs-Konvention dann mit der „has_many :calendars“ Direktive im User Model automatisch, wie es für einen gegebenen „user“ über den Aufruf „user.calendars“ an die Liste der zum User gehörigen Kalender kommt.

   – REST in Rails? Mappt die CRUD (Create, Read, Update, Delete) Methoden für ein Model (allgemein Ressource genannt) auf die HTTP-Methoden POST, GET, PUT und DELETE. Macht Rails quasi automatisch indem es die folgenden URLs anlegt:
   POST /users –> controller „users“, methode „create“
   GET /users –> controller „users“, methode „index“
   GET /users/:id –> controller „users“, methode „show“
   PUT /users/:id –> controller „users“, methode „update“
   DELETE /users/:id –> controller „users“, methode „destroy“

   Zugegeben, das ist textuell einfacher erklärt, als übers Micro…

   Eine ganz wichtige Ressource für den Einstieg und die Vertiefung fehlte: http://guides.rubyonrails.org/

   BDD (Behavior Driven Development) – z.B. mit Cucumber – wäre übrigens fast schon mal einen eigenen CRE wert.

   Antworten ↓

5. @Lars Fischer

   Programmieren ist nunmal kopflastig, und mit einer flexibleren Sprache kann man nun mal für den „Anwender“ einfachere APIs gestalten.

   http://michid.wordpress.com/2010/08/24/so-scala-is-too-complex/
   http://lamp.epfl.ch/~odersky/blogs/isscalacomplex.html

   Mit Groovy arbeite ich selber, und es hat eben genau all die Nachteile der dynamischen Sprachen, die mich derzeit zu Scala treiben.

   Dass sich die Sprachen zu viel ändern um wirklich Enterprise-tauglich zu sein stimmt, aber da geben sich Python, Ruby, Groovy, Clojure leider auch nichts.

   Antworten ↓

6. @f8 „enterprise-tauglich“… als nächstes kommt „skalieren nicht“.

   Unternehmen (ja, wirklich!) wie Xing (angefangen mit dem Marketplace) oder betterplace.org entwickeln in Rails (und bedienen nebenbei auch noch große Schnittstellen). Mit agilen Methoden wie Scrum kann man sich dabei auch ganz „enterprisy“ und wichtig fühlen. Was zur Hölle ist überhaupt „enterprise-tauglich“?! Das ist ein Buzzword von konservativen IT-Leuten mit dem sie sich vor neuen Technologien abschotten und ihr Gehaltslevel zu halten versuchen, ohne sich weiterbilden zu müssen.

   Groovy ist auch nur ein weiteres Beispiel, wie versucht wird die Rails Prinzipien in andere Sprachen/Frameworks zu integrieren. Ich kenne Groovy nicht genau, bisherige Implementierungen (u.a. in PHP) waren aber kaum mehr als schlechte Scherze. Abgesehen davon, dass die Vorteile der Sprache Ruby fehlen, sind Grundprinzipien wie REST nicht verstanden oder fehlerhaft umgesetzt worden.

   Nenn mich Fanboi, aber mit Ruby und Rails macht auch mir – wie Martin schön sagte – das Entwickeln wieder richtig Spaß.

   Antworten ↓

7. Angenehme Stimme

   Antworten ↓

8. Schade. Ich hatte immer gehofft, dass es eine Folge zu ruby (ich betone extra zu ruby, nicht erschöpfend zu rails. Das Thema ist nämlich totgequatscht) geben wird und als sie endlich da ist, wird sie durch den gewählten Interviewpartner wirklich heruntergezogen.
   Da lag fachlich einfach vieles im Argen.

   Ich kann mich den Punkten des Artikels „Ruby im Chaos“ auf der Ruby-Mine nur voll und ganz anschließen. Diese jetzt noch einmal aufzuzählen wäre redundant, deshalb verlinke ich den Blogeintrag:

   http://www.ruby-mine.de/2010/10/2/ruby-im-chaos

   Antworten ↓

9. Ohje, kein Höhepunkt. Ganz toll auch der Teil mit TDD, BDD, DSLs und dem Testing.

   Antworten ↓

10. @mru danke für den Link, wirklich gut auseinandergenommen.

    Rails hat Ruby halt zu einem Großteil seiner Popularität verholfen, ich kann den Focus schon ein wenig verstehen. Auch denke ich nicht – gerade mit den neusten Entwicklungen in Version 3 – dass Rails totgequatscht ist. Erst recht nicht in Anbetracht der Scharen an „das ist nicht enterprise-ready“-Schreiern, die einem immer wieder begegnen.

    Antworten ↓

11. Wirklich seltsam ist, dass glaube ich noch keiner deiner Gäste eine wirklich gute Erklärung von closures hinbekommen hat.

    Antworten ↓

12. Trotz interessantem Thema leider eine sehr enttäuschende Sendung.

    Martin wirkt nicht besonders gut vorbereitet und es kam doch recht häufig zu „ähhm, das weiß ich jetzt nicht“ bei Fragen, die schon wichtig gewesen wären.
    Oft wirkten die Ausführungen auch zusammenhanglos. Ich habe wirklich den „Roten Faden“ vermisst.

    Was mich auch gestört hat, war, dass wenig Bezug zu anderen Sprachen hergestellt wurde. Oft wurden Dinge wie z.B. MVC oder ORM so erwähnt, als ob Rails das einzige Framework sei, das diese Dinge beherrscht, obwohl ja inzwischen die meisten populären Sprachen Frameworks mit diesen Features haben. Das erzeugt einen gewissen Ruby-Fanboy Eindruck.

    Schön wäre auch Dinge gewesen wie „Wenn du das und das bisher in so gemacht hast, funtioniert das in Ruby so und so …“.

    Ich hatte bisher wenig mit Ruby/Rails zu tun, aber nach der Sendung hat das Interesse, damit mal ein wenig herumzuspielen ziemlich abgenommen.

    Insgesamt fand ich die früheren Sendungen, die sich mit Programmiersprachen befasst haben, deutlich besser. z.B. die Folge über Java (und das obwohl ich Java nicht sonderlich mag…). Vor allem waren sie weniger einseitig.

    Antworten ↓

13. Für mich kam auch wenig von der sexyness von Ruby und Rails rüber und in der mitte irgendwo dachte ich, zum ersten mal bei einem CRE, das es sich ganz schön zieht.

    Antworten ↓

14. Interessantes Thema, aber es fehlte der distanzierte Überblick. Zu oft wurde auf Details eingegangen, ohne zuvor den Rahmen zu erklären. Als Django-User kannte ich die Konzepte und konnte es dadurch einigermaßen verstehen. Aber jemand der MVC-Webframeworks nur vom HörenSagen kennt, bekam hier wahrscheinlich auch keinen Überblick. Auch wenn Tim sich redlich bemüht hat den Schaden in Grenzen zu halten – eigentlich kam alles was zum Verständis beigetragen hatte von Tim ;( Schade.

    Antworten ↓

15. feine sendung. ich hatte bisher nichts mit ruby zu tun, hatte es mir aber vorgenommen. nach dieser sendung werde ich, wenn ich dann auch noch die zeit dafür finde, mal reinschnuppern. *thumbsup*

    Antworten ↓

16. Zur Sendung:

    Ich finde das Thema auch schon bisschen abgequatscht (wenn man sich mit programmieren beschäftigt) aber durchaus ok weil sich ja CRE auch leute anschauen die sich jetzt nicht extrem of mit Programmiersprachen beschäftigen.

    Ich als Ruby fremder bin nach den podcast nicht wirklich versucht rails zu probieren. Einiges wurde schlecht erklährt und zu kompliziert dargestellt z.B. die each funktion mit MapReduce zu erklähren. Das geht gar nicht da map und each eigentlich das gleiche sind.

    Allgemein:

    Ich finde man sollte nicht zwei Themen mischen. CRE078 Zope und Plone konnte man auch verstehen ohne Python zu verstehen.

    Eine Sprach gut anzuschaun braucht schon eine ganze Sendung und ein grosses Framework auch.

    @f8
    Es wurde schon mehrfach bewiesen das man sehr erfolgreich grosse Projekte mit dynamischen Sprachen machen kann. Dein beitrag kommt sehr Scala-Fanboy mässig daher.

    @f8 nr 2.

    Es ändert sich zu viel bei dynamischen Sprachen? Wie ist das jetzt bei Scala mit der 2.8er? Abwärtskompatible?

    @ch

    Ich glaube bei JS wars nicht schlecht aber find ich wirklich verwunderlich. Ist Meiner meinung nach das wichtigste überhaubt. Eine Sprache ohne Closures kann ich kaum mehr verwenden.

    Mein Tipp für eine Weitere Sendung wäre:
    Funktional Programmieren (Sollte jemand zu finden sein der sich mit (fast) allen arten von FP auskennt)
    Ruby war for ein paar Jahren der grosse Hype. Jetzt ist es FP da sollte man schon ne Sendung zu machen. Gibt ja jetzt auch die ganzen neuen FP Sprachen F#, Clojure und (je nach standpunkt) Scala.

    Antworten ↓

17. Nee wirklich nicht. Martin hat sich stets bemüht. Aber das reicht leider nicht. Er kann Konzepte nicht erklären, verliert sich in Details, kann nicht begeistern. Closures total falsch (Tim besser) und was Map/Reduce macht empfehle ich beiden nochmal nachzulesen. Kein Wort über Grails / Groovy und dass man dort keine neuen Libs von 0 lernen muss. Und ORM heisst nicht Object Rational Mapper. Paradigm Mismatch. Ich beantrage Wiederholung mit hukl.

    Antworten ↓

18. schade, gerade von dem Thema hatte ich mir viel mehr Erwartet.

    Martin klingt verwirrt, bringt technische Details durcheinander und kann – was mich an diesem CRE besonders stört – keinerlei Beigeisterung für Rails rüberbringen.

    Antworten ↓

19. Für mich kommt der Podcast genau zur richtigen Zeit, er hat mir wichtige Anstöße für mein Referat gegeben, das ich demnächst in der Schule halte…

    Antworten ↓

20. Warum Ruby on Rails jetzt doch enterprise-ready ist, konnte er aber auch nicht erklären.

    Antworten ↓

21. Ja, schade. Hatte mich auch gefreut und kann die allgemeine enttäuschung leider nur teilen.
    Als ich den Titel las, war ich sicher dass du Hukl verpflichtet hast und beantrage ebenfalls eine wiederholung mit hukl. am
    besten mit nem java fan boy der groovy und grails im vergleich anpreist.
    das würde schwung in die sendung bringen und mich endlich dazu bringen mir endlich einen flattr account zu zu legen.

    marcus

    Antworten ↓

22. Schade, hätte so ein tolles Thema werden können.
    Voll zerfasert das ganze, da hätte es eine Reihe besserer Gäste gegeben, wie z.B. die Leute vom CouchDB Podcast oder Soup.io.
    Ich flattr Dich trotzdem, aber quasi mehr so im Voraus, ok? ;)

    Antworten ↓

23. Leider kann ich mich der allgemeinen Meinung hier nur anschließen; begeistert habe ich angefangen diesen CRE zu hören, musste aber mehrfach unterbrechen (was sonst eigentlich nie nötig ist), weil ich nicht allen Erklärungen so zugestimmt hätte bzw mir teilweise mehr Tiefgang gewünscht hätte. Das mag allerdings auch mit daran liegen, dass ich selbst seit vielen Jahren tief im Thema Ruby/Rails stecke und vielleicht recht hohe Erwartungen hatte. Insgesamt habe ich aber auch den roten Faden vermisst und es gab auch einige Aussagen/Erklärungen, denen ich so nicht zustimmen würde.

    Ich flattr aber ebenfalls trotzdem; für Einsteiger ist es ein guter Überblick quer durch die Rails-Welt.

    Antworten ↓

24. Zum Thema installierbare Rails-Software:
    Als Blog-Software möchte ich mal Typo (ohne 3) nennen.
    Ein Projektmanagementsystem in Rails ist Redmine.

    Antworten ↓

25. @Tim: auch ich hatte zum Thema Abstraktion von der Datenbankebene instinktiv erwartet, dass es eine Möglichkeit gibt, die Models automatisiert in ein Datenbankschema zu übertragen. Django macht das genau auf diese Weise. Das will man definitiv haben.

    Deine Erklärung von Closures war schon in Ordnung so – vielleicht gibt es da ja Begriffsunterschiede in der Ruby Welt, aber deine Auffassung deckt sich mit meinem bisherigen Weltbild von Closures.

    Zur Sendung: Martin hat sich gerne in Details festgebissen, zu welchen der Zusammenhang fehlte. Das möchte ich ihm gar nicht persönlich vorwerfen oder als fehlende Kompetenz beim Thema auslegen. Er hat einfach kein so gutes Händchen beim Erklären, was natürlich schade ist bei einem Podcast.

    Antworten ↓

26. Hast du deinen Gesprächspartner zu diesem Podcast gezwungen? :-)

    Antworten ↓

27. Ich hatte mich sehr auf das Thema gefreut. IMHO ist der Gesprächspartner aber flasch gewählt. Ich weiß bis jetzt nicht was ein Closure genau sein soll. Sehr schade.

    Antworten ↓

28. Traurig, dass zum Thema Nebenläufigkeit weder hier noch in der Python/Pypy Folge der Global Interpreter Lock angesprochen wurde.

    Antworten ↓

29. Das war der letzte Beitrag über eine Programmiersprache hier über Ruby, 2010. Gerade diese Beiträge über Sprachen fand ich immer wieder gut als Einstieg, sich mit der jeweiligen etwas näher vertraut zu machen.
    Mittlerweile gibt es neue spannende Sprachen, so Scala und Julia, die in Verbindung mit BigData immer mehr Bedeutung gewinnen. Scala als Implementierungssprache für Apache Spark, Julia als schnelle LLVM-basierte Alternative des Data Scientist für Python.
    Ggf. hätte ich auch Namen von Leuten, die sich zumindest mit Scala recht vertraut gemacht haben, für Julia vielleicht auch.

    Ebenso ist R in aller Munde, wäre vielleicht auch ein interessantes Thema? Oder auch ganz allgemein Data Science?

    Antworten ↓

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.