Odzew XSolve był niemal natychmiastowy i 16 marca w firmie odbył się całodzienny event Symfony Bug Fixing Day, w którym wzięli udział członkowie teamu PHP oraz zainteresowani wydarzeniem członkowie innych teamów.

Naszym celem było wsparcie developmentu Symfony2, nie tylko poprzez zamykanie istniejących zadań ale także poprzez sprawdzanie ich poprawności, komentowanie zadań, aktualizację dokumentacji, uzupełnianie testów. Każdy mógł znaleźć coś interesującego i przyczynić się do rozwoju frameworka.

Dzięki tej akcji udało nam się rozwiązać kilka problemów. Kilka ticketów z listy zgłoszonej na blogu zostały dokładnie sprawdzone oraz skomentowane na githubie (np.
https://github.com/symfony/symfony/issues/2383#issuecomment-4538055). Zgłosiliśmy także jeden pull request (https://github.com/symfony/symfony/pull/3617). Rozwiązywał on problem, który uniemozliwiał wykonanie skryptu sprawdzającego pokrycie kodu testami jednostkowymi. Dwa dni później patch został zaakceptowany i włączony do kodu Symfony 2.1.

Oczywiście podstawowym narzędziem w rękach twórców oprogramowania są testy, jednakże nie zawsze są one w stanie wychwycić wszystkie niuanse. Zwłaszcza, gdy napisany kod pozornie działa, ale jest źle przemyślany, przez co może ujawnić swoje wady w najmniej oczekiwanym momencie. W takim wypadku wychwycenie takiego błędu może nastąpić w dwóch momentach: po wystąpieniu usterki (co czasem może być katastrofalne w skutkach) lub czasie code review.

Czym właściwie jest code review, lub w tłumaczeniu na język polski inspekcja kodu? To nic innego jak przeglądanie kodu innego programisty w celu wykrycia i poprawy błędów jeszcze przed włączeniem kodu do systemu kontroli wersji i przekazaniem go do testowania*.

Code review zazwyczaj przede wszystkim zwiększa czytelność kodu. Po wielu godzinach pisania kodu niesforny nawias klamrowy może uciec do następnej linijki, a pomiędzy instrukcją if i nawiasem z warunkiem zabraknie spacji. Zdarza się, że koderzy zostawiają po sobie stary zakomentowany kod, który jest już nie potrzebny i tylko wprowadza bałagan. Są to detale, które za pewne wielu programistów uznałoby za bzdurne, jednakże w każdej poważnej organizacji są wytyczone tzw. coding standards. Zwiększa on czytelność kodu, a co za tym idzie wydajność osoby, która w przyszłości wprowadza zmiany czy poprawki.

Najważniejszym aspektem code review jest oczywiście wychwytywanie i poprawa błędów oraz usunięcie luk w zabezpieczeniach. Jest to szczególnie ważne, gdy pracujemy nad oprogramowaniem o podwyższonym standardzie bezpieczeństwa, lub gdy w zespole pracują programiści o różnym stażu pracy: od najbardziej doświadczonych po juniorów i stażystów. Dane branżowe wskazują, że inspekcja kodu może usunąć aż do 85% usterek, jednak przeciętnie ta wartość utrzymuje się w granicach 65%**, co i tak jest niezłym wynikiem.

Nawiązując do juniorów i stażystów: wiele osób zapomina, że code review ma bardzo duży aspekt edukacyjny. Początkujący programista może się bardzo wiele nauczyć przeglądając kod seniora a także odwrotnie, doświadczony deweloper wskazując błędy juniorowi przyczynia się do rozwinięcia jego wiedzy i nauki dobrych praktyk programistycznych. Ale programowanie to bardzo szeroka dziedzina, więc bywa też tak, że i senior nauczy się czegoś od juniora. Często przy okazji code review można podpatrzyć ciekawe rozwiązania i zaaplikować je w swoim kodzie przy kolejnej okazji. Warto przy tym porozmawiać z autorem i dowiedzieć się więcej.

Niestety jak wiadomo nie ma rzeczy idealnych, więc także i code review ma swoje wady. Wg niektórych, czas poświęcony na inspekcję kodu jest czasem zmarnowanym. Absolutnie nie mogę się zgodzić z tym stwierdzeniem (i mam nadzieję, że Wy też nie, zwłaszcza w obliczu przytoczonych wyżej zalet), ale faktem jest, że w tym czasie nie powstaje ani jedna nowa linijka kodu. Co w sposób oczywisty spowalnia rozwój aplikacji. Chyba każdy deweloper wie, jak to jest pracować pod presją czasu. Przy niektórych projektach, zwłaszcza w fazach końcowych, po prostu nie ma czasu na porządne code review. Przeciętnie inspekcja 150 linijek kodu zajmuje około godziny***. Niestety przyspieszenie tego procesu może spowodować drastyczny spadek efektywności takiego procesu.

Nie da się ukryć, że czytanie ze zrozumieniem cudzego kodu do przyjemności nie należy, a już na pewno nie może się równać z przyjemnością płynącą z pisania własnego ;). Ale mimo wszystko jak widać warto. Pamiętajmy, że człowiek pozostanie tylko człowiekiem i zawsze będzie się mylił. Cała sztuka polega na tym, żeby pomyłki wychwycić i naprawić. A więc po co robimy code review? Odpowiedź nasuwa się sama: po to, aby nieustannie podnosić jakość. I to nie tylko oprogramowania, ale przede wszystkim naszych programistów. Przecież nie od dziś wiadomo, że firma jest tylko tak dobra, jak pracujący w niej ludzie!

