Node und Python - Heute CLI
Erstellen einer CLI Applikation
November 15, 2020 - Lesezeit: 9 Minuten
Es ist toll, dass man sobald man die entsprchenden Umgebungen installiert hat, man sowohl in Python als auch in Node.js einfach so kleine und große Skripte ausführen kann. Gerade bei Linux ist das durch die Paketmanager sehr einfach gestaltet. Und da viele andere Installationen ja teilweise schon die Hälfte der benötigten Pakete mitbringen, muss auch meistens nicht mehr viel installiert werden.
Wie ist es aber jetzt, wenn ich ein kleines Skript einem Kunden zukommen lassen will ohne dem Kunden eine komplette installation zuzumuten. Nicht jeder möchte ein komplettes Enticklungsystem auf seinem Rechner haben oder als Admin auch noch diese Installationen supporten. Im schlimmsten Fall müssen gegebenenfalls auch noch zusätzliche Installationen druchgeführt werden, die nicht ganz so unkompliziert sind.
Es gibt in Python wie auch in Node.js die Möglichkeit die Skripte in eine CLI Applikation zu verpacken und somit unter Windows, Linux und macOS die Möglichkeit zu schaffen ohne komplizierte Installationen das Ausführen von Skripten zu ermöglichen. Hierbei konnen kleine 2 Zeiler verwendet werden als auch ganze, vollwertige Programme erstellt und weitergegeben werden.
Zwischen Node und Python gibt es bei kleinen Anwendungen, wie z.B. Auflisten und Vergelichen eines Verzichnisinhaltes kaum einen Unterschied in der Implementierung. Hierbei entscheidet die persönliche Preferenz und der persönliche Entwicklungstand des Entwicklers wohl am meisten über die Wahl der Umgebung. Aber es gibt noch weitere Fakten, die in die Überlegung mit einfließen sollten. Um mir hier einen Überblick zu verschaffen und weitere objektive Kriterien für eine Entschidung zu sammeln, habe ich ein kleines Testprojekt sowohl in Python als auch in Node erstellt, diese in eine CLI Applikation gepackt und verglichen. Eins vorweg, es gibt keinen Sieger, da auch hier die Entschidung immer vom Anwendungsfall abhängig ist. Mein Test kann hier nur grob in eine Richtung zeigen und vielleicht im Vorfeld Impulse liefern.
Der Test
Um die komplexität der Aufgabe nicht unnötig zu steigern und eventuell das Ergebnis unnötig zu verzerren habe ich absichtlich ein sehr einfaches Problem genommen.
| Node | Python |
|
const readline = require('readline');
console.log("Hello World");
const rl = readline.createInterface({
input: process.stdin,
output: process.stdout
});
rl.question('Press Enter to continue...', (answer) => {
rl.close();
});
|
print("Hello, World!")
input("Press Enter to continue...")
|
Die Auswertung
Wie zu erwarten lies sich das Problem mit beiden Umgebungen lösen. In keiner der Umgebungen habe ich unnötige Klimzüge durchführen müssen um die Aufgabe zu lösen. Es haben sich allerdings ein paar Unterschiede gezeigt, die ich hier kurz besprechen möchte:
Die Dateigröße
Hier zeigt sich ein großer unterschied, der beachtung finden sollte. Die erstellte Datei ist in Node um einvielfaches großer als das Gegenstück in Python. Dieser Unterschied sollte im Hinblick auf ein Deploy beachtung finden. Klar Speicherplatz kostet nix und ein paar MB hat man immer frei. Aber Bandbreite ist immer noch ein Thema. Es kann also durchaus Sinn machen, je nach Projektumgebung zu prüfen ob kleinere Dateien hilfreicher sind.
Startgeschwindigkeit
Wenn die Applikation gestartet wird ist es in Python so, dass der Quelltest kompiliert wird. Das dauert einen kleinen Moment. Die Nodeapplikation hingegen interpretiert auch beim Start ganz normal. Es ist anzunehmen, dass die Ausführgeschwindigkeit eines Pythonprogramms damit deutlich performanter ausfällt als bei Node. Im vorliegenden einfache Fall ist es allerdings so, dass die Nodeapplikation schon wieder beendet ist, da ist Python noch nicht einmal richtig gestartet. Auch hier gilt wieder, dass es vom Anwendungfall abhängig ist ob dieses Verhalten erwünscht ist.
Portabilität
Während sich Nodeapplikationen auf einem Windowssystem auch für Linux und macOS erstellen lassen ist dies bei Python leider nicht möglich. Obwohl beide Systeme hier ein vorgefertigtes Kompilat runterladen und den eigenen Quelltest einfach núr einbetten. Wenn also Python auch für Linux laufen soll, muss man das Ganze auch unter Linux erstellen. Das ist, wenn man das Programm weiterreichen möchte und nicht dasselbe Betriebssytem wie das Ziel hat, etwas umständlich. Wenn man dann möglichst viele Ziele abdecken möchte ist das dann eher ein bisschen hinderlich.
Fazit
Wie schon erwähnt, so richtig sticht hier keine der Umgebungen hervor. Beide haben Stärken und Schwächen, auch wenn beide einfache Aufgaben erfüllen können. Trotzdem sollten die hier vorgestellten Punkte nicht außer Acht gelassen werden, da diese einem das Leben unter Umständen schwermachen können.
Mit Node.js gegen den Rest der Welt - Heute Webserver
Webserver in Node.js
November 8, 2020 - Lesezeit: 26 Minuten
Mit Node.js lässt sich JavaScript in einer Konsolenumgebung starten, ohne dass dazu eín Browser notwendig wäre. Das eröffnet ganz neue Möglichkeiten, da so JavaScript aus der Sandbox des Browsers herauskommt und die bisherigen Beschränkungen, wie Dateizugriff und betriebssytemspezifische Abfragen nun entweder direkt möglich sind oder unkomplitziert implementiert werden können. Node.js kommt mit einem Paketverwaltungssytem auf den Rechner. Dieser Manager liefert Zugriff auf eine große Zahl von Paketen, in denen viele Funktionen in Node.js bereits realisiert sind oder Node.js durch z.B. Platform invokes sinnvoll erweitert.
Diese Pakete wiederum können Verweise auf andere Pakete haben, falls sie diese benutzen. Ganz ähnlich zu dem Paketmanager von Debian. Wenn z.B. ein FTP Paket geladen wird, wird im Hintergrund das Paket für den Dateizugriff ebenfalls installiert. Mithilfe einer kleinen Konfigurationsdatei und einem ordnerbasierten Paketmanagement, können verschiedene Versionen auf einem Rechner nebeneinander installiert werden. Dies ermöglicht verschiedene Projekte in verschiedenen Versionständen nebeneinander zu betreiben. Weiterhin ist der Anspruch, auf jedem System lauffähig zu sein und das Prinzip "Write once, run anywhere" passend umzusetzen. Intressant wird es immer dann, wenn man versucht betriebssystemspezifische Implementierungen zu nutzen.
Da Node.js unkompliziert sowohl unter Windows als auch unter Linux verwendet werden kann, ist es naheligend, als JavaScriptentwickler einen Blick zu wagen. Man kann im Gegensatz zu anderen Systemen den Know How Aufbau für eine Skriptsprache minimal halten und schnell Ergebnisse erzielen. Um mit der ganzen Umgebung etwas warm zu werden und weil ich für die Entwicklung einen kleinen Webserver benötigt habe, hab ich das Ganze mal mit einem Nodeskript umgesetzt. Natürlich ist dieser Server nicht vergleichbar mit der voll ausgestatteten Variante eines Symolo Servers, aber für kleine Zwecke ist auch ein solches Skript durchaus hilfreich.
Die Funktion des Skriptes umfasst lediglich das Starten eines Webservers, der eine begrenze Anzahl von Dateien aus einem Ordner und dessen Unterordnern laden kann. Dieses Skript ist nicht für Produktivumgebungen gedacht. So, genug chitchat, los gehts:
Ein minimalistischer Server auf nur 50 Zeilen. Natürlich wird hier Gebrauch von einigen Paketen gemacht, die viele der Grundarbeiten bereits erledigen. Trotzdem kann sich das Ergebnis sehen lassen. Dieses Skript, unter und für Windows entwickelt, ist auch aus dem Stand unter Linux und MacOS lauffähig. Da hier Dateizugriffe verwendet werden, ist dieses Skript leider nicht für den direkten Einsatz im Browser verwendbar. Dafür beim nächsten Mal ein Beispiel.
linux shell skript immer als administrator ausführen
hilfreiches skripttool
November 3, 2020 - Lesezeit: 78 Minuten
Problemstellung:
Wir haben ein Serverskript das wir immer als Administrator ausführen.
Dieses Skript führt ein Serverupdate bei uns durch.
Wenn das Skript nicht als Administrator ausgeführt, wird führt dies zu einem unvollständigen Update, da für bestimmte Dateien die Berechtigung fehlt.
Daraus resultiert unter Umständen eine unvollständige Installation.
Um eine Fehlerquelle auszuschließen haben wir nach einer Möglichkeit gesucht wie sichergestellt werden kann, dass das Skript immer als Administrator ausgeführt wird.
Lösung:
$EUID stellt die Identität des angemeldeten Users dar der für die Rechteprüfung genutzt wird hierbei hat er root Nutzer die 0.
-ne ist der Operator für ungleich
Das Skript prüft ob es sich bei dem angemeldeten Benutzer um den Root handelt.
Ist das nicht der Fall: Ruft sich das Skript erneut mit Rootrechten auf.
Testen - Wichtiger als man vielleicht denkt
Oktober 20, 2020 - Lesezeit: ~1 Minute
Heute möchte ich kurz über einen Teil der Softwareentwicklung sprechen, der oftmals zu kurz kommt, obwohl es der wichtigste überhaupt ist.
Das TESTEN
Die Entwicklung und Programmierung kann noch so schnell gegangen sein und die allerneusten Methoden verwenden, wenn nichts funktioniert, bringt es niemandem etwas.
Eine ungetestete Software ist so wie ein Auto ohne Tüv. Kann laufen, muss es aber nicht.
Also haben Sie ein Augenmerk darauf, dass sie fähige Mitarbeiter die Software inhouse testen lassen. Ein Entwickler kann zwar dafür Sorge tragen, dass die Software läuft, aber ob sie so läuft wie Sie das wollen und benötigen, dass kann er nicht unbedingt wissen.