Das ist paradox – Oder ist die Zeit noch nicht reif dafür?

Es gibt ja immer wieder Entwicklungen, Möglichkeiten, Wege, die sich nicht durchsetzen, nicht wahrgenommen oder nicht gegangen werden. Das hört sich jetzt tiefgründig an, ist aber ganz praktisch gemeint – nennen wir es das “Video 2000 Paradox”.

Die etwas älteren Semester haben schon eine Ahnung, was ich meine. Es geht um eigentlich überlegene technische Entwicklungen, die sich auf dem Markt einfach nicht durchsetzen können. So trat Anfang der 80er Jahre das VHS Videosystem seinen Siegeszug an und “Video 2000”, das technisch bessere Konkurrenzprodukt, war Geschichte (hier nachzulesen).

Ich möchte auf zwei ähnliche Dinge aufmerksam machen, bei denen ich Vermutungen anstellen möchte, warum diese Technologien sich nicht durchsetzen. Bei dem Videoformat Anfang der 1980er Jahre steckte natürlich viel Marketing hinter der Technik. Dieses Marketing war ausschlaggebend. Den Firmen kommt es nicht immer auf die beste Technologie an – sie wollen ihre Geräte verkaufen.

Bei meinen zwei Beispielen passt diese Erklärung aber nicht. Da kann man nur Vermutungen darüber anstellen, warum sich diese beiden Konzepte nicht durchsetzen. In beiden Fällen ist das sehr schade, denn es kann sich in zwei ganz wichtigen technologischen Bereichen ein längst überfälliger Standard nicht durchsetzen.

Das PNG Format.

Jeder, der Fotos mit einer Digitalkamera oder einem Handy macht kennt das Bildformat, in dem die Bilder als Standard gespeichert werden (abgesehen von den RAW Formaten, die Sensor-spezifisch und nicht einheitlich sind). Die Kameras nutzen als Standardformat das JPG-Format.

Dafür gibt es zunächst eine recht einfache und sehr plausible Erklärung. JPG hat sich etabliert, als das WWW immer mehr an Bedeutung gewann. Denn die ursprünglich etablierten Formate hatten große Nachteile. BMP, eine Bitmapdatei, konnte nicht komprimiert werden und das GIF Format, welches Transparenz und Animation darstellen kann, hatte nur einen Farbumfang von 256 Farben. JPG kann komprimiert werden. Und das funktioniert sehr gut – selbst bei hohen Kompressionsraten und damit kleinen Dateigrößen (war zur Zeit von 14400 Modems in den 90er Jahren ganz wichtig), wurden Bilder ansprechend dargestellt. Der große Nachteil von JPG: wenn man das Originalbild, also das nicht komprimierte Bild, nicht behält, dann ist die Kompression immer auch ein Qualitätsverlust. Möchte man eine vergrößerte Version eines JPG plötzlich benutzen, so wird man die schlechte Qualität erkennen.

Ein weiterer Nachteil: JPG kennt keine Transparenz. Entwirft man in einer Bildbearbeitung zum Beispiel ein Logo und möchte seinen Hintergrund transparent machen, weil man das Logo in unterschiedlichsten Umgebungen einsetzen möchte, dann kann man JPG vergessen. PNG lässt sich verlustfrei komprimieren, kennt den maximalen Farbumfang und kennt transparente Bereiche.
Man braucht also ein Format, das fast alle Vorteile vereint. Und das ist eben PNG. Diese Tabelle listet die wichtigsten Eigenschaften der gängigsten Bildformate auf. Die Vorteile von PNG im Vergleich zu JPG sind offensichtlich:

Format / Eigenschaft
GIF
JPG
PNG
TIFF
Kompression möglich
nein
ja
ja
nein
Kompression verlustfrei
nein
nein
ja
nein
Metadaten integrierbar
nein
ja
ja1
ja
Farbumfang
256
16,7 Mill.
16,7 Mill.
16,7 Mill.
Transparenz möglich
ja
nein
ja
nein
Animation möglich
ja
nein
nein
nein
CYMK Farbraum für Druck
nein
nein
nein
ja

Was bedeuten die Abkürzungen?

GIF –> Graphics Interchange Format
JPG –> Joint Photographic Experts Group (daher auch JPEG als gleichbedeutende Abkürzung)
PNG –> Portable Network Graphics
TIFF –> Tagged Image File Format

1 Metadaten folgen nicht dem ITPC oder EXIF Standard

