[Mini] Bug iTunes/iPod

Miałem już dziś nie spamować więcej, ale w sumie dlaczego nie? Już nie wiem który raz widzę tego typu bug iTunes i mojego iPoda Nano. Jakby ktoś miał wątpliwości to obie widoczne pozycje są w rzeczywistości dwoma osobnymi plikami (widać po liczbie odtworzeń choćby), tylko oprogramowanie od Apple ma ciekawe kryterium tego, jaki utwór jest obecnie odtwarzany.

Bug iTunes

PS: Wpisy nie będą się codziennie pojawiać z taką częstotliwością, bo wiadomo jak wygląda sprawa z moją motywacją, ale niewątpliwie będzie ich więcej niż obecnie. Nie przeszkadza Wam taka ilość małych wpisów? Może chcecie aby w jakiś sposób oddzielić takie małe pierdółki od reszty bloga (choćby przez osobny kanał RSS)?

PS2: Tak, to kryptoreklama Tima Minchina, polecam :D

[Mini] Kolejna reorganizacja na blogu

Będzie tym razem krótko, bo i tak już połowa tego bloga to pisanie o nim samym (metablogowanie?). Sprawa pierwsza: kategorie "Komputery" i "Internet" zostały zamienione na jedną kategorię o nazwie "Technologia", bo moim zdaniem poprzedni podział był sztuczny i niewygodny dla mnie. Oczywiście nadal zostają kategorie takie jak PHP/SQL/HTML&CSS - kategoria "Technologia" to po prostu miejsce na inne techniczne rzeczy.

Sprawa druga: w związku z małą ilością treści na blogu, zmieniam troszkę podejście. Będzie pojawiać się więcej wpisów krótkich, dotyczących prostych porad lub pojedynczych wizji w mojej chorej głowie. Będą one poprzedzone prefixem [Mini] tak jak ten.

Pozdrawiam.

[Mini] Czym jest i jak działa plik .gitkeep?

Być może miałeś okazję zobaczyć taki plik w kilku repozytoriach Git i zastanawiałeś się czym on jest. Podstawowa znajomość angielskiego pozwala stwierdzić, że będzie on czymś w rodzaju pliku .gitignore - wewnętrznym plikiem przekazującym jakieś informacje gitowi.

Rolą pliku .gitkeep jest spowodowanie aby dany folder był wysłany do repozytorium nawet gdy nie zawiera żadnych innych plików - git bowiem pomija puste foldery przy commitowaniu. Teraz uwaga: plik nie jest w żaden sposób częścią standardu - jest to nazwa umowna - plik na dobrą sprawę może być dowolnym innym (pustym bądź nie) plikiem, jest on potrzebny aby Git uwzględnił zawierający go folder w repozytorium. Wprowadzenie jakiejś określonej nazwy pozwala po prostu zorientować się czym jest plik, po samej jego nazwie.

Tak więc podsumowując jakby ktoś nie zrozumiał: folder pusty nie jest "widziany" przez Gita, tak więc dodaje się do takich folderów puste pliki o dowolnych nazwach, żeby zmienić to zachowanie. Kilka osób umówiło się natomiast, że .gitkeep to dobra nazwa, bo nawiązuje konwencją do .gitignore - faktycznego pliku konfiguracyjnego no i mówi nam nazwą o co w pliku chodzi.

[WordPress] Pobieranie ilości i treści zapytań oraz czasu generowania strony

Często zachodzi potrzeba sprawdzenia tego, jak wygląda czas generowania naszej strony lub ile generuje ona zapytań do bazy danych. Pomijając tutaj użycie profilerów (choćby ze względu na brak dostępności na większości hostingów) pokażę jak uzyskać takie informacje w skrypcie Wordpress.

Pobieranie ilości zapytań
Aby uzyskać ilość zapytań wykonanych do bazy przez Wordpressa należy skorzystać z funkcji get_num_queries() - zwraca ona liczbę tylko liczbę wykonanych zapytań. Przykład użycia pokażę na końcu wpisu.

Pobieranie listy zapytań
Pobranie samej treści wykonanych zapytań jest już lekko trudniejsze. Należy zacząć od zdefiniowania jednej stałej w pliku wp-config.php. Gdzieś w nim (można to zrobić np. po stałej WP_DEBUG) należy umieścić następujący zapis.

define('SAVEQUERIES', true);

