Ponad tydzień temu odbyła się kolejna edycja konferencji PHPCon Poland. Jak ten czas szybko leci, pamiętam jak była organizowana pierwsza edycja w 2010 roku. Wtedy była to mała konferencja na 100-200 osób w Hucie Szklanej.
W tym roku uczestników było już prawie dziewięciuset, a konferencja przeniosła się do wielkiego hotelu w Ossie. Ale dzięki wielkości hotelu, oraz 3 salom (2 prelekcyjne, 1 warsztatowa) nie odczuwało się tak dużej ilości uczestników. Moim zdaniem hotel dobrze poradził sobie z taką imprezą, gastronomicznie również dał radę. Jedyne co, to brakowało ewidentnie znaków/strzałek kierujących pierwszego dnia na miejsce rejestracji uczestników konferencji, z recepcji hotelowej.
W tym roku miałem okazję uczestniczyć w konferencyjnych warsztatach. Ze względu na Mariusza uczestniczyłem w warsztacie z Ansible. Moim zdaniem świetna rzecz, Mariusz z Kacprem pokazali dlaczego warto skorzystać z Ansible oraz jak łatwo wykorzystać to narzędzie. Ansible jest bardzo łatwy jeśli chodzi o “czytanie” plików konfiguracyjnych, jak także w samej konfiguracji. Bardzo ułatwia w dostosowywaniu pod siebie Vagranta, który siedzi pod spodem. A dzięki Ansible nie musimy za wiele wiedzieć o samym mechaniźmie wirtualizacji i kolejny raz tracić czas na stawianie środowiska pracy pod konkretny projekt.
Minusem warsztatów było, że w najlepszym wypadku traciliśmy połowę wykładowego dnia. Nie powinno tak być. Pierwsza prelekcja, na której mogłem być zaczynała się o 20:00 (agenda). Wybrałem “OLX pod maską”. Łukasz Szymański przedstawił krótko historię polskiego OLX, które zaczynało jako szerlok (ktoś jeszcze pamięta?), a następnie tablica. Miesięcznie polski OLX obsługuje 9,5 mln UU / 77,5 mln wizyt / 1,5 mld odsłon. Wszystko jest ogarniane przez 1 instancję haproxy, za tym dopiero stoją nginx-y z varnishem oraz riakiem. Poza tym OLX wykorzystuje głównie memcached, Redis dla fjuczerów oraz MySQL. Do statystyk używają Graphite. Później Łukasz opisał jak była stworzona architektura aplikacji, jakie zespół miał wyzwania i co obecnie planują. To już nie było tak interesujące. Jak na wykład sponsorki tej edycji było i tak bardzo dobrze.
Drugi, a jednocześnie ostatni wykład tego dnia, który wysłuchałem był poświęcony PSR-7, a dokładnie jego historii. Niestety zapomniałem, że historia może być tak nudna. Mimo sporych wysiłków Kacpra Guni i Mariusza Gila, oraz cofnięcia się do podstaw PHP czyli aplikacji webowych opartych o Request i Response nie sprawili, że pokochałem historię. Najważniejsze do zapamiętanie – teraz wszyscy “będą” PSR-7 i jest to dobra wiadomość, bo będzie można prawie, że dowolnie podmieniać implementację tego interfejsu/specyfikacji.
Drugi dzień konferencji. Sobota miała być tym co programiści lubią najbardziej. Prelekcje w godzinach od 10:00 do 20:00 dawały teoretyczną możliwość poznania sporej porcji nowej wiedzy i weryfikację już posiadanej. Niestety w tym roku coś niedobrego stało się z prelekcjami. Pewne prelekcje zostały specjalnie wyróżnione w agendzie (S), coś czego nie było w latach poprzednich. Niby nic, ale merytoryka mocno spadła moim zdaniem. I nie chodzi o to, że były to tzw. “sponsorskie wykłady”. W poprzednich latach “mówiły” firmy, ale były to ciekawe case study lub przypadki opisu użytych technologii. Tym razem były to tylko wyjątki jak OLX lub getResponse.
Na PHPCon Poland najbardziej lubię posłuchać polskich prelegentów, zagranicznych mamy w kuluarach i na YT. Pierwszy wykład tego dnia przesiedziałem u Leszka na “PHP 7 w praktyce”, gdzie tytułowej praktyki mi zabrakło ale merytorycznie było bardzo dobrze. Dla osób myślących o przesiadce na PHP 7 przypominam, że dostępny jest darmowy ebook. Najważniejsze do zapamiętania – Udział PHP 5.3 w rynku to 36.4%, PHP które żyło w latach 2009-2014.
Abstrakt prelekcji “Bla Bla Bla – technical story” naprawdę zachęcał. Serwis obsługuje duży ruch, równie duża jest liczba deweloperów odpowiedzialnych za serwis. Niestety angielsko-francuski prelegentów (Benjamin de Bernardi, Olivier Dolbeau) sporo zepsuł.
To co udało mi się wychwycić, to informacja że BlaBla najpierw było oparte o Mambo w 2005 roku, a dopiero później zaczęli stosować inne technologie, szczególnie gdy w 2010 roku weszli na inne rynki (Hiszpania, Włochy, UK).
W pierwszych wersjach powstały takie potworki jak plik lib.trip.php, który posiadał prawie 4k linii kodu, bez żadnych testów. Dlatego zespół postanowił przejść z własnego rozwiązania na Symfony.
A dlaczego Symfony? Ponieważ Symfony posiada duże community, szczególnie we Francji. Łatwiej również znaleźć nowych programistów, którzy szybko wdrożą się w projekt symfonowy.
Obecnie BlaBlaCar korzysta z git, Atlassian Bamboo, phpunit, behat, Elasticsearch, rabbitMQ, varnish, chef, zabbix, hadoop, AWS, New Relic, Galera, swrrot.
Jak tylko ukażą się nagrania (zapewne wiosną) warto obejrzeć, jak opowiadają o problemach z jakimi się zderzyli (chociażby kod spaghetti).
Najważniejsze do zapamiętania – warto posiadać wewnętrzne API pomiędzy warstwami
W ostatnim czasie kilkukrotnie już zdarzyło się, że osoba z którą rozmawiałem sądziła, że MariaDB to zupełnie nowy silnik bazodanowy niekompatybilny z MySQL.
Nic bardziej mylnego. Sytuacja wygląda bardzo podobnie do tej z OpenOffice sprzed kilku lat. Jak pamiętacie w 1999 roku firma Sun Microsystems przejęła produkty firmy StarDivision i udostępniła pod nazwą StarOffice. Pakiet był darmowy, ale zamknięty ze silnym wsparcie od firmy Sun. W 2002 roku pojawiła się pierwsza wersja OpenOffice, na której bazował StarOffice 6.0. Był to bardzo popularny zabieg w tamtym czasie (patrz OpenSUSE, CentOS). Firma wydawała otwartą, darmową wersję community rozwijaną przez społeczność, następnie markowała swoją marką i rozprowadzała za odpowiednie benefity (często w formie płatnego supportu).
Nie wszystko układało się jednak najlepiej, ale w takim zawieszeniu środowisko współtwórców OO trwało przez wiele lat. W 2010 roku firma Oracle przejęła Sun i wszelkie projekty, w tym OpenOffice/StarOffice. Środowisko open-source było zaniepokojone poczynaniami Oracle (np. pozwy w sprawie korzystania z Javy w Androidzie) i postanowiono zupełnie oddzielić się od korporacyjnych wpływów – powstał LibreOffice.
To tak w sporym skrócie. Co wspólnego ma z tym MySQL? MySQL tworzony był przez szwedzką firmę MySQL AB, która została wykupiona przez Sun w 2008 roku, a ta została przejęta… Zgadza się, przez Oracle w 2010 roku. Ale już w 2004 roku środowisko wolnego oprogramowania zaczęło mieć „problemy” z MySQL, a dokładniej programiści chociażby PHP. Wszystko z powodu zmian w licencji MySQL od wersji 4.1, ponieważ od tego momentu MySQL na darmowej licencji można było używać wyłącznie do zastosowań niekomercyjnych. W momencie przejęcia przez Sun, jeden z twórców MySQL (Monty Widenius) stworzył forka MySQL pod nazwą MariaDB.
MariaDB jest oparta na tym samym kodzie co MySQL, ale rozpowszechniana tylko na licencji GPL. Twórcy starają się utrzymywać ciągłą kompatybilność do pierwowzoru – MySQL. Produkt ma być dostępny zawsze na licencji GPL, czego nie można powiedzieć o przyszłości MySQL od Oracle.
Do wersji 5.5 (aktualna stabilna) MariaDB jest numerowana identycznie do MySQL i kompatybilna w pełni. Natomiast następcą MariaDB 5.5 będzie MariaDB 10 (obecnie w fazie rozwoju, będzie częściowo kompatybilna z MySQL 5.6).
Firma Percona natomiast stworzyła fork MySQL zastępując jej silnik innoDB (względy licencyjne) silnikiem pisanym przez zespół XtraDB. Głównym powodem wprowadzenia własnych zmian była słaba skalowalność bazy MySQL w oryginale.
Percona Server jest w stanie skalować się aż na 48 rdzeni procesora. Podobnie jak MariaDB, również Percona Server od wersji 5.6 nie będzie w pełni kompatybilna z MySQL 5.6. Percona Server wykorzystuje natomiast dobre smaczki z MariaDB, oraz pewne udostępnione fragmenty kodu przez Google (np. SHOW USER/TABLE/INDEX).
Percona Server 5.5 udostępniona jest na wersji CC BY-SA 2.0.
Dzisiejszy wpis jest tym z rodzaju błahych, ale nie do końca. Często zapominamy, że przeniesienie słowa z życia codziennego (w tym wypadku: float) do świata maszyn nie zawsze jest właściwe.
Często w projektach, w których uczestniczę projektowanie bazy danych oddaje się w ręce niedoświadczonych osób. Bo dlaczego nie może jej zaprojektować osoba, która będzie tworzyła logikę w aplikacji do niej?
Zaprojektować owszem – może, ale często osoba odpowiedzialna za część programistyczną aplikacji ma nikłe pojęcie o projektowaniu bazy, a szczególnie dostępnych typach, procedurach itp.
Szczególnie studenci i osoby z firm, gdzie wyznaje się zasadę „człowiek-orkiestra” popełniają ten błąd. Korzystając z typu VARCHAR i podając jego wielkość (10) sądzą, że tak samo można ograniczyć wielkość (długość) pól liczbowych, np. INT.
Tym bardziej powielają ten błąd, gdy silnik bazodanowy podczas tworzenia tabeli nie zwraca błędu. Zapis INT(10) jest poprawny, ale nie powoduje on, że ograniczymy INT do 10 miejsc (pomijam fakt, że niektórzy sądzą, że podając INT(18) przeskoczą definicję długości samego INT-a). Z założenia zapis INT(X) powinien iść w parze z opcją ZEROFILL. Konstrukcja:
CREATE TABLE `codes` ( `code` INT(5) ZEROFILL COMMENT 'kod, ktory zostanie dopełniony zerami' )
To spowoduje, że gdy dodamy kod o wartości 1, to wynik zapytania zwróci nam 00001 (czyli cyfrę 1 uzupełnioną do 5 miejsc zerami – ZEROFILL). I tylko dlatego istnieje zapis INT(X), a nie z powodu ograniczenia długości pola danego typu numerycznego. Od tego mamy masę aliasów (jak SMALLINT czy TINYINT).
Jedną sprawę mamy wyjaśnioną. Teraz poważniejsza sprawa, która wpływa na wyniki zapytań bazy danych. Raz na jakiś czas zdarza mi się zetknąć z kodem, gdzie kwoty z faktur, rachunków są umieszczane w polach typu FLOAT. Wydaje mi się, że autorów takich konstrukcji popycha posługiwanie się tłumaczeniem FLOAT na język polski jako liczba zmiennoprzecinkowa. Człowiek widzi hasło „liczba … przecinkowa” i sądzi, że służy do zapisu ogólnie pojętych cen. Dlatego lepiej odwołać się do angielskich definicji, które moim zdaniem są jaśniejsze: float jest to liczba aproksymowana, czyli przybliżona. A najlepiej posłużyć się przykładem. Utwórzmy tabelę:
CREATE TABLE `invoice_record` ( `price` FLOAT NOT NULL )
Następnie umieśćmy w niej dane z wartościami po przecinku, np. kwotę „29.99„. Cała operacja się powiedzie, a zapytanie SELECT zwróci nam odpowiednie wyniki. Oto nam chodziło. Na pewno?
W przypadku, gdy będziemy chcieli uzyskać faktury, które mają pozycje z ceną ”29.99” lub są większe równe to nie zobaczymy żadnych wyników. Dlaczego? Ponieważ jest to liczba zmiennoprzecinkowa, a prościej nieprecyzyjna. Nasze „29.99” wygląda tak naprawdę tak:
Kanał ATOM
