Ich mag ja WordPress, auch wenn viele zurecht darauf schimpfen. Es ist bloated, saugt ordentlich Performance und die Plugins sind oft grützig geschrieben. Aber es hat eben viele Optionen, man kann es einfach skinnen und der Kunde versteht es schnell. Dennoch muss man nicht bei jedem kleinsten Projekt gleich WordPress installieren, wenn das meiste eh nicht verwendet wird. Doch gibt es brauchbare Alternativen?

Zum einen gibt es GetSimple, welches ich noch nicht wirklich getestet habe, es aber auf jeden Fall vorhabe, da es XML-basiert ist. Vor einigen Wochen entdeckte ich dann Anchor CMS, welches ich auf Anhieb sympathisch fand. Warum? Weil es auf das Nötigste reduziert und dadurch sehr schmal ist. Natürlich ist es noch keine WordPress-Alternative, denn viele Dinge fehlen noch, um es richtig rund zu machen. Dennoch werde ich das mal bei eigenen und auch an kleinen Kundenprojekten einsetzen, wo der Wunsch besteht, hin und wieder einen Text zu ändern.

Was Anchor CMS u.a. kann:

• Blog-Posts
• Seiten
• Custom Fields
• individuelles CSS für jeden Post
• Themes

Was Anchor CMS u.a. nicht kann:

• Bild-Upload
• WYSIWYG-Editor
• Plugins

Doch Anchor CMS steckt auch noch in der Beta (Version 0.6.x) und Open Source. Also wird sich da noch einiges ändern. Wer aber ein schmales CMS braucht, welches die Grundfunktionen abdeckt und sich seine Plugins und Funktionen eh lieber selbst schreibt, der sollte das mal antesten. Es ist vielleicht nicht verkehrt, sich etwas von WordPress zu lösen. Weil eben viel dagegen spricht, wie Speicherplatz und eben die Performance.

Anchor CMS läuft mit PHP 5.3+ und MySQL, ist kostenlos und gerade mal 200 kb klein.

Anchor CMS

Das Plugin P3 (Plugin Performance Profiler) scannt die Seite in einem Livetest einmal durch und spuckt am Ende eine Statistik aus, die zeigt, welches Plugin am meisten Performance frisst. Eine gute Sache und im Falle dieses Blogs ist es ein Plugin, welches ich als letztes auf dem Zettel hatte:

Ein vermeintlich kleines Plugin, welches die Code Syntax in meinen Beiträgen formatiert. Nun gut, also mal nach einer Alternative suchen. Auch WPtouch, welches eine mobile Oberfläche des Blogs erstellt, ist gut dabei. Das wird sich dann ja beim Relaunch demnächst eh erledigen.

Wer viele Plugins verwendet, der sollte dieses einmal drüber laufen lassen. Schaden kann es nicht, nur helfen.

via

Zuerst muss man abwägen, wann eine Silbentrennung überhaupt Sinn ergibt. Bei extrem langen Wörtern, wie Fußbodenschleifmaschinenverleih, die in recht schmale Container gesteckt werden, ja. Aber auch bei Blocksatz, den man allerdings auf Websites sehr bedacht einsetzen sollte. Wenn man Blocksatz und ein responsive Layout verwendet, dann ist eine automatische Silbentrennung quasi ein Muss. Oder man steht auf extrem gezogene Leerstellen zwischen den Wörtern.

Mit CSS3 ist die sogenannte Hyphenation jetzt möglich. Gibt man einem Element die Methode hyphens mit, wird der Text getrennt. Dabei gibt es drei values, die man angeben kann: none, manual und auto. In der Praxis sähe das so aus:

1
2
3
4
5
6

.element p {
  -webkit-hyphens: auto;
  -moz-hyphens: auto;
  -ms-hyphens: auto;
  hyphens: auto;
}

Dabei ist es wichtig, dass das CSS weiß, in welcher Sprache hier getrennt werden soll. Also gibt man dem Dokument logischerweise eine Sprache mit. Eine Übersicht der Sprachkürzel und Deklarationen des HTML- bzw. XML-Dokuments, gibt es hier.

Textbaustein ohne und mit der hyphens-Methode

Alternative

Wer es auf allen Browsern haben will, der kann mit einer “soften” Silbentrennung nachhelfen. Dafür bedient man sich einfach dem HTML-Entity ­ und platziert diesen im entsprechenden Wort:

1

Fußboden­schleif­maschinen­verleih

Das sieht im Code nicht gut aus, hat aber keine Auswirkungen auf die Außenansicht. Auch werden Texte ganz normal kopiert. Ich habe das bei meinem Portfolio so angewandt und werde diese dann entfernen, sobald der Browser-Support auch Chrome erreicht hat. Einen Tod muss man ja sterben.

Ich habe so eben den Relaunch meines Portfolios vollzogen und möchte die Gelegenheit nutzen, ein wenig darüber zu erzählen. Denn mein Plan war nicht nur, es so gut wie möglich aussehen zu lassen. Es sollte auch responsive sein, also auf allen Geräten mit Browser funktionieren. Und das, ohne eine separate Mobile-Version zu entwickeln. One template to rule them all, quasi.

Design und Layout

Das Design hat sich nicht großartig verändert, da ich das vorige immer noch zu sehr mochte. Ich binde weiterhin Fotografien von mir als Hintergrundbild ein, allerdings nur für die Desktops. Mobile Geräte bekommen aufgrund der Datenmenge eine Kachel. Zudem wirken die Fotos auch nur auf größeren Auflösungen.

Die kubischen Module gibt es auch weiterhin, allerdings mit dezent angerundeten Ecken. Die Webfont sind nun PT Sans, PT Narrow und PT Serif. Das Blau als Signal- und das Pink als Linkfarbe, bleiben weiterhin bestehen. Im Großen und Ganzen ist das Thema also beibehalten worden, außer dass die Seite nun eine Single page ist.

Entwicklung

Als Framework habe ich wieder auf Smarty gesetzt. Von XHTML 1.0 strict habe ich mich verabschiedet und verwende nun HTML5 mit Modernizr, damit mir IE-Nutzer nicht wieder die Ohren vollplärren.

Das responsive Layout kommt von Bootstrap, welches ich allerdings anpassen musste, wie schon hier beschrieben. Ansonsten funktioniert dies ganz gut, da ich auf das Layout nicht fluid haben wollte und mir Bootstrap in der Hinsicht viel Gefrickel erspart hat. Die JS-Library von Bootstrap brauchte ich allerdings nicht. Die teste ich mal bei einem anderen Projekt aus.

Entwickelt habe ich das restliche CSS mit LESS, lokal kompiliert hat das CodeKit für mich, wobei ich Letzteres nicht mehr missen möchte. Der Vorteil bei CodeKit bzw. dem lokalen Kompilieren ist, dass man LESS nicht mehr per JavaScript einbinden muss, um es clientseitig zu rendern. Was sich positiv auf die Performance auswirkt.

Die Portfolio-Screens werden auf die jeweilige Auflösung komprimiert, sodass man auf dem Smartphone nicht die 1100px großen Bilder laden muss.

Fazit

Abgesehen davon, dass es immer noch viel Zeit und Nerven kostet, für sich selbst zu gestalten, hat es sich dieses mal wieder ausgezahlt, in bestimmten Bereichen auf Frameworks zu setzen. Das perfekte Framework, vor allem im responsive CSS, habe ich noch nicht gefunden. Dafür gibt es aber auch für jeden Anspruch genügend Alternativen geboten.

Was LESS angeht, so werde ich Projekte wohl nicht mehr ohne entwickeln, sofern ich lokal entwickeln kann.

Links

Smarty
Bootstrap
Modernizr
CodeKit
LESS

Doch seit heute Morgen saß ich an dem Problem, dass IE8 und drunter nicht auf das responsive CSS anspringt. Da man nach einer Weile betriebsblind wird, saß ich auch echt lange daran, dieses Problem zu lösen. Denn auch die Bootstrap-Seite ist unter diesen Browsern nicht responsive. Die Lösung zum Problem habe ich nun gefunden. Und die ist schon echt peinlich, wie ich finde.

Mein Problem war, dass der IE nicht auf die Mediaqueries ansprang. Da ich parallel noch ein responsive Projekt habe, verglich ich die Styles. Aber bis dahin dachte ich, dass es ein JavaScript-Problem oder so sei. Wie auch immer, bei Bootstrap sind die Mediaqueries einfach nicht richtig eingebaut. Man findet sie so vor:

1

