Archiv der Kategorie: Visual Studio / Programmieren

Asychrones Nerdfutter

Ich weiß ja, dass einige Nutzer über Suchbegriffe zu meiner Seite finden, die sehr IT-lastig sind. Meine kleinen Notizen und Code-Beispiele sollen Menschen helfen, deren Lage ähnlich die der meinen ist. Ich suche oft nach Lösungen zu bestimmten Problemen und finde sie oft nicht – weil ich dann vielleicht doch zu praktisch veranlagt bin und mir die fehlende Theorie über konkrete Beispiele aneigne.

Nachfolgender Code-Schnipsel ist das Ergebnis einer langen Problemsuche, bei der ich sogar die Netzwerkfachleute bei meinem Kunden aufgescheucht habe. Ich hatte wirklich geglaubt, dass der Fehler dort irgendwie im Netzwerk zu finden ist – aber das war, Stand heute, wohl doch nicht der Fall. Lösung des Problems war eine Kleinigkeit – aber die muß man erstmal wissen.

Wenn man eine Web-Applikation baut und diese mit einer Datenbank verbindet, dann findet zwischen dem Client und dem Server eine besondere Interaktion statt. Da auf der Clientseite niemals Datenbankanweisungen als Klartext sichtbar sein dürfen – jeder Browser kann den Quelltext einer jeden Seite anzeigen – müssen die serverseitigen Anweisungen auf dem Server erfolgen. Die Programmiersprache hierfür ist PHP.

Aber der Nutzer der Seite interagiert mit der Applikation auf der Clientseite. In dem er z.B. ein Passwort eingibt. Das erfolgt dann vermutlich über Javascript und mit einem der passenden Frameworks. D.h. diese Eingabe muss auf dem Server landen, also vom Client (Javascript) an den Server (PHP) übergeben werden. Diesen Mechansimus nennt man AJAX (Asynchronous JavaScript and XML) . Das A steht also für asynchron, d.h. die Auswertung auf dem Server ist dem Input nachgelagert und muss erst ein Feedback zurückgeben.

Ich bin da in eine böse Falle getappt, denn es gibt einen großen Unterschied bei diesem Feedback des Servers zwischen zwei Stati: complete und success. Das war mir nicht bekannt. Und wer oberflächlich nach Lösungen zu ähnlichen Problemen sucht, wird diesen Zusammenhang vielleicht auch erst viel zu spät begreifen. Vermutlich liegt das daran, dass AJAX Requests eher selten für das Erzeugen einer Datei verwendet werden.

Der AJAX Request gibt das Feedback success wenn er erfolgreich abgearbeitet wurde. Das Feedback complete wird ausgelöst, wenn das Ergebnis des Requests vorliegt und ist unabhängig von success (kann also auch bei einem Fehler ausgelöst sein, wenn ein Ergebnis nur teilweise vorliegt).

Konkretes Beispiel: Ich wollte anhand von zwei Clientseitigen Parametern (z.B. zwei Userangaben) das Erzeugen einer Datei auf dem Server auslösen und diese Datei dann als Input in meiner Applikation nutzen. Da ich bisher nur das Feedback success kannte und mich mit complete nie beschäftigt habe, fand diese Einbindung immer bei dem success Feedback statt. Das ist aber falsch, denn success bedeutet, die Dateierzeugung wurde erfolgreich initiiert (damit ist der AJAX Request erfolgreich abgeschlossen). Fertig ist der Request aber erst mit der vollständigen Datei und dem complete Feedback.

Ich habe also die ganze Zeit herumgerätselt, warum ich meine Datei manchmal nicht in mein Programm einbinden konnte. Da wir hier im Milisekundenbereich sind kam es ab und an vor, dass die Datei mit dem success Feedback schon vorlag und alles war OK – manchmal aber auch nicht. Die Einbindung muss also mit dem complete Feedback des AJAX Requests verbunden sein – nicht mit success. So erklärt sich der zunächst naheliegende Gedanke, dass im Netzwerk ein Problem vorliegt, welches die Datei blockiert. Naheliegend, aber falsch.

So sieht das konkret aus:

Dumm, wenn einem Nerd der Unterschied zwischen success und complete nicht geläufig ist …

Linux has taken over

Ich hatte so meine Phasen … mit Windows 3.1. Ende der 80er Jahre angefangen, dann eine erste Phase mit Linux gegen Ende der 90er Jahre, dann viele Jahre MacOSX, dann nochmal Linux und jetzt wieder – auch beruflich bedingt – nutze ich Microsoft Windows. Aber man schaut sich immer wieder die Alternativen an, was dank Virtualisierung zum Ausprobieren sehr einfach ist. Eines sticht jedoch heraus – Linux ist überall. Sogar in Windows.