W tym momencie Wordpress zacznie logować informacje na temat wszystkich wykonanych przez siebie zapytań. Aby je wyświetlić możemy użyć kodu oferowanego przez oficjalną dokumentację WP:

<?php
if (current_user_can('administrator')){
  global $wpdb;
  echo "<pre>";
  print_r($wpdb->queries);
  echo "</pre>";
}
?>

Zasada działania jest prosta: jeżeli dany użytkownik ma uprawnienia administratora, to pokaże się dump tablicy wielowymiarowej zawierającej informację o zapytaniu. Na każde zapytanie składają się trzy klucze. Pierwszy określa treść zapytania, drugi: czas jego wykonania, a trzeci mówi o tym jak po kolei wyglądała droga do wykonania tego zapytania (dołączane pliki i wywoływane funkcji).

Jeżeli jednak, tak jak ja, nie potrzebujecie aż tak szczegółowych informacji o każdym zapytaniu, możecie użyć takiego kodu:

<?php
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";
?>

Ten kod pokazuje jedynie treść wykonanych zapytań. Uwaga: ja używam tego kodu do wsadzenia tej informacji w HTML-owy komentarz. Jeżeli chcecie wyświetlić to na stronie, to pamiętajcie o zamianie nowej linii na br. Oczywiście można dodać sprawdzanie uprawień użytkownika, aby takie informacje udostępnić tylko dla administratorów (to wskazane posunięcie!).

Pobieranie czasu generowania strony
Do pobrania czasu generowania strony opartej na WP służy funkcja timer_stop(). Przyjmuje ona dwa parametry, pierwszy określa czy wartość ma być wyświetlona (1), czy zwrócona (0; ustawienie domyślne). Drugi określa zaś precyzję, czyli ilość cyfr po przecinku w czasie generowania (domyślnie 3). Przykład użycia za chwilkę.

Sprawdzanie ilości użytej pamięci
Tutaj skorzystamy już z wbudowanej w PHP funkcji memory_get_usage(). Zwraca ona wynik w bajtach, tak więc dla lepszej czytelności zatroszczymy się o przeliczenie na megabajty.

<?php echo number_format(memory_get_usage()/1024/1024, 2); ?>

Drugi parametr funkcji number_format() także określa liczbę miejsc po przecinku.

Kompletny przykład
Oto przykładowa implementacja powyżej pokazanych rozwiązań.

<!--
Zapytania: <?php echo get_num_queries();
global $wpdb;
foreach ($wpdb->queries as $query) 
  echo $query[0]."\n";  ?>
Czas generowania: <?php timer_stop(1, 2); ?>s
Użyta pamięć: <?php  echo number_format(memory_get_usage()/1024/1024, 2); ?>MB
-->

I to by było na tyle. Mam nadzieję, że przedstawione rozwiązanie do czegoś się Wam przydało. Pamiętajcie też, że po skończonym debugu lepiej jest usunąć stałą SAVEQUERIES z konfiguracji lub przestawić ją na false, gdyż włączenie opcji logowania zapytań zwiększa zużycie zasobów.

[PHP] Wyłączanie komunikatów notice

Problem stary jak świat. Po odpaleniu aplikacji (często na innym serwerze) wyskakuje szereg komunikatów typu notice (podkreślmy od razu bardzo ważną rzecz: notice to nie błąd). W tym wypadku przedstawiane są dwie szkoły: jedna mówi, że aplikacja nie powinna generować żadnych komunikatów, a druga uznaje, że skoro notice błędem nie jest, to może wystąpić, bo to tylko informacja dla programisty. Niezależnie od tego, którą z nich wyznajemy, ukrycie notice (jak i  błędów) jest konieczne w środowisku produkcyjnym, ze względów bezpieczeństwa.

Wykonanie tego zadania sprowadza się do dodania jednej linijki gdzieś na początku pliku PHP.

<?php
error_reporting(E_ALL ^ E_NOTICE);

To sposób jednorazowy/doraźny. Jeżeli chcemy załatwić sprawę na stałe i mamy taką możliwość to po prostu edytujemy plik php.ini i tak jak wyżej zmieniamy wartość dyrektywy error_reporting na E_ALL ^ E_NOTICE.

PS: Wiem, ze problem jest oklepany, ale będzie gdzie odsyłać kolejnych ludzi mówiących o "błędach notice".

Jak (dobrze) umieścić komunikat o cookies

