Real-Worls Solutions for Developing High Quality PHP Frameworks and Applications

• pracuje na systemach z zaszłościami (Legacy Systems)
• myśli, że refaktoring takich systemów nie jest możliwy
• testy automatyczne muszą być równie przyjemne jak hemoroidy
• boi się, że aplikacja, w którą zainwestował już sporo powoli staje się niemożliwa w utrzymaniu
• myśli, że system, którego używa od lat trzeba przepisać od zera

Pozycja zdecudowanie nie jest przeznaczona dla tych, którzy zaczynają swoją przygodę z PHP. Jeśli jednak już okrzepłeś i szukasz czegoś więcej – polecam gorąco.

Ciekawa analiza czterech gigantów: Apple, Google, Microsoft i Google.

I dlaczego Amazon jest na dobrej drodze, aby osiągnąć dominację na rynku?

Pozwolę sobie zacytować charakterystykę wielkiej czwórki z tego artykułu

Why Amazon will lead the big four:

• Apple sells content and writes software to sell hardware. It is a hardware company.
• Microsoft sells content and makes hardware to sell software. It is a software company.
• Google sells or gives away content and software to sell advertisements. It is an ad sales company.
• Amazon sells or gives away hardware and software to sell content. It is an online retailer — a content

company.

Interesujące przemyślenia dotyczące technologii flash i jej przyszłości

Czy flash ma przyszłość?. Co myśli o tym Steve Jobs i Dean Hachamovitch (jeden z leaderów zespołu w Microsofcie)?

Bardzo ciekawy fragment, który oddaje filozofię Apple, jako całości:

If developers grow dependent on third party development libraries and tools, they can only take advantage of platform enhancements if and when the third party chooses to adopt the new features. We cannot be at the mercy of a third party deciding if and when they will make our enhancements available to our developers.

Przyznam się, że też za flashem nie będę płakał. Nigdy nie miał sensownego wsparcia na platformy linuxowe. Do niedawna domyślnie każdy element flash miałem zablokowany (flashblock)…

Dla tych, którzy lubią społeczne aspekty sieci i marketingu…

Poradnik jak przygotować skuteczną infografikę. Jeśli przygotujesz jakąś przy pomocy tych wskazówek – pochwal się proszę w komentarzu.

Dla estetów i całej reszty

Ci pierwsi dostaną argumenty za, ci drudzy mają okazję przekonać się dlaczego jest istotna i skąd czerpać odpowiednią wiedzę o typografii.

I na koniec, żeby było coś o projektach stricte informatycznych.

Kto rozwija plany testów dla oprogramowania open-source? Kto aktualizuje zrzuty ekranów w instrukcji użytkownika i pomocy online? Oraz kto tłumaczy dokumentację na polski i turecki? Kto weryfikuje, czy dana funkcjonalność nie łamie Amerykańskiej Ustawy o Niepełnosprawnych, bądź Niemieckich Praw odnośnie Prywatności? Wtedy, gdy pracowałem nad Linuxem, odpowiedzią było “Nikt. Nie ma czegoś takiego jak plan testów, drukowana instrukcja użytkownika, jedyną dokumentacją, jaka istnieje, to ta po angielsku, oraz nikt nie przejmuje się zgodnością z jakimikolwiek prawami.” Może coś się pozmieniało od tamtego czasu.

Dowiedz się dlaczego open source’owi lżej na sercu?

Przy okazji (jeśli dotarłeś aż tutaj, to znaczy, że artykuł jest wystarczająco ciekawy)

Noszę się z zamiarem kupna kindle’a (nie tabletu), żeby między innymi mieć szybki dostęp do dobrej literatury branżowej (czyli anglojęzycznej) i artykułów takie jak te powyżej. Zatem jeśli mój blog wydał Ci się pomocny, jeśli wydaje Ci się, że jest coś wart – możesz rozważyć zafundowanie mi bonu podarunkowego amazona. 1$ jest super kwotą – możesz zapłacić na przykład z paypall’a. Możesz mi go wysłać na adres podaruj.mi.kindle@gmail.com :)
Jeśli masz blog, to w wiadomości umieść swój adres – umieszczę go na swojej stronie, jeśli zechcesz.
Będę też zachwycony, jeśli dołączysz też jakąś osobistą wiadomość od siebie.

Na pewno godne polecenia z tej listy są wydawnictwa z serii “Head First”, np. to:

Dwa jednocześnie działające układy, jeden myślący, drugi emocjonalny

Wynika to z ewolucji. Tzw. korę starą odpowiadająca za emocje mieliśmy będąc już homo, ale nie koniecznie sapiens. Dzięki niej reagowaliśmy strachem na widok tygrysa, gniewem na widok innego samca smalącego cholewki do naszej wybranki serca itd.

