Posts Tagged ‘Bug’

Sonntag, 13. Januar 2019

Netgear Arlo bei Bewegungsmeldungen in der Nacht aufnehmen lassen

Link zu diesem Artikel

Netgear hat mit Arlo ein tolles Überwachungskamera-Produkt entwickelt, doch leider bei der Software-Entwicklung respektive bei der Usability etwas geschlampt.

Ich helfe wetten, dass sehr viele Käufer eine Kamera für folgenden Anwendungsfall anschaffen: Zeichne ein Video auf, sobald die Kamera in der Nacht eine Bewegung entdeckt; z.B. wenn die Kamera auf einen Hinterhof gerichtet ist und man gelegentlich „Besuch“ von unliebsamen Gestalten erhält.

Folgendes Feature ist in der Software derzeit nicht präsent:

Aktivierung des Bewegungsmelders nach Sonnenuntergang und Deaktivierung nach Sonnenaufgang Dies könnte man auf zwei Arten bewerkstelligen: (a) An Hand des konfigurierten Standorts einer Kamera werden tagesaktuelle Sonnenauf- und -untergangszeiten beachtet. Oder (b): Ein Lichtsensor bemerkt, wann es Dunkel respektive wieder Hell wird und aktiviert/deaktiviert den Bewegungsmelder der Kamera entsprechend.

Derzeit muss man sich damit behelfen, den Bewegungsmelder der Kamera gemäss Zeitplan aktiv zu schalten. Und hier lauert bereits der nächste Fallstrick: Arlo kennt zur Agrenzung für Zeitpläne nur Tage, d.h. von Mitternacht bis Mitternacht. Etwas Naheliegendes wie „aktiviere die Kamera während der ganzen Nacht“ ist der Software unbekannt und kann so nicht direkt konfiguriert werden, weil das Ereignis „Nacht“ auf unseren Breitengraden immer zwei Tage umfasst.

Deshalb muss man sich bei einem solchen Wunsch mittels eines klassischen „Workarounds“ damit behelfen, dass man für jeden Tag zwei Aktivitätsblöcke einrichtet: Einen von 00:00 bis bspw. 08:00 Uhr, und dann einen zweiten von 17 bis 23:59 Uhr. Dabei ist es extrem wichtig, dass man nicht 00:00 Uhr als Endzeit einstellt, weil das auf Grund der Überschneidung sonst den Aktivitätsblock von 00:00 bis 08:00 Uhr des nächsten Tages (!) deaktiviert und nach Mitternacht keine Aktivitäten aufzeichnet. Wieso dies als „Überschneidung“ gilt und wieso eine solche Überschneidung in dem Fall nicht die klitzekleinste Warnmeldung aufpoppen lässt, wissen wohl nicht einmal die Entwickler …

Das Problem ist bekannt und den Arlo-Foren bereits mehrmals diskutiert: Scheduled mode setting all night sowie Schedule is active but after midnight, stops recording

Die Einstellungen macht man in der Kalenderansicht auf arlo.netgear.com unter Mode > Schedule. Bei mir schaut das beispielsweise so aus:

Tags: , , , , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 28. Oktober 2018

Eine der wichtigsten Programmier-Regeln: Input Validation

Link zu diesem Artikel

Among the errors here is casting an internal structure over external data. […] From a practical point of view, this leads to confusion, as the programmer is never quite clear as to the boundary between external and internal data. You are supposed to rigorously verify external data, because the hacker controls it. You don’t keep double-checking and second-guessing internal data, because that would be stupid. When you blur the lines between internal and external data, then your checks get muddled up.

Quelle: Systemd is bad parsing and should feel bad

Siehe dazu auch:

Input validation should happen as early as possible in the data flow, preferably as soon as the data is received from the external party.

OWASP: Input Validation Cheat Sheet

Tags: , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 18. Juli 2018

Auf chinesischen iPhones gibt es die Taiwan-Flagge nicht als Emoji

Link zu diesem Artikel

Patrick Wardle hat einer Bekannten geholfen, reproduzierbare Abstürze ihres iPhones zu debuggen.

Die Abstürze rührten von einem Bug in einer Routine her, welche nur Personen betraf, welche ihr iPhone in der chinesischen Lokalisation betrieben: Die Routine kümmert sich darum, dass iPhones mit dieser Landeseinstellung das Wort „Taiwan“ in Texten sowie die Taiwan-Flagge (Emoji) nicht anzeigen, sondern stattdessen mit einem rechteckigen, ein Kreuz enthaltendes Kästchen ersetzen (Bild):

A Remote iOS Bug. apple wrote code to appease the chinese government …it was buggy

Apple hat den Bug in der Routine in der Zwischenzeit behoben. Die Taiwan-Flagge kriegen solche Benutzer aber aus nachvollziehbaren Gründen immer noch nicht zu sehen: Apple möchte es sich mit seinem grössten Markt nicht verderben und zensiert seine Produkte freiwillig.

Wem die vertrackten geschichtlichen Hintergründe dieser Angelegenheit nicht klar sind, lese sich auf Wikipedia ein: Taiwan-Konflikt sowie als konkretes Symptom des Konflikts die Resolution 2758 der UN-Generalversammlung.

Nachtrag

Und jetzt flattert auch noch gerade diese Meldung bei mir rein:

China does not recognise any nation that has diplomatic relations with Taiwan – officially known as the Republic of China (ROC). Under the One China Policy, it does not consider the island nation be an independent country. The island has been self-ruled since its split from the mainland after the 1949 civil war.

Palau officially established diplomatic ties with Taiwan in December 1999.

Quelle: Airline says it shut down after China labelled Palau an ‘illegal destination’ over its Taiwan recognition

Tags: , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Freitag, 29. September 2017

iOS 11 bereitet meinem iPhone (und mir) Kopfschmerzen

Link zu diesem Artikel

Normalerweise warte ich bei Major-Releases von iOS jeweils die Version X.0.1 ab, bevor ich meinen Gerätepark auf die neue Version des mobilen Betriebssystems „lüpfe“. Diese Woche hielt ich mich nicht an meine eiserne Regel — unter anderem, weil die Medienberichterstattung nicht von gravierenden Problemen berichtete. Ein Fehler, der aber auch nicht mit Abwarten auf X.0.1 Linderung gebracht hätte.

Leider kämpfe ich auf meinem iPhone SE (Kaufdatum: April 2016) mit folgenden permanenten oder sporadisch auftretenden Problemen:

  • Das Gerät ist spürbar langsamer als unter iOS 10 — sowohl das Betriebssystem selber als auch die Applikationen. Wenn ich Podcasts höre und dann Applikationen öffne oder bediene, höre regelmässig verzerrtes Audio, als würde die Podcast-Applikation mit der laufenden Applikation um Systemressourcen kämpfen. Mit der Haptik und der Reaktion fühlt sich das UI eher wie Android als iOS an. Furchtbar! Derzeit tippe ich Probleme mit dem Netzwerkstack (Bauchgefühl, kann ich nicht belegen).
  • Das Thumbnail für soeben gemachte Screenshots wird einige Male nach einem Reboot des Geräts angezeigt, dann nicht mehr. Nach einer Weile macht das Telefon nicht nur kein Geräusch, wenn ich den Bildschirm abfotografiere, sondern das Thumbnail zur Nachbearbeitung wird auch nicht mehr angezeigt. Das Photo selber landet aber anstandslos im Photoalbum. Dabei wäre dies eine der besten Produktivitätssteigerungen mit diesem iOS-Release.
  • Heute verschwand die Statusanzeige (Empfangsstärke 4G/WiFi, Uhrzeit, Batterieanzeige) ganz oben am Bildschirm, wenn der Homescreen und alle anderen Springboard-Screens angezeigt wurde. In den Applikationen selber wurde die Statusanzeige ohne Probleme angezeigt. Ein Neustart behob das Problem.
  • Mail.app hängt regelmässig, wenn ich meine Mails über IMAP und Gmail abrufe. Das Spinning-Icon dreht und dreht, ohne dass die Unified INBOX je aktualisiert wird. Ich muss dann jeweils Mail.app gewaltsam schliessen und neu starten, damit die neuen Mails heruntergeladen werden.
  • Vor einigen Tagen zeigte Waze nach dem Start nur einen schwarzen Bildschirm an. Ich konnte die App nicht starten.
  • Die Sonos-App zeigt nach der Ankunft Zuhause während mehreren Minuten den Splash-Screen an, und stürzt dann urplötzlich ab.

Es bleibt zu hoffen, dass Apple der Ursache des Problems auf der Spur ist und bald mit X.0.2 Abhilfe schafft.

PS: Das Problem beschränkt sich nicht nur auf mein iPhone SE — meine Frau klagt auch mit ihrem iPhone 6s ebenfalls über spürbare Performanceprobleme.

Tags: , , , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 2. Juli 2017

Stockende Texteingabe in Web-Formularen mit hunderten HTML Input-Elementen unter Safari

Link zu diesem Artikel

Seit einigen Monaten (wahrscheinlich als Kollateralschaden eines Safari-Updates) habe ich ein Problem mit einer selber geschriebenen Web-Applikation: Die Eingabe von Zeichen in Textfelder eines Web-Formulars ist extrem langsam.

Zuerst verdächtigte eine veraltete jQuery-Bibliothek und onkeyup– und onblur-Attribute als Ursache, doch ein Update von jQuery hat keine Abhilfe geschafft.

Heute reichte es mir, und ich nahm erneut einen Anlauf, das Problem einzugrenzen. Eine Google-Suche förderte schnurstracks Probleme mit Safari unter iOS zu Tage, welche vor einigen Jahren bestanden (oder immer noch bestehen). Dies führte mich auf die Spur eines Stackexchange-Artikels, der identisches Verhalten auch in Safari unter macOS berichtete:

Safari on Mac responses slow when typing on a webpage with lots of <input type=“text”> fields

Das liess mich aufhorchen — denn die Applikation zeigt zwar nicht gerade hundert Eingabefelder an, doch in mehreren HTML-Tabellen werden alle Inhalte von Datenbank-Tabellen aufgelistet, woraus der Benutzer mit einem Klick auf einen Formular-Button den gewünschten Datensatz auswählen kann. Auf der Seite finden sich deshalb problemlos einige hundert input[button]-Elemente.

Könnte es sein, dass diese Elemente Safari spürbar langsamer machen? Ja!

Meine Lösung: Ich habe die Formular-Buttons in der Liste mit hinterlegtem JavaScript onclick mit HTML-Anchors ersetzt:

<a href="javascript:clicked();">wählen</a>

Seither fühlt sich der Browser wieder wie 2017 an, und nicht wie Netscape von 1998.

Tags: , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen

Mittwoch, 29. Juni 2016

StatusCake funktioniert mit Hostpoint nicht mehr

Link zu diesem Artikel

Vor einigen Monaten wurde ich durch die Ankündigung einer Preiserhöhung beim schwedischen Pingdom aufgeschreckt und sah mich deshalb etwas genauer auf dem Markt für Web-Site-Monitoring herum.

Fündig wurde ich beim us-amerikanischen StatusCake, welches kostenloses Monitoring einer unlimitierten Zahl an Web-Sites bietet — sofern man damit leben kann, das Checks nur alle fünf Minuten erfolgen. Im Nu hatte ich um die 50 Tests eingerichtet — von SSH, OpenVPN, PPTP über ordinäres HTTP/S bis hin zu Dashboards, welche Laufzeitdaten zusammenziehen und mich mittels von 200 abweichenden HTTP-Codes bei Problemen warnen.

Das Monitoring funktionierte wunderprächtig, bis Hostpoint letzte Woche damit begann, von Apache 2.2 auf Apache 2.4 zu migrieren:

Apache Update

21.06.2016, 00:00 Uhr – 31.07.2016, 00:00 Uhr

Wir aktualisieren derzeit auf sämtlichen Server die Apache Version von 2.2 auf 2.4. Dieses Update ist grösstenteils transparent, nur in den unten aufgeführten Szenarien muss eine Anpassung vorgenommen werden. Für das Update wird es eine Unterbrechung von wenigen Sekunden geben.

HTTP/2

Neu Unterstützen wir mit Apache 2.4 das Protokoll HTTP/2. Dieses steigert die Effizienz bei der Kommunikation zwischen Browser und Server: Mehr Durchsatz, mehr Parallelität, weniger Latenz. Vor allem moderne web-2.0-typische Webseiten mit vielen kleinen Resourcen profitieren davon. Voraussetzung für HTTP/2 ist eine TLS geschützte Verbindung (SSL Zertifikat). Dieses steht dank FreeSSL all unseren Kunden zur Verfügung.

…

Quelle: Hostpoint – Statusseite

Wahrscheinlich seit der Migration auf die neue Web-Server-Version meldete StatusCake für jede meiner bei Hostpoint gehosteten Web-Sites Folgendes:

StatusCake - Geschichtstage Down

Die konkreten Ausfallzeiten sind:

bibliothek-neuenegg.ch
2016-06-21 13:02:54 (Server: sl51.web.hostpoint.ch / s20)
sek-neuenegg.ch
2016-06-21 13:09:48 (Server: sl58.web.hostpoint.ch / s27)
geschichtstage.ch
2016-06-27 12:41:58 (Server: sl103.web.hostpoint.ch / s36)
ahc-ch.ch
2016-06-27 12:44:38 (Server: sl103.web.hostpoint.ch / s36)

Erste Anlaufstelle: Hostpoint

Zuerst dachte ich mir: Klarer Fall, da hat Hostpoint geschludert.

Ich kontaktierte dementsprechend deren Support am 28. Juni um 14:51 Uhr, um 17:22 Uhr erhielt ich die fachkundige Antwort von Jonas. Mittels eines Auszugs aus dem Domain Log legte er mir glaubwürdig dar, dass die StatusCake Probes den Server der Bibliothek Neuenegg bis heute alle fünf Minuten anpingen:

...
107.170.219.46 - - [28/Jun/2016:16:45:57 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
107.170.227.23 - - [28/Jun/2016:16:51:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
217.148.43.202 - - [28/Jun/2016:16:56:00 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
37.235.48.42 - - [28/Jun/2016:17:01:29 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
46.101.110.32 - - [28/Jun/2016:17:06:37 +0200] "GET / HTTP/1.1" 200 8770 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)"
...

Eine manuelle Kontrolle meinerseits zeigte, dass dies auch bei allen anderen oben genannten Servern der Fall war.

Der Web-Server antwortet auf die HTTP/1.1-Anfrage mittels des HTTP-Codes 200 und liefert 8770 Bytes an Daten zurück. Ein kurzer Test mit wget von soeben zeigt, dass das durchaus hinkommt (wget erhält „nur“ 8697 Bytes zurück, also ca. 100 Bytes weniger — dies auf Grund einer Anpassung im Inhalt der Homepage; sprich: vernachlässigbar):

$ wget bibliothek-neuenegg.ch
--2016-06-29 19:34:30--  http://bibliothek-neuenegg.ch/
Auflösen des Hostnamens »bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)« … 217.26.52.30
Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:80 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 301 Moved Permanently
Platz: https://bibliothek-neuenegg.ch/ [folgend]
--2016-06-29 19:34:31--  https://bibliothek-neuenegg.ch/
Verbindungsaufbau zu bibliothek-neuenegg.ch (bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »»index.html«« gespeichert.

index.html            [ <=>                ]   8,49K  --.-KB/s    in 0s      

2016-06-29 19:34:31 (49,4 MB/s) - »index.html« gespeichert [8697]

Zweite Anlaufstelle: StatusCake

Nun gut. Dementsprechend stellte ich alle wichtigen Infos zusammen, die einem Second-Level-Supporter nützlich erscheinen könnten und kontaktierte am selben Tag um 19:09 Uhr Schweizer Zeit den Support von StatusCake. Dan antwortete mir am folgenden Tag um 11:07 Uhr morgens, ging aber wie von us-amerikanischem Support-Personal gewohnt überhaupt nicht auf mein Anliegen ein. Stattdessen erhielt ich wohl einen Knowledge-Base-Artikel als Standardantwort:

We use a large global network of testing servers, it’s looking to me like you may need to whitelist our IPs on these servers, you can grab our full lists here – https://www.statuscake.com/kb/knowledge-base/what-are-your-ips/

9 Minuten später hatte ich ihm bereits geantwortet (wenn man einen Supporter schon mal „dran“ hat, sollte man ihn nicht mehr gehen lassen): Ich wies ihn darauf hin, dass die Apache Access Logs zeigen, dass die Server alle fünf Minuten Besuch von der Probe bekämen, Whitelisting also definitiv nicht das Problem sei.

Um 15:43 Uhr schrieb mir Dan zurück:

Had a look into this one. The only thing I can see that might be causing this is the introduction of HTTP/2, we don’t currently support this and will be giving a down result for any HTTP/2-only enabled sites.

Immerhin schien er die Status-Seite von Hostpoint aufgerufen und dort gelesen zu haben, dass HTTP/2 eingeführt wurde. Das wäre durchaus ein Ansatz, doch wieso taucht die Probe dann mit HTTP/1.1 in den Logs auf? Ich habe Dan zurückgeschrieben, doch bis jetzt ist noch keine weiterführende Antwort eingetrudelt. Ich bleibe dran!

Test mit wget

In der Zwischenzeit kam mir nun auch noch die Idee, dass der Web-Server vielleicht auf Grund des StatusCake User-Agents plötzlich meint, dass die Gegenseite fähig ist, HTTP/2 zu sprechen — und die Verbindung auf HTTP/2 upgradet.

Mit meinem lokal installierten wget probierte ich es aus:

$ wget --server-response --user-agent="Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.4 (KHTML, like Gecko) Chrome/98 Safari/537.4 (StatusCake)" https://www.bibliothek-neuenegg.ch/
--2016-06-29 19:47:56--  https://www.bibliothek-neuenegg.ch/
Auflösen des Hostnamens »www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)« … 217.26.52.30
Verbindungsaufbau zu www.bibliothek-neuenegg.ch (www.bibliothek-neuenegg.ch)|217.26.52.30|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 
  HTTP/1.1 200 OK
  Date: Wed, 29 Jun 2016 17:47:56 GMT
  Server: Apache/2.4
  X-Powered-By: PHP/7.0.7
  Set-Cookie: PHPSESSID=dbneu9nses8n52ge8i4esj72b1; path=/
  Expires: Thu, 19 Nov 1981 08:52:00 GMT
  Cache-Control: no-store, no-cache, must-revalidate
  Pragma: no-cache
  Upgrade: h2,h2c
  Connection: Upgrade, Keep-Alive
  X-Frame-Options: SAMEORIGIN
  X-Content-Type-Options: nosniff
  Keep-Alive: timeout=5, max=100
  Transfer-Encoding: chunked
  Content-Type: text/html; charset=utf-8
Länge: nicht spezifiziert [text/html]
Wird in »»index.html«« gespeichert.

index.html                   [ <=>                              ]   8,49K  --.-KB/s    in 0s      

2016-06-29 19:47:56 (30,9 MB/s) - »index.html« gespeichert [8697]

Wie man sieht antwortet der Hostpoint-Server brav mit HTTP/1.1 200 OK (wget spricht KEIN HTTP/2; hätte der Server also — nicht-standardkonform notabene — mit HTTP/2 geantwortet, hätte wget mir einen Fehler angezeigt.).

Dritte Reaktion: Hostpoint entdeckt Blog-Post

Heute (1. Juli 2016) trudelte kurz nach 11 Uhr morgens eine neue Nachricht zu meinem eigentlich als geschlossen geglaubten Support-Ticket bei Hostpoint ein: Jessica nahm Bezug auf meinen kürzlich veröffentlichten Blog-Artikel und teilte mir mit, dass die Angelegenheit intern noch einmal genauer angeschaut worden war. Sie war es, welche mir in diesem E-Mail den entscheidenden Hinweis gab:

StatusCake scheint NodeJS zu verwenden. Dieses hat einen Bug, wenn Apache einen Upgrade Header mitschickt. Dies ist HTTP-Konform und ist so korrekt.

Sie können die Details in folgendem Threads nachlesen:

NodeJS unable to make https requests when h2 enabled in Apache 2.4.18 #73
http: do not emit `upgrade` on advertisement #4337

Hostpoint hatte mit ein wenig Recherche herausgefunden, dass ältere Versionen von NodeJS HTTP/HTTPS-Verbindungen zu Web-Servern abbrechen, wenn dieser mit einer HTTP/2-Upgrade-Anforderung antwortet. Und irgendwie hatte Hostpoint weiter bemerkt, dass StatusCake höchstwahrscheinlich NodeJS für die Abfragen einsetzt.

Klasse, genau solches Debugging liebe ich an meinem Beruf so sehr — und umso mehr freut es mich, wenn sich Dienstleister in einen Bug verbeissen und alles tun möchten, um diesen zu beheben.

Ich bedankte mich bei Jessica und wendete mich anschliessend gleich Dan von StatusCake zu.

Vierte Reaktion: StatusCake

Da ich von Dan seit meiner Rückmeldung nichts mehr gehört hatte, antwortete ich erneut auf sein letztes Mail und beschrieb ihm auf Englisch die von Hostpoint vermutete Ursache hinter dem Problem. Ich hatte ehrlich gesagt nicht viel Hoffnung, dass ich jemals wieder von StatusCake hören würde (Kunde, der (noch) keinen Umsatz generiert, und mit komischen Problemen nervt) — doch ich täuschte mich auch hier.

Um 11:35 Uhr ging meine Anfrage an Dan raus, um 11:44 Uhr (innert 9 Minuten!) lag bereits seine Antwort in der INBOX. Und dieses Mal nichts aus der Büchse, sondern eine tatsächlich auf meine Anfrage Bezug nehmende Antwort.

Dies wahrscheinlich aus verschiedenen Gründen:

  • Ich teilte ihm mit, dass Hostpoint der grösste Hoster in der Schweiz sei
  • Ich erwähnte NodeJS
  • Ich erwähnte die Nachricht von Jessica von Hostpoint und fügte die Links auf die NodeJS-Bugs ein
  • Ich erwähnte, dass auf Grund der weltweit laufenden Upgrades auf Apache 2.4 dieses Problem exponentiell zunehmen würde

Dan schrieb mir:

[…] this has been escalated to our engineers. We are working on this and we will have it sorted asap, it’s a big job so you’ll appreciate that the resolution will not be instant. Sorry if I wasn’t great at troubleshooting this at first – the results we were seeing did not make sense.

Dann warten wir also geduldig, bis StatusCake ihre NodeJS-Installation upgegradet hat …

Tags: , , , , , , , , , , ,
Labels: IT, Web

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 7. Oktober 2012

Syntax eines PHP-Scripts auf der Kommandozeile überprüfen

Link zu diesem Artikel

Nicht immer produziere ich auf dem lokalen Mac Code in einem Verzeichnis, welches über den lokalen Web-Server angesprochen werden kann. Wenn ich den Code auf den Server des Kunden kopiert habe und mir dort eine gähnende Leere entgegenblickt, ist die Vermutung in der Regel ein Syntax-Problem, welches den PHP-Parser zum Abbruch bewegt. So genau weiss man das natürlich nicht, da man als guter Entwickler display_errors auf einem Produktivsystem auf 0/off/false gesetzt hat und Fehlermeldungen nur in das error_log ablegt.

Entweder öffnet man das error_log via FTP, oder aber man lässt die Syntax auf dem Mac selber von der Kommandozeilenversion von PHP überprüfen:

php -l <Pfad zum syntaktisch defekten PHP-Script>

Dies führt entweder zur Absolution mit

No syntax errors detected in <Pfad zum syntaktisch defekten PHP-Script>

oder aber im unglücklicheren Fall zur folgenden oder ähnlichen Fehlermeldung:

Parse error: parse error in <Pfad zum syntaktisch defekten PHP-Script> on line 146
Errors parsing <Pfad zum syntaktisch defekten PHP-Script>

Tags: , , , , ,
Labels: Programmierung

Keine Kommentare | neuen Kommentar verfassen

Samstag, 25. Februar 2012

youtube-dl meldet „no fmt_url_map or conn information found in video info“

Link zu diesem Artikel

Wer Youtube-Videos auf seinen Rechner herunterladen möchte, um sie später ohne Internetverbindung anschauen zu können, wird das Python-Script youtube-dl längst kennen.

Wenn das Ding aber den Fehler

$ ~/youtube-dl.sh http://www.youtube.com/watch?v=QhhFQ-3w5tE
[youtube] Setting language
[youtube] QhhFQ-3w5tE: Downloading video webpage
[youtube] QhhFQ-3w5tE: Downloading video info webpage
[youtube] QhhFQ-3w5tE: Extracting video information
ERROR: no fmt_url_map or conn information found in video info

meldet, sollte man sich den Fork von Philipp Hagemeister herunterladen, welcher den Bug behebt:

youtube-dl (Philipp Hagemeisters Fork)

Youtube-Video als MP3 herunterladen

Wenn wir gerade dabei sind: Wer obiges Tool einsetzt, sollte auch zwingend nachfolgende Web-Site kennen, welche Youtube-Videos in MP3-Dateien umwandelt:

www.youtube-mp3.org

Tags: , , , , ,
Labels: Linux

2 Kommentare | neuen Kommentar verfassen

Dienstag, 18. August 2009

Microsoft schiesst wieder mal den Vogel ab

Link zu diesem Artikel

The bug caused one of our customers to get different business reports depending on whether anyone had started up MS Paint during the data analysis.

Quelle: FYI: Not so funny Microsoft bug that hosed our company’s product because a „function randomly returns incorrect results“. : reddit.com

Tags: , ,
Labels: Funny

Keine Kommentare | neuen Kommentar verfassen