Diese Tabelle zeigt, was PNG kann – es gibt kein rationales Argument, was gegen die Ablösung von JPG als Standardformat für Bilder spricht. Für ein Format wie TIFF spricht der CMYK Farbraum, der in der Druckindustrie relevant ist. Für GIF spricht ferner die Möglichkeit, kleine Videosequenzen als Animationen in ein Bildformat zu verwandeln.  Für die Weiterverarbeitung in Druckerzeugnissen können sowohl PNG als auf JPG Dateien in CMYK Farbräume überführt werden.

Der einzige plausible Grund, warum Digitalkameras immer noch JPG statt PNG erzeugen ist in der Fußnote versteckt. PNG speichert die Metadaten nicht in Standards ab. Metadaten sind alle Informationen zu einem Bild, mit denen Bilder später in Datenbanken klassifiziert werden können. Ein nicht unerheblicher Nachteil, der aber durch eine Erweiterung des PNG Standards behoben werden könnte.

Ich jedenfalls würde mir einen Umstieg auf PNG wünschen. Es würde einige Arbeitsschritte bei der Verwendung von Fotos, insbesondere auf Webseiten, vereinfachen oder sogar überflüssig machen.

PYTHON

Wer ganz praktisch Software schreibt, sei es im beruflichen Alltag oder als Nerd, versteht nach einiger Zeit, dass alle höheren Programmiersprachen denselben logischen Prinzipien folgen:

  • Bedingung
  • Fallunterscheidungen
  • Zählschleifen

Es gibt im Grunde nichts anderes in der Informatik. Lediglich das ganze Drumherum ist anders. Da werden Speicher optimiert, in dem man statt mit Variablen mit “Pointern” arbeitet. Da gibt es Prozeduren, Klassen, Module usw.  – die Syntax ist unterschiedlich, die Logik bleibt jedoch immer gleich. Würde man das auf “normale” Sprachen anwenden bedeutet das: die Vokabeln sind gleich, aber die Grammatik ist variabel.

Für mich gibt es daher nur einen wirklich wesentlichen Faktor, der die Programmiersprachen trennt: { } oder nicht. Sprachen, die ihre Codeblöcke in Klammern gruppieren oder nicht. Ich, der ich mit “Locomotive Basic” und später “Visual Basic” aufgewachsen bin, hasse alle Sprachen, die mit Klammern arbeiten. Denn diese Klammern verleiten eben nicht zu einem sauberen, übersichtlichen Programmierstil. Meiner Meinung nach bewirken sie das exakte Gegenteil. Denn ob Klammern vernünftig eingerückt sind oder ob man eine Bedingung in eine einzige Zeile schreibt, ist für das Kompilieren völlig egal.

Warum gibt es diese Klammern überhaupt? Sie dienen bei der Kompilierung eines Programms zur Abgrenzung von Anweisungen zur Übersetzung in die eigentliche Maschinensprache. Ganz abartig wird es dann noch, wenn einzelne Zeilen mit einem Semikolon abgeschlossen werden müssen. Also Java, PHP, C#, C, C++ – ich hasse das!

Unter Windows bleibe ich hartnäckig bei Visual Basic. Visual Basic kommt ohne klammern aus, verlangt aber praktisch überhaupt keinen Programmierstil. Muss man sich also mal in die Gedankenwelt eines anderen Programmierers reindenken, z.B. wenn jemand vor etlichen Jahren mal eine Access Datenbank mit seinem eigenen “VBA-Dialekt” erstellt hat, dann kann das ganz schön spaßig sein. Codefragmente über etliche Module verteilt fügen sich erst nach langem suchen und dem Aufmalen von Flowchart-ähnlichen Zusammenhängen zu einer Logik zusammen. Da wäre eine Programmiersprache von Vorteil, die keine Klammern nutzt und Konventionen hat, die alle Programmierer zu einer identischen Form der Codierung zwingt. Wenn diese Programmiersprache dann auch noch einfach und effektiv ist, im besten Fall auch noch plattformunabhängig, dann müsste sie doch eigentlich die bisher geltenden Standards ersetzen.

So eine Sprache gibt es, aber sie fristet immer noch ein Nischendasein. Sie wird zwar immer beliebter, ist aber noch keine wirklich relevante Programmiersprache. Sie heißt Python und hat ein einfaches Prinzip: der Compiler erkennt Code-Blöcke anhand von Einrückungen durch Tabulatoren.