Sobak, jako wybitny specjalista w dziedzinach accessability, usability i innych –ity ma dla Was najnowszą super-wypasioną poradę przydatną w dzisiejszych czasach. Będzie ona dotyczyć… cookies. Małych, niewinnych ciasteczek, które od maja tego roku zostały skazane na bycie piętnowanymi przez Unię Europejską miłościwie nam panującą.

Mam ja krótkie pytanie: dlaczego prawie nikt nie umieścił komunikatu o cookies na dole strony bez fixed? Najczęściej widuję strony, które taki komunikat mają przyczepiony na górze. Dosyć rzadko dzieje się tak, że po przewinięciu w dół komunikat zostaje na górze (czyli po prostu nie ma fixed). Wiele stron zdecydowało się umieścić taki komunikat na dole, jednak w takim rozwiązaniu mamy permanentnie ucięte kilkanaście pixeli z dołu strony.

Natomiast zestaw, do którego chciałbym Was przekonać, czyli informacja umieszczona na dole strony i nie przylepiona do dołu ekranu na fixed, mimo że zdaje mi się najlepszy, widziałem raptem na kilku stronach WWW (choćby Google/Youtube czy Forumweb). Dlaczego takie rozwiązanie jest wg mnie najlepszym wyjściem? Przede wszystkim nie zabieramy na stałe przestrzeni z ekranu. Komunikaty z fixed rezerwują sobie nieraz wiele przestrzeni i dopóki użytkownik ich nie zamknie będą wędrować z nami podczas czytania strony. Komunikat umieszczony na dole może być przeczytany przez użytkownika po zobaczeniu tego, po co przyszedł na stronę. To przecież nie informacja o ciasteczkach jest dla niego najważniejsza.

Dlaczego więc webmasterzy tak bardzo upodobali sobie inne formy? Zwięzłą i bardzo ciekawą analizę przedstawił logeen na Forumweb.pl. W skrócie: jako pierwsze komunikat o cookies wprowadziły witryny rządowe. Webmasterzy, a raczej ich zleceniodawcy pod natłokiem całego szumu jaki wywołała zmiana prawa uznali strony rządowe za dobry wzorzec i gwarancję zgodności ze znowelizowaną ustawą ("to nie może być złe bo tak robi strona prezydenta/premiera etc").

Tymczasem przedstawione przeze mnie rozwiązane w żaden sposób nie narusza ustawy Prawo Telekomunikacyjne. Ustawa o samym komunikacie mówi jedynie, że ma być on jednoznaczny, bezpośredni i zrozumiały dla użytkownika.

abonent lub użytkownik końcowy zostanie uprzednio jednoznacznie i bezpośrednio poinformowany, w sposób łatwy i zrozumiały

W związku z tym porada na dziś będzie taka: nie marnujcie miejsca na monitorach Waszych czytelników, nie marnujcie ich uwagi na czytanie tego samego komunikatu po raz kolejny. Odpowiednia wzmianka w stopce spokojnie wystarczy.

Spotify - nowe ograniczenia w pakiecie Free

Dziś dostałem następującą wiadomość email od Spotify:

(...) Chcielibyśmy Cię poinformować, że w dniu 12 sierpnia 2013 r. zostały wprowadzone zmiany Ogólnych Warunków Umownych Korzystania z Serwisu Spotify, w szczególności odnoszące się do Bezpłatnej Usługi. Możesz zapoznać się z nowymi Ogólnymi Warunkami Serwisu Spotify. (...)

Po zajrzeniu do podlinkowanego regulaminu potwierdziłem swoje przypuszczenia. Serwis wprowadził kolejne limitacje dla darmowego pakietu. Przechodząc od raz do sedna, po udaniu się do odpowiedniego punktu FAQ możemy ujrzeć następującą informację:

Nieograniczone odtwarzanie strumieniowe przez 6 pierwszych miesięcy Gdy utworzysz swoje konto Spotify, przez sześć pierwszych miesięcy będziesz mieć możliwość nieograniczonego przesyłania strumieniowego muzyki w ramach konta Spotify Free. Po tych sześciu pierwszych miesiącach pojawią się pewne ograniczenia czasu odtwarzania.

Ile muzyki można odtwarzać strumieniowo Zaczynając od 10 godzin, Twoje konto będzie otrzymywać co tydzień przydział 2,5 godziny odtwarzania strumieniowego. Niewykorzystany czas w danymi tygodniu jest sumowany. W ten sposób czas odtwarzania strumieniowego może być sumowany do maksymalnie 10 godzin.