Na sam koniec parę wskazówek, jak uczynić code review przyjemniejszym i bardziej efektywnym:
1. Warto specjalnie wyznaczyć czas przeznaczony właśnie na code review. Tak, aby programista mógł na spokojnie porządnie przeanalizować kod. Pamiętajcie, około 150 linijek na godzinę.
2. Powinien być przewidziany czas na konsultację autora kodu z recenzentem, aby można było wyjaśnić ewentualne niejasności a także przedyskutować alternatywne rozwiązanie.
3. Każda, nawet najdrobniejsza modyfikacja, powinna być sprawdzana, gdyż w takim momencie można wykryć błąd, który w przyszłości mógłby spowodować potencjalne straty.
4. Warto się zastanowić nad wdrożeniem oprogramowania, które ułatwi code review. Na rynku istnieje wiele takich rozwiązań. Obecnie w XSolve korzystamy z Crucible, jednakże zachęcam do poszukiwań :).
___________________________________________________________________________________
* Definicja na podstawie polskiej Wikipedii
** Jones, Capers (June 2008). „Measuring Defect Potentials and Defect Removal Efficiency”. Crosstalk, The Journal of Defense Software Engineering. Retrieved 2010-10-05.
*** Ganssle, Jack (February 2010). „A Guide to Code Inspections”. The Ganssle Group. Retrieved 2010-10-05.

To czym zdecydowanie różnią się książki Blocha od innych dotyczących programowania czy też javy, jest to że w każdej z nich skupia się na pewnej niszy w temacie o którym pisze. W przypadku efektywnego programowania, skupia się na praktycznych aspektach tworzenia oprogramowania, dobrych, sprawdzonych wzorcach postępowania przy jego projektowaniu oraz na specyficznych dla javy zagadnieniach. Autor porusza 78 tematów, z którego każdy to kilku stronnicowy artykuł szczegółowo omawiający problem. Materiał zawarty w książce został skatagoryzowany według pewnych większych grup problemów, które porusza. Autor rozpoczyna od omawiania zagadnień związanych z tworzeniem i usuwaniem obiektów, następnie przechodzi do tych związanych z projektowaniem klas, w tym aspektów specyficznych dla javy. Można tutaj dowiedzieć się m.in. dlaczego należy uważnie używać singletonów, podstaw działania garbage collectora, jak definiować prawidłowe metody hashCode czy equals, dlaczego warto stosować interfejsy czy zastępować dziedziczenie kompozycją. Na uwagę zasługe fakt, iż autor stara się być jak najbardziej obiektywny, dostrzega zarówno zalety proponowanych przez siebie rozwiązań jak i ewentualne wady. W dalszej kolejności omawia takie konstrukcje jak typy ogólne, wyliczeniowe i adnotacje. Udziela praktycznych wskazówek jakich konstrukcji języka i praktyk programowania używać, a jakie są już przestarzałe. W ostatnich rozdziałach omawia sposoby wydajnego i rozsądnego korzystania z wyjątków, dzieli się doświadczeniem w kwestii współbieżności oraz serializacji. Cała wiedza z książki jest gdzieś pewnie rozsiana po internecie w postaci pojedynczych postów na blogach czy artykułów. Wydaje mi się jednak iż warto takie kompendium wiedzy nt problemów specyficznych dla javy mieć zawsze pod ręką i od czasu do czasu odświeżyć swoją pamięć. Gorąco polecam książkę Java. Efektywne programowanie . Tymczasem uciekam do kolejnego dziecka Blocha – Java puzzlers .

31 stycznia 2012r. programiści, informatycy oraz pasjonaci oprogramowania staną przed niepowtarzalną szansą poznania najnowszych trendów, technik i kierunków rozwoju branży  programistycznej. Skillful Software House XSolve objął patronatem medialnym cały cykl konferencji, widząc powiązanie pomiędzy branżą w jakiej na co dzień działa z tematyką poruszaną na poszczególnych imprezach Softdevcon.

Prelekcje poruszą tematykę z obszaru Cloud Development.

Lista prelekcji:

1. Analiza danych przy użyciu Apache Hive I Elastic MapReduce
(Radek Maciaszek / Krystian Nowak)
2. Development for the Cloud – changing the team’s mindset
(Masha Belyakova)
3. A cloud in your pocket
(Axel Quack)
4. Testowanie chmury
(Rafał Sibilski )
5. Komunikacja ze światem zewnętrznym z wykorzystaniem Windows Azure AppFabric
(Marcin Pytlik)
6. How Telecom companies are reacting to Cloud and what are the typical Telecom cloud offers
(Alper Celik)

Siódma prelekcja należy do Sponsora Głównego.

