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.

Zaczęło się niewinnie, przyszło zgłoszenie od testerów, że aplikacja zajmuje strasznie dużo pamięci, a przy wykonywaniu pewnej operacji ta zajętość jeszcze rośnie i wielce nazywać to chcieli memory leakiem. Jako programista raczej nie dowierzałem, przecież w dot-necie tak być nie może, zgodnie z teorią pamięć sama się zwalnia, Pan Garbage Collector robi wszystko za nas… pomijając fakt że programista generalnie nie wierzy testerom, którzy zawsze szukają dziury w całym…

ot… teoretycznie…

Godzina 1

kawa i te sprawy… partyjka piłkarzyków, przecież zadanie na pewno zostanie odbite!

Godzina 2

Sprawdzam – i już widzę, że jednak coś jest na rzeczy. Coś się nie zwalnia. Dziwne…

Godzina 3

No tak – testerzy jak to w ich zwyczaju coś znaleźli, ale sami nie wiedzieli co. Nie trzeba nawet wykonywać zgłoszonej akcji… wystarczy wejść do okienka i wyjść z niego. I tak kilka razy i task manager poda nam jakieś fantastyczne, zawrotne sumy pożeranej przez naszą aplikację pamięci.

Godzina 4

Kod przeanalizowany, wszystko co trzeba zdaje się być zwalniane. Wszystko gra, a jednak… jednak nie… Powoli pojawiają się jednak promyki nadziei na znalezienie przyczyny.

Godzina 5

Nadzieja rośnie, podejrzany jest namierzony – udało się zablokować przeciek. Ale coś jednak tutaj nie pasuje, coś jest nie-tak. Bug niby zwalczony, ale wewnątrz płonie ogień buntu, że przecież to nie była faktyczna przyczyna. Trzeba sięgnąć po cięższą artylerię. Trzeba skombinować jakiegoś profilera z opcją analizy pamięci. Na pierwszy ogień idzie ANTS Memory Profiler firmy Red Gate („tej od .NET Reflectora”). Piłkarzyki, kawa… w końcu musi się pobrać i zainstalować (tak trochę tej kawy dzisiaj… to piątek, zmęczenie tygodnia się kumuluje, a rano wstałem o 5:15… pobiegać…)

Godzina 6

Profiler odpalony, bardzo pozytywne zaskoczenie, intuicyjność pierwsza klasa, bez czytania tutoriali, bez instrukcji w ciągu kilku minut znajduję – prawdziwą przyczynę błędu. Otóż okienko WPF zostaje w pamięci, a jest trzymane przez… przez jego własną kontrolkę! Przecież to niemożliwe… przecież „GC” wykrywa i cykliczne referencje i w ogóle te wszystkie szmery bajery…

Mija jeszcze kilka chwil zanim ogarnę cały temat…

Sprawdzam co to za kontrolka, Google, dokumentacja MSDN i robi mi się smutno, dopisuję 1 (słownie jedną) linię kodu i „fixuję buga w JIRA’ze”.

Po przydługim wstępie wytłumaczenie na przykładzie, dla uproszczenia malutka aplikacja WPF – 2 formatki i jedna klasa oczywiście:

Okienko główne z buttonem i akcją otwierającą nowe okienko:

<Window x:Class=”MemoryLeaking.Window1″
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
Title=”Window1″ Height=”170″ Width=”306″>
<Grid>
<Button Margin=”50,50,50,50″ Click=”Button_Click”>Take the RAM!</Button>
</Grid>
</Window>

namespace MemoryLeaking
{
/// <summary>
/// Interaction logic for Window1.xaml
/// </summary>
public partial class Window1 : Window
{
public Window1()
{
InitializeComponent();
}

private void Button_Click(object sender, RoutedEventArgs e)
{
new MemoryTakingWindow().ShowDialog();
GC.Collect();
}
}
}

Klasa „zjadająca RAM” (banalnie prosta – lista stringów, do każdego przypisujemy GUID):

namespace MemoryLeaking
{
class MemoryTakingClass
{
private List<string> MemoryTaker;

public MemoryTakingClass()
{
MemoryTaker = new List<string>(100000);

for (int i = 0; i < 100000; i++)
{
MemoryTaker.Add(Guid.NewGuid().ToString());
}
}
}
}

Okienko „zjadające RAM”:

<Window x:Class=”MemoryLeaking.MemoryTakingWindow”
xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”
xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
xmlns:winForms=”clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms”
Title=”MemoryTakingWindow” Height=”134″ Width=”306″>
<Grid>
<WindowsFormsHost Name=”host”></WindowsFormsHost>
</Grid>
</Window>

