[linux-l] PHP 4.3.x auf Redhat 7.1 und andere Dinge

[Steffen Dettmer]

* Christian Boulanger wrote on Fri, Dec 12, 2003 at 13:16 +0100:
> Steffen schrieb:
> 
> >Ich hab den Eindruck, daß gerade bei Scriptsprachen gern mal
> >probiert wird. Genau wie die Jungs mit den High-Tech IDEs (Visual
> 
> Da hast Du recht, und ich glaube, ich schreibe auch eher so. Bin eben
> kein Programmierer, sondern Freizeitskripter, ohne Verantwortung
> gegenüber einem Arbeitgeber oder einem Entwicklungsteam. (hoffentlich
> trotzdem hier nicht falsch).

Ist ja bei "Freizeitprojekten" und so auch prima! Man hat ja
keine Gewährleistung, keinen Termindruck oder harte externe
Anforderungen und selten mehrere Leute oder lange
Wartungs/Lebensphasen. Wie gesagt, ein 2000 Zeilen Projekt kann
man noch "hacken", daß überschaut man dann schon irgendwie, aber
wenn man 100 Module a 1000-2000 Zeilen hat oder so, funktioniert
das nicht mehr. Hat man aber privat ja selten :-) Und wenn man
sowas über drei Major-Versionen in drei Jahren hin warten kann,
ist man kein Freizeitskripter mehr, sondern wohl ein erfahrener
Praxis-Entwickler.

> >Ja, das wird aber auch nicht direkt kommuniziert. Ich dachte
> >immer, PHP(4) sei OO, aber das stimmt nicht. Es gibt Rudimente
> >davon. Damit darf man IMHO nicht arbeiten, weil es bekloppt ist,
> 
> Das war ein Grund, warum ich angefangen habe, die Programmlogik in
> Java-Script auf dem Client zu verlagern, und mir die Sprache so gut
> gefiel (obwohl sicher professionellen Programmierern die Haare zu Berge
> stehen) - ist ja alles relativ!!! 

Na ja, ich fand JavaScript damals gar nicht so schlecht, nur ist
es eben doch wieder Browserabhängig... Eine einfache Sprache, die
ein paar gute Konzepte wie Perl hat, mit der man sich sogar sowas
wie Refelection bauen kann, wenn man denn möchte. Allerdings ist
hier die Umgebung wieder schwierig, weil so Webseiten gebunden.
Wenn man richtige Datenstrukturen braucht, die seitenübergreifend
funktionieren soll, und der Kram nicht "abstürzen" soll, wenn den
Benutzer Mist macht oder "zurück" klickt, kann die
Fehlerbehandlung schnell wieder extrem nervig werden.
Modularisierung geht auch nur mit "Krücken". Also auch hier: ein
paar tausend Zeilen gehen noch, wenn man was komplexeres braucht,
ist es wohl nicht mehr die ideale Sprache - aber dafür ist's ja
auch nicht gedacht!

> Es schein so wenig Sinn zu machen, in PHP ein Objekt zu
> definieren, was nur für eine Sitzung besteht oder mühsam
> serialisiert/deserialisiert werden muss. 

Na gut, das kommt von der Umgebung; schließlich "läuft" Dein
Programm ja nur *zwischen* den Benutzerinteraktionen, daß ist
damit grundlegend anders als klassisch-algorihmisches Entwicklen
(wo man sagen kann: nimm menüauswahl und zeig das an, frage "Sind
Sie sicher", bei Ja rufe Funktion A). Dadruch wird das schnell
aufwendig und schnell ne "GOTO" Programmierung: je nach dem,
welche Seite der Benutzer wählt, muß hier oder da reingesprungen
werden; der Benutzer kann durch Browserhistory etc. beliebig
springen, z.B. bei "Sind Sie sicher" ne ganz andere Seite
anschließend laden. Nervig.

Ich denke, hier könnte man mit ereignisorientierter Methodik was
machen, was aber auch keine so sehr einfache Technik ist, und
vermutlich auch nicht so richtig zu PHP paßt.

Am Ende kommen dann oft Scripte im Schema:
1. Lade alle Session-Daten
2. Prüfe Daten
3. Lade Benutzerdaten
4. Prüfe Benuzterdaten
5. wende Benutzerdaten auf Session-Daten an
6. Speichere neue Session-Daten (komplett)
7. erzeuge Ausgabe
8. sende Ausgabe und Ende

Wie bekloppt das eigentlich ist, merkt man, wenn man z.B. eine
Variable einfach nur nach einer Sicherheitsabfrage auf "0" setzen
möchte (z.B.). Man macht die 8 Punkte, 99% davon braucht man
eigentlich nicht, irgendwie programmiert man einen Haufen Sachen,
in dem das unter geht, was man eigentlich meint: nämlich

if (dialog.confirm("Sind Sie sicher") == YES) {
  variable = 0;
}

und hat dafür plötzlich viel Code (sind zwar nur drei Funktionen
vorher und drei hinterher, aber ist mindestens langsam) der
ausgeführt wird. Das kann nicht KISS sein :-)

> Eine Verkettung von Objekten nach dem Muster
> $main->instance->subobject->method() geht glaube ich auch
> nicht, oder erst in PHP5. 

humpf, nichtmal sowas?! Mal abgesehen davon, daß sowas eigentlich
im Allgemeinen schlechter Stil ist, es verletzt das
Geheimnisprinzip, das Orthoginalitätsprinzip und das KISS
Prinzip. Warum muß "main" wissen, daß "subobject" eine "method"
hat? Wenn ihm "instance" gehört, sollte main instance->method
aufrufen. Instance weiß dann, daß es subobject->method aufrufen
muß. Ist subobject später zusammengesetzt oder heißt anders oder
wird durch was anderes ersetzt, muß man nur instance ändern, und
auch nicht noch main. Das hat auch einen Namen... <blätter...>
ahh, das "Demeter-Gesetz".

Sowas kann man übrigens alles in "Der Pragmatische Programmierer"
nachlesen, welches ich gerade so bißchen nebenbei lese. Gefällt
mir gut, das Buch, ist schön pragmatisch :) ISBN 3-446-22309-6.

> Ich benutze (noch) ein in JavaScript
> geschriebenes (!) GUI (http://www.netwindows.org), überlege
> aber gerade, auf http://www.xwt.org/ umzusteigen, weil ich
> weiterhin in JavaScript clientseitig programmieren könnte.

Kenn ich beides nicht, wirkte aber interessant. Client-Server
Applikationen sind auch so gut wie nie einfach, weil man sich mit
bestimmten Dingen auseinandersetzen muß, die sonst beim "Hacken"
untergehen können, ohne das was passiert; beispielsweise
Nebenläufigkeit (was man der Server, während der Client...). Das
führt sofort zu Synchronisationsfragen, Persistenz und weiß ich
was noch alles.

Oft kann man sich das Leben einfacher machen, wenn man einen
"thin client" entwickelt, also etwas "ohne Intelligenz". Das
prüft vielleicht noch, ob die Zahl wirklich ne Zahl ist, aber den
Rest überläßt er dem Server. Für so einen Thin-Clienten in
kleineren Projekten mag JavaScript eine interessante Sprache
sein, vielleicht bei nächst größeren Dingen auch
Client-side-Java. Ist vermutlich beides einfacher und klarer, als
so Sessionbasierte PHP Programmierung auf einer "HTML RPC"
Plattform.

> > > Programme in C sind nichts für ein breiteres Publikum 
> 
> schreiben, die sich mit einem Minimum an Zeit (und Ahnung!) auf
> billigen Providern installieren lassen (Siehe z.B.

Ahh! Ja, das kann schnell nervig werden. Komischerweise bekommt
man PHP an jeder Ecke, einen passenden C-Compiler und ne Shell zu
kriegen, ist schon schwieriger, ja.

> http://www.panya.de/bibliograph/ oder

mmm.. Geht wohl gerad nicht.

> Deswegen fällt C aus, weil fast kein Politikwissenschaftler
> weiß, was ein Compiler ist. Aber ein FTP- Programm können
> einige bedienen, und etwas Webspace mieten, und einen Ordner
> hochladen. Schon die Access rights zu verändern macht meinem
> "Zielpublikum" schwierigkeiten...

mmm... Versteh eigentlich nicht so ganz, warum ein
Politikwissenschafler mit FTP Programmcode hochladen sollte. Der
kriegt doch ne URL einer Installation? Aber erstaunlich, daß das
anscheinend mit PHP in der Praxis funktioniert. Wüßte nichtmal,
wie ich so ohne weiteres einen brauchbaren Backupmechanismus
machen sollte. Bei einem "normalen" Server kann man ja einfach ne
Datei schreiben und die täglich wegkopieren oder so.

> >> An Java reizt natürlich das "Cross Platform",
> >C/C++ ist IMHO auch "Cross Platform". Gut, man muß
> >neukompilieren, wie auch bei Java, aber der Code ist der gleich
> >(bzw. man bekommt es hin). 
> 
> Ja, C++ und Qt, z.B., scheint ja wirklich ein tolles Duo zu sein. 

Ach so, GUIs, ja, vergessen. Stimmt, *hier* ist Java IMHO
wirklich "besser" (hängt natürlich davon ab und vom Wetter und
überhaupt ;)). JavaSwing find ich wirklich Klasse (nur leider
bissel langsam). GUIs in Swing machen Spaß, finde ich, weil es
schön, klar und relativ sauber ist.

> Das interessiert mich am meisten: Software, die im Browser
> läuft und ein RPC-Backend hat, egal in welcher Sprache. Damit
> hat sich dann doch jegliche Plattformabhängigkeit vollständig
> verflüchtigt, und man kann sich auf das Lösen von Problemen
> konzentrieren. 

Yo, prima, sehr professioneller Ansatz!

Ich hab ähnliche Aufgaben in meiner Arbeit gehabt. Für "im
Browser" läuft konnten wir (zum Glück) argumentieren, daß Java
per JavaWebStart ja "im Browser läuft" (also, nicht wirklich,
aber der Benutzer klickt einen Link, und das Teil geht dann auf,
darauf kommt's ja an), für RPC hab ich CORBA genommen (vielleicht
auch, weil ich nix anderes kann, und CORBA natürlich nur
rudimentär). War auch gut so, inzwischen gibt's nicht nur
"polling" in irgendwelchen Formen (also RPC von Client->Server),
sondern auch "pushing" (Server->Client), weil das sonst einfach
zu viel Performance verballert hatte. Das ist ein Vorteil von
clientside Java <- CORBA -> serverside irgendwas; man ist offen
für ne Menge neue Anforderungen (von denen ja 10 vor der ersten
Beta kommen :-)).

> Und danke für die Hinweise zu Sicherheitslücken von PHP, vieles
> davon wusste ich tatsächlich noch nicht.

Na ja, sowas hat man meistens, darf man auch nicht überbewerten,
finde ich, besonders, wenn der ISP das Problem hat :) Bloß
Backups sollte man machen.

> Tolle Liste, ich verstehe nicht alles, aber lerne viel dazu!

Prima, geht mir genauso!

oki,

Steffen

-- 
Dieses Schreiben wurde maschinell erstellt,
es trägt daher weder Unterschrift noch Siegel.