Zeev Suraski – izraelski programista PHP, współzałożyciel Zend Technologies. Z pomocą Andiego Gutmans’a w 1997 napisał PHP3, po czym dwa lata później stworzył Zend Engine.

Derick Rethans – twórca mcrypt, input_filter, dbus i rozszerzeń typu date/time w PHP. Znany również z opieki nad projektem PHP’owego profilera Xdebug oraz z kilkuletniego zaangażowania w Apache Zeta Components.

Jouzas Kaziukenas – założyciel i prezes firmy Web Species Ltd, mówca na konferencjach dotyczących technologii informatycznych, blogger.

Joshua Thijssen - starszy inżynier oprogramowania w Enrise/4Worx oraz właściciel prywatnej firmy NoxLogic.

Pomimo tego, iż byłem w stanie uczestniczyć tylko na przemówieniach w języku angielskim, muszę przyznać, że poruszono w nich kilka ciekawych tematów takich jak:

- 15 porad dla użytkowników MySQL
-  Struktury danych SPL i ich złożoność
- Jak władać przestrzeniami nazw w PHP
- Nowa era frameworków w PHP
- Rozszerzenia w PHP, z czym i dlaczego ?

Oceniając je poprzez pryzmat programisty PHP, trzy pierwsze uważam za naprawdę wartościowe i godne uwagi.

Według mnie najciekawsze przemówienie wygłosił Joshua Thijssen, specjalista MySQL, który w zwięzły sposób pokazał kilkanaście sztuczek mogących znacznie przyspieszyć operacje na bazie danych. Uważam, że przejrzenie slajdów z jego przemowy na pewno nauczy Was czegoś nowego. Pamiętajcie by nie ufać varchar’om! :)

Kolejnym, wybitnym przemówieniem popisał się Jurriën Stutterheim, który po krótkiej dygresji na temat złożoności algorytmów przeszedł do ciekawszej części poświęconej strukturom danych w PHP. Było naprawdę miło słuchać wykładu w którym dowodził, że prócz typowych tablic, PHP oferuje tak zaawansowane struktury jak: SplDoublyLinkedList, SplStack, SplQueue, SplHeap, SplMaxHeap, SplMinHeap, SplPriorityQueue, SplFixedArray i SplObjectStorage. Szczerze zachęcam do obejrzenia jego prezentacji.

Chciałbym też wspomnieć o wystąpieniu Nicka Belhomme, który postanowił opowiedzieć o nowej funkcjonalności wprowadzonej do PHP dopiero w wersji 5.3. Jego tematem były oczywiście przestrzenie nazw (ang. namespaces), czyli abstrakcyjne kontenery stworzone do trzymania logicznie pogrupowanych unikatowych identyfikatorów. Jego prezentacja była szczególnie edukacyjna i istotna dla przyszłych projektów w PHP, obfitując przy tym dodatkowo w kilkanaście przykładów z kodami źródłowymi.

Na sam koniec chciałbym przytoczyć wypowiedź Jouzasa Kaziukenas’a. Starał się on ukazać zmiany jakie zaszły w świecie frameworków PHP’owych w przeciągu ostatnich sześciu lat. Muszę przyznać, że zrobił to wyjątkowo dobrze. Wymieniwszy kilka frameworków, w tym Symfony2, Zend Framework, Lithium, Alloy, Fuel, Fat-free oraz Flow3, jego uwagę na dłużej przykuło Symfony2. Przede wszystkim za sprawą innowacyjnych rozwiązań o których rozprawiał, takich jak: bundles, dependency injection oraz community driven development (GIT). Nie bez znaczenia okazały się również symfonowe interoperacyjność, szybkość i doskonała dokumentacja. Jouzas ponadto bardzo oczekiwał nowej, stabilnej wersji frameworka ZF2, którego premiery nie potrafił niestety określić. Jeśli w tym czasie chcielibyśmy czegoś z innej beczki, do wypróbowania zostają microframeworki. Pomimo tego, iż stworzone głównie dla małych projektów, z pewnością będą interesującą i godną uwagi alternatywą. Dla zainteresowanych, przytoczonym microframeworkiem został Silex.

Podsumowując konferencję PFCongres muszę przyznać, że uczestnictwo w niej było dla mnie bardzo cennym doświadczeniem. Miałem bowiem okazję poznać wiele ciekawostek i wodotrysków jak również zaznajomić się z nowinkami i przyszłymi trendami języka PHP. Miałem też okazję na własne oczy zobaczyć Tych, którzy wkładają ogromny wysiłek w jego rozwój. Co więcej, bardzo zmotywowało mnie ich entuzjastyczne podejście do dalszego rozwoju i udoskonalania owego języka. Liczę, że i w przyszłym roku zdołam stawić się na PFCongres, a jeśli i Ty czujesz się podobnie „wkręcony” w PHP, to serdecznie polecam i zapraszam Cie na to wydarzenie!

Nagłówek artykułu sugeruje, że będę starał się dokonać porównania Javy i Pythona. Przecież to dwa kompletnie różne światy. Niemniej jednak postaram się w skrócie nakreślić czym cechuje się Python i opisać co poniektóre ciekawsze rozwiązania, z którymi spotkałem się podczas mojej krótkiej i burzliwej znajomości z tym językiem.

