piątek, 20 grudnia 2013

Podstawowa konfiguracja


Na samym początku warto zastanowić się w jakim środowisku oraz korzystając z jakich narzędzi będziemy wytwarzać soft.

 Na sam początek polecam książki , które po przeczytaniu bardzo mi pomogły poskładać to wszystko w całość :


 - Java power tools
 - Sonar code quality
 - Jenkins the definitive guide
 - Jenkins continuous integration cookbook
 - Release it
 - JBoss 5 Performance Tuning
 - Continuous Deliery
 - Maven (reference)
 - Building Scalable and High-Performance Java Web
 - JUnit in Action
 - JUnit
 - Web services testing with soapui
 - Selenium 
 - Selenium 2
 - Xunit test pattern

Ja używam :
Ubuntu - bo uważam , że wiele rzeczy mogę zrobić szybko i łatwo.
Np skrypty w środowiskach linuksowych są niesamowite .
Shell też jest dużo lepszy niż konsola windows (teraz używam fish'a) wcześniej był to bash .

STS  - bo używam springa a jednocześnie mam spore doświadczenie w eclipsie.
 Poza tym ma  Insight + tcServer - a to już sporo daje :)

Maven  -  mam również duże doświadczenie ale próbuje już używać gradle , zgodnie z trendem przejętym z innych frameworków jak Spring czy Hibernate.

Jenkins - bo po prostu jest najlepszy ;)

Nexus - tu wybór był również nie duży . Ale jestem przekonany do Nexusa bardziej niż do Artifactory.

GIT - bez dyskusyjne jest najlepszy z pośród VCS . W szczególności jak robisz dużo branch'y i merge'y.  Jak daje radę z jądrem linuxa to tym bardziej da radę z moimi wypocinami.

W STS używam eGit dla mnie jest jak najbardziej ok . Używam go głównie do przeglądania różnic podczas operacji merge.  Z konsoli wystarcza mi git + czasem odpalam gitk.

Sonar -  chce wiedzieć przynajmniej  poglądowo jak wygląda od strony QA mój kod .

JMeter , Grinder - testuje sobie wydajność

SoapUI - testuje WS i REST  , w pewnym sensie też JMeter to potrafi.

Gerrit - to jest w trakcie testów . W każdym razie jest to code review tool.

Scala - w trybie REPL ( programowanie eksperymentami)

JVISUALVM dawniej visualvm  - monitoring JVM

JConsole - monitoring JVM

Jstat , Jmap , Jhat - używam do wykrywania problemów wydajności

Selenium - testy UAT

Luke - indeksy lucene

Portecle - generacja i zarządzanie kluczami i cerfyfikatami

RestClient-UI - testowanie dla REST






































Moja podstawowa konfiguracja dla :
 -  bash (aliasy , exporty),
 -  git (alias + konfiguracja),
 -  eclipse (formatter , save action , editor , ini , oraz spis pluginów)
    to wszystko znajduje się  tutaj

dalej -> 


czwartek, 19 grudnia 2013

CI założenia i cele


CI  ->  CD (integration - > delivery)


Continuum Integration 
CI (Continuous Integration) (przykład jak to działa znajduje się tutaj)

CI jest to technika służąca ochronie i poprawie pracy nad projektem. Pomaga usprawnić proces wytwarzania i czyni ten proces mniej ryzykownym i bardziej przejrzystym oraz większa higienę w projekcie.  Ciągłe łączenie zmian wprowadzanych przez różne osoby w projekcie to również CI.

Generalnie  trzymamy się zasad opisanych na diagramie powyżej  i
zdefiniowanych przez samego M.Fowlera czyli integrować często i wcześnie.

Nie stosowanie dobrych praktyk CI i CD skutkuje zjawiskiem zwanym piekłem integracji (integration hell) czyli co może pójść niezgodnie z przewidywaniami :
  - błędy ludzkie
  - problemy z komunikacją w zespole
  - różnice w środowiskach uruchomieniowych (np inne wersje JDK czy przeglądarek)
  - błędy i różnice w plikach konfiguracyjnych
 Pewnie coś takiego każdy z nas zauważył jeśli nie stosował wcześniej narzędzi ciągłej integracji.

Fajnie pokazane jest to na stronie : blog.octo.com







Cykl życia w CI według mnie jest następujący :
- instalacja i konfiguracja
- zdefiniowanie build'u oraz polityki pobierania i kompilacji
- testowanie (unit test , integration test  etc)
- raporty oraz metryki
- budowanie paczki
- uruchamianie paczki na serwerze testowym oraz odpalanie testów UAT
- dostarczanie paczki do klienta (zdalny deploy , sftp , etc)

