Was ist besser: Pebble Time oder Apple Watch?

Als bisher erfolgreichste Kickstarter Kampagne hat Pebble nun bereits zwei mal alle Rekorde gebrochen – und auch eine entsprechende Bekanntheit erlangt. Und da man mich ja sehr schnell für technische Spielereien begeistern kann, hatte ich relativ schnell eine Pebble (die allererste) an der Hand.

img_2946

Und ich war mega glücklich. Pebble hatte die Zeichen der Zeit (Achtung Wortspiel 🙂 ) erkannt und war die perfekte Kombination zum Smartphone. Nach einiger Zeit merkt man allerdings, dass auch nur die Anzeige von Notifications Sinn macht – bei den Apps gibt es nur einige wenige gute Ausnahmen. Mit diesem Problem haben aus meiner Sicht jedoch alle Smartwatches zu kämpfen.

Dank der großartigen Unterstützung für App Enwickler, mit Online IDE und simpler Javascript Entwicklung, waren auch schnell die ersten eigenen Apps gebastelt. Geblieben ist allerdings nur eine App für die Anzeige von Abfahrtszeiten der für mich relevanten Busse und Bahnen. Aus meiner Sicht muss eine App ihren Zweck innerhalb kürzester Zeit erfüllen (max. 10s), sonst wird man äußerst schnell ungeduldig. Dies gilt übrigens auch für alle Smartwatches.

Die cleverste Idee hatte Pebble jedoch mit dem E-Paper/LCD Display, welches eine Laufzeit von bis zu 7 Tagen ermöglicht – und zusätzlich auch bei direkter Sonneneinstrahlung perfekt ablesbar ist. Aus meiner Sicht eines der Hauptargumente für die Pebble.

Und dann kam Apple daher und kündigte die Apple Watch an. Bäm. Und sie kam richtig geil rüber. Retina Screen, Touch, tolles Design – aber nicht mal einen vollen Tag an Akkulaufzeit. Glücklicherweise hatte ich die Möglichkeit, über meinen damaligen Arbeitgeber eine Apple Watch als Testexemplar lange und ausführlich ausprobieren zu können.

img_4432

Der Unterschied zur Pebble war enorm, endlich wunderbare Grafik, Siri direkt an der Hand, auf Nachrichten direkt antworten können – und wenn es mal in den Flieger ging, das Boardticket auch direkt an der Hand haben. Stark. Aber ein riesiger Schatten lag über all den Vorteilen: die Akkulaufzeit. Teilweise ging die Uhr bereits am frühen Abend aus. Und nach den WatchOS Updates hatte ich einige Tage lang das Problem, dass die Uhr bereits nach wenigen Stunden leer war. Mega nervig und enttäuschend, vor allem weil alleine das “Ladekabel” gute 35€ kostet.

Nachdem ich nun vor kurzem die Apple Watch wieder abgeben musste, war ich im Zugzwang. Kaufe ich mir eine eigene Apple Watch, oder schwenke ich zurück zu Pebble, die mit der “Time” mittlerweile auch eine Smartwatch mit Farbdisplay im Angebot haben. Nachdem ich dann sah dass die Pebble Time “nur” 100€ kostet, war die Entscheidung sehr schnell gefällt. Die Uhr kam kurze Zeit später an, war schnell eingerichtet und ab an den Arm. Wahnsinnig toll, welchen Sprung die Uhr gemacht hat – tolles Design sowie ein großartiges neues und vor allem sehr durchdachtes Betriebssystem. Man merkt, dass sich da Leute richtig viel Gedanken gemacht haben. Touch ist in vielen Fällen sicherlich die bessere Art der Steuerung durch Menschen, aber auf dem kleinen Display kommt man mit den Tasten dann doch besser klar.

Aber der größte Vorteil der Pebble ist und bleibt: die Akkulaufzeit. Es ist unglaublich, wie entspannend es sein kann, wenn einem der Akkustand der Smartwatch auf einmal wieder egal ist. Man muss nicht ständig überlegen, ob man das Kabel eingepackt hat und ob der Akku durchhält. First-World-Problems, ich weiß – aber so ist es nun mal 🙂

Kommen wir zum Vergleich: Das Hauptaugenmerk einer Smartwatch sollte das Display sein. Hier muss ich sagen, dass die Pebble Time zwar leicht vorne liegt, die Apple Watch aber auch ganz klar ihre Vorzüge hat. Zwar ist das E-Ink Display der Pebble immer an und in sehr vielen Situationen ganz gut ablesbar, das Display der Apple Watch ist aber ganz klar überlegen – wenn es denn angeht. Reicht es bei der Apple Watch in nahezu allen Situationen, einfach den Arm so zu bewegen, dass man auf die Uhr schauen möchte, so muss man bei der Pebble eine heftige Schüttelbewegung durchführen, damit die Hintergrundbeleuchtung eingeschaltet wird. Wie gesagt, die Pebble liegt hier etwas weiter vorne, einfach, weil man die Uhrzeit bzw. Notification in 99% der Fälle sofort sehen kann. Bei der Watch funktioniert der Mechanismus ab und zu einfach nicht, was dann in hektischen Bewegungen endet. Alles in allem nicht wirklich befriedigend.

Zusammenfassend kann ich sagen: Aus meiner Sicht funktionieren derzeit alle Smartwatches gleich. Sie dienen hauptsächlich der Anzeige von Notifications, Apps spielen kaum eine Rolle und wirklich relevant ist die Akkulaufzeit. Man kann sich nun streiten, ob der Akku nun unbedingt 7 Tage lang halten muss, aber ich denke 2 Tage sollten mindestens drin sein. Einfach, weil man sein Ladegerät nun nicht immer überall mit dabei hat. Der deutliche Mehrwert ergibt sich dann mit der Integration in das jeweilige Handy-Betriebssystem. Unter iOS liegt die Apple Watch hier klar vorne, weil auch wirkliche Interaktion sowie die Nutzung von Siri möglich ist. Bei Android wiederum kann die Pebble vollständig genutzt werden und dann z.B. auch auf SMS direkte Antworten schicken.

Fazit: seid ihr iOS Nutzer, dann müsst ihr selbst abwägen, ob euch die Akkulaufzeit oder die Interaktionsmöglichkeiten wichtiger sind. Für Android Nutzer ist die Pebble sehr sinnvoll.

Nachtrag: während ich diesen Beitrag verfasst habe, wurde Pebble leider an Fitbit verkauft und die Herstellung der Hardware sowie deren Verkauf beendet. Fitbit will wohl dafür sorgen, dass die Software weiterhin funktioniert. Mega schade, aber so ist es nun mal. Solltet ihr also darüber nachdenken, euch eine günstige Pebble zu kaufen, dann solltet ihr sehr schnell zuschlagen. Ihr müsst dann aber auch damit rechnen, dass die notwendige Pebble App in Zukunft irgendwann nicht mehr funktioniert 🙁

Wie kann ich einen unendlich lang gültigen Facebook Page Accesstoken erzeugen?

Facebook Access Tokens sind eine ziemlich fiese Sache, wenn man Server only Anwendungen bauen möchte – also keine wirkliche Chance hat, den User einen Token besorgen zu lassen. Zusätzlich haben die “normalen” Access Tokens bei Facebook das Problem, dass sie spätestens nach 60 Tagen ungültig sind. Es gibt aber derzeit noch eine Möglichkeit, an unendlich gültige Access Tokens zu kommen. Mit diesen Tokens könnt ihr beliebig auf euer Seite posten, Statistiken abfragen usw. – und an diesen Token kommt ihr so:

  1. Zunächst müsst ihr Admin der gewünschten Fan Page sein
  2. erstellt eine Facebook App – natürlich mit dem gleichen User, der auch Admin der Seite ist.
  3. kopiert in den Einstellungen der App die App-ID sowie das App Secret
  4. öffnet den Facebook Graph API Explorer
  5. oben rechts ist ein Dropdown, in dem ihr die eben erstellte App auswählt (anfänglich steht da “Graph API Explorer” drin)
  6. nun klickt ihr auf das “Get Token”-Dropdown und wählt da “Get User Access Token” – dabei ist es wichtig, dass ihr in der nun erscheinenden Übersicht das Häkchen bei “manage_pages” setzt
  7. kopiert nun den kurzfristigen Token aus dem Textfeld in der Mitte und ruft folgende URL auf:
    https://graph.facebook.com/oauth/access_token?client_id=[APP_ID]&client_secret=[APP_SECRET]&grant_type=fb_exchange_token&fb_exchange_token=[TOKEN]
  8. kopiert euch den nun angezeigten langfristigen Token (LONG_LIVING_TOKEN, 60 Tage gültig)
  9. ruft nun die folgende URL auf:

    https://graph.facebook.com/me/accounts?access_token=[LONG_LIVING_TOKEN]

  10. in dem nun erscheinenden JSON seht ihr alle von euch verwalteten Seiten sowie deren unendlich lang gültigen Tokens für die verwendete App

Zur Überprüfung ruft ihr einfach das Access Token Debug Tool auf: 

https://developers.facebook.com/tools/debug/accesstoken

Hier könnt ihr den Token eintragen und bekommt dann Informationen darüber – und eben auch die Gültigkeit.

Wie kann ich auf das Timemachine Backup eines anderen Macs zugreifen?

Folgende Problemstellung: Du hast eine Timemachine USB Festplatte mit Backups eines anderen Macs, aus denen du einzelne Dateien auf deinen aktuellen Mac kopieren möchtest. Prinzipiell geht das einfach über den Finder, aber der Zugriff auf bestimmte Ordner, wie z.B. den Documents oder Images Ordner eines Users kannst du nicht öffnen, da dafür eine Beschränkung aktiviert ist. Um diese Beschränkung zu umgehen, rufe folgendes Command in einem Terminal aus:

sudo vsdbutil -d '/Volumes/[NAME_DEINER_USB_PLATTE]'

Mit diesem Command werden die Dateizugriffsrechte für diesen Pfad deaktiviert und du hast vollen Zugriff darauf.

Wie lade ich in Django 1.10 ein Bild von der Festplatte per Django Command hoch?

Für den Fall, dass man ein Bild in eine Django Applikation uploaden möchte, gibt es unzählige Tutorials – kniffelig wird es dann ein bisschen, wenn man ein Bild von der Festplatte des Servers, auf dem die Applikation läuft, mittels Django Command hochladen möchte. In meinem Beispiel importiere ich Bilder per Cronjob aus einem anderen Programm. Bisher ging der Upload auch ohne Probleme, aber seit Django 1.9 oder 1.10 wurde das Sicherheitskonzept geändert – man darf keine Dateien mehr ausserhalb des Media_Path Kontextes hochladen (Suspicious File Operation. Um das Problem zu umgehen, muss man das “normale” Fileobject, welches man normalerweise dann an das Model übergeben würde, in den Django File Wrapper packen. Dazu importiert ihr diesen Wrapper wie im Beispiel unten, übergebt den realen Pfad zum Bild und, und das ist nun wichtig, übergebt per “name” Parameter einen beliebigen Dateinamen, mit dem diese Datei dann im “Upload Prozess” von Django ankommt. Nun müsst ihr das “image” Objekt einfach nur an den Image Parameter eures Models hängen, und schon klappt das Einspielen der Datei wieder. Bei mir war es tatsächlich der fehlende “name” Parameter, der mich in die Verzweiflung getrieben hat 🙂

from django.core.files import File
image = File(open("[PATH_TO_REAL_FILE]", "rb"), name="[SOME_FILE_NAME]")

[Quicktip] Nginx Reverse Proxy mit Basic Auth

Nehmen wir an, ihr richtet einen Nginx als reverse Proxy ein und möchtet nun, dass bestimmte Subdomains, die von anderen Servern durchgeschliffen werden, per Basic Auth “geschützt” werden sollen. Dann werdet ihr wahrscheinlich auf das Problem stoßen, dass ihr immer wieder nach dem Basic Auth Login gefragt werdet und der Reverse Proxy nicht korrekt agiert. Die Lösung ist ganz einfach: ihr müsst verhindern, dass die Basic Auth Header weitergereicht werden. Und das geht so:

server {
    listen 80;
    server_name foo.bar.com;
    access_log            /var/log/nginx/foo.access.log;
    location / {
      proxy_set_header        Authorization "";    # <== das ist die wichtige Zeile, die verhindert, dass Basic Auth weiter gereicht wird!
      auth_basic              "Protected";
      auth_basic_user_file    /etc/nginx/basic_auth;
      proxy_set_header        X-Real-IP $remote_addr;
      proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header        X-Forwarded-Proto $scheme;
      proxy_set_header        Host [YOUR_REMOTE_DOMAIN];
      proxy_set_header        Accept-Encoding "";
      proxy_pass              [YOUR_REMOTE_URL];
      proxy_read_timeout      90;
    }
}

[Quicktip] 2 Faktor Authentifizierung für Amazon aktivieren

Mittlerweile hat man mit Amazon ja einen relativ wichtigen Account, über den man nicht nur einkauft, sondern evtl. auch seine Cloud Server betreibt oder das Amazon Cloud Drive verwendet. Von daher macht die 2 Factor Authentifizierung in jedem Fall Sinn, um nicht mal eine böse Überraschung zu erleben.

Die Aktivierung ist relativ leicht: meldet euch einfach auf “amazon.com” statt auf “amazon.de” an, und geht dann in die Accounteinstellungen, wo ihr das Passwort ändern könnt (Login & Security Settings). Unter “Advanced Security Settings” könnt ihr dann 2-Factor Auth aktivieren. Sobald das erledigt ist, erscheint dieser Menüpunkt auch auf der deutschen Amazon Seite 😉

[Quicktip] Wie kann ich alle installierten Python pip Packages upgraden?

Über einen kleinen Umweg kann man auf der Bash ganz einfach alle aktuell installierten pip Pakete updaten / upgraden:

pip freeze | sed -e 's/==.*//g' > upgrade.txt
pip install --upgrade -r upgrade.txt
rm upgrade.txt

Das Script lässt sich alle installierten Pakete ausgeben, entfernt das “==[Versionsnummer]” hinter dem Namen und packt diese Liste in die Datei upgrade.txt. Anschließend wird diese Datei bei einem “pip upgrade” als “requirements.txt” übergeben und mit dem upgrade Befehl ausgeführt.

Crashplan auf Windows Homeserver (WHS) installieren

Seit langem bin ich auf der Suche nach einer Off-Site Backup Lösung, die preislich noch im Rahmen ist, aber gleichzeitig auch relativ große Datenmengen erlaubt. Letzteres ist bei nahezu allen “einfachen” Diensten wie Dropbox, OneDrive, iCloud usw. nicht gegeben, da dort eher im Bereich GB bis wenige TB gearbeitet wird. Als Fotograf mit sehr vielen und leider auch sehr großen RAW Files stoße ich da relativ schnell an die Grenzen. Hinzu kommt die Einschränkung, dass ich meine Daten auf einem Windows Homeserver liegen habe, der auch gleichzeitig das zentrale Backup übernehmen soll. Mit Crashplan bin ich fündig geworden – es gibt einen “unlimit” Backup für 60€ im Jahr – und der Client läuft auch unter Windows Homeserver. Andere Anbieter blockieren sofort, wenn sie merken, dass der Client auf einer “Serverversion” von Windows läuft. Crashplan glücklicherweise nicht.

Zurück zum Thema. Ich hab den Client installiert und es passiert nichts. Der Dienst besteht aus zwei Teilen: einer Backup Engine und der Gui. Die Gui sagte mir einfach nur, dass sie die Backup Engine nicht finden könne. Ein Blick in den Dienste Manager von Windows zeigte mir, dass der Service auch nicht lief. Wenn man ihn starten wollte, kam nur die Meldung, dass der Dienst “gestartet und anschließend gleich wieder gestoppt/pausiert wurde. Keine weiteren Hinweise oder Logs. Nach etwas Recherche im Netz fand ich zumindest Hinweise, dass es wohl Probleme mit den Portbelegungen gibt – aber bei mir wollte ja der Dienst nicht mal starten. Die Lösung war dann doch etwas simpel: Der Client verbraucht per Default mittlerweile 1GB Ram – und das hat mein Acer Aspire easyStore H340 mit seinen 2GB Ram scheinbar nicht mehr übrig. Also editiert man in der Datei “c:\Programme\CrashPlan\CrashPlanService.ini” die Zeile mit den Java Virtual Machine Parameters:

von

-Xmx1024M

in

-Xmx512M

Und schon läuft der Service, sobald man ihn nochmal startet. Aber der Client wollte noch immer nicht – und da kam die eben genannte Port Problematik zum Vorschein. Um dies nachvollziehen zu können, ruft man die Command Shell von Windows auf und gibt da folgendes ein:

netstat -ona

Bildschirmfoto 2016-05-08 um 14.28.37 Kopie

Wie man sieht, lauscht die Backup Engine auf Port 4242, der Port im Client ist per Default jedoch 4243. Wenn man nun in der Datei “c:\Programme\CrashPlan\conf\ui.properties” die folgende Zeile editiert, läuft es:

#servicePort=4243


in

servicePort=4242

Abschließend startet man nun den Client und wird endlich von der Crashplan Oberfläche empfangen 😉