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.
Die Brotseiten iOS App ist im App Store verfügbar und natürlich auch auf unserer Seite dokumentiert.
Es freut uns, dass die App auch bereits positives Feedback erhalten hat, z.B. meint User MarcG78:
Kommt echt gut. 20 Min und Blick am Abend sind eh viel zu reisserisch und deprimierend. Im Vergleich ist das inspirierende und hochwertige Unterhaltung für unterwegs.
Sollte man sich unbedingt mal anschauen: Die neue iOS App “BROTSEITEN” Die clevere Alternative zu den Pendlerzeitungen. Ausgewählte Geschichten für dein Smartphone & Tablet. In der perfekten Länge für unterwegs. Zum Lesen und Hören. Programmiert von … Simplificator!
BROTSEITEN gewinnt den “seif Award for Social Entrepreneurship 2013”! Weitere Infos zum Projekt auf http://www.brotseiten.com/
Mit git kann man auf einfache Weise einen Diff eines Files über verschiedene Branches machen:
git diff master..other-branch — path/to/file.xyz
Wir freuen uns, dass wir heute den neuen Auftritt von Markenfels online stellen konnten.
Dieses Problem kennen alle Web-Entwickler: es sieht gut in Chrome aus aber in Firefox stimmen die Schriften nicht. Oder es sieht gut in Safari aus aber im IE ist der Abstand viel zu gross.
Auch wenn sich die Situation in den letzten Jahren deutlich entspannt hat, besonders zwischen FF, Safari, Chrome und neuen Versionen von IE.
Aber ältere Versionen (d.h. alles < 10) tun sich teilweise immer noch schwer mit Stylesheets welche auf anderen Browsern gute Resultate erzielen.
Bei unserer Webseite jedoch…war es ein Fehler beim entwickeln. Die Webseite basiert auf Bootstrap und die Stylesheets werden mittels SASS “pre-processed”. Durch einen unabsichtlichen mehrfach Import von Bootstrap hatten wir zuviele Regeln in einem einzelnen Stylesheet und nichts ging mehr.
Details zu den Stylesheet Limits gibt es hier.
Das Problem ist mittlerweile gefixed und die neue Version deployed. Nun sollte die Seite auch auf älteren IEs wieder besser aussehen.
Sabine ist bereits dabei die Seite neu zu gestalten…Anpassungen folgen bald.
Eine Rails Engine mit helper methoden und Javascript um Timestamps und Dates in lokalen Zeiten darzustellen.
local_time gem von 37 Signals
Neues CMS neue URLs und nichts mehr auffindbar?
Beim Technologiewechsel von unserem CMS wurde auch die URL generierung geändert. Somit sind gewisse URLs nicht mehr gültig.
Um diesem Problem vorzubeugen, SEO und Benutzerfreundlichkeit lassen grüssen, verwenden wir Rack::Rewrite um alte URLs mit einem 301 Status Code zu beantworten und gleich an den richtigen Ort weiterzuleiten.
config.middleware.insert\_before(ActionDispatch::RequestId, Rack::Rewrite) do
# company
r301 '/de/firma', '/de/company'
# offers
r301 '/de/angebote', '/de/offers'
# references
r301 '/de/referenzen', '/de/projects'
r301 '/en/references', '/en/projects'
r301 %r{/de/referenzen/.\*}, '/de/projects'
r301 %r{/en/references/.\*}, '/de/projects'
....
....
end
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)