namespace MemoryLeaking
{
/// <summary>
/// Interaction logic for MemoryTakingWindow.xaml
/// </summary>
public partial class MemoryTakingWindow : Window
{
public MemoryTakingWindow()
{
InitializeComponent();

this.DataContext = new MemoryTakingClass();
}
}
}

Wszystkich estetów wyczulonych na GC.Collect() proszę o wybaczenie. Użycie tego wywołania w naszym przykładzie ma bardzo głęboki sens – chodzi o to, by mieć pewność, że w pamięci zajmowanej przez proces będą zajęte wyłącznie bajty rzeczywiście zajęte. Zresztą czasem takie wywołanie ma głębszy sens, chociaż oczywiście lepiej go unikać i projektować aplikację tak, by nie było ono potrzebne. To jednak temat na osobne dyskusje.

Dla wyjaśnienia – oprócz przekopiowania powyższego kodu do własnej aplikacji należy jeszcze dodać do projektu referencję do biblioteki WindowsFormsIntegration (z niej pochodzi ta dziwna kontrolka <WindowsFormsHost>. Kontrolka służy do hostowania kontrolek pochodzących z tradycyjnych “winformsów” w kontrolkach / oknach WPF.

I teraz – do dzieła. Najpierw wykres zużycia pamięci dla takiej aplikacji, po kilku wywołaniach okna MemoryTakingWindow:

Gdybyśmy byli budowniczymi moglibyśmy się cieszyć z (prawie) równych schodów, jednak jako programiści wpadamy właśnie w konsternację… przecież to niemożliwe, żeby takie cyrki działy w aplikacji .NET!

Dokładnie to samo czułem. Pierwsza myśl skierowała mnie na DataContext (tutaj oczywiście uproszczony), gdyż w rzeczywistej aplikacji klasa do niego podpinana zabierała najwięcej pamięci i przechowywała olbrzymie ilości danych. Dokonałem małej modyfikacji w celu weryfikacji podejrzeń – mianowicie do klasy DataContext dodałem finalizer (u nas byłby to ~MemoryTakingClass(){ }) i postawiłem tam breakpointa. Breakpoint po kilku minutach miał wciąż tyle trafień, co nasz reprezentacja w ostatnim meczu z Litwą (dla mniej zorientowanych – 0).

Pierwsza myśl była banalnie prosta, skoro tam gdzieś jakieś zależności się trzymają, to przecież wystarczy odpiąć DataContext od kontrolki! Czyli dodać taki kod:

Closed += ((sender, e) =>
{
this.DataContext = null;
});

na przykład gdzieś w konstruktorze naszego okienka MemoryTakingWindow. Postęp jest natychmiastowy – po powtórzeniu doświadczenia otrzymujemy dużo ładniejszy wynik w postaci ząbków:

Pięknieje także liczba trafień w breakpointa – staje się dokładnie równa liczbie wywołań okna.

Na tym etapie można by zamknąć zadanie i przejść dalej. Jednak bardziej dociekliwym jednostkom jest wciąż mało i wciąż coś nie gra. Dlaczego przecież wcześniej obiekt klasy MemoryTakingClass nie był zwalniany? Dlaczego ciągle coś go trzymało, fakt uwolnienia go po odpięciu od DataContext jest podejrzany – oznacza przecież, że… coś ciągle trzyma okienko! Tylko co i dlaczego, no i czy na pewno.

Tutaj właśnie sięgnąłem po grubą altyrerię w postaci ANTS Memory Profilera. Po uruchomieniu aplikacji w Profilerze wykonujemy “doświadczenie” (otwarcie kilkukrotne okienka) i używamy funkcji “Take memory snapshot”, po czym w szukamy naszych klas na liście:

Tutaj wybieramy naszego “podejrzanego” i wykorzystujemy opcję “Instance list”, która zwraca nam listę wszystkich instancji klasy istniejących w momencie stworzenia snapshota.

I cóż to?! W pamięci zalega nam 5 obiektów okna! Wiemy już gdzie leży przyczyna całej tej udręki – a odpinanie DataContext nie było fixem, a tylko ograniczeniem uciążliwości błędu – pozbywamy się z pamięci najcięższych obiektów, ale niestety nie wszystkich. Pozostaje ostatni krok – odpowiedź na pytanie – co powstrzymuje nasze okno przed zwolnieniem? Musimy prześledzić wszelkie referencje do niego. Gdyby przyszło nam w tym momencie analizować kod…

Całe szczęście możemy wykorzystać ostatnią “prezentowaną” dziś opcję ANTS Profilera – “Instance Retention Graph”. Jest to graf przedstawiający łańcuchy obiektów wstrzymujących Garbage Collectora przed “skolekcjonowaniem” naszych obiektów. Analizując ten graf wypatrujemy wszystkich niepewnych połączeń, w naszym przypadku wygląda to tak:

Już pierwszy stopień od okna pokazuje kontrolkę WindowsFormsHost, co rodzi pytanie – dlaczego kontrolka będąca “dzieckiem” naszego okna miałaby niby blokować jego sprzątnięcie?

Patrzymy “stopień wyżej” na klasę “WinFormsAdapter”, której pole _host zawiera referencję do naszego hosta – klasa ta nam zapewne za wiele nie mówi (co nie dziwi, gdyż jest to wewnętrzna klasa w WindowsFormsIntegration).

Stopień wyżej widzimy klasę ProcessInputEventHandler, po nazwie i polu (_target) sądzić można, że metoda klasy WinFormsAdapter obsługuje zdarzenie PostProcessInput pochodzące z klasy InputManager.
Gdyby bardziej zgłębić kalsę InputManagera – okazuje się, ze ma ona statyczne pole Current i do niego właśnie podpina się WindowsFormsHost za posrednictwem klasy WinFormsAdapter, z tego powodu referencja do kontrolki jest trzymana “na zawsze”, a co za tym idzie blokuje całe nasze okno. Co gorsza okno blokowało obiekt podpięty do DataContext, a obiekt ten mały zdecydowanie nie był!

Gdyby za każdym razem zanim użyje się kontrolki przestudiować MSDN można by zauważyć, że klasa dziedziczy po HwndHost, który jak wszyscy wiemy implementuje interfejs IDisposable… zaraz nie wszyscy? i wcale mnie to nie dziwi… w każdym razie –  jeżeli nawet pośrednio nasza kontrolka dziedziczy po IDisposable, to  po skończeniu pracy z naszą kontrolką wystarczy wywołać metodę Dispose() i wszystko będzie działać jak należy.

Zmieniamy zatem naszą obsługę zdarzenia Closed na następującą:

Closed += ((sender, e) =>
{
this.host.Dispose();
});

i wszystko gra – wykres zajmowanej pamięci właściwie się nie zmieni w porównaniu do poprzedniego (niepełnego) fixa, gdyż nasze okienko samo w sobie pamięci za wiele nie pochłania (brak zauważalnych efektów), ale już wynik działania profilera – owszem. Na liście klas nie znajdziemy już pozycji MemoryTakingWindow (pod warunkiem, że okienko nie jest otwarte podczas pobierania snapshota, oczywiście).

Kilka wniosków na koniec:
- Panowie z Red Gate mają głowy na karku. Wiedzą co programiści lubią – ich narzędzia są świetnie wykonane, bardzo funkcjonalne, a zarazem intuicyjne i estetyczne. W celu znalezienia mojego błędu nie potrzebowałem korzystać z żadnej dokumentacji, czy instrukcji. Wszystko wydawało się super-naturalne!

- kontrolka WindowsFormsHost lubi zrobić psikusa. Należy pamiętać, że przy zamykaniu okna należy wywołać metodę Dispose (wg. informacji znalezionych „na Google’u” bywa tak, że trzeba ją najpierw jeszcze ręcznie usunąć z nadrzędnego grida, czy innego kontenera, jednak nie ręczę za prawdziwość tej informacji, tylko przestrzegam przed ewentualnością). Nie jest to wiedza “oczywista” i raczej wymaga przekazania informacji przez kogoś, bądź też kilku godzin męki – jak w moim przypadku.

- WPF jest “fajny” i daje sporo możliwości, ale czyha tu na programistę wiele przykrych niespodzianek, które mogą napsuć krwi. Nie jest to jedyny tego przykład

- teoretycznie winą programisty są konsekwencje nie zwolnienia zasobów i nie wywołania metody Dispose w klasie implementującej interfejs IDisposable.

I… kilka usprawiedliwień:

- kontrolka WindowsFormsHost, jak to przystało na kontrolkę WPF dodawana jest w XAML‘u – a z tego poziomu raczej ciężko stwierdzić, że akurat TA kontrolka rozwija jakiś tam interfejs. Metod również nie zobaczymy w intelisensie – nawet przypadkiem…

- oczywiście wypadało zajrzeć na dokumentację kontrolki przed jej użyciem – szczególnie takiej „wyjątkowej” – ale jak to już było wyżej zaznaczone, WindowsFormsHost nie implementuje IDisposable bezpośrednio, a poprzez klasę bazową, więc i w dokumentacji na pierwszy rzut oka nie widzimy nic nakierowującego nas.

- podpinanie się pod zdarzenia statycznych pól jest generalnie mechanizmem „trochę dziwnym” i ryzykownym i dość często odradzanym. Jeśli o mnie chodzi – mam wrażenie, że kod pod WindowsFormsHost mógłby być napisany troszkę lepiej – w celu zniwelowania tego ryzyka.

- kontrolki implementujące interfejs IDisposable to rzadkość i raczej niewielu programistów spodziewa się takiego psikusa.

- Czytelnikowi wydać się może dziwne – przecież w przykładzie na pierwszy rzut oka widać, że to WidnowsFormsHost coś tu miesza, jednak w naszej prawdziwej aplikacji – jak to w życiu rzeczywistym – kontrolka nie rzucała się w oczy… była dodana do formatki pośrednio (stanowiła element innej kontrolki dodanej do okienka), ponadto stanowiła jedną z kilkudziesięciu kontrolek, a przy tym zdecydowanie nie istotna, pokazywała się tylko na kilka chwil i miała rozmiar kilkunastu px…)