Dla mnie najlepszym przykładem oraz pierwszym objawem kiedy trzeba zastosować ciągłą integracje jest zjawisko, które nazywałem : ' U mnie działa ...'.
Ale kogo to obchodzi, skoro pobierasz aktualną wersje z repozytorium. Budujesz kod, wrzucasz na serwer i ....lipa. Nic nie działa.
Teraz myślisz a co mnie kur ... obchodzi, że u Ciebie mój drogi kolego jakoś zadziałało skoro na serwerze wszystko się wypierda......, lub dostajesz deploy failed.

Jest jeszcze gorsza wersja problemu :), a właściwie to lepsza bo występuję we wcześniejszym stadium wytwarzania softu mianowicie przy kompilacji.

Teraz okazało się znów, że kumpel zapomniał zrobić commit na jeden z klas.
O tyle ten przypadek jest lepszy bo łatwość zweryfikowania problemu jest o niebo łatwiejsza. Gorzej jeśli kod się kompiluje ale integruje źle z innymi komponentami lub klasami , albo wystąpił problem z java classloader bo ktoś zmienił wersję jakiejś biblioteki.
 
Tu wysuwa się pierwszy z naszych wniosków :
- profilaktyka jest tańsza niż leczenie 
(Wczesne wykrywanie błędów i konfliktów by można je było wystarczająco szybko wyeliminować - w miarę bezboleśnie.
Sprowadza się do w sumie do częstej kompilacji kody z repozytorium i wykonywania testów jednostkowych, a następnie powiadamianie różnymi kanałami o ewentualnych problemach)

Tutaj chcemy również żeby nasze build'y były możliwie szybkie.
Możemy to osiągnąć na kilka sposobów.

1. Ograniczamy i selekcjonujemy testy np poprzez lifecycle procesów z mavena lub profile.
Testy powinny wykonywać się szybko. Nikt nie będzie czekał przez 10 min aż zbuduje mu się paczka. Testy kŧóre wymagają integracji są z reguły czasochłonne bo wymagają inicjalizacji zasobów , wczytania kontekstu, czekania na odpowiedź itd.
Z kolei testy akceptacyjne UAT z reguły wymagają uruchomienia przeglądarki i przejścia po scenariuszach testowych.
Fajnie jest jeśli mamy odpowiednią separację takich testów. Fajnie to może złe  słowo - to raczej konieczność.
2. Wyznaczymy inną ścieżkę budowy w naszym CI (rozdzielany buildy)
Np czasochłonne testy wykonują się w nocy. Testy wydajnościowe wykonują się na innych maszynach a po ich skończeniu dostajemy informacje zwrotne o ewentualnych problemach.
3. Stosujemy pipeline.
Jenkins dostarcza plugin, który pomaga podzielić proces na części. W praktyce wygląda to tak, że nie musimy czekać aż wszystkie moduły które zależą od paczki końcowej się wykonają. Zwiększamy jakby bardziej ziarnistość procesu budowy.

Chcemy poprawić testowalość (testablility) naszej aplikacji, a CI nam w tym pomaga:
- automatyczne testy (regresja - daje nam pewność, że wcześniej dostarczona funkcjonalność nadal działa pomimo wprowadzenia nowych zmian)
- separacja testów (czytaj wyżej)
- monitoring czasu wykonywania testów
- monitoring pokrycia testami (test coverage)

 Drugi z naszych wniosków:
 - skracanie procesu wytwarzania i czasu wydania release'a
 CI sprawia , że prawie przez cały czas dysponujemy działającą wersją aplikacji, którą możemy pokazać testerom , a potem po ich akceptacji zmienić wersję z snapshot na release po czym otagować ją w repozytorium ponownie.
Ewentualne defekty poprawia osoba, które je wprowadziła ponieważ ma największą wiedzę z dziedziny problemu oraz kontekstu.
Dostajemy również łatwy dostęp do najnowszego artefaktu, a także każdego artefaktu historycznego.

Trzeci z naszych wniosków:
 - automatyzacja jest zajebista bo jest odporna na ludzkie błędy
