Jesienne tło na telefon

Wczoraj byłem na Cytadeli na spacerze z rodziną. Taka jesienna wycieczka. Nawet ładna jesień i trochę słońca. Stwierdziłem, że zrobię sobie tapetę na telefon. Coś prostego, jesiennego. Oczywiście telefonem.  Pierwotnie myślałem o drzewie na tle nieba, ale… fota/ujęcie może ładna, ale na tapetę się zdecydowanie nie nadaje – za jasne, napisy i ikony giną.

Postanowiłem zrobić coś, co zawsze wychodzi – jednolita mozaika, w tym przypadku liście. Oryginał wyglądał tak (wyświetla się pomniejszony, rozmiar jest oryginalny):

Liście jesień tapeta

Źródło: fot. własna

Tapeta całkiem przyjemna, ale… nadal za jasno i białych napisów nie widać. Ale efekt na zablokowanym ekranie był naprawdę fajny, więc postanowiłem pobawić się chwilę w Gimpie. Balans bieli plus lekka zabawa z kolorami (nie znalazłem prostego ściemnij) plus zabawa z kompresją (zupełnie nie oszczędzałem) i ostateczny efekt wygląda tak:

Jesień tapeta wersja ostateczna

Źródło: fot. własna

Daje się używać jako tapeta na telefonie, napisy widać, ale nadal mogło by być ciut ciemniejsze. Póki co zostaje w tej wersji.

Żegnaj Twitterfeed, witaj dlvr.it!

Serwis Twitterfeed.com (nie linkuję, bo pewnie zaraz dead link będzie) ogłosił, że z końcem bieżącego roku kończy działalność. Zamknięcie wzorowe – jest dużo wcześniej, jest komunikacja mailowa i informacja na stronie. W mailu są wskazane alternatywy (buffer.com i dlvr.it).

Rzuciłem okiem na strony polecanych serwisów i stwierdziłem, że przenoszę się na ten drugi serwis. Strona wyglądała zachęcająco – wszystko przejrzyste, logicznie poukładane i dobrze opisane, więc się zarejestrowałem.

Pierwszy zgrzyt – wystarczy podać maila i hasło, by założyć konto w serwisie. Żadnego potwierdzania rejestracji mailem, klikania w URL. Z jednej strony fajnie, bo szybciej i łatwiej – klik, klik i już możemy dodawać feed. Z drugiej nawet hasła nie trzeba podawać dwa razy – ciekawe ile drugich logowań zaczyna się od przypomnienia hasła.

Drugi zgrzyt – podanie URLa do feedu, rozpoznanie i… wykryty tytuł to Pomiędzy bitami Hell, yeah, XXI w. Na szczęście tytuł można edytować (co nie jest standardem). Zobaczymy co będzie z treścią… Oczywiście to poniekąd wina Blox, który nadal nie korzysta z UTF-8, ale charset jest poprawnie zadeklarowany…

Trzeci zgrzyt – skracanie URLi nie jest już tak fajne jak kiedyś. IIRC Twitterfeed.com pozwalał na dodanie bit.ly tak po prostu. w dlvr.it nie ma tak dobrze. Bit.ly można dodać, ale tylko po zalogowaniu, a nie przypominam sobie, bym kiedykolwiek zakładał tam konto. Ani rejestrować się tam nie chcę. Więc chwilowo wszystkie jajka blogowo-twitterowe lądują w jednym koszyku z napisem dlvr.it. Dobrze, że nie potrzebuję tego jakoś poważniej…

W każdym razie pora na test. Ten wpis powinien pojawić się na Twitterze dwa razy – po staremu i po nowemu. I zobaczmy jak to wygląda w praktyce…

Goodbye lighttpd

Do niedawna korzystałem na prywatnych gratach z lighttpd jako serwera WWW. Lekki, fajny, składnia pliku konfiguracyjnego powiedzmy perlowa, działał. Niby wszystko OK, ale… raczej nie jest wykorzystywany w różnych nowych projektach, jeśli ktoś daje narzędzia czy instrukcje, to raczej można się nie spodziewać znalezienia wersji dla lighttpd.

