(38.7 MB) 00:06:35
2014-06-15 01:20 🛈Mehr kommt aus Getreide und der Mühle, Wasser aus Quellen, Salz durch verdunstendes Wasser – doch wo kommt die Hefe her? Wilde Hefe, auch Sauerteig genannt, kann man selbst züchten.
Meine Lieblingsbeschäftigung :)
(38.7 MB) 00:06:35
2014-06-15 01:20 🛈Mehr kommt aus Getreide und der Mühle, Wasser aus Quellen, Salz durch verdunstendes Wasser – doch wo kommt die Hefe her? Wilde Hefe, auch Sauerteig genannt, kann man selbst züchten.
(31.7 MB) 00:18:30
2014-06-14 23:40 🛈100 Folgen BitBastelei, 21 Stunden Bastelspaß und mit allen anderen Formaten mehr als 200 Videos – in den letzten 4 Jahren ist mein Podcast doch etwas gewachsen – weit mehr, als ich es für möglich gehalten hätte. Wie versprochen antworte ich hier auf eure Fragen. Neben der unausweichlichen Werkbank-Tour habe ich noch etwas besonderes zum „Fest“: Zur 100. Folge werde ich heute, beginnend ab Mitternacht, alle 100 Minuten ein neues Video veröffentlichen. Großteils ist es zwar Material, welches durch meine Faulheit schon etwas eingestaubt ist, aber es sind auch etwas ungewöhnliche Themenfelder für mich dabei. Lasst euch überraschen.
Ich danke allen, die Interesse an meinen Projekten zeigen und durch ihr Zuschauen und Kommentare mir immer wieder die nötige Motivation geben meine Basteleien in dieser Form zu dokumentieren – auf weitere 100 Folgen!
(39.3 MB) 00:10:40
2014-06-14 22:01 🛈Datenblatt/Spannungsumbau: http://www.digole.com/index.php?productID=458
USB Charging Specification: http://www.usb.org/developers/devclass_docs
USB Charging – Erklärung von Julian Ilett: https://www.youtube.com/watch?v=iJMX6THgPRE
(7.7 MB) 00:01:37
2014-06-11 10:00 🛈Vor einiger Zeit hatte ich gezeigt wie man aus IC-Schaum einen Stift für kapazitive Touchscreens von Handys und Tablets bauen kann (https://www.youtube.com/watch?v=JjDLnSlB7-c). Es geht aber auch einfacher:
Ein alter Permanentmarker mit Metall-Gehäuse kann ohne basteln direkt als Touchscreen-Stift verwendet werden!
(23.3 MB) 00:18:11
2014-06-08 10:00 🛈(Manuelle) Installation des Volkszähler-Backends unter Debian Linux
Korrektur: Debian liefert zur Zeit PHP 5.4 aus, der Opcode-Cache ist erst ab PHP 5.5 verfügbar, APC wäre in diesem Setup also noch sinnvoll.
Passend dazu: BitBastelei #98 – Installation von Debian 7.5
(36.8 MB) 00:02:46
2014-06-05 10:00 🛈„Auch nach Gebrauch nicht gewaltsam öffnen“ – aber seit wann höre ich auf die Anleitung?
(40.1 MB) 00:04:25
2014-06-03 10:00 🛈Heute bringt der Postbote: Einen Stapel HD44780-LC-Displays
In einem vorherigem Video hatte ich mich über die Verwendung des als unsicher eingestuften RC4-Algorithmus bei eBay ausgelassen – heute erhielt ich eine Antwort auf die Nachfrage:
Guten Tag Herr Knodt,
vielen Dank für Ihre Nachricht, in der Sie uns Ihre Bedenken bezüglich der RC4 Verschlüsselung mitgeteilt haben.
Bedingt durch eine unerwartet hohe Anzahl von Mitgliederanfragen konnten wir unsere Antwortzeiten nicht wie gewohnt einhalten. Da wir Ihren Anfragen und Hinweisen in jedem Fall gründlich nachgehen, hoffen wir auf Ihr Verständnis und bitten Sie um Entschuldigung für die Verzögerung.
Nun zu Ihrem eigentlichen Anliegen:
Ich habe Ihr Anliegen an die zuständige Abteilung weitergeleitet. Sehr gern gebe ich Ihnen nun weitere Informationen.
Aufgrund den Rückmeldungen unserer Nutzer ist eBay bereits am prüfen der Verwendung von RC4 Verschlüsselung. Sollte es einer Änderung bedürfen wird eBay diese zeitnah umsetzen.
Da diese evtl. Änderung einer globalen Änderung bedarf können wir leider keinen Zeitpunkt nennen wie und wann eine Änderung erfolgen wird.
Für Ihre Geduld und Verständnis danke ich Ihnen im Voraus und wünschen Ihnen, dass Sie eBay nun sorglos nutzen können.Mit freundlichen Grüßen nach Saffig
Aletta Sonnenschein
eBay-Kundenservice
Nun, ohne Änderung sorglos nutzen ist etwas optimistisch, aber offenbar ist das Thema bereits angekommen und wird „geprüft“ – mal schauen, ob und wann hier eine Besserung eintritt.
(14 MB) 00:14:44
2014-06-01 10:00 🛈Für ein Projekt benötige ich ein kleines, möglichst wartungsarmes Linux-System – was eignet sich da besser, als „good, old“ Debian? Hier wird eine Grundinstallation des Systems durchgeführt.
Wer in den letzten Wochen auf meinem Blog unterwegs war hat es eventuell gemerkt: Irgendwie war das Ganze etwas zäh. Jeder Aufruf dauerte mindestens 5 Sekunden – nur warum?
Also gehen wir die große Frage an: Was ist der Auslöser. Frage einfach, Antwort kompliziert. Erster Anlaufpunkt: das Netz. Um zu prüfen, dass das Problem wirklich am Server und nicht am Netzwerk liegt wird die Seite lokal aufgerufen:
time wget -O - https://adlerweb.info/ > /dev/null
[…]
real 0m5.488s
[…]
Danke, keine weiteren Fragen, am Netz liegt es nicht. Wenn wir aber schon mal da sind rufen wir auch einen statischen Inhalt auf – nehmen wir z.B. einfach mal ein Bild:
time wget -O - https://adlerweb.info/blog/wp-content/uploads/2014/05/header-2014.png > /dev/null
[…]
real 0m0.017s
[…]
Aha – der statische Aufruf funktioniert zügig, damit wäre ein Fehler des Webservers selbst eher unwahrscheinlich. Der PHP-Interpreter oder die Anwendung scheint also Auslöser zu sein. Testen wir mal eine „rohe“ PHP-Datei. Reines echo.
time wget -O - https://adlerweb.info/test.php > /dev/null
[…]
real 0m0.007s
[…]
Somit wäre auch der PHP-Interpreter raus – es kann also eigentlich nur noch WordPress sein, oder? Nunja, ein reines WordPress auf selbem Server ist da anderer Meinung:
time wget -O - https://adlerweb.info/wptest/ > /dev/null
[…]
real 0m0.895s
[…]
Deutlich langsamer als der Testcode, aber es sind ja auch ein paar Zeilen mehr – eine Sekunde ist aber imo noch erträglich. Also muss irgendwas in der Seite den Fehler verursachen – Plugins, Themes, Anpassungen. Viele Kandidaten.
Erster Versacht: Meine Solarstatistiken. Diese müssen sich erst durch meinen heimischen Anschluss quetschen und der ist nicht gerade der schnellste. Statistik aus, aber trotzden: 4.925s. Kein Wunder: Es sind ja nur wenige Zeichen Text und spätestens beim zweiten Aufruf wären sie im Cache des Servers. Also weiter geht die Deaktivierungsorgie, aber mit Nachbrenner.
Um herauszufinden ob ein Plugin oder sonstiger Code das Problem verursacht wandern alle Plugins temporär aus dem WordPress-Ordner in ein temporäres Verzeichnis. Bingo: Ohne Plugins lädt die Seite in gerade mal 0.265s – suchen wir den Schuldigen. Plugin für Plugin wird dieser eingerichtet, dabei stechen einige hervor:
– apc: +1,2 Sekunden
– wp-slimstat +0,3 Sekunden
APC war früher als Cache im Einsatz, heute ist das Plugin im Backend deaktiviert, aber durch einen damals nötigen Symlink werden offenbar trotzdem Teile des Plugins geladen. Die Ladezeit steigt dabei offenbar mit der Codegröße – wenn mehr andere Plugins geladen sind erhöht sich die Ladezeit mit APC prozentual. Wie schon gesagt: Historie – kurze Sache: Weg damit.
WP-Slimstat ist ebenfalls etwas auffällig, wenngleich weit entfernt von der Bremswirkung des vorherigen Kandidaten. Slimstat sah mir nach einer guten Idee aus – der Webserver anonymisiert bereits die IPs, entsprechend kann ich hiermit lokale & anonyme Statistiken generieren. Den Performance-Impact hatte ich mir allerdings nicht ganz so groß vorgestellt, als Alternative hat sich jetzt WordPress Statistics von Mostafa Soufi eingefunden – mit diesem Plugin kann ich keien messbare Verschlechterung feststellen.
Ergebnis des Frühjahrsputzes (a2b, 100 Requests, 10 Parallel):
Vorher: Ohne APC: Andere Stats 100 Requests 100 Requests 100 Requests 146.809 seconds 24.047 seconds 14.385 seconds 6282600 bytes 6282600 bytes 6240100 bytes 42.08 Kbytes/sec 256.91 Kbytes/sec 426.60 Kbytes/sec =================== ================== ================== 1468.093 ms/Request 240.471 ms/Request 143.846 ms/Request 0.68 Requests/sec 4.16 Requests/sec 6.95 Requests/sec
Durch löschen des alten Plugins konnte die Ladezeit um 83% gesenkt werden – mit neuem Statistikplugin waren sogar weitere 7% Reduktion möglich. Ein zehntel der Ladezeit – nicht schlecht für eine eigentlich so kleine Ursache…
Wir lernen: Man sollte öfter mal aufräumen, nicht mehr verwendete Plugins auch aus dem Dateisystem entfernen und Plugins vor der Nutzung vergleichen…