Często spotkałeś się pewnie z następującym problemem czy zjawiskiem :
Szef projektu każe szybko przygotować wersji dla klienta z jakimś nowym CR czy poprawką w stosunku do powszedniej wersji. Twoim zadaniem jest tylko zbudować wersji odpowiadającą środowisku produkcyjnemu klienta. Tylko...
Pośpiech jest złym doradcą ....
Zapomniałeś zmienić profil z -Pdevelop na -Pprod , lub jeśli masz to zorganizowane w inny sposób w pliku .properties nie zmieniłeś parametrów bazy , adresu jakiegoś WS czy serwisu LDAP , lub obojętnie czego w zależności od specyfiki projektu.

Taka wersja trafia do klienta i z reguły nie działa. Traci na tym wizerunek firmy.
Jeśli są to odosobnione przypadki to jest jeszcze ok, każdy robi błędy i klient to zrozumie.
Gorzej jeśli to zjawisko występuje nagminnie. To kolejny powód by pomyśleć o CI w firmie.

Czwarty z naszych wniosków:
 - wspomaga zwinne metodyki wytwarzania
Continuous Delivery (CD) sprawia, że proces wytwarzania staje się faktycznie i praktycznie procesem zwinnym (agile). Cały cykl iteracyjny wytwarzania ma odzwierciedlenie CD.
Kompilacja - Testy - Budowanie - (Testy) - Dostarczanie.
Użytkownik końcowy jak i tester są bliżej wprowadzanych zmian i poprawek niż kiedykolwiek przedtem.
Przez to mają lepszy obraz funkcjonalności i  faktycznego postępu co z kolei definiuje szybki feedback z ich strony.
Klient faktycznie widzi jak z każdą iteracją aplikacji rozwija się co przekłada się na polepszenie obustronnego zaufania i zaciśnięcie obustronnej współpracy.

 Piąty z naszych wniosków:
 - każdy członek zespołu umie wyprodukować produkt końcowy łącznie z zainstalowaniem go na dedykowanym do tego serwerze. (Poprawa komunikacji (team collaboration)) oraz Collective Ownership (własność wspólna)
Częste commit'y oraz wspólny kod sprzyja manifestowi Agile oraz poprawia komunikacje w zespole. Nie istnieją "bogowie build'ow" czyli takie osoby, które jako jedyne są w stanie zbudować i dostarczyć paczkę dla klienta.
Taka wiedza powinna należeć do całego zespołu. Dzięki CI ten proces obywa się automatycznie (scheduled process) lub na żądanie wystarczy wcisnąć (play-> tzn  build) w jenkinsie.
Wszyscy widzą co się dzieje - (M.Fowler), każdy jest w stanie określić w jakim stadium znajduje się projekt oraz określić jakie zmiany do niego wprowadzono.

Szósty z naszych wniosków :
- zdecydowana poprawa jakości wytwarzanego oprogramowanie.
Podpięcie testów wspomaga przyszły refaktoring. Podpięcie narzędzi do statycznej analizy kody zwiększa higienę kodu, oraz eliminuje część złych praktyk oraz potencjalnych bug'ów.
Dzięki temu  przechodzimy do pojęcia (Continuous inspection) ciągła inspekcja, dzięki której możemy wytwarzać oprogramowanie lepszej jakości (sonar - timeline)

Definicja polityki pokrycia testami , tu możemy zakończyć proces budowy jeśli okaże się, że pokrycie testów (test coverage) nie pokrywa np 60% całości. Tak samo działa polityka wykrywania wszelkiego rodzaju nieprawidłowości w kodzie np : build kończy się niepowodzeniem jeśli system wykrył ponad 20 nowych problemów (issue)
Można zdefiniować repozytorium tzn staging dzięki któremu możemy wprowadzić funkcjonalność typu code review (np gerrit) co zwiększa kontrolę  oraz jeszcze bardziej poprawia jakoś finalnego kodu. Ponieważ kod, który znajdzie się docelowo we właściwym repozytorium musi być sprawdzony i zatwierdzony przez członka zespołu o największych umiejętnościach i wiedzy w danej dziedzinie.
Gramy w leader board - czyli stosujemy licznik i wprowadzamy zasady punktacji np : za każdy dobry deploy +1 punkt, za każde issue +3 punkty , za każdy TODO + 3punkt, za każdy nieudany build -1punkt, za wygenerowanie nowego issue -3 punkty itd.
CI wspomaga tworzenie soft TDD (Test Driven Development) - piszesz najpierw testy które z początku nie działają, a podczas budowania cała funkcjonalność musi przejść te testy. (JUnit , TestNG)   ->  mvn test
BDD (Behavior Driven Development) - zespół opisuje poprzez testy scenariusze i ustala warunki i wynik  ich wykonania. (jbehave, Cucumber) -> mvn verify