W międzyczasie troche bliżej miałem okazję zetknąć się z nginx i zrobił na mnie bardzo dobre wrażenie – dla kilku vhostów bardziej przejrzysty konfig, nieźle wspierany w dokumentacji różnych projektów (apache to to nie jest, ale jest dobrze). Gwoździem do trumny dla lighttpd okazał się brak wsparcia dla HTTP/2, a nawet brak planów w tym zakresie. I łatwość włączenia obsługi HTTP/2 na nginx – wystarczy jedna dyrektywa w pliku konfiguracyjnym (przy odpowiednio nowej wersji nginx – jest w backportach debianowych). Trochę na zasadzie „wykorzystać, nie wykorzystać, możliwość mieć można”.

Nic dziwnego, że pojawił się pomysł przesiadki na prywatnych gratach z lighttpd na nginx. Brakowało motywacji, bo po pierwsze istniejąca wersja działała, po drugie konfiguracja była lekko zakręcona, po trzecie brak czasu. Ostatecznie któregoś razu zebrałem się, wymyśliłem, że uruchomię oba serwery WWW równolegle, na różnych portach i zrobię szybki benchmark lighttpd vs nginx. Który to benchmark oczywiście wykaże, że nginx jest szybszy i potwierdzi słuszność przesiadki[1]. 😉

Jak już się zebrałem, to okazało się, że w sumie nie ma aż tak wielu rzeczy skonfigurowanych, a z wielu można/wypadałoby zrezygnować. Głównym wyzwaniem okazało się skonfigurowanie nginx tak, żeby HTTP słuchało na niestandardowym porcie i jednocześnie przekierowywało na HTTPS, również na niestandardowym porcie. Znalazłem rozwiązanie, ale machnąłem ręką – dziwne, nieprzystające do normalnego konfiga, a przydatne tylko na moment, przy benchmarku. Za to przydać się może ładny gotowiec do przekierowań z wersji z www na bez www i odwrotnie.

Przy okazji instalacji SSL dowiedziałem się, że w końcu istnieje oficjalna paczka z klientem Certbot dla certyfikatów SSL od Let’s Encrypt w Jessie (trzeba skorzystać z backportów). Plus, strona daje gotowe instrukcje instalacji dla popularnego oprogramowania (znowu: nginx jest, lighttpd nie ma). Czyli w certyfikatach też został zrobiony porządek. Dla pamięci: znalazłem stronkę z gotowcem, jak uzyskać A+ na popularnym teście SSL. Nieco przestarzała, ale nadal przydatna.

W zasadzie poszło zaskakująco dobrze, najwięcej niespodzianek wyszło na rzeczach najprostszych – a to serwer nie kompresował treści (tu jest o włączaniu kompresji), a to był problem z przetwarzaniem skryptów PHP. W końcu jest sensowna obsługa haseł na dostęp do stron (ew. miałem to wcześniej zrobione słabo).

Z rzeczy, które powinny działać, a nie działają – HTTP/2. Nie wiem, czy bardziej kwestia konfiguracji, wersji nginx, czy Firefoksa, ale wg testu HTTP/2 działało, a w Firefoksie (i na niektórych testach, zapewne korzystają z Firefoksa) strona się nie otwierała. Na innych przeglądarkach działało OK, ale do czasu rozwiązania problemu wyłączam HTTP/2.

Ponieważ wygląda, że publiczne motywatory działają: następna w kolejce jest przesiadka z chronicle na pelican na Wattmeter. Robi dobre wrażenie i jest w Pythonie. 😉

[1] Na przykładzie strony nextbike.tk i prostego testu przy pomocy ab -n 2000 -c 20 okazało się jednak, że różnicy większej niż błąd pomiaru nie ma. Być może kwestia wielkości małej wielkości pliku i narzutu na transmisję, być może kwestia obciążenia serwera, konfigi serwerów też nie były ani identyczne, ani optymalizowane. W każdym razie dla mnie szybciej nie będzie.