Intro

W odróżnieniu do Javy, Python jest językiem typowanym dynamicznie: zmiennych się nie deklaruje i tym samym nie określa się ich typu. Znaczy to mniej więcej tyle, że do tej samej zmiennej można przypisywać obiekty różnych klas bez potrzeby rzutowania, nie narażając się na odpowiednik javowego ClassCastException. Skoro już mowa o klasach – Python jest w pełni obiektowy, a więc typy proste (bool, int, float, complex) również są obiektami. Python jest językiem interpretowanym, nie wymagającym kompilacji (ten krok jest opcjonalny – interpreter może generować skompilowany kod do plików *.pyc). Fakt ten może spodobać się weteranom Javy – przecież nieraz budowanie złożonych projektów potrafiło zająć ładne parenaście minut. Jednak dynamiczne typowanie w połączeniu z brakiem konieczności kompilacji (który de facto często w pewnym stoponiu weryfikuje poprawność kodu) i nieuwagą programisty może przyczynić się do powstawania błędów. Ale to temat na osobną dyskusję.

Liczby.

Cechą, której nie miałem okazji specjalnie wykorzystać, a która bardzo pozytywnie mnie zaskoczyła, jest wbudowana obsługa liczb zespolonych. Dostępny mamy typ prosty complex.

>>> 1j * 1J
(-1+0j)
>>> 1j * complex(0,1)
(-1+0j)
>>> a=1.5+0.5j
>>> a.real
1.5
>>> a.imag
0.5

Kolejną ciekawostką jest fakt, że ograniczeniem długości liczby typu long jest w zasadzie tylko ilość dostępnej pamięci operacyjnej. Dostajemy zatem „out-of-the-box” możliwość wyrażania odległości międzygalaktycznych w milimetrach. Tylko co, jeśli będziemy chcieli przekazać obliczony wynik na inną maszynę?

(), [], {}.

Zdarza się, że potrzebujemy, aby metoda zwróciła więcej niż jeden obiekt. Rzecz jasna mowa tu nie o liście/tablicy, ale o obiektach różnych typów. Jednocześnie nie widzimy sensu tworzenia nowej klasy, która i tak byłaby wykorzystana tylko w tym jednym miejscu. Wtedy (na przykładzie Javy) zaczyna się kombinowanie: może przekazywać jeden obiekt przez parametr, w metodzie wypełniać go danymi, a drugą część informacji zwracać przez return statement?; może przejrzeć pakiet *utils w poszukiwaniu generycznej klasy Pair<A,B> lub Trio<A,B,C> i we wspomnianej metodzie zwracać właśnie obiekt takiej klasy? a może spróbować użyć mapę?

Zdaje się, że m.in. wówczas przydałyby się znane z Pythona krotki – niemodyfikowalne sekwencje referencji dostępnych niezależnie. Dostęp do poszczególnych elementów odbywa się przez podanie indeksu (numeracja od zera).

>>> tuple = 12345, 54321, 'hello!'
>>> tuple
(12345, 54321, 'hello!')
>>> tuple = (12345, 54321, 'hello!')
>>> tuple
(12345, 54321, 'hello!')
>>> tuple[0]
12345

Idąc za ciosem – kolejnym typem danych jest lista, oznaczana przy pomocy nawiasów kwadratowych. Bardzo podobna do krotki, jednak daje możliwość modyfikacji swoich danych.

>>> list = ['spam', 'eggs', 100, 1234]
>>> list
['spam', 'eggs', 100, 1234]

Słowniki, które w Pythonie tworzy się przy użyciu nawiasów klamrowych, prezentują nieco inny sposób grupowania danych. Podczas gdy krotki i listy są numerowane na podstawie indeksów liczbowych, słowniki do indeksacji stosują nazwy – mogą to być litery, ciągi znaków lub symbole. Słowniki można porównać do java.util.Map, dane wkładamy podając klucz oraz odpowiadającą mu wartość, klucze muszą być unikatowe, jednak pod jednym kluczem wystąpić może wiele wartości.

>>> tel = {'jack': 4098, 'sape': 4139}
>>> tel['guido'] = 4127
>>> tel
{'sape': 4139, 'guido': 4127, 'jack': 4098}
>>> tel['jack']
4098
>>> del tel['sape']
>>> tel['irv'] = 4127
>>> tel
{'guido': 4127, 'irv': 4127, 'jack': 4098}

Ciekawym niuansem jest możliwość dostępu do elementów sekwencji podając ujemną wartość indeksu. W Javie chcąc pobrać ostatni element listy, potrzeba mniej więcej takiego kodu: list.get(list.size() – 1); podczas gdy w Pythonie wystarczy: list[-1]. Przechodząc kolejno elementy listy użylibyśmy indeksów od 0 do len(list)-1. Ten sam efekt można osiągnąć iterując od -len(list) do -1. Taka mała rzecz, a cieszy.

Istnieją również skróty na „krojenie” sekwencji. W Javie skorzystalibyśmy z metody List.subList(), która zwraca widok oryginalnej listy. Odpowiadająca temu instrukcja Pythona to zaledwie: list[a:b], gdzie a i b to indeks początkowy i końcowy nowej listy.