- to nie ja dodałem kontrolkę do tamtego formularza ;)

- nadmierne pseudo-poczucie humoru we wpisie jest implikacją pory oraz dnia, w którym powstawał. Czyli „jakiś weekendowy wieczór” ;)

1. pobrania repozytorium na dysk
2. stworzenie konfiguracji vhost z jakąś nazwą serwera
3. stworzenie wpisu w /etc/hosts który będzie odzwierciedlał nazwę serwera użytego w vhoście na 127.0.0.1

Jestem pewny, że powyższa ścieżka jest używana przez wielu programistów. Możemy pominąć dwa ostatnie kroki, ograniczając przygotowanie środowiska do umieszczenia kodu źródłowego w specjalnym folderze na dysku. Aby to osiągnąć potrzebujemy moduł Apache’a mod_vhost_alias oraz prosty serwer DNS, który będzie rozwiązywał lokalne domeny dla nas.
Instalacja mod_vhost_alias jest dość prosta. Moduł jest prawdopodbnie dołączony do twojej instalacji Apache, pozostaje go tylko uruchomić następującą komendą:

sudo a2enmod vhost_alias

Dzięki mod vhost alias możemy dynamicznie wskazywać Document Root bazując na nazwie serwera. Wystarczy umieścić następującą konfigurację w pliku /etc/apache2/sites-enabled/000-default

