Jak myślicie jaka jest odpowiedź? (Oprócz tej, że powinien przeczytać książkę/dwie?).

Tutaj przeczytacie najciekawszą i bardzo obrazową odpowiedź dlaczego tak się dzieje (po angielsku). Pokażcie ją swojemu “menadżerowi” jeśli też go ta kwestia dziwi.

Moja odpowiedź: Estymacja jest błędna z defininicji (<łac. aestimatio ocena> != wycena). Jeśli zakładasz, ze estymacja da Ci dokładny wynik, to zamień to słowo na szacowanie. Jeśli nadal popełniasz ten sam błąd i po szacowaniu spodziewasz się dokładnych wyników – zamień to słowo na… zgadywanie. Czasem trafi się ktoś, kto potrzebuje jeszcze silniejszego określenia, żeby odpaliło odpowiednie zwoje mózgowe. Ja w ekstremalnych warunkach lubię użyć określenia “Wróżenie z fusów”.

foto: Flood

Szczególnie, jeśli na przeciw masz zabójczą kombinację:

zabójca kombinacja =
rozległe zadanie
+ technologia w której brak Ci doświadczenia
+ menadżer (lub klient) który nie rozumie znaczenia słów

• “To wróżenie z fusów”.
• “Jeśli mam podać konkretne daty, to zajmie od 3 do 10 miesięcy”
• “Dlaczego? Bo to jest jak wróżenie z fusów”
• “Jest wiele niewiadomych, a wymagań jest na tyle dużo, że nie mieszczą się już na kartce a4 – dlatego przypomina to wróżenie z fusów”.
• “Podając Ci konkretne wartości, czuję się jakbym wróżył z fusów”

Powtarzaj to tak często jak potrafisz. I porzuć nadzieję, że zrozumieją. Będziesz powtarzał to zdanie (lub inne ulubione) tylko z jednego powodu – dla zachowania własnego zdrowia psychicznego. Gdy na kolejnym spotkaniu (miejmy nadzieję, że szybciej niż za 3 miesiące) ktoś wytknie Ci nietrafioną estymację przypomnij mu o tym. Powtórzyłeś tę frazę tak wiele razy, że coś musi zaświtać… Estymacje to wróżenie z fusów.

Estymacja z definicji zawiera błąd. Istotne jest jaka jest natura tego błędu.

Dlatego jest nadzieja. W pytaniu jest informacja, że estymacje zazwyczaj chybią o współczynnik 2-3 (cokolwiek by to nie znaczyło). I to jest już coś na czym można budować. Zwinne metodyki potrafią radzić sobie z błędnymi estymacjami jeśli błąd jest w miarę stały (i nie trzeba nawet wiedzieć ile on wynosi). Ale to temat na kolejny post.

foto: Wen Rou

Phing creates file phing.bat in the PHP directory, so it makes only to put another file, named phing (executable) with content:

php -d html_errors=off -qC "C:\path_to_your\PHP\PEAR\phing.php" $@

And that’s it. Hope it was helpful :)

Dziś na hacking.pl pojawił się artykuł potwierdzający, że poniekąd miałem rację. Nawet wychodzi na to, że użyta przeze mnie sugestia o trzymaniu ich w piwnicy nie była aż tak odległa od prawdy ;)

Z innej beczki – dlaczego hacking.pl nie potrafi podać aktywnego linka do źródła, tylko podaje nieaktywny tekst z adresem do strony głównej źródłowego serwisu? Styl podobny jak webinside, ale ten drugi nie podaje nic. Udaje, że jest sam w całym Internecie…

Jesteś kompletnie zielony, więc cykl pracy wygląda mniej więcej tak:

1. nowy problem
2. google
3. znajdujesz tutorial (lub odpowiedź na stack-overflow), który go (lub wystarczająco podobny) rozwiązuje
4. implementujesz rozwiązanie zgodnie z tekstem
5. dostosowujesz do swoich potrzeb
6. powtarzasz cykl

Po pewnym czasie listę można zredukować o punkt 4 – od razu przystępujemy do modyfikacji. Po kolejnych cyklach pomijamy punkt 2 i wiemy, że analogie są w napisanym przez nas kodzie- musimy sobie przypomnieć “jak to się robiło”. Coraz mniej też jest problemów, które w ten sposób potrzebujemy rozwiązać aż w końcu sięgamy po tą technikę tak rzadko, że już nie można mówić o Tutorial Driven Development. Czujemy się swobodnie z nową technologią, a z tąd już prosta (choć długa) droga do zostania ekspertem.

foto: Sigurd R

Ps. Ten wpis miał być humorystyczny, ale w trakcie pisania uświadomiłem sobie, że opisuję koncepcję Shu-ha-ri).

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.

Ale wróćmy do głównego wątku. Jeśli nie byłeś nigdy członkiem takiego zespołu, a chciałbyś takim zarządzać, to czytaj uważnie.

Z natury jestem leniwy. Ale jestem dość specyficznym leniem, który nie lubi nic nie robić. Dlatego w ogóle zostałem programistą – lubię automatyzować i ulepszać rzeczy, które są nudne i żmudne do ręcznego wykonywania.

Zatem zaczął mi doskwierać pewien proces. Przy pewnym projekcie dość często musimy aktualizować utrzymywane systemy, które mają kilka instancji(w tej chwili 3, a ma być więcej). Wygląda to mniej więcej tak:

1. zaloguj się na serwer
2. cd instancja#1
3. git pull
4. wpisz hasło
5. odpal migrację
6. cd ../instancja#2
7. git pull
8. wpisz hasło
9. odpal migrację
10. cd ../instancja#3
11. git pull
12. wpisz hasło
13. odpal migrację
14. TADA!

Serio. Pierwszym krokiem było napisanie skryptu, które te kroki odpala samodzielnie. Zaczęło to wyglądać tak:

1. zaloguj się na serwer
2. ./update-me.sh
3. wpisz hasło
4. wpisz hasło
5. wpisz hasło

Drugim krokiem było skonfigurowanie GITa tak, aby nie wymagał hasła na niektórych maszynach (przy pomocy kluczy rsa) Proces uprościł się do

1. zaloguj się na serwer
2. ./update-me.sh

Jaki jest efekt? Pierwszy, który się narzuca to oszczędność czasu. Zakładając, że taki update odbywał się 3 razy dziennie to zaoszczędziliśmy jakąś minutę. Nie wydaje się to rozsądne, gdyż oba zadania zajęły mi kilka godzin. Z księgowego punktu widzenia mamy stratę.

Jednak uważny obserwator mógł stwierdzić, że mamy w tym projekcie instancję główną i “towarzyszące”. W pierwotnym, ręcznym, procesie pozostałe dwie często zostawały w tyle. Rodziło to problemy przy testowaniu i mergowaniu zmian.

Dodatkowo prosty update to częsty update, zatem i testerzy nie muszą się dopraszać, żeby zaktualizować wersje, bo zwyczajnie są w najnowszej wersji.

Wracając do mojej tezy: Zespół to maszyna, programiści to (nie tak łatwo wymienialne) trybiki, procesy to miejsca, gdzie trybiki i inne części się ścierają. Niedoświadczonemu operatorowi może się wydawać, że przestoje spowodowane oliwieniem maszynerii to stracone pieniądze. W końcu przez te X godzin mogła wyprodukować Y $$$.

Refaktoring, automatyzacja i inne usprawnienia oliwią procesy w zespole programistów. Gdy nie ma niepotrzebnych tarć można rozwinąć optymalną prędkość, a awarie są mniej prawdopodobne.

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.