s = "ABCDEF"
s[2:5]  --> "CDE"
s[4:]   --> "EF"
s[:2]   --> "AB"
s[:-1]  --> "ABCDE"
s[-1:]  --> "F"
s[:]    --> "ABCDEF"

Kolejny interesujący feature to funkcja range(a, b, c), która zwraca listę liczb od a do b (z opcjonalnym krokiem c), i która często przydaje się przy definiowaniu pętli for..in. Funkcja xrange() spełnia taką samą rolę, jednak poleca się ją stosować przy dużych rozmiarach list: zamiast alokować zbędnie duży fragment pamięci tylko po to, aby trzymać w niej uporządkowane wartości – xrange() na potrzeby iteracji tworzy tzw. lazy-list, która generuje i udostępnia jedynie elementy potrzebne w danej chwili.

# liczenie silni ze 100:
product = 1L
for i in xrange(1, 100):
    product = product * i

Pozostałe małe plusiki

Bardzo istotnym elementem kodu Pythona są białe znaki, a konkretnie wcięcia. To one określają bloki kodu. Z jednej strony jest to plus – mniej pisania, mniej linii kodu. Jednak błędnie zaaplikowane wcięcia w kodzie (np. wynikające z popularnej techniki copy-paste) mogą spowodować ciężkie do wytropienia błędy.

Świetnym ułatwieniem, które przydałoby się w innych językach, jest możliwość szeregowania (chaining) operatorów porównań:

>>> x = 5
>>> 1 < x < 10
True

Porównania wartości String’ów w Pythonie to kwestia użycia operatorów == lub !=. Daje to sporo poziom przejrzystości kodu, w porównaniu do Javy, gdzie wykorzystalibyśmy String.equals(), compare() lub compareTo().

Podobnie jak w Scali, w Pythonie możliwe jest deklarowanie funkcji wewnątrz funkcji. Zamiast powielać ten sam fragment kodu, lepiej zdefiniować i wywołać nową funkcję. Taka fragmentacja szybko mogłaby doprowadzić do zmniejszenia czytelności interfejsu danej klasy (multum krótkich metod), toteż warto zastanowić się nad umieszczeniem nowej funkcji w ciele funkcji, w której będzie ona używana. Korzystać również możemy z funkcji lambda (któtkich funkcji anonimowych), znanych m.in. z C# i Scali.

„Talk less, more action”

Podaje się, że pisząc w Pythonie, można być 5-10 razy bardziej produktywnym niż w Javie. Trudno się temu dziwić, jeśli otwarcie i odczytanie pliku tekstowego w Pythonie sprowadza się do:

file = open('plik')
file.read()

Podczas gdy w Javie należałoby zadeklarować odpowiedni bufor, utworzyć strumień podając ścieżke pliku, prawdopodobnie czytać fragmentami w pętli, całość okraszając tłustą warstwą try {} catch().

Python pozwala na dużą swobodę. Jest językiem skryptowym, ale nie oznacza to, że nie można pisać w nim kodu zorientowanego obiektowo. Oferuje zaawansowaną modularność (wprowadza pojęcie modułu i pakietu), choć właściwie całą, nawet bardziej skomplikowaną aplikację można zawrzeć w jednym pliku *.py.

Python daje duże możliwości. Może być stosowany przy projektach z wielu dziedzin, jako język podstawowy, jak i uzupełniający. Zbudujemy w nim GUI (pyGTK), napiszemy testy jednostkowe (pyUnit), utworzymy zwięzły i treściwy skrypcik użytkowy, dostarczymy plugin do Firefox’a, tudzież rozszerzenie do Blender’a, połączymy się z relacyjną bazą danych, obsłużymy dokumenty XML (wbudowane parsery SAX i DOM, narzędzia walidacji, transformacji XML, dodatkowy pakiet PyXML), wreszcie w parudziesięciu liniach zmieścimy prostego klienta email, czy komunikator sieciowy, postawimy aplikację webową (framework Django), w międzyczasie korzystając z bibliotek pisanych w C lub C++.

Ok. Gdzie jest haczyk?

Python może nie wydawać się stabilną platformą, jeśli w danym momencie korzysta się z elementów, które z czasem się zmieniają. Jeśli chce się budować większą aplikację, warto trzymać się jednej wersji języka. Niestety takie podejście też nie jest najlepsze, bo:

• Nowsze wersje bibliotek zazwyczaj powstają tylko dla najnowszych wersji Pythona
• Pewne nowe elementy Pythona mogą spowodować subtelne zmiany w działaniu aplikacji, które nie dadzą się łatwo wykryć. To z pewnością nie sprzyja biznesowi.

Weźmy konkretny przykład. W Pythonie 2.3.4 i wcześniejszym poniższy snippet powoduje wygenerowanie wyniku, którego oczekuje się po programie napisanym w C:

>>> print "%x" % -2
fffffffe

Poczynając od wersji 2.4 widzimy z goła odmienny wynik:

>>> print "%x" % -2
-2