Jenkins posiada wtyczki pozwalające na odpalanie testów wydajnościowych stworzonych np przez JMeter dzięki czemu jesteśmy w stanie dotrzymać warunki zawarte w SLA projektu.

Siódmy z naszych wniosków :
- mniejszy poziom stresu dla całego zespołu, większa kontrola, dostarczanie produktu na czas. 
Jako podsumowanie naszym poprzednich 6 punktów przychodzi następująca konkluzja:
- wiedzę , że mam większą kontrolę na całością cyklu wytwarzania.
- odpowiednie osoby dostają odpowiednie raporty
- widzę czy wytwarzanie projektu idzie w dobrym kierunku
- dbam o higienę kodu - bardziej to CI to na mnie wymusza
- dostarczam natychmiastowo nowy produkt
- popełniam mniej błędów - wyeliminowanie do min czynnika ludzkiego.

 Kolejny ciekawy artykuł o CI  jest dostępny pod linkiem .

Inne dobre praktyki które mogę  polecić : 
- osobne konta w CI
- wprowadzenie polityki (zarządzanie i konfiguracja oraz dostęp do artefaktów)
- wszechobecne wiki
- polityka archiwizacji build'ów (harmonogram prac konserwacyjnych)
- korzystanie w różnych rodzajów systemów operacyjnych , dzięki czemu można 
testy integracyjne lub funkcjonalne na kilku różnych przeglądarkach.
-wirtualizacja CI
-polityka kopii zapasowych artefaktów.(murphy laws , backup plugin)
-monitoring zasobów : pamięć, procesor (javaMelody plugin), oraz wykorzystania dysków (disk usage plugin)
- zdefiniowanie właściwych parametrów MAVEN_OPTS
- przeglądanie logów budowy paczki (Log Parser Plugin) - pozwala nam to między innymi zagregować logi poziomem błędów.
- plugin do firefox - pozwalający na wgląd w stan aplikacji oraz pokazuje na bieżąco ich status (rss)
- integracja z groovy - pozwala na wykonywanie skryptów .groovy
- automatyczny deploy na zdalne repozytorium z udziałem ustawień znajdujących się w settings.xml mavena.
- slave axis - rozproszenie obciążenia na różne maszyny. Umożliwia stworzenie  macierzy rozwiązań tzn mogę uruchamiać i budować wersją pod różnymi systemami oraz testować na różnych przeglądarkach (Selenium, UAT test) lub wykorzystać różne instancje baz danych.
- oraz wiele innych ciekawych wtyczek które są opisane tutaj.

Szybkie i  bazowe konfigurowanie Jenkinsa w skrócie:
- konfiguracja global properties
- konfiguracja jdk
- konfiguracja jednego z wybranych narzędzi budowy np: maven
- konfiguracja systemu kontroli wersji np: git
- konfiguracja mail serwera do wysyłki wiadomości oraz potencjalnych odbiorców
- instalacja potrzebnych wtyczek
- dodanie użytkowników oraz uprawnień
- ewentualna konfiguracja proxy
- zdefiniowanie ewentualnych pre , post procesorów
- zdefiniowanie końcowych serwerów
 
dalej ->

Moje kategorie jakości oprogramowania



Ok, lecimy dalej. Zostawmy na razie poprzedni temat.
Jakiś czas temu opracowałem sobie kilka kryteriów wytwarzania softu.
Staram się zawsze sumiennie i szczerzę oszacować poniższe punkty. Taki rachunek sumienia. Potem należy się zastanowić co zrobić aby sprawić, by następnym razem wyniki nie były takie słabe.








Oceń swój najlepszy czyli Twój pewnie ostatni projekt :), bo każdy następny jest lepszy i to jest naturalny bieg rzeczy.

Potem odpowiedz sobie na pytanie co zrobić żeby było lepiej.

Czy te pojęcia coś Ci mówią ? :

Clean code, Separation of concerns, Convention over configuration

Stateless, Failover, LoadBalance, CRSF, Propotypowanie

Pociski smugowe, Agile, Scrum

DSL, Quartz, Responsive, CI

Maven , Gradle, AOP, Immutable, Guava, Scala

REST, Nosql, JSON, JMX, SLA, Pipe and Filter

MapReduce, Execution Orchestrator, GC, JIT

Nodes heterogeneity, Dynamic Reconfiguration, TPS

DTPS, Technical dept

etc

dalej ->


środa, 18 grudnia 2013

Wytwarzanie i rozwój : szkic























