Archiv der Kategorie: Tutorial

Der Unterschied zwischen einem FTP Server und GIT

Vielen wird es wohl ähnlich ergangen sein. Wenn man als Neuling anfängt ein paar Websites zu bearbeiten, wird man relativ schnell mit FTP Bekanntschaft machen. Das File Transfer Protokoll ermöglicht es, einfach Dateien vom eigenen Rechner auf einen Server hochzuladen. FTP ist einfach zu bedienen, und funktioniert auch, solange man alleine an einem Projekt arbeitet. Wenn aber dieser Neuling nun in eine Gruppe kommt, wo mehrere Leute gleichzeitig an einem Code arbeiten, ist meist Schluss mit FTP. Dann muss man sich mit so kompliziertem Zeug wie GIT anfreunden.

Viele Neulinge stänkern dann erst mal. „Aber mit FTP hat es doch bei mir auch wunderbar funktioniert. Weshalb nun plötzlich so ein kompliziertes Tool?“ GIT ist tatsächlich ein komplizierteres Tool als FTP und der Unterschied ist erst mal nicht so offensichtlich. Den will ich Euch heute erklären.

Die Grenzen von FTP

Wenn man vom eigenen Rechner via FTP auf einen Webserver eine Datei oder mehrere hochlädt, wird die alte Datei einfach überschrieben. Klingt erst mal logisch, ist ja auf dem lokalen Rechner genau so. Doch wenn mehrere Leute an einer Website arbeiten kann das zu einem heillosen durcheinander führen. Ein Beispiel: Entwickler eins macht in einer Datei eine Änderung… informiert aber nicht gleich das Team. Er lädt die Datei auf den Server hoch. Dann kommt Entwickler zwei und will auch ein paar Änderungen machen. Nur hat er noch eine Datei ohne die Änderungen von Entwickler eins. Wenn nun Entwickler zwei seine Änderungen auf den Server hochlädt, sind die Änderungen von Entwickler eins einfach überschrieben. Dieses Problem schlägt schon bei ganz kleinen Teams zu, weshalb eigentlich alle Entwicklungsteams auf eine Versionskontrolle (GIT ist eine von vielen) setzen.

GIT speichert Change sets, keine komplette Dateien

Der eigentliche Unterschied zwischen einem FTP Server und GIT liegt im Hintergrund verborgen. Im Unterschied zu einem FTP Server speichert GIT nämlich die Änderungen in sog. Change sets. Das sieht dann ungefähr so aus:

Initial commit	Version 1
Changeset 1	Version 2
Changeset 2	Version 3
Changeset 3	Version 4

Stark vereinfachte Darstellung einer Versionskontrolle

Wenn man also etas via GIT auf ein Repository (wie man die Ablage nennt) hochlädt, dann erstellt GIT erst auf dem eigenen Rechner ein Change set. Dieses wird dann an den Server übermittelt. Die Change Sets funktionieren Zeilenbasiert. An folgendem Screenshot kann man das sehr gut erkennen:

Ein Change Set auf GitHube — Darstellung eines Change Sets auf GitHub.com Hier zu sehen Code von Apache Openmeetings

Die Dateien die man also in Git erhält, sind immer aus vielen einzelnen Change sets zusammengezimmert worden.

Dieses System eröffnet ganz andere Möglichkeiten. Zum einen können so Fehler einfach zurückgespult werden. Zum anderen ist es möglich, Änderungen eines anderen Entwicklers in den eigenen Quellcode einzubauen auch wenn man selbst schon Änderungen gemacht hat.

GIT ist zwar komplizierter zu bedienen, vereinfacht aber letztendlich vieles. Selbst das kleine Einmann Projekt profitiert davon. Insbesondere wenn man was einbauen wollte, und erst zu spät bemerkt, dass es nicht funktioniert. Mit GIT kann man die Änderung einfach zurückrollen und hat somit eine laufende Website.

Sich mit der Kommandozeile anfreunden

1 Antwort

