Vue.js für Angular Entwickler

Veröffentlicht am von
Antworten

Ich habe bisher mehr mit Angular als mit Vue.js gearbeitet. Für ein kleines Projekt wollte ich aber lieber Vue.js (aufgrund der geringeren Größe) verwenden.

Dabei sind mir ein paar Fragen in den Sinn gekommen, die ich hier in Form von einem kleinen Cheatsheet auch für andere Angular Entwickler festhalten möchte.

Grundsätzlicher Aufbau

Vue.js und Angular sind vom grundsätzlichen Aufbau nicht so verschieden. Vue.js hat sich ja auch bei der Erstellung von Angular.js (welches grundsätzlich anders als Angular v2+ aufgebaut ist) inspirieren lassen und wurde von einem ehemaligen Google-Entwicker gestartet.

Bei beiden Projekten gibt es Components, welche aus einem HTML, CSS und JavaScript (oder TypeScript) bestehen. Diese Components kann man entweder in einer Datei (HTML und CSS inline) oder in getrennten Dateien erstellen.

TypeScript und class-style Components

Der gemeine Angular-Entwickler ist TypeScript mit schönen Decorators gewohnt. Wenn er also das Standard-Vue.js einrichtet (JavaScript ohne Decorators) ist er erst mal geschockt. Das muss aber nicht sein!

Vue.js unterstützt auch TypeScript: https://vuejs.org/v2/guide/typescript.html und mit der https://github.com/vuejs/vue-class-component sieht eine Vue.js Component fast wie eine Angular-Component aus!

Dependency Injection

Gibt es in Vue.js auch: https://vuejs.org/v2/guide/components-edge-cases.html#Dependency-Injection

RxJS

Auch hier muss der gewohnte Angular-Liebhaber auf nichts Neues setzten: https://github.com/vuejs/vue-rx

Material Design

https://vuetifyjs.com/en/ ist quasi das äquivalent für Angular Material.

Fazit

Gerade über die letzten Jahre sind viele Standard-Features von Angular auch zu Vue.js gekommen und man muss sich nicht einmal großartig umgewöhnen, wenn man mal statt Angular Vue.js in einem neuen Projekt verwenden will.

Xbox 360: Lade öffnet sich nicht

Veröffentlicht am von
Antworten

In letzter Zeit habe ich einige defekte Xbox 360 gekauft. Viele davon hatten das Problem, dass sich die Lade / das Laufwerk einfach nicht öffnet. Bei manchen ging es sporadisch, bei anderen ging es überhaupt nicht.

Ein typisches Zeichen für das Problem ist, dass das Laufwerk Geräusche von sich gibt und grün blinkt, sonst aber nichts Weiteres passiert.

In dem folgenden Video zeige ich, wie man das Problem behebt:

Für alle, die den Lösungsweg gerne in Textform sehen möchten, habe ich meinen Weg hier auch aufgeschrieben:

  1. Es gibt für jedes Xbox Modell ein passendes Netzteil – es sollte also sichergestellt werden, dass das richtige Netzteil verwendet wird.
  2. Um zu testen, ob das Laufwerk überhaupt funktioniert und Spiele lesen kann, kann man mit der Hilfe einer Kreditkarte an der rechten Seite der Lade beim Öffnen mithelfen, indem man die Karte hineinsteckt und etwas nach vorne drückt.
    • In meinen Fall konnte ich anschließend ein Spiel einlegen und dieses wurde auch abgespielt.
  3. Um das Problem zu beheben, sollte man am Besten die Xbox 360 auseinandernehmen. Hierfür kann man entweder ein spezielles Xbox 360 Opener Tool verwenden oder man verwendet einen Schlitzschraubenzieher.
    1. Für die untere und obere Abdeckungen (dunkelgrau) muss man die Plastiklaschen lösen, hierfür kann man mit einem stumpfen Gegenstand in die Löcher stechen.
    2. Bei der oberen Abdeckung sollte man zudem einen Standfuß lösen, da darunter das benötigte Loch zum Lösen der Lasche ist.
    3. Die Frontplatte (mit dem Startbutton) kann man am unteren Ende vorsichtig loslösen.
    4. Auf der Rückseite sind viele schlitzgroße Löcher, die man entweder vorsichtig mit einem Schlitzschraubenzieher und dem erwähnten Tool eindrücken kann.
    5. Auf der Vorderseite sind mehrere Laschen, die man mit einem Schlitzschraubenzieher auch leichter öffnen kann.
  4. Nun sollte man alle Torx-Schrauben entfernen. Diese sind lang und silberfarben und können mit einem T10 Schraubenzieher entfernt werden.
  5. Anschließend dreht man die Xbox um und entfernt das übrige Plastikgehäuse.
  6. Evtl. muss man nun noch das silbrige Siegel am DVD Laufwerk brechen.
  7. Darauf sollte man die zwei Anschlüsse am Ende des DVD Laufwerks entfernen.
  8. Das DVD Laufwerk kann man nun einfach hochheben und entfernen.
  9. Um das DVD Laufwerk zu öffnen, reicht ein einfacher Kreuzschraubenzieher
    1. Man kann anschließend leicht die beiden Gehäusehälften entfernen.
    2. Anschließend sollte man mit einem Schraubenzieher vorne das Rad unter der Lade leicht drehen und an der Lade ziehen, um diese zu öffnen.
    3. Danach kann man das Band am Zahnrad aus der Lade entfernen.
  10. Ich konnte gute Erfolge erzielen, indem ich das Band in einen Wasserkocher erhitzt habe und anschließend in IPA (Isopropanol) getaucht habe.
  11. Danach habe ich das Band wieder befestigt und die Xbox wieder zusammengebaut.

Hoffentlich kann jemand mit dieser Anleitung auch seine Xboxen reparieren. Bei Fragen freue ich mich auf Kommentare unter diesem Blog Post oder unter dem YouTube-Video.

Windows: Start-Skript einrichten

Veröffentlicht am von
Antworten

Wer unter Windows ein Start-Skript einrichtet, kann Aufgaben wie das Pullen von Git-Repositorys und das Starten von Programmen schön automatisieren.

Aufgaben kann man mit der Windows Aufgabenplanung planen. Diese wird über Start -> Suche nach „Aufgabenplanung“ auch schnell gefunden.

Eine neue Aufgabe kann über „Einfache Aufgabe erstellen …“ ganz einfach angelegt werden.

Zur besseren Übersicht sollte man der neuen Aufgabe natürlich einen Namen geben. „Startup“ wäre eine Option …

Anschließend gibt es verschiedene Optionen, wann die Aufgabe ausgeführt werden soll. „Beim Anmelden“ führt die Aufgabe nach der Anmeldung eines Benutzers aus.

Natürlich muss man angeben, was genau durchgeführt werden soll. „Programm starten“ ist hier allerdings die einzige Möglichkeit, welche nicht veraltet ist.

Da ich ein Batch-Skript geschrieben habe (eine Anleitung, wie man ein Batch-Skript schreibt, kann man mit einer gezielten Suche schnell finden), wähle ich dieses natürlich aus.

Kurz vor dem Ende können wir unsere Auswahl noch einmal begutachten.

Fertig. Die Aufgabe wurde erstellt und sollte bei allen zukünftigen Anmeldungen ausgeführt werden können.

Xfce: Start-Skript einrichten

Veröffentlicht am von
Antworten

Ein Start-Skript nach dem Anmelden eines Benutzers kann bestimmte Aufgaben wie z.B.: das Pullen von einem Git Repository oder das Öffnen von Anwendungen gleich beim Start ausführen.

Da ich mir unter Xfce ein solches Skript eingerichtet habe, möchte ich nun zeigen, wie das funktioniert. Als Beispielsystem werde ich Xfce unter Manjaro Linux verwenden.