Ein Beispiel:
So sieht ein einfacher Pseudocode-Block mit einer Bedingung in C, C++ oder Java aus:

if (bedingung == erfüllt)
{
mache etwas
}
else
{mache etwas beim Gegenteil}

Diese Anweisung kann aber auch so geschrieben werden:

if (bedingung == erfüllt) {mache etwas} else {mache etwas beim Gegenteil}

Oder so (was am ehesten den Konventionen für saubere Code-Strukturierung entspricht):

if (bedingung == erfüllt){ 
mache etwas
}
else
{
mache etwas beim Gegenteil
}

Alle drei Beispiele werden vom Compiler gleich interpretiert.

Bei Python gäbe es nur diese eine Möglichkeit der Darstellung. Eine andere würde vom Compiler nicht verstanden werden. Es gibt keine Klammern (ein Segen bei verschachtelten Schleifen) und die Konvention wird quasi vom Compiler vorgegeben:

if bedingung == erfüllt:
mache etwas
elif
:
mache etwas beim Gegenteil

Jetzt stellt sich hier die Frage, warum sich kein Paradigmenwechsel unter den Programmieren abzeichnet? Warum ist so etwas wie Python nicht schon längst Standard?

Naja, das hat zum Einen mit der Macht der Gewohnheit zu tun. Erfahrene Programmierer, die von Anfang an mit C++ oder C arbeiten, haben sich an die Nachteile längst gewöhnt. Würde man sie zu Python bekehren wollen, dann wäre das in etwa so, als würde man jemandem, der das 10-Finger-Prinzip beherrscht zu einem 2-3 Finger System zwingen wollen. Heute lernt niemand mehr die 10-Finger-Technik – sie zu Beherrschen aber als ineffektiv zu bezeichnen, wäre sicher falsch. Das ist einer der Gründe, warum sich Python bisher nicht ganz oben in der Liste der am meisten genutzten Programmiersprachen etabliert hat. Und natürlich ist es so, dass laufende, sich im produktiven Einsatz befindliche Software nicht so ohne weiteres umschreiben lässt. Zumal wenn es dafür keinen betriebswirtschaftlichen Grund gibt.

Ein weiterer Grund, den man aber nicht gelten lassen kann, ist die angebliche Ineffizienz von Sprachen wie Python oder Visual Basic gegenüber z.B. C/C++. Das ist nur dann relevant, wenn man den Verwendungszweck mit einbezieht. Schreibt man ein Anwenderprogramm z.B. für Windows, dann ist die Programmiersprache völlig unwichtig. Wichtig ist dann nur das Framework und der benutzte Compiler. Wenn Sie also ein Programm für Windows in Visual Basic.net schreiben oder in C# – es wird in der Effizienz des Programms keine Unterschiede geben.

Und Effizienz ist das Stichwort: wieviel Zeit, wieviel Geld geht uns verloren, weil Software aufgrund unterschiedlicher Konventionen ständig verändert, angepasst und neu verstanden werden muss? Welches Konzept wäre am besten für eine Vereinheitlichung geeignet? – Meiner Meinung nach das Konzept hinter Python.

Mehr zu Python finden Sie hier: https://www.python.org/

Jimdo mag Blogspot

Die größte Herausforderung bei der Umstellung auf Jimdo war meine Anforderung, den existierenden Blogspot Account in die neue Struktur zu integrieren. Und wie man sieht, hat es geklappt. Nach viel Bastelei, die ich mit diesem Artikel vielen Menschen vielleicht ersparen kann.

Die grundlegende Idee: einen IFRAME auf einer Jimdo-Seite einbetten, der die Inhalte von Blogspot anzeigt. Entfernt man im Blog alle Formatierungen und passt sie an das gewählte Jimdo Layout an, dann ist optisch gar nicht zu merken (obwohl sich das als schwieriger erwiesen hat, als es zunächst den Anschein hat). Und wofür der Aufwand, wenn Jimdo selbst doch auch eine Blog-Funktion hat?

Nun, meine Seiten sind bereits bei Google indiziert. Es gibt zahlreiche Verweise auf die Einträge. Und der Aufwand, hunderte von Einträge zu kopieren, war mir zu groß. Außerdem spricht nichts gegen Blogspot. Könnte man dort ein Shopsystem einbauen, dann hätte ich meine Seite sogar so belassen. Ein weiterer Vorteil: ich brauche keinen der internen Links in den vielen veröffentlichten Posts abzuändern. Die können alle bestehen bleiben.