Wytwarzanie : przydatne informacje znajdziesz pod tym linkiem (link)
Generalnie informacje, które tam się znajdują stanowią podstawę zwinnych metodyk i dobrych praktyk. Powinny być one stosowane każdym cyklu życia wytwarzanej przez Ciebie aplikacji.

dalej ->

Książki



Na czym bazuje moja wiedza pisząc tego bloga ?

Generalnie na książkach. Czytam dużo. Swoich projektach i nabytym przez nich doświadczeniu , doświadczeniach innych, przeczytanych postach, blogach, analizie kodu z githuba, sourceforge, konferencjach ....
Staram się często wytwarzać projekty typu Proof of concept i nigdy kopiuje swoich poprzednich rozwiązań.
Staram się w miarę możliwości tworzyć generyczne rozwiązania. Wzorzec DI  załatwia sprawę ponownego wykorzystania danego modułu czy funkcjonalności.
Aktualnie próbuje poznać pozostałe języki oparte na JVM jak :  Scala czy Groovy oraz poznać lepiej i zwiększyć swoje doświadczenie w Big Data.


 Na początek polecimy po książkach :

Spring : 
- Spring in action od 1 do 3
- Pro spring 3
- Just spring data access
- Pro spring batch
- Publishing spring 2.5 Aspect Oriented Programming
- Pro spring mvc
- Spring batch in action
- Pro Java EE spring patterns
- Spring persistence with hibernate
- Spring Enterprise Recipes
- Spring data
- Spring data [Packt]
- Spring Recipes 
- Spring Security 3
- Spring Security 3.1


Hibernate :
 - Hibernate in Action
 - Java Persistence with Hibernate
 - Pojos in Action
 - Pro JPA 2

WS - REST :
- Apache CXF Web Service Development
- Restful Web Services
- Restful Web Services Cookbook
- Restful Java Web Services
- Rest in Practice
- Usługi WWW - bezpieczeństwo

Integration:
 - Camel in Action
 - Enterprise Integration Pattern Designing Building and Deploying

Java :
 - EJB3 in Action
 - Pro Java Management And Optimization
 - Pro EJB3 Java Persistence API
 - Beginning Java EE 7
 - Thinking in  java 1 .. 3
 - Struktury danych i techniki obiektowe
 - Effective java programing
 - Wzorce projektowe
 -  Refaktoryzacja do wzorców projektowych
 - GWT in action
 - jQuery in action
 - Pragmatyczny programista
 - Pragmatic thinking and learning
 - Clean code
 - Clean coder
 - Refaktoryzacja   
 - Skalowanie witryn internetowych
 - J2EE stosowanie wzorców projektowych
 - J2EE wzorce projektowe 
 - Optymalizacja serwisów internetowych
 - Architektura systemów zarządzania przedsiębiorstwem
 - Building Social Web Application
 - Java Performance on Multi-Core Platforms
 - Continuous Delivery
 - High Performance Web Sites Essential
 - The Art of Capacity Planing
 - The Art of Scalability
 - Scalability
 - Scalability rules
 - Pragmatic project automation
 - Java Concurrency in Practice
 - Pragmatic SQL AntiPatterns
 - Release it - Design and Deploy Production Ready software
 - CoderMetrics
 - Apache Tomcat 7
 - JBoss in Action
 - Tomcat The definitive  
 - Pro Apache Tomcat 6
 - Apache Maven 3 CookBook
 - Maven  - A Developer's Notebook
 - Oracle weblogic server 12c
 - Oracle weblogic server 10
 - Weblogic Server 8 For Dummies

 Agile - XP :
  - Zarządzanie projektami informarycznymi
  - Scrum
  - The Agile Samurai
  - Technologia w e-commerce
  - The art of agile development
  - The art of Project Management
  - Behind Closed Doors - Secret of Great Management
  - Agile coaching


  i wiele innych o których zapomniałem..

- Aktualnie czytam : 
 - Spring in practice
 - SOA Patterns
 - Seven Languages in Seven Weeks
 - Scala in Depth
 - Git
 - Making Java Groovy
 - The Well-grounded Java Developer

pozostałe warte zauważenia będę starał się dopisać w najbliższym czasie.

Oceń się sam...i sprawdz co wiesz część 1

Wiele programistów uważa - " kurwa ale jestem dobry ".
Piszę zajebisty kod. Wszystko prawie działa a najwięcej działa u mnie :)
Kod jest tak dobry, fajny i w ogóle , że .....
Jest jeden problem, niestety muszę go utrzymywać i tylko ja uważam, że kod jest piękny.
Czasem uda się coś napisać nawet szybko wystarczy miesiąc, dwa miesiące na całkiem spory i złożony system.


