Technikwürze – Web Standards Podcast

@marc danke :) Freut mich, dass du es kurzweilig fandest.

Wir schnacken auf jeden fall! Wünsche dir erstmal viel Spaß in Nottingham. Bin leider dieses Jahr nicht dort.

Entschuldigt den Tippfehler im erwähnten Namen. Es muss natürlich Allgeiger heißen.

@basstian: bitte nimm meinen kommentar nicht zu persönlich. Wir können uns gerne mal auf nen analogen oder digitalen kaffee treffen und ausführlicher über das projekt sprechen.

Grüße aus düsseldorf

@Oliver: Ich denke es ist nicht richtig rüber gekommen. Aber wenn man mit Kirby und ohne Datenbank arbeitet, dann heißt das nicht, das es nicht semantisch ist oder gar ohne Struktur. Die klare Datenstruktur wird aber eben nicht über eine Datenbank erzeugt und ist prinzipiell nicht dadurch vorgegeben. Schau es dir einmal an. Strukturiertes Arbeiten ist durchaus möglich.

Ich denke so etwas hat auch deswegen seine Berechtigung, weil man Personen, die mit Datenbanken und deren Nutzung nicht vertraut sind, durchaus aber Computer-Vorkenntnisse haben und sich mit Ordnerstrukturen auskennen, die Chance gibt über Bekanntes eine strukturierte Site ohne Datenbank aufzusetzen und vor allem zu pflegen und zu erweitern.

/marc

@marcel: mit “bei der qualität” beziehe ich mich einzig und allein auf die etwas holprigen Argumentationen von Bastian im Podcast.

Da ich durch euren Technik-Würze Podcast schon öfter auf interessante Entwicklungen aufmerksam geworden bin und Einiges sehr nützlich fand, dachte ich auch mit kirby etwas entdeckt zu haben.

@marc: ok!
Vielleicht muss ich wirklich noch einmal genauer hinsehen um die Vorteile von kirby für mich zu entdecken. Dazu werde ich mir am kommenden Wochenende etwas mehr Zeit nehmen um die Demo zu testen. Da ich sonst immer mit Datenbank-basierten Systemen arbeite, konnte ich es mir nicht wirklich vorstellen ein CMS aus einzelnen Dateien aufzubauen.

Grundsätzlich zolle ich jedem Respekt, der versucht neue Wege zu gehen und in neuen Bahnen zu denken.
@bastian: danke

ich denke dass das angekündigte Backend dazu beitragen kann, die potentiellen Eingabefehler von Redakteursseite zu minimieren und so eine Nutzung des systems für diese noch einfacher werden kann.

Ich werde die Entwicklung von kirby weiterhin verfolgen und bleibe gespannt.

Habe es mir gerade angeschaut und sorry, aber das ist doch der totale Murks. Wie soll das überzeugen es zu nutzen oder gar dafür Geld zu zahlen?? Bin immer noch am Kopf schütteln. :-(

Hi!
Also ich habe den Podcast am Montag gehört. Heute Morgen Bastians Tweet auf Twitter gelesen und musste nun erstmal hier reingucken. (nachdem wir schon ein bisschen auf Twitter geschrieben haben g @joschie)

Also, ich arbeite nun seit einer Woche aktiv mit Kirby. Von der Einfachheit bin ich super begeistert. Und fand toll, dass er nun rein zufällig eine Woche nach dem Entdecken von Kirby, nun bei der Technikwürze ist. Das erste mal von Kirby habe ich bei Technikload gehört.

Ich fand sehr interessant zu hören wie Bastians Gedanken hinter dem System sind. Wie es dazu gekommen ist und wohin er mit Kirby will. Das was er sagt zum System kann ich so unterschreiben. Es ist einfach, jeder kann bei “null” anfangen und ist an nix gebunden. Das ist doch genau das was man will, oder?

Vielleicht ist es gerade diese simple Struktur und Einfachheit die so abschreckt oder verwundert? Vielleicht ist man derzeit einfach nur daran gewöhnt, dass das CMS >5MB groß sein muss, dass man 5 Plugins benötigt, eine Datenbank haben muss, dass man eine halbe Stunde nur für die Konfiguration/Installation des CMS verschwendet?

Ohne HTML/CSS und minimale PHP Kenntnisse ist man relativ aufgeschmissen. Aber ich denke an diese Zielgruppe richtet sich das CMS Kirby gar nicht. Dafür ist Wordpress da… mit den tausenden Plugins und zehntausenden Themes.

Ich werde in Zukunft weiter auf Kirby bauen. Wenn, wie angekündigt, bald noch ein Backend kommt (wann war nun noch mal Release-Datum? :P) bin ich überglücklich (um auch einfach via iPhone einen Blogeintrag zu schreiben).

@Bubka, schade. Unqualifizierter Beitrag, da du scheinbar das System einfach nicht verstanden hast. Man muss nicht alles mögen, ich denke es ist auch keine Pflicht Kirby zu mögen. Aber zu einer Meinung die man sich bildet gehören Gründe – nenne diese einfach und schon wird dein unqualifizierter Beitrag wertvoller, für alle.

Viele Grüße Johannes

Einige Kommentatoren hier können richtige Schmocks sein. Aber das verwundert mich gar nicht, denn das bestätigt genau meine realen Erfahrungen, die ich generell mit Leuten aus der IT Branche mache. Die Werbebranche kommt gleich danach.

@Paul & Verena wo ist der Like-Button, wenn man ihn mal braucht :)