Die folgenden Erläuterungen erklären, wie sie Ihren Blogspot Blog in Jimdo integrieren können. Oder – ganz generell – wie sie überhaupt einen externen Content in Jimdo einbinden können.
Also … worauf muss ich achten, wenn der IFRAME mit den Blogspot Seiten in JIMDO platziert wird?

  1. Woher weiß die Blogspot Seite, dass sie nicht wie gewöhnlich angezeigt, sondern in den IFRAME der Jimdo-Seite umgeleitet werden soll? Die Blogspot Seite wird ja quasi kastriert. Es gibt keine Menues mehr (die sind um den IFRAME herum in Jimdo), keine Navigation. Es muss also etwas in Blogspot integriert werden, was dies bewerkstelligt.
  2. Der Inhalt des IFRAMES muss irgendwie dynamisch veränderbar sein, denn es ist ja möglich, dass jemand auf die Blogspotseite gelangt, ohne direkt die Blogspot URL wie etwa pkillert.blogspot.de eingegeben zu haben. Im IFRAME muss immer das angezeigt werden, was als Referenz angegeben wurde also zum Beispiel der Verweis auf einen konkreten Artikel. Wurde nichts angegeben, dann muss einfach immer die Startseite des Blogs in den IFRAME geladen werden.

Beides lässt sich mit Javascript bewerkstelligen. Ich habe allerdings eine ganze Weile gebraucht, bis ich die Lösung zusammengebastelt hatte. Das erste Javascript platzieren Sie in einem JavaScript/HTML-Widget irgendwo auf ihrer Blogspot-Seite. Wenn Sie keinen Titel in dem Widget vergeben, dann ist das völlig unsichtbar. Passen Sie die Einträge entsprechend Ihrem Jimdo-Account an:

<script type="text/javascript">
if(top.location.href !== 'http://ihr_jimdo_account.jimdo.com/jimdo_seite/' && 
 top.location.href !== 'http://ihr_jimdo_account.jimdo.com/jimdo_seite/index.htm')
{
var the_url=''
;
the_url=window.location.href
;
location.href = "http://ihr_jimdo_account.jimdo.com/?blog_source="+the_url
;
}
</script>

Erklärung zu diesem Script: Dieses Script prüft, ob die Top-Location der URL ihre Jimdo-Seite ist. Ist sie es nicht, dann ist davon auszugehen, dass die Blogspot-Seite direkt aufgerufen wurde. Das wollen wir nicht. Wir sagen also per Javascript: leite diese Seite auf die Jimdo-Seite um, wenn Du Dich nicht in dem IFRAME der Jimdo-Seite befindest. Wichtig ist hierbei der Teil, der in “the_url” gespeichert wird. Damit geben wir die komplette URL an Jimdo weiter, also auch, ob ein direkter Beitrag aufgerufen wurde.

Auf der Jimdo-Seite platzieren Sie dann per HTML Widget einen IFRAME. Diesem IFRAME geben Sie die ID “blog_source”. Damit steuern wir den IFRAME in dem nächsten Schritt an.

<p><iframe id=„blog_source“src=„http://ihre_blogspot_id.blogspot.de“name=„blog_source“width=„880“ 
height=„800“ frameborder=„0“></iframe></p>

Passen Sie die Einstellungen entsprechend Ihrem Blog an. Ebenso die Größe des IFRAMES.
Unter diesem IFRAME platzieren Sie ein weiteres HTML Widget auf ihrer Jimdo Seite. In dieses Widget packen Sie das nun folgende Javascript:

<script type="text/javascript">

var getUrlParameter = function getUrlParameter(sParam)
{
var sPageURL = decodeURIComponent(window.location.search.substring(1
)),
sURLVariables = sPageURL.split('&'), sParameterName,i
;
for (i = 0; i < sURLVariables.length; i++)
{
sParameterName = sURLVariables[i].split('='
);
if (sParameterName[0] === sParam)
{
return sParameterName[1] === undefined ? true : sParameterName[1]
;
}
}
};
var the_source=''
;
var the_frame=''
;
the_source = getUrlParameter('blog_source');

the_frame
= document.getElementById('blog_source'
);
if(typeof the_source == 'undefined'){the_source='http://ihre_blogspot_id.blogspot.de'
;}
the_frame.src = the_source
;

</script>

Erklärung zu diesem zweiten Script: Der obere Teil zerlegt das, was wir in “the_url” an die Jimdo-Seite übertragen haben. Es erkennt, dass beim Aufruf der Seite etwas über die Variable “blog_source” übertragen wurde. Das ist die URL, die in den IFRAME geladen werden soll.