Czas odtwarzania strumieniowego jest co tydzień dodawany do Twojego konta – tego samego dnia tygodnia, w którym zostało utworzone Twoje konto Spotify, mniej więcej o tej samej porze dnia.

Analizując szybko podane informacje: limity dotkną nas po 6 miesiącach od założenia konta. Będziemy mogli słuchać do 2,5h muzyki tygodniowo (limit nie dotyczy oczywiście muzyki znajdującej się lokalnie na naszym komputerze, a jedynie dodanej do Spotify). Niewykorzystany czas będzie sumowany (aby wykorzystać go później), przy czym jego ilość nie może przekroczyć 10h.

Nie sądzę aby mnie osobiście dotknęły nowe zmiany. Spotify wykorzystuję głównie do poznawania nowych zespołów lub szybkiego przejrzenia i przesłuchania dyskografii danego artysty. Niewątpliwie jednak, dla osób, które używają usługi Spotify jako głównego źródła muzyki na swoim komputerze owe limity będą dosyć dotkliwe (limit 2,5h nie wystarczył by mi na jeden dzień, nie mówiąc o tygodniu, po prostu większość słuchanej muzyki biorę z innych źródeł niż Spotify).

Co sądzicie o wprowadzonych regulacjach? Nie jest to przypadkiem strzał w stopę? Wydaje mi się, że wiele osób w obliczu limitów po prostu porzuci tę usługę i potrzebne im utwory pobierze na dysk, a jako źródło utworów do jednorazowego przesłuchania zacznie wykorzystać choćby YouTube.

It's alive!

Tak tak, nadal żyję, choć patrząc na to jak długo się tutaj nic nie działo, można było pomyśleć inaczej. Niestety, tak łatwo się świat Sobaka nie pozbędzie, więc po prawie czterech miesiącach (sic!) bez wpisu, czas na mały-wielki powrót. Zdaję sobie sprawę, że pewnie część z Was wyrzuciła mnie już z czytników RSS (o ile kiedyś w jakimś byłem :D), ale mam nadzieję, że mimo tego wszystkiego ktoś będzie chciał czytać moje wypociny.

Jak widać, każdemu, nawet mi, może znudzić się nic nie robienie. W związku z tym doszedłem do wniosku, że czas trochę odkurzyć na moim blogu. Standardowo, przy takim „powrocie” (wolę nie liczyć ile ich już było) poprawiłem kilka zalegających rzeczy.

Zabrałem się za poprawienie różnych rzeczy powiązanych z theme strony. Zależało mi głównie na poprawie generowanego kodu HTML i to się częściowo udało. Nie jest jeszcze dobrze, bo pewne rzeczy są trudne w modyfikacji ze względu na to jak generuje je WordPress, na kilka innych nie miałem pomysłu lub wiedzy jak je rozwiązać (bardzo możliwe, że dało by się to zrobić optymalniej i np. pozbyć się jeszcze kilku divów). Mimo wszystko udało się pozbyć naprawdę sporej części zbędnego kodu HTML i CSS (rozmiar tego [wliczając minifikację] zmniejszył się o połowę) oraz poprawić semantykę. Użycie HTML5 zostało rozszerzone poza samo doctype, które było w theme od początku (między innymi poprzez użycie atrybutu placeholder zamiast JS-owych zamienników).

Przy okazji poprawiania wyżej wspomnianych rzeczy okazało się jednak, że kod PHP szablonu dał mi okazję do poprawienia wielu rzeczy. Theme Mystique został oparty na frameworku przeznaczonym do tworzenia właśnie szablonów pod WordPressa - Atom. Jedną rzecz mogę o tym skrypcie powiedzieć na pewno - niesamowita kobyła. Okazało się, że sama konstrukcja wspomnianego frameworka miała duży wpływ na wydajność strony. Wystarczy chyba wspomnieć, że po w miarę drobnych modyfikacjach, w niektórych miejscach udało mi się zmniejszyć ilość zapytań SQL o 50%. Świadomie pozbyłem się bardzo wielu możliwości theme, z których nie planuję korzystać, tak aby poprawić katastrofalną (serio katastrofalną) wydajność mojej instalacji WordPressa.