Zuerst sollte man natürlich sein Skript (z.B.: als Bash-Skript) schreiben. Hierauf gehe ich allerdings in diesem Artikel nicht genauer ein. Seiten wie „ubuntuusers“ bieten dazu genügend gute Anleitungen.

Anschließend kann man über die Xfce-Einstellungen den Punkt „Sitzung- und Startverhalten“ auswählen.

Über „Automatisch gestartete Anwendungen“ kann man mit dem Button „Hinzufügen“ auch eine neue Startanwendung in die Liste aufnehmen.

Das anschließende Fenster möchte mit einem verständlichen Namen und dem Pfad zu unserem Skript gefüllt werden.

Nun sollte das Skript immer nach der Anmeldung automatisch ausgeführt werden.

Arch Linux: Bildschirmhelligkeit anpassen

Veröffentlicht am von
Antworten

Ich wollte heute unter Manjaro Linux meine Bildschirmhelligkeit anpassen. Leider gibt es direkt von Manjaro / Arch Linux hier keine GUI-Einstellung zum Regeln der Helligkeit.

Was es aber gibt, sind zwei nützliche Pakete: light und Clight. Mit light kann man die Helligkeit über die Konsole anpassen, Clight erkennt die aktuelle Umgebungshelligkeit über die Webcam und passt dementsprechend die Bildschirmhelligkeit an.

Da Clight aber nur über Arch AUR erhältlich ist, habe ich mal light ausprobiert und bin damit zufrieden.

Light kann man ganz einfach über pacman installieren:

pacman -S light

Anschließend kann man die aktuelle Helligkeit als Prozentwert ausgeben lassen:

$ light -G
23.99

Und die Helligkeit um x Prozent erhöhen:

$ light -A 70

Automatische Gitea Updates

Veröffentlicht am von
2

Bereits im Januar dieses Jahres habe ich über meine Erfahrungen mit Gitea Updates berichtet. Das große Problem von Gitea ist, dass es sich nicht automatisch selbst aktualisiert. Ein Issue für das Problem ist schon seit fast 2 Jahren offen: https://github.com/go-gitea/gitea/issues/518#issuecomment-441742904

Ich hasse es wirklich, wenn sich eine sicherheitskritische Webanwendung nicht von selbst aktualisiert – das erlaubt Hackern ein leichtes Spiel. Vor vier Monaten habe ich nun schon die Entwicklung eines automatischen Gitea Update Skripts begonnen, welches ich nun vorstellen möchte.

Hinweise vor der Benutzung

Wie ich bereits erwähnt habe, bin ich kein Fan von manuellen Updates und schreibe deshalb für viele meiner Systeme Skripts zum automatischen Aktualisieren. Diese Programme sind schnell erstellt worden und auf meine Bedürfnisse angepasst und können unsauberen Code enthalten. Ich bin allerdings für Verbesserungsvorschläge in Form von Issues und Pull-Requests offen!

Manche Entwickler – wie der Ersteller von Kanboard – haben eine grundsätzliche Skepsis gegenüber automatischen Updates. Es gibt hierfür gute Gründe – du möchtest ja sicher nicht, dass deine Anwendung plötzlich aufgrund eines fehlerhaften Upgrades nicht mehr geht – deshalb empfehle ich automatische Upgrades nur, wenn auch automatische Backups eingerichtet sind.

Das Skript

Die veröffentliche Version meines Skripts kann auf GitHub gefunden werden: https://github.com/CMiksche/gitea-auto-update

Ich habe das Skript nur für mein Debian System entwickelt und getestet. Wenn das Skript einfach so auf Windows, MacOS oder Linux Systemen ohne Systemd ausgeführt wird, können Fehler nicht vermieden werden! Für diese Systeme muss das Skript definitv angepasst werden.

Wenn das Design von Gitea angepasst wurde, kann es sein, dass ein automatisches Upgrade dieses Template zerstört. Hierauf wird im Skript nicht geprüft.

Wie man mein Skript benutzt

Bitte zuerst die oberen Absätze lesen, ohne Beachtung dieser Hinweise kann es schnell in die Hose gehen!

Die Anwendung ist recht einfach:

  • Installiere mein Skript auf dem Zielsystem: 
    pip install gitea-auto-update
  • Erstelle eine settings.ini: 
    [Gitea]
site=https://your-gitea-instance.com/api/v1/version
apiUrl=https://api.github.com/repos/go-gitea/gitea/releases/latest
system=linux-amd64
file=/usr/local/bin/gitea
tmpDir=/tmp/
buildFromSource=None
sourceDir=/home/git/go/src/code.gitea.io/gitea
logFile=update.log
  • Führe den Befehl gite-auto-update --settings=/path/to/settings.ini aus, um das erste Upgrade zu testen
  • Wenn die Updates regelmäßig automatisch ausgeführt werden sollen, bearbeite die /etc/crontab Datei und rufe dort einen Aufruf des Skripts aus

So einfach geht das. Wenn du auf Probleme stößt, zögere nicht einen Issue oder Pull-Request auf Github zu erstellen oder hier einen Kommentar zu hinterlassen.

Diesen Beitrag habe ich auch auf Englisch veröffentlicht.

Debian 9 Upgrade mit nginx und PHP 7.2

Veröffentlicht am von
Antworten

Ich habe nun alle meine Debian Systeme auf die neueste Version „Stretch“ ohne größere Probleme aktualisieren können.

Da ich in den letzten Jahren allerdings immer größere Probleme hatte und weiß, dass eine gute Anleitung hilfreich sein kann, möchte ich hier meine Vorgehensweise anhand eines Webservers mit Debian 8 beschreiben.

Hintergrund

Gerade bei Webservern ist eine Aktualisierung wichtig, da Sicherheitslücken den Server schnell zu einer Virenschleuder verwandeln können.

Sollte PHP auf dem Webserver verwendet werden, führt kaum ein Weg an einem Upgrade vorbei, da Debian 8 keine aktuelle PHP-Version ausliefert. (Debian 9 zwar auch nicht wirklich aber dazu später mehr …)

Vorbereitung

Folgende Punkte führe ich immer vor einer Webserver-Aktualisierung durch:

  • Wartungsmodus in WordPress / anderen CMS aktivieren
    • Bei größeren Projekten die Nutzer über das Upgrade informieren
  • Wichtige Verzeichnisse sichern (sollte man generell regelmäßig machen), z.B.:
    • Webserver-Verzeichnis (/var/www)
    • /opt Verzeichnis (bei manuell hinzugefügter Software)
    • /home Verzeichnisse (Daten der Unix-Nutzer)
  • Wichtige Dateien sichern
    • z.B.: /etc/crontab mit regelmäßig ausgeführten Skripten
  • Alle Datenbanken sichern

Aktuelle Pakete herunterladen

Mit

apt update

und danach

apt upgrade

aktualisiert man die aktuellen Pakete.

Alte Sources sichern

Damit man bei Problemen schnell wieder auf Debian Jessie wechseln kann, ist eine Sicherung der alten Sources List hilfreich:

cp /etc/apt/sources.list /etc/apt/sources.list_backup

Wichtig: Sollte es auch Dateien unter /etc/apt/sources.list.d geben, ist auch eine Sicherung dieser Dateien nicht überflüssig!

Neue Sources pflegen

Nun sollte man den Namen der alten Version durch den Namen der neuen Version in der Sources.list und allen anderen Dateien unter z.B.: /etc/apt/sources.list.d aktualisieren. sed ist für solche Aufgaben perfekt geeignet:

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

Pakete aktualisieren

Nachdem wir nun die Quellen auf die neue Version geändert haben, können wir die Paketquellen mit den folgenden Befehl aktualisieren:

apt update

