Login
Newsletter
Werbung

Thema: Pro-Linux: Workshop Ruby on Rails, Teil 1: Einführung

61 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von MichaelK am Mo, 30. Juli 2007 um 02:42 #
Hallo,

wie sieht es bei Rails-Anwendungen mit der Geschwindigkeit aus? mod_ruby soll ja bei Apache2 noch nicht so gut laufen. Und einen (offiziellen) Bytecode-Compiler/Interpreter gibts ja auch erst im Ende des Jahres mit Ruby 1.9.
Da fragt sich, ob PHP (erks; nein wohl nicht wirklich; zu unsauber), Python (schon besser; und mit Bytecode), ASP.NET (hm .... so ziemlich Windows-only; also auch nicht das Gelbe vom Ei) oder nicht gar Java (Servlets, JSP und der ganze Kram) nicht schneller/besser sind? Ok. Kommt natürlich auf die Anwendung an. Mit Skriptsprachen a-la Ruby, Python usw. lässt sich meist schneller entwickeln. Aber auch für die Java-Plattform sind ja die Skriptsprachen (a-la Groovy usw.) groß im Kommen.

Optimal für die Geschwindigkeit wäre wahrscheinlich, wenn man seine Anwendung direkt als ASM oder C-Code in den Apache-Quell-Code (oder besser noch ein Kernel-Webserver wie Tux) reinpatcht. :-)

Gruß
MichaelK

[
| Versenden | Drucken ]
  • 0
    Von Liberator am Mo, 30. Juli 2007 um 05:53 #
    Ruby ist in der Tat recht langsam - aber zumindest Groovy (= Java-Skriptsprache, mit "Grails" als "Rails"-Alternative) ist das ebenfalls. In beiden Fällen wird versucht, die Performance mit allen möglichen Tricksereien auf ein erträgliches Maß hochzuschrauben, aber die grossen Erfolge lassen (noch) auf sich warten... insofern sind PHP (und ggf. Python) im Moment durchaus nicht die schlechtesten Alternativen.

    Das mit dem "schnelleren Entwickeln" ist so eine Sache: Ruby ist zwar eine sehr produktive Sprache, mit der Programmieren auch (wieder) richtig Spass machen kann, aber wer denkt dabei an die Wartungsprobleme, wenn es darum geht, (irgendwann ;-) ) einmal auf eine neue Ruby-Version zu updaten? Was Up- und Downgrades angeht, ist Python deutlich verlässlicher, und wird (im Unterschied zu Ruby) auch von den meisten Webhostern direkt angeboten. (Bei Python bekommt man wiederum Wartungsprobleme, sobald man nativ compilierte Module verwenden will...)

    Insofern wird man bei Anwendungen, die man nicht alleine betreut, tatsächlich eher auf PHP (produktiv) und "reines" Java (eher weniger produktiv, aber mit extremer API-Komplexität) zurückgreifen. Evtl. noch auf Python oder Perl, und (leider) auch oft auf ASP.NET...

    Es ist wirklich schade, dass der praktische Einsatz ("Deployment") von Ruby so problematisch ist... wobei man wartungsmäßig vermutlich noch ganz gut wegkommt, wenn man für Ruby einen eigenen Debian-Rootserver anmieten kann. Ist aber auch eine Kostenfrage: Rootserver sind in der Regel teurer als reines Webhosting, und für manche Anwendung lohnt sich der (finanzielle) Aufwand nicht.

    Wobei andererseits die "Nische" von "Ruby on Rails" beschrieben ist: im "Intranet", also auf einem Server im LAN, für spezielle interne Anwendungen, die sich mit RoR recht einfach und vor allem schnell programmieren lassen. (Aber selbst dann stellt sich die Frage, ob es die entsprechende Anwendung nicht bereits als Freie Software gibt, meist auf PHP-Basis, und eine Anpassung vorhandener Software nicht trotzdem besser sein könnte als eine Neuentwicklung mit "Ruby on Rails".)

    Letztendlich kann man nur hoffen, dass aus der ganzen Sprachauswahl-Problematik (unter Linux) nicht in der praktischen Nutzung ASP.NET (unter Windows) als heimlicher Sieger hervorgehen wird, weil man dort (zumindest im Prinzip) inzwischen alle der oben genannten Sprachen auf VM-Basis (CLR) miteinander koppeln kann... sich aber gleichzeitig (was Patente und Lizenzen angeht) sehr eng an Microsoft bindet...

    [
    | Versenden | Drucken ]
    • 0
      Von me am Mo, 30. Juli 2007 um 15:47 #
      Soweit ich das in letzter Zeit sehe, bewegen sich immer mehr Leute weg von Lighttpd, da die Proxy-Module anscheinend unter großer Last einige Fehler haben und Apache in der Version 2.2 hier eine gute Alternative darstellt. Eine andere Alternative fürs Load-Balancing ist Pound (http://www.apsis.ch/pound/). Dahinter setzt man momentan eigentlich immer Mongrel als Rails-Server ein.

      Ich denke Python sollte man nicht zu sehr loben: Wer einmal längere Zeit TRAC oder andere Python-basierte Software administriert hat wird sicher auch seinen Spaß gehabt haben, die ständigen Abhängigkeiten von bestimmten Python-Versionen die dann eben nicht jener in der eigenen Distribution entsprechen sind auch nicht gerade schön. Da ist PHP schon angenehmer, mit Version 5 läuft fast alles (wobei man sich da wünschen könnte, sie würden mal mit der Abwärtskompatibilität brechen und die Sprache aufräumen).

      Der große Vorteil von Rails ist eben die schnelle und elegante Entwicklung, wofür man das Framework aber eben auch recht gut kennen sollte. Gleich loslegen wie mit PHP ist da eben schwieriger.

      Ich denke der Kostennachteil eines virtuellen/dedizierten Servers ist relativ zu sehen, wenn ein Projekt so große Last erzeugt, dass die Perfomance von Rails relevant wird, dann sollte man auch die paar Euro mehr über haben ;)

      [
      | Versenden | Drucken ]
      mehr PHP
      0
      Von MichaelK am Mo, 30. Juli 2007 um 16:27 #
      Hallo,

      die einzigen "Vorteile" von PHP sind, dass es viele Webhoster anbieten und es bereits viele PHP-Projekte gibt, auf die man aufbauen kann. Dem gegenüber stehen aber eine Reihe von Nachteilen.

      So fällt PHP immer wieder durch Sicherheitslücken auf. Ein vernünftiges Sicherheitskonzept fehlt im Gegensatz zu Java oder auch Ruby. Man muss sich also teilweise mit externen Lösungen behelfen die wiederum man beim normalen Webhoster nicht einfach installieren kann.
      Zudem gibt es, man höre und staune, immer noch PHP-Apllikationen die ein register_globals=on verlangen.
      Zugegeben: Sowas wie eval gibts auch in Ruby. Allerdings ist man darauf bei Ruby praktisch nicht angewiesen.

      Man merkt bei PHP deutlich, dass es gewachsen ist. Die API ist ... nunja ... Konsistanz ist was anders. Beispielsweise:
      strpos($string, $gesuchtesWort)
      aber in_array($gesuchtesElement, $array) ???
      Oder auch sort() ändert das übergebene Array aber array_reverse() gibt das bearbeitete Array zurück???

      PHP ist auf den Einsatz als "Websprache" begrenzt. Das gilt nicht mehr ganz so wie früher. Aber es war halt ursprünglich für nichts anderes vorgesehen. Dementsprechend merkt man das der Sprache auch an.

      PHP wird interpretiert. Bei Java wird immerhin ein Zwischencode (Bytecode) erzeugt, was für die Geschwindigkeit einiges bringt. Wenngleich man mit eAccelerator versucht diesen Mangel zu beheben.

      Keine Objektorientierung. Jetzt werden die ganzen PHP-Verfechter aufschreien, dass dass PHP doch schon lange kann. Sicher. Aber was nützt mir das, wenn die vorhanden Bibliotheken eben noch nicht objektorientiert sind? Mit PHP5 hat sich da einiges gebessert. Aber von Ruby oder Java ist das alles noch meilenweit entfernt (selbst Java hat da so seine Einschränkungen; z.B. gibt es [historisch aus Geschwindigkeitsgründen bedingt] primitive Variablen-Typen die eben nicht objektorientiert sind).

      PHP und Unicode? Naja. Nicht wirklich.

      Namespaces? Auch nicht.

      Variablendeklaration wie z.B. in Java? Leider nein. Viele mögen sagen zum Glück. Aber spätestens wenn sie mal lange einen Fehler suchen der eigentlich nur aufgrund eines Vertippers entstand, wünscht man sich die sonst so lästigen Variablendeklarationen.
      Bei Ruby muss man leider Variablen auch nicht deklarieren. Allerdings ist der Typ zu jeder Zeit klar, während es bei PHP von den Umständen abhängig ist. "Von den Umständen abhängig" klingt schwammig und so ist das dann auch in der Realität.

      Noch ein Wort zu ASP.NET. Ich sehe bei dem ganzen .NET-Kram eher Nachteile als Vorteile. Nicht nur das es Windows-only ist (von Mono mal abgesehen) bzw. Microsoft jederzeit sein Daumen draufdrücken kann. Ich sehe einfach den Mehrwert gegenüber z.B. Java nicht. .NET macht nur wirklich Sinn mit C# und daher zieht auch das Argument der Mehrsprachigkeit der .NET-VM nicht. Es ist ja z.B. nicht so, dass ich vorhandenen VisualBasic-Code einfach nehmen kann und in VB.NET verwenden. Die Anpassungen sind so umfangreich, dass man es lieber in C# neu schreibt. Gleiches gilt im Prinzip auch für alle anderen von .NET unterstützten Sprachen. Insofern kann man auch gleich Java nehmen und auch für die JavaVM gibts mehr Sprachen als nur Java.

      Gruß
      MichaelK

      [
      | Versenden | Drucken ]
      • 0
        Von fuffy am Mo, 30. Juli 2007 um 18:08 #
        die einzigen "Vorteile" von PHP sind, dass es viele Webhoster anbieten und es bereits viele PHP-Projekte gibt, auf die man aufbauen kann.
        Zusätzlich das Deployment, gerade bei Shared-Hosting-Konfigurationen.
        Die für RoR oder auch Python-Frameworks (WSGI) notwendigen Konfigurationsmöglichkeiten von Apache oder lighttpd wird kaum ein Shared-Hoster seinen Kunden anvertrauen.

        Zugegeben: Sowas wie eval gibts auch in Ruby. Allerdings ist man darauf bei Ruby praktisch nicht angewiesen.
        Ist in PHP auch nicht der Fall.

        PHP und Unicode? Naja. Nicht wirklich.
        Namespaces? Auch nicht.

        Die beiden Kritikpunkte haben sich mit PHP 6 erledigt, register_globals auch.

        Was die Punkte Sicherheit und API-Konsistenz angeht, muss ich dir zustimmen. ;-)

        [
        | Versenden | Drucken ]
        • 0
          Von MichaelK am Mo, 30. Juli 2007 um 19:55 #
          Hallo,

          >> die einzigen "Vorteile" von PHP sind, dass es
          >> viele Webhoster anbieten und es bereits viele
          >> PHP-Projekte gibt, auf die man aufbauen kann.
          > Zusätzlich das Deployment, gerade bei
          > Shared-Hosting-Konfigurationen.
          > Die für RoR oder auch Python-Frameworks (WSGI)
          > notwendigen Konfigurationsmöglichkeiten von
          > Apache oder lighttpd wird kaum ein
          > Shared-Hoster seinen Kunden anvertrauen.
          :-) Ja.

          >> Zugegeben: Sowas wie eval gibts auch in
          >> Ruby. Allerdings ist man darauf bei Ruby
          >> praktisch nicht angewiesen.
          > Ist in PHP auch nicht der Fall.
          Wird aber trotzdem gerne verwendet, weils einige Dinge sehr abkürzt. Und es gibt keine offizielle Empfehlung es nicht zu verwenden.

          >> PHP und Unicode? Naja. Nicht wirklich.
          >> Namespaces? Auch nicht.
          > Die beiden Kritikpunkte haben sich mit PHP 6
          Schaun wa mal. Ist aber einfach die Frage, ob man jetzt auf ein irgendwann erscheinendes PHP6 warten kann (was wahrscheinlich auf Anhieb auch noch nicht ausgereift wird), während es abgehangene Lösungen in anderen Sprachen bereits schon gibt.

          Gruß
          MichaelK

          [
          | Versenden | Drucken ]
    0
    Von Isotopp am Mo, 30. Juli 2007 um 07:23 #
    Lies http://mysqldump.azundris.com/archives/72-Rubyisms.html zu Ruby und Geschwindigkeit von Ruby (Datenbankaspekte).

    Für das Deployment setzt man lighttpd mit FCGI ein. Das hat eine Geschwindigkeit, die Apache-Servermodulen vergleichbar ist, aber ist leichter zu skalieren und kann auch dank chroot besser gesichert werden. Das gilt übrigens nicht nur für Ruby, sondern etwa auch für PHP.

    [
    | Versenden | Drucken ]
    • 0
      Von Demo am Mo, 30. Juli 2007 um 08:51 #
      Als Alternative ist natuerlich auch Mongrel erwähnenswert. Davor schaltet man natürlich einen Apache oder lighttpd mit einer Proxy Konfiguration.
      [
      | Versenden | Drucken ]
    0
    Von Guido am Mo, 30. Juli 2007 um 09:43 #
    Wenn du mit einer Skriptsprache schneller entwicklen willst - sowohl von der Performance (benchmarktechnisch belegt) als auch vom Workflow (IMHO) - solltest du dir mal gewisse Pythonframeworks anschauen:

    * Django (speziell für contentlastige Websites)
    * Pylons (meiner Meinung nach das flexibelste, meine Wahl)
    * TurboGears (hier aber bitte auf TG2 das Projekt hängt gerade intern in den Seilen..)

    [
    | Versenden | Drucken ]
    0
    Von Johannes am Mo, 30. Juli 2007 um 11:14 #
    Also ich denke nicht, dass die Geschwindigkeit von RubyOnRails so dramatisch mies ist.
    Mit FCGI rennt das schon gut (wenn man mal bedenkt was hinter der Bühne alles passiert..)

    Auch große Projekte setzten ja auf RubyOnRails. Auch solche die starkt frequentiert werden.
    Die Anwendungen von basecamp oder 43things..

    [
    | Versenden | Drucken ]