Przedstawiona zmiana może wydawać się błaha, ale tak nie jest. W nowszej wersji Pythona zmianie uległ sposób traktowania liczb całkowitych bez znaku. Ponieważ z liczb całkowitych korzysta się nawet w najmniejszym skrypcie, tego rodzaju zmiana może nieść kolosalne konsekwencje.

Innymi słowy – Python jest na tyle młodym językiem, że jego twórcy na razie nie przejmują się kwestiami zgodności i stabilności (przynajmniej nie tak bardzo jak w Javie, w której cykle życia oprogramowania obejmują niejednokrotnie 10 lat).

Python to nie tylko maszyna wirtualna, API i składnia – to także zbiór bibliotek otaczających podstawowe funkcje systemu operacyjnego. Z założenia skrypty pythonowe mają być przenośne pomiędzy systemami operacyjnymi i hardware’m. Często ochrona przed różnicami pomiędzy systemami jest iluzoryczna, zwłaszcza w kwestii obsługi protokołów sieciowych i wielowątkowości. Np. interfejs gniazd sieciowych, stosowany w wielu programach, zgłasza inne wyjątki pod Windows, a inne pod *nix. Więc albo wyłapuje się wszystkie wyjątki, albo stosuje się osobny kod dla tych przypadków.

Z mojego, subiektywnego punktu widzenia mechanizm dołączania dodatkowych zewnętrznych bibliotek do instancji Pythona jest niekiedy mocno przesadzony. Nie wszystkie biblioteki wymagają instalacji – niektóre zwyczajnie wrzucamy do katalogu PythonXX\Lib\site-packages i po wykonaniu odpowiedniej instrukcji importu od razu są widoczne z poziomu interpretera. Inne biblioteki dostarczają cały instalator, który teoretycznie powinien wszystkim się zająć.
Ku przestrodze: Instalacja Pythona 2.6.7 pod 64bitowym Windows7 nie powinna stwarzać problemów. Jednak potem doinstalowanie dodatkowych modułów może okazać się już nie takie proste – biblioteka szuka w rejestrze informacji o ścieżkce instalacji wymaganej wersji Pythona – i nic nie znajduje. Wtedy niezwykle irytujący staje się fakt, że byle biblioteka (której kod pewnie mieści się na paru ekranach), z wielce wyszukanym instalatorem, jest nie do zainstalowania, choćbyśmy ściągali coraz to inne wersje i samego Pythona i rozszerzeń. Jakby tego było mało – deinstalacja pod Win7 trwa ~8minut, i zostawia po sobie multum śmieci, m.in. w katalogach systemowych.

Dużym minusem jest brak możliwości debuggowania wątków (oczywiście można próbować to „obejść” przy pomocy logger’a, lub pisząc dokładne testy jednostkowe).

Outro

Python jest narzędziem zorientowanym na maksymalną zwięzłość, prostotę i wysoki stopień abstrakcji. Dzięki temu pozwala na szybkie i efektywne tworzenie aplikacji. Pozwala skupić się na samej funkcjonalności programu, odkładając kwestie niskopoziomowe na dalsze tło. Byłby świetnym wyborem, kiedy przyjdzie potrzeba napisania na szybko prostego skryptu, czy niewielkiej aplikacji w ramach uczelnianego projektu. Zdaje się, że nie jest to jeszcze język na tyle dojrzały, ustabilizowany i konsekwentny, aby na jego podstawie pisać rozbudowane aplikacje biznesowe o długim cyklu życia. Chyba, że jako wyjątkowo wysoko-poziomowy język uzupełniający, stanowiący niewielką część całości aplikacji.

Polecam

http://stackoverflow.com/questions/101268/hidden-features-of-python

Na rynku istnieje mnóstwo rozwiązań Open Source, rozwiązujące różne klasy zagadnień. Mowa tu o produktach e-commerce (Magento, Presta Shop), CMS (Drupal, Joomla, WordPress), systemach klasy CRM, ERP, czy DMS, a także „community builders”, czyli np. fora internetowe (PHP BB). W zdecydowanej większości powyższych przypadków nie potrzeba wiedzy programistycznej aby wdrożyć i rozwijać serwisy. Mają one obszerne zbiory rozszerzeń i wtyczek (plugins), które pozwalają dostosowywać systemy do potrzeb. Takie podejście pozwala na znaczne zmniejszenie kosztów wdrożenia aplikacji.

Pomimo tych zalet, często jest tak, że systemy te pasują do prostych modeli biznesowych, które w życiu codziennym występują nad wyraz rzadko. W starciu z rzeczywistością, wdrażanie takich systemów, a przede wszystkim utrzymanie i reakcje na rozwój rynku mają przełożenie na zasadę Pareto, która mówi o tym, że 80% funkcjonalności jesteśmy w stanie osiągnąć w 20% czasu, a 20% krytycznych funkcji systemu konsumuje 80% budżetu.

