(V)iew, przygłupi kolega każdego MC
kwi/1028
Gdzieś tam w świecie przed firewallem, w wybranej aplikacji stworzonej przez wybranego programistę istnieje znany wszystkim kontroler. Ten sam kontroler, który właśnie przed chwilą otrzymał od dyspozytora pałeczkę przy przetwarzaniu żądania. Pobudzony i gotowy do działania ma na wyciągnięcie ręki półkę z modelami. Jest pewnego rodzaju pośrednikiem, tytułowany często strażnikiem cnoty widoku. Z modelów wyciąga tylko to co dla widoku najodpowiedniejsze. Gdy kontroler jest na służbie, wspomniany współpracownik niezdolny do samodzielnego myślenia może czuć się naprawdę bezpiecznie. Kontroler mógłby być więc niezwykle dumnym i bardzo szczęśliwym komponentem, chodzić z podniesioną głową wśród wzorca MVC. Niestety jest jeden mały szkopuł. W kontrolerze widać już oznaki wypalenia zawodowego. Nie ma co wieszać psów na biednym komponencie, że leniwy, że niedostosowany do wymagań wolnego rynku. To szefostwo zrzuca na niego coraz więcej obowiązków i zatrudnia oprócz niego jako widok, głąba. W swojej pracy codziennej nasz kontroler jest zasypywany przez programistę stosem zmieniających się kilka razy dziennie zamówień na coraz różniejsze porcje danych dla niegrzeszącego bystrością widoku. Tutaj z 5 newsów zrobiło się 7, tam trzeba pobrać dodatkowo pole z tabeli, a jeszcze gdzieś indziej użytkownik będzie chciał poznać aktualną datę. To tylko szczyt góry lodowej. A mogłem zostać marynarzem, powiedziałby kontroler.
Wolałbym nazwę HyperPHP albo cokolwiek
lut/109
Po buńczucznym i hip hip hurra wpisie o modelu implementacji serwisów internetowych, przyszedł czas na projekt Facebooka związany z PHP, czyli HipHop. Międzynarodowa społeczność żyje podekscytowana tym projektem już od ponad tygodnia, więc nie mogłem go sobie ot tak pominąć. Od nagłówków z nazwą HipHop, nazwą głupią nadmienię, RSS puchnął mi w zastraszającym tempie, a ja z tej listy wybiorę jeden post i szczególnie mu się przyjrzę. Chciałbym zająć się kwestiami poruszonymi w poście Terrego Chaya i rzucić okiem na tematy luźno związane z projektem.
Client-side o muerte
sty/1026
Dzisiaj chciałbym zaryzykować parę kontrowersyjnych stwierdzeń n.t. budowania aplikacji internetowych. Pamiętacie mój poprzedni wpis o pluginizowaniu aplikacji PHP? Po jego napisaniu uznałem, że stworzę malutki framework korzystający z dobrodziejstw idei stojących za HMVC. Tak dla przykładu i dla własnej chorej rozrywki. Mam aktualnie dużo pracy, a co za tym idzie mój umysł pracuje na wystarczająco wysokich obrotach, by poradzić sobie w ekspresowym tempie i wolnym czasie rozwiązać problemy dotyczące architektur oprogramowania. Na tyle szybkim tempie, by nie zamęczyć się dodatkowo swym hobby i wypuścić kilka ciekawych wpisów. Przez ostatnie tygodnie powstawały szkice, klasy i interfejsy napisane w ulubionym PHP. Powstawały dopóki nie przystanąłem na chwilę i nie spojrzałem na ostatnie lata ewolucji aplikacji internetowych, dystansując się do swojego doświadczenia. I wiecie co? Patrzyłem na web-developing, który musi zostać zduszony w postaci w której utkwił. Musimy zrobić krok do przodu. Client-side albo śmierć.
Pluginizowanie aplikacji PHP
gru/098
Są 3 główne cechy programisty: ambicja, niecierpliwość i lenistwo. Chcemy podejmować się wspaniałych wyzwań, tworzyć aplikacje szybko i się przy tym nie napracować. Nie brzmi to zbyt dobrze szczerze powiedziawszy. Gdybym miał narażać życie innych będąc chirurgiem, po wypowiedzeniu tych słów już płonął bym na stosie. Na szczęście w inżynierii oprogramowania mamy takie cuda jak pluginy. I nikt przy tym nie umiera.
Każdy z nas jest odtwórczym wynalazcą
sie/096
Około roku 2002 (i to wciąż mi nie minęło) byłem zafascynowany tworzeniem na własne potrzeby tzw. engineów, czyli tłumacząc na dzisiejsze frameworków. Eksperymentowałem na nich ze wzorcem MVC, bawiąc się budowaniem sprawnych narzędzi do szybkiego budowania aplikacji. Jednym z owych “potworków”, wyników moich eksperymentów był niezwykle modularny framework: pozbawiony routera z autonomicznymi kontrolerami, które były wywoływane z własnymi parametrami przekazanymi w adresie. Jakież było moje zdziwienie, gdy dziś odkryłem, że Kohana wprowadza takie rozwiązanie od wersji 3.0 i ten wynalazek ma swoją fachową nazwę. Wzorzec projektowy o którym mowa to HMVC i został opisany pierwszy raz w lipcu 2000 roku na łamach “JavaWorld Magazine”.
Każdy z nas jest niestety odtwórczym wynalazcą.
Bym zapomniał. Ten “engine” nazywał się “Sequence”.
Szybkie komponenty w PHP
sie/098
Ostatnio kolegom zaprezentowałem szybki sposób na stworzenie sprawnego prototypu komponentu w PHP. Ostatecznym wnioskiem, który zaraz wysuniemy jest przypomnienie faktu pracy z dynamicznym językiem programowania, który udostępniając nam hermetyzację i inne paradygmaty języka obiektowego pozwala nam uniknąć licznych “dżawawizmów” (czyt. rozwiązań Javy).
Refaktoryzacja kodu i wzorce projektowe
cze/090
Chętnych do zapoznania się jak wzorce projektowe mogą pomóc przy refaktoryzacji kodu zachęcam do przeczytania mojego artykułu na PHP.pl.
(…) Wszystkie te elementy mają zastosowanie nie tylko w aplikacjach biznesowych, ale także w pracy przy otwartym oprogramowaniu i współpracy w zespołach programistów; w projektach, które mają być rozwijane znacznie dłużej. (…)
Mam nadzieję, że okaże się przydatny. Jestem pewny, że jeszcze kiedyś wrócę do tego tematu i skupię się szczególnie na wzorcu DI.