Archiv für Schlagwort: code

Der neue Chefkoch

Der neue Chefkoch

Viele Stunden Arbeit stecken im neuen Aussehen des Chefkochs, das wir am frühen Dienstagmorgen ausgerollt haben. Dabei blieb kein Stein auf dem anderen. Neben den optischen Neuerungen haben wir auch im Code ordentlich aufgeräumt, ausgemistet und neu geschrieben. Eine Menge Zeit ging ins Land, bis wir soweit waren, keine Datei blieb unangetastet.

Und dann war es Dienstagmorgen, sieben Uhr und ich war das erste Mal seit langem wieder wirklich aufgeregt. Fast so, wie es mir früher vor Klausuren ging. Der Umstieg vom Entwicklungssystem in die Live-Umgebung war die letzte Hürde, die es zu bewältigen gab. Und fast genau so war dann nach nicht ganz anderthalb Stunden alles verflogen. Chefkoch.de wieder online und alle versammelten Kollegen sehr zufrieden. Das Feedback ist auch überwiegend positiv, was will man also mehr?

Außerdem haben wir mit Was koche ich heute? ein ziemlich cooles inspiratives Feature eingeführt, auf das ich ziemlich stolz bin. Erinnert sich noch jemand an das, was ich zu meinem Projekt Mahlzeit vor fast drei Jahren geschrieben habe? Mit Hilfe der Chefkoch-Datenbank sind nun etwas mehr als 200 Mal so viele Rezepte in der Rotation, als das bei meiner Variante damals der Fall war.

Nur falls sich jemand fragen sollte, was ich so den ganzen Tag auf der Arbeit mache.

Das HTML5-Grundgerüst für ein Blog

Im Rahmen der Neuausrichtung meiner Seite beschäftigte ich mich auch eingehend mit HTML5 und den damit neu gegebenen Möglichkeiten. Vorweg: HTML5 ist nach wie vor kein festgelegter Standard, sondern weiterhin in Entwicklung. Dennoch unterstützen moderne Browser auch heute schon viele Möglichkeiten, die HTML5 bietet. Einen interessanten Artikel über die Inhalte von HTML5 mit einer durchdachten Grafik hat Peter Kröner mit Was ist HTML5 und was nicht? Und was hätte der Kaiser dazu gesagt? veröffentlicht. Dieser bietet eine erste Übersicht mit der man sich dann leicht in die einzelnen Themen abtauchen kann.

Ich will mich nun erst einmal mit den neuen semantischen Möglichkeiten von HTML5 auseinandersetzen. „Semantisch“ will heißen, dass man versucht durch den Einsatz diverser HTML-Elemente den Inhalt einer Webseite zu strukturieren. Natürlich könnte man auch alle Inhalte rigoros div-Elemente packen. Das Ergebnis würde im Browser vermutlich gleich aussehen. Durch die Verwendung von semantisch korrekten Elementen, die für den jeweiligen Inhalt-Typ vorgesehen sind, macht man den Code aber auch lesbar. Und zwar nicht nur für einen selbst oder andere Menschen, sondern auch für Screenreader und Suchmaschinen. Insgesamt also eine gute Sache.

Bisher bot (X)HTML hier nur eine beschränkte Anzahl von Elementen an. Überschriften, Listen und Textabsätze wurden im wesentlichen abgedeckt. HTML5 geht nun einen Schritt weiter und bietet die Möglichkeit eine Seite komplett semantisch zu strukturieren. Es gibt nun Elemente für den Kopf einer Seite (header), die Navigation (nav), den Inhalt (section, article) und seinen logischen Aufbau und den Fuss (footer) einer Seite. Ohne diese nun all zu lange eingehen zu wollen, verweise ich auf den Artikel Structural Tags in HTML5 bei Ordered List. Der Artikel dort beschreibt jedes Element kurz und zeigt auch einen beispielhaften Quellcode.

Im neu zu bauenden Layout meiner Seite möchte ich am oberen Ende der Seite eine Navigationsleiste mit den neuen Kategorien haben. Danach der eigentliche Inhalt und dann schließlich eine Sidebar, die eigentlich mehr eine „Bottombar“ ist. Dementsprechend ergibt sich folgende Struktur im Code:

[html]
<!– der tag und ich = header.php –>
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8">
<title>der tag und ich</title>
<link rel="stylesheet" type="text/css" href="style.css">
</head>
<body>
<header id="header">
<h1><a href="#">der tag und ich</a></h1>
</header>
<nav id="nav">
<ul>
<li><a href="#">Link 1</a></li>
<li><a href="#">Link 2</a></li>
<li><a href="#">Link 3</a></li>
<li><a href="#">Link 4</a></li>
</ul>
</nav>
<!– der tag und ich = index.php –>
<section>
<article>
<header>
<h2><a href="#">Die Überschrift eines Artikels</a></h2>
</header>
<section>
<p>Der Inhalt eines Artikels</p>
</section>
</article>
</section>
<!– der tag und ich = sidebar.php –>
<aside>
<p>Hier kommt die Sidebar hin</p>
</aside>
<!– der tag und ich = footer.php –>
<footer>
<p>Der Footer der Seite mit einigen wichtigen Links.</p>
</footer>
</body>
</html>
[/html]

In diese Grundstruktur kommt nun der erste WordPress-Code, damit die Inhalte ausgegeben werden können. Anschließend werden die gewünschten zusätzlichen Informationen eingebaut, wie etwa die Kommentaranzahl pro Beitrag oder das Veröffentlichungsdatum. Und natürlich das ganze drumherum, wie etwa Meta-Tags und externe Dateien die eingebunden werden wollen.

Ein kleiner Tipp am Rande: Nicht alle Browser unterstützen die neuen HTML-Elemente bereits, gerendert werden sie aber schon irgendwie. Damit das alles aber auch so tut wie es soll, setzt der kluge Webentwickler in einem Rundumschlag alle neuen Elemente im CSS der Seite manuell auf display: block;.

[css]
/* Nun bringen wir den HTML5-Tags erst mal ordentliches Benehmen bei */
article, aside, dialog, figure, footer, header, hgroup, menu, nav, section {
display: block;
}
[/css]
So sind die Elemente nämlich spezifiziert, werden aber unter anderem im Internet Explorer mangels Kenntnis als inline gerendert.

Plugin? Pah! – Ein Tutorial

Da fragte mich der Andi dieser Tage doch, mit welchem Plugin ich denn die Schlagworte und verwandten Einträge unter einem Eintrag hier aus- und einblenden lasse. Plugin? Pah! Natürlich habe ich da selbst ein wenig Hand angelegt. So sieht das übrigens ausgeklappt aus, zum Beispiel unter dem vorigen Beitrag ((Verwirrend übrigens, einen Screenshot in Originalgröße in den Eintrag einzublenden. Ich will da dauernd draufklicken.)):

Verwandte Einträge/Schlagworte

Nachdem ich eine kurze Weile beleidigt war, erklärte ich die näheren Umstände und dass man nicht immer alles per Plugin lösen muss. Daraufhin wurde ich als „Programmierer“ beschimpft. Wieder war ich für kurze Zeit beleidigt. Anschließend kam dann meine Gutherzigkeit doch wieder durch und so versprach ich dann, mal zu erklären wie man so was selbst baut. Eigentlich ist das nämlich nicht schwer. Und das gibt es dann nach dem Klick.

Den ganzen Beitrag lesen.

Relative Zeitangaben in WordPress

Aktualisierung: Damit das alles mehr Sinn macht, habe ich noch ein „über“ in das erste if eingebaut.

Kleine Bastelei in der Mittagspause: Über den Kommentaren wird jetzt nicht mehr das Datum des Kommentars angezeigt, sondern wie lange er schon dort steht. Das finde ich sehr viel hübscher als die normale Zeitangabe.

Nur ein klein wenig musste ich rumsuchen, bis ich eine Lösung für WordPress gefunden hatte. Im Ninedays Blog erklärt Terri Ann wie es geht und was der PHP-Code genau macht.

Da ich schon sehr viel Wert darauf lege das hier alles auf deutsch ist, übersetzte ich die wenigen Texte schnell. Außerdem habe ich das Skript so angepasst, dass es statt vor 1 Minute nun vor einer Minute ausgibt. Dazu habe ich in jede if-Abfrage noch ein weiteres „if“ eingebaut, das die Zahl 1 durch einen Text ersetzt. Das sieht in meinen Augen besser aus. Den von mir verwendeten Code gibt es nach dem Klick.

Den ganzen Beitrag lesen.

Neue Schriftarten braucht das Land!

Wer hier aufmerksam mitliest, dem ist es schon aufgefallen: Ich suche in der letzten Zeit verstärkt nach Möglichkeiten um von den üblichen, „websicheren“ Schriften wegzukommen. Ein wenig habe ich mich schon an den Standardschriften sattgesehen. Außerdem ist im eher „verschnörkelt-verspielten“ Bereich da relativ wenig zu machen. Wenn man nicht gerade ComicSans einsetzen möchte.

Grundsätzlich ist es ja erst einmal so, dass die Schriftart die ein Browser darstellen soll auch auf dem Computer des Seitenbesuchers vorhanden sein muss. Es bringt mir also nichts, TotalCooleSchrift.ttf auf meiner Seite zu benutzen, wenn außer mir dieses Schrift niemand besitzt. Das klingt nach einem Problem!

Natürlich bin ich nicht der einzige, der sich mit diesem Thema auseinandersetzt und so haben sich schon einige kluge Menschen ein paar Gedanken um das Thema gemacht. Nachdem ich nun auch ein wenig recherchiert habe, sind mir grundsätzlich zwei Methoden in Erinnerung geblieben.

  • sIFR: Der auszugebende Text wird mit Hilfe von Javascript dynamisch in Flash gerendert. Das nennt sich dann sIFR.
    Hier liegt der zu verwendende Schriftsatz als Flash-Datei auf dem Server und mit ein wenig Javascript-Magie werden dann vorher bestimmte HTML-Elemente durch Flash-Elemente ersetzt. Sehr cool dabei: Der Text ist auch weiterhin markierbar und lässt sich auch kopieren. Wird Flash vom Browser nicht dargestellt, etwa weil das Plugin nicht installiert ist, rendert der Browser den normalen HTML-Tag. Das klingt doch alles schon mal ganz gut.
    Ein Nachteil in meinen Augen ist aber die Benutzung von Flash. Gerade auf dem Mac ist das Plugin nicht gerade ausgereift und verursacht teilweise eine enorme Prozessorlast. Ein wenig frickelig war bei meinen ersten Versuchen das anschließende justieren von Größe und Abständen des Textes mit CSS. Hier gilt es sich gegebenenfalls mal einzuarbeiten.
  • @font-face: Auch per CSS gibt es eine Möglichkeit, eigene Schriften in eine Webseite einzubinden. Kurioserweise wurde diese Methode übrigens ursprünglich von Microsoft entwickelt, war Bestandteil von CSS 2 und flog dann wieder aus den CSS 2.1-Spezifikationen, weil die Browserentwickler sie nicht implementierten. Mit CSS 3 kommt @font-face nun wieder. Dieses Mal ziehen anscheinend auch alle mit.
    Bei dieser Methode muss die entsprechende Schriftart in verschiedenen Varianten auf dem Webserver bereitstehen. Natürlich hat man sich wieder einmal nicht auf einen 100%igen Standard einigen können. Großer Vorteil: Es werden keine weiteren Technologien verwendet, HTML und CSS setzt man so oder so ein, wie auch schon bei der sIFR-Variante lässt sich hier der Text natürlich auch kopieren.
    Bei ersten Tests hat das Einbinden der Schriftarten leider nicht immer 100%ig funktioniert. Schade.

Das Ersetzen von Schrift durch Bilder (auch dynamisch, z.B. per GDlib) kommt für mich nicht in Frage. Die Lösungen über die ich hier bisher stolperte waren alle wesentlich komplizierter und aufwändiger als die oben genannten, das Ergebnis dafür aber eher nicht so schön.

Soweit zu den beiden Möglichkeiten, die ich mir noch näher anschauen muss. Beide Varianten sehen sehr vielversprechend aus, ich glaube dass ich für meine Zwecke schon was finden werde. Spaß am Basteln hatte ich ja schon immer, in der nächsten Zeit werde ich mich mit dem Thema noch ein wenig ausführlicher auseinandersetzen und die für mich beste Methode herausfinden.

SEO braucht kein Mensch

Search Engine Optimization is not a legitimate form of marketing. It should not be undertaken by people with brains or souls. If someone charges you for SEO, you have been conned.

Derek Powazek schreibt mir in seinem sehr lesenswerten Beitrag mit dem Titel Spammers, Evildoers, and Opportunists die Worte von den Lippen: SEO braucht kein Mensch. Das Geld, was man für die „Optimierung“ und das „Ranking“ seiner Seiten ausgibt, ist anderswo viel besser aufgehoben. Zum Beispiel bei einem Entwickler, der vernünftigen HTML-Code schreibt. Danach dann bei einem Menschen, der gute und interessante Inhalte für die Seite schreibt. Wirklich schlecht aufgehoben ist das Geld bei einem Menschen der Kommentarformulare und Foren voll schreibt.

Webseiten die in einem vernünftigen Code vorliegen, können von Suchmaschinen gelesen, verstanden und ordentlich gelistet werden. Gute Inhalte machen Menschen auf die Seite aufmerksam und sorgen für Verlinkungen und damit neue Besucher. So einfach ist das. Eigentlich.