You are reading articles by Simplificator, a Swiss-based custom software development agency. Here we write about the problems we solve and how we work together.
Generally speaking, we don’t worry about W3C validation.
Practically speaking, it honestly doesn’t make much sense to strive for it in most production environments if industry accepted practices are viewed as errors. All the CSS we use is valid, and while some lines are hacks (* for IE7, 9 for IE7-9, etc), it all renders as expected. I’m sure much of this will be cleaned up as we drop legacy browser support (I see lots of hiccups for the IE hacks).
Unsere Webseite verwenden wir immer mal wieder um Technologien etwas genauer zu evaluieren. Aus einem grösseren Projekt kann man mehr Erfahrungen ziehen als aus einem einfachen “Hello World”. Oft trifft man im laufe eines Projektes auf ein grösseres Hindernis und erst dann zeigt sich ob die richtige Technologie gewählt wurde. Einfach genug für den Normalfall, mächtig genug für spezielle Features.
Nachdem wir zuletzt Radiant, nanoc und auch eine gehostete CMS Lösung verwendet haben, haben wir in den letzten Tagen und Wochen LocomotiveCMS und auch eine eigene CMS Lösung angeschaut.
Dabei hat sich einmal mehr gezeigt, dass es im Bereich CMS keine “Silver Bullets” gibt. Es kommt auf den Einzelfall an.
Mittlerweile wurde die Webseite mit einem Custom CMS umgesetzt und auf Heroku deployt. Noch ist nicht alles perfekt, am Design wird noch gefeilt und auch die responsive Variante, speziell für Mobiles, braucht noch etwas Politur.
Aber wir versuchen auch mit unserer Webseite ein agiles vorgehen zu leben. Die kleineren Probleme können wir in den nächsten Tagen verbessern und so Stück für Stück dem Ziel näher kommen.
Verglichen mit LocomotiveCMS hatten wir einen etwas höheren Initialaufwand, können nun aber schnell Erweiterungen Vornehmen und auf die ganze Palette von Bibliotheken und Tools zugreifen. Mit einer guten Testcoverage stellen wir sicher, dass die Seite so funktioniert wie gedacht.
Gegen Locomotive sprach die momentan nicht aktuelle Dokumentation über Mehrsprachigkeit und die Template Entwicklung mittels Liquid.
Während Liquid natürlich eine gute Lösung ist, wenn eine “non-evaling” Template Sprache benötigt wird, bevorzugen wir als Entwickler HAML/ERB und die Rails Helpers anstelle von Liquid und den Filtern.
Zuvor hatten wir eine statische Seite welche via nanoc generiert und über Heroku ausgelifert wurde. Der Entwicklungs und Update Zyklus war, wie sich nach einer Weile herausgestellt hat, unbefriedigend. Zu kompliziert für nicht Techniker, zu langsam für die Entwickler (autocompile mit einer grösseren nanoc Seite ist seeeehr langsam).
Nun sind wir wieder da wo wir uns wohlfühlen und können auf bewährte Tools zurückgreifen.
Die nächsten Monate werden wir mal dabei bleiben, dann entscheiden wir ob es wieder etwas neues gibt.
Verschiedene Programmiersprachen, verschiedene Konventionen für die Namen von Klassen, Methoden, Variablen.
Da gibt es uppercase, camelcase, snakecase und dashes. Und natürlich noch dashes/underscore in uppercase, upper-camelcase und so weiter.
Hier ein paar Beispiele:
Das befolgen von Konventionen ist wichtig um die Lesbarkeit des Codes zu erhöhen. Somit kann man sich besser in Code einarbeiten und Fehler vermeiden. Besonders bei Sprachen welche nicht kompiliert sind (ein Compiler merkt, ob man einmal getUserName und ein anderes mal GetUserName schreibt). Auch bei Webapplikationen, wo auf dem Server HTML gerendert wird und dann im Browser mit Javascript manipuliert wird, passieren immer mal wieder Fehler.
Ein Beispiel:
HTML:
<div class=”node-1234”>Ein Element</div>Javascript:
$(“.node\_1234”).hide()Dies sieht auf den ersten Blick korrekt aus, aber später wird man feststellen, dass der Javascript Code nicht das macht was man erwartet.
Ich versuchen in meinen Projekten die folgenden Konventionen einzuhalten:
Ruby:
Klassen: Upper Camelcase (UserGroup)
Methoden: Snakecase (user_group)
Konstanten: Uppercase mit Unterstrich (USER_GROUP)
HTML/CSS:
id: Lowercase mit Bindestrich (#user-group)
class:Lowercase mit Bindestrich (.user-group)
Javascript:
Klassen: Upper Camelcase (UserGroup)
Methoden: Camelcase (userGroup)
Nachdem wir im Juni Sabine und Fabian begrüssen konnten, hat im Juli nun Thomas bei Simplificator angefangen.
Bilder und Kurzbiographie folgen, das Photoshooting findet heute statt:-)
Anfang Juni ist das Simplificator Team gleich um zwei Mitarbeiter gewachsen.
Sabine unterstützt uns in den Bereichen Konzeption, Design, Grafik und Projektleitung. Somit kann Simplificator nun erstmals alles aus einer Hand bieten. Von der Idee bis zum fertigen Produkt.
Fabian verstärkt unser Team mit seinem Knowhow und Erfahrung in der Softwareentwicklung.
Wir können bei unseren Nachbarn, dem Punkt Magazin, das Photostudio benutzen, so dass hoffentlich bald alle Bilder aktualisiert sind.
Sicher ist sicher oder eben auch nicht. Wer einen Router hat und dessen Passwort nicht zurücksetzt, sollte sich nicht wundern, wenn der freundliche Nachbar sich an der Konfiguration zu schaffen macht.
Eine typische Situation nach den ersten Erfolgen mit einer Applikation: Das Team ist langsam, wehrt sich gegen Anforderungen. Neue Funktionen sind schwierig umzusetzen, und die Testphasen werden länger. Die Software-Entwicklung wird immer schwieriger.
Architektur einer Applikation ist eine relativ abstrakte Angelegenheit: Oft von technologischen Überlegungen getrieben, mit dem Wunsch eine allgemeine Lösung für alles zu haben. Auf der einen Seite gibt es den Hacker-Ansatz - auf eine schnelle, unspezifische Weise möglichst schnell zum Ziel zu kommen. Es gleicht einem Basar - alles geht irgendwie, es ist effizient - aber die Systeme sind schwierig zu warten weil die Struktur fehlt. Auf der anderen Seite gibt es die Architektur-Astronauten - sie haben ein Buch (oder mehrere) gelesen, sind überzeugt von dem Wert von Struktur, aber sie überborden: Grundlos bauen sie virtuelle Kathedralen, flechten Schichten über Schichten, machen alles extrem “flexibel” und verlieren die Entwicklungsgeschwindigkeit.
Der Hauptgrund ist die Komplexität der Aufgabe. Architektur ist nötig, aber schwierig, und muss der Aufgabe angepasst sein. Es ist nicht einfach objektive Bewertungskriterien zu finden, verschiedene Architekturen zu beurteilen. Dazu kommt, dass Architekturanpassungen normalerweise viel Aufwand bedeuten, ohne dass eine Applikation an Funktionalität gewinnt. Damit entscheiden sich Betriebe oft dazu, eine bestehende Architektur beizubehalten und mit den Problemen umzugehen.
Wie wäre es hingegen, wenn Entwickler eine klare Idee haben, wie ein System idealerweise umgesetzt würde? Wenn die Technologie-Entscheide vom Bedarf getrieben werden statt von Glaubenssätzen von Architektur-Astronauten? Wenn die Entwicklungsgeschwindigkeit Schritt für Schritt zunimmt, die Fehlerrate abnimmt, das Team mehr Produktivität gewinnt, und die Fähigkeit schnell zu reagieren? Wenn Sicherheitsprobleme erkannt werden, bevor ein Problem auftritt?
Die zentrale Aufgabe ist, mit der Komplexität kontrolliert umzugehen. Komplexität lässt sich nicht wegdiskutieren. Es gibt die inhärente Komplexität der Aufgabe, und es gibt die Komplexität des Systems. Die effizienteste Lösung ist, wenn die Komplexität der Aufgabe sauber modelliert wird - dies wird die zentrale Architektur. Gleichzeitig soll die Komplexität des Systems so klein wie möglich gehalten werden.
Durch Refactoring kann diese Aufgabe auch später in der Entwicklung angegangen werden. Refactoring ist die Verbesserung der Struktur einer Applikation ohne der Veränderung der Funktion. Wenn die Architektur aus Refactoring entsteht, ist sie im Allgemeinen sinnvoll - sie hat eine Berechtigung von bestehendem Code her. Refactoring kann auch unnötige Komplexität reduzieren - wenn zu viele Schichten vorhanden sind in der Software, kann damit wieder Übersicht geschaffen werden.
Durch Code Reviews können verschiedene Sichtweisen eines Problems berücksichtigt werden: Code Reviews können zum Beispiel aufdecken, wenn defensiv programmiert wird. Defensive Programmierung ist wenn Teile des Programms anderen Teilen “nicht glauben” dass sie sich anständig verhalten, und versuchen auf unerwartetes zu reagieren. Das bläht den Code auf. Code Reviews helfen, solche Strukturen zu erkennen und die Probleme zu lösen.
Durch automatisierte Qualitätssicherung (Unit Tests und ähnlichem) können zentrale Funktionen gesichert werden, sodass die Testphase strukturierter und kürzer wird, und die Fehlerrate sinkt.
Wir bieten eine Beratung an, wo die Architektur eines Systems optimiert wird. Folgende Schritte können sinnvoll sein.
Code Review: Wir können in der ersten Stufe das System bezüglich Sicherheit, innerer Qualität, Modernität und Flexibilität beurteilen. Wir machen hierzu ein Code Review. Das Resultat ist ein Dokument, eine Arbeitsliste von Punkten wo gearbeitet werden soll, und allfällige Sicherheitsbedenken, die separate untersucht werden soll.
Architekturberatung: Wir beschreiben wie das System so verbessert werden kann, dass es besser für die Zukunft gerüstet ist. Wir schlagen Technologien vor und haben Beispiele dazu. Wir können die Entwicklungsprozesse optimieren helfen, und Vorschläge zum Umgang mit Anforderungen und Fehlern geben.
Coaching: Wir coachen die Entwickler, bezüglich Ressourcen, Büchern, Webseiten, welche diese Technologien und Architekturentscheidungen unterstützen können.
Qualitätssicherung: Wir können die Qualitätssicherung mit Unit Tests ermöglichen, sodass alte Fehler nicht mehr wiederkommen, und das Team höhere Sicherheit gewinnt beim Anpassen der Software.
Entwicklungsbegleitung: Wir begleiten nach Wunsch das Team von der Umsetzung bis zum fertigen Deployment.
Wir können in einem unverbindlichen Gespräch ein angepasstes Angebot formulieren. Wir können dies spontan machen oder etwas abmachen. Und wir haben guten Kaffee. Ruf an.
Jetzt. :-)
Kontakt: 044 500 47 50, info@simplificator.com oder @simplificator. Wir freuen uns.
Über die Zusammenarbeit von Evita und LUKS wird auch auf 20min.ch berichtet.
Mamagenda.ch, ein Angebot von TravailSuisse, wird neu von Simplificator betreut, gehostet und gewartet.
Mamagenda ist eine digitale Agenda zur Betreuung von schwangeren Mitarbeitern.
Das Pilotprojekt der HNO-Abteilung des Luzerner Kantonsspitals mit Evita, einem kostenlosen Service von Swisscom, bietet Patienten die Möglichkeit, auf ihre persönlichen Spitaldokumente aus der HNO sicher und jederzeit über das Internet zuzugreifen.
Simplificator hat bei der Implementierung der Schnittstelle mitgearbeitet und wir freuen uns, dass das Projekt nun in die Pilotphase übergegangen ist.
Details finden Sie hier.