Głównymi problemami z jakimi spotykają się wdrożenia oparte o gotowe rozwiązania to przede wszystkim komplikacja logiki biznesowej systemu, której nie da się odwzorować na możliwości produktu. Często dochodzi do paradoksalnych sytuacji, w których model biznesowy trzeba dopasowywać do systemu, co nigdy nie powinno mieć miejsca. Inną kwestia jest rozwój aplikacji i zwiększenie ruchu, które powoduje, że dobrze działające oprogramowanie dla małej liczby użytkowników staje się bezużyteczne przy wielkim obciążeniu. Poza tym istnieje potencjalne ryzyko związane z atakami hakerskimi, gdyż kod jest otwarty i dostępny dla potencjalnych włamywaczy. Aby dostrzec skalę problemu, wystarczy przejrzeć serwisy z dostępnymi exploitami. Ostatnią kwestią, która przychodzi w tym momencie na myśl, jest to, że czasem społeczność rozwijająca dany produkt, w pewnym etapie może zaprzestać dalszych prac. Powodów może być kilka, raz jest to skłócenie zespołu, innym razem przejście na nową technologię, lub do innego projektu, pozostawiając dotychczasowych użytkowników samych sobie.

Zalety tworzenia oprogramowania dedykowanego

Wszystkie problemy opisane powyżej rozwiązuje oprogramowanie dedykowane, a nawet można się pokusić o stwierdzenie, że wnosi tutaj wiele wartości dodanych. Przede wszystkim klient dostaje dokładnie to czego potrzebuje i za co płaci. Oczywiście trzeba mieć na względzie, że nie każdy klient jest osobą techniczną i nie koniecznie musi mieć doświadczenie z systemami informatycznymi, więc doradztwo technologiczne jest tutaj nieocenioną wartością. Firma programistyczna na etapie przygotowania oferty doradza klientowi najlepsze rozwiązania, proponuje pewne opcje, tworząc przy tym najlepszą możliwą ofertę, budując relację i zaufanie z zamawiającym. Dzięki temu klient odzwierciedla swój model biznesowy w tworzonym systemie, nastawiając się na zysk z inwestycji w przyszłości. Poza tym oprogramowanie jest gotowe na rozwój, co jest bardzo ważnym czynnikiem, gwarantującym skuteczność przedsięwzięcia i reakcję na sygnały spływające od użytkowników lub na trendy rynkowe. Ważnym czynnikiem jest tutaj również samopoczucie programistów, którzy nie klikają w panelach administracyjnych Drupala czy Magento, ale programują i rozwiązują problemy, realizując się przy tym zawodowo.

Nie wynajdujemy koła od nowa, czyli o frameworkach słów kilka

Framework to z definicji zestaw uniwersalnych narzędzi na bazie których tworzy się aplikacje. Nie wyobrażalne jest, aby w tych czasach tworzyć systemy informatyczne bez wykorzystania takiego narzędzia. Aby lepiej zobrazować temat, możemy porównać do płyty podwoziowej samochodu. Daje nam ona wszelkie potrzebne mechanizmy, czyli ramę całego auta, łożyska, układ wydechowy, wiązki elektryczne. Na takiej ramie możemy stworzyć wiele rodzajów samochodów, np. pickup, miejski hatchback, średniej klasy sedan, lub ekskluzywny, drogi wóz. Podobnie jest z frameworkiem – zapewnia mechanizmy potrzebne w większości systemów. Mowa przede wszystkim o kontrolerze aplikacji, reagującym na żądania użytkownika, warstwie widoku, prezentującą dane w formie graficzne, warstwie dostępu do bazy danych, mechanizmie bezpieczeństwa, pozwalającą na autoryzowanie użytkowników i ograniczanie dostępu do poszczególnych części serwisu. To tylko niektóre z rozwiązań, nowoczesne frameworki dostarczają wiele więcej. Inną kwestią jest standaryzacja kodu tworzonego przy ich użyciu. Jest o wiele łatwiej nowej osobie wejść w projekt, jeśli framework narzuca standardy kodowania i rozwiązania umieszczane są w odpowiedniej strukturze kodu. Pozwala to na szybsze wdrażanie się nowych członków zespołu, a co za tym idzie na przyspieszenie całego rozwoju.

Jest jeszcze jedna ważna kwestia, która decyduje o sukcesie danego frameworka – liczba gotowych rozwiązań w postaci wtyczek lub komponentów. Jest to sytuacja analogiczna do gotowych rozwiązań Open Source, z tym, że tutaj łatwo rozszerzyć dany komponent oraz dostosować go do wymagań systemu. Mamy też zapewnione wsparcie społeczności w kwestii rozwiązywania problemów, tworzenia nowych funkcjonalności czy aktualizacji i wydawania poprawek.

Dlaczego Symfony2 pasuje tutaj jak ulał?

Symfony2 kontynuuje dobrą passę swojego poprzednika, który istnieje już 6 lat. Programiści wyciągnęli naukę z poprzedniej wersji, podpatrzyli rozwiązania z innych platform (Java, Ruby On Rails, Python i Django, czy Zend Framework) i przepisali całość od podstaw. Dzięki temu powstał najlepszy aktualnie framework PHP, który wygrywa przede wszystkim bardzo dobrą strukturą niezależnych modułów, które można rozwijać oddzielnie, a nawet wykorzystywać w innych projektach. Autorzy przewidzieli strukturę projektu tworząc tzw. Bundle, które są modułami, gotowymi do użycia w innych projektach (nawet wnętrze frameworka się z nich składa). W tym momencie warto wspomnieć o Bundlach dostarczanych przez programistów i firmy zewnętrzne (jest ich już prawie 600). Całość systemu jest oparta o nowoczesny kontener wstrzykiwania zależności (Dependency Injection Container), przez co podmiana kluczowych części systemu może być zrobiona w mgnieniu oka (to rozwiązanie bardzo szeroko stosuje się w Java EE oraz innych dojrzałych rozwiązaniach). Warto też zauważyć, że autorzy duży nacisk kładą na wydajność i szybkość działania, co jest zauważalne na pierwszy rzut oka, bez wnikliwych badań obciążeniowych.