Als Programmieranfänger stösst man in Tutorials oft auf die Aufforderung die Command Line zu öffnen und Befehl xy einzugeben. Als ich noch in den Anfängen steckte, öffnete ich dann jeweils die Kommando Zeile und dachte mir… „Nein, das sieht zu gefährlich aus.“ Tatsächlich ist das schwarze Fenster (ok, auf dem Mac ist es weiss) nicht gerade vertrauenserweckend. Grundsätzlich muss man erst mal wissen, dass Windows und die Unixoiden Welt (also Linux, Mac OS, Free BSD usw.) zwei vollkommen verschiedene Systeme haben.

Auch die Gerüchte, dass man mit der Kommandozeile mit einem Befehl den gesamten Computer zerstören kann, stimmen. Wenn man das unabsichtlich tun will, braucht es allerdings schon eine gehörige Portion Pech. Vor allem aber Befehle die man als Root (tiefste Admin Rechte) ausführt, sollte man zwei mal ansehen bevor man sie ausführt. Denn anders als in vielen Grafischen Oberflächen bekommt man auf der Kommandozeile keine Warnung, wenn man zum Beispiel wichtige Systemdaten löschen will. Vor allem auf Linux gibt es sehr selten Rückfragen wie: „Wollen Sie wirklich…“ Deswegen ist eine gewisse Vorsicht angebracht, aber man muss nicht gleich eine Command Line Phobie entwickeln.

Nun habt ihr also dieses schwarze, unsympathische Fenster vor euch und da kommt natürlich die Frage auf, für was soll ich das brauchen? Weshalb tun sich das Programmierer an, auf einem so schwer verständlichen System zu arbeiten? Sind die tatsächlich in den 80ern stehen geblieben? Kein normaler Anwender würde heute auf eine Graphische Oberfläche verzichten. Wollen die Linux Programmierer damit zeigen, dass sie den anderen technisch überlegen sind?

Nein, der Grund liegt wohl an einem ganz anderen Ort. Sowohl beim programmieren als auch bei Server warten gibt es immer wieder Aufgaben die man ständig wiederholen muss. Diese möchte man natürlich automatisieren. Dies macht man dann mit kleinen Scripts. Ein Script für die Kommandozeile ist viel einfacher zu schreiben als ein kleines Progrämmchen für eine Graphische Oberfläche. Weil man genau für so automatisierte Aufgaben die Kommando Zeile sowieso braucht, wird sie auch sonst oft mal verwendet.

Kommandozeile ist nicht Liebe auf den ersten Blick, denn man muss sie erst mal verstehen und daran scheitern schon viele. Der folgende Befehl gibt eine liste der aktuellen Verzeichnisse und Dateien aus:

ls

Stop! ls ist kein Befehl. Der vermeintliche Befehl ist eigentlich ein kleines Programm. In der Kommandozeile gibt man also keine Befehle ein, sondern man startet Programme. Die Kommandozeile ist also eine Schnittstelle die es ermöglicht, Programme zu starten und eine Interaktion mit den Programmen zu haben. Ls macht nichts anderes als schauen welche Dateien und Verzeichnisse in dem aktuellen Verzeichnis sind, und gibt dann die Namen an die Kommandozeilen Ausgabe zurück. Ls kan aber mehr wie der folgende Befehl zeigt.

ls -l

Damit bekommt man eine erweiterte Liste mit mehr Informationen. Dem Programm kann man einen Parameter übergeben, dass das Programm beeinflusst. Fast alle Commandline Programme haben Parameter. Welche das sind kann man mit

programm --help

