Już 7 lutego 2012 r. zapraszamy na konferencję Business Intelligence w instytucjach finansowych. Podczas imprezy Tomasz Wielga z TouK przedstawi temat: „Agile BI – decyzje, o których nie wiesz, że będziesz musiał je podjąć, na podstawie dużej ilości danych, o których nie wiesz, że masz je zbierać”.

Miejsce: Centrum Bankowo-Finansowe „Nowy Świat” S.A., Warszawa, ul. Nowy Świat 6/12.

Udział w konferencji  jest bezpłatny dla przedstawicieli sektora finansowego, wymaga jednak wcześniejszej rejestracji.

Jeśli jest problem z pobieraniem plików z polskimi znakami diakrytycznymi, to trzeba dopisać kodowanie do connectora w tomcat/conf/server.xml

URIEncoding="UTF-8"

Typowa konfiguracja connectora będzie wyglądała tak

<Connector port="8080" protocol="HTTP/1.1"
               connectionTimeout="20000"
               redirectPort="8443" URIEncoding="UTF-8" />

Ostatnio na jednej z rozmów rekrutacyjnych dowiedzieliśmy się, że na grupie dyskusyjnej warszawskiego juga pojawił się kiedyś wątek: “jakie pytania zadawać pracodawcom”. Postanowiliśmy odpowiedzieć na pytania jakie na początku zadał Witalij Olejnik.

1. O której zaczyna się i kończy praca?

Jesteśmy umówieni, że wszyscy są w biurze pomiędzy 10-16. Pracujemy osiem godzin dziennie. Od każdego indywidualnie i od umowy z resztą zespołu zależy czy zacznie pracę o 8 czy o 10:00. Staramy się nie zostawać po godzinach, w części projektów są dyżury z domu.

2. Którego dnia miesiąca pensja wpływa na konto?

Zwykle do ostatniego dnia miesiąca. Jeśli ktoś wystawia fakturę, w ciągu kilku dni od wystawienia.

3. Czy zespół spotyka się po pracy?

Raz w roku mamy imprezę ogólno firmową, w między czasie chodzimy na piwo (jak pojawi się taka inicjatywa), zdarza się, że gramy w piłkę lub squasha.

4. Jakie narzędzia poza IDE są wykorzystywane?

Nie narzucamy używania IDE, chociaż większość osób używa IDEI. :-) Pilnujemy zasady, żeby projekt budował się i testował z linii poleceń. Dzięki temu od razu działa ciągła integracja i statyczna analiza kodu. Jeśli potrzebne są inne narzędzia, to je kupujemy i używamy.

5. Czy odbywają się wewnętrzne szkolenia?

Tak, piątek jest naszym dniem nauki. Odbywają się wtedy warsztaty OCR (Open Code Review), wykłady technologiczne oraz nauka prezentacji. Jak masz dobry pomysł na zespołową naukę, chętnie pomożemy Ci w realizacji.

6. Czy piszecie testy jednostkowe, jeśli tak to czego do tego celu używacie?

Tak, kilku orędowników-ewangelistów nas tego nauczyło. Nowe projekty mają całkiem niezłe pokrycie testami. Narzędzia są różne w zależności od projektu, zespołu, technologii – junit, mockito, jmock, spock. Jakoś testujemy javascrypty – o szczegółach będzie na wykładzie w piątek. Może autor opisze to na blogu?

7. W jaki sposób jest gromadzona wiedza? Wiki?

Wiedza jest w samodokumentującym się kodzie. I na firmowym Confluence.

8. W jaki sposób tworzycie warstwę dostępu do danych?

Nie tworzymy, sama się robi. A jeśli to – z jakiś przyczyn – pobożne życzenie, to używamy narzędzi, które w danym kontekście są najlepsze.

9. Jakie frameworki wykorzystujecie w warstwie prezentacji?

Ja pamiętam: Strutsy, Wicketa, GWT, GXT, SmartClient, Spring MVC. Pewnie było ich więcej.

10. Czy istnieją wewnętrzne frameworki/biblioteki?

Najważniejsze są doświadczenia. Mamy mało powtarzalnej pracy, dlatego wolimy korzystać z otwartego oprogramowania, niż tworzyć własne frameworki. Z naszych większych kawałków softu na Apache-u są: xmlbeansxx – biblioteka do manipulacji XMLem w C++ oraz HISE – implementacja specyfikacji WS-HT.

11. Czy używacie serwera ciągłej integracji?

Aplikacji pilnuje u nas Jenkins.

12. Jakie metody prowadzenia projektów stosujecie?

Wewnątrz zespołów używamy zwinnych metodyk. Czasem metodyka ma inną fasadę dla klienta.

13. Czy prezes firmy programuje/programował?

Niestety cały zarząd ciągle programuje. :-)

14. Czy mój przełożony  programuje/programował?