Ich bin mit meiner Einschätzung nicht allein, aber für manche wirkt es wie dieser Aprilscherz, der vor einigen Jahren mal veröffentlicht wurde und denen viele gar nicht auf den Leim gegangen sind. Viele haben nach diesem Artikel an einem 1. April eine sachliche Diskussion zu dem Thema angefangen. Weil es tatsächlich nicht abwegig ist.

KDE Anwendungen unter Windows 10

Meiner Meinung nach ist es nur noch eine Frage der Zeit, bis Microsoft den eigenen Kernel zugunsten eines Linux Kernels aufgeben wird. Was sich mit dem Linux-Subsystem für Windows schon angekündigt hat und sich mit der Plattform-unabhängigen Powershell fortsetzt, ist heute schon im Microsoft Store unter Windows 10 zu sehen: dank des Linux Subsystems laufen Linux Anwendungen vorzüglich unter Windows. Populäres Beispiel ist die Anwendung „Okular„, mit der sich unter anderem PDFs bearbeiten lassen. „Okular“ ist normalerweise Teil des KDE Desktops.

Dokumentbetrachter OKULAR  unter Windows 10

OKULAR – Der Dokumentbetrachter und PDF Editor des KDE Desktop lässt sich über den Microsoft Store problemlos für Windows 10 anwenden

Weitere Linux-Anwendungen unter Windows 10

Ein anderes Beispiel ist „Kate„, der KDE Editor für Programmierarbeiten aller Art, ebenfalls unter KDE. Diese Anwendungen laufen flüssig unter Windows 10, da sie auf dem QT-Framework basieren. Dieses Framework erlaubt die Entwicklung einer Anwendung auf einer beliebigen Plattform – das Endergebnis läuft auf allen bekannten Betriebssystemen. Das spart Entwicklungszeit und -kosten.

KDE Editor KATE unter WIndows 10

Der KDE Editor KATE lässt sich ebenfalls über den Microsoft Store für Windows 10 verwenden

 

Andere Beispiele sind der LaTex-Editor „Kile„, das Matheprogramm „LabPlot“ oder Visualisierungstool „Filelight„. Auch einige Anwendungen des anderen großen Desktops unter Linux („Gnome“) sind unter Windows zu Hause. Das bekannteste Programm ist sicher die Bildbearbeitung „Gimp“. Aber auch die Excel-Alternative „Gnumeric“ oder die Textverarbeitung „Abiword“ gibt es als Windows Versionen.

Vieles ist aber auch einfach nur Politik. Exemplarisch für die Notwendigkeit, den Unterbau von sämtlichen Computersystemen zu vereinheitlichen, ist das Zusammenspiel zwischen Desktop Programmen und mobilen Programmen. Das bedeutet derzeit noch, das der Quellcode für die Plattformen separat kompiliert werden muss – Mehrarbeit und zusätzlicher Support wird dadurch notwendig. Das QT-Framework schafft hier Abhilfe. QT wird von Trolltech entwickelt. Trolltech gehörte eine zeitlang zu NOKIA. NOKIA gehört zu Microsoft … den Rest kann man sich denken. Ebenso den Weg in die Nahe Zukunft und die Intention von Microsoft. Auch wenn ich diese Zusammenhänge jetzt sehr vereinfacht und verkürzt dargestellt habe.

Linux has taken over …

Ich kann das aus meiner eigenen beruflichen Umgebung bestätigen. Vor wenigen Jahren, waren Linux Server noch kein Thema. Dann aber kamen viele Unternehmen auf den Trichter, nicht die Software, sondern ihren Support zu verkaufen (Fedora, Canonical) und plötzlich war Linux das einzige Server-Betriebssystem. Android nutzt einen Linux-Kernel, MacOS basiert auf einem FreeBSD Unterbau mit Unix-kompatiblen Kernel. Und Windows hat ein Linux Subsystem, dass immer besser mit Windows Software interagiert. Microsoft muss nur noch Betonklötze wie die Registry und DirectX loswerden. Dann wird auch hier Linux dominieren. Windows in der jetzigen Form muss für Microsoft wie ein Klotz am Bein sein.

Linus Torvalds, der Initiator von Linux erklärt in diesem kleinen Ausschnitt, warum seiner Meinung nach LINUX nicht überall auf Desktop-Rechner genutzt wird. Die Antwort ist relativ simpel und einleuchtend: 99% der Nutzer haben weder Zeit noch Interesse daran, ein Betriebssystem zu installieren. LINUX auf Desktop Rechner vorinstalliert – solche Versuche hat es gegeben, solche Rechner gibt es mit grandioser Ausstattung. Es hat sich schlicht niemals durchgesetzt.

Fazit

