Die Redakteuse

Schlagwort: Tech

  • Content-Management über Ordner und SubVersion

    Wie man meinem Blog entnehmen kann, beschäftige ich mich seit ca. 2 Jahren mit DITA. Anfangs haben wir unsere Daten über Ordner und SVN verwaltet. Inzwischen haben wir schon fast alles im Redaktionssystem drin – das SVN ist bald Geschichte. Da ich aber weiß, dass ein Redaktionssystem häufig zu den unerfüllten Träumen von technischen Redakteuren gehört, teile ich hier mal meine Erfahrungen mit DITA und SVN.

    Übersetzungsmanagement

    Die einzelnen Sprachen auf demselben Stand zu halten gestaltet sich schwierig. Man muss sehr diszipliniert sein, denn sonst vergisst man leicht, dass ein kleiner Fix in der einen Sprache auf die anderen übertragen werden sollte.

    Bei Änderungen an bestehenden Daten hat man das Problem, das man das Delta entweder manuell rauskopieren, übersetzen und dann wieder reinkopieren muss. Oder man gibt eben immer nur komplette Topics zur Übersetzung, auch wenn nur ein Satz neu ist (was aber schnell recht teuer werden kann).

    Verwaltung

    Versionshistorie ist Gold wert 🙂

    Dateileichen herauszufinden ist schwierig, z.B. wenn man in der Konzeptionsphase mehrere Topics angelegt hat und am Ende einige gar nicht braucht. Bei uns sind solche Leichen teilweise übersetzt worden, obwohl sie nie gebraucht wurden. Hier können kleine Skripte hilfreich sein, die alle Dateien listen, die in keiner Map referenziert sind.

    Man schludert schnell mit SVN-Kommentaren und am Ende weiß man selber nicht mehr, was man eigentlich mit  dem Kommentar „Änderung“ gemeint hat 😉

    Tags und Branches sind äußerst wichtig, damit man komfortabel an neuen Projekten arbeiten kann und immer noch gleichzeitig den aktuellen Online-Stand aktualisieren kann. Am Anfang hab ich nur auf dem trunk gearbeitet, was darin resultierte, dass ich im Projektverlauf keine Updates am Online-Stand machen konnte und als sich dann das Projekt verschob, alle Änderungen händisch zurücknehmen musste.

    Wenn man die Ordner erst einmal angelegt hat, wird es ziemlich kompliziert sie wieder zu reorganisieren, wenn man z.B. merkt, dass die Struktur doch nicht so gut ist. Zum einen können Referenzen zwischen Topics aus verschiedenen Ordnern kaputt gehen, zum anderen muss man im SVN aufpassen, dass man die Versionshistorie nicht verliert.

    Fazit

    Man kann auch topicorientiert schreiben und mit XML arbeiten ohne ein CMS zu benutzen. Eine Sache, die gern außer Acht gelassen wird, aber ich muss sagen, dass es nicht drauf ankommt welches Tool oder welche Standardisierungsmethode man verwendet – wichtig ist, was am Ende rauskommt!

    Wenn man als Redaktion also kein Redaktionssystem zur Verfügung hat und trotzdem mit DITA arbeiten will, ist eine Verwaltung über Ordner und SVN meiner Meinung nach eine super Alternative.  Die Benutzung von SVN ist sogar absolut obligatorisch, wie ich finde.

    Bei dieser Arbeitsweise müssen allerdings viele Dinge über Regeln und Workflows als „Denk dran“-Lösung abgedeckt werden, und die Erfahrung zeigt nun mal, dass man im Eifer des Projektgefechts nicht immer dran denkt.  Man kann zwar Skripte schreiben, die einem bestimmte Dinge abnehmen, aber am Ende muss man eben doch dran denken, das auch zu benutzen. Wenn sich mit der Zeit solche kleinen Fehler einschleichen, hat man irgendwann ein Problem. Man muss das Redaktionsteam außerdem ausführlich  schulen, denn die Grundfunktionen von SVN sind relativ schnell drin, aber gerade solche Dinge wie Tags/Branches/Merging sind nicht intuitiv.

  • Dateiendungen in DITA – kleines Problem

    Heute ein kleiner Wissensschnipsel zu Dateiendungen in DITA. Prinzipiell ist es inzwischen erlaubt, sowohl Dateien mit XML-Endung als auch welche mit DITA-Endung in eine Map zu integrieren. Ich persönlich finde ja so einen Misch-masch nicht gut, und als ich es mal getestet habe, hat es auch nicht gut funktioniert.

    Kommen wir aber zu einem Problem, das seine Ursache in diesem Misch-Masch hat, und das in den meisten Fällen gar kein Problem ist, außer man schafft es mal wieder einen Sonderfall zu erwischen. So wie ich 😉

    Ich musste gerade bei einer Transformation einem Topic die Information mitgeben, welchen Parent es hat – und zwar musste es die ID des Parents sein.

    Da kam mir sehr gelegen, dass in unserem Redaktionssystem der Dateiname auch als Topic-ID fungiert .
    [xml]<task id="d262.dita">…</task>[/xml]

    Also geb ich hier einfach das href-Attribut des Parents aus, das ja den Dateinamen beinhaltet. Sehr einfach, juhu!
    [xml]<xsl:value-of select="../@href"/>[/xml]

    Aber Moment im Endergebnis der Transformation finde ich plötzlich das hier
    [xml]
    <topic id="t_Duda.dita">
    <title>Duda</title>
    <topic parentid="t_Duda.xml" id="t_Dida.dita">
    [/xml]
    Die Parent-ID stimmt im Prinzip, bloß ist da plötzlich XML als Dateiendung angegeben! Was soll das denn jetzt?

    Ich habe eine Weile gesucht, blieb aber ratlos. Ein Artikel zur Verwendungvon Dateien mit XML-oder DITA-Endung hat mich dann auf die Lösung gebracht. Beim Generieren der temporären Dateien aus denen das Toolkit letzten Endes die Ausgabe baut, kann man sich auch „aussuchen“ welche Dateiendung diese temporären Dateien haben sollen.

    Standardmäßig werden sie in XML generiert, aber das kann man in seinen Build-Dateien auch ändern.. Also habe ich in meine Build-Datei flugs folgenden Parameter eingebaut:
    [xml]<param name="dita.extname" value="dita"/>[/xml]

    Und schon hat es gepasst!
    [xml]
    <topic " id="t_Duda.dita">
    <title>Duda</title>
    <topic parentid="t_Duda.dita" id="t_Dida.dita">
    [/xml]

  • Breadcrumbs in DITA-XHTML – Update

    Ich habe das Breadcrumbs-Plugin ja bereits vorgestellt. Der damalige Bug bei der Verwendung von Reltables war sehr schnell behoben – superklasse!

    Aber schon damals ist mir eine unschöne Sache aufgefallen: der Text für das Wurzelelement in der Breadcrumb ist hart kodiert. Das ist natürlich gerade bei der Internationalisierung der Hilfe eher so ein bisschen doof. Schließlich will ich ja nicht für jedes Generieren jeder Sprache immer wieder die Stylesheets anfassen. Daher hab ich eine Internationalisierung an dieser Stelle eingebaut, d.h. der Text für das Wurzelelement wird je nach Sprache der Map & Topics generiert.

    Wer sich dafür interessiert, befolge bitte diese Schritte:
    In der Datei dita.xsl.maplink.xsl aus dem Plugin wird dieser Schnipsel
    <xsl:param name="indexLinkText" select="'Index'"/>>

    zu diesem


    <xsl:param name="indexLinkText">
    <xsl:call-template name="getString">
    <xsl:with-param name="stringName" select="'Start'"/>
    </xsl:call-template>
    </xsl:param>

    In der de-de.xml im xsl-Verzeichnis des Toolkits muss natürlich der entsprechende String angelegt werden:
    <str name="Start">Start

    Dann muss man noch den obigen Schnipsel aus Zeile 9 in das xsl-Template (ab Zeile 14) verschieben, also so:

    <xsl:template match="*" mode="link-to-other">
    <xsl:param name="pathBackToMapDirectory"/>
    <xsl:param name="indexLinkText">
    <xsl:call-template name="getString">
    <xsl:with-param name="stringName" select="'Start'"/>
    </xsl:call-template>
    </xsl:param>
    <xsl:if test="$doAncestors='yes'"> ......

    Wenn man die Parameterdefinition global belässt, wird immer nur en-us als Sprache erkannt, warum auch immer.

    So, das war's auch schon. Und zu meinen Tricks, um mich beim Programmieren und Testen bei Laune zu halten, gehören motivierende Ausgabetexte für den Fall, dass es endlich klappt, und eher so die destruktiven für den anderen Fall 😉

  • Und es hat Bing gemacht!

    Mich hat der Hype um Microsofts neue Suchmaschine Bing relativ kalt gelassen, weil…naja, seien wir mal ehrlich… wann hat einen zuletzt was aus diesem Softwarehause schon groß umgeworfen?

    Nun mehren sich die Meldungen, dass der Marktanteil steigt und ich musste nun doch mal kurz reinschnuppern. (mehr …)

  • Spezialisierung: Eigene DITA-Attribute definieren

    DITA bietet bereits einige Attribute, die schon sehr viele wichtige Dinge in der technischen Dokumentation abdecken: product, audience, platform seien da als Beispiele genannt.

    Wenn es um sehr firmenspezifische Dinge geht, benötigt man hier schnell eigene Attribute. Für mich persönlich sehr wichtig, sind auch vorgegebene Attributwerte, weil eine vorgegebene Auswahl immer sehr viel weniger fehleranfällig ist.

    Was bedeutet Spezialisierung?

    In DITA nimmt man etwas Vorhandenes, also einen bereits vorhandenen Topictyp (z.B. Concept) oder ein bereits vorhandenes Attribut, und leitet davon seine eigene Version ab: man spezialisiert. Inbesondere in Bezug auf Topictypen ist wichtig zu wissen, dass man Festlegungen der DTD von der man ableitet, nicht „aufweichen“ kann. Wenn ein Element <hups> in der Ur-DTD zwingend erforderlich ist, kann man es in der Spezialisierungs-DTD nicht optional definieren.

    Attribute spezialisieren

    Es gibts 2 Arten von Attributen, die man spezialisieren kann: props (speziell für Filtern) und base (Sinn und Zweck hat sich mir noch nicht erschlossen…). Da ich mein neues Attribut zum Filtern des Contents benutzen möchte, benutze ich daher das props-Attribut.

    Schritt 1: Attribut deklarieren
    Ich werde nun ein Attribut definieren, das beschreiben soll, für welchen Hilfekontext das Element gilt: für die Hilfe im Web oder für die Hilfe in der Software.

    1. Zuerst erstelle ich eine Datei namens helpContextPropsDomain.ent mit folgendem Inhalt:



      Im ersten Teil lege ich den Namen des Attributs (help-context) fest und in meinem Fall auch 2 vordefinierte Werte (webpage, software).
    2. Ich speichere die Datei im dtd-Verzeichnis des DITA-OT ab.

    Schritt 2: Attribut der DTD bekannt machen

    1. Nun öffne ich die concept.dtd und lege noch eine Sicherheitskopie von ihr unter anderem Namen ab Man weiß nie… ;).
    2. Unter dem Bereich DOMAIN ATTRIBUTE DECLARATIONS füge ich ein:

      SYSTEM "helpContextPropsDomain.ent"
      >
      %help-context-props-d-dec;
    3. Unter dem Bereich DOMAIN ATTRIBUTE EXTENSIONS erweitere ich :

    4. Unter dem Bereich DOMAINS ATTRIBUTE OVERRIDE erweitere ich :

      &ui-d-att; &hi-d-att; &pr-d-att; &sw-d-att;
      &ut-d-att; &indexing-d-att;&help-context-props-d-att;" >
    5. Diese Schritte müssen nun für alle Topictypen wiederhiolt werden, für die man das Attribut braucht.

    Schritt 3: testen 🙂

    1. Ich erstelle eine XML-Datei auf Grundlage dieser DTD
    2. Ich füge das Attribut _help-context=“webpage“_ in ein-Element ein
    3. Ich jage das Dokument durch einen Validator – und wenn der nicht meckert, hat es funktioniert

    Spezialisierung in XMetal DITA Edition
    Der XMetal DITA Edition bindet ein DITA-OT ein. Wie es scheint benutzt er dieses ausschließich zum Generieren.
    Die DTDs, die XMetal benutzt, liegen im Programmverzeichnis unter „…XMetaL 5\Author\DITA\DITA_OT_DTD\“<.

    1. D.h. die oben erstellten bzw. bearbeiteten Dateien müss dort hinein kopiert werden.
    2. XMetal neu starten
    3. Ein Concept anlegen
    4. Und sich freuen, dass man ein neues Attribut im Attribute Inspector sieht 🙂

    Mehr zum Thema
    In Eliot Kimbers Tutorial erfahrt ihr mehr zur Spezialisierung.

  • IBM Task Modeler: die Anfänge einer Dokumentation

    Ich bin in den letzten Monaten mehr land unter als mir lieb ist und man sieht doch eindeutig an der Zahl meiner Blogeinträge, dass ich nach Feierabend kaum noch Energie für TR abseits meiner Arbeit aufbringe. Dabei habe ich doch gerade in dieser arbeitsreichen Zeit wieder einigen Stoff gesammelt 🙂

    Tasks konzipieren
    jeder Schreiber kennt das: da sitzt man also vor dem leeren Blatt / dem weißen Screen und muss irgendwie anfangen mit der Doku. Ich fange in der Regel so an, dass ich mich erst einmal selber als Dummy durch das Produkt klicke und mir Tasks notiere, die ich dokumentieren würde. Von Mike Hughes habe ich mir abgeschaut, die größte Prio auf die Tasks zu setzen, da sie für den Nutzer erst einmal das Wichtigste sind, denn dieser will in erster Linie etwas MACHEN.

    Ideal für diese Vorgehensweise ist der IBM Task Modeler, ein eclipse-basierte Editor mit dem man Topics und ihre Beziehungen / Hierarchien in einer Map visualisieren kann. Man hat die Wahl zwischen einer Baumansicht und einer Listenhierarchie-Ansicht. Hier mal ein sehr einfaches Beispiel in einer Baumansicht:

    Per Tastenkombination kann man sehr schnell Child-Topics ( Strg+Pfeil nach unten) oder Schwester-Topics einfügen und somit sehr zügig arbeiten. Man kann die Topics außerdem in der Anordnung per „Drag and Drop“ wild verändern, was meiner Arbeitsweise sehr entgegen kommt.

    Ich sammele immer zuerst alle Informationen bzw. Topics und schiebe /lösche / erweitere /verteile dann so lange bis ich die perfekte Struktur finde. Gleichzeitig kann ich im Modeler auch schon alle Metadaten für die Topics bearbeiten oder die Reltables.

    Tasks exportieren

    Wenn ich nämlich all das fertig habe, kann ich ganz einfach hergehen und diese schöne Struktur mit allen Informationen exportieren: File > Export from Model > Stub Topic Files

    Der Task Modeler generiert mir sogenannte Stub Files, d.h. Dateigerüste für jedes Topic. Diese Dateigerüste enthalten auch direkt alle Informationen, die ich eben eingegeben habe. Also für alle Tasks werden dann echte Task-Dateien mit den eingegebenen Titeln, Attributen etc. angelegt. Zusätzlich ich kann festlegen, dass in der exportierten Map auch automatisch die Referenzen auf die Stub Files gesetzt werden und die Dateinamen der Stub Files ihrem Topictyp entsprechen, d.h. dass beispielsweise alle Task-Dateien mit dem Präfix t_ im Ordner tasks abgespeichert werden. Und zack – hab ich die Grundlage zum weiteren Arbeiten.

    Vorsicht ist allerdings speziell im Deutschen geboten, wenn man Umlaute im Titel verwendet, denn dieser ist auch Grundlage für die Dateibenennung und ID-Vergabe. Und der Task-Modeler schreibt diese Umlaute auch gnadenlos in den Dateinamen und in die ID: das Topic Lösung finden bekommt dann eben auch den Dateinamen t_lösung_finden.dita. Früher oder später führt so etwas immer zu Problemen, je nachdem wo die Dateien weiterverarbeitet werden. Mein Workaround war irgendwann, dass ich Umlaute in den Titeln einfach ausgelassen habe und sie später nach dem Export im Editor einfügte. Das ist schneller als alle Dateinamen und noch die ID zu bearbeiten.

    Fazit – Task Modeler rockt!

    Der Task Modeler ist eine super Unterstützung in der Konzeptionsphase einer DITA-basierten Dokumentation. Das Konzipieren ist schön einfach und am Ende kommt auch per Knopfdruck direkt eine schöne Arbeitsgrundlage raus, nämlich die Map plus Dateien.

    Das Handling der Eclipse-Oberfläche ist allerdings für Nicht-Entwickler etwas gewöhnungsbedürftig – diese ganzen Panels sind einfach etwas verwirrend. Wärmstens zu empfehlen ist das Task Modeler Tutorial – diese Zeit sollte man sich nehmen, wenn man effektiv mit dem Tool arbeiten möchte.

    Noch nicht getestet – Import von bestehenden Maps

    Angeblich kann man andere Maps auch in den Modeler importieren, was sich natürlich für strukturelle Nacharbeiten sehr empfehlen würde. Allerdings habe ich das bisher noch nicht machen müssen 🙂

  • DITA-Output filtern mit XMetal

    Wiederverwendung und Varianten
    Das Filtern wird in Zeiten der Wiederverwendung früher oder später notwendig. Man hat beispielsweise ein Produkt, dass es in einer Light-Version und einer Vollversion gibt. Natürlich werden sich hier die Hilfetexte zum größten Teil überschneiden – bis auf die kleinen Ausnahmen, wo dann in der Vollversion hier noch ein Schritt weniger ist und dort eine Option mehr verfügbar. Man hat also eine Wiederverwendungsquote von 90%, aber was tun? Die Hilfetopics nun zweifach vorhalten? Ne, da sträuben sich jedem guten Redakteur die Haare. Redundanz, nein danke!

    Nun, wie wär’s, wenn man einfach alle Varianten in eine Datei schreibt und die Teile, die nur für ein Produkt gelten mit einem Attribut versieht? Und dann beim Generieren einen Filter definiert, der nur Teile generiert, die einen bestimmten Attributwert enthalten? Klingt cool – isses auch!

    Attribute in DITA
    Es gibt für DITA schon einige fest definierte Attribute, die man an fast jeden Tag vergeben kann. Es sind gängigen Attribute nach denen man in der Doku filtert und für die man frei Werte definieren kann:

    • product
    • audience
    • platform
    • outputclass (erst ab DITA OT 1.4 unterstützt)

    Zu guter Letzt gibt es das otherprops-Attribut, das so ziemlich alles enthalten kann. Eine Art Auffanglager für den Rest sozusagen.

    DITA-Attributvergabe im XMetal

    Wir nehmen uns nun ein Beispiel, in dem ein bestimmter Handlungsschritt nur in der Print-Hilfe auftaucht und in der Online-Hilfe nicht, weil die Online-Hilfe kontextbasiert ist und ein Zwischenschritt wegfällt, der aber in der Print-Version nötig ist.

    Eigentlich sollte man dazu ab DITA 1.4 das Attribut outputclass verwenden, da ich aber noch auf DITA 1.3 arbeite, werde ich also das otherprops-Attribut verwenden. Ich markiere den <step> und  schreibe im Attribute Inspector einfach den Wert hinein nach dem ich filtern möchte.

    Der Nachteil hierbei ist, dass je nach Attributwert einem anderen Redakteur nicht unbedingt von Namen her sofort klar ist, nach was hier gefiltert wird. Wenn ich z.B. handbook als Wert eingebe, kann das einerseits bedeuten, dass ich für den PDF-Output etwas filtern möchte (es also eine technische Bedeutung hat) oder aber für den Dokumenttyp „Handbuch“ (was dann eher inhaltliche Bedeutung hat).

    Filterregeln in XMetal anlegen

    Hierzu muss man folgende Datei öffnen: c:\Programme\XMetaL 5\Author\Conditional Text\configs\ct_config.xml

    Hier kann man nun seine Attributwerte definieren und festlegen, wie diese in der Filterauswahl angezeigt werden. Ich habe hier den Attributkomplex zu otherprops bearbeitet. Für jeden Attributwert definiert man einen <value>-Tag, in name steht der Attributwert und in title steht der Anzeigename in der Filterauswahl.

    ´[....]

    Filterregeln auswählen

    1. Auf File > Generate Output from DITA map klicken.
    2. Im Dialog auf Show/Hide Conditional Text klicken.
    3. Hier kann man nun auswählen, welche Filterkriterien für den aktuellen Output gelten sollen.
      Ich will nun beispielsweise eine Online-Hilfe generieren, d.h. der <step>, der nur für Handbücher gilt, soll nicht generiert werden. Also klicke ich das Filterkriterium Onlinehelp an. Es wird alles generiert, was keinen Wert für dieses Attribut hat oder eben genau diesen Wert, d.h. der <step> mit dem Attributwert Handbook wird hier nicht generiert werden.

    Ergebnis
    Am Anfang steht also dieser Code:

    Öffnen Sie das Programm.

    Klicken Sie auf

    DateiNeu

    Editieren Sie die Datei.

    Und am Ende dieser Text:

    1. Klicken Sie auf Datei > Neu.
    2. Editieren Sie die Datei.

  • Firebug – neu entdeckt

    Ich habe ja schon einmal über den Nutzen von Firebug für Screenshots erzählt. Und schon wieder habe ich ein nützliches Feature entdeckt, auf das ich bisher einfach noch nie geklickt hatte, das aber insbesondere für die Webentwicklung extrem praktisch ist. Denn beim Layouten hat man oft das Problem, dass sich die CSS-Definitionen für padding oder margin einzelner Elemente in die Quere kommen und damit das Layout verhunzen.

    Einen schnellen Zugriff auf die Info, welches Element nun welche Werte für padding, margin oder border hat, bekommt man im Layout-Tab rechts unten im Firebug:

    In diesem Tab wird einem auf einen Blick zum aktuell in Firebug angewählten Tag angezeigt, welche Werte ihm für padding, margin oder border zugewiesen sind.

    Beispiel:

    1. Man rufe dieses Blog auf.
    2. Man öffne Firebug.
    3. Man markiere im Firebug folgenden Tag:

    4. Man sieht nun, dass die Navigation den Innenabstand 1 an allen Seiten hat und dass es beispielsweise nach oben hin 210px vom oberen Seitenrand entfernt ist.

  • XHTML-Output anpassen #2 – Wie mache ich einen Override?

    Ich habe nun damit angefangen Anpassungen vorzunehmen.

    Im Groben sind dazu folgende Schritte notwendig:

    1. Plugin-Verzeichnis und Dateien anlegen.
    2. Plugin integrieren.
    3. XSL anpassen.

    Plugin-Verzeichnis und Dateien anlegen

    Dazu habe ich unter DITA_OT/demo ein Verzeichnis meinxhtml für meine Overrides angelegt, d.h. hier liegen meine Anpassungen für den XHTML-Output. Für DITA ist das einfach ein Plugin.

    In diesem Verzeichnis befindet sich ein Ordner mit meinen XSL-Dateien und die plugin.xml. In dieser Datei muss man dem DITA-OT sein Plugin quasi bekannt machen. Das sieht dann so aus:

    Plugin integrieren

    1. Hierzu öffnet man sich eine Konsole im DITA-OT-Verzeichnis und führt folgenden Befehl aus: ant -f integrator.xml
      Ob das wirklich geklappt hat, kann man in der Datei xsl/dita.2xhtml überprüfen. Dort sollte die XSL-Datei nun über ein <xsl:import> referenziert werden.

    XSL anpassen

    Jetzt kommt der wirklich spannende Teil. Wie schon erwähnt, wird das meiste über die Datei dita2htmlImpl.xsl gemacht. Wenn ich also nun etwas Bestimmtes modifizieren will, z.B. dass nach dem Titel einer Note kein Doppelpunkt kommt, gehe ich wie folgt vor.

    1. Ich schaue über Firebug in den Quelltext des Outputs, um zu sehen, ob der Bereich irgendwie besonders ausgezeichnet ist. Im Falle der Note sehe ich, dass der Note-Title in einem span-Tag steht und mit der CSS-Klasse notetitle ausgestattet ist.
    2. Über diese Hinweise finde ich dann in der XSL-Datei das entsprechende XSL-Template für diesen Bereich:
    3. Ich kopiere nun das komplette Template in meine mein_xhtml.xsl.
    4. Um den Doppelpunkt zu entfernen, lösche ich die entsprechenden Anweisungen. In diesem Beispiel also: 

    5. Diese Änderung speichern.
    6. Output generieren.
      Und nun sollte der Doppelpunkt verschwunden sein. Leider muss man den Doppelpunkt für alle Note-Typen entfernen, die es gibt, also für Tipps, Warnungen etc.

    Hiermit lässt sich schon mal sehr viel machen. An die Grenzen der Overrides kommt man beim OT 1.3, wenn es um die Anpassung des Inhaltsverzeichnisses geht. Hier funktionieren Overrides nämlich leider, leider nicht. Doch dazu ein anderes Mal mehr 🙂

  • Meine liebsten Tools

    Ich bin immer wieder höchst entzückt, wenn ich irgendwo ein Programm entdecke, dass mir die Arbeit wirklich erleichtert. Der Vorteil an einem IT-Unternehmen liegt darin, dass man solche Sachen gerne mal zufällig beim Kollegen oder der Kollegin entdecken kann. Ich liebe Open-Source. Meistens.

    Daher habe ich gedacht, poste ich einfach mal eine Liste meiner unverzichtbaren Programme (tw. mit Plugins), was die Arbeit anbelangt.

    • Mozilla Firefox: Mal ernsthaft – er ist einfach nur genial! Und jede Webseite, die nur IE-kompatibel ist, stinkt! (An dieser Stelle ein freundlicher Gruß an den englischen Billigflieger! Es hat Spaß gemacht, herauszufinden, dass eure Ticketbestellung nur mit dem IE geht. Oh ja!)
      • Firebug: darum und für die Webentwicklung
      • Greasemonkey: um Seiten, die ich oft aufrufe, und an denen mich bspw. die Unübersichtlichkeit nervt, mit einem kleinen bisschen JavaScript so zu modifizieren, dass ich damit „leben“ kann (wie z.B. mein Firmen-Speiseplan…). Es gibt eine Vielzahl an fertigen Skripten für viele Seiten – einfach mal stöbern!
      • Adblock Plus: ebenfalls genial! Damit kann man Werbung bestimmter Seiten blocken und wird endlich nicht mehr von Werbebannern genervt. Zudem kommt dieses Add-on schon direkt mit einer Liste zu blockender Werbung, so dass das meiste schon direkt ausgeblendet wird. Und man hat die Möglichkeit diese Liste auch zu abonnieren.
      • Delicious Bookmarks: wer del.icio.us nutzt, kann hier beim Surfen seine Bookmarks direkt dort speichern
    • Total Commander: ein sehr komfortabler Dateisystem-Explorer mit zwei Panes und auch Tabs, den man sehr schön über die Tastatur bedienen kann (das weiß man sehr zu schätzen, wenn das Betriebssytem so fertig ist, dass es die Maus nicht mehr erkennt…). Und der gleichzeitig auch als FTP- oder SSH-Client fungieren kann. Für SSH benötigt man noch ein Plugin. Das Programm ist zwar nicht Open-Source, aber es kostet nicht viel bzw. kann man die Testversion unbegrenzt nutzen (beim Starten muss man dann lediglich immer einen Dialog wegklicken).
    • Launchy: ein kleines Progrämmchen, über das man in Windeseile andere Programme aufrufen kann, ohne sich durch das Start-Menü, Desktop-Verknüpfungen zu hangeln. Man ruft das kleine Launchy-Fenster über ein Tastenkürzel auf, tippt die ersten Buchstaben des gewünschten Programms ein und kann es direkt aufrufen. Mac- und Linux-Usern sollte das ganze bekannt vorkommen 🙂 An dieser Stelle nochmal Danke für den Tipp, liebe Kollegin 🙂
    • TortoiseSVN: SVN-Client, der sich in den Windows Explorer und auch den Total Commander integriert. Für den Total Commander muss man einige Einstellungen vornehmen.
    • Notepad++: ein Editor für jede Art von Quelltext. Sei es XML, XSLT, HTML oder PHP, ein rundum guter Editor. Die Dateien werden in Tabs angezeigt, das Syntax-Highlighting passt. Ein Tipp von Entwicklern und ich arbeite wirklich gern damit.

    Das sind einmal die wichtigsten Sachen. To be continued 🙂