Posts Tagged ‘symfony’

Kiedy i dlaczego tworzyć oprogramowanie pod klucz i dlaczego framework Symfony2 pasuje tu jak ulał?

Author: Wojtek Sznapka (wojciech.sznapka) | wrzesień 20th, 2011
avatar

Gotowe rozwiązania Open Source

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.

Symfony2 Showcase

Author: Wojtek Sznapka (wojciech.sznapka) | styczeń 31st, 2011
avatar

Podczas pierwszego Piątku z XSolve w tym roku oraz pierwszego w nowej siedzibie, poprowadziłem prezentację na temat Symfony2, które wkrótce ujrzy światło dzienne. Symfony2 zostało przepisane od zera, porzucono kompatybilność wstecz, czego rezultatem jest nowoczesny framework, pozwalający szybko tworzyć bardzo złożone aplikacje. Nadąża on za najaktualniejszymi trendami w brażny, a autorzy chwalą się trzykrotną poprawą wydajności i zmniejszeniem użycia pamięci o połowę.
Aktualnie można przetestować Symfony2 pobierając wersję Preview Release 5 githuba. Ja już to zrobiłem, czego rezultatem jest poniższa prezentacja :-)

Doctrine cache

Author: Paweł Sołtysek (pawel.soltysek) | styczeń 17th, 2011
avatar

Użycie mechanizmu keszującego (ang. cache) jest powszechnie uznawane za jedną z najefektywniejszych metod optymalizacji. Niestety mimo licznych zastosowań często pomija się wykorzystanie tego mechanizmu w celu przechowywania wyników zapytań do baz danych. Tymczasem dzięki wbudowanemu w Doctrine wsparciu dla keszowania możemy łatwo przyspieszyć obsługę zapytań SQL w naszych aplikacjach.

Konfiguracja

Podstawowa konfiguracja polega na ustawieniu odpowiedniej klasy sterownika oraz strategii keszowania. Doctrine dostarcza klasy sterowników dla większości powszechnie używanych mechanizmów keszujących (APC, XCache, memcache) oraz dwie strategie keszowania (keszowanie wyników procesu parsowania zapytań DQL oraz keszowanie wyników zapytań SQL). W zależności od potrzeb konfigurację możemy przeprowadzić globalnie (do wyboru mamy konfigurację managera lub połączeń) lub lokalnie z poziomu konkretnego zapytania.

Pracując z symfony ustawienia globalne najlepiej zdefiniować poprzez dodanie metody configureDoctrine() klasy ProjectConfiguration. W zależności od wybranej strategii rejestrujemy sterownik poprzez ustawienie odpowiedniego atrybutu (Doctrine_Core::ATTR_QUERY_CACHE lub Doctrine_Core::ATTR_RESULT_CACHE). Dodatkowo poprzez ustawienie atrybutu Doctrine_Core::ATTR_*_CACHE_LIFESPAN możemy ustawić czas ważności rekordów.

Powyższa konfiguracja obejmuje wszystkie połączenia nawiązywane przez Doctrine. Czasem może zaistnieć potrzeba ograniczenia konfiguracji do konkretnego połączenia (na przykład jedno z dwóch połączeń jest nawiązywane do bazy danych modyfikowanej przez inną aplikacje). W takiej sytuacji możemy użyć metody configureDoctrineConnectionName() zastępując człon Name nazwą naszego połączenia.

W razie potrzeby konfigurację możemy przeprowadzić z poziomu konkretnego zapytania. Służą do tego metody useQueryCache() oraz useResultCache() (w dalszej części artykułu poznamy szersze zastosowanie tych metod). Konfiguracja lokalna nadpisuje konfigurację globalną.

Keszowanie w praktyce

Mając poprawnie skonfigurowany sterownik jesteśmy gotowi, aby zastosować mechanizm keszujący do naszych zapytań. Kolejne kroki zależą od poziomu konfiguracji oraz wybranej strategii keszownia. Dla przykładu, jeśli wybraliśmy konfigurację globalną oraz keszowanie wyników zapytań, należy powiadomić Doctrine, które zapytania mają być keszowane (keszowanie wyników procesu parsowania DQL jest automatycznie zastosowane do wszystkich zapytań). Służy do tego wczesniej poznana metoda useResultCache(). Metoda ta jako pierwszy parametr przyjmuje instancję sterownika lub wartość logiczną, który informuje czy dane zapytanie ma być objęte mechanizmem keszowania. Drugi parametr określa czas ważności rekordu dla naszego zapytania, natomiast trzeci jest identyfikatorem tego rekordu.

