Webapplikation: Shop in welcher Sprache/Framework?

[Fallen][Angel]

Dem Hörensagen nach soll RoR nicht gerade gut Skalieren.

Das haben einige aufgezeigt. z.b.:
http://wiki.rubyonrails.com/rails/pages ... erformance
Hatten wir hier diskutiert: http://www.python-forum.de/topic-10152.html

EDIT: Noch ein alter Artikel gefunden:
http://www.alrond.com/en/2007/jan/25/pe ... rameworks/

Vielleicht auch noch interessant: "A Rails/Django Comparison": http://docs.google.com/View?docid=dcn8282p_1hg4sr9

Ich hab mir einige davon, werd mich jedoch noch alle, einmal ansehen. Jedoch muss ich sagen, dass nun absolute Geschwindigkeit bei mir nicht primär im Vordergrund steht, jedoch es ist gut sowas mal zu sehen.

Mir kommts aber eher auf die Sprache und ihre Qualitäten als solche an.

[Leonidas]

Ansonsten wird oft gesagt, dass django noch sehr in der Entwicklung sei und man häufig immer nur mit der svn-Version arbeiten muss, was zur folge hat, dass man oft irgendwelchen Änderungen am Framework unterlegen ist. Hacks für Bugs sollen angeblich auch öfters nötig sein.

Naja, manchmal trifft man durchaus auf Bugs, aber wir wollen nicht übertreiben - das passiert nicht so oft. Es sind eher Designentscheidungen, die einen stören. Die wird es in RoR wohl auch geben.

Was die SVN-Version angeht: stimmt, wenn du neue Features verwenden willst, dann solltest du die SVN-Version einsetzen. Aber meiner Erfahrung nach ist die durchaus für den Produktiven Gebrauch nutzbar, da die Releases recht alt sind. Wenn aber etwas eingeführt wird, was alten Code bricht, dann wird das dokumentiert - da gibt es eine Wiki-Seite zu dem Thema. Ist in meinen Augen eigentlich kein Problem.

[Y0Gi]

`self` bei Python ist ähnlich dem `end` bei Ruby - mit dem Unterschied, das ersteres keine eigene Zeile verschwendet `end` mag ich nicht, doch wenn ich das so lese und bedenke, dass ich mich an `self` gewöhnt habe, dann ist das sicherlich zu verschmerzen und mit Disziplin eine Frage der Gewohnheit, was umgekehrt wieder für Pythons Whitespace-Awareness gelten dürfte.

`self` gibt es wegen "explicit is better than implicit". Der Name ist dabei völlig egal und `self` nur Konvention. Tatsache ist, dass alle Objektmethoden es als erstes Argument erhalten (Klassenmethoden erhalten stattdessen eine Referenz auf die Klasse, statische Methoden keins von beiden).

Man sollte durchaus zwischen Sprache und Framework unterscheiden. So mag ich Python sehr, aber Django fast gar nicht (leider gibt es keine brauchbare Alternative an vorgefertigten Full-Stack-Frameworks, was für mich jedoch egal ist). In der Ruby-Liga gibt es ebenso welche, die Ruby lieben, aber statt Rails lieber auf andere (oder keine, es gibt ja noch mehr Anwendungsgebiete als das Web) Pakete wie Nitro oder Camping(?) setzen. Gerade durch den RoR-Hype werden Framework und Sprache aber sehr oft in einen Topf geworfen und synonym verwendet.


P.S.: Über drastische Probleme beim Rails-Deployment bei großen und kleinen Setups habe ich zuletzt auch zahlreiche Artikel abgeklappert. Offenbar sind Mongrel und auch das (frühere) Rails-eigene Deployment (iirc?) für Speicherlecks anfällig. Es mag in der Praxis funktionieren, aber mir ist keineswegs wohl dabei, einen Cronjob zu haben, der ein, zweimal am Tag (spätestens) FastCGI-Prozesse abschießt.

[Fallen][Angel]

Es mag in der Praxis funktionieren, aber mir ist keineswegs wohl dabei, einen Cronjob zu haben, der ein, zweimal am Tag (spätestens) FastCGI-Prozesse abschießt.

Quellen dafür?

Also alles im allen muss ich sagen: PHP ist derzeit wohl das Schlusslicht bei meiner Auswahl - wundert mich jedoch nicht wirklich