Mit Windows ohne mobile Version und der Notwendigkeit, Verbindungen zu Android und IOS permanent separat zu unterhalten – dazu noch der eigene Windows Unterbau – wird Microsoft nicht weit kommen. Die Systeme werden sich langfristig angleichen müssen. Das bedeutet aber natürlich nicht das Ende des Softwaregiganten – im Gegenteil: schon jetzt verdient Microsoft richtig Kohle mit Azure und Office, das zurecht die führende Bürosoftware ist. Das wird so bleiben. Nur weil das Betriebssystem Open Source wäre, bedeutet das nicht das Ende der klassischen proprietären Software, Werden in Zukunft immer mehr Spiele unter Verzicht auf DirectX produziert, immer mehr Software mit plattformunabhängigen Frameworks, dann ist meiner Meinung nach klar, wohin die Reise geht.

Automatischer Browser Reload – mit Visual Studio Code

Einer der wichtigsten und flexibelsten (und auch kostenfreien) Editoren für Entwickler ist sicher Visual Studio Code. Auf allen Plattformen verfügbar – man muss sich nur ein wenig an das Konzept gewöhnen.

Der von mir beschriebene sehr hilfreiche automatische Browser Reload aus diesem Post, kann auch mit Visual Studio Code ausgelöst werden. Es ging um dieses Powershell Script, das wir einfach mal „BrowserRefresh.ps1“ nennen:

$wshell=New-Object -ComObject wscript.shell;
$wshell.AppActivate('Firefox Developer Edition'); # Aktiviere Firefox Develope Edition 
$wshell.SendKeys('^{F5}'); # Refresh The Browser
Write-Host "Firefox aktualisiert"

Um es in Visual Studio Code aufzurufen, muss ein Task angelegt werden (task.json) – wie das geht, erfährt man in der Dokumentation zu VS Code. In der Regel kann die Datei über F1 und dann Task -> Aufgabe konfigurieren angelegt werden, falls noch nicht vorhanden.

Der Eintrag sieht dann so aus:

Task in VS Code für Browser Refresh

"reveal" : "never"

bewirkt übrigens, dass das Ergebnis des Scripts nicht im internen Terminal von VS Code angezeigt wird (sehr nervig).

Dann muss man das Script nur noch über Tastenkombination (bei mir STRG + WIN + R) aufrufen (auch wieder F1 -> Tastenkombinationen JSON aufrufen):

Key für VS Code Browser Refresh

Das wollte ich zu dem ursprünglichen Post noch ergänzen – auch in VS Code ist das Aufrufen solcher nützlichen Scripts problemlos möglich.

 

 

Automatischer Browser Reload

Welcher Webentwickler kennt dieses Problem nicht?  – Man ändert einzelne Komponenten auf einer Seite und möchte das Ergebnis dann im Browser sehen. Also öffnet man den Browser, macht einen Reload – in der Regel mit zu löschendem Cache, falls sich auch CSS oder Javascript Files geändert haben – und schaut sich das Ergebnis an. Der Browser läuft bereits auf einem eigenen Monitor, aber das Refreshing ist lästig.

Lösungen wie „Live.js“ oder „LiveReload“ funktionieren nicht (oder ich war zu blöd für die Einrichtung). Was also tun? Auch hier hilft wieder Powershell. Das nachfolgende Script sendet an einen geöffneten Firefox (Developer Edition) SHIFT + F5 – der Browserinhalt wird neu geladen.

$wshell=New-Object -ComObject wscript.shell;
$wshell.AppActivate('Firefox Developer Edition'); # Aktiviere Firefox Develope Edition 
$wshell.SendKeys('^{F5}'); # Refresh The Browser
Write-Host "Firefox aktualisiert"

Was soll jetzt aber der Vorteil sein? Nun, sicher ist es kein Vorteil, ein Powershell-Script aufzurufen, statt in den Browser zu wechseln. Der Aufwand wäre sogar größer. Aber man kann dieses Script in seine Arbeitsumgebung als externes Tool einbauen und mit einem Shortcut versehen. UltraEdit oder die IDEs von JetBrains bieten dafür einfache Schnittstellen. Ich schreibe meinen Code mit PHPStorm und da sieht das dann so aus:Browser Reload mit phpStorm

Program: powershell.exe

Arguments: Der Pfad zu dem oben beschriebenen PowershellScript

Working Directory : Der Pfad zur powershell.exe, falls dieser nicht bereits in der PATH Variable des Systems integriert ist.

Man kann dieses Script natürlich auch als Shortcut auf einem Desktop abrufen, ohne eine Umgebung zu nutzen. Nachteil dabei ist, dass sie den Konsolenoutput nicht umleiten oder unterdrücken können – es öffnet sich immer ein Powershell-Terminal.

Die Arbeitserleichterung liegt darin, dieses Script mit einem Shortcut zu versehen oder – vielleicht sogar noch besser – über ein Makro in der Entwicklungsumgebung mit dem Speichervorgang zu verknüpfen. Jedes Mal, wenn eine Seite oder eine Datei gespeichert wird, wird auch der Browser neu geladen. Noch besser: natürlich können Sie das Script erweitern und gleich mehrere verschiedene Browser refreshen. Das kann wichtig sein, wenn Sie Anwendungen entwickeln, die zuverlässig in mehreren Browsern laufen sollen.