Teraz wszystkie odwołania będą wskazywały na nasz /var/www/FIRST_PART_OF_DOMAIN/web, ponieważ użyliśmy modyfikatora %1. Możesz wprowadzić własną konwencję używając innych modyfikatorów w dyrektywie  VirtualDocumentRoot (patrz dokumentacja). Powyższa konfiguracja jest bardzo minimalistyczna, powinieneś dodać do niej jeszcze logowanie itp.

Ostatnią rzeczą, o jaką należy się zatroszczyć jest dynamiczne rozwiązywanie nazw domen. Najprostszym sposobem jest dodawanie nazwy serwera do pliku /etc/hosts, ale to wymaga dodawania wpisu dla każdego hosta. Na przykład wpis w /etc/hosts:

 127.0.0.1 myapp.local.dev

uruchomi aplikację zlokalizowaną w  /var/www/myapp/ (wskaże na katalog web/, według konwencji symfony). Jeśli chcesz to zautomatyzować, zainstaluj dnsmasq, prosty serwer DNS

sudo apt-get install dnsmasq

Następnie wyedytuj /etc/dnsmasq.conf file (może być położony gdzie indziej, tutaj na przykładzie Ubuntu):

listen-address=127.0.0.1
address=/.local.dev/127.0.0.1

Ostatnią rzeczą jest aktualizacja pliku /etc/resolv.conf przez dodanie adresu naszego DNSa na początek:

nameserver 127.0.0.1

Następnie restartujemy dnsmasq i Apache2:

sudo /etc/init.d/apache2 restart
sudo /etc/init.d/dnsmasq restart

Od teraz możesz się cieszyć nową konfiguracją środowiska LAMP. Każdy nowy projekt potrzebuje być tylko umieszczony w katalogu  /var/www/PROJECT_NAME i będzie od razu dostępny z poziomu przeglądarki pod adresem  PROJECT_NAME.local.dev