0
Von sfasgd am Mo, 30. Juli 2007 um 10:02 #
Etablierte Platform, professionelle Entwicklungswerkzeuge und Frameworks bis hinauf in den Enterprisebereich.

Ruby ist nett aber das wars dann auch.

Relevant ist nur Java.

[
| Versenden | Drucken ]
  • 0
    Von dgsafs am Mo, 30. Juli 2007 um 11:23 #
    Das ist mal fundiert. Habe bisher wenig (ausser dem Ansatz von google und der kompeliert den Javacode in html+javascript) von Webanwendungen für Java gesehen. Ist wohl auch nicht angebracht VM für jeden Request zu erstellen. Für andere Dinge ist Java gut zu gebrauchen. Doch hier sehe ich nicht den Vorteil.
    [
    | Versenden | Drucken ]
    0
    Von o13 am Mo, 30. Juli 2007 um 11:34 #
    > Etablierte Platform, professionelle Entwicklungswerkzeuge und Frameworks bis hinauf in den
    > Enterprisebereich.
    Gibt bei PHP zB auch.

    > Relevant ist nur Java.
    Zum Glueck nicht.

    Der Omega13.

    [
    | Versenden | Drucken ]
    0
    Von MichaelK am Mo, 30. Juli 2007 um 15:43 #
    Hallo,

    nur so vorweg. Ich habe selbst jahrelang mit Java programmiert (erst letztes Jahr noch hatte ich ein privates Projekt umgesetzt). Ich sage das, um diversen Sprüchen vorzubeugen.

    Das grundlegende Problem von Java ist, dass die Sprache einfach und restriktiv ist (was ja ansicht gut ist und war auch beabsichtigt, damit mans schnell lernen kann) aber gleichzeitig die API sehr komplex.
    Und das sind Sachen, die nicht gehen. Entweder man hat eine einfache Sprache und dazu einfache APIs oder eine mächtige Sprache und eine komplexe API. Den Weg den Sun gewählt hat, also eine einfache Sprache und eine komplexe API muss zwangsläufig in einer Katastrophe enden (seit Java 1.5 gibt es das leichte Verbesserungen).
    Das führt dann dazu, dass man sehr viel und umständlichen Code schreiben muss, um sie (die API) zu benutzen. Es ist geradezu eine Offenbarung, wenn man auf die API z.B. mittels Groovy zugreift. Nicht umsonst ist Sun auf den Skriptsprachen-Zug aufgesprungen.

    Auch die Annotations betrachte ich mit Argwohn. Statt die Sprach-Features zu verbessern verwenden jetzt auch schon Entwürfe für offizielle APIs die Annotations als inoffizielle Spracherweiterungen. Statt die Sprache vernünftig und zielgerichtet zu erweitern, bekommen wir jetzt also ganze Massen von schlecht integrierten Metasprachen in Java, die das bisherige Argument für Javas Reduktionismus, nämlich die Lernkurve und die Fehlerquoten niedrig zu halten, ad absurdum führt.

    Viele der offiziellen APIs (z.B. Persitenz oder Webapplikationen) sind auchfach nur aufgeblasen, langsam und praktisch nicht verwendbar. Zum Glück gibt es da viele Projekte aus der OpenSource-Community die die unbrauchbaren APIs ersetzen. Im Zuge der Freigabe von Java unter GPL ist ja vielleicht so hoffen, dass die fehldesignten APIs rausfliegen zugunsten der besseren Lösungen.

    Für Web-Applikationen gibt es praktisch gar kein vernünftiges Framework. Gerade bei kleineren Projekten machen sie mehr Arbeit, als dass sie Arbeit abnehmen. Aber auch für größere Projekte kann ich nicht so recht den Nutzen erkennen.
    Ruby on Rails ist keineswegs optimal aber gerade für Webapplikationen weitaus pragmatischer. Das macht es so attraktiv trotz der Nachteile (schlechten Encoding-Support und schlechte Performance der Runtime).

    Man sollte Ruby durchaus mal ausprobieren. Selbst wenn man es dann doch nicht nimmt, macht einen die Beschäftigung mit Ruby zu einem besseren Programmierer.
    Und mit XRuby lässt sich sogar Ruby-Quellcode zu Java-Bytecode kompilieren.

    Gruß
    MichaelK

    [
    | Versenden | Drucken ]
    • 0
      Von MichaelK am Mo, 30. Juli 2007 um 17:21 #
      Hallo,

      betreffs Java 6 ...

      gibts denn eigentlich endlich ordentliche enums ? (und nein, public static final ist keine Alternative und wer enums kennt, der weiß das auch; das fängt schon damit an, dass evtl. Fehler erst zur Laufzeit erkannt werden können).

      Überladen von Operatoren ist auch noch nicht vorgesehen?
      Also ich meine sowas hier:
      String a = "A";
      String b = "B";
      System.out.println(a+b); //ergibt "AB"
      aber
      Integer one = new Integer(1);
      Integer two = new Integer(2);
      Integer three = one+two;
      Geht nicht. Unglaublich.

      Interfaces ist ganz nett aber manchmal braucht man doch echte Mehrfachvererbung. Ich finde nicht gut, dass Sun hier dem Programmierer vorschreibt, was er darf und was nicht. Ok. Mehrfachvererbung kann leicht zu Problemen führen, aber wer sich als Programmierer bezeichnet, sollte um die Fallstricke wissen und dieses Konstrukt auch mit Bedacht einsetzen.

      Viele Klassen sind nach wie vor final. Wird ein Bug gefunden, so muss man also direkt im JDK-Quellcode fixen und ist damit inkompatibel zum Rest der Welt (zudem ergibt sich das Problem, dass der Java-Compiler javac selbst unter der Java-Ungebung läuft und davon abhängig ist; von daher ist es sowieso eine schlechte Idee die Standardklassen zu ändern). Und reicht man ihn ein ... naja wir wissen alle, wie lange das dauert eh das im Orginal-JDK gefixt ist. Eine einfache Lösung wäre die betreffene Klasse einfach zu "überschreiben", was aber durch die final-Deklarationen bei vielen Standardklassen nicht möglich ist.

      Meldet/logt der Bytecode-Verifizierer inzwischen, wenn er was ungültiges findet? Wäre nützlich, um eventuelle Hackversuche aufzudecken.

      Was ist bei Java6 bezüglich der "Destruktoren". Ok. Gibt es so in Java nicht, weil ja die GarbageCollection das abräumen der Objekte übernimmt. Aber manchmal muss man doch noch von Hand einige Aufräumarbeiten machen. Deswegen gibts ja unter Java das finalize(). Unglücklicherweise gibt es meines Wissens nach keine Garantie dafür, dass finalize() aufgerufen wird. Zudem muss der Finalizer der SuperClass per Hand aufgerufen werden. Argh.

      Gruß
      MichaelK

      [
      | Versenden | Drucken ]
      • 0
        Von fuffy am Mo, 30. Juli 2007 um 18:15 #
        gibts denn eigentlich endlich ordentliche enums ?
        Die gibt es doch schon seit Java 1.5.

        Integer one = new Integer(1);
        Integer two = new Integer(2);
        Integer three = one+two;
        Geht nicht. Unglaublich.

        Natürlich geht das. Vor wie vielen Jahren hast du zuletzt in Java programmiert?

        [
        | Versenden | Drucken ]
        • 0
          Von MichaelK am Mo, 30. Juli 2007 um 20:40 #
          Hallo,

          >> gibts denn eigentlich endlich
          >> ordentliche enums ?
          > Die gibt es doch schon seit Java 1.5.
          Stimmt. Habs gerade unter Java 1.5 probiert.

          >> Integer one = new Integer(1);
          >> Integer two = new Integer(2);
          >> Integer three = one+two;
          >> Geht nicht. Unglaublich.
          > Natürlich geht das. Vor wie vielen
          > Jahren hast du zuletzt in Java programmiert?
          Ich war bis Java 1.4 professioneller Java-Entwickler (habe mich dann anderen Projekten zugewandt; das lag aber nicht daran, dass ich mit Java unzufrieden war oder sowas sondern hat sich einfach ergeben).
          Das Problem ist, dass man ja auch wenn eine neue Java-Version rauskommt nicht einfach umstellen kann. Kunden die Java-Programme benutzen haben evtl. noch die alte Version und nicht alle neuen Features sind unbedingt Byte-Code-kompatibel zu älteren JavaVMs. Ich habe mich des Problems dadurch teilweise entledigt, indem ich zum Programm einfach das JRE hinzupackte in ein Unterverzeichnis des Programms. Man kann ja auch eine JRE benutzen ohne installieren (was ich übrigens sehr gut finde). Damit hat man dann auch noch andere Inkompatibilitäten im Griff. Sun ändert ja gerne mal was so das bestimmte Dinge in höheren Java-Versionen plötzlich nicht mehr laufen (und ich spreche hier nichtmal von deprecated-Sachen im API). Und Plattenplatz ist ja sowieso meist reichlich vorhanden, so dass die zusätzliche JRE nicht so ins Gewicht fällt selbst wenn schon eine installiert ist.
          Diese Vorgehensweise hat natürlich auch ihre Grenzen. Klassisches Beispiel sind Applets und Webstart-Anwendungen. Ok. Außerhalb des Intranets sind Applets sowieso praktisch tot und von Flash und DHTML verdrängt worden. Das liegt wahrscheinlich weniger daran, dass die JRE so groß ist, sondern das bestimmte Sachen einfach nicht gehen. Das scheitert schon daran, wenn man nur irgendwelche Einstellungen speichern will. Oder Zugriff auf Mikrofon oder Kameras. Ja. Ich weiß. Das ist ein potentielles Sicherheitsrisiko. Aber das bekommt man in Griff. Bei Flash gehts ja auch.

          Gruß
          MichaelK

          [
          | Versenden | Drucken ]
        0
        Von B.C.K. am Mo, 30. Juli 2007 um 19:05 #
        Es gibt in Java Enums seit Version 5.
        [
        | Versenden | Drucken ]
        • 0
          Von MichaelK am Mo, 30. Juli 2007 um 21:07 #
          Hallo,

          wie soll man das werten, dass Java-Entwicklern mit Features prahlen, die es in anderen Sprachen schon ewig(!) gibt?

          Gruß
          MichaelK

          [
          | Versenden | Drucken ]
          • 0
            Von fuffy am Mo, 30. Juli 2007 um 22:57 #
            Bei Java gab es von Anfang an ResourceBundles zur Internationalisierung. Sämtliche guten Webframeworks machen hiervon Gebrauch.

            Bei RoR habe ich keinen Standard erkennen können. Der Salted-Login-Generator z.B. verwendet den Localization-Generator, dessen Sprache man beim WEBrick-Start fest vorgeben muss. Für eine mehrsprachige Website/-anwendung ist das schon mal unbrauchbar.

            [
            | Versenden | Drucken ]
            • 0
              Von MichaelK am Di, 31. Juli 2007 um 01:12 #
              Hallo,

              > Bei Java gab es von Anfang an ResourceBundles
              > zur Internationalisierung.
              Ja. ResourcenBundles. Sehr schick. Aber im Grunde nicht mehr als eine Hash-Table. Sorry. Aber veralbern kann ich mich selber!
              Wenn wenigstens hierbei von den enum-Fähigkeiten Gebrauch gemacht würde. Aber nein. Die Schlüssel ist ein normaler String. Tippfehler werden also vom Compiler nicht bemerkt und man sieht den Fehler, wenn überhaupt, erst zur Laufzeit.

              Gruß
              MichaelK

              [
              | Versenden | Drucken ]
              • 0
                Von fuffy am Di, 31. Juli 2007 um 08:26 #
                Meine Rede ist hier nicht mehr von Enums, sondern von Features, die Java seit Ewigkeiten bietet (integrierte Internationalisierung) und die z.B. bei Rails bis heute nicht konsequent umgesetzt wurden.

                Aber im Grunde nicht mehr als eine Hash-Table.
                Die Laufzeitumgebung (JavaVM) wählt automatisch die zur jeweiligen Locale passende ResourceBundle-Datei. So etwas kann man mittels gettext auch erreichen, nur ist gettext kein Bestandteil der stdlib von Ruby und Rails verwendet diese gewöhnlich nicht zur Internationalisierung.

                [
                | Versenden | Drucken ]
                • 0
                  Von MichaelK am Di, 31. Juli 2007 um 14:06 #
                  Hallo,

                  >> Meine Rede ist hier nicht mehr von Enums,
                  >> sondern von Features, die Java seit
                  >> Ewigkeiten bietet (integrierte Internationalisierung)
                  Unglaublich. Sag mal, stellst Du Dich absichtlich so blöd?
                  Nochmal: Die Werte aus dem ResourcenBundle werden über ein Schlüssel adressiert. Dieser Schlüssel ist ein String. Das ist natürlich sehr ungeschickt, da Tippfehler beim eingeben des Schlüssels erst zur Laufzeit erkannt werden können. Würde man für den Schlüssel statt String z.B. enums nehmen (die es ja in Java jetzt gibt), könnten Tippfehler schon zur Laufzeit erkannt werden.

                  >> Die Laufzeitumgebung (JavaVM) wählt automatisch
                  >> die zur jeweiligen Locale passende
                  >> ResourceBundle-Datei.
                  Das ist ja wirklich eine "tolle" Leistung. Es dürfte 5 Codezeilen nicht überschreiten den Browser nach seiner bevorzugten Sprache abzufragen und dann die entsprechende Ressourcendatei zu laden.

                  Man, man man ... und und ich dachte wenigstens die IT-Leute wären gegenüber Marketing resistent. Aber man merkt deutlich, dass der Wirtschaftsinformatikeranteil wächst.

                  Gruß
                  MichaelK

                  [
                  | Versenden | Drucken ]
                  • 0
                    Von fuffy am Di, 31. Juli 2007 um 14:45 #
                    Die Werte aus dem ResourcenBundle werden über ein Schlüssel adressiert.
                    Das ist für Dictionaries nun mal so üblich.

                    Würde man für den Schlüssel statt String z.B. enums nehmen (die es ja in Java jetzt gibt), könnten Tippfehler schon zur Laufzeit erkannt werden.
                    Was ist, wenn dir die Tippfehler in den Textdateien widerfahren?

                    Das ist ja wirklich eine "tolle" Leistung. Es dürfte 5 Codezeilen nicht überschreiten den Browser nach seiner bevorzugten Sprache abzufragen und dann die entsprechende Ressourcendatei zu laden.
                    Wetten, dass doch? gettext enthält jedenfalls an sich schon mehr Codezeilen.

                    Man, man man ... und und ich dachte wenigstens die IT-Leute wären gegenüber Marketing resistent. Aber man merkt deutlich, dass der Wirtschaftsinformatikeranteil wächst.
                    Was hat das bitte mit Marketing zu tun? Solche Features gibt es für praktisch jede Programmiersprache, und sei es, dass man GNU gettext nutzt.

                    Du hast aber immer noch nicht die Kernaussage verstanden, nämlich die, dass Ruby (RoR) eben keine solche Lösung eingebaut hat und man sich stattdessen mit dutzenden (halbherzigen) Lösungen wie Globalize, Localization, etc. herumschlagen muss und das bei einem Webframework. Eine solche Standardfunktionalität sollte eigentlich vom Framework unterstützt werden. Im Falle von Java, .NET und Co. gehört das sogar zum Standard-API.

                    [
                    | Versenden | Drucken ]
                    • 0
                      Von MichaelK am Di, 31. Juli 2007 um 17:34 #
                      Hallo,

                      >> Die Werte aus dem ResourcenBundle werden
                      >> über ein Schlüssel adressiert.
                      > Das ist für Dictionaries nun mal so üblich.
                      Sehr witzig.
                      Ich hielt diese einleitende Erklärung für nötig. Man passt sich eben dem Niveau seines Diskussionspartners an.

                      >> Würde man für den Schlüssel statt
                      >> String z.B. enums nehmen (die es ja
                      >> in Java jetzt gibt), könnten Tippfehler
                      >> schon zur Laufzeit erkannt werden.
                      > Was ist, wenn dir die Tippfehler in den Textdateien widerfahren?
                      Immerhin hätte man eine Fehlerquelle schon mal ausgeschlossen. Somal man in den Ressourcendateien den Schlüssel nur einmal schreibt dieser aber dann im Quellcode nicht selten mehrmals verwendet wird.

                      >> Das ist ja wirklich eine "tolle"
                      >> Leistung. Es dürfte 5 Codezeilen
                      >> nicht überschreiten den Browser
                      >> nach seiner bevorzugten Sprache
                      >> abzufragen und dann die
                      >> entsprechende Ressourcendatei zu
                      >> laden.
                      > Wetten, dass doch? gettext enthält
                      > jedenfalls an sich schon mehr
                      > Codezeilen.
                      Hm. Anscheinend muss man hier echt noch die Grundlagen des Programmierens vermitteln. Ok. Ich schreibe das jetzt mal in Pseudo-Code. Lässt sich aber im Prinzip auf jede beliebige Sprache übertragen.
                      Wenn wir jetzt mal von der CGI-Schnittstelle ausgehen, dann fragen wir einfach mal folgendermaßen die bevorzugte Sprache des Browsers ab:
                      String sprache = System.getEnv("HTTP_ACCEPT_LANGUAGE"); // ergibt de für Deutsch
                      InputFile ressourcendatei = File.open("meineressourcen_"+sprache+".res")
                      while (zeile=ressourcendatei.readLine())!=EOF)
                      usw. also Zeile in Hashtable packen; ist auch in Python/Ruby nur ein Einzeiler
                      end
                      ressourcendatei.close()

                      Ok. Es sind 6 Zeilen geworden. Aber ich wollte nicht mit den Abkürzungstricks arbeiten die sonst so üblich sind, um dass Ganze verständlich zu halten.

                      Der Zugriff erfolgt dann natürlich über enum-Schlüssel. Also z.B.:
                      print(ressourcenbundle.get(OK_BUTTON))
                      statt
                      print(ressourcenbundle.get("OK_BUTTON"))

                      Tippfehler ausgeschlossen.

                      Und wie man aus der Ressourcendatei automatisiert die Definition des enum in den Quelltext bekommt, brauche ich wohl hoffentlich niemanden erklären.

                      >> Man, man man ... und und ich
                      >> dachte wenigstens die IT-Leute
                      >> wären gegenüber Marketing resistent.
                      >> Aber man merkt deutlich, dass der
                      >> Wirtschaftsinformatikeranteil wächst.
                      > Was hat das bitte mit Marketing zu tun?
                      > Solche Features gibt es für praktisch
                      > jede Programmiersprache, und sei es,
                      > dass man GNU gettext nutzt.
                      Ja klar. Aber ich war es ja nicht, der Javas ResourcenBundle als besonderes Feature dargestellt hat. Und ehrlich gesagt wäre ich fast geneigt dazu einen Programmierer zu entlassen, der tatsächlich ohne Not von dem Orginal-Java-ResourcenBundle Gebrauch macht. Eben wegen der dargestellten Schwächen und der sehr einfachen Möglichkeit das ResourcenBundle durch etwas besseres zu ersetzen.
                      Und vorhandene Altlasten umzustellen die noch das Orginal ResourcenBundle (oder Vergleichbares) benutzen, dürfte ja mit "Suchen&Ersetzen" auch kein Problem sein.

                      >> Du hast aber immer noch nicht die
                      >> Kernaussage verstanden, nämlich die,
                      >> dass Ruby (RoR) eben keine solche
                      >> Lösung eingebaut hat und man sich
                      >> stattdessen mit dutzenden
                      >> (halbherzigen) Lösungen wie
                      >> Globalize, Localization, etc.
                      >> herumschlagen muss und das
                      >> bei einem Webframework. Eine solche
                      >> Standardfunktionalität sollte
                      >> eigentlich vom Framework unterstützt
                      >> werden. Im Falle von Java, .NET und
                      >> Co. gehört das sogar zum Standard-API.
                      Ich kann zu Rails nicht soviel sagen. Das liegt zum einen daran, dass als ich mit Webapplikationen abgefangen habe es noch keine fertigen Web-Frameworks gab und man sich also selbst was basteln musste (wir hatten damals schon Lösungen, wo man den Inhalt wahlweise als HTML,PDF oder WML [Handy] ausliefern konnte; allerdings noch mit TeX als Quelle und nicht wie heutzutage z.B. bei Apache Cocoon mit XML). Zum zweiten bin ich vom MVC-Ansatz nicht so überzeugt wie andere. In der Praxis trifft man nämlich immer wieder auf Probleme, die sich nicht so ohne weiteres auf die reine Lehre von MVC abbilden lassen (z.B. kann es durchaus Sinn machen Controller und View eben nicht strikt zu trennen). Aber das würde jetzt zu weit führen.

                      Jedenfalls kann ich mir nicht vorstellen, dass es bei Rails so kompliziert sein sollte, eine Internationalisierung mit einzubauen.

                      Gruß
                      MichaelK

                      [
                      | Versenden | Drucken ]
                      • 0
                        Von fuffy am Di, 31. Juli 2007 um 19:10 #
                        String sprache = System.getEnv("HTTP_ACCEPT_LANGUAGE"); // ergibt de für Deutsch
                        InputFile ressourcendatei = File.open("meineressourcen_"+sprache+".res")
                        while (zeile=ressourcendatei.readLine())!=EOF)
                        usw. also Zeile in Hashtable packen; ist auch in Python/Ruby nur ein Einzeiler
                        end
                        ressourcendatei.close()

                        HTTP_ACCEPT_LANGUAGE enthält in der Regel mehrere Werte, nach Priorisierung sortiert. Nicht für jede Sprache liegt eine Resource-Datei vor. Jemand, der einen englischsprachigen Browser in einem Internet-Cafe verwendet, möchte die Sprache manuell umstellen. Vielleicht gibt es auch gar keinen Header. Zudem sollte man nicht einfach Fremdeingaben vertrauen. Auch HTTP-Header müssen, genauso wie sämtliche Formulareingaben gefiltert werden. Alles Dinge, die abgefangen werden *müssen*.
                        Hinzu kommen noch die Helferlein, damit man so Dinge wie die Wahl von Singular oder Plural nicht ständig neu schreiben muss.

                        Jedenfalls kann ich mir nicht vorstellen, dass es bei Rails so kompliziert sein sollte, eine Internationalisierung mit einzubauen.

                        Ist es allerdings. So sind die Strings für die Fehlermeldungen der ActiveRecord-Validierungen wie "%s is required." hardcoded. Das Thema I18N wurde von den Entwicklern schlichtweg ignoriert.

                        [
                        | Versenden | Drucken ]
                        • 0
                          Von MichaelK am Di, 31. Juli 2007 um 23:02 #
                          Hallo,

                          > HTTP_ACCEPT_LANGUAGE enthält in der Regel mehrere
                          > Werte, nach Priorisierung sortiert. Nicht für jede
                          > Sprache liegt eine Resource-Datei vor.
                          > Jemand, der einen englischsprachigen Browser in
                          > einem Internet-Cafe verwendet, möchte die Sprache
                          > manuell umstellen. Vielleicht gibt es auch gar
                          > keinen Header.
                          Das war nur ein Beispiel. Kein ausformulierter Code den man sofort verwenden kann. Ich wollte lediglich das Prinzip darstellen. Um das rund zu machen, braucht man noch ein paar Zeilen mehr. Aber das ist insgesamt kein großes Ding (inkl. Prüfung und Berücksichtigung manueller Sprachwahl vielleicht 10 Zeilen) und das ist, was ich sagen wollte.
                          Und natürlich sollte man bei Webanwendung immer die Möglichkeit geben die Sprache auch manuell auswählen zu können. Aber ich dachte über Selbstverständlichkeiten muss ich nicht noch lange drum rum reden.

                          > Zudem sollte man nicht einfach
                          > Fremdeingaben vertrauen. Auch HTTP-Header müssen,
                          > genauso wie sämtliche Formulareingaben gefiltert
                          > werden. Alles Dinge, die abgefangen werden *müssen*.
                          Ja. Auch das ist nichts Neues. Aber erzähl das mal lieber den PHP-Entwicklern, die Benutzereingaben ungeprüft in eval() verwenden. :-)

                          >> Jedenfalls kann ich mir nicht vorstellen, dass es
                          >> bei Rails so kompliziert sein sollte, eine
                          >> Internationalisierung mit einzubauen.
                          > Ist es allerdings. So sind die Strings für die
                          > Fehlermeldungen der ActiveRecord-Validierungen
                          > wie "%s is required." hardcoded. Das Thema
                          > I18N wurde von den Entwicklern schlichtweg
                          > ignoriert.
                          Wie schon gesagt, ich bin jetzt kein ausgesprochener Rails-Experte. Aber das sind vielleicht Sachen, die man ohne Probleme korrigieren könnte. Und man muss es ja nur einmal machen. Beim nächsten Web-Projekt kann man ja gleich mit dem angepasst Rails arbeiten. Die erforderlichen Patches reicht man dann einfach ein, damit sie (hoffentlich) Bestandteil des "offiziellen" Rails werden und gut ist. Das ist ja gerade der Vorteil bei Open-Source.

                          Gruß
                          MichaelK

                          [
                          | Versenden | Drucken ]
                          0
                          Von caffeine am Mo, 6. August 2007 um 11:09 #

                          > Ist es allerdings. So sind die Strings für die Fehlermeldungen der ActiveRecord-Validierungen wie "%s is required."
                          > hardcoded. Das Thema I18N wurde von den Entwicklern schlichtweg ignoriert.

                          Zum Glück hast du keine Ahnung ... validates_uniqueness_of :name, :message => "ist ein Pflichtfeld"

                          [
                          | Versenden | Drucken ]
        0
        Von Jens am Mo, 30. Juli 2007 um 21:13 #
        Moin,

        >Entweder man hat eine einfache Sprache und dazu einfache APIs oder eine mächtige Sprache und eine komplexe API.

        was für eine dumme Aussage (sorry). Das eine hat mit dem anderen rein gar nichts zu tun.

        >Überladen von Operatoren ist auch noch nicht vorgesehen? ... Geht nicht. Unglaublich.

        Nicht jede Sprache muss alles können und nicht jede Sprache, die nicht alles kann, taugt auch nichts. Schön, dass du deinen Favoriten hast, aber deshalb ist nicht alles andere schlecht.

        - J

        [
        | Versenden | Drucken ]
        • 0
          Von MichaelK am Mo, 30. Juli 2007 um 23:07 #
          Hallo,

          > Nicht jede Sprache muss alles können
          > und nicht jede Sprache, die nicht
          > alles kann, taugt auch nichts.
          Was ich wünsche ist nur eine vernünftige Weiterentwicklung. Weiter nichts. Und wenn Java überleben will, muss es sich weiter entwickeln. .NET/C# und was es da sonst noch so gibt bringen sonst Java in arge Bedrängnis.

          > Schön, dass du deinen Favoriten hast, aber
          > deshalb ist nicht alles andere schlecht.
          Siehst Du. Das zeigt, dass Du überhaupt nichts begriffen hast. Es gibt nicht DEN Favoriten bei den Programmiersprachen. Es kommt immer darauf an, was man machen will.
          Für z.B. ein kleines Backup-Skript würde ich nie Java nehmen. Da muss man ja schon allein vier Zeilen schreiben, ohne dass da irgendwas produktives bei ist:
          public class Meinskript {
          public static void main(String[] args) {
          }
          }

          Da ist z.B. unter UNIX ein Shell-Skript einfach besser, somal man ohne Probleme andere Tools aufrufen kann und die meisten eigenen sich Dank Pipes und Umleitungen sehr gut dazu. Oder wenns etwas mächtiger sein soll von mir aus auch Perl.
          Bei Python und Ruby muss man schon wieder etwas vorsichtiger sein. Kann sein, dass das nicht immer installiert ist. Aber wenn, dann ist es natürlich auch gut. Weil man da noch die Objektorientierung geschenkt bekommt, was dann aber erst bei größeren Skripten interessant wird.

          Vermutlich wird auch kaum jemand auf die Idee kommen Gerätetreiber mit Java oder .NET zu programmieren (naja ... mit .NET geht das zumindest theoretisch; allerdings gibt man damit die Vorteile des "managed-code" auf und ist daher eigentlich widersinnig). Da wird man wohl auch noch weiterhin zu primär zu C greifen.

          Gleiches gilt für den Spielesektor, der nach wie vor von C/C++ (und teilweise Assembler) dominiert ist und das nicht zu unrecht. Auch wenn sich hier den Trend verstärkt zumindest Skriptsprachen wie Python mit einzubinden. Allerdings nur für das "drumherum" und weniger für die eigentliche Engine.

          Und dann gibts ja da noch die Uralt-Diskussion ob überhaupt kompiliert (also in Maschinencode) oder interpretiert. Java und .NET (aber im Prinzip auch inzwischen einige Skriptsprachen wie Python) versuchen da ein Mittelding (Bytecode), was die Schwächen (oder auch Stärken) der beiden Konzepte vereint. Ich sehe das erstmal als problematisch an. Man schafft sich immer mehr Layer. Das ist bis zu einem gewissen Grad ja auch ok. Aber man darf es halt nicht übertreiben. Die Krönung des Ganzen wäre ein Python-Programm was mit JPython intepretiert wird, was wiederum auf einer JavaVM läuft, die sich wiederum des Betriebsystemlayers bedient (und das Betriebssystem ist ja auch nochmal in mehrere Layer unterteilt) und das ganze vielleicht noch in einer VM-Ware-Session die dann wiederum auf einem Betriebssystem läuft usw. Alles Overhead der überhaupt nichts bringt, weil mehr Layer als überhaupt nötig. Kein Wunder, das das ordentlich Geschwindigkeit kostet und die Komplexität und damit die Fehleranfälligkeit erhöht.

          Ich hatte mir mehr erhofft, dass man endlich mal gründlich ausmistet. Die JavaVM z.B. nicht als extra Layer, sondern ins Betriebssystem selbst integrieren. Die JavaVM soll demnach nicht die Betriebssystem-API aufrufen, sondern die Betriebssystem-API selbst sein. Ich denke aber mal, dieses Ziel wird Microsoft mit .NET eher erreichen (was sie auch müssen; ihre bisherigen MS-APIs sind ja alle kaputt). Das liegt vor allem daran, dass sie ja nur eine Plattform (Windows eben) beherrschen müssen. Aber ich schweife ab.

          Was ich eigentlich sagen wollte: Für jede Aufgabe sollte man auch die dafür geeignete Sprache nehmen. Java versucht hierbei eine Eierlegende Wollmilchsau zu sein. Soll laufen vom Handy, Browser, Applikation bis auf dem dicken Server. Bisher sehe ich das aber bei weitem noch nicht umgesetzt, falls das überhaupt gehen sollte. Im Gegenteil. Mir fällt kein Bereich ein, bei dem es zu Java nicht eine bessere Alternative gibt. Von daher ist es eigentlich obsolet, weshalb ich es selbst auch nicht mehr verwende. Es kommt auch nur noch dann zum Zuge, wenn bestehende Lösung sich nicht anders ergänzen lassen (das ist wohl auch der Grund, warum sich bis heute Fortran und Cobol hält).

          Noch ein Wort zu C++: Während C ja noch gut verwendbar ist, halte ich C++ für kompletten Schrott. Warum sich das durchgesetzt hat, ist mir bis heute ein Rätsel und ich finde es immer furchtbar, wenn ich damit programmieren muss. Das um etwa die gleiche Zeit entstandene Objective-C (MacOS-Programmierer kennen das) ist da weitaus besser. Viele Features die heute in Java bestaunt werden gabs damals schon in Objective-C. Das C++ sich durchgesetzt hat, dürfte die Softwareindustrie um Jahre zurückgeworfen haben. Für C++ sprechen allenfalls zwei Dinge:
          Der Schritt von C zu C++ ist nicht so drastisch wie von C zu Objective-C (was gleichzeitig auch ein Nachteil ist; so fängt sich C++ die Schwächen von C ebenfalls ein).
          Die Laufzeitgeschwindigkeit von C++-Programme lag damals sicherlich etwas höher. Leider hatte ich in den 80er Jahren noch keinen Objective-C-Compiler zur Verfügung, um dass wirklich mal zu testen.

          Gruß
          MichaelK

          [
          | Versenden | Drucken ]
      0
      Von fuffy am Mo, 30. Juli 2007 um 18:15 #
      Für Web-Applikationen gibt es praktisch gar kein vernünftiges Framework.
      Kennst du Struts 2 oder Spring Web?
      [
      | Versenden | Drucken ]
      • 0
        Von elBarto am Mo, 30. Juli 2007 um 19:41 #
        Oder Tapestry oder Wicket oder ...
        [
        | Versenden | Drucken ]
        0
        Von MichaelK am Mo, 30. Juli 2007 um 20:59 #
        Hallo,

        >> Für Web-Applikationen gibt es praktisch
        >> gar kein vernünftiges Framework.
        > Kennst du Struts 2 oder Spring Web?
        Tja. Hättest Du mal mein Beitrag gelesen, dann wüsstest Du, dass es mir primär um die Standard-API ging und ich OpenSource-Java-Lösungen ausdrücklich gelobt habe.
        J2EE zum Beispiel ist praktisch unbenutzbar. Das fängt schon mit EJB (oder hat sich seit Version 2.1 irgendwas Bedeutendes getan?) an. JSP/JSF sind den Alternativen hoffnungslos unterlegen. Oder auch JDBC. Wer andere Sachen für Datenbanken als JDBC kennt, wird mir hier zustimmen.

        Das mit Java 1.4 eingeführte NIO war mehr als dringend nötig (und schon einer der wichtigsten Forderungen seit Java 1.0). Mit Java 1.5 soll es (NIO) dann auch auch endlich brauchbar geworden sein.

        Abgesehen davon finde ich es schade, dass keiner auf meine Kernkritik an Java eingeht.
        Sowas wie die Annotations sind doch geradezu ein Eingeständnis in die Unzulänglichkeit von Java, wo bei Annotations da natürlich der falsche Weg sind. Besser wäre es den Sprachkern als solches weiter zu entwickeln. Als weiteres Eingeständnis kann die Integration von Skriptsprachen in Java gelten. Warum sollte man sie sonst fördern? Kann doch nur darin begründet sein, dass sie eben Java überlegen sind sonst würde man ja direkt Java nehmen. Die Integration ist daher kein Plus für Java sondern ein Plus für die Skriptsprachen.

        Fazit: Sun rüstet bei Java mächtig auf, so dass diese Plattform immer mehr leistet. Bleibt nur die Frage, warum der Entwickler nicht lieber gleich das entsprechende Orginal statt die schlechte Kopie (die Java-Plattform von Sun) nehmen sollte?

        Gruß
        MichaelK

        [
        | Versenden | Drucken ]
        • 0
          Von fuffy am Mo, 30. Juli 2007 um 22:47 #
          Hättest Du mal mein Beitrag gelesen, dann wüsstest Du, dass es mir primär um die Standard-API ging und ich OpenSource-Java-Lösungen ausdrücklich gelobt habe.
          Ach, sind CGI/Ruby und CGI/Python da etwa besser? Nein, Rails und Django gehören nicht zur "Standard-API" von Ruby und Python.

          Sowas wie die Annotations sind doch geradezu ein Eingeständnis in die Unzulänglichkeit von Java, wo bei Annotations da natürlich der falsche Weg sind.
          Warum? Über Annotations lassen sich Methoden als Transactional definieren, Validierungen sowie Berechtigungen auf Actions festlegen etc., fast in ähnlichem Stil, wie dies bei RoR möglich ist. Dieses Feature wurde übrigens von .NET übernommen.

          [
          | Versenden | Drucken ]
          • 0
            Von MichaelK am Di, 31. Juli 2007 um 02:20 #
            Hallo,

            >> Hättest Du mal mein Beitrag gelesen,
            >> dann wüsstest Du, dass es mir primär
            >> um die Standard-API ging und ich
            >> OpenSource-Java-Lösungen ausdrücklich gelobt habe.
            > Ach, sind CGI/Ruby und CGI/Python da etwa besser?
            Es ging um eine Java-Kritik. Daher hat es wenig Sinn mit "sind XYZ etwa besser?" zu antworten. Selbst wenn es keine Sprache geben sollte, wo das besser gelöst ist reicht das wohl kaum als Argument aus den Missstand bei Java so zu lassen. Ich erhoffe mir etwas davon dadurch das Java GPLed ist und die unbenutzbaren APIs endlich durch die brauchbaren ersetzt werden.

            >> Sowas wie die Annotations sind doch geradezu ein
            >> Eingeständnis in die Unzulänglichkeit von Java,
            >> wo bei Annotations da natürlich der falsche Weg sind.
            > Warum? Über Annotations lassen sich Methoden als
            > Transactional definieren, Validierungen sowie
            > Berechtigungen auf Actions festlegen etc.,
            Ja. Nur ändert das wenig an meiner Kritik. Andere Programmiersprachen bekommen die Probleme ja auch in den Griff ohne eine "Metasprache" wie Annotations zu benutzen, was eben auch viele Nachteile mitsich bringt.

            Gruß
            MichaelK

            [
            | Versenden | Drucken ]
            • 0
              Von fuffy am Di, 31. Juli 2007 um 09:24 #
              Es ging um eine Java-Kritik. Daher hat es wenig Sinn mit "sind XYZ etwa besser?" zu antworten.
              Doch, denn im gleichen Atemzug, in dem du Java kritisiert, hebst du Ruby hervor. Dabei ist Ruby an dieser Stelle eben kein bisschen besser.

              Andere Programmiersprachen bekommen die Probleme ja auch in den Griff ohne eine "Metasprache" wie Annotations zu benutzen, was eben auch viele Nachteile mitsich bringt.
              Welche Nachteile? Metasprachen für Metainformationen passen genau in das DSL-Schema rein.

              [
              | Versenden | Drucken ]
              • 0
                Von MichaelK am Di, 31. Juli 2007 um 17:51 #
                Hallo,

                >> Es ging um eine Java-Kritik. Daher
                >> hat es wenig Sinn mit "sind XYZ etwa
                >> besser?" zu antworten.
                > Doch, denn im gleichen Atemzug, in
                > dem du Java kritisiert, hebst du Ruby
                > hervor. Dabei ist Ruby an dieser Stelle
                > eben kein bisschen besser.
                Rails ist nicht perfekt. Aber um Längen besser als dieses unbenutzbare J2EE-Geraffel. Und das ist nicht nur meine Meinung. Das sagen mir selbst eingefleischte Java-Programmierer. Die finden Rails nicht toll aber gegenüber dem was Sun zu bieten hat ist man in vielen Fällen damit schneller am Ziel.

                >> Andere Programmiersprachen bekommen die
                >> Probleme ja auch in den Griff ohne eine
                >> "Metasprache" wie Annotations zu benutzen,
                >> was eben auch viele Nachteile mitsich bringt.
                >Welche Nachteile?
                Ähm. Lies einfach nochmal, was ich dazu in früheren Beiträgen geschrieben habe. Ich habe keine Lust mich nochmal zu widerholen. Wenn Dir dann noch was unklar ist, frage konkret.

                Gruß
                MichaelK

                [
                | Versenden | Drucken ]
                • 0
                  Von fuffy am Di, 31. Juli 2007 um 19:16 #
                  Ähm. Lies einfach nochmal, was ich dazu in früheren Beiträgen geschrieben habe. Ich habe keine Lust mich nochmal zu widerholen. Wenn Dir dann noch was unklar ist, frage konkret.
                  Du hast überhaupt keine konkreten Nachteile der Annotations genannt, sondern nur die Behauptung aufgestellt, dass diese ein Eingeständnis an die Unzulänglichkeit von Java seien.
                  [
                  | Versenden | Drucken ]
                  • 0
                    Von MichaelK am Di, 31. Juli 2007 um 23:07 #
                    Hallo,

                    >> Ähm. Lies einfach nochmal, was ich dazu in
                    >> früheren Beiträgen geschrieben habe. Ich
                    >> habe keine Lust mich nochmal zu widerholen.
                    >> Wenn Dir dann noch was unklar ist, frage konkret.
                    > Du hast überhaupt keine konkreten Nachteile der
                    > Annotations genannt, sondern nur die Behauptung
                    > aufgestellt, dass diese ein Eingeständnis an
                    > die Unzulänglichkeit von Java seien.
                    Ja. Das auch. Ansonsten zitiere ich mich an dieser Stelle nochmal selbst:
                    Auch die Annotations betrachte ich mit Argwohn. Statt die Sprach-Features zu verbessern verwenden jetzt auch schon Entwürfe für offizielle APIs die Annotations als inoffizielle Spracherweiterungen. Statt die Sprache vernünftig und zielgerichtet zu erweitern, bekommen wir jetzt also ganze Massen von schlecht integrierten Metasprachen in Java, die das bisherige Argument für Javas Reduktionismus, nämlich die Lernkurve und die Fehlerquoten niedrig zu halten, ad absurdum führt.

                    Gruß
                    MichaelK

                    [
                    | Versenden | Drucken ]
          0
          Von elBarto am Mo, 30. Juli 2007 um 23:50 #
          Seit EJB 2.1 hat sich einiges getan. EJB3 hat gewaltige Verbesserungen mit sich gebracht.

          Was soll besser sein als JDBC? Von welchen Alternativen redest du? JDBC ist ausgereift und "Rock-Solid". Mal davon abgesehen, dass man für grössere Projekte eh meist auf Hibernate oder JPA (falls man Standards haben will) zurück greift, die natürlich auf JDBC aufsetzen.

          JSF ist ebenfalls ausgereift. Mit Facelets + Seam macht JSF inzwischen richtig Spass.

          Und was du an Annotations auszusetzen hast, habe ich auch nicht verstanden. Du redest nur um den heissen Brei herum. Annotations sind für Metadaten da und diese Aufgabe erledigen sie ausgezeichnet.

          z.B. das ist ein Webservice in Java.

          @Stateless
          @WebService
          public class HelloServiceBean {
          private String message = "Hello, ";
          public void HelloServiceBean() {}

          @WebMethod
          public String sayHello(String name) {
          return message + name + ".";
          }
          }

          Ohne Annotations bräuchte man noch eine XML-Datei als Konfiguration, deswegen ist es schön, dass es sie gibt.


          Und nochmal zu deinem Fazit. (Original vs. Java-Plattform) Das was im z.B. im JavaEE-Standard drin ist, wird von sehr vielen Sofwareherstellern abgesegnet. (IBM, Google, SAP, Sun, Apache, uvm.). Wenn man nicht von einem Hersteller abhängig sein will, setzt man eben auf Standards. Meine Kunden legen z.B. grossen Wert drauf. Ich benutze z.B. EJB3 Persistence anstatt die "Originale" Hibernate, Kodo oder Toplink und meine Anwendung "deployed" auf vier verschiedenen App-Servern ohne eine einzige Änderung.

          [
          | Versenden | Drucken ]
          • 0
            Von MichaelK am Di, 31. Juli 2007 um 03:14 #
            Hallo,

            >> Seit EJB 2.1 hat sich einiges getan. EJB3
            >> hat gewaltige Verbesserungen mit sich gebracht.
            Zum Beispiel?

            Ich verbinde mit dem J2EE-Kram immer noch megabyte-weise XML-Konfig-Dateien erstellen. Argh.
            Statische Typisierung hat durchaus ihre Vorteile. Und mit Generics und Autoboxing wird das Arbeiten mit Java auch etwas angenehmer. Leider macht gerade EJB von den Vorteilen der statischen Typisierung wenig Gebrauch. Namenssuche geschieht dann zur Laufzeit und zwar über Strings statt über Klassen. *Hände_über_den_Kopf_zusammenschlag* Neben der Fehleranfälligkeit ist damit auch praktisch kein Refactoring mehr möglich.

            Ich würde trotz allem was ich bisher an Java kritisiert habe empfehlen Java zu lernen. Für jemanden der einen sicheren Job haben will gibt es derzeit kaum was besseres. Wer statt dessen aber lieber produktiv sein will, sollte sich durchaus mal Ruby usw. ansehen.

            > Und was du an Annotations auszusetzen hast,
            > habe ich auch nicht verstanden.
            Sun macht nicht einfach die Sprache Java mächtiger, sondern führt einfach ein neues Konstrukt ein. Eine Metasprache. Wo jeder dann sein eigenes Süppchen kochen kann. Aber zu den Nachteilen dieser "Lösung" hatte ich ja weiter oben bereits geschrieben. Besser wäre es einfach die Mächtigkeit der Sprache Java zu erhöhen. Programmiere die Java-Plattform mal mit Groovy. Dann verstehst Du, was ich meine.

            > Was soll besser sein als JDBC?
            Ich durfte mich eine ganze Weile mit JDBC herumquälen. Da waren sogar die älteren C-APIs die wir vorher verwendet haben besser.
            Aber nun gut. Heutzutage kommt man mit JDBC ohnehin kaum noch in Berührung genauso wenig wie mit SQL. Abgesehen davon, dass objektorientierte Datenstrukturen in eine relationale Datenbank zu speichern ohnehin mit auspeitschen bestraft werden sollte. Ganz davon abgesehen gibt es natürlich immer häufig noch Fälle, wo ne Tabelle ausreicht und dann (aber auch nur dann) macht ein RDBMS Sinn.

            >> Das was im z.B. im JavaEE-Standard drin ist,
            >> wird von sehr vielen Sofwareherstellern
            >> abgesegnet. (IBM, Google, SAP, Sun, Apache,
            >> uvm.).

            >> Wenn man nicht von einem Hersteller abhängig
            >> sein will, setzt man eben auf Standards.
            >> Meine Kunden legen z.B. grossen Wert drauf.
            Genau das ist das Problem was ich bei diesen Standards sehe. Da wird irgendwas zum Standard gemacht, was völlig unbrauchbar ist. Dann doch lieber keine Standard-API (noch besser wäre natürlich ein brauchbarer Standard) und ich kann mir das geeignete Framework selbst aussuchen. Und wenn man OpenSource einsetzt, hat man auch kein Problem mit der Herstellerabhängigkeit. Schon allein was man an Entwicklungszeit einspart, wenn man etwas Ordentliches einsetzt ...

            Das Problem hast Du schon richtig erkannt. Die Kunden wollen das so. Nur leider entscheidet das nie ein Techniker der sich damit auskennt, sondern Entscheider (Schlipsträger) der irgendwie sein BWL-Studium geschafft hat. Wenn Du "Glück" hast, es ist sogar ein Wirtschaftsinformatiker, was ihn aber deshalb nicht qualifizierter macht (wenn so einer mal Code "schreibt", dann ist das VBA und mit dem Makrorecorder aufgenommen und selbst das macht er noch falsch). Und wenn man da halt nicht die passenden Buzzwords parat hat, steht man auf dem Schlauch.
            Glaubst Du Windows hätte heute den Marktanteil den es hat, wenn es darum ginge, was besser ist?
            Manchmal ist man ja echt auf Windows angewiesen aber oftmals eben nicht. Gerade im Firmenumfeld. Die Standardaufgaben (Office, Internet/eMail usw.) sind ohnehin abgedeckt und für alles andere findet sich häufig ein ganz gutes Äquivalent. Für den Rest gibt es noch WINE und was auch da nicht läuft, kommt auf einen Windows-Terminal-Server. Dann sind die Ausnahmen die es noch gibt auf ein Minimum reduziert. Nur setz das mal durch (selbst sanfte Migration wäre ja möglich), wenn dass letzte Wort unsere lieben und "kompetenten" Entscheider haben.

            Gruß
            MichaelK

            [
            | Versenden | Drucken ]
            • 0
              Von fuffy am Di, 31. Juli 2007 um 09:28 #
              Abgesehen davon, dass objektorientierte Datenstrukturen in eine relationale Datenbank zu speichern ohnehin mit auspeitschen bestraft werden sollte.
              Du machst also in RoR keinen Gebrauch von ActiveRecord?
              [
              | Versenden | Drucken ]
              • 0
                Von MichaelK am Di, 31. Juli 2007 um 18:07 #
                Hallo,

                >> Abgesehen davon, dass objektorientierte
                >> Datenstrukturen in eine relationale
                >> Datenbank zu speichern ohnehin mit
                >> auspeitschen bestraft werden sollte.
                > Du machst also in RoR keinen Gebrauch
                > von ActiveRecord?
                ActiveRecord ist nett. Aber wie gesagt. Für Objektstrukturen die über eine Tabelle hinaus gehen, nimmt man dann doch lieber was anderes.
                Abgesehen davon, dass ich Rails nicht verwende, da ich schon sowas brauchte, bevor es Rails gab. Und von daher war ich auf solche vorgefertigten Konstrukte auch nicht angewiesen.

                Gruß
                MichaelK

                [
                | Versenden | Drucken ]
              0
              Von elBarto am Di, 31. Juli 2007 um 10:23 #
              Ich finde EJB3 toll. EJB 1-2.1 habe ich gehasst und wollte eigentlich nie wieder was mit EJBs zu tun haben, wegen der unnötigen Komplexität und der XML-Hölle vor allem. Das ist auch der Grund (xml) warum ich persönlich Spring nicht mag - obwohl da auch bereits Besserung in Sicht ist. In meinem jetzigen Projekt habe ich noch keine einzige Zeile XML geschrieben. Schau dir am besten irgend ein Tutorial zum Thema EJB3 an, dann werden die Vorteile schon offensichtlich.

              Standards sind nicht immer wichtig. Manchmal kann man sie vernachlässigen und manchmal sind sie unentbehrlich. Selbst wenn z.B. JDBC nicht perfekt ist, es ist trotzdem ein Segen, dass es diese einheitliche Schnittstelle gibt. Beim Entwickeln benutze ich z.B. Derby und dann läuft das Projekt ohne Änderungen auf Oracle und MSSQL-Server und das ist nur Möglich, weil Hibernate/Toplink/JPA/... auf JDBC aufsetzen. Ich kenne keine ordentliche Datenbank fuer die es keinen JDBC-Treiber gibt. Wie gesagt, selbst fuer MSSQL-Server gibt es mehrere verschiedene.
              Aber es ist z.B. reine Geschmackssache welches Web-Framework man benutzt, weil sie alle eh nur auf dem Servlet-Container laufen. Hey "wait a minite", da haben wir es schon wieder, Servlets sind standardisiert (Java EE), was ganz sicher dazu beigetragen hat, dass es so viele Web-Frameworks gibt und einige sich so gut durchsetzen konnten.

              Standards werden ja nicht einfach so von irgendwem verabschiedet, Standards sind "common sense". Oft liegen JSRs fertige Implementierungen zugrunde - die Leute, die diese Software entwickelt haben, wollen dass ihre Software standardisiert wird bzw. dass die Ideen Anerkennung finden. Es ist ja nicht so, dass Sun hinter allen Standards steckt. Und es wird auch niemand ausgeschlossen. In der JSR für JSF2 sitzt z.B. Howard L. Ship der Kopf hinter dem Tapestry framework und im JSR für Java EE6 macht kein geringerer als Rod Johnson mit.

              Du hast natürlich Recht, in vielen Firmen treffen falsche Leute die Entscheidung. Das nennt man dann (analog zu Test-Driven-Development) Asshole-Driven-Development, aber das gibt es leider in allen Branchen. Marketing-Leutchen fallen nun mal gerne dem Hype zum Opfer. Zur Zeit muss eben alles AJAX und SOA sein.

              Und noch meine persönliche Meinung zu der Sprache Java selbst. Ich persönlich bin zufrieden damit aber ich habe auch Verständnis dafür, dass es Leute gibt, die neue Features haben wollen. Das Problem ist nur, dass man genau überlegen muss ob man einfach so neue Features in eine vorhandene Sprache einbauen soll oder nicht, weil dadurch auch viel Schaden entstehen kann. Ich bin inzwischen der Meinung, dass es einfacher ist eine neue Sprache zu entwickeln, als eine alte zu vergewaltigen. So kann man am einfachsten alle glücklich machen. Es können mehrere Sprachen auf einer Plattform existieren. Ich spiele zur Zeit ein wenig mit Scala, ist eine wirklich schöne Sprache für die Java-Plattform. http://www.scala-lang.org/

              [
              | Versenden | Drucken ]
              • 0
                Von MichaelK am Di, 31. Juli 2007 um 19:18 #
                Hallo,

                > Ich finde EJB3 toll. EJB 1-2.1 habe ich
                > gehasst und wollte eigentlich nie wieder
                > was mit EJBs zu tun haben, wegen der
                > unnötigen Komplexität und der XML-Hölle
                > vor allem. Das ist auch der Grund (xml)
                > warum ich persönlich Spring nicht mag -
                > obwohl da auch bereits Besserung in Sicht
                > ist. In meinem jetzigen Projekt habe ich
                > noch keine einzige Zeile XML geschrieben.
                Ich habe diesen XML-Hype sowieso nie verstanden. In verschiedensten Projekten (also ich spreche jetzt allgemein und nicht nur von Web oder Java) kam man auf die "tolle" Idee selbst popligste Konfigurationsdateien mit XML zu machen. XML hat durchaus seine Vorteile. Aber dieser Drang es wirklich überall einsetzen zu wollen jenseits von Sinn und Verstand, dass habe ich nie kapiert.

                > Standards sind nicht immer wichtig. Manchmal
                > kann man sie vernachlässigen und manchmal
                > sind sie unentbehrlich.
                Heutzutage muss man ja fast schon jemand als qualifiziert bezeichnen, wenn er richtigerweise Standard statt Standart schreibt. Insofern erstmal Lob an Dich. ;-)
                Ja. Standards sind durchaus wichtig. Stell Dir mal vor, es gebe zum Beispiel bei Schrauben keinen Standard wie das metrische Gewinde, um mal 'n simples Beispiel zu nennen (obwohl selbst daran halten sich nicht alle; sieht man ja am Airbus wo sich die Britten weigern metrisches Gewinde zu benutzen was dann dazu führt, dass am linken Flügel komplett andere Schrauben verwendet werden als am rechten Flügel; aber ok, dass iss ne andere Geschichte).
                Aber eben nicht überall machen sie Sinn. Vorallem dann nicht, wenn eben nicht das Beste bei herauskommt.

                > Standards werden ja nicht einfach so von
                > irgendwem verabschiedet, Standards sind
                > "common sense".
                Naja. Gerade bei Java war es bisher so, dass Sun gesagt hat, was der Standard ist. Der viel zittierte Java-Community-Process kam eigentlich nur dann wirklich zum tragen, wenn Entwickler abwanderten. Sonst wäre beispielsweise das wichtige NIO schon sehr viel früher drin gewesen (das war eine Forderung die schon seit Java 1.0 bestand). Sun entschied sich stattdessen die Threads zu entwickeln, obwohl schon damals klar war, dass sie geschwindigkeitsmäßig den Multiplexing-Lösungen unterlegen sein würden.
                Sun handelte ja nicht ohne Grund so. Ging es doch darum die Hardwareverkäufe anzukurbeln. Naja. Sei es drum.
                Das sich in den letzten Jahren Sun öffnete und sogar Java unter GPL gestellt, ist eher eine Not als eine Tugend.
                Oder meinst Du es gäbe ein OpenSolaris wenn es Linux nicht gäbe?

                Aber nochmal den Bogen zurück zu den Standards. Ich sehe das speziell bei EJB-Sachen eher unkritisch. Vor allem wenn das benutzte Framework OpenSource ist. Um es zu benutzen, braucht man ja nur beim Kunden die entsprechende JAR-Datei mit dem Framework im Classpath hinzuzufügen. :-)
                Ok. Ganz so einfach ist es nicht. Aber ich wollte nur verdeutlichen, dass sich solche Lösungen relativ unproblematisch ins Kundensystem integrieren lassen. Das ist vorallem dann vertretbar, wenn Lösungen die auf den offiziellen Standard beruhen sehr viel mehr Entwicklungszeit benötigen und daher sehr viel teurer sind.

                > [JDBC]
                Ja. Inzwischen gibt es zum Glück Frameworks die das eklige JDBC kapseln. Gerade in den Anfangszeiten war JDBC nur zu verwenden, wenn man inoffizielle APIs (ihr wisst schon; die Packages die mit sun. anfangen) benutzte. Auch später noch waren teilweise umfangreiche Anpassungen nötig, wenn man sein Programm auf einer anderen Datenbank laufen lassen wollte (gerade wenn man Software an Kunden liefert, wollen die nachvollziehbarer Weise keine neue Datenbank dafür, sondern ihre Vorhandene verwenden). Das sollte eigentlich die Aufgabe von JDBC sein. JDBC als ODBC-Alternative für Java (so kam es mir jedenfalls vor) macht dagegen keinen Sinn.

                > [Servlets]
                Witzigerweise verwendete ich für meine ersten Servlets eben nicht den Servlet-Container von Sun. Es gab auch kein Freien. Erst mit der Freigabe von Tomcat wurde die Situation besser.

                > Du hast natürlich Recht, in vielen
                > Firmen treffen falsche Leute die
                > Entscheidung. Das nennt man dann
                > (analog zu Test-Driven-Development)
                > Asshole-Driven-Development, aber das
                > gibt es leider in allen Branchen.
                > Marketing-Leutchen fallen nun mal gerne
                > dem Hype zum Opfer. Zur Zeit muss eben
                > alles AJAX und SOA sein.
                Ja. Letztlich ist AJAX nur eine Krücke um bisherige Unzulänglichkeiten zu überwinden. Dabei standen alternative Möglichkeiten schon lange in den Startlöchern und haben sich aber dann eben nicht durchgesetzt.
                Außerdem führt AJAX viele Grundgedanken von Browser und HTML ins ad absurdum. Das fängt schon bei simplen Sachen wie den Zurück-Button an, der eben nicht mehr wie gewohnt funktioniert (bzw. dann noch mehr Krücken vom Programmierer gebastelt werden müssen) oder Lesezeichen/Favoriten setzen. Oder das man den Webserver pollen muss statt einfach ein Event zu bekommen. Argh.
                Spätestens wenn der Benutzer Javascript ausgeschaltet hat (Sicherheitsgründe) geht gar nichts mehr.

                > Und noch meine persönliche Meinung zu der
                > Sprache Java selbst. Ich persönlich bin zufrieden
                > damit aber ich habe auch Verständnis dafür, dass
                > es Leute gibt, die neue Features haben wollen.
                > Das Problem ist nur, dass man genau überlegen
                > muss ob man einfach so neue Features in eine
                > vorhandene Sprache einbauen soll oder nicht,
                > weil dadurch auch viel Schaden entstehen kann.
                Ja. Erweiterungen sollten natürlich schon irgendwie zum Konzept der Sprache passen.
                Trotzdem (oder vielleicht gerade deshalb) verstehe ich nicht den Hype um Java nicht, wo erst jetzt die Features kommen, wo andere Sprachen schon vor Jahren waren.

                > [Scala]
                Ja. Ist durchaus nett. Vor allem die statische Typisierung. Aber im Prinzip gibts da nichts, was ich als herausragend bezeichnen würde. Eine YAL (Yet Another Language). Aber vielleicht kannst Du mir ja mehr dazu erzählen.

                Gruß
                MichaelK

                [
                | Versenden | Drucken ]
          0
          Von elBarto am Di, 31. Juli 2007 um 00:22 #
          Ich finde man sollte zwischen der Sprache Java und der Java-Plattform unterscheiden. Die Sprache ist nur ein kleiner Bestandteil davon. Wenn man die Sprache nicht mag, kann man genau so gut eine andere Sprache benutzen.

          Ich finde man sollte immer versuchen die Stärken verschiedener Technologien nutzten. Ist Ruby eine Konkurrenz für Java? Für die Sprache Java vielleicht, aber für die Java-Plattform kann Ruby und andere Sprachen eine Bereicherung sein.

          Bei uns in der Firma wird zur zeit eine RoR-Software entwickelt (ich arbeite leider nicht dran), diese Software läuft auf einem Java App-Server und ist ein Frontend für ein bestehendes System. Funktioniert fantastisch. Dank RoR geht die Entwicklung schnell voran und man nutzt weiterhin die Power des App-Servers. Selbst Sun hat das inzwischen erkannt, JRuby-Entwickler sind bei Sun angestellt und Netbeans 6 bringt sehr guten Ruby-Support mit - die beste Ruby-IDE, die ich bisher gesehen habe.

          Anderes Beispiel, man kann mit Quercus (http://www.caucho.com/) viele bekannte PHP-Anwendungen auf Java-Servern laufen lassen. Wir setzen erfolgreich Drupal und MediaWiki ein.

          [
          | Versenden | Drucken ]
          • 0
            Von MichaelK am Di, 31. Juli 2007 um 19:25 #
            Hallo,

            > Ich finde man sollte zwischen der Sprache
            > Java und der Java-Plattform unterscheiden.
            > Die Sprache ist nur ein kleiner Bestandteil
            > davon. Wenn man die Sprache nicht mag, kann
            > man genau so gut eine andere Sprache benutzen.
            Jo. Und das schon eine ganze Weile. Beispielsweise Python und Scheme liefen schon auf der JavaVM 1.1.

            Dem Rest kann ich Dir im Großen und Ganzen zustimmen.

            Gruß
            MichaelK

            [
            | Versenden | Drucken ]
      0
      Von abcdewi am Mo, 30. Juli 2007 um 19:06 #
      Halbwissen so weit das Auge reicht.
      [
      | Versenden | Drucken ]
      • 0
        Von MichaelK am Mo, 30. Juli 2007 um 21:00 #
        Hallo,

        > Halbwissen so weit das Auge reicht.
        Selbst wenn es so wäre: Laut Deinem Beitrag hast Du noch nicht mal Halbwissen.

        Gruß
        MichaelK

        [
        | Versenden | Drucken ]
        • 0
          Von Jens am Mo, 30. Juli 2007 um 21:15 #

          > Selbst wenn es so wäre: Laut Deinem Beitrag hast Du noch nicht mal Halbwissen.

          ... und dann noch beleidigt sein!

          [
          | Versenden | Drucken ]
          • 0
            Von MichaelK am Mo, 30. Juli 2007 um 22:11 #
            Hallo,

            > ... und dann noch beleidigt sein!
            Nein. Ich würde mir nur wünschen mal etwas konkreter zu werden als nur einfach bloß so 'n Satz hinzuschreiben. Solche "Kritik" kann man wohl kaum ernst nehmen.

            Gruß
            MichaelK

            [
            | Versenden | Drucken ]
0
Von zugführer am Mo, 30. Juli 2007 um 10:30 #
ich finde den Workshop richtig gut und bin schon gespannt auf den zweiten Teil!
Diejenigen die sich durch diesen Workshop Appetit geholt haben, können sich
auf http://www.rubyonrails.de nach weiterführenden Büchern informieren.
[
| Versenden | Drucken ]
  • 0
    Von ror am Mo, 30. Juli 2007 um 14:03 #
    gut gemacht, weiter so!
    [
    | Versenden | Drucken ]
    • 0
      Von Sascha Kersken am Mo, 6. August 2007 um 06:35 #
      Thank you, guys :-).

      Der zweite Teil kommt ca. im November. Der Workskop wurde ursprünglich für die GUUG-Mitgliederzeitschrift UpTimes geschrieben (siehe http://www.guug.de/). Da die Herbstausgabe ein Sonderheft zu den LDAP- und IPv6-Konferenzen in Köln wird, erscheint der nächste Teil erst in der Winterausgabe, und somit auch hier ungefähr zu diesem Zeitpunkt.

      Gruß
      Sascha

      [
      | Versenden | Drucken ]
0
Von cassiel am Mo, 30. Juli 2007 um 22:28 #
Bis zum Taschenrechner war's ja noch übersichtlich und auch für einen (vergleichsweise) Laien wie mich verständlich, aber dann hob es so langsam ab und wurde immer weniger nachvollziehbar. Und als dann die Installation von Rails scheiterte, da war der Workshop und ich mit dem Latein und der Lust am Ende. Irgendwie setzt das immer noch zuviel Know-how voraus. Vor allem die vielen Fallstricke, wenn eben mal was nicht so klappt wie beschrieben, dann wird's haarig.
Muss dann doch bei LAMP bleiben.
[
| Versenden | Drucken ]
  • 0
    Von MichaelK am Mo, 30. Juli 2007 um 23:12 #
    Hallo,

    LAMP nimmt doch keiner mehr. Jeder Webentwickler, der was auch sich hält nimmt WIMA (Windows, IIS, MS-SQL-Server, ASP.NET).

    LAMP ist für Hobbyseiten a-la das-bin-ich-und-das-ist-mein-hund.de
    Wer professionelle Webseiten erstellen und darüber hinaus Geld verdienen will, der kommt an WIMA nicht vorbei. ;-)

    Gruß
    Steve B.

    [
    | Versenden | Drucken ]
    0
    Von Sascha Kersken am Mo, 6. August 2007 um 06:25 #
    Hi,

    was genau hat denn bei der Rails-Installation nicht funktioniert? Wenn du eine etwas detailliertere Fehlerbeschreibung als "klappt nicht" liefern könntest, wäre das Problem sicher leicht zu beheben ...

    Gruß
    Sascha

    [
    | Versenden | Drucken ]
mehr MVC
0
Von MichaelK am Mo, 30. Juli 2007 um 23:28 #
Hallo,

MVC ist gut und nett, aber sollte das nicht darüber hinwegtäuschen, dass es trotzdem noch zahlreiche Probleme gibt. So war ja MVC ursprünglich nicht fürs Web (zustandsloses HTT-Protokoll) gedacht, wenngleich man auch hier MVC realisieren kann wie Rails (aber auch etliche Java-Frameworks) schön zeigen.
Nur damit allein ist es noch nicht getan. Auch auf den Aspekt sollte man vielleicht eingehen. Zudem ist je nach Webanwendung MVC nicht immer optimal. Daher immer auch die Frage, wie stark das Framework den Weg vorgibt und ob ein Abweichen davon im Fall des Falles möglich ist (ok; wenngleich sich dann natürlich die Frage stellt, warum man in dem Fall ein MVC-Framework nehmen sollte; aber Frameworks bieten ja mehr an als nur die MVC-Funktionalitäten).

Gruß
MichaelK

[
| Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung