Re: Ruby, Fanboys und Anwendungsfälle

[Robert Klemme]

On 08/04/2012 11:07 AM, Oliver Sch@d wrote:

> Für welche Strukturgrößen seht ihr Ruby?

Ich habe keine Erfahrungen mit großen Ruby-Projekten aber eine gewisse
Skepsis gegenüber der Bedeutung statischer Typisierung und anderer
Dinge, die es z.B. in Java gibt und in Ruby nicht. Ich habe schon zu
viel schlechten Java-Code gesehen, der auch durch die größere Striktheit
nicht verhindert wurde. Wenn man Software mal betrachtet, stellt das
Schreiben von Programmcode nur einen kleinen Teil der Arbeit dar (da
wären noch: Anforderungsanalyse, Design, Tests, Dokumentationen...).
Und wenn es in diesem eher kleinen Teil eine Erleichterung gibt, dann
muss das für das gesamte Projekt gar nichts bedeuten.

> Gibt es Aspekte, die man zudem noch dringend mitbetrachten sollte beim
> Einsatz?

Ja. Im Ernst: so allgemein kann man das schwer beantworten.

Ciao

robert

[Robert Klemme]

On 04.08.2012 13:24, Oliver Sch@d wrote:
> Robert Klemme wrote:

> Ich hab z.B. auch eine ganze Zeit C und C++ gemacht. Cool war, dass ich
> mir ein Header-File schnappen konnte und wusste was erwartet wird. Ich
> musste keinen Code lesen dafür, ich hatte eine Blackbox + Header.
>
> Das halte ich für große Projekte für recht hilfreich, dass man an
> irgendeiner Stelle sagen kann: Blackbox, Schnittstelle ist hier, fertig.

Das Vorgehen ist _generell_ hilfreich, weil es hilft, Code zu strukturieren.

> In Ruby sehe ich, dass man strukturell oft dafür dann HTTP-
> Schnittstellen verwendet, um darüber ein API bereitzustellen, weil
> andere Mechanismen nicht vorhanden sind.

Du wirfst Dinge durcheinander: HTTP wird für Verteilung (im Netzwerk)
benutzt. Ein C-Header definiert die Schnittstelle (oder sogar mehr)
eines Moduls (wobei die Sprache kein explizites Modulkonzept hat - im
Gegensatz zu C++, wo man Klassen als Module betrachten kann). Natürlich
stellt beides eine API zur Verfügung, aber man würde in Ruby sicherlich
keine Schnittstelle über HTTP bereitstellen, wenn Verteilung nicht
erforderlich ist.

>>> Gibt es Aspekte, die man zudem noch dringend mitbetrachten sollte
>>> beim Einsatz?
>>
>> Ja. Im Ernst: so allgemein kann man das schwer beantworten.
>

> Ich gebe zu, dass das alles eine ziemlich abstrakte Betrachtung ist.
> Aber nehmen wir mal an, du bist Software-Architekt und musst ein großes
> Projekt organisieren. Wie entscheidest du dich für eine Technik, wenn
> nicht auf einem abstrakten Betrachtung?

Ich denke über die Anforderungen des konkreten Projektes nach.

Ciao

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/

[Robert Klemme]

On 04.08.2012 15:18, Oliver Sch@d wrote:
> Robert Klemme wrote:
>
>> On 04.08.2012 13:24, Oliver Sch@d wrote:
>>> In Ruby sehe ich, dass man strukturell oft dafür dann HTTP-
>>> Schnittstellen verwendet, um darüber ein API bereitzustellen, weil
>>> andere Mechanismen nicht vorhanden sind.
>>
>> Du wirfst Dinge durcheinander: HTTP wird für Verteilung (im Netzwerk)
>> benutzt. Ein C-Header definiert die Schnittstelle (oder sogar mehr)
>> eines Moduls (wobei die Sprache kein explizites Modulkonzept hat - im
>> Gegensatz zu C++, wo man Klassen als Module betrachten kann).
>> Natürlich stellt beides eine API zur Verfügung, aber man würde in Ruby
>> sicherlich keine Schnittstelle über HTTP bereitstellen, wenn
>> Verteilung nicht erforderlich ist.
>

> Wie baust du sonst in Ruby eine unabhängige Blackbox mit definierter
> Schnittstelle?

Definiere "unabhängig". Grundsätzlich genau so wie in C++: Namespaces,
Klassen etc.

>>> Ich gebe zu, dass das alles eine ziemlich abstrakte Betrachtung ist.
>>> Aber nehmen wir mal an, du bist Software-Architekt und musst ein
>>> großes Projekt organisieren. Wie entscheidest du dich für eine
>>> Technik, wenn nicht auf einem abstrakten Betrachtung?
>>
>> Ich denke über die Anforderungen des konkreten Projektes nach.
>

> Wenn große Projekte starten, haben sie die Eigenart, dass über die
> Details wenig bekannt ist. Man hat ein großes Ziel, einige wenige
> konkrete Anforderungen und muss nun anfangen. Zumindest, wenn man im
> Webbereich arbeitet, ist das regelmäßig genauso der Fall.

"Webanwendung" ist ja schon viel konkreter. Das schränkt die Anzahl
sinnvoller Architekturen deutlich ein.

> So was in der Art wie "wir wollen eine große Börse im Web für
> $DIENSTLEISTUNG machen".
>
> Dir ist vielleicht klar, welche Akteuere es gibt (Leute, die was
> einstellen, Leute, die was an der Börse beziehen wollen), es gibt
> Buchhaltung, Marketing, BI usw.

Admin...

> Es gibt vielleicht schon ein Grob-Web-Design und ein paar Abläufe in
> Grobdarstellung, der Rest wird dann noch gefunden, im laufenden Produkt-
> Management.

An der Stelle scheinen mir eher andere Informationen ausschlaggebend für
die Wahl der Architektur bzw. des Frameworks, z.B. erwartete
Benutzerzahl und parallele Sessions, Lastprofil (Änderungen vs.
Lesezugriffe), Datenvolumen... Solche Dinge müssen auf jeden Fall klar
sein - sonst fängst Du mit einer Plattform für 100 Benutzer an und
nachher meint der Kunde, dass da aber mal 5 Millionen drauf sein sollen.

> Danach kannst du Leute suchen gehen, die dir helfen das Projekt
> umzusetzen, denn viel konkreter wird es erst im laufenden
> Produktmanagement, was aber dann schon mit Entwicklern, die irgendeine
> Sprache beherrschen oder aber auch nicht, zusammen geschieht.
>
> Welche Sprache nimmst du jetzt und warum?

Wenn das Team nicht von vornherein feststeht, hast Du in gewisser Weise
eine Catch 22-Situation: ohne die Skills zu kennen, kannst Du kein
Framework / Platform / Sprache / Technologie auswählen - ohne die
Technologie weißt Du nicht, welche Leute Du anheuern sollst.

Dann ist es sinnvoll zweigleisig vorzugehen: zum einen schauen, welche
Fähigkeiten am Markt angeboten werden (es sei denn $DIENSTLEISTUNG ist
die Börse für Entwickler, die Dir erst die Marktübersicht geben würde
:-)) und welche bekannten Frameworks gut zu den Anforderungen passen.
Dann versuchen einen Best-Match herzustellen.

> Und wenn du das für unrealistisch hälst - das ist in meiner Welt Alltag,
> dass es genauso läuft.

Blöd. Ein stabiles Team ist auf jeden Fall produktiver - und ich bin
außerdem davon überzeugt, dass es bessere Qualität liefert (z.B. weil
die Leute nicht am Ende des Projektes auseinander gehen und dadurch mehr
Verbindlichkeit herrscht).

[Robert Klemme]

On 08/05/2012 01:06 AM, Oliver Sch@d wrote:
> Robert Klemme wrote:
>
>> On 04.08.2012 15:18, Oliver Sch@d wrote:
>>> Welche Sprache nimmst du jetzt und warum?
>>
>> Wenn das Team nicht von vornherein feststeht, hast Du in gewisser
>> Weise eine Catch 22-Situation: ohne die Skills zu kennen, kannst Du
>> kein Framework / Platform / Sprache / Technologie auswählen - ohne die
>> Technologie weißt Du nicht, welche Leute Du anheuern sollst.
>>
>> Dann ist es sinnvoll zweigleisig vorzugehen: zum einen schauen, welche
>> Fähigkeiten am Markt angeboten werden (es sei denn $DIENSTLEISTUNG ist
>> die Börse für Entwickler, die Dir erst die Marktübersicht geben würde
>> :-)) und welche bekannten Frameworks gut zu den Anforderungen passen.
>> Dann versuchen einen Best-Match herzustellen.
>

> So mache ich es ja letztlich auch, wobei das "gut passen" noch recht
> generisch ist bei den Frameworks, sprich man hält sich Möglichkeiten
> tendenziell offen, um flexibel zu reagieren.

Es gibt ja auch so viele. Im Zweifel ist es wichtiger, Leute zu finden,
die grundsätzlich verstehen, wie Webanwendungen funktionieren, und die
die Sprache beherrschen. Die einzelnen Frameworks muss man sich dann
halt als Teil des Projektes drauf schaffen.

> Worauf ich eingangs hinauswollte war etwas, worauf du noch nicht
> geantwortet hast. Ich stelle die Frage vielleicht mal andersherum: wofür
> ist Ruby im Webbereich nicht oder schlecht geeignet aus deiner Sicht?

Ich habe Ruby in dem Bereich noch fast nicht eingesetzt, insbesondere
bin ich kein Rails-Kenner. Aber ich würde so erst mal sagen, dass Web
eher eine Domäne von Ruby ist - man sieht es ja auch an der Vielzahl von
Frameworks und Unterstützung (Web-Server-Module). Richtig schlecht ist
Ruby m.E. nur bei graphischen Oberflächen.

>>> Und wenn du das für unrealistisch hälst - das ist in meiner Welt
>>> Alltag, dass es genauso läuft.
>>
>> Blöd. Ein stabiles Team ist auf jeden Fall produktiver - und ich bin
>> außerdem davon überzeugt, dass es bessere Qualität liefert (z.B. weil
>> die Leute nicht am Ende des Projektes auseinander gehen und dadurch
>> mehr Verbindlichkeit herrscht).
>

> Mmh, ich wollte gar keine Aussage über diesen Aspekt treffen. Habe ich
> das?

Nein, aber ich. :-)

robert


PS: Ich finde das wirklich schade, dass das hier zu einem Dialog
verkommt. Wie viele lesen denn hier noch?

[Dominik Schlütter]

Robert Klemme <short...@googlemail.com> schrieb:

> PS: Ich finde das wirklich schade, dass das hier zu einem Dialog
> verkommt. Wie viele lesen denn hier noch?

Ich lese hier beispielsweise noch mit - allerdings kann ich zum Thema
nicht wirklich was beitragen, ich verdiene mein Geld nicht mit
Softwareentwicklung (und habe auch sonst nicht so viel mit derartigen
Großprojekten zu tun).


Gruß,

Dominik.

[Robert Klemme]

On 08/05/2012 02:20 PM, Oliver Sch@d wrote:

> Facebook hat z.B. PHP nach C/C++ kompiliert, damit das funktioniert.
> Wohin kompiliert man eigentlich Ruby?

JRuby. Das funktioniert richtig gut. Und wenn man möchte, kann man
z.B. die üblichen Dinge aus der Java-Welt nehmen (Webserver wie Tomcat
usw., EJB) und Ruby für das Skripten oder die Business-Logik nehmen.

Ciao

robert

[Oliver Sch@d]

Finde ich grundsätzlich keine schlechte Idee das Zusammenstecken einer
Applikation mit JRuby zu machen und die kritischen Teile mit Java, um
Schnittstellen garantieren zu können. Das würde der Idee einer
Skriptsprache auch näher kommen.

mfg
Oli

--
Man darf ruhig intelligent sein, man muss sich nur zu helfen wissen

[Robert Klemme]

On 08/06/2012 08:40 AM, Oliver Sch@d wrote:
> Robert Klemme wrote:
>
>> On 08/05/2012 02:20 PM, Oliver Sch@d wrote:
>>
>>> Facebook hat z.B. PHP nach C/C++ kompiliert, damit das funktioniert.
>>> Wohin kompiliert man eigentlich Ruby?
>>
>> JRuby. Das funktioniert richtig gut. Und wenn man möchte, kann man
>> z.B. die üblichen Dinge aus der Java-Welt nehmen (Webserver wie Tomcat
>> usw., EJB) und Ruby für das Skripten oder die Business-Logik nehmen.
>
> Finde ich grundsätzlich keine schlechte Idee das Zusammenstecken einer
> Applikation mit JRuby zu machen und die kritischen Teile mit Java, um
> Schnittstellen garantieren zu können. Das würde der Idee einer
> Skriptsprache auch näher kommen.

Ich hatte es eigentlich anders herum gemeint (Webserver in Java, Logik
in JRuby), aber das ist natürlich auch eine Möglichkeit. Einbetten von
JRuby in Java und Einbetten von Java in JRuby - beides geht recht
problemlos.

Viele Grüße

robert

[Simon Krahnke]

* Robert Klemme <short...@googlemail.com> (2012-08-06) schrieb:

>On 08/06/2012 08:40 AM, Oliver Sch@d wrote:
>> Robert Klemme wrote:
>>
>>> On 08/05/2012 02:20 PM, Oliver Sch@d wrote:
>>>
>>>> Facebook hat z.B. PHP nach C/C++ kompiliert, damit das funktioniert.
>>>> Wohin kompiliert man eigentlich Ruby?
>>>

>>> JRuby. Das funktioniert richtig gut. Und wenn man m�chte, kann man
>>> z.B. die �blichen Dinge aus der Java-Welt nehmen (Webserver wie Tomcat
>>> usw., EJB) und Ruby f�r das Skripten oder die Business-Logik nehmen.
>>
>> Finde ich grunds�tzlich keine schlechte Idee das Zusammenstecken einer

>> Applikation mit JRuby zu machen und die kritischen Teile mit Java, um

>> Schnittstellen garantieren zu k�nnen. Das w�rde der Idee einer
>> Skriptsprache auch n�her kommen.

>
> Ich hatte es eigentlich anders herum gemeint (Webserver in Java, Logik

> in JRuby), aber das ist nat�rlich auch eine M�glichkeit. Einbetten von

> JRuby in Java und Einbetten von Java in JRuby - beides geht recht
> problemlos.

Wenn das mit C nur so w�re, bin auf LUA ausgewichen.

mfg, simon .... l

[Marc Haber]

"Oliver Sch@d"
<spam.entfernen.und.bring...@oschad.de> wrote:
>Wie seht ihr das?
>Wie erlebt ihr die Community?

>Für welche Strukturgrößen seht ihr Ruby?

>Gibt es Aspekte, die man zudem noch dringend mitbetrachten sollte beim
>Einsatz?

Also, ich erlebe die Community als sehr Spaß- und Coding-orientiert.
Sprich, die Sachzwänge beim Einsatz von Ruby-Software in größeren,
oder gar professionellen Umgebungen werden von der Community genau so
ignoriert wie die Bedürfnisse der Systemadministration, die in vielen
Fällen von denen der Coder abweichen.

So finde ich es beispielsweise nicht akzeptabel, dass bei Gems, die
Schnittstellen zu anderen Gems haben, während der Installation ein
Compiler angeworfen wird - ein Compiler ist auf vielen professionell
betriebenen Produktionssystemen nicht vorhanden und kann auch nicht
installiert werden.

Dann ist mir aufgefallen, dass große Teile der Community das Bauen von
Paketen, die keine Gems sind, als feindlichen Akt werten - nicht
verstehend, dass viele Anwenderorganisationen die Regel haben, dass
Software nur in Form von Distributionspaketen installiert wird. Python
und vor allem Perl unterstützen das Paketieren von Modulen aktiv durch
Bereitstellen einheitlicher Schnittstellen zum Paketbau. Bei Ruby habe
ich eher das Gefühl, dass so eine Einheitlichkeit "nach draußen"
ausdrücklich nicht gewünscht wird, weil das Gem-Format ja der Weisheit
letzter Schluß ist, und wer keine Gems deployed hat es nicht anders
verdient.

Vor diesem Hintergrund bleibt die übliche Entwicklereinstellung fast
nicht zu berücksichtigen. Das, was ich mir aus der Community bei der
Frage nach Paketierungstecniken etc anhören musste, übersteigt bei
weitem das übliche "Was, Du setzt das ein, was wir letzte Woche
released haben und nicht den Entwicklersnapshot von vor zwei Stunden?
Dann musst Du Deine Scherben selbst zusammenkehren!".

Das gesagt: Ich mag Ruby, ich entwickle viele kleine Dinge in Ruby.
Aber die Community braucht dringend ein wenig Professionalisierung,
das kommt alles wie eine zwanglose Entwicklerspielwiese rüber.

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

[Marc Haber]

"Oliver Sch@d"
<spam.entfernen.und.bring...@oschad.de> wrote:
>Aber von den meisten Ruby-Entwicklern auch als Kollegen
>wird man für den Gedanken ein stabiles System betreiben zu wollen
>förmlich ausgelacht.

Mir ist das -gerade- von Kollegen[1] passiert. Ich muss mir echt nicht
von Leuten, die fünfzehn Jahre weniger IT-Erfahrung haben als ich,
sagen lassen, dass es in Ordnung ist, von derselben Bibliothek fünf
verschiedene Versionen auf Produktionssystemen herumdümpeln zu haben,
um mir dann erklären lassen, wie Suchpfade funktionieren.

Grüße
Marc

[1] Ok, keine Kollegen, sondern fest angestellte Softwareentwickler in
der Firma, die ich gerade als Freelancer berate.

[Marc Haber]

"Oliver Sch@d"
<spam.entfernen.und.bring...@oschad.de> wrote:
>Ich kann so oder so nicht verstehen, wie man ohne Build-System den
>ganzen Scheiß ausrollen kann. Das System, wo der Betrieb stattfindet,
>soll keine Dev-Maschine sein, es ist ein Produktionssystem. Wenn man das
>Vorgehen ändert, heißt das ja auch, dass jedes System am Schluss
>individuell ist. Das macht sich im Cluster-Betrieb total super.

Mir wurde Neulich[tm] für den Clusterbetrieb NFS oder rsync empfohlen.

[Robert Klemme]

On 19.08.2012 12:01, Oliver Sch@d wrote:
>> "Oliver Sch@d"

>> Das gesagt: Ich mag Ruby, ich entwickle viele kleine Dinge in Ruby.
>> Aber die Community braucht dringend ein wenig Professionalisierung,
>> das kommt alles wie eine zwanglose Entwicklerspielwiese rüber.
>

> Ich kann deinen Ausführungen nur vorbehaltlos zustimmen. Vieles davon
> kann man natürlich aktiv umschiffen, indem man sich selbst geeignete
> Strukturen baut. Aber von den meisten Ruby-Entwicklern auch als Kollegen

> wird man für den Gedanken ein stabiles System betreiben zu wollen
> förmlich ausgelacht.

Ich meine das Phänomen auch zu beobachten, allerdings bin ich mir nicht
sicher, ob man das auf die Ruby-Community einschränken sollte. Die
ganze Web20-Szene kommt mir oft recht vor wie ein Hort von
Cowboy-Coding. Andererseits ist das u.U. auch einfach eine Reaktion auf
die Anforderungen: gerade im Web-Bereich geht es oft darum, eine
Webseite an eine aktuelle Entwicklung anzupassen und dabei wird dann
Time to Market deutlich höher gewichtet als Robustheit. (Warum auch
nicht, wenn der aktuelle Code in zwei Wochen schon wieder außer Betrieb
ist und man Fehler genau so schnell reparieren kann wie man neue
Versionen deployed?)

Ich muss allerdings dazu sagen, das sind Eindrücke, die ich habe. Ich
arbeite selbst nicht in dem Bereich und nutze Ruby hauptsächlich für
nützliche Automatisierung im Alltag.