@media (max-width: 480px)

Damit der IE8 und seine älteren Geschwister das auch kapiert, muss der Satz vervollständigt werden. Nämlich so:

1

@media handheld, only screen and (max-width: 480px)

Kein Hexenwerk, kein Hack, sondern einfach nur vier Wörter mehr. Dann funktioniert es wunderbar im IE7 und IE8. Dass man sich diese “Mühe” nicht gemacht hat, verstehe ich nicht.

Ich möchte den Entwicklern von Bootstrap nichts unterstellen, aber das sieht mir nicht nach einem Flüchtigkeitsfehler aus. Eher hat man diese Browser einfach ignoriert. Das ist schade, da nicht alle Entwickler die Freiheit haben, auf die IE-Browser zu verzichten. Aber das passt auch grad zum Trend, dass Entwickler sich immer mehr nur auf WebKit konzentrieren und den Rest einfach ignorieren. Selbst Firefox wird immer mehr vernachlässigt.

Ich hatte mal vor langer Zeit einen Rant geschrieben, dass Cross-Browser-Optimierungen nicht allzu eng gesehen werden sollten und oft auch Stillstand bedeuten. Allerdings bezieht sich diese Meinung nicht auf funktionale Eigenschaften einer Website. Ich bin der Meinung, dass eine Seite nicht unbedingt überall gleich aussehen muss, aber über all gleich funktionieren sollte.

Das Responsive Design Test Bookmarklet von Benjamin Koon ist ein kleiner Helfer beim Umsetzung von Responsive Layouts. Für die, die nicht wissen, was das ist: Responsive bedeutet, dass sich das Layout dem User bzw. seiner Bildschirmauflösung anpasst, sodass auch bei mobilen Endgeräten kein eigenes Template mehr nötig ist.

Die verschiedenen Auflösungen, die man angezeigt bekommen möchte, kann man vorher selbst definieren. Dann generieren lassen und das Bookmarklet einsetzen. Das Resultat sieht dann aus, wie hier bei der Website von treehouse:

Anklicken, in groß angucken

Phantastisches Tool, wirklich.

Responsive Design Test Bookmarklet

Gestern schrieb ich über den Feed-Reader Fever°, den man auf seinem eigenen Server installieren kann. Für Leute, die Kontrolle über ihre Daten haben wollen, ‘ne sauber’ Sach’. Was ist aber, wenn man auch seinen Kalender, seine Kontakte und so wieso alles in einer eigenen Cloud haben will und man nicht unbedingt Amazon, Google oder gar, kchihi, die Telekom Cloud nutzen möchte? Ich für meinen Teil nutze seit einiger Zeit ownCloud und freunde mich immer mehr damit an.

Was ist ownCloud? Kurz angerissen bietet ownCloud neben einer Datei- und Bookmarkverwaltung auch einen CalDAV- und CardDAV-Server. Ich habe mich am meisten für die Kalenderfunktion interessiert, da ich Google nicht unbedingt wissen lassen muss, wann ich das nächste Mal zu welchem Arzt gehe. Aber auch die Bookmarkfunktion nutze ich als halben Ersatz für ReadItLater. Aber mal der Reihe nach.

Installation

Die Installation hat keine 5 Minuten gedauert. Ich musste lediglich PECL installieren und habe anschließend ownCloud per git gezogen. Mehr war das nicht. Allerdings hat nicht jeder Server das gleiche Setup.

Kalender auf allen Geräten

Google Calendar ist zwar schön einfach zu konfigurieren und zu syncen, aber mit ein paar wenigen Schritten mehr, geht es auch wunderbar mit ownCloud. Ich nutze OS X, habe aber ein Android-Telefon. So muss ich also zwei Geräte mit einander synchronisieren. Die Einrichtung unter OS X ist recht einfach, wenn man den richtigen Pfad ergoogelt hat. Der in den Einstellungen von ownCloud funktioniert nämlich leider nicht.

So muss das aussehen:

Serverpfad: /owncloud/apps/calendar/caldav.php/principals/<username>/

Für Android gibt es eine App, die zwar kostet, aber wunderbar funktioniert. Da die App aber noch beta ist, sollte man von der Option absehen, die das Verwalten des Kalenders von Android aus ermöglicht. Glaubt mir, tut es einfach (noch nicht). Ich habe mich dafür entschieden, den Kalender ausschließlich von OS X aus zu verwalten, sodass ich mich nicht mal mehr bei ownCloud einloggen muss.