Później kora stara obrosła korą nową, która odpowiada za logiczne myślenie, analizę. Staliśmy się bardziej cywilizowani, zaczęliśmy myśleć przed podjęciem działania.

Jednak ciągle mamy obie warstwy. W zasadzie rządzi mózg myślący, jednak analiza i myślenie zajmują relatywnie sporo czasu. Dlatego w sytuacjach zagrożenia kontrolę przejmuje mózg emocjonalny. Gdy na siatkówkę oka padnie obraz pędzącego w Twoim kierunku samochodu sygnał pójdzie na skróty przez układ limbiczny, który zareaguje nawykowo, a Ty odskoczysz zanim zdążysz pomyśleć co się wydarzyło.

Brzmi to dobrze w sytuacji realnego zagrożenia. Zabawnie jest, gdy sygnał zostanie błędnie zinterpretowany. Podczas rozmowy mama machnie ręką, a ten obraz wzbudzi alarm “nadlatujący przedmiot” i uchylając głowę walniesz się w szafkę kuchenną…

Do tego równania dodajmy jeszcze jedno – sytuacja stresowa też jest sygnałem o zagrożeniu. Na przykład starcie dwóch samców alfa w barze wywołane nieumyślnym szturchnięciem jednego przez drugiego. Już po chwili dwaj dżentelmeni, już na świeżym powietrzu, ryzykują z tego powodu faktyczne obrażenia ciała w sytuacji, gdy wystarczyłoby “sory z jednej, spoko z drugiej strony”. Emocje przejmują kontrolę i powodują, że jesteśmy gotowi ponosić koszty niewspółmierne do korzyści (ciekawostka: ten efekt próbują wykorzystać czasem manipulujący sprzedawcy, gdy mówią, że to jest ostatnia sztuka w tak fantastycznej cenie).

Pewnie zaczyna Ci się nudzić i myślisz, że nie po to subskrybujesz blog programisty, żeby czytać o psychologii. Otóż takie same sytuacje zdarzają się w biurze. Emocje wyłączają logiczne myślenie (i na odwrót, ale o tym za chwilę). Oczywiście lubimy “nasze” emocje – płakać na romansie, śmiać się z dobrych dowcipów, zakochiwać się bez pamięci. Jednak najważniejszym narzędziem programisty jest jego mózg. Jeśli wkurza Cię kolejny mail klienta lub za głośne radio to znaczy, że powoli mózg emocjonalny zaczyna przejmować kontrolę. Gdy dasz się ponieść zaczynasz nie zauważać prostych błędów, wprowadzasz nowe. W skrócie: przestajesz efektywnie rozumować.

Gdybym zakończył w tym miejscu post, nie podając Ci sposobów jak sobie z tym radzić, mógłbyś się wkurzyć.

Pierwszym krokiem jest uświadomienie sobie, że tak się dzieje. Nie musisz wierzyć mi na słowo – sprawdź to w życiu codziennym, obserwuj siebie i innych.

Gdy już stwierdzisz, że coś w tym jest – trzeba nauczyć się rozpoznawać takie stany. Zacznij od tego, że zauważysz je po tym jak się wystąpią. Na początku nie sposób wyjść z trybu awaryjnego, bo ona na Ciebie wrzeszczy, więc Twój autopilot czeka na wolne pasmo, żeby móc odwrzeszczeć. Z czasem okaże się, że coraz szybciej po tym jak dasz się porwać, uświadamiasz sobie co się wydarzyło. Aż w końcu okazuje się, że zaczynasz sobie uświadamiać co się dzieje wtedy, gdy to się wydarza.

Kiedy już wiesz co się dzieje, wystarczy wyłączyć mózg emocjonalny. Tak jak pisałem: mózg emocjonalny wyłącza mózg myślący i na odwrót. Jeśli tzw. wkurw leci na pełnych obrotach spróbuj rozruszać logiczne myślenie. Ale nie zabieraj się za kostkę Rubika, bo za chwilę może wylecieć przez zamknięte okno. Zacznij od czegoś prostego, metody polecanej od pokoleń: policz do dziesięciu. Możesz obserwować jak wiele w takim momencie wymaga to wysiłku ;)

Na koniec cytat kogoś mądrego, niestety nazwiska nie pamiętam (sam cytat też może być niedokładny, ale ideę zachowam):

Wpaść w gniew to jak zsikać się w majtki. Najpierw jest przyjemnie ciepło, ale potem straszna siara.