Wykorzystałem nawet nową wersję Javy, .neta czy innego chłamu, mam nawet dobry serwer, zajebistą bazę oracle 11 i cokolwiek jeszcze .
Ale czy to wystarczy? 
Teraz zadaj sobie pytanie: czy przejąłbyś chętnie system pisany przez innych - potencjalnie kolegów ?
Dla mnie odpowiednim miernikiem jest to, czy ktoś inny chętnie wykorzystuje moje API, funkcjonalność, moduł .

Jeśli stosujesz się do zasad SOLID i GRASP masz duże szanse, że Twój kod będzie dobry, a kolega chętnie przejmie Twój kod i będzie z nim sprawnie pracował .

Jeśli jeszcze dodasz testy będzie super :), dlaczego ? - bo test nie dość, że sprawdzą funkcjonalność to jeszcze będą najlepszą dokumentacją . Napisane w BDD pomagają także zrozumieć przypadki użycia.
Poza jest jeszcze jedno o czym powinieneś już teraz wiedzieć .
Dług projektowy (technical dept) - bierze się stąd, że nie wprowadzany odpowiednich zmian, pielęgnacji kodu , oraz usprawnień w następnych iteracjach procesu wytwarzania. Teraz wprowadzamy pojęcie refaktoryzacji (refactoring) -  w skrócie zmieniamy strukturę kodu bez zmiany jej funkcjonalności. Tylko następny problem - refaktoryzacja nie działa bez testów:)
Tzn można chwalić się , zrobiłem refaktoring jakieś funkcji czy klasy ale to jest podeście nie pełne.
Pierwsza zasada refaktoringu - refaktoryzuj tylko kod pokryty testami i spodziewaj się zielonego na ekranie :)

Następne pytanie czemu chętnie używasz np Springa czy podobnych frameworków ?
Odpowiedź jest następująca : bo mają dobre API , wysoki poziom abstrakcji i bazują na interfejsach.

Zapytany kiedyś na konferencji  James Gosling (twórca java) co zmieniłby  jakby miał jave napisać od nowa opowiedział - wyjeb.... klasy :)

Jakiś czas temu sam zauważyłem , że mój najlepszy kod z którego mogę być w jakiś sposób dumny - to czysta abstrakcja.
Dzięki temu dany moduł mogę wykorzystać wielu projektach i doskonale się do nich integruje - oczywiście dzięki DI . (czytaj : DI + GRASP + SOLID = 80% sukcesu)

Recepta :



Teraz pytanie co zrobić aby to poprawić ?
Edukacja..

Teraz czasy się zmieniły. Dostęp do internetu jest tani i powszechny.
Książki też nie kosztują majątku. Konferencje są często darmowe.
Wewnątrz firm teamy mogą tworzyć warsztaty.




Craftsmanship - wiesz co to jest ?  - to zainteresuj się .
A o to jego manifest :


1. Nie tylko działające oprogramowanie, ale również dobrze napisane oprogramowanie
2. Nie tylko reagowanie na zmiany, ale również ciągłe zwiększanie wartości
3. Nie tylko osoby i interakcje, ale również społeczność profesjonalistów
4. Nie tylko współpraca z klientem, ale również produktywne partnerstwo
Poznajesz te hasła ?
A może skojarzysz te : 
   - Cały czas doskonal swój warsztat
   - Lepiej zapobiegać niż leczyć.
   - Zły szelong zawsze wraca
   - Niezależnie jak piękny jest dom bałagan na biurku psuje wrażenie


Bardziej radykalne podsumowanie : 

Lepsze jest niedziałające programowanie ale dobrze napisane niż działające ale oderwane od wszelkich norm i zasad projektowych , ponieważ z tym pierwszym da się coś jeszcze zrobić natomiast drugie nadaje się co najwyżej do kosza
(trudno się  z powyższym nie zgodzić ale jak to wytłumaczyć dla biznesu ? )

To jest sprytna modyfikacja manifestu Agile :)

Następne pytanie czy Ty lub Twój Team wytwarzanie w duchu Agile ? - zastanów się dwa razy za czym powiesz tak :)

Craftsmanship zdobywał szybko popularność na zachodzie, tam już nie liczy się działające oprogramowanie, ale też produkt wysokiej jakości. Coś co jest określane terminem Clean Code (Uncle Bob mówi Ci to coś ?)