Einen eigenen CalDAV-Server zu haben, finde ich ‘ne gute Sache.

Dateien mit anderen teilen

Screenshot von ownCloud 3

Man hat die Möglichkeit, Dateien wie Fotos oder Musik, mit anderen zu teilen oder aber auch öffentliche Links zu erzeugen. Ähnlich wie bei Dropbox. Musik lässt sich direkt im Browser abspielen, Galerien lassen sich ebenso erstellen.

Nachteile

ownCloud steht zur Zeit als Version 3 Alpha 1 im Netz und in 3 Tagen soll wohl die stable kommen. Wie auch immer, es ist natürlich noch etwas schmal alles, was die Optionen angeht. Und mobil ist die Seite auch noch nicht zu gebrauchen. Da bin ich gespannt, was da noch kommen wird.

Ein weiterer Nachteil ist, dass unter OS X Snow Leopard wohl der CardDAV-Account im Adressbuch nicht funktioniert. Ich habe es nicht hinbekommen und da bin ich auch nicht der Einzige.

Fazit

Es gibt noch einiges zu tun, aber eine gute Sache ist es dennoch schon. Alleine durch die CalDAV-Funktion lohnt es sich, das Ding mal auszuprobieren. Man darf also gespannt sein, wie sich ownCloud noch entwickeln wird.

owncloud.org
owncloud.com

So angenehm und einfach die Dienste von Google sind, desto vorsichtiger sollte man sein, diese zu nutzen. Denn auch wie bei Facebook gilt: Wenn es umsonst ist, bist Du das Produkt. Keine Frage, die Dienste erleichtern so einiges im Alltag und kaum ein anderer Anbieter ist dabei so schnell und bietet so viel kostenlosen Platz. Doch niemand hat etwas zu verschenken, auch Google nicht. Und ich erst recht nicht meine Lesegewohnheiten.

In den letzten Jahren habe ich mir diverse Alternativen zu Google Reader angeschaut und bin am Ende immer wieder bei Google gelandet. Zu umständlich, zu hässlich, zu langsam waren bisher all diese Tools. Zudem wollte ich nicht schon wieder meine Daten auf einem fremden Server haben, sondern meinen eigenen nutzen. Ich habe rsslounge, Tiny Tiny RSS und Liliana getestet. Doch die sehen entweder alle aus wie Windows 95 oder sind mobil nicht nutzbar. Wie soll ich da auf Klo meinen Reader lesen? Eben. Doch wer lange sucht, wird endlich fündig …

Endlich angekommen

Klick mich, mach mich groß!

Fever° hat mich schnell so sehr überzeugt, dass ich bei Google für immer raus bin. Seit einigen Monaten nutze ich Fever° nun und kann mir nicht mehr vorstellen, zurückzugehen. Warum? Erstens, weil es gut aussieht, zweitens es sich gut anfühlt und drittens die mobile Seite ziemlich chic ist. Die Features decken alles ab, was man braucht.

Man muss sich allerdings von ein paar Annehmlichkeiten verabschieden, die man vom Google Reader kennt. Die Shortcuts wurden zwar übernommen, aber einen neuen Feed einpflegen bedeutet, dass der Seitentitel händisch eingetragen werden muss. Daran wird die Welt nicht zugrunde gehen. Es gibt auch ein Bookmarklet, welches bei mir allerdings nicht funktioniert.

Fever° will natürlich etwas anders sein und hat eine Funktion namens “Hot” eingebaut. Die gruppiert wohl diverse Feeds und versieht sie mit Temperaturangaben. Keine Ahnung, was mir das bringen soll, brauche ich nicht, nutze ich nicht. Ich halte mich nur in “Kindling” auf, speichere Artikel mit der Taste S, um sie später in meine Bookmarkdienste zu sortieren.

Wichtig ist unterwegs

Wie erwähnt, die mobile Seite ist auch recht schön gelöst, synchronisiert natürlich die Feeds mit dem Server, sodass man nichts doppelt liest. Auch läuft die mobile Seite ziemlich flüssig. Es ist also alles abgedeckt, was man zum Lesen braucht. Und da Google das Sharing beim Reader eh gekickt hat, vermisst man das bei Fever° gar nicht erst.

Es gibt allerdings zwei Nachteile, über die man erst mal nachdenken muss. Der erste ist, dass es keine Demo gibt:

Because Fever is a state-based single-user system a live demo isn’t possible.

Dafür gibt es aber dieses Video. Die zweite ist, dass Fever°, wie die meisten guten Sachen in der Welt, Geld kostet. Die 30$ sind allerdings bestens angelegt. Ich habe auch lange überlegt, hatte aber angesichts der Alternativen, auch kein Bock mehr, mit so holprigen und unbefriedigenden Clones rumzumachen. Dafür ist die Installation auch echt kackeneinfach.

Fazit

Wem es egal, wer was mitliest und welche Daten wo an wen verkauft, der braucht das nicht. Der ist bei Google eh gut aufgehoben. Wer es mag, Kontrolle über seine Daten zu haben, der wird nicht enttäuscht sein, wenn er dafür etwas Geld ausgibt. Ich werde nichts anderes mehr zum Feeds lesen nutzen.

Fever° läuft mit PHP/MySQL und findet man unter feedafever.com.

Um SpriteRight entsteht grad ein kleiner Buzz. Die Software für OS X kann wohl recht viel, wenn man dem Video glauben darf. Man kann individuelle Parameter bestimmen, wie den Abstand zwischen den Grafiken und ein CSS Code wird auch on the fly erstellt. Ganz gute Sache, auch wenn es für mich aus zwei Gründen nicht infrage kommt:

1. Die meisten meiner Sprites erstelle ich nach der diagonalen Methode, um HTML-Elemente zu sparen. Das ist zwar etwas aufwendiger (wenn es z.B. um ein Flaggen-Sprite mit 50 Flaggen und mehr geht), aber man kann mehrzeilige Texte besser mit Sprites versehen. Diese Methode bekommt dieses Tool meines Erachtens nicht hin.
2. OS X  Lion only – dem verweigere ich mich immer noch, bis Apple irgendwann den Support für das XP der OS Xe einstellt.

Wer es aber testet, sind ja schlanke 4 Euro, der kann hier gerne seine Erfahrung mitteilen. Vielleicht convinced mich das ja doch, auf Lion umzusteigen. Irgendwann.

Hier das oben erwähnte Video:

[Im Feed kann dieses Video nicht angezeigt werden.Klicke zum Blogeintrag um das Video anzusehen.]

Vertrauliche Dateien in der Dropbox verschlüsseln, ist mit Tools wie TrueCrypt kein Problem. Einfach einen Container erstellen und gut. Allerdings ist das recht unkomfortabel, wenn man entweder mit mehreren Rechnern arbeitet oder verschlüsselte Dateien mit anderen teilen will.

Am Wochenende bin ich auf Safebox gestoßen und bin recht begeistert. Das Prinzip von Safebox funktioniert so: Man legt einen Ordner außerhalb von dem Dropbox-Ordner an und generiert einen Schlüssel. Dieser Ordner synchronisiert einen bestimmten Ordner in der Dropbox mit den Inhalten, nur dass sie dort schon verschlüsselt ankommen. Den generierten Schlüssel kann man dann entweder auf seinem anderen Rechner anwenden oder mit jemandem teilen.

Die Verschlüsselung sollte auch ausreichend sein:

Encryption algorithms used:

1. PBKDF2 for key strengthening. Iteration count 10900 for AES engine and 10500 for HMAC signing.
2. AES256 with CBC mode and PCKCS7-RFC5652(CMS) padding.
3. HMAC-SHA256 for file authentication.
4. Random unit depends on Operating System for generating IV.

Genau so etwas habe ich immer gesucht, da ich z.B. Dateien, auf die ich immer zugreifen muss, nicht mehr in TrueCrypt-Container packen und diese mounten muss. Der Nachteil an TrueCrypt ist leider auch, dass, wenn sie die Container nicht unmounted sind und man selbigen von einem anderen Ort mounted und diesen speichert, es dann immer Konfliktdateien gibt. Hat mich tierisch genervt.

Safebox kostet pro Rechner $0.99 und wem das zu viel ist, findet auf der Seite auch den Link, mit dem man zur freien Lizenz kommt. Für mich sind das auf jeden Fall die am besten angelegten paar Cent der letzten Tage.