Przy okazji pozbyłem się też nieużywanej już wtyczki do śledzenia błędów 404. Wtyczka nie widziała problemu w zostawieniu swoich tabel w bazie po odinstalowaniu. W jednej leżało 14 tysięcy rekordów, w drugiej 9 tysięcy – i kto to teraz posprząta? Doliczmy do tego 23 tysiące rekordów od kolejnej wtyczki, która zapomniała zabrać swoje zabawki z piaskownicy przy odinstalowywaniu i mamy już całkiem pokaźną (oczywiście jak na moją skalę) część bazy danych.

Może jest to mało zauważalne, ale istotnego odświeżenia doczekała się organizacja treści na blogu. Ponownie otagowałem i skategoryzowałem wszystkie wpisy. Kategorie nie powinny być już aż tak ogólne, z kolei ilość tagów została ograniczona ponad dwukrotnie, tak, aby faktycznie grupowały one podobne treści (zmiany widać zresztą nawet wizualnie na samej chmurze tagów).

W związku z przeprowadzonymi sporymi porządkami zwracam się z prośbą do czytelników mojego bloga (o ile jeszcze ktoś taki pozostał po tej czteromiesięcznej niezapowiedzianej przerwie). Jeżeli ktoś z Was widzi coś, co powinno zostać poprawione, to będę wdzięczny za zgłoszenie, czy to w komentarzu do tego wpisu, czy też przez kontakt. Starałem się poprawić to, o czym przypominaliście mi od dawna, ale mam świadomość, że mogłem o czymś zapomnieć.

Przepraszam za tak długą nieplanowaną przerwę i liczę na to, że ktoś jeszcze zamierza czytać przyszłe wpisy :)

IronCMS2 beta3 i informacje

Zgodnie z ostatnimi zapowiedziami projekt CMS-a (wbrew pozorom) nie został porzucony. Poza wydaniem kolejnej bety, która naprawia poprzednio znalezione błędy i dodaje trochę nowych funkcjonalności chciałem wyjaśnić kilka kwestii natury organizacyjnej.

Po pierwsze, coś co może Was lekko zasmucić (choć, serio, nie powinno :D). Z powodu moich niezbyt wyrafinowanych umiejętności i pewnych specyficznych wymagań jakie postawiłem przed systemem, a także uwarunkowań licencyjnych związanych z szablonem, CMS nie zostanie na razie wydany publicznie. Po drugie: ponownie nadszedł czas na podziękowanie grupie świetnych testerów i kolegów, którzy pomagają mi w realizacji całego tego przedsięwzięcia. Podziękowania lecą , alfabetycznie, do:

Jeżeli o kimś zapomniałem to proszę bić :D W tej wersji ponownie poprawiono ponad 50 zgłoszeń odnośnie błędów i funkcjonalności. Jeżeli ktoś z Was chciałby dołączyć do grona testerów, to proszę o skorzystanie z zakładki "Kontakt".

Mam nadzieję, że kolejna wersja będzie już stabilna, wtedy na pewno przedstawię więcej informacji.

Pozdrawiam :)

[Minecraft] Jak wyłączyć griefing endermanów i eksplozje creeperów?

Tematem dzisiejszej krótkiej porady będzie Minecraft - popularna gra sandboksowa. Pokażę, jak w prosty sposób można wyłączyć wszelki griefing wykonywany przez moby. Wlicza się w to:

  • niszczenie bloków poprzez eksplozje creeperów, ghastów i witherów
  • podnoszenie bloków przez endermany
  • wyłamywnanie drzwi przez zombie

Swego czasu stworzyłem plugin MobsControl, który realizował powyższe zadania, ale od Minecrafta w wersji 1.4.2 wyłączenie powyższych zachowań jest możliwe przez wykonanie jednej komendy.

Multiplayer
Wykonanie komendy wymaga uprawnień operatora. Z konsoli serwera lub wykonaj następującą komendę:

/gamerule mobGriefing false

Singleplayer
Wykonanie tej czynności w trybie singleplayer wymaga włączenia cheats (oszustw) przy tworzeniu świata. Inaczej nie będzie możliwe wykonanie komendy. Komenda tak jak powyżej:

/gamerule mobGriefing false

Uwagi na koniec
Rozróżniana jest wielkość znaków! Jeśli chcemy przywrócić ustawienia domyślne to po prostu zmieniamy false na true i wykonujemy komendę raz jeszcze.