O powadze sytuacji świadczy też fakt, że Symfony2 zostało w całości przeniesione do gita i jego kod jest utrzymywany w serwisie Github.com. Dzięki temu każdy może go sklonować kod źródłowy, pracować na nim lokalnie wprowadzając poprawki czy tworząc nowe funkcjonalności, a później jednym kliknięciem wysłać prośbę o włączenie swoich zmian do głównego repozytorium. To powoduje, że na dzień dzisiejszy Symfony2 jest najczęściej rozgałęzianym i najchętniej oglądanym repozytorium PHP na Githubie, a liczba osób, które miały swój wkład w rozwój przekracza 250. Poza tym za frameworkiem stoi francuska firma Sensio Labs, wraz z założycielem i głównym programistą Fabienem Potencierem. Ten fakt zapewnia stabilność rozwoju, wysoką jakość dokumentacji oraz dostępność szkoleń i materiałów. Firma ta zorganizowała nawet zbiórkę pieniędzy wśród społeczności i zleciła audyt bezpieczeństwa organizacji zajmującej się tego typu działaniami .

Reasumując, trzeba przyznać, że Symfony2 zrewolucjonizowało świat frameworków PHP, a można się nawet pokusić o stwierdzenie, że programiści innych języków (Python, Ruby, Groovy) też z szacunkiem patrzą na to rozwiązanie. Symfony2 idealnie nadaje się do rozwoju aplikacji dedykowanych i na pewno można go polecić do większości projektów.

W wielu miastach na całym świecie odbywają się imprezy związane z premierą Symfony2. Także w Polsce programiści i osoby zainteresowane rozwojem tego frameworka będą mogły spotkać się i porozmawiać o jego możliwościach i zastosowaniach. W Gliwicach w siedzibie firm XSolve (branża software development) oraz Chilid (agencja New Marketing) w czwartek (28.07) odbędzie się XSolve Poland Symfony2 Launch Party! Impreza ma charakter otwarty i skierowana jest głównie do programistów pracujących we frameworku Symfony2 oraz osób działających w branży IT. Impreza organizowana jest przy promocyjnym wsparciu Wydawnictwa Helion, które zapewniło wartościowe nagrody dla gości, którzy wezmą udział w zaplanowanych konkursach.

Spotkanie rozpocznie się o godzinie 17.00, w trakcie jego trwania odbędzie się prezentacja Symfony2, będzie również możliwość wymiany doświadczeń z programistami XSolve, którzy na co dzień korzystają z tego frameworka.

Polub wydarzenie na Facebooku!

Jednogłośnie uznaliśmy, że najlepszym wykładem był Domain-Driven Design Sławomira Sobótki, który w bardzo przystępny sposób pokazał tą technikę projektowania i modelowania systemów. DDD ma zastosowanie szczególnie tam, gdzie model domenowy jest bardzo złożony, a czas życia systemu liczy się w latach.

Ciekawa była również prezentacja Bartka Majsaka „Jak wycisnąć maksimum z testów”. TDD nie jest nam obce, ale podejścia jakie pokazał Bartek bardzo nam przypadły do gusty. W szczególności mam tu na myśli testy behawioralne oraz nagrywanie wykonania testów techniką screen-capture, co pozwala nam błyskawicznie przejrzeć testy funkcjonalne, które nie zakończyły się sukcesem.

Dwa wykłady były poświęcone tylko i wyłącznie Scali, którą nazywa się czasem następcą Javy. W szczególności pasowały one Pawłowi, który jest zapalonym miłośnikiem tej technologii i firmowy ekspertem w tej dziedzinie. Szczególnie zaciekawiło nas usytyuowanie Scali w klasie rozwiązań Enterprise, które prezentował Paweł Dolega.

Oczywiście nie ominęliśmy też prelekcji o architekturze modelu dla rozwiązań NoSQL. Prowadzący spotkał się z niemałymi sprzeciwami z widowni, dzięki czemu prezentacja nabrała dynamiki i zmusiła Jarosława do usilnego bronienia swoich poglądów :-)

Podsumowując, konferencję oceniamy pozytywnie. Nie ma zarzutów co do organizacji, która była na prawdę na wysokim poziomie, aczkolwiek mieliśmy wrażenie, że 45 minutowe prezentacje rzadko komu wystarczały, żeby przeprowadzić pełny wykład. Większość prelekcji była dobrze przygotowana i przeprowadzona, aczkolwiek zdarzały się też takie, które wymagają większego wysiłku w przyszłości :-) Generalnie Confiturę uznajemy za udaną i z chęcią wybierzemy się również w przyszłym roku.