herausfinden. „programm“ ist natürlich ein Platzhalter für das aufgerufene Programm. (z.B ls, cp, rm, mv, find, apt usw.

Linux Subsystem auf Windows als Webserver missbrauchen

3 Antworten

Nicht Techniker brauchen diesen Blog nicht zu lesen.

Wer beruflich mit Linux Webserver zu tun hat und aber zum Entwickeln lieber Windows als Plattform verwendet, kennt das Problem. Man möchte die Website gerne lokal bearbeiten und testen, doch was verwende ich dafür? Eine Möglichkeit ist XAMPP, das ich in einem Blog auch schon vorstellte. Das Problem: Die Programme Apache, MySQL und PHP sind nicht komplett identisch auf allen Plattformen. In details kann es zu Abweichungen kommen. Wenn also eine Web Applikation auf XAMPP läuft, ist man nie ganz sicher ob sie dann auch auf dem Webserver läuft.

Seit mehr als einem Jahr gibt es für Windows ein Linux Subsystem. Dieses wurde vorwiegend für Administratoren von Linux Servern hinzugefügt. Denn es bringt die Linux Commandline endlich auch auf Windows. Das Linux Subsystem ist allerdings mehr als nur ein SSH Client. Es ist ein komplettes Command Line Linux auf einem Windows Rechner. Ich habe sogar munkeln hören, dass sogar XWindow Systeme darauf laufen sollten. Probiert hab ich es selbst noch nie und bestimmt ist es auch nicht dafür gedacht. Beziehen kann man das Ganze über den Microsoft Store, ist kostenlos und hat einige Linux Distros zur Auswahl.

Mich hat es letzthin wunder genommen, ob man auf das Linux Subsystem auch einen kompletten Webserver draufbringt. So dass man auf Windows einen LAMP Server hat. Die Antwort ist ja, man kann das. Man muss halt einfach in der Lage sein ein Webserver auf Linux von der Command Line aus einzurichten.

Doch was ist daran besser als eine VM zu nutzen? Man muss beim Subsystem nicht bridgen. Der Server ist direkt auf localhost verfügbar. Was ich allerdings bis jetzt noch nicht hingekriegt habe, war eine SFTP Verbindung zu dem Subsystem aufzubauen. Ich hab allerdings auch nicht lange versucht, da wir eh GIT nutzen, und ich dann jederzeit die aktuelle Version vom Internet holen kann.

Man muss natürlich darauf achten, dass man nicht gleichzeitig ein XAMPP am laufen hat, da es sonst zu Port Konflikten kommt. Das Subsystem ist zwar nicht das schnellste, das will gesagt sein, funktioniert aber wirklich gut. Ein Kuriosum gibt es allerdings. Will man das Subsystem ausschalten braucht man dafür die Windows PowerShell.

net stop LxssManager

Dieser Befehl stoppt dann das Subsystem. Ich finde das eine spannende Alternative, vor allem wenn man hin und wieder auch noch Shell Scripte und cmd Programme braucht. Viel Spass beim ausprobieren.

Programmieren lernen, aber wie?

1 Antwort

Immer wieder werde ich gefragt, wie ich überhaupt programmieren lernte. Alles im Selbststudium, das ist doch gar nicht möglich. Doch das ist möglich, wenn auch nicht so einfach wie manche immer behaupten. Für viele Menschen ist programmieren ein Mysterium und wie es Mysterien so an sich haben, geht auch vom programmieren eine Faszination aus.

Um es gleich mal vorweg zu nehmen, all die Kiddies, die jetzt glauben, man könne Informatik mit dem vergleichen was so ein durchschnitts Jugendlicher vor einem Computer macht, vergesst es! Programmieren hat nichts mit Gamen und schon gar nicht mit YouTube Video kucken zu tun. Und ja, es ist schon wahr, nicht jeder ist für das Programmieren geschaffen. Es erfordert abstraktes und logisches Denken und vor allem (und das ist noch viel wichtiger) viel, nein verdammt viel Geduld. Neven aus Stahlseilen sind hier Pflicht. Denn es kommt vor, dass du mehrere Stunden an einem Fehler sitzt. Mein persönlicher Rekord lag bei 30h, und es war am Schluss ein Komma das ein Kollege vergessen hatte. Jeder Programmierer kann dir da seine eigenen Geschichten erzählen.

Dazu solltest du einen Hang zur Genauigkeit haben und den willen Sachen richtig zu machen. Oft ist dieses „Richtig machen“ den längeren Weg. Aber man tut gut daran diesen zu gehen, denn die Abkürzungen (durty hacks wie man sie nennt) bringen später meist Probleme. Viele lernen das erst nach schmerzlichen Erfahrungen, andere lernen es gar nie. Mit anderen Worten, Programmieren ist nicht der geile Job, den man aus dem Fernsehen kennt, sondern grösstenteils einfach üble Fleissarbeit.

Ich konnte Euch damit noch nicht vertreiben? Eigentlich ziemlich schade, denn sonst hätte ich das Tutorial gar nicht schreiben müssen. Wobei ein Tutorial soll das hier gar nicht werden. Denn solche gibt es schon genug. Ich möchte Euch eher so das Grundrüstzeug auf den Weg geben, um los zu legen.

Viele stellen sich programmieren lernen eh falsch vor. Sie glauben, man liest da irgend ein schlaues Buch und prügelt sich den Inhalt in den Kopf, und danach könne man programmieren. Programmieren lernen heisst learning by doing. Man beginnt ganz am Anfang schon mit kleinen Programmen. Mittels Nachschlagewerken und einer guten Portion Geduld und Logik kann man sich bereits ein Programm zusammenschustern. Dennoch ist der Weg voll von Stolperfallen, und genau diese will ich in meiner Blogserie behandeln. Viele Informationen die ich euch nenne, erscheinen vielleicht gar nicht so wichtig. Lest es Euch trotzdem durch, Ihr erhaltet viele Informationen, die euch später jede Menge Zeit ersparen.

Wir werden mit der Website Programmierung anfangen und uns dann langsam hoch arbeiten. Ich wünsche Euch bei den Tutorials viel Spass

Der neue WordPress.com Editor

Kommentar verfassen

Einige WordPress.com Benutzer haben es vielleicht schon mitbekommen, es gibt einen neuen Editor. Die meisten Leute werden vermutlich von dem Ding erst mal enttäuscht sein. Denn es gibt da die Leiste nicht mehr, bei der man formatieren kann. Beim genaueren betrachten ist sie dann allerdings doch vorhanden, nämlich wenn man mit der Maus über den Absatz fährt.

Aber da ist ja auch nicht alles vorhanden, wo bitte schön ist der Rest? und warum tut man sowas? Der neue Editor unterscheidet zwischen den Block Elementen und den Inline Elementen von HTML. Aus technischer Sicht ist das eine riesige Verbesserung. In Wahrheit ist dein Blog nämlich in Blöcke aufgeteilt. Ein Absatz ist zum Beispiel ein Block, ein Bild ist auch ein Block. Diese kann man neuerdings einfügen in dem man oben links auf das + Symbol klickt.

Da ist dann auch die Auswahl wesentlich grösser, als bei dem alten Editor. YouTube Videos musste man beispielsweise früher händisch im Source Modus hinzufügen. Heute gebt es einen extra Block dafür. Auf der rechten Seite, dort wo im alten Editor die Einstellungen für das Dokument waren, gibt es jetzt einen zusätzlichen Reiter für den Block. Da werden einem die Einstellungen für den jeweils aktiven Block angezeigt. Bei Bildern kann man zum Beispiel die Grösse verändern. Bei Text die Schriftgrösse, sowie die Text und Hintergrundfarbe. Und für die Freaks gibt es sogar die Möglichkeit eigene CSS Eigenschaften zu definieren.

Ich selbst hab auch erst ein kleiner Teil des Editors ausprobiert. Aber was ich gesehen habe, gefällt mir. Ja, es hat noch einige Bugs drin, die hoffentlich noch beseitigt werden. Ich musste schon ein zwei mal in den Source gehen, um Probleme zu beheben. Den Technikern unter uns, wird dieser Editor bestimmt gefallen. Nicht so technisch versierte Leute werden vielleicht eine kleine Angewöhnungszeit brauchen, bis sie sich wohl fühlen. Die neuen Funktionen machen das aber sicher wieder wett.

Nun wünsche ich Euch viel Spass mit dem neuen Editor, und schreibt mir doch einen Kommentar, was ihr davon haltet.

Testwebserver unter Windows mit XAMPP

4 Antworten

Wenn man als Webentwickler das Arbeitssystem auf Windows hat, gibt es immer wieder ein Problem. Denn wo teste ich meine Website? Gerade wenn man eine Seite bearbeiten möchte, die schon produktiv läuft, tut man gut daran, die Änderungen erst zu testen, bevor man sie auf den produktiven Webserver überspielt. Wie schön wäre es doch, einen eigenen Webserver auf dem Computer zu haben. Doch die Gängigen Tools (Apache HTTPd, PHP, MySQL, Tomcat) sind auf Windows nicht vorhanden. Das XAMPP Projekt hilft dabei.

Erst mal muss man auf das XAMPP Projekt gehen, und sich den Installer für Windows runterladen. Dann kann man den Installer starten, bei dem man in mehreren Schritten durch die Installation geführt wird.

Der Installer ist eigentlich selbsterklärend, und sollte für jeden der ein bisschen was von Computer versteht, kein Problem darstellen. Ich rate Euch, alle Tools gleich mit zu installieren, Denn es ist nicht möglich mit dem Installer Module nach zu installieren. Wenn man Module nachinstallieren möchte, muss man das händisch erledigen, was dann nicht mehr so trivial ist.

Der Standard Installationspfad ist C:\xampp was für ein modernes Windows ziemlich untypisch ist. Allerdings ermöglicht dieser Installationspfad, dass alle Benutzer des Rechners auf den Testserver zugreifen können. Wer das verhindern möchte, installiert den Server einfach im eigenen Benutzerverzeichnis. Und ach ja, die installation braucht seine Zeit. Auch wenn ich ein schneller Laptop mit SSD habe, brauchte es doch über 7 Minuten.

Ist die Installation fertig, kann man den XAMPP Control Panel starten. Dort könnt ihr die Services starten. Wer so eine Standardumgebung haben möchte, startet einfach Apche, PHP, und MySQL (Wobei MySQL eine MariaDB ist). Und nicht erschrecken, Windows Firewall wird vermutlich meckern, weil die Services Ports öffnen. Ihr müsst das bestätigen.

Ach ja, wenn das Starten fehlschlägt ist oft ein anderer, bereits auf den Port laufenden Service schuld. Wenn zum Beispiel der IIS von Microsoft bereits gestartet ist, und damit den Port 80 belegt, wird XAMPP nicht laufen.

Man kann den Webserver auch automatisch bei jedem Start starten. Dafür klickt man auf den Config Button im Control Panel und man kann dann bei den Services, die man starten möchte, einen Haken setzen.

Ob das Ganze auch funktioniert, findet ihr heraus, wenn ihr in Eurem Browser https://localhost eingebt. Die Website Daten liegen auf C:\xampp\htdocs\ (bei Standardinstallation). Da habt ihr vier Dateien die ihr einfach überschreiben könnt. Die Ordner die da schon existieren lasst ihr allerdings besser am Leben

XAMPP verfügt über eine Version von PHPMyAdmin. Diese ist über https://localhost/phpmyadmin zu erreichen. Ja, der root Account hat kein Passwort. Wenn ihr wollt, könnt ihr das ändern.

Ach ja, XAMPP ist als reines Testsystem ausgelegt und nicht für den produktiven Einsatz gedacht. Produktiv Systeme setzt man besser händisch auf. XAMPP spuckt zum Beispiel Errors direkt auf der Website aus. Das ist praktisch zum Entwickeln, kann aber ein erhebliches Sicherheitsrisiko auf einem produktiven Server darstellen. Ebenfalls sollte man sich bewusst sein, dass es in vereinzelten Fällen zu Abweichungen von einem normalen Webserver auf Linux kommen kann. Das kommt davon, dass sich die Windows und die Linux Versionen der einzelnen Services teilweise leicht unterscheiden.

Aber zum Entwickeln ist das Tool sehr wohl gut zu gebrauchen. Einen lokalen Webserver zu haben ist praktisch. So, ich hoffe, Euch damit geholfen zu haben. Falls ihr den Beitrag gut findet, linkt ihn doch in den Social Media oder auf Euren Webseiten. Vielen Dank!

Raphael Bircher's Blog

Programmiert, war Sportler, mit Behinderung