Czy w Twojej firmie spełnione są jakiekolwiek standardy , dobre praktyki itd ?
Teraz mógłbym wymienić z tuzin książek, które warto być przeczytał abyś ogarnął w jakimś stopniu temat by przejść do dalszej lektury.

Zadaj sobie następne pytanie : 

wychodzą nowe wersje  javy  : 1.4, 1.5 ... teraz 1.8
Czy potrafisz wymienić  features z każdej z wersji ?
np :
-  java concurrent ? - po co to jest, na co pozwala i co ułatwia, czemu to taki przełom w wielowątkowości ?
Przecież java została wymyślona jako programowanie sieciowe.

- Generics (np kiedy extends a kiedy super )?
- Try-with-resource ?
- NIO 2 ?
- Fork&Join ?
- Invokedynamic ?
- G1 ?
- czy teraz lamba w 1.8 ?

Dochodzą do tego biblioteki , które każdy dobry programista javy ma obowiązek znać (w kolejności od najważniejszej w moim przekonaniu ):
- GUAVA ?
- AOP (AspectJ) ?
- JODA TIME , MONEY ?
- LOMBOK ?
- LOGBACK ?
- SLF4J ?
- GSON ?

Testujemy :
- MOCKITO ?
- HARMCREST ?
- FEST ASSERT ?
- SELENIUM ?
- ConcurrentUnit ?
- Spock ?
- GRINDER ?
- JMETER ?
- Cucumber?
- PIT ?
- JBehave ?
- DB Unit ?
- SQL Unit ?

Dorzucam pojęcia : 
- EIP ?
- DI ?
- SOA ?
- TDD ?
- BDD ?
- DDD ?
- REST ?
- WS ?
- CI ?
- CD ?
- Clean code ?
- Refactoring ?
- JBPM ?
- Design Pattern (tych nie wymieniam bo zabrakło by dnia) ?
- Nosql ?
- MapReduce ?
- ORM ?
- Immutable ?


W książce pt : Pragmatic thinking and learning dowiadujemy się o modelu braci Dreyfus.

Możemy odbyć  podróż od adepta , początkującego w sztuce programowania na samą górę tej drabiny czyli do eksperta w danej dziedzinie.
Bracia opisali pięć poziomów doświadczenia. Poniżej moja interpretacja.
(Dreyfus model)

1. Novices (Począkujacy)
Jak sam tytuł mówi nie masz doświadczenia lub masz je niewielkie.
Fajny przykład podali autorzy : developer, który rzekomo twierdzi , że na 10 letnie doświadczenie , ale w rzeczywistości było to roczne doświadczenie ale powtórzone 9 razy. Więc nie liczy się to jako doświadczenie.

Inaczej:)
Hipotetycznie przychodzi facet do stolarza i mówi :
'Mistrzu mam 8 lat doświadczenia w bijaniu gwoździ w deskę '
Co odpowie na to stolarz ?.
Odpowie tak : 'chu...mnie obchodzi, że wbijałeś  8 czy 10 lat te pieprzone  gwoździe w jakąś dechę..
Jak dla mnie masz 2 tyg doświadczenia. W tej materii jak dla mnie nic więcej  już się nie nauczysz.'
Trudno się z tym nie zgodzić. Podobne zjawisko występuje w programowaniu. 
Przykład ze stolarzem jest może nieco przesadzony ale czasem lepiej walną z grubej rury, żeby do niektórych dodarło co robią.

Żeby coś zrobić dobrze muszą mieć podaną recepturę. (Novices need recipes)
Może wykonać pewne zadanie ale ktoś go musi prowadzić . Początkujący nie ma szerszej świadomości kontekstu ani problemu jakie może napotkać w swoim zadaniu.

2. Advanced begginer (Zaawansowany początkujący)
  Jest już lepszy w tym co robi. Potrafi znaleźć sobie potrzebne informacje o danym API. Nadal nie rozumie szerszego kontekstu. Ktoś musi podpowiadać mu rozwiązania. Często kopiuje rozwiązania już istniejące w kodzie, nie jest potrafi powiedzieć dlatego to właśnie tak ma być.

Przykład z życia.
Na początku swojej przygody zawodowej pracowałem z jednym zespole z obcokrajowcami. Nie istotne jakiej narodowości. Np nie hindusi, bo tych to w ogóle nie wiem do jakiej kategorii zakwalifikować;)