Der untere Teil des Javascripts bewirkt genau diesen Ladevorgang. Dieser Teil checkt außerdem, ob dieser Parameter “blog_source” gar nicht definiert wurde, wenn z.B. jemand nur die Jimdo URL angegeben hat und gar nicht von Blogspot weitergeleitet wurde. Für diesen Fall wird “the_source” mit der gewöhnlichen Blogspot-Adresse gefüttert. Es wird also in jedem Fall der richtige Inhalt in den IFRAME geladen. Sie müssen nur “ihre_blogspot_id” mit der korrekten Bezeichnung ersetzen.

Das war´s …!

Abschließend noch ein paar Tipps, wie sie das Layout Ihrer Blogspot-Seite entschlacken.
Mir war der Abstand zwischen dem BlogTitel als Header und den ersten Einträgen viel zu groß. Diesen Abstand werden sie los, wenn sie Blogspot in den “Einstellungen –> Vorlage –> Anpassen –> Erweitert –> CSS hinzufügen” folgendes eingeben:

.header {padding-bottom: 0px; padding-top: 0px; height: 70px;}


Die 70px können natürlich variiert werden.

Außerdem kann an derselben Stelle folgender Code verwendet werden. Er bewirkt das alle Randabstände entfernt werden. Die braucht man in einem IFRAME eh nicht:

.content-inner {padding: 0px; margin-top: -40px !important;}

Coming soon

CodeIsPoetry_LogoNeuWhiteVor einigen Wochen hatte ich von den VSTO Tools für Visual Studio und der Firmenpolitik von Microsoft und deren Entwicklerwerkzeuge berichtet. Als VBA Junkie, der mit Erweiterungen von Microsoft Office jeden Tag zu tun hat, war diese Freigabe der passenden Tools etwas, dass in jeder Hinsicht neue Horizonte eröffnet hat. Ich baue mir jetzt meine eigenen Office Erweiterungen. Die Verschmelzung von Ambition und Erfahrung. Code is Poetry.

Das erste Ergebnis ist jetzt kurz vor der Fertigstellung. Ich habe es “AutorTools” genannt und es ist eine bahnbrechende Erweiterung von Microsoft Word. Neben einem ePub Export, einem Export nach HTML on-the-fly (einfach über die Zwischenablage) gibt es auch einen sogenannten RSS Distiller, der aus Blog-Einträgen ein Word Dokument macht. Es gibt eine Datenbank im Hintergrund, die die Arbeitsschritte eines Users dokumentiert, eine Zitatsammlung, eine Normseitenformatierung, einen Blindtextgenerator und einen Export der Dokumentstruktur als MindMap. Selbst ein Export ins Schriftsatzsystem LaTeX oder als OPML Struktur ist möglich. Das mag sich für viele exotisch anhören, aber ich bin mir sicher, es gibt viele Menschen, die auf so ein Tool gewartet haben.

WINWORD_2016-07-06_19-53-32

Neben der Implementierung der letzten fehlenden Funktionen arbeite ich derzeit an der Dokumentation dieses Tools und an ersten Screencast Videos, die aus diesen abstrakten Beschreibungen die praktischen Anwendungen darstellen. Das geht immer nur Schritt für Schritt. Daher gibt es im Moment auch nur spärlichen literarischen Fortschritt.

Mit einer ersten “Beta”-Version rechne ich ab August – dann gebe ich dieses Tool an einige Vielschreiber, die im Moment von Ihrem Glück noch gar nichts wissen. “AutorTools” wird code-is-poetry.de bereichern, eine Seite auf der ich derzeit nur einen kaum wahrgenommenen Rapid-Weaver Stack zum Kauf anbiete. War aber eh nur eine Spielerei.

VSTO

Es ist locker 25 Jahre her, da habe ich das erste Mal Visual Basic in Aktion gesehen. Jemand aus der “Teestube” – ein Jugendtreff der Evangelischen Kirche, den ich damals besucht habe – hat mir Visual Basic 3.0 gezeigt. Das hat mich direkt beeindruckt, weil das Prinzip sehr einfach war. Einfach ein Formular zusammenbauen und dann Ereignisse definieren. Kommt man aus den 80er Jahren und hat an einem Schneider-Computer einfache BASIC Programme gebaut, muss man sich erst an die Objektorientierung gewöhnen. Ein Programm läuft eben nicht linear ab sondern interaktiv, je nachdem was der User macht. Das war damals unter Windows 3.1 – hier ein Video für Nostalgiker.