W ten sposób wynik zapytania po pierwszym wykonaniu zostanie umieszczony w mechanizmie keszującym pod nazwą sample_query na okres jednej godziny. W ciągu tej godziny każde kolejne wykonanie zapytania będzie oddelegowane do mechanizmu keszującego.

Przekazując do zapytania dodatkowe parametry, musimy zadbać, aby każdemu ich zestawowi odpowiadał inny ciąg identyfikujacy wynik zapytania. Doctrine automatycznie wygeneruje odpowiedni identyfikator jeśli nie podamy go jawnie. Takie rozwiązanie jest niewygodne jeśli mamy w perspektywie zarządzanie zawartością mechanizmu keszującego (musimy znać idnentyfikator). Więcej o zarządzaniu wynikami operacji keszowania można przeczytać w poniższym paragrafie.

Metoda useQueryCache() poza tym, że nie przyjmuje trzeciego parametru (identyfikatora) działa analogicznie do useResultCache(). Szczegółowe informacje można znaleźć w dokumentacji API.

Co dalej?

Keszowanie wyników zapytań niesie ze sobą pewne niebezpieczeństwo – dane mogą szybko stać się nieaktualne. Wraz ze sterownikami otrzymujemy zestaw metod umożliwiających zarządzanie zawartością mechanizmu keszującego. W połączeniu z mechanizmem zdarzeń możemy automatycznie usuwać skeszowane wyniki, zapewniając sobie w ten sposób aktualność danych.

Wolne od takich problemów jest keszowanie wyników parsowania DQL, które zarządzane jest przez Doctrine automatycznie.

Podsumowanie

Pomimo oczywistych zalet, stosowanie mechanizmu keszującego powinno być dobrze przemyślane. O ile keszowanie sparsowanych zapytań DQL jest bezpieczne (jeśli stosujemy prepared statements) i zaleca się jego użycie w większości projektów, to wykorzystanie skeszowanych wyników zapytań powinno dotyczyć tylko wybranych przypadków, w których ma sens i faktycznie przyniesie nam korzyści. Nie należy zapominać tutaj o zasadzie, że nie wszystko co zostało opisane jako dobra metoda na polepszenie wydajności aplikacji, będzie dawało taki rezultat we wszystkich sytuacjach.

Konfiguracja projektu w symfony pod Test Driven Development

Author: Wojtek Sznapka (wojciech.sznapka) | październik 22nd, 2010
avatar

W projektach symfony, korzystając z wbudowanego mechanizmu do testów jednostkowych (lime), można łatwo programować w oparciu o nurt Test Driven Development (TDD).

Aby przygotować środowisko do TDD wystarczą trzy kroki:

  1. Konfigurujemy połączenie do testowej bazy, którą będzie sqlite przechowywane w pamięci. W pliku config/databases.yml dopisujemy:
  2. Tworzymy dane testowe, tzw. fixtures, które umieszczamy w folderze test/fixtures (należy go stworzyć ręcznie). Celowo nie umieszczamy danych w data/fixtures, gdyż tam powinny znaleźć się testowe dane, które mogą być użyte np. podczas prezentacji systemu. Jeśli chcemy zachować kolejność danych, możemy ponumerować pliki yml, np.
  3. Tworzymy plik bootstrap dla testów opartych o bazę danych (test/bootstrap/model.php). Plik ten stworzy strukturę tabel na podstawie modelu i załaduje je do bazy oraz wprowadzi dane testowe (fixtures). „Dziedziczy” on pewne ustawienia z bootstrapu unit.php. Trzeba z niego korzystać zawsze, gdy przychodzi potrzeba odwoływania się w testach do bazy danych.

Następnie uruchamiamy ./symfony test:unit i podziwiamy, jak nasze testy przechodzą w stu procentach :-)
Powyższa konfiguracja była testowana dla symfony 1.4 z doctrine 1.2