Nun kommt es zu Platz 1 und 2 und genau hier liegt das Problem: Im Endeffekt arbeiten beide Sprachen sehr solide und die Frameworks dazu verrichten ihren Dienst ebenso erfolgreich. Oft hängt es dann wohl an Kleinigkeiten, je nachdem, wie man seinen Fokus legt: Geschwindigkeit, Syntax der Sprache, gewisse Features, etc.

An RoR stört mich z.B., dass es keine wirkliche Möglichkeit für Mehrsprachigkeit gibt und sowas würde ich eigentlich von einem guten Framework erwarten. Dagegen scheint die Einbindung von Foreign-Keys in Django umständlicher als in RoR, wo einem das Framework eigentlich alles abnimmt.

Daher bin ich (noch immer) leicht unentschlossen, wer nun auf Platz 1 meiner Vorlieben darf und wer auf Platz 2

[BlackJack]

@Fallen][Angel: Also ich mag Ruby nicht. Das "fühlt" sich für mich sehr anders an als Python. Und ich glaube das geht nicht nur mir so, und gilt mit umgekehrten Vorzeichen auch für viele(?) Ruby-Programmierer. Also ist wohl die persönliche Vorliebe hier nicht ganz unwichtig. Wenn Dir sonst keine wichtigen Entscheidungskriterien mehr bleiben, dann würde ich an Deiner Stelle einfach mal ein kleines Testprojekt in beiden Sprachen implementieren und schauen welche Sprache (+Webframework) Deiner "Denke" eher entgegen kommt.

[Fallen][Angel]

@Fallen][Angel: Also ich mag Ruby nicht. Das "fühlt" sich für mich sehr anders an als Python. Und ich glaube das geht nicht nur mir so, und gilt mit umgekehrten Vorzeichen auch für viele(?) Ruby-Programmierer. Also ist wohl die persönliche Vorliebe hier nicht ganz unwichtig. Wenn Dir sonst keine wichtigen Entscheidungskriterien mehr bleiben, dann würde ich an Deiner Stelle einfach mal ein kleines Testprojekt in beiden Sprachen implementieren und schauen welche Sprache (+Webframework) Deiner "Denke" eher entgegen kommt.

Darauf wird es vermutlich auch hinauslaufen. Ich habe mich schonmal nach guten Lernquellen umgesehen und bin am Pythonbuch von Galileo-Computing hängen geblieben.

Gibt es netterweise als OpenBook, wodurch ich es mir kostenlos ansehen kann.

[BlackJack]

@Fallen][Angel: Iiih da bist Du dann gleich an einem schlechten Buch hängen geblieben. Daraus wirst Du kein idiomatisches Python lernen können, sondern eines wie ein C++- oder Java-Programmierer Python schreiben würde, ohne sich damit wirklich auseinander gesetzt zu haben.

Für den Einstieg ist das Tutorial in der Python-Dokumentation eine ganz nette Tour durch die Sprache. Ein anderer guter, freier Text für Leute mit schon etwas Programmiererfahrung ist "Dive Into Python".

[veers]

Gratulation: Du hast das wohl schlechteste Buch über Python entdeckt!
An deiner Stelle würde ich mir eine andere Lektüre wie "Diving into Python" suchen

[Fallen][Angel]

Oha, hätte ich nicht gedacht, dass das Buch so schlimm ist Sah auf den ersten Blick eigentlich recht solide aus.

Ansonsten noch irgendwelche Tipps, wo es nette und gute Lektüre gibt, welche sich einsteigerfreundlich verhält?

[gerold]

Ansonsten noch irgendwelche Tipps, wo es nette und gute Lektüre gibt, welche sich einsteigerfreundlich verhält?

Hallo FA!

http://halvar.at/python/einstieg_in_python/

[jens]

Dagegen scheint die Einbindung von Foreign-Keys in Django umständlicher als in RoR, wo einem das Framework eigentlich alles abnimmt.

Hm? Kannst du das ein wenig mehr ausführen?

[Fallen][Angel]

Dagegen scheint die Einbindung von Foreign-Keys in Django umständlicher als in RoR, wo einem das Framework eigentlich alles abnimmt.

Hm? Kannst du das ein wenig mehr ausführen?

Code: Alles auswählen

class ReadingOccasion(models.Model):
    reader = models.ForeignKey(Reader)
    book = models.ForeignKey(Book, edit_inline=models.STACKED,
        num_in_admin=1)

Code: Alles auswählen

class Reading < ActiveRecord::Base
  belongs_to :book
  belongs_to :reader
end

Da muss ich zugeben, dass ich RoR von seiner Konfiguration irgendwie schlanker und übersichtlicher wirkt.

Abnehmen tun beide Framework wohl die gleiche Arbeit, war vielleicht falsch formuliert. Es bleibt aber, dass ich finde, das Python da für den gleichen Effekt etwas mehr tippen verlangt

[Leonidas]

Eher:

Code: Alles auswählen

class Reading(models.Model):
    reader = models.ForeignKey(Reader)
    book = models.ForeignKey(Book)

Das es in deinem Beispiel länger ist, liegt daran, dass du da Sachen für den Django Admin konfigurierst. Was RoR ja nicht hat, also für einen fairen Vergleich musst du das wegnehmen. Und die Klassen in Django drei mal länger zu nennen als in Rails ist natürlich auch nicht so toll zum Vergleich.

[Fallen][Angel]

Okay, dass das für den Admin war, wusste ich so noch nicht direkt. Soll dann nicht zu Lasten von Django gehen

Wenn man es so aber runterkürzt sieht es schon kürzer aus

Grundsätzlich sieht das von RoR auch einfach "schlanker" aus, weil ich das schon kenne.

[jens]

Es kommt auch darauf an, wie man den import gestaltet.

Die alte Variante:

Code: Alles auswählen

from django.db import models

class Reading(models.Model):
    reader = models.ForeignKey(Reader)
    book = models.ForeignKey(Book)

So müßte es aber auch gehen:

Code: Alles auswählen

from django.db.models import Model, ForeignKey

class Reading(Model):
    reader = ForeignKey(Reader)
    book = ForeignKey(Book)

Ich mache das aber auch nach der ersten Variante.

Wie sehen denn bei Ruby die imports aus? Also woher kommt "belongs_to"?

[Fallen][Angel]

In RoR kommt dies automatisch durch "ActiveRecord::Base". Um alles weitere kümmert sich RoR dann selbst.

[jens]

Da bleibe ich lieber bei:

Explicit is better than implicit.

Siehe auch: http://www.python.org/dev/peps/pep-0020/

[Leonidas]

Mit etwas Metamagie ließe sich das eine Funktion ``belongs_to`` auch in Django machen. Aber das wiederspricht eigentlich der Philosophie von Python, wo eine explizite Zuweisung besser ist, als Magie die unter der Haube funktioniert.

[Y0Gi]

Es mag in der Praxis funktionieren, aber mir ist keineswegs wohl dabei, einen Cronjob zu haben, der ein, zweimal am Tag (spätestens) FastCGI-Prozesse abschießt.

Quellen dafür?

Einiges kommt aus persönlichem Kontakt, andere Belege finden sich z.B. in diesen beiden, ja, Rants:

Rails Is A Ghetto (Abschnitt "How’d This Happen?", ~sechster Absatz)

The main Rails application that DHH created required restarting _400 times/day. That’s a production application that can’t stay up for more than 4 minutes on average.

How Ruby on Rails Could Be Much Better

[lunar]

Es gibt auch einen Vortrag vom 24c3, in dem einige Dinge über RoR Sicherheit gesagt werden.

Vieles davon ist gewöhnlich (CSS- und CSRF-Attacken, SQL Injection, etc), aber am Schluss kommt der Mensch auch auf DoS-Angriffe auf RoR Seiten zu sprechen.

RoR ist offenbar nicht multithreaded, nutzt also für jeden Request einen separaten Prozess. Offenbar ist die Anzahl der Handler-Prozesse allerdings limitiert, auf ~8 Prozesse pro CPU. Die Konsequenz dessen ist, dass ein aufwändiger Request-Handler-Code (der Vortrag nennt u.a. Bildbearbeitung, Mass Mailing und Up-/Downloads als Beispiele) die Zahl der Handler-Prozesse effektiv reduziert. Auf diese Weise kann man Rails-Seiten über massenhafte Requests anscheinend relativ leicht lahmlegen.

Ich habe keine Ahnung, ob das nun in der Realität wirklich so einfach ist, aber allein die Tatsache, dass die Anzahl der Handler-Prozesse limitiert ist, widerspricht der Aussage "Rails skaliere gut" ein bisschen