@Verena sag Bescheid, wenn das Projekt startet und du irgendwie Hilfe brauchst.

Grundlegend ein guter Ansatz. Das nette daran ist (ähnlich gehts mir bei Redaxo), dass man als Programmierer viele Sachen individuell umsetzen kann.

Nachteilig bei Kirby erscheint mir das Fehlen von Modulen oder Hooks (was auch Deine Frage beantwortet, warum Systeme immer so umfangreich sein müssen). Um bestimmte Sachen zu implementieren, muss man die Funktion entweder unschön im Template umsetzen/anstoßen oder im Core-Code herumfuhrwerken.

Die Textdatei-basierte Content-Verwaltung scheint mir eher was für Entwickler oder Liebhaber zu sein, leider ist Wysiwyg für Endkunden oft Standard und viele Redakteure sehen sich mit Textile o.ä. schon überfordert.

Ein nächster Knackpunkt – die Asset-Verwaltung. Es können keine Metadaten o.ä. verwendet werden. Gut man könnte sie jetzt im einbindenden Kontext definieren, dann erzeugt man aber Doppelungen bei mehrfach eingebundenen Assets.

Assets und Inhalte unterliegen auch keiner Zugriffskontrolle. Überhaupt – Redakteursrechte lassen sich wohl auch kaum abbilden mit einem solchen System. Hier kannst Du allenfalls den FTP-Zugang dichtmachen, eine künstliche Zugriffschicht einführen, dann alle Inhaltsverwaltung übers Backend routen und hast letztendlich genau die Einschränkung des Anwenders, die Du im Beitrag kritisierst (und ein komplexes CMS).

Auch wenn sich das Problem bald hoffentlich erledigt – ein zukünftiges Backend wird immer mit safe_mode Problemen kämpfen, das ist typisch für ordnerbasierte CMS.

Fazit: Netter Ansatz, aber nur geringfügiger Zugewinn zu einer individuell programmierten dynamischen Site. Die großen Herausforderungen – Rechte, geschlossene Bereiche, einfache Inhaltsstrukturverwaltung, Semantik – kann dieses CMS nicht lösen.

Interessante Sendung.

Ich sehe seine Vorteile vor allem darin, dass

1) ich in meinem favorisierten Text-Editor schreiben kann, in dem ich in der Regel schneller bin und mehr Struktur und Semantik zu produzieren vermag als im SEO-optimierten CMS X oder Y.

2) es keinen Overhead mitbringt. Ein paar Benchmarks fände ich hier interessant zum Vergleich mit Datenbank-basierten Lösungen.

3) ich mit GIT und automatisiertem Deployment direkt alles auf den Server pushen kann, ohne eine Datenbank synchronisieren zu müssen.

Ich sehe auf jeden Fall einige Anwendungsfälle und kann mir vorstellen, dass es aufgrund des Alleinstellungsmerkmals der Performance (sowohl in der Entwicklung als auch auf dem Server) vor allem bei Entwicklern viele Freunde finden könnte.

Von daher für mich auch ein absoluter Kandidat für Open-Source, wovon du auf lange Sicht ja ebenfalls profitieren kannst.