W każdym razie tamci mieli robić jakąś warstwę pomiędzy frontendem a backendem, która tak naprawdę nie była nikomu potrzebna. Nazwijmy ją adapterem. Goście mieli bogate CV, kilkunastoletnie doświadczenie jeszcze wywodzące się z cobola, bo wtedy nawet java nie istniała.

Podsumowując, śmieliśmy się z nich, że u nich jest taka charakterystyka:
im większe doświadczenie tym gorzej bo zdążyli przez ten czas więcej zapomnieć;)
(Advanced begginers don't want the big picture) 

3. Competent (kompetentny)
Ma nastawienie na konkretny cel i wie jak go osiągnąć. Jego praca opiera się bardziej na celowym planowaniu i doświadczeniu z przeszłości. Wypracowuje swój sposób działania który potrafi skutecznie wdrożyć. Stosuje się do porad ekspertów , posiada zdolność incjatywy i jest zaradny.
To co wcześniej sprawiało problemy teraz idzie to znacznie lepiej.
Może już być mentorem dla początkujących i nie drażnić ekspertów.
Jego rozwiązania pomimo , że nie są do końca idealne -  działają.
Dobrze posiadać takich ludzi w swojej drużynie. 
Generalnie nie chce wysilać się za bardzo (samodoskonalenie, edukacja) dlatego ciężko mu będzie wejść na następny poziom.
(Competents can troubleshoot)


4. Proficient (doświadczony) (need the big picture)
Jest już na zupełnie dobrym poziomie. Posiadł biegłość w danej dziedzinie.
Ma duże chęci do nauki . Potrafi znajdywać analogie do innych procesów.
Potrzebuje znać też cały kontekst.
Według autorów jest po poziom na którym osoba powinna skutecznie używać wzorców projektowych co niekoniecznie udaje się osobom na niższych poziomach.
W poprzednich poziomach osoba ma "błogi spokój" . Tutaj nawet po pracy intrygują go pytania i problemy z którymi na cały czas styczność.
Ciągle zadaje pytania : np czy warto persystować dane w bazie nosql, a jak tak to dlaczego ?
Ma poczucie że nic nie wie - to jest idealny przykład tego poziomu.
Proficient to ogromny przeskok jakościowy z poprzednim poziomem.
(Proficient practitioners can self-correct)


5. Expert (ekspert)
Główne źródło wiedzy i informacji na każdym polu. Zgromadził prawie kompletną wiedzę z danej dziedziny.
Wystarczy , że spojrzy i już poda receptę na lepszą metodę lub drogę zrobienia czegoś.
Taki ktoś często pisze książki , artykuły itd. Jest określany jako współczesny czarodziej - alchemik.
Widzi szeroki kontekst i działa intuicyjnie, bardzo szybko znajduje analogie do innych dziedzin. Myśli zawsze abstrakcjami. Konkretne klasy dla niego mało się liczą. Stosuje metafory. Często zdarza się tak , że nie potrafi argumentować swoich decyzji, a rozwiązania rodzą się same w głowie.
(Experts work from intuition)

 Ja dodałem jeszcze od siebie jeden poziom Guru. 
Na tym poziomie się nigdy nie znajdziesz. Guru jest odpowiednikiem Boga w programowaniu , wyznacza nowe trendy i tworzy kierunki rozwoju.


Czytaj dalej a dowiesz się więcej. Na wstępie będzie trochę  jak być  pragmatycznym i jakie korzyści z tego wynikną dla Ciebie i Twojej firmy.

dalej ->

Wstęp



Cześć ,

nauczmy się czegoś pożytecznego.
Niby umiesz programować, ale trzeba mieć świadomość, że nie jesteś najlepszy ani nigdy nie będziesz. Warto jednak dążyć do doskonalenia swojego warsztatu i poszerzania wiedzy.
Rób to systematycznie, a na wyniki będzie trzeba czekać krócej niż myślisz.





Ten blog niech będzie formą warsztatów :

- pokaże jak zrobić coś naprawdę dobrze,
- jak nie wpaść w pułapkę i nie narobić sobie kłopotów ,
- jak sprawić by kod był lepszy ,
- żeby nie pływać w czyimś gównie,
- nie zrobić tego samego innym,
- na co zwrócić  szczególną uwagę ,
- i jak  pobić tego skurwysyna jvm a samemu nie zostać pobitym (czyli jvm tuning),
- jak zwiększać wydajność ,
- jak eliminować wąskie gardła,
- jak zwiększać skalowalność ,
- jak korzystać w praktyce ze wzorców,
- jak zostać pragmatycznym programistą , 
- i wiele innych fajnych rzeczy....:)