Jest to niemal pewne. Tylko dwie osoby ze wszystkich 60, które zajmują się na co dzień projektami nie programuje obecnie, ale wszyscy kiedyś programowali.

15. Jakiego narzędzia do śledzenia błędów używacie?

Do wizualizacji błędów i zadań w ogóle – tablicy z postitami. Jeśli w grę wchodzi współpraca z klientem, to różnych systemów ticketowych u klientów.

16. Narzędzia do budowania projektów?

To zależy od zespołu, technologii. Musi działać z linii poleceń, zwykle Maven, którego używamy też do zarządzania wydaniami, ale też ant i różne skrypty.

17. Dlaczego poprzedni pracownik zrezygnował?

Dostał lepszą finansowo ofertę, przeprowadził się (z żalem). Generalnie poświęcamy sporo czasu na rekrutację i mamy małą rotację.

18. OK, pokazałem wam swój kod, a teraz pokażcie mi swój.

https://github.com/TouK/

19. Jeżeli odpowiedź na niektóre z pytań (nie na wszystkie, inaczej tam nie idę;-) ). 4, 6, 7, 11, 12, 15, 16 będą negatywne: czy ja będę miał możliwość jego (narzędzia)  uruchomienia?

Jak sądzisz?

Magda (i Witek)

Jeżeli jesteś pasjonatem programowania przyślij swoje CV z opisem projektów, w których pracowałaś/eś i którymi chciał(a)byś się pochwalić, komercyjnych lub/ i open source’owych lub własnych.

więcej informacji

TouK angażuje się w aktywności Warszawa JUG. W czerwcu sponsorował Confiturę 2011.
Tym razem wsparł Warsjawę, nie tylko finansowo, ale również fundując książki, które zostaną rozlosowane podczas warsztatów.

Warsjawa 2011 już w najbliższą sobotę, 15 X 2011, na Wydziale Elektroniki i Technik Informacyjnych PW.

Już za 10 dni Agile By Example. Pierwsza warszawska konferencja o tematyce szeroko pojętego "Agile". Na dwudniowej konferencji można posłuchać ludzi, którzy od dawna tworzą ten ruch. Będzie też i "nasz człowiek", Piotr Burdyło, który przedstawi Kontrakty Agile'owe, w których TouK i Piotr w szczególności ma duże doświadczenie.
Pogodzenie "zwinności" i "stałości" korporacji jest bardzo trudnym zadaniem. Piotr opowie jak pogodzić te dwie strony - Software House wytwarzający zwinnie oprogramowanie i korporacje, dla których kwestie prawne i ścisłe trzymanie się ustaleń umów są kluczowe.
Piotr nie jest prawnikiem. Jest praktykiem, który potrafi skutecznie połączyć te nie-połączalne strony :)

Do zobaczenia na ABE 2011.

Pod koniec czerwca miałem przyjemność powiedzieć kilka słów na konferencji Integracja Systemów Informatycznych GigaCon 2011. Z pozostałych prelekcji najbardziej zainteresowała mnie ta przeprowadzona przez pana Jarosława Żelińskiego. Zresztą sam prelegent w jednym z pierwszych zdań stwierdził, że będzie ze mną polemizował (moja prezentacja była wcześniej), czego potem raczej nie robił. Choć sam główny temat jego prelekcji nie był może z punktu widzenia osób tworzących systemy IT odkrywczy, to wszelkie dygresje były bardzo ciekawe, ale … w większości trudno się mi było z nimi zgodzić. I pewnie dlatego były dla mnie ciekawe.

Od tamtego czasu stałem się stałym czytelnikiem blogu pana Żelińskiego. Chciałbym się podzielić kilkoma spostrzeżeniami do treści tam prezentowanych.

Zacznę od drobnej złośliwości. W maju, jako że sięgnąłem też do starszych wpisów, autor napisał: „[...] ja już wyrosłem ze społecznych źródeł wiedzy jakim jest Wikipedia i przytoczę definicję z książek mających konkretnego autora [...]”. A dzisiaj czytam, jak autor krytykuje praktyki Agile … czerpiąc wiedzę na ich temat z tego społecznego źródła wiedzy. Kończąc złośliwość dodam adresując to do autora, że Wiki i Wikipedia to nie to samo i mają się do siebie tak ja klasa do obiektu. :P

To moje łapanie za słówka pokazuje jednak pewien problem. Pan Żeliński lubi zaczynać myśl od „nie jestem wrogiem Agile”, by potem jasno swoją wrogość do tych idei przedstawić. A z wrogością często bywa tak, że jest ona skierowana do czegoś, czego się do końca nie zna.