Jetzt, mehr als zwei Jahrzehnte später würde ich sagen, dass mein Interesse von damals, der Kauf eines ersten großen “Kompendiums” und das Durcharbeiten desselben sich gelohnt haben. Das, was in meinem beruflichen Alltag heute wirklich wichtig ist, ist genau dieses technische Verständnis. Microsoft hat dann bei Office 97 einen genialen Schachzug getan: man hat Visual Basic in Microsoft Office integriert. Das nannte sich dann VBA, “Visual Basic For Applications”. Mit VBA arbeite ich jeden Tag.

Visual Basic hat sich dann stetig weiterentwickelt. Mit dem “.net” Framework wurden auch weitere Sprachen integriert- Statt mit Visual Basic konnte auch mit dem klassischen C++ oder mit C# programmiert werden. Visual Basic ist aber nach wie vor mein Favorit, denn ich hasse alle Programmiersprachen, bei denen man sich mehr auf die verschachtelten Klammerpaare, als auf die eigentlichen Prozeduren konzentrieren muss.

Apple hat auf seinen Rechnern die Tools zum Programmieren immer kostenfrei gelassen. Für Xcode und die mit diesem Tool entwickelten Anwendungen, ist prinzipiell keine Lizenzierung von Xcode notwendig. Das war bei “.net” lange nicht so. Lizenzen für VB oder Visual Studio waren extrem teuer. Diese Politik hat Microsoft in etwa zur Mitte der 00er Jahr geändert. Neben den kommerziellen Lizenzen standen die sogenannten “Express Editionen” bereit – diese erlaubten eine kostenfreie Programmierung für Opensource Projekte und den privaten Gebrauch. Aber auch das wurde mittlerweile verworfen. Es gibt seit 2012 eine sogenannte “Community Edition”, die mit der kommerziellen Version von Visual Studio identisch ist. Man darf jetzt auch kommerzielle Produkte damit entwerfen. Einzige Einschränkung: arbeitet der Entwickler in einem Unternehmen mit mehr als 1 Millionen EUR Jahresumsatz, dann erst werden Lizenzgebühren fällig.

Aber auch hier gab es noch eine Einschränkung: die Entwicklung sogenannter VSTO Elemente, also Erweiterungen von Microsoft Office, die über die VBA Elemente hinausgehen, war mit der Community Edition nicht möglich. Nun – auch das hat sich jetzt geändert. Seit Anfang diesen Jahres lassen sich VSTO Projekte mit der kostenfreien Community Edition erstellen:

2016-04-22_19-44-54

Die Möglichkeiten, die sich für jemanden, der sich mit Visual Basic auskennt und die Tiefen von Microsoft Office in VBA ergründet hat, sich unbeschreiblich.

Einen kleinen Vorgeschmack auf das, was möglich ist, zeige ich hier. Dieser Screenshot zeigt eine Erweiterung für Microsoft Word, die ich derzeit zusammenbaue. Man sieht oben einen eigenen “Ribbon” für dieses AddIn und rechts eine “Taskpane” mit dem Titel “Dokumentstruktur”, also ein eigenes Panel, an dem sich diverse Einstellungen machen lassen. Ziel dieses Tools ist die Pflege einer integrierten Datenbank, zu der sich zu jedem Kapitel eines längeren Textes, Statusangaben pflegen lassen. Alle literarischen Projekte lassen sich damit verwalten und in ihrer Entstehung dokumentieren.

2016-04-22_19-43-26

Zunächst einmal baue ich dieses Tool nur für mich selbst. Aber es dürfte nichts dagegen sprechen, dieses Projekt mehr und mehr auszubauen. Es ist wirklich faszinierend zu sehen, wie sich persönliche Erfahrung, Ideen und neue Möglichkeiten zu etwas Greifbarem zusammensetzen lassen. Teilweise lassen sich mit IntelliSense, das ist das automatische Antizipieren des logisch folgenden Quellcodes, Lösungen intuitiv erstellen, ohne dass man noch großartig in eine Dokumentation schauen muss. Daher hat dieser Blog mit “Visual Studio / Programmieren” einen neue Kategorie bekommen.

Link zum Download der deutschen Fassung der Community Edition von Visual Studio

Link zum Download der VSTO Erweiterung für Visual Studio