Anschließend aktualisieren wir die Pakete wieder mit:

apt upgrade

Hier kann es sein, dass wir den Befehl mehrmals ausführen müssen und gefragt werden, ob wir die aktuellen Konfigurationsdateien behalten wollen oder neue Konfigurationsdateien übernehmen (letzteres sollte nur gemacht werden, wenn nichts an den Konfigurationen geändert wurde).

Systemupgrade abschließen

Mit den bisherigen Befehlen wurden noch nicht alle Pakete aktualisiert. Um das Systemupgrade abzuschließen, benötigen wir eine Ausführung des folgenden CLI-Befehls:

apt dist-upgrade

Systemupgrade prüfen

Nach einem großen Upgrade empfiehlt sich ein Neustart, welcher mit

reboot

durchgeführt werden kann.

Um festzustellen, ob wir die gewünschte Version haben, kann man diese mit cat ausgeben lassen:

cat /etc/issue

PHP aktualisieren

Zum Zeitpunkt dieses Posts gibt es noch keinen mir bekannten Weg, um PHP direkt von den Debian Sources zu beziehen. Deshalb müssen für PHP 7.2 Fremdquellen genutzt werden. Bei Fremdquellen sollte immer auch auf das Sicherheitsrisiko geschaut werden.

Vorerst sollten wir PHP deinstallieren:

apt purge php*

Anschließend den Schlüssel des fremden Repos importieren:

wget -qO - https://packages.sury.org/php/apt.gpg | sudo apt-key add -

Um dann die Quelle in eine Sources List zu speichern:

sudo echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

Die Paketquellen aktualisieren wir wieder mit:

apt update

Nun können wir endlich die neue Version von PHP installieren:

sudo apt install php7.2

(hier können natürlich auch noch weitere Pakete wie php7.2-imap gewählt werden)

nginx anpassen

Da ich gerne nginx als Webserver verwende, musste ich für die neue PHP-Version auch den Socket in den sites-available aktualisieren.

Dafür wechseln wir erst in das Verzeichnis der virtual Hosts:

cd /etc/nginx/sites-available/

Danach bearbeiten wir die gewünschte Website mit einem Editor unserer Wahl – z.B.: nano.

Wir suchen erst nach fastcgi_pass und passen die Zeile dann wie folgt an:

fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;

Um die Änderung aktiv zu schalten, müssen wir den Webserver noch neu starten:

systemctl restart nginx.service

Ich hoffe, meine Erklärung des Debian Upgrades war hilfreich. Wenn ihr zukünftig Tutorials zu Themen wie Debian Webserver erhalten möchtet, könnt ihr mir gerne auf Twitter folgen.

nginx: upstream sent too big header

Veröffentlicht am von
Antworten

Beim Einloggen in einen WordPress Blog hatte ich vor Kurzem nach einem Upgrade von Debian und PHP einen 502 Bad Gateway Error. Dieser wurde von einem „upstream sent too big header“ Fehler ausgelöst.

Da ich zu diesem Fehler nur englische Beiträge gefunden habe, möchte ich hier mal einen Lösungsweg auf Deutsch teilen.

In der nginx Error Log, welche man unter Debian unter /var/log/nginx/error.log finden kann, fand ich die folgende Zeile:

[error] upstream sent too big header while reading response header from upstream, client: ***.***.***.***, server: *****.***, request: "GET /wp-login.php

(Domain und IP-Adresse aus Datenschutzgründen unkenntlich gemacht)

Eine Lösung, um diesen Fehler zu beheben, ist unter Debian die /etc/nginx/fastcgi.conf zu bearbeiten und die folgenden Zeilen hinzuzufügen, um die Buffer Size festzulegen: 

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

(Stack Overflow Post dazu)

Natürlich muss man selbst ermitteln bzw. wissen, welche Buffergrößen notwendig sind. Nginx selbst hat hierzu auch eine gute Dokumentation online: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffer_size