Z czerwcowej konferencji zapamiętałem pan Żeliński ostrzegał przed zwinną (Agile) integracją, która miałaby polegać na tym, że programistom daje się dostęp do bazy danych a ci (bez jakiegokolwiek zastanowienia) z nowego kodu z takiej bazy korzystają. Co to ma wspólnego z Agile? Otóż idee Agile nie mówią o tym jak ma wyglądać architektura oprogramowania, tylko jak powinien/może wyglądać proces tworzenia oprogramowania. W tradycyjnych (starych) metodykach analityk czy projektant też mógłby programistom przekazać (raczej nakazać), że mają w identyczny sposób taką integrację wykonać. Tyle tylko że, w przeciwieństwie do metodyk zwinnych, od źle wykonanej analizy czy złego projektu nie byłoby wtedy odwrotu, bo przecież zdaniem pana Żelińskiego dobry programista nie dyskutuje z projektantem.

Oczywiście tak jak wiele osób programujących mówi, że stworzony przez nich kod programu jest bezbłędny, dokładnie przetestowany a niuanse platformy mają w jednym palcu, tak i analityk może powiedzieć, że opracowany (odkryty) przez niego model dokładnie opisuje rzeczywistość, jest przetestowany a samą dziedzinę rozumie doskonale. Megalomania albo pokora – wybór należy do ciebie. Błąd można popełnić zawsze. Jednak w tradycyjnych metodykach błąd w analizie jest dużo bardziej kosztowny niż błąd w kodzie programu.

Ten problem dostrzega również pan Żeliński pisząc w innym z wpisów, że „źle wykonana analiza przeciętnie podnosi koszty dwukrotnie a bywa, że znacznie więcej”. Z tym że jego rozwiązanie widzi w bardziej rozbudowanej fazie analizy, co ilustruje diagramem z „kosztowną pętlą odkrywania wymagań”. Jako źródło podana jest firma IBM. Mamy więc tzw. argument przez odwołanie się do autorytetu. Znana firma zrobiła badania (zrobiła?) i z nich wynika założona teza. Bardzo dobry argument… do czasu aż autorytet zmienia zdanie. Bo rozwiązaniem problemów z kosztami wynikająymi ze słabej analizy nie jest (już?) według firmy IBM wydłużanie jej czasu przed fazą implementacji, tylko stosowanie zwinnych (agile) metodyk i choćby  w takim kierunku zmierza sztandarowy zestaw produktów tej firmy wspierających proces tworzenia oprogramowania – IBM Rational.

W zasadzie to może błędnie napisałem, że nasz „autorytet” zmienił zdanie? Może zrobił dokładnie odwrotnie? Bo metodyki zwinne nie polegają na likwidacji fazy analizy, jak wydaje się sam to rozumieć a sugerować innym pan Żeliński, tylko na maksymalnym możliwym jej wydłużeniu, czyli … na cały czas trwania projektu. Scott Ambler (chief methodologist for Agile at IBM Rational) napisał kiedyś, że „analiza jest tak ważna dla praktyków Agile, że robimy ją każdego dnia”. Temu służą planowania, stand-up meetingi. Po to zwinny zespół winien być wielofuncyjny, czyli posiadać więdzę i umiejętności w pełnym zakresie wymaganym do tworzenia oprogramowania, w tym również umiejętności analityczne. Nie są one jednak skupione w pojedyńczych, wyizolowanych osobach, które na dodatek innych przydatnych umiejętności nie mają. Agile to nie brak tak lubianych przez pana Żelińskiego diagramów UML, tylko wykorzystanie ich do przekazywania i uspójniania wiedzy, kiedy jest taka potrzeba, a nie jako (podstawowa) forma komunikacji z zamawiającym oprogramowanie.

I w tym miejscu odeślę do dość już leciwego źródła http://www.agilemodeling.com/essays/agileAnalysis.htm

Wydawałoby się, że skoro można nazwać kolumnę „DATE” jeśli umieści się ten wyraz w cudzysłowach to jest to bezpieczne. Okazuje się jednak, że używanie tej nazwy powoduje następujący błąd kompilacji w procedurze wykorzystującej na wejściu typ wierszowy na tej tabeli:

ORA-06552: PL/SQL: Compilation unit analysis terminated
ORA-06553: PLS-320: the declaration of the type of this expression is incomplete or malformed

Dzieje się tak, mimo że widok na tej tabeli działa poprawnie i można przez niego wrzucać dane. Podobny błąd występuje, gdy kolumna nazywa się NUMBER, ale dla VARCHAR, VARCHAR2, INTEGER, FLOAT, TIMESTAMP, CLOB, LOB, CHAR, LONG precedura działa poprawnie.

Poniżej test dla typu DATE

create table test_date ( "DATE" date );
create table test_date2 ( "DATE2" date );

-- ta procedura się nie kompiluje
create procedure pr_test_date(p_date test_date%rowtype) as
begin
 null;
end;

create procedure pr_test_date2(p_date2 test_date2%rowtype) as
begin
 null;
end;

create view v_test_date as select * from test_date;
create view v_test_date2 as select * from test_date2;

insert into v_test_date("DATE") values (sysdate);