Programista z doświadczeniem zarówno w projektach biznesowych (CRM, B2B) jak i web 2.0.
Zwolennik zwinnego podejścia do wytwarzania oprogramowania hubert@dzbanyit.pl
Wszyscy teraz mówią o Agile, stosują zwinne metodyki, słyszeli o scrum”ie czy eXtreme programming. Ale mam pytanie: czy widziałeś w ogóle “Manifest zwinnego wytwarzania oprogramowania“? Jesteś w stanie wymienić przynajmniej dwa nazwiska osób, którego go podpisały? Albo co lepsze czy wymienisz chociaż połowę z dwunastu zasad zwinnego programowania?
Jeżeli na wszystkie pytania odpowiedziałeś tak, to możesz zrezygnować z czytania reszty tego artykuły, w przeciwnym razie zapraszam do zapoznania się z podstawami zwinnego podejścia do tworzenia oprogramowania. Na pierwszy ogień idzie treść manifestu agile (oryginalna wersja po angielsku jest dostępna na stonie agilemanifesto.org):
Manifest zwinnego wytwarzania oprogramowania
Odkrywamy lepsze sposoby rozwoju oprogramowania, wytwarzając je pomagając w tym innym. Dzięki temu nauczyliśmy się cenić:
Jednostki i interakcje bardziej niż procesy i narzędzi
Działające oprogramowanie bardziej niż kompletną dokumentacje
Współpracę z klientem bardziej niż negocjowanie kontraktu
Reagowanie na zmiany bardziej niż postępowanie zgodnie z planem
Oznacza to, że choć pozycje po prawej stronie są ważne, bardziej cenimy zagadnienia przestawione po stronie lewej.
2001, powyżsi autorzy
Tę deklaracje można swobodnie kopiować w dowolnej postaci, jednak tylko w całości.
W dniach 11-13 lutego 2001 roku w malowniczym kurorcie Snowbird w stanie Utah zebrała się grupa znajomych, reprezentujących nowe podejścia do wytwarzania oprogramowania, będące alternatywą dla nieefektywnego modelu kaskadowego. Wynikiem ich spotkania była deklaracja manifestu zwinnego wytwarzania oprogramowania. Od tego momentu nowe metodyki zaczęto nazywać mianem metodyk zwinnych (ang. agile).
Nieoderwanym elementem manifestu agile jest również lista zasad zwinnej filozofii:
Zasady stojące u podstaw manifestu zwinności
Stosujemy się do następujących zasad:
Naszym priorytetem jest zapewnienie satysfakcji klientów przez szybkie i ciągłe udostępniani wartościowego oprogramowania.
Nie obawiamy się zmian wymagań na późnych etapach rozwoju. Zwinne procesy pozwalają wykorzystywać zmiany do zapewnienia klientom przewagi konkurencyjnej
Często udostępniamy działające oprogramowanie (w odstępach od kilku tygodni do kilku miesięcy), przy czym preferujemy jak najkrótsze terminy.
Odbiorcy i programiści muszą regularnie współpracować ze sobą w czasie trwania projektu.
Budujemy projekty wokół zmotywowanych jednostek. Należy zapewnić im środowisko i zaspokoić potrzeby oraz ufać, że wykonują powierzone zadania.
Najbardziej wydajna i efektowna metoda przekazywania informacji zespołowi programistycznemu i w obrębie jego to rozmowa twarzą w twarz.
Działające oprogramowanie to główny wyznacznik postępów.
Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni móc zachować stałe tempo pracy.
Ciągłe poświęcanie uwagi technicznej doskonałości i dobremu projektowi zwiększa zwinność.
Niezwykle istotna jest prostota, czyli sztuka maksymalizowania liczby zadań, których nie trzeba wykonywać.
Najlepsze architektury, wymagania i projekty są efektem pracy samodzielnie organizujących się zespołów.
W stałych odstępach czasu zespół określa, jak może zwiększyć wydajność, a następnie w odpowiedni sposób usprawnia i dostosowuje swe działania.
Idee manifestu są wręcz przez niektórych uważane za najważniejszy do tej pory krok na drodze rozwoju informatyki. Zasady Agile z pewnością wyznaczają nowy kierunek w myśleniu o projektowaniu i programowaniu systemów informatycznych. Każdy zespół zaczynający swoją przygodę z agile powinien poznać oraz przyswoić zarówno treść manifestu jak i zasad zwinnego programowania.
W końcu Lublin ma swoją imprezę branży internetowej “NetDay Lublin“. Nawet Zamość ze swoim ZamCamp nas wyprzedził, ale lepiej późno niż wcale. Za całą imprezę odpowiada firma Enzo za co należą im się brawa, mam nadzieje, że do następnych edycji dołączy się więcej firm.
Pomimo choroby postanowiłem być twardy i nie opuścić pierwszego spotkania. Moja gorączka niestety stłumiła odbieranie bodźców zewnętrznych i pozwoliła dotrwać jedynie do końca części oficjalnej (z darmowego piwka i rozmów kuluarowych musiałem zrezygnować).
Impreza bardzo była udana i dobrze zorganizowana. W prawdzie wynikło 20 minutowe opóźnienie spowodowane nie punktualnością większości słuchaczy. Sam zjawiłem się tuż przed 15-stą i byłem jedną z pierwszych osób na sali. Pomimo awarii mikrofonu wszystko było słychać wyraźnie i nie wpłynęło to negatywnie na całą imprezę. Były trzy zapowiedziane prezentacje (materiały z nich są dostępne na oficjalnej stronie) oraz dwa spontaniczne wystąpienia bez oprawy graficznej, również bardzo ciekawe. Organizatorzy zapewnili gorące napoje oraz kupon na darmowe piwko :)
Moje uwagi co do imprezy: zaczynać zgodnie z planem, zwiększyć ilość prezentacji do 4 i organizować zebrania częściej niż raz na dwa miesiące.
Najciekawszym zadaniem w mojej ostatniej pracy było przeprowadzenie procesu rekrutacji na stanowisko programisty i webmastera. Było to dla mnie zupełnie nowym doświadczeniem, do tej pory stałem po drugiej stronie barykady i nie miałem pojęcia co mnie czeka. Teraz bogatszy o ciężko zdobyte doświadczenia chciałbym się z Wami podzielić moimi obserwacjami i wnioskami z perspektywy osoby rekrutującej (jednocześnie programisty). Zaznaczam jednak, że moje przemyslenia będą odnosić się do rekrutacji w małej firmie.
Obalenie mitu, że nie ma pracy
Jak to jest, że wszyscy narzekają, że nie pracy, że brakuje poważnych i ciekawych ofert, a z drugiej strony pracodawcy (no i po części ja ;) narzekają, że nie można znaleźć dobrego pracownika? Praca jest i czeka, ale aby ją wykonać trzeba coś umieć! A z tym jest duży problem. Rozumiem, że Ci lepsi i bardziej mobilni wyjechali do Krakowa czy Warszawy (mieszkam i pracuje w Lublinie), ale ktoś na pewno musiał zostać.
Błędy popełniane przez szukających pracy
Przede wszystkim strasznie niski poziom i jakość nadsyłanych CV! Jest to szczególnie przykre, ale po informatykach spodziewałem przyzwoitych aplikacji, a tu lipa z nędzą. CV ma zachęcić, zainteresować a nie odstraszać! Ludzie opisują doświadczenie w zawodach w ogóle nie związanych ze stanowiskiem na jakie się ubiegają. Niektórzy uważali, ze na stanowisko webmastera na pewno przyda się doświadczenie w Żabce, Stokrotce czy jako operatora wózka widłowego (sic!). Do tego dochodzi notoryczne pomijanie informacji o wykonywanych obowiązkach czy posiadanych umiejętnościach. Nigdy nie uważałem siebie jako eksperta w przygotowywaniu CV, ale wiele godzin spędzonych na czytaniu o tym jak powinien, a jak nie powinien wyglądać życiorys, pozwoliło mi poznać przynajmniej podstawy tej trudnej sztuki. Widać, że dla większości ciągle jest to za trudne. O tym jak według mnie powinno wyglądać CV programisty napiszę innym razem.
Kolejna sprawa to nie potwierdzenia i nie stawianie się na umówione spotkania. Wystarczy poinformować, że nie jest się już zainteresowanym. Innym ciekawym zjawiskiem jest ‘wbijanie się na harpuna’ do siedziby firmy bez zaproszenie, bez wysłania cv - takim mówi się od razu do widzenia.
Z wiedzą, nawet tą podstawową także jest duży problem. Wiem, że nie można wszystkiego nauczyć się na pamięć i zawsze można znaleźć odpowiedz w internecie, ale jeżeli startujesz na stanowisko programisty i proste zapytanie sql z sumowaniem i agregacją jest ponad twoje siły, zastanów się czy aby na pewno wybrałeś sobie dobry sposób na zarabiania na życie.
Sama rozmowa
Nie uznaje żadnych pseudo-psychologicznych testów osobowych, czy pytań w stylu: pokój jest wypełniony różnokolorowymi piłeczkami, gdybyś mógł, jaką chciałbyś zostać rośliną? WTF. Dlatego rozmowa, pomijając części formalne, była czysto techniczna. Bardzo ważne: niezależnie jakim doświadczeniem może się pochwalić aplikant, zawsze należy zweryfikować jego wiedzę. W przeciągu 20 minut rozmowy można się zorientować czy dana osoba zna się na rzeczy, czy tylko wpisuje głupoty w swoim życiorysie, aby go jakoś wypełnić. Pozwoli to uniknąć przykrych niespodzianek.
W przypadku wymagań finansowych, też było ciekawie. Z jednej strony osoby mniej doświadczone nie potrafiły się wycenić, z drugiej strony zdarzały się dzbany, które mimo bardzo malej wiedzy i doświadczenia żądały dość astronomicznych sum (uwierzcie, ciężko zachować powagę jak gość, który nie odróżnia javy od javascriptu, kod html opiera tylko na tabelkach, a na koniec żąda 2500zł netto - no nie wiem, może w Warszawie by tyle dostał…)
Jak ciekawostkę wspomnę, że kiedy CV mi się podobało i byłem zainteresowany, prosiłem również o próbki kodu. W ten sposób wystraszyłem 50% zaproszonych osób na rozmowę. Albo kontakt się urywał, albo przekładali ciągle spotkania, tłumacząc się, że nie zdążyli przygotować tych próbek!? Żenada. Twój kod to twoja wizytówka. Bez niej nie pokazuj się ludziom ;)
Prosty projekcik (to nie znaczy, że nie pracochłonny): formularz z ponad 130 polami, podzielonymi na około 75 kroków. Ktoś miał się zając przygotowanie formularza: html, css i walidacją na poziomie javascript!? Ja miałem to obsłużyć w php (jak będzie o tym w kolejnym wpisie, bo problem jest nawet ciekawy).
No i otrzymuje z pewnym opóźnieniem nie gotowy ‘formularz’. A tam lista pytań z nazwami pól: q1, q2, q3…q45…q99… a często miedzy nimi q9a, q9b, q9c WTF? Formularz był nie kompletny i musiałbym jeszcze między q9a a q9b wsadzić jeszcze 20 pytań. Gdybym sam umieścił w bazie danych pola o takich wartościach - to potem stałbym się bohaterem podobnego wpisu, a programista zajmujący się tym później projektem wyzywałbym mnie od dzbanów.
Nie pozostało mi nic innego jak samemu wszystko robić od nowa.
Wniosek: czasem lepiej zrobić wszystko od początku niż korzystać z czyiś rozwiązań.
Chciałem ustawić kilka wirtualnych hostów pod apache, przy czym zachowująć możliwość przeglądania głównego drzewa katalogów poprzez 127.0.0.1.
Największy problem był w tym, że działał tylko jeden wirtualny host, jak dodawałem kolejny wszystko się sypało. Strasznie długo szukałem rozwiązania tego problemu. Żadne (nie)oficjalne materiały nie pomagały. Ale udało się. Mam nadzieje, że oszczędzi wam to dużo czasu.
Rozwiązanie
Konfiguracje opieram na apachu 2.x dostępnym w super paczce xampp i system win xp. Przy innym zestawieniu nazwy plików mogą się różnić, ale filozofia jest taka sama. Otwieramy plik \apache\conf\extra i umieszczamy kod podobny do tego:
Ostatnio natrafiłem na pewien problem podczas prac nad nowym projektem (opartym o Zend Framework). Rozwiązanie problemu sprowadza się do odpowiedzi na pytanie: Co jest ważniejsze: optymalizacja czy zasady programowania obiektowego?
Mamy model Photos oraz klasę PhotosRow reprezentujący pojedynczy rekord. W aplikacji istnieją różne rodzaje zdjęć (profile, albumy, wydarzenia). Każde zdjęcia, w zależności od typu posiada kilka różnych rozmiarów.
class Photos extends Advaf_Db_Table {
public function deleteAlbumPhoto($photosId, $usersId) {
if ($this->_hasAccessToPhoto(..., 'albums')) {
$row = $this->findOne($photosId);
return $row->delete();
}
return null;
}
public function deleteEventPhoto($photosId, $usersId) {
if ($this->_hasAccessToPhoto(..., 'events')) {
$row = $this->findOne($photosId);
return $row->delete();
}
return null;
}
}
class PhotosRow extends Advaf_Db_Table_Row {
public function _postDelete() {
$mgr = new PhotoMgr();
foreach ($mgr->getSizes(this->type) as $size) {
$path = $mgr->getPhotoFullPath(...);
if(file_exists($path)) {
unlink($path);
}
}
}
}
Chciałem umieścić w metodzie _postDelete() klasy PhotosRow cały kod odpowiedzialny za usuwanie z przestrzeni dyskowej odpowiednich zdjęć. Mój kolega, Szymon od razu zwrócił uwagę, że to nie jest optymalne. Aby usunąć rekord, najpierw go pobieramy, potem usuwany (SELECT + DELETE, zamiast tylko DELETE). Wykonujemy jedno zapytanie dodatkowo, dla każdego zdjęcia. Dla 20 zdjęć do 20 extra zapytań! Szymon zaproponował aby przenieść cały kod odpowiedzialny za usuwanie zdjęć do Photos, a zdjęcia usuwać bezpośrednio $this->delete($where).
class Photos extends Advaf_Db_Table {
public function deleteAlbumPhoto($photosId, $usersId) {
if ($this->_hasAccessToPhoto(..., 'albums')) {
$where = $this->quoteInto('id = ?', $photosId);
$this->_unlink(...);
return $this->delete(where);
}
return null;
}
private function _unlink(...) {
}
}
Mimo wszystko obstaje przy swoim. Zgodnie z zasadą odpowiedzialności to klasa PhotosRow powinna po sobie posprzątać. Wydaje mi się, że właśnie w tym celu developerzy Zenda stworzyli takie metody jak _postDelete czy _postInsert w klasie Zend_Db_Table_Row.
Nie oznacza to oczywiście, że twórcy ZF nie moją głupich pomysłów… moim zdaniem do nich m.in należy obsługa formularzy i osobiście preferuje rozwiązanie Szymona: Fasic_Form.
Jestem bardzo Ciekawy twojej opinii, bo sprawa nadal nie jest rozstrzygnięta. Być może znasz lepsze rozwiązanie?
Bardzo polecam obejrzeć prezentacje Marka Hołyńskiego jaką przeprowadził na Bootstrapie 8.5. Dowiecie się z niej między innymi o historii startup’ów, o różnicy w rozwiązywaniu problemów w akademicki i biznesowy sposób. Poznacie również co się stało z pewnym geniuszem z Grecji.
Zostać programistą to pikuś, wyzwaniem jest zostać dobrymprogramistą. Niniejszym otwieram serię wpisów z kategorii rozwój osobisty, w której będę na podstawie własnego doświadczenia pokazywał drogę do sukcesu.
Dodaj mój rss to swojego czytnika.