Chcesz zgłębić temat? Polecam Ci książkę Daniela Golemana “Inteligencja emocjonalna”, to o czym piszę znajdziesz w w części pierwszej, rozdziale drugim pod tytułem “Anatomia porwania emocjonalnego”.

E. Yourdon - Marsz ku klęsce

Pozycja obowiązkowa nie tylko ze względów dydaktycznych, ale również rozrywkowych. Znajdziecie w niej inspirujące, czasem anarchistyczne przygody różnych zespołów, które będąc nad przepaścią nie miały już nic do stracenia.

Oczywiście do wygrania jest wersja popisana ołówkiem, gdyż ta książka też była moim źródłem przy pracy nad magisterką…

Muszę przyznać, że oddanie jej jest dla mnie trudne – jestem pewien, że jeszcze kiedyś po nią sięgnę. Ale póki co nie musi się kisić na półce. Książki są po to, żeby je czytać!

jeśli zespół pracuje w typowym “otwartym biurze” i nie można zastosować żadnej z omawianych wcześniej strategii, to załatwcie ulokowanie członków zespołu w sąsiednich klatkach. Następnie postarajcie się zabarykadować te komórki przed dostępem pozostałej watahy biurowej. Odłączcie telefony wewnętrzne i głośniki, które hałasują pod sufitem (przygotujcie się na robienie tego raz na tydzień, gdyż będą naprawiane). Wyłączcie telefony albo, jak zalecają DeMarco i Lister, zapchajcie dzwonki watą. Jeśli możecie, opanujcie całe piętro albo nawet budynek. Im więcej, wym lepiej. Wywieście piracką flagę na szczycie budynku, tak jak zrobił to Steve Jobs z zespołem Macintosha w Apple. Ustawcie strażnika, który będzie strzelał do niepożądanych gości.

Tym, którym nie uda się zdobyć teraz tej książki proponuję drugie wydanie w wersji angielskiej:
Death March (2nd Edition)

Chętnych proszę o pozostawienie komentarza wraz z mailem kontaktowym. Termin – 1 tydzień z możliwą obsuwą ;)

Zastanawiałeś się kiedyś jaki język jest “przyszłościowy”? Nie Ty jeden, na forach i portalach co kilka dni pojawia się podobne pytanie. Czy nauczyć się php? Czy może ruby, albo python? W co zainwestować?

Często odpowiedzi są niezadowalające – możesz dowiedzieć się, że jeśli będziesz wybierał język wg spodziewanych przyszłych zarobków, to nie będziesz dobrym programistą. W tym stwierdzeniu jest tylko połowa prawdy. Jeśli zostajesz programistą ze względu na możliwe zarobki możesz nie być tak dobry jak ten, dla którego jest to pasja.
Jeśli jednak już wybrałeś tą ścieżkę i chcesz się nauczyć tej technologii, która jest najbardziej pożądana, a przez to najlepiej płatna – jest to jak najbardziej rozsądne działanie. Porównałbym go do inwestowania tam, gdzie spodziewamy się największych zysków.

Jeśli stoisz właśnie przed podobnym dylematem chętnie zasugeruję Ci książkę, która może nieco rozjaśnić Ci sytuację. “Więcej niż Java” nie odpowie Ci na pytanie “którą droga iść?”. Ale rzuci światło na każdą z interesujących ścieżek, dzięki czemu, być może, łatwiej będzie Ci zdecydować.

Jednocześnie warto mieć w głowie pewne stwierdzenie, które przeczytałem w informatorze uniwersytetu kiedy startowałem na studia.

Studia informatyczne nie mają za zadanie nauczyć studentów jakiegokolwiek języka programowania. Mają za zadanie nauczyć ich myślenia, zasad i mechanizmów zachodzących w świecie informatyki, żeby absolwent mógł nauczyć się samodzielnie dowolnej potrzebnej technologii

Dlatego nawet jeśli podejmiesz decyzję i okaże się strzałem w dziesiątkę (zastąpi Javę i da Ci wspaniałe zarobki) pamiętaj, że powstaną wspanialsze narzędzia, które prędzej czy później wrzucą z piedestału Twojego wybrańca i kurę znoszącą złote jajka w jednym.

Bądź na bieżąco, poznaj jeden, ciekawy język/framework przynajmniej raz na pół roku… choćby pobieżnie i przeczytaj książkę, którą Ci polecam, bo warto ;)

Chciałbym się podzielić dobrymi książkami, które przeczytałem i które polecam.

Na pierwszy ogień – Coś lekkiego. Head First: Software Development. Świetna pozycja odświeżająca to ciężkie podejście do wytwarzania oprogramowania, które każdy w jakimś stopniu wynosi z czasów akademickich:

Przykłady kodu są wprawdzie w Javie, ale i tak wielki pożytek może przynieść nawet jeśli o Javie wiesz, że ma klasy i składnię podobną do C ;)

Sama książka jest nieco sfatygowana, lekko zaokrąglone rogi od wożenia w plecaku i czytaniu w autobusie i jest tam trochę bazgrołów wykonanych ołówkiem. Ale potraktujcie to jako dodatkową zaletę – nieciekawych książek nie wożę ze sobą, a notuję tylko w tych, które naprawdę pobudzają do myślenia.

Na koniec zasady – jeśli chcesz wygrać tę książkę – dodaj proszę komentarz do tego postu (koniecznie podaj prawdziwy mail). Za tydzień (26 maja) wylosuję zwycięzcę, z którym się skontaktuję za pomocą tegoż maila.

Powodzenia!

Agile. Programowanie w Rails.

Agile. Programowanie w Rails

Znalazłem tam ciekawy fragment na temat warstwy modelu, który zacytuję (mi w rączki wpadła angielska wersja, więc tłumaczenie będzie moje):

Model to coś więcej niż tylko dane; wspiera wszystkie reguły biznesowe które odnoszą się do danych.
Na przykład, jesli zniżka nie powinna być stosowana dla zamówień na kwotę mniejszą niż 20 dolarów, model wspiera to ograniczenie.
To jest sensowne; poprzez umieszczenie implementacji tej reguły biznesowej w modelu mamy pewność, że nic innego w naszej aplikacji nie może sprawić, że nasze dane będą nieprawidłowe.
Model spełnia dwie role: pilnowanie bramy i przechowywania danych.

1. Agile Software Development. Gra zespołowa. Alistair Cockburn
   
   

   Agile Software Development. Dużo teorii i dużo informacji

   
   
   Bardzo dobra pozycja, choć dość trudna w odbiorze. Charakteryzuje się dość wysokim poziomem abstrakcji. Ale dzięki niej można zrozumieć dlaczego agile działa, a nawet kiedy nie działa i dlaczego. Autor jest też twórcą rodziny metodyk Crystal i z tej książki dowiesz się o nich co nieco. Jeśli na temat stosowania Agile chcesz poznać wszystkie sekrety i mechanizmy stojące za jego siłą – to pozycja dla Ciebie. Jeśli nie jesteś gotowy na teoretyczną przeprawę – rzuć okiem na pozycje poniżej.

2. Agile Development. Filozofia programowania zwinnego. James Shore, Shane Warden
   

   Agile Development. Równowaga między teorią a praktyką stosowania XP

   
   To nieco lżejsza pozycja, bardziej traktująca o tym jak używać (w tym przypadku XP), a nie jak działa. Z tej książki poznasz dokładnie wszystkie elementy XP, łącznie z tymi najbardziej subtelnymi. Dowiesz się dlaczego programowanie w parach jest równie skuteczne, co dziwaczne (na pierwszy rzut oka). Jeśli jesteś szefem programistów – zrozumiesz dokładniej co programiści robią podczas pracy. Dowiesz się, że jeśli nie klepią w klawiaturę, to jeszcze nie oznacza, że nie pracują. Pozycja obowiązkowa dla tych, którzy chcą z powodzeniem stosować XP. Dla osiągnięcia mistrzostwa prawdopodobnie po pół roku używania XP warto by do niej wrócić.
3. Head First Software development. Dan Pilone, Russ Miles
   
   

   Head First Software Development. Zestaw praktyk w lekkiej i przystępnej formie

   
   Najlżejsza pozycja w zestawienia, jednak również wartościowa. Nie przedstawia z sobą żadnej konkretnej metodyki. Choć może raczej nie przedstawia żadnej nazwanej metodyki. Jest to zbiór prostych praktyk, które usprawnią działanie Twojego zespołu. Przykłady zamieszczone są w języku Java, ale pozycja przydatna nawet dla tych co Javy nie znają (jak ja, kiedy zaczynałem tą książkę czytać). Wiele ćwiczeń, pytań i wszystkiego, co sprawi, że nawet jeśli zdiagnozowano u Ciebie ADHD – wciągnie Cię i niewielkim wysiłkiem poznasz podstawy zwinnego wytwarzania oprogramowania.

Miłej lektury.

Ps. jeśli sam(a) chcesz mi coś polecić – wrzuć to koniecznie do komentarza – nie mogę się doczekać.

]]> http://blog.grzegorzpawlik.com/2009/06/jaka-ksiazke-warto-przeczytac-aby-poznac-agile/feed/ 2