PHP + HipHop ... i nigdy stop :)

Tytuł sam odkrywa szczegóły tej wypowiedzi. Chciałbym opisać swoimi słowami co myślę o rozwiązaniach sieciowych, które są wysoko skalowalne i produkcyjnie pozwalają na obsłużenie stron o ruchu ~400 mln odsłon miesięcznie. Temat do tyczy znanego wszystkim języka PHP oraz narzędzia poprawiającego niemalże o połowe wydajność tego języka tzn. prj. HipHop.



Wiele projektów udowodniło, że język PHP daje się osadzać na innych platformach (t.j. Java, .NET, Erlang VM)i konwertować do innych formatów wykonawczych. Niewiele miało tak wyjątkową rekomentację jak HipHop. Pierwotnie projekt zrodził się na potrzeby optymalizacji wydajności skryptów w serwisie społecznościowym Facebook. Od kilku dni źródła zostały uwolnione i umieszczono je na GitHub.

Wracając do alternatywnych prób kompilacji w PHP oraz osadzania warto przytoczyć następujące projekty:
phpcompiler
roadsend
Phalanger php compiler
Quercus - PHP in Java



Kwintesencja HipHop jest zarazem założeniem tego tworu. Jest to coś ala kompilator skrośny z języka PHP do języka C++. Dzięki takiej ścieżce ANSI C (Zend API), w którym napisany jest PHP, dalej PHP i na końcu skrypty CGI skompilowane kompilatorem G++ daje zysk ponoć dwukrotny w wydajności !!!
Co dla świata PHP jak i dla samego Facebooka jest REWOLUCYJNE :-) Pierwotnie produkt komenrcyjny ZendServer próbował optymalizować czas działania skryptów, poprzez pakowanie OPCODES (coś ala bytecode w PHP), lecz możliwości tego rozwiązania skończyły się bardzo szybko. Aktualnie zamiast np: dokupować kolejny rdzeń lub stawiać kolejną maszynę w farmie wystarczy użyć HipHop - nieprawdaż że proste ;) Poniższy schemat pokazuje ogólnie ten proces:





Materiały dodatkowe:

 http://developers.facebook.com/news.php?story=358&blog=1
 http://www.ustream.tv/recorded/4409735
 http://www.facebook.com/video/video.php?v=124728580468&ref=mf

Przodują Java + C a PHP w górę się pnie ;)

Na stronie Tiobe podejrzymy interesujące statystyki sporządzane wymyślnym algorytmem dot. populrności języków programowania. Oto raport w postaci wykresu udostępniany w ramach serwisu Tiobe:





W postaci uproszczonej widać ciekawe wyniki w tabeli:

Position
Feb 2010 Position
Feb 2009 Delta in Position Programming Language Ratings
Feb 2010 Delta 
Feb 2009 Status
1 1  Java 17.348% -2.05%   A
2 2  C 16.602% +0.76%   A
3 5  PHP 10.001% +1.22%   A
4 3  C++ 9.447% -0.19%   A
5 4  (Visual) Basic 7.051% -1.79%   A
6 6  C# 5.015% -0.05%   A
7 7  Python 4.314% -0.25%   A
8 8  Perl 3.600% -0.52%   A
9 9  Delphi 2.656% -0.97%   A
10 10  JavaScript 2.636% -0.90%   A
11 11  Ruby 2.439% -0.84%   A
12 32  Objective-C 1.779% +1.60%   A
13 -  Go 1.778% +1.78%   A-
14 14  SAS 0.771% -0.06%   A
15 13  PL/SQL 0.738% -0.25%   A
16 17  ABAP 0.661% +0.09%   B
17 16  Pascal 0.606% -0.08%   B
18 18  ActionScript 0.579% +0.04%   B
19 23  Lisp/Scheme 0.563% +0.13%   B
20 24  MATLAB 0.536% +0.12%   B

Warto podkreślić, że serwis agreguje dane z różnych przeglądarek oraz przetwarza je po czym wyznacza na podstawie sporządzonego przez siebie - i opublikowanego - wzoru rankingi.

GIT - dlaczego Linus i ja nie polubiliśmy subversion

Systemy kontroli wersji są niezbędnym narzędziem w codziennej pracy zespołu projektowego, a często bez odpowiedniego rozwiązania niemożliwa jest komunikacja i wymiana rezultatów prac pomiędzy programistami.

Ujmując temat zwięźle w ramy praktyczne Linux Torvalds poczuł potrzebę niezależności w wytwarzanych projektach i zrozumiał, że problem łączenia kodu różnych osób współtworzących jeden produkt tzw.merge to klucz do sprawnej pracy. Tworzenie oprogramowania, kiedy 30% czasu zajmuje rozwiązywanie konfliktów mojego kodu z innymi to znane z SVN (Subversion) marne zwyczaje współpracy. Linus wychwycił również ten fakt, więc nie chciał kopiować systemu wersji SVN i pomyślał o swoim systemie wersji. Ponieważ zna się na algorytmach opracował koncept, kiedy każda zmiana może być postrzegana jako gałąź drzewa stanowiących naturalny system zmian, zakończony jednym pniem. Pień drzewa, czyli master jest miejscem (tzw. branch), gdzie wszystkie powstające zmiany (tzw. features) trafiają ostatecznie. Każda nowa zmiana może dosłownie niezależnie być rozwijana w dowolnym innych mniej lub bardziej zależnym repozytorium przez jednego lub więcej developerów. Niby nic dziwnego, bo tak ma wiele systemów kontroli wersji, ale jednak więcej niżeli w Subversion. Koncept, który udało się wytworzyć pozwala na podłączanie się do wielu zdalnych repozytoriów kodu, łączenie ze sobą pracy wielu niezależnych programistów i osiąganie w ten sposób jednego zamierzonego celu. Tym celem jest Linux Kernel, czyli jądro >70% urządzeń, maszyn, serwerów, rakiet, sprzętu wojskowego i innych przemysłowych wytworów, do tego współczesnych smartfonów, tabletów, komputerów. Linus Torvalds tworząc GITa osiągnął swój cel, czyli uniezależnienie pracy wielu chętnych ludzi ze świata Open Source w celu stworzenia jednego z największych i rewolucyjnych produktów. Sukcesem tym Linus podzielił się ze światem i zmienił myślenie, ułatwiając tym samym pracę wielu milionów programistów.

Linus, thanks for GIT, too ;)

Przypominam sobie jak chciałem zrobić kilka poprawek do słynącego systemu helpdesk o nazwie OTRS, co tutaj będę ukrywał - w języku Perl :-)< br /> Zapowiadał się dość niepewnie, bo na starcie dowiedziałem się o tym, że mają w tym projekcie repozytorium CVS, które to jest dość magicznym sposobem na gromadzenie historii zmian wersji kodu. Nie pozostało mi nic innego jak zaproponować autorowi OTRSa przenieść się na GITa :-) Nie musiałem go zbyt przekonywać, bo dzięki temu społeczność developerów wokół projektu OTRS odżyła. Szczegóły widać na GITHUB w projekcie OTRS

Cechy z którymi GIT stał się potęgą obsługi wersji współczesnych projektów to:

• gałęzie gita - branch
• Narzędzia Gita - Moduły zależne - submodules
• poddrzewa projektowe gita - subtress
• rozproszona obsługa wersji i zdalne branche - DVCS

Oto co mówi Linus na temat systemu kontroli wersji GIT:

Linki:

Move OTRS code repositories/branches to GIT

GIT-SCM

Linux Kernel