Dziś – dwa cytaty związane z wytwarzaniem oprogramowania. Dały mi dużo do myślenia, gdyż raz po raz łapię się na tym, że programując, za dużo rozmyślam nad koncepcją, próbując wybrać najlepszą, najbardziej optymalną – zamiast po prostu realizować projekt. W trakcie i tak przeważnie okazuje się, że plan trzeba całkowicie zmienić, bo doszły nowe wymagania, podczas realizacji wynikły jakieś problemy, koncepcja była błędna lub niektórych składników nie da się w sposób prosty i szybki ze sobą połączyć. Wniosek jest prosty: mniej planować, więcej działać.

Ponieważ każdy projekt i tak prawdopodobnie będzie kiedyś zmieniony, nie ma się co nad nim zastanawiać, tylko trzeba go realizować.
(Jeden z postulatów XP, źródło: „Sztuka testowania oprogramowania”.)

Cytat ten związany jest z kolejnym:

Nie można z góry przewidzieć, jaka architektura będzie najlepsza dla danego problemu. Dlatego należy ją tworzyć w miarę rozszerzania programu.
(Źródło: Programowanie ekstremalne, Wikipedia)

Dlaczego nauka (programowania – i nie tylko) jest taka ciężka to temat artykułu: Why Learning to Code is So Damn Hard (wersja offline w stopce postu).

Artykuł opisuje cztery etapy nauki „od zera do milionera”. Pierwszy, gdy młody padawan jest pełen entuzjazmu, wydaje mu się, że swoją nowo nabytą wiedzą może przenosić góry. Drugi – gdy zaczyna zauważać, że to, co potrafi, to jedynie kropla w morzu, tracić swoją pewność siebie. Trzeci, najdłuższy etap, to kluczenie w poszukiwaniu rozwiązań. Czwarty, to etap gdy naprawdę staje się ekspertem.

Bardzo ciekawe przedstawienie sprawy. Zwłaszcza, gdy pod koniec zostaje zestawione z wykresem ilości wiedzy, jaką należy przyswoić. Wniosków jest kilka. Jeden z nich mówi, że dużo większy przyrost wiedzy następuje, gdy uczymy się na błędach (II etap), gdy rozwiązujemy realne problemy, niż podczas lektury podręcznika (I etap). Resztę – proszę przeczytać sobie u źródła, bo warto. Zwłaszcza że owe wykresy można zastosować też w szerszej perspektywie zarządzania projektem. Przedstawiono także garść porad, jak radzić sobie na każdym z etapów.

Świetne opracowanie, polecam. Czytaj dalej →

Dziś ciekawy link. Tabelkę kompetencji można użyć na przynajmniej na dwa sposoby – jako mapy, tworząc na jej podstawie plan nauki oraz do oceny stopnia swojej wiedzy (przydatne np. podczas pisania CV). W oryginale: http://sijinjoseph.com/programmer-competency-matrix/. A Ty, na którym poziomie jesteś?

[Cache: Programmer Competency Matrix _ Sijin Joseph]

Dziś nieco wiedzy archiwalnej, która jednak osobom początkującym może się przydać. Czyli słowo o pewnym ustrojstwie, którego nazwy nie potrafiłam zbyt szybko zapamiętać. Mowa o ternary operation (symbol ?:), zwanym trójoperandowym operatorem warunkowym. Nazwę zapamiętałam skutecznie dopiero po wyjaśnieniu, skąd się bierze – mamy: unary, binary, ternary…

Operator ten występuje w większości języków programowania (Java, C#, JavaScript, PHP, Ruby…). Pozwala na skrócenie następującej formy zapisu:

if (warunek)
  zmienna = wartosc_gdy_prawda
else
  zmienna = wartosc_gdy_falsz

do formy jednolinijkowej:

zmienna = (warunek)? wartosc_gdy_prawda : wartosc_gdy_falsz;

Przydatne np. podczas sprawdzania, czy zmienna nie jest nullem:

return (field == null) ? "" : field.getValue();