Von mir auf jeden Fall Hut ab und viel Erfolg weiterhin.

mir hat die lockere art gut gefallen. ich mag es lieber wenn man einen sympathischen menschen zuhört der sich auch mal leicht verhaspelt wie irgend so ne graue typisch deutsche monotone leerveranstaltung.

die wichtigsten punkte warum es interessant sein kann, kamen für mich jedenfalls rüber. jedenfalls genug um es mir mal anzuschauen. finde den ersteindruck positiv, aber so eine einfache backendschicht wäre genial. die fehlt mir um es wirklich mal für ne kleine kundenseite einzusetzen.
denn letztendlich brauch ich für die einen wysiwyg der auf ddas nötigste reduzierbar ist und eine funktion bilder automatisch zu verkleinern, das bekommen kunden sonst auch nicht hin.

so generell fand ich bisher in dieser art das cms pulse am interessantesten. das bietet aber nicht diesen strukturierten aufbau mit feldern und ist nochmal feature-armer. hat aber ein backend.

@Bastian: spannend und für mich persönlich die beste Einstellung zu einem Stück Code oder Projekt die man haben kann.

*wo findet man deine angesprochene Toolbox, die nicht nur im Zusammenhang Kirby steht; die du auch bei Zoo genutzt/bearbeitet hast. Ich finde andere PHP Projekte und Tools immer spannend.

@all: die Sendung war unterhaltend, spannend; den Blickwinkel die Nutzung muss jeder für sich selbst beurteilen; was an vielen Faktoren hängt. Allein das Teilen der Arbeit, die in Kirby steckt bedarf aber Anerkennung; der Mut in die Öffentlichkeit zu gehen ebenso; denn Kritiker gibt es genug; Möglichkeiten zu lernen und zu teilen jedoch nicht.
Die Sendung ist und war in jedem Fall hörenswert und enthält Informationen, die nicht schaden, egal ob man Kirby nun einsetzt oder nicht.

@Bastian: danke dir, bin nicht davon ausgegangen, dass du alles Klassen in einer Datei hast; jetzt ist es offensichtlich.

@Niko ich wollte das Preismodell möglichst simpel halten. Man kann mich aber gerne wegen Studenten- oder Mengenrabatt anschreiben. bastian [at] getkirby [dot] com

Habe die Sendung heute erst gehört und war am Anfang ganz gespannt, da es doch wenig Systeme gibt die auf Dateisystem ebene funktionieren. Ich sehe das ähnlich wie der Autor der Software, dass Filesystem basierte Systeme wieder zunehmen.

Die Software habe ich mir dann aber nicht angeschaut. Mir ist bei der Erläuterung des Systems einfach nicht klar geworden, wofür ich die Software gebrauchen kann.

So wie ich das verstehe, habe ich das System auf einem oder mehren Lokalen System vorliegen und bearbeite die Dateien. Wenn ich alles bearbeitet habe übertrage ich die Dateien auf meinen Server wo ein php System die Dateien zu HTML Seiten aufbereitet und ausliefert.

Nun meine Probleme damit.

1. Warum werden die HTML Seiten nicht auf dem Lokalen System erstellt und die HTML Seiten auf den Server Übertragen? Dann brauch ich mir keinen Kopf über Performance von PHP zu machen und das ganze Thema Caching usw. ist aus dem Kopf.

2. Warum ein eigenes Template System, für das es keine Editor gibt? Hier sehe ich doch XML und XSLT2 mit ein paar Shell oder PowerShell Scripten die die HTML Seiten bauen klar im Vorteil. Mit XML-Schema ist es möglich Editoren zu Konfigurieren und somit eine Valide Eingabeoberflächen dem Kunden bereit zu stellen und XSLT2 ist sehr mächtig und da kommt eine eigne ausgedachte Syntax bestimmt nicht dran.

Insgesamt kommt mir das System so vor als ob es im Jahre 1998 ersonnen worden ist und konzeptionell nicht mit der Zeit gegangen ist.

Also am Ende des Pocast habe ich mich doch gefragt, wieso man heute ein Podcast Veröffentlicht ohne sich vorher zu informieren, was mit einfachen mitteln heute möglich ist und der ein System Vorstellt, welches aus dem Jahr 1998 kommen könnte.