Software
Dienstag28. August 2012

Im Dezember letzten Jahres habe ich bereits über meine Erfahrungen mit Sublime Text 2 geschrieben und das eine oder andere Plugin empfohlen, welches die Arbeit mit HTML/CSS und JavaScript erleichtert. Damals habe ich mich gefreut, dass ich erstmals in einem Editor unter Windows ohne größere Verrenkungen einen Linter ans Laufen gebracht habe, um meine JavaScript-Files auf problematischen Code hin überprüfen zu können. Mittlerweile ist Sublime Text 2 in der finalen Fassung 2.0.1. erhältlich und auch beim Linting ist alles mittlerweile noch viel bequemer geworden.

Das Plugin der Stunde heisst “SublimeLinter” und liefert ein Live-Linting für JavaScript, CSS und noch zahlreiche andere Sprachen und Formate (Ruby, Java, Perl). Installiert wird es sinnvollerweise über den überaus bequemen Plugin-Manager PackageControl, der alle installierten Plugins selbstständig auf dem jeweils aktuellen Stand hält (bequemer geht’s nicht mehr).

Für Mac-Nutzer war’s das bereits, Windows Nutzer müssen sich zusätzlich Node.js installieren, um in den Genuss des Live-Lintings zu kommen. Hintergrund dafür ist, dass OS X standardmäßig eine JavaScript-Engine mit an Bord hat (genannt: JavaScriptCore), während man unter diese mit Node.js nachrüsten muss. Mittlerweile ist aber auch Node unter Windows mit bequemen 2..3 Klicks einrichtet - also keine echte Hürde mehr. Dann noch ein Neustart des Editors und es kann losgehen.

Sobald man eine JavaScript-Datei geöffnet hat, arbeitet der Linter im Hintergrund. Entdeckt er einen Fehler, so wird die entsprechende Code-Zeile mit einem weißen Rahmen umrandet, wie im Screenshot zu erkennen ist. Die einzelnen Fehler lassen sich per Tastaturkürzel (Nächster Fehler: Strg+Alt+E, vorheriger Fehler: Strg+Alt+Shift+E ) ansteuern. Ist der Cursor auf der markierten Zeile, so findet man in der Statusleiste des Editors (die befindet sich üblicherweise am unteren Rand) eine Erklärung, was der Linter auszusetzen hat und in der Codezeile ist die betreffende Stelle zusätzlich mit einem weißen Unterstrich markiert. Das Überprüfen von bestehendem Code, wie auch das Schreiben von sauberem JavaScript wird damit wirklich sehr erleichtert.

Die Konfiguration des Linters ist ebenfalls - dank Sublime Text - sehr übersichtlich gelöst. Über Preferences->Package-Settings-SublimeLinter öffnet man zunächst die Datei “Settings - Default”, kopiert sich deren Inhalt und fügt sie in die - über das gleiche Menü erreichbare - “Settings - User” ein. Anschließend kann der Linter nach Herzenslust konfiguriert werden - zumal alle Optionen dokumentiert sind.


Samstag31. Dezember 2011

Es hat nur wenige Tage gebraucht, um mit Sublime Text 2 warm zu werden. Dieser schlanke, spartanisch aussehende Editor hat es faustdick hinter den Ohren und mich erstaunlich schnell verzaubert. Das schönste daran, es gibt ihn sowohl für Windows, OSX als auch unter Linux. Es ist also überhaupt kein Problem, als Entwickler zwischen den einzelnen Welten hin- und herzuspringen, die Entwicklungsumgebung ist immer mit dabei.

Sublime Text 2 kommt mit einer ganzen Reihe verschiedener Color-Schemes daher. Ich persönlich mag dunkle UIs, weil ich oft bis tief in die Nacht programmiere und kann das Monokai-Theme empfehlen (gibt’s übrigens auch für Coda).

Eines der Highlights des Editors sind die zahlreichen Plugins. Zunächst solltet Ihr Euch aber Package Control installieren, einen bequemen Paket-Manager für Sublime Text 2. Über diesen könnt Ihr dann bequem aus Liste die zu installierenden Pakete auswählen, die Installation geschieht in der Regel vollautomatisch. Als Empfehlung hier eine kleine Auswahl der bei mir installierten Pakete:

  • Alignment - erleichtert die Ausrichtung des Quelltextes, z.B. vertikale Ausrichtung an Gleichheitszeichen
  • BracketHighlighter - Hervorhebung zusammengehöriger Klammern
  • Sublime JSLint - vollautomatisiertes Linting für JavaScript Code aus dem Editor heraus. Bequemer geht es nicht mehr
  • Tortoise - Speziell für Windows User interessant, erweitert es den Editor um Menüeinträge und Keyboard-Shortcuts zur Ansteuerung von Tortoise, dem defakto Standard-SVN-Client unter Windows
  • Zen Coding - komplexes Plugin zur Code-Vervollständigung für HTML & CSS

JSLint Konfiguration

Obgleich das JSLint Plugin auf Anbieb funktioniert (um eine Java-Runtime braucht man sich nicht kümmern, die kommt gleich mit), ist es dennoch sinnvoll, dem Linter ein wenig Wind aus den Segeln zu nehmen, um nicht von tausenden angeblichen Fehlermeldungen zugeschüttet zu werden. Die Konfiguration erfolgt über ein Config-File, welches man im Editor selbst über Preferences->Package-Settings->JSLint->Settings-Default erreicht.

Unter “jslint_options” kann man hier den Linter entsprechend der eigenen Vorlieben anpassen. Folgende Optionen habe ich gesetzt:

—predef $,document
Wer wie ich viel mit jQuery arbeitet, wird um die Option predef nicht herumkommen. Sie dient dazu, JSLint über globale Variablen zu informieren, auf die der zu prüfende Code zugreift und deren Benutzung somit nicht als Fehler gewertet wird. Für jQuery sind das mindestens $, bzw. jQuery und document.
—white
Ist meinem persönlichen Coding-Stil geschuldet, dass ich nicht von JSLint über die Verwendung von Leerzeichen belehrt werden will.
—browser
Damit werden typische gobale Variablen der Browser verfügbar, z.B. window.
—sloppy
Sollte immer aktiviert werden, solange man noch nicht mit “use strict”; arbeitet.

Das ganze sieht dann fertig so aus:

// Options pass to jslint.
"jslint_options": "--predef $,document --white --sloppy --browser"

Eine vollständige Liste der Optionen gibt es hier. Hat man das hinter sich gebracht, kann man den Linter jederzeit mit Crtl+J anschmeißen und sich anschließend gemütlich durch die Fehlerliste navigieren. So bequem hatte ich es bisher in keinem Editor.

 

 


Dienstag26. April 2011

Ostern ist gerade vorbei, doch ich habe noch eine kleine Überraschung. Seit der Veröffentlichung des YAML Builders 1.0 im Februar 2008 war mir klar, dass dies die Richtung ist, in die ich mit meinen zukünftigen Projekten verfolgen wollte. Zum einen bin ich selbst ein eher visuell orientierter Mensch, zum anderen wollte ich schon damals nicht akzeptieren, dass die Community zwar täglich Webapplikationen wie Google Mail & Docs sowie die Vorzüge von HTML5 hypt, der normale Webentwickler aber seine CSS-Layouts in der Regel auch heute noch im Texteditor schreibt und immer wieder den Browser anklickt, F5 drückt, um sein Getipptes alle paar Minuten auf Fehlerfreiheit zu überprüfen. Das kann nicht die Zukunft sein.

Also habe ich angefangen, darüber nachzudenken, wie sich das Konzept hinter dem YAML-Builder sinnvoll aufbohren lässt. Nach zahlreichen Diskussionen, Tests und JavaScript-Lernerei habe ich angefangen. Dieser Beginn meines neuen Projektes »Thinkin’ Tags« liegt nun ca. 2 Jahre zurück und es ist Zeit, die ersten Ergebnisse der Programmierarbeit der letzten zwei Jahre vorzustellen.

Das Projekt »Thinkin’ Tags«

»Thinkin’ Tags« ist eine völlig neuartige, browserbasierte Entwicklungsumgebung für das schnelle Erstellen von Layout-/Webseiten-Prototypen mit bisher einzigartigen Features. »Thinkin’ Tags« ist als webbasierter Dienst konzipiert, der nach erfolgreicher Betaphase neben einem kostenfreien Zugang auch kostenpflichtige Premiumfeatures anbieten wird (allerdings wird bis dahin noch etwas Zeit vergehen). Die Layout-Prototypen können entweder von Grund auf mit einfachem HTML & CSS erstellt werden oder optional auf Basis verschiedener CSS-Frameworks. Dabei steht selbstverständlich YAML (aktuell in der Version 4 alpha3) zur Verfügung aber auch Grid-Frameworks wie Blueprint CSS (bereits experimentell implementiert) sowie zukünftig auch 960.gs sind angedacht.

Der große Vorteil des browserbasierten Prototypings in Verbindung mit einem CSS-Framework ist, dass der auf diese Weise entstehende Code in großen Teilen weiter- bzw. wiederverwendbar ist für die finale Umsetzung des Layouts für den Produktivbetrieb. Einerseits erlaubt der visuelle Ansatz, CSS-Layouts im Browser zu »entwerfen«, denn dank der mittlerweile hervorragenden Performance aktueller Browser und den visuellen Gestaltungsmöglichkeiten mit CSS2 und CSS3 ist das Vorzeichnen in Grafikprogrammen wie Photoshop in vielen Fällen unnötig. Andererseits sichert die professionelle Codebasis und die Ausrichtung von »Thinkin’ Tags« als Werkzeug für erfahrene Frontendentwickler eine Codequalität, die ein eine annähernd vollständige Übernahme des Prototypen in die nachfolgenden Enwicklungsschritte ermöglicht. Und auch wenn in der Vergangenheit zahlreiche desktopbasierte WYSIWYG-Editoren (Dreamweaver, GoLive, ExpressionWeb) nicht das erreicht haben, was ihre Werbung verspricht, ist dieser Ansatz innerhalb eines Browsers ausgesprochen reizvoll.

Das folgende Video basiert auf einem etwas älteren Entwicklungsstand (Januar 2011), es gibt jedoch einen recht guten Überblick darüber, wie die Applikation bedient wird und was in technischer Hinsicht momentan möglich ist.

Einige Features ...

  • Vollständig browserbasierte Erstellung von Layout-Prototypen (in Firefox, Chrome, Safari und Opera)
  • Unterstützung für CSS-Frameworks YAML und Blueprint CSS (960.gs in Vorbereitung)
  • Der Anwender hat nahezu vollständige Kontrolle über Markup und CSS
  • CSS-Parser zeigt CSS-Eigenschaften einschließlich Vererbung an
  • Jegliche CSS-Änderungen werden unmittelbar sichtbar
  • Verschiedene Darstellungsmodi zur Erstellung des Markups, sowie des Screen- und Print-Layouts
  • Projektexport und Download als ZIP-File

 

Den gesamten Beitrag lesen


Mittwoch25. Februar 2009

Seit gestern macht die Heise-Meldung über die Fa. Xenocode und ihre virtualisierten Webrowser, welche in einer Sandbox laufen und somit keine lokale Installation benötigen, die Runde in diversen Blogs und bei Twitter. Zitat aus der Heise-Meldung:

“Auf der Website des Herstellers Xenocode stehen sieben verschiedene Browser zum Download bereit, die in ausführbare .exe-Dateien verpackt sind. Damit können etwa Webentwickler ihre Kreationen direkt in einem Internet Explorer der Versionen 6, 7 und 8 sowie in Chrome, Safari, Firefox und Opera testen.”

Ich habe heute morgen die IE-Varianten kurz getestet und kann nur ausdrücklich davon abraten, diese Pseudo-Sandbox-Tools zu verwenden. Auf meinem XP Rechner war nach einem einminütigen Test des Sandbox-IE6 mein lokal installierter IE7 unbenutzbar und musste vollständig neu installiert werden (auch ein Reboot zuvor hatte keine Besserung gebracht). Im selben Atemzug, in dem ich das Dilemma bemerkte, flatterten bereits ähnlich klingende Problemmeldungen von Freunden (Jens Grochtdreis, Tom Klingenberg) bei mir ein, leider in beiden Fällen für mich ca. 10min zu spät.

Die Kommentare unter dem Heise-Newsartikel füllen sich übrigens auch zunehmend mit Problemmeldungen, die darauf schließen lassen, dass es sich hier um alles andere als eine saubere und vollständig gekapselte Sandbox-Lösung handelt.

Deshalb: Finger weg von den Dingern!

Für den Test des Internet Explorers ist der IETester nach wie vor die empfehlenswerte und sicherere Alternative, von Firefox gibt es portable Versionen bei portableapps.com. Für Opera, Safari und Chrome ist mir zwar momentan nichts gleichwertiges bekannt, jedoch lassen sich diese Browser leicht installieren und auch wieder rückstandsfrei aus dem System entfernen. Weiterhin gibt es von Microsoft aus Basis von VirtualPC kostenfreie virtuelle Maschinen für IE6 und IE7, auf denen man ebenfalls beliebig viele Browser störungsfrei nachinstallieren und ausprobieren kann. Und zum Abschluss wären dann noch VMWare oder VirtualBox als weitere, zuverlässige Virtualisierungslösungen zu nennen.


Montag16. Februar 2009

YAML kommt bereits seit einigen Versionen mit einem speziellen Debug-Stylesheet daher, welches einerseits ermöglicht, die Layoutstruktur zu visualisieren, andererseits auch darüber Auskunft gibt, ob die CSS-Datei iehacks.css im Internet Explorer korrekt eingebunden ist. Ebenfalls seit einiger Zeit liegt das Debug-Stylesheet dem Downloadpaket bei, sondern es konnte auch über ein kleines Bookmarklet in jede beliebige Seite eingebunden werden. So schön der Gedanke auch ist, so unübersichtlich ist das Ergebnis, wenn ein solches Debug-Stylesheet zuviele Informationen enthält. Deshalb habe ich im Verlauf der letzten Wochen YAML Debug vollständig überarbeitet und eine eigenständige Applikation daraus entwickelt.

YAML Debug Application Screenshot

Die neue Applikation basiert auf jQuery und wird per Bookmark auf jeder beliebigen Seite hinzugeladen. Die Funktionalität umfasst Informationen über den Rendering-Mode, die Anzahl eingebundener externer Stylesheets, Scripts und Bilder. Per Klick können veraltete Elemente oder auch Elemente mit Inline-Styles hervorgehoben werden. Ebenso ist es möglich, sich auf einen Klick einen Überblick über die Layoutstruktur (DIV-Verschachtelung) oder die semantische Auszeichnung der Inhalte direkt im Layout zu verschaffen. WAI-ARIA roles, states und properties können hervorgehoben werden, Relationen z.B. über aria-labelledby macht das Tool durch das Hovern mit der Maus über die jeweilige Eigenschaft sichtbar. Schließlich gibt YAML Debug auch Auskunft über alle eingebundenen Stylesheets. Alle externen Stylesheets können zudem deaktiviert, angezeigt oder direk an den Validierungsdienst des W3C gesandt werden.

Einen vollständigen Überblick über den Funktionsumfang gibt es auf der zugehörigen kleinen Microsite, die ich diesem Projekt spendiert habe. Von dort kann dann auch das Bookmarklet bezogen werden. Aus der Browserwelt werden momentan Firefox 3, Opera 9.x und Safari 3.x/Webkit voll unterstützt, wobei der Safari 3.x aktuell das Deaktiveren von per @import eingebundenen Stylesheets verweigert. Der Internet Explorer 7 erhält momentan nur eine sehr eingeschränkte Unterstützung. Hier habe ich mich aufgrund der doch umfangreichen Abweichungen vom Standard (sowohl bei CSS, als auch bei JavaScript) auf die Bereitstellung der Stylesheet-Infos beschränkt, um gerade bei YAML-basierten Layouts eine einfache Kontrolle der korrekten Einbindung der Patch-Dateien zu ermöglichen. Auf die JS-Nachprogrammierung der ansonsten per CSS funktionierenden Hervorhebungsoptionen habe ich zunächst verzichtet, da es sich bei YAML Debug um ein Markup-Analysetool handelt und dieser ist im Normalfall in allen Browsern identisch. Demzufolge sollte man für seine Tests einen der o.g. voll unterstützten Browser verwenden.

Ich wünsche Euch viel Spaß mit dem Tool und freue über jegliches Feedback, sowohl hier in den Kommentaren als auch über die Projektseite.

Für Feedback (Meinungen, Bugmeldungen oder Wünsche für weitere oder verbesserte Funktionen) habe ich auf der Projektseite ein Kontaktformular eingerichtet, von welchem ihr hoffentlich rege Gebrauch macht. Die aktuelle Version 0.9 ist noch im Betastadium und ich möchte durch den öffentlichen Test mehr Informationen und vor allem Featurewünsche sammeln, um das Tool Schritt für Schritt zu vervollständigen. Ab YAML 3.1.1 wird es im Übrigen auch das bisherige debug.css ablösen.

Nachtrag: Als Spielwiese eignen sich besonders gut die YAML-Layoutbeispiele oder die Seite Einfach für Alle, die bereits mit WAI-ARIA angereichert ist und sich daher die Funktionalität des Tools dort sehr schön testen läst.


Seite 1 von 3 Seiten

 1 2 3 >