Pokazywanie postów oznaczonych etykietą różne. Pokaż wszystkie posty
Pokazywanie postów oznaczonych etykietą różne. Pokaż wszystkie posty

22 października 2014

Słowotok społecznościowy głównie na twitterze - za krótko jednak

1 komentarzy
Pamiętam bardzo dobrze czasy, kiedy mikroblogowanie nie było dla mnie wartościowym sposobem wymiany myśli. Ostatnio jednak jest zupełnie inaczej.

Zreflektowałem się, że kiedykolwiek chciałbym przekazać myśl, wybieram twittera. Jakkolwiek 144 znaki nie pozwala na "wyrzucenie" z siebie wszystkiego, to po kilku latach korzystania z tego medium, daję radę.

I to mnie właśnie przeraża w twitterze - jego prostota, która zawęziła moje pole literackiego działania do owych 144 znaków.


Po całym dniu "strzelania" 144 znakami na twitterze mam po prostu dosyć i wszystko zostało już w zasadzie powiedziane. Co mi tam zatem zabierać się za wpisy na blogu (szczególnie polskim niestety), kiedy, co chciałem powiedzieć, powiedziałem, a resztę przeczytałem na Quora lub StackOverflow.

W Quorę dopiero wchodzę i traktuję ją wciąż jako niewielką alternatywę do StackOverflow, na którym wyżywam się głównie na kanale sbt. I właśnie po takiej dziennej dawce wypowiedzi na SO, pisania mam już wystarczająco w zakresie ponad 144 znaków.

Do tego dochodzi jeszcze monitorowanie (w trybie do odczytu) LinkedIn, trochę commits na GitHub i idę spać z głową naładowaną pomysłami. A że obecny sponsor pozwala na szerokozakrojone wizje architektoniczne, to i czytania (dla wybrania właściwego rozwiązania) sporo.

Zatem jakbym był wszędzie, a nie ma mnie tutaj.

Możnaby zapytać, dlaczego mnie to martwi i dla zainteresowanych śpieszę z odpowiedzią - brakuje mi możliwości poruszania nowych technologii w dyskusjach w naszym, lokalnym, polskim środowisku informatycznym. Nie mówię, że nie ma spotkań/meetupów czy konferencji, ale wciąż brakuje mi miejsc, w których mógłbym poruszyć kwestie adekwatności stosowania nowych technologii, które mnie obecnie zajmują, do zadanych obszarów. Weźmy Spark, Storm, etcd, Docker, Ansible, ZooKeeper, Cassandra, bazy grafowe (z Titan), Mesos, Curator i kilka innych poza-stricte-scalowych tematów, które zajmują mnie ostatnimi czasy, bo jedynie czuję, że one mogą spełnić moje wymagania architektoniczne (oczywiście to jedynie już zawężona pula projektów, które rozważam po "ostrej" selekcji). Wciąż zdecydowanie za mało spotkań typu hackathon czy warsztatów, gdzie z innymi napaleńcami rozwikływałbym tajniki produktu i konsultowałbym pomysły.

Podczas rozpoznawania produktu, tworzę wiele notatek na boku, w Evernote, i tak sobie myślę, że warto byłoby je upublicznić pro publico bono i mojej. Mam jednak pewne obawy przed plagiatem, bo większość z materiału w moich notatkach, to kopie całych zdań, które są kwintesencją pełniejszego artykułu czy prezentacji. Chciałbym je jednak móc skonfrontować z wiedzą innych lokalesów.

Skoro zależy mi bardzo na ożywieniu polskiego środowiska informatycznego pod kątem zastosowania nowych technologii (niekoniecznie wyłącznie programistycznych ze Scalą w roli głównej) oraz wyrażaniu swoich myśli obszerniej (poza 144 znaki), to może właśnie należałoby skorzystać z tego miejsca - na polskojęzycznym blogu - i tutaj szukać merytorycznego wsparcia.

Pamiętam rozmowę z Bartkiem Zdanowskim, który (podczas naszej wspólnej wizyty na konferencji we Lwowie) wspominał z rozrzewnieniem o wygaszonej już inicjatywie Sebastiana Pietrowskiego, która polegała na publikowaniu wpisów z blogów z krótkimi opisami na własnym blogu, co pozwalało na zorientowanie się w pojawiających się co rusz nowych narzędziach. Nie zamierzam tego reaktywować, ale coś na ten kształt się właśnie w mojej głowie kluje.

Niech ten wpis będzie swoistym ożywieniem tego miejsca. Do usłyszenia niebawem!

A Ty gdzie zrzucasz stan swoich rejestrów mózgowych do publicznej konsumpcji? GitHub Pages może? Inne medium? Czy po prostu tak leciwie trochę w postaci notatek na boku na dysku lokalnym? Chciałbym móc znaleźć właściwe miejsce...

p.s. Jeśli chciałbyś dołączyć do mojego zespołu "poszukiwaczy właściwych rozwiązań", skontaktuj się ze mną na jacek@japila.pl. Pogadajmy!

23 maja 2014

#StackOverflow, #twitter i #github na #javotok'u w @javeo_eu

0 komentarzy
Wprosiłem się na spotkanie w @javeo_eu i zawłaszczyłem czas antenowy tematem "#Be #social #FTW - #stackoverflow, #github, #twitter et al for professional #development".

Zależało mi najbardziej na zbudowaniu platformy otwartej wymiany opinii na temat korzystania z mediów społecznościowo-programistycznych dla własnych celów rozwojowych (przede wszystkim), które, przy pewnej wytrwałości w działaniu, wpływają również na postrzeganie pracodawcy delikwenta (pożądany skutek uboczny). Cieszę się, że się udało i w jednym miejscu zgromadziło się 13 osób, wśród których był właściciel/prezes, Magda od spraw HR/PR, juniorzy, seniorzy i pamiętający dawne czasy Javartu.

Pytanie wiodące było: Jak zbadać siłę merytoryczną zespołu?

Po raz pierwszy doświadczyłem olśnienia znaczenia pytań "Kto...?" podczas wystąpień publicznych, gdzie nie ma mowy o większej interakcji niż podniesienie ręki. Pytania kto? są swego rodzaju pytaniami czy? z tą jednak różnicą, że pierwsze kto? wymusza jedynie gest, a drugie werbalne wyrażenie zdania, co nie pozwala na jednoczesną rekację większej liczby osób, a dodatkowo wprowadza niepożądany hałas (przy grupie > 5 osób). Muszę jeszcze pamiętać, aby samemu wyrażać zdanie przez podniesienie ręki po lub w trakcie zadawania pytania. Ciekawa technika.

Możliwość odpalenia tej inicjatywy w zaprzyjaźnionej firmie javeo utrwaliła we mnie przekonanie o konieczności kontynuowania tego typu wymiany wiedzy - w budynku firmy, w dzień luźniejszy projektowo aka piątek i w ramach godzin pracy. Sądzę, że przy odpowiednim dopasowaniu godzinowym, np. godzina 10:30 i właściwej aranżacji miejsca spotkania - wyżywienie, napoje, okna ze słońcem na zewnątrz, wygodnymi pufo-fotelami, itp. - mogłoby sprawić ciekawy dodatek w życiu pracownika.

Spotkanie zaplanowane było na godzinę, ale jakimś przypadkiem przeciągnęło się do dwóch :) Bywa. Wybaczcie znudzeni i cieszcie się niespożyci kontynuacji tematu. Postarajmy się wspólnie następne spotkanie wpasować w gusta czasowe większej liczby uczestników. Z 13 osób zostało do końca 7, co przy konkurencji z dzisiejszym spotkaniem o MongoDB uważam za wynik bardzo dobry.

Mam nieodparte wrażenie, że w wyniku spotkania w javeo pojawi się kilka ciekawych inicjatyw rozwojowych, w których nie zabranie prelegentów na najbliższych konferencjach (ukłony dla Zbyszka) i nie będzie trzeba czegokolwiek redukować (ukłony dla Tomka i Przemka), chyba że korzystając z języka Scala wespół z map i filter (ukłony dla Grześka i Wojtka). Było ciekawie, a dla mnie największa nauka płynie taka, że kiedy oczekuje się dyskusji i się ją wznieciło, to należałoby odsunąć się po prostu w cień i słuchać, pozwalając na wymianę zdań między uczestnikami. Nie bez przyczyny mamy więcej narządów słuchu niż mowy! Do zapamiętania.

Dzięki za zaproszenie i niezwykle inspirującą dyskusję. Ciekawym opinii uczestników. Od jednego już mam, więc brakuje jeszcze 12. Nadsyłajcie hejty i lajki. W zamian obiecuję podobne reakcje :) Do następnego razu!

07 października 2013

Czytelność kodu a przegląd kodu w moim zespole w Citi

0 komentarzy
Nie miałem jakiejkolwiek wątpliwości, że przejście do Citi będzie dla mnie wyjątkowe pod wieloma względami. Ot, chociażby dzisiejsze spotkanie zespołu celem przeglądu kodu jednego z nas - nazwisko ominę (wybacz Artur).

W jeden sali miałem okazję zasiąść z (kolejność przypadkowa) Marcinem, Grześkiem, Tomkiem, Arturem, Pawłem i innymi, mniej lansującymi się w Sieci, ale wciąż światłymi osobami (określenie "lansowanie" używam tutaj wyłącznie w pozytywnym znaczeniu). Wielu ich zna, niektórzy nawet osobiście, ale niewielu może z nimi pracować na co dzień. Ja taką okazję mam i nie zamierzam jej marnować, więc uczestniczę we wszystkich spotkaniach. Uważam, że obcowanie z mądrym sprawia, że sam się nim stanę (?), a co najmniej zbliżę się do takiego poziomu. Dziękuję Panowie!

Podczas pierwszego przeglądu kodu, wyniknęła dyskusja o czytelności kodu. Początkowo sądziłem, że to kolejne marnowanie czasu, ale wystarczyło wstrzymać się z dalszymi ocenami, aby przekonać się, jak bardzo się myliłem. Dyskusja rozgorzała, kiedy pojawił się poniższy kawałek kodu:
  val wasStateChanged = prevCMStatusState match {
    case Some(prevState) => prevState != currentState
    case None => true
  }
Ten kawałek został zganiony za powtórzenie implementacji metody Option.fold. Korzystając z niej możnaby powyższe zapisać następująco:
  val wasStateChanged = prevCMStatusState.fold(true)(_ != currentState)
I tu się zaczęło.

Kiedy zobaczyłem fold zacząłem rozkładać prevCMStatusState na elementy (zakładając, że to kolekcja). To był błąd, bo prevCMStatusState to scala.Option.

Zajęło mi chwilę, co mogłoby to robić, ale kiedy dowiedziałem się, spodobało mi się. Jakieś takie geek'owe :) I tu cały pies pogrzebany. Może faktycznie geek'owe, albo po prostu moja nieznajomość (ignorancja) podstawowych klas i ich metod w Scali sprawiła, że odniosłem takie wrażenie. Nieistotne, bo szybko stałem się zwolennikiem Option.fold. Nie wszyscy.

Inny przykład mógłby być taki:
  case class X(age: Int)
  Some(X(40)).fold(false)(_.age > 30)
Odczytanie tej linijki z Option.fold zajmuje mi tyle samo czasu, co odczytanie pattern matching wyżej, a pisze się krócej, więc obstaję za wersją krótszą.

Ale czy krócej to piękniej? I czy nie przekraczamy cienkiej granicy czytelności kodu nad jego zwięzłością? I czy czytelność kodu jest cechą kodu czy relacją między kodem a czytelnikiem. Sądzę, że to drugie.

Dla mnie czytelny kod nie musi implikować jego czytelności dla Ciebie czy Twoich znajomych. Dyskusja sprowokowała mnie do zastanowienia się nad (lekko wyświechtanym) określeniem "czytelność kodu". Dla mnie, czytelność kodu jest wypadkową doświadczenia czytelnika, a nawet nastroju. Dzisiaj jestem w stananie czytać między liniami, ale czy jutro również będzie mi to dane? Zdecydowanie obstaję nad pełną znajomością standardowej biblioteki języka (w tym przypadku Scali), więc jeśli mamy Option.fold w Scali, to będę z tego korzystał (zamiast pisać implementację za każdym razem, gdzie Option.fold mógłby być zastosowany).

A jak z Twoją definicją czytelności kodu? Czy powyższy przykład mógłby stanowić podstawę do takiej dyskusji z Tobą? Czy znasz inne, kontrowersyjne przykłady?

29 września 2013

Wiktor o Scrumie dla lokalnych społeczności a Grzegorz z 33rd Degree dla dzieciaków

0 komentarzy
Kilka dni temu napisał do mnie +Wiktor Żołnowski, który przedstawił pewien pomysł warty uwagi. Poprosił, aby pomóc mu nagłośnić temat, a że zacny (temat), więc nie tracąc czasu...

Cześć,

Realizuje właśnie jeden ze swoich pomysłów na rozruszanie lokalnych społeczności IT.

Pomysł jest stosunkowo prosty - ja daje coś od siebie - w tym wypadku darmowe szkolenie ze Scrum - 8h mojego czasu, a uczestnicy w zamian za udział mają poświęcić swoje 8h na rzecz dowolnej społeczności IT/Agile, cokolwiek.

Więcej informacji na moim blogu: http://blog.testowka.pl/2013/09/17/nie-do-konca-darmowe-szkolenie-scrum/.

Może zechciałbyś wspomóc inicjatywę i napisać coś o tym u siebie. Albo w ogóle samemu zrobić coś podobnego?

Pozdrawiam,
Wiktor Żołnowski

Chwilę potem napisał do mnie +Grzegorz Duda, który w podobnym tonie napisał o swojej inicjatywie - 33rd Degree 4 charity. Kolejna zacna inicjatywa, której nie opublikować na moim blogu, grzechem możnaby nazwać. A że dodatkowo ładnie napisał...

Jacek,

Przychodzę do Ciebie z prośbą, czy nie mógłbyś napisać parę słów o 33rd Degree 4 charity?

Masz najbardziej poczytnego bloga, więc taki wpis na 100% przyczyniłby się do zebrania kilku złotych więcej dla dzieciaków i rodzin w trudnych sytuacjach...

Regards/Pozdrawiam,
Grzegorz Duda

06 sierpnia 2013

Ach, cóż to były za wakacje! Niechorze rządzi

3 komentarzy
Ach, cóż to były za wspaniałe wakacje!

Gdyby ktoś mi powiedział jeszcze kilka tygodni temu, że nad naszym polskim morzem (w Niechorzu i okolicy) może być taka pogoda, fale i ogólnie atmosfera, nie dałbym temu wiary.


Zaplanowaliśmy nasz rodzinny wyjazd na wczesny, sobotni ranek, o 4:00 w sobotę, 20 lipca. Trasa do Niechorza trwała ponad 12 godzin (!), więc kiedy dotarliśmy na miejsce, pozostał nam już tylko krótki spacer po plaży i wio do spania z Maksymkiem.

Kolejne dni już dane nam było spędzić według schematu: pobudka chwilę przed 8, śniadanie do 9, spacer do Boryska do 10 i smażing do 12, aby zdrzemnąć się z Maksymkiem do 15, obiad od 16 do 17 i spacerowanie po okolicy do 20, kąpiel Maksymka i ziuziu spać. Całkiem pozytywnie wpłynęło to na naszą kondycję. Każdemu przydała się spora porcja spania!

Starszaki - Iwetka i Patryk - "broili" do późnego wieczora, więc trudno było znaleźć kogoś niezadowolonego.

Chyba, że wspominamy drugi tydzień, kiedy to pogoda podupadła i zaczęło padać. Tutaj należało już wykazać się inicjatywą, co zrobić z czasem między śniadaniem a południem i później po południowym spaniu Maksymka do wieczora. Mimo przelotnych deszczy, pogoda pozwalała na krótkie wypady nad morze i przez to było cudownie.

Siedzieliśmy nad morzem prawie pełne dwa tygodnie, a wciąż nie mieliśmy dosyć (Agata i Ja z Maksymkiem, bo Iwetka z Patrykiem nawiali do Warszawy na swoje koncerty).

Kąpiel w morzu była (prawie) codziennie. Fale były również. Maksym z Boryskiem bawili się w piachu całym sobą. Słońca ponad miarę. Ryba smaczna (w Kergulenie i u Cywila). Jedzenie w Jantar-Spa na medal. Słowem - żyć, nie umierać.


Akurat ten dwutygodniowy wypoczynek zbiegł się z moim przejściem do nowej pracy w Citi, więc kolejna zmiana - wyjazd poza Warszawę na dłużej - tylko mnie podkręciły. Czuję się wypoczęty i gotowy do kolejnych wyzwań! Kto chętny sprawdzić?! :-)

A skoro o wyzwaniach to zapraszam do udziału w kolejnym przedsięwzięciu - projekcie scalania, którego celem jest spopularyzowanie języka Scala i podreperowanie wiedzy z zakresu algorytmiki (bo mi się kandydaci do pracy wykruszają i nie ma kogo rekrutować). Już zakasałem rękawy i uwijam się, aby zdążyć przez warsjawą, bo chodzi mi po głowie poprowadzenie scalowego warsztatu! Kto wyraziłby zainteresowanie udziałem?

01 lipca 2013

Pierwszy dzień...Chorwacji w UE, dzieci na wakacjach i mojej pracy w Citi

2 komentarzy
1 lipca Chorwacja oficjalnie wstąpiła do Uni Europejskiej. Gratulacje!

1 lipca moja córcia Iwetka pierwszy raz poleciała samolotem, sama, do Portugalii (w której nawet ja jeszcze nie byłem!)

1 lipca mój (starszy) syn Patryk wyjechał na wakacje.

1 lipca mój (młodszy) syn Maksym miał zaplanowaną pierwszą wizytę w żłobku (ale plany się "odplanowały"). Następnym razem.

I w końcu, 1 lipca zacząłem pierwszy dzień u nowego pracodawcy Citibank International PLC (Publiczna Spółka Akcyjna) Oddział w Polsce jako menedżer ds. rozwoju aplikacji.

Za Wikipedią:

"Menedżerowie jako przedstawiciele kadry zarządzającej cechują się poczuciem odpowiedzialności, strategicznego myślenia i przewidywania."

Mniemam, że od dzisiaj jestem odpowiedzialny i mam poczucie myślenia i przewidywania (niepotrzebne skreślić).

A poważnie, zapominając na moment o tytułach, to przyjdzie mi pracować w bardzo interesującym zespole, z osobami, które znałem z wcześniejszych aktywności około-Scala-owych i które zawsze imponowały mi swoją wiedzą. Teraz jestem częścią tego zespołu! Gratulacje Jacku!

Niewiele się wydarzyło tego pierwszego dnia w nowej pracy - sesja wprowadzająca w tajniki pracy, aby podsumować BHP i podpisaniem umowy.

Jutro kolejny dzień wdrażania zgodnie z wytycznymi działu kadr. W środę powinienem pojawić się już w biurze na Goleszowskiej. Pora zapoznać się z komunikacją miejską, bo dojazd na drugi koniec Warszawy będzie mnie kosztował sporo czasu i przynajmniej 2 przesiadki. Będzie jeszcze więcej czasu na czytanie i słuchanie!

I zadanko w Scali na koniec - co robi poniższy jednolinijkowiec?
s filter (_ != ' ')
Można krócej? Ładniej?

27 czerwca 2013

Pauzowanie projektowe i przedwakacyjne zmiany służbowe = opuszczam IBM

10 komentarzy
Minęło parę już dni od ostatniego wpisu z cyklu "moje pierwsze kroki przy tworzeniu aplikacji pisanej w Scali, której daję czas od pomysłu do realizacji najwyżej 1 miesiąc." I nic się nie pojawiło od owych kilku dni! Projekt zamarł...niestety, bo obowiązków sporo i to rodzinnych głównie!

Najpierw zaczęło się od wyjazdu weekendowego, podczas którego napracowałem się bardzo. "Upodliłem" się pracując fizycznie i kiedy dopadłem już kompa, zaraz zatwittowałem o moim powrocie.

Powrót nie trwał jednak długo :(

We wtorek żonka obchodziła urodziny, więc znowu przytrafiło mi się odciąć od sieci. Dosłownie. Nie miałem ze sobą komputera, a w dodatku padła mi komórka, więc sieci nie widziałem przez dobre 2 dni! Odświeżające. Najbardziej zachwycona była moja żoncia (której nota bene też padła komórka!)

I tak dobrnąłem do czwartku, w którym również nie znalazłem wiele czasu na boje projektowe przy taskassinie. Widziałem komentarz Radka dotyczący stworzenia cechy (trait), który podzielam, ale niestety i dzisiaj przyszło mi zająć się innymi sprawami.

Z dniem jutrzejszym, 30 czerwca, kończę pracę w IBM.

Postanowiłem podreperować moją znajomość branży finansowej i od 1 lipca (poniedziałek) przechodzę do Citi na stanowisko (użyję mojego tłumaczenia) szefa technicznego zespołu programistycznego (Credit Front Office - Warsaw Team Lead).

Będzie Scala, Clojure i problemy analizy dużej ilości danych finansowych. Będą też ludzie, których znam osobiście i z którymi zawsze marzyłem usiąść przy jednym kompie, aby spędzić kilka dłuższych chwil, chociażby na dyskusji o niczym. Teraz dostaję to na tacy! Raportuję do kierowników w Londynie i Nowym Jorku, co podtrzymuje mój entuzjazm doskonalenia języka angielskiego. Słowem wszystko, co dusza moja pragnęła bardzo. Dodać należy również, że zawsze zastanawiało mnie, jak to jest być po drugiej stronie flanki - poza sektorem IT. Teraz będzie okazja zmaterializować marzenia.

Nie zostawiam WebSphere i rozwiązań IBM, bo uważam je za stosunkowo dobre, aby poświęcać im swój czas. Przyjdzie moment, w którym rozważę "kapitalizację" swojej wiedzy, ale na razie odkładam to na półkę z pomysłami. To z pewnością będzie ciekawie doświadczenie móc obserwować rozwój rynku WebSphere nie będąc już IBMerem.

Mówi się, że do końca roku zespół programistyczny ma liczyć 40 osób i potrzeba osób do programowania, jak i prowadzenia zespołów programistów od strony technicznej. Jeśli uważasz, że to robota dla Ciebie, napisz. Skontaktuję Cię z moim szefem, który zawiaduje procesem rekrutacji. To będzie niezwykła grupa pod względem osób i stosowanych technologii. Wprost robota marzenie (technicznie).

Dla zainteresowanych wycinki z opisu stanowisk:

"We are seeking highly motivated candidates to join on the ground floor of building our Framework Development Team in Warsaw, Poland.

The candidates will have responsibility for leading a team focused on development of core technology used by Citi’s Credit Trading business.

The Credit Front Office Development Team supports Credit Trading businesses in London, New York, and Asia.

Global Credit Technology is establishing a development center in Warsaw to work on core technology for our Credit Trading Businesses. This work will provide critical components for our new global strategy.

Thorough familiarity with algorithms & data structures.

Exposure to any of the following technologies is a bonus: WPF/XAML, Clojure, Scala, Hadoop, Apache Camel, HBase"

27 maja 2013

Jak to czytanie książek zbliża - Atomic Scala w akcji

0 komentarzy
Podczas tegorocznej konferencji GeeCON w Krakowie Adrian wręczył mi książkę "Atomic Scala" Bruce Eckel i Dianne Marsh. Książka w zasadzie bardzo lekka merytorycznie i wprowadza w temat programowania w Scali przykładami. Początkowo rzadko, aby dopiero przy ostatnich atomach (termin autorów na poszczególne rozdziały) znaleźć w niej odrobinę "cięższej" wiedzy. Na pewno można się przy niej pozytywnie rozerwać.

W trakcie lotu do Stambułu, Turcja, towarzyszyła mi dzielnie. Zostało mi jeszcze kilka stron do przeczytania, więc można oczekiwać recenzji niebawem, co jednak od dzisiaj będzie kojarzyło mi się z nią nierozerwalnie, to spotkanie z...szefem zespołu, który rozważa wejście w Scalę i Play Framework - Arkadiuszem Biczem.


Jeszcze przed startem, kiedy zobaczył moją książkę, zapytał o moje zainteresowanie Scalą, aby po kilku kolejnych, rozpoznać we mnie tego "oszołoma" z bloga (którego masz przyjemność czytać). To było niewątpliwie najmilsze spotkanie w ostatnich kilku miesiącach, bo nie tylko dzielimy ze sobą podobne pasje, ale pracujemy i mieszkamy w tym samym mieście - Warszawie.

Jak to czytanie książek zbliża. I kto by pomyślał, że do momentu spotkania trochę utyskiwałem w duszy, że zapomniałem zamienić miejsca. Warto od czasu do czasu pozwolić sobie na chwilę zapomnienia, bo przypadek może sprowokować miłe zdarzenia.

Powodzenia Arek w Autonomii Kurdyjskiej! Do zobaczenia!

13 grudnia 2012

Pytań o prace inżynierską końca nie widać

7 komentarzy
To już nie pierwszy raz, kiedy odpowiadam na pytanie w stylu "Mam pytanie odnośnie tematu pracy inżynierskiej, może Pan pomógłby nakierować na wybrany temat z jakieś dziedziny Javy bądź czegoś nowego. Aplikacja biznesowa, rozbudowana, połączona z jakimś API bądź coś zupełnie innego. Liczę na odpowiedź."

I co ja mam takiemu biedakowi odpowiedzieć?! Za mało jestem wyrazisty w swojej znajomości Javy i samemu daleko mi do określenia swoich zainteresowań poznawczych.

Z jednej strony języki programowania, przede wszystkim funkcyjne, w których miejsce znajdują Clojure, Scala i F#, ale nie stronię od artykułów i ciekawych wskazówek ze strony Dart, JRuby, Jython i JavaScript. Nie bez echa pozostają wydarzenia wokół Java 8. Choćby w samych językach programowania sporo tego.

Do tego należałoby dorzucić Java EE, serwery aplikacyjne (Apache TomEE i WebSphere Liberty Profile), specyfikacje OSGi, Enterprise OSGi i SCA.

Później jeszcze produkty typu IBM Worklight czy IBM BPM, aby nie zapomnieć o wciąż nękającym mnie o więcej czasu platformie Android.

Jak można przeczytać, ja powinienem być ostatnią osobą, z którą należałoby się wiązać, albo przynajmniej pytać o sugestie, bo sam jestem w kropce, za co się zabrać (!) Robię tym samym wszystko i nic!

Skończyło się na takiej odpowiedzi, bo właśnie wczoraj zgłosiłem ten temat do programu w ramach IBM:

Proponuję Enterprise OSGi jako temat baaardzo ciekawy a wciąż niedoceniany. Zacząłbym od przejrzenia/przeczytania specyfikacji 4.2 [1] i zabrania się za dłubanie przykładowych aplikacji, które będą uruchamiane na WebSphere 8.5.5 Alpha Liberty Profile [2], które z kolei trafią do githuba [3]. Tego jak widzę nigdy za wiele, a ludziska wykazują zainteresowanie.

Sam nad tym obecnie siedzę, aby przygotować zestaw materiałów "reklamujących", więc moglibyśmy połączyć siły.

[1] http://www.osgi.org/Download/Release4V42
[2] https://www.ibm.com/developerworks/mydeveloperworks/blogs/wasdev/entry/download_wlp_v85next_alpha?lang=en
[3] https://github.com/

Powodzenia życzę wszystkim borykającym się z samookreśleniem i wyborem tematu prac. Nic bardziej mylnego myśląc, że różnorodność pomaga. Poszedłbym nawet dalej z moimi tezami. Zaczynam twierdzić, że wiedza wcale nie uskrzydla, a wręcz odwrotnie - ogranicza w myśleniu, kierując je na już przetarte szlaki. Tego zazdroszczę mojemu najmłodszemu synowi - otwartości umysłu, braku ograniczeń i pasji odkrywania. Straciłem to drugie, a zaczyna się koniec pierwszego. Życzę innych doznań w 2013!

Jako pomysł jakiejkolwiek pracy sugeruję wyłączyć wszystko wokół i zastanowić się, czego samemu chciałoby się użyć. Niechby to już istniało i niechby to był Facebook, nie ważne. Właśnie za to zabrałbym się w pierwszym rzucie i zaczął swoje poczynania rozwojowe. Po drodze pojawi się wiele ciekawych tematów-odprysków.

27 listopada 2011

Łącząc przyjemności - o TDD i spacerze "nagraniowym" z Maksymem

2 komentarzy
Warto czasami przystanąć, zastanowić się i po prostu pomyśleć bez jakichkolwiek zewnętrznych "przeszkadzaczy". Doświadczyłem błogosławieństwa takich chwil niedawno dwukrotnie i nie mogłem uwierzyć, jak niewiele trzeba, aby mieć ich więcej.

Podczas konferencji JDD w Krakowie (czytaj Wrażenia pokonferencyjne - zacznijmy od JDD w Krakowie) miałem przyjemność uczestniczyć w sesji "TDD Coding Dojo" z Krzyśkiem Jelskim i Marcinem Zajączkowskim. Kiedy wracałem do domu pociągiem, a może jeszcze wcześniej, w taksówce, zacząłem zastanawiać się nad słowami Jakuba Nabrdalika, który kiedyś stanowczym tonem stwierdził, że nie da się robić TDD z już gotową aplikacją. Miałem wtedy wrażenie, że Kuba jest tak etycznie upośledzony przez TDD, że jedyną, słuszną drogą dla TDD jest zacząć od testów. Ja jednak bardzo nalegałem na możliwość dopisywania testów do gotowej aplikacji (projekt Apache OpenEJB), aby stworzyć siatkę bezpieczeństwa dla późniejszych prac przy zmianie kodu. Nie pomagał nawet mój wrodzony wdzięk. Po prostu, Kuba kończył taki pomysł stanowczym: "To nie będzie TDD" i tyle mi było z nim rozmawiać. Oj, jaki ja byłem na niego zły za takie potraktowanie. Nie żebym czuł jakąś zadrę do niego za to, ale po prostu nie mogłem zrozumieć, dlaczego to nie przejdzie.

I właśnie podczas powrotu do Warszawy, po sesji z Krzyśkiem i Marcinem, olśniło mnie! Wydaje mi się, że zrozumiałem ideę TDD. Wreszcie połączyłem teorię z praktyką i jakkolwiek nie było tego drugiego wiele, to wystarczyło, abym usnął tezę, która wydaje się zgodna z myśleniem Kuby (!) Nie zapomnę tej chwili, kiedy prawie wykrzyknąłem "Eureka!"

TDD stosujemy jako "zapalnik" zmian w aplikacji. Pojawia się test, nie przechodzi (czerwono), piszemy minimalistyczną implementację, taką, aby jedynie pozwoliła przejść testowi (pojawia się zielone), refaktoring i tak w kółko. Kiedy zastanowić się nad kolejnością zmian w aplikacji - najpierw test, później minimalnistyczna implementacja i tak, aż do znudzenia, to łatwo zrozumieć, że aplikacja ma tyle, aby jedynie/aż przeszły testy. Nic więcej. Jeśli jest więcej, to prawdopodobnie możemy liczyć się z miejscami niepokrytymi testami. Całkiem zrozumiałe, jeśli para programistów jest więcej niż początkująca w temacie programowania i TDD w ogólności.

Weźmy teraz działającą aplikację. Skoro działa, to każdy kawałek kodu, który mógłby wyglądać na potencjalny błąd...NIE jest błędem! Na pewno nie jest nim jeszcze. Gdyby już był, to pojawiłaby się poprawka i...po błędzie. I teraz pora na moje olśnienie - wręcz niemożliwym jest pisanie testów, które objęłyby wszystkie możliwe przypadki do przetestowania dla działającej aplikacji. Słyszałem o narzędziach automatyzujących, które prześwietlając kod wykrywają "zakręty" na if'ach i temu podobnych konstrukcji "rozgałęziających", ale, właśnie, to są automaty. Gdyby pisać je ręcznie, to nigdy nie wiadomo, czy jest ich wystarczająco wiele, aby powiedzieć, że jest ich wystarczająco wiele. Właśnie to odwrócenie zależności między testami a aplikacją jest problemem. Nie można mówić o odwróceniu zależności w przypadku TDD, gdzie zależnością aplikacji są testy. A może na odwrót? Tak czy inaczej, jeśli zakładamy, że dla testu sprawdzającego, czy zwrócono liczbę 5 piszemy kod, który po prostu zwraca 5, to nie ma szansy na pomyłkę. Kod może być dalej pod kątem zaawansowania funkcjonalnego, ale należałoby to odznaczyć jako...nadgorliwość. Oczekujemy 5, to nie ma potrzeby wywoływać usługi RESTowej, która zwraca 5, bo wystarczy zwrócić 5. Proste i oczywiste.

Czy moje zrozumienie TDD jest właściwe? Czy takiego myślenia oczekuje się od praktyków TDD? Chętnie poznam Twoją opinię. W komentarzach jest duuuużo miejsca na dywagacje.

Kolejnym momentem, w którym doświadczyłem momentu olśnienia był dzisiejszy spacer z Maksymem. Kolejny samotny spacer przez 1,5-2h to nie przelewki. Łazisz po utartych ścieżkach Lasu Kabackiego i tak idziesz, i idziesz, i idziesz. Można kota dostać.

Z drugiej strony, kilka dni temu odznaczyłem sobie kilka nagrań z konferencji do odsłuchania i wcale mi się nie uśmiechało odsłuchiwanie ich podczas siedzenia w domu. Każdorazowo, kiedy próbowałem usiąść nad nimi w domu, zawsze pojawiało się zniecierpliwienie i w ogóle ogólna niechęć do ślęczenia przed kompem i gapienia się w monitor z założonymi rękoma. Nuda. Nosiło mnie moje wewnętrzne ADHD. 30 minut jeszcze dam radę słuchać, ale więcej?! Nie ma mowy! No i jeszcze mógłbym nie usłyszeć Maksyma, kiedy się obudzi i daje znać o tym wszem i wobec!

I tak dzisiaj przypomniałem sobie o tych nagraniach i idąc Lasem Kabackim włączyłem Language Panel o językach programowania. Byłem ciekaw, co też tam Ci myśliciele mówią o językach. Skoro i tak miałem ponad godzinę czasu na spacer, to przecież mogłem go spędzić łącząć przyjemne z pożytecznym.

I tak ze słuchawkami na uszach (głos) i smartfonem w nogach Maksyma (wizja) zeszło mi przyjemnie 40 minut. Las gwarantował spokój, brak zewnętrznych przeszkadzaczy i wiatru, który szalejąc na osiedlu tutaj zanikł kompletnie. Przyjemna sprawa.

Początkowo planowałem godzinny spacer, ale kiedy minęło mi 40 minut, stwierdziłem, że pozwolę sobie na dłuższy spacer i...ponad godzinne nagranie Clojure and the Web. Nie polecam tego nagrania, ale dla napaleńców może być ciekawym podsumowaniem zalet Clojure (przez pierwsze 20 minut) oraz przegląd szkieletów webowych w Clojure z praktycznym przeglądem Ring w drugiej części.

Po 2,5 godzinach wróciłem do domu wyjątkowo zadowolony (!) Maksym przez całą drogę spał smacznie, ja przejrzałem 2 nagrania, co dało nam obu sporą dawkę świeżego (?) powietrza, a reszta rodzinki odetchnęła na jakiś czas od Maksyma. Już nie mogę doczekać się kolejnego spaceru! Co proponujecie do obejrzenia? Może coś w tematyce TDD? Zastanawiam się, czy pomysł odsłuchiwania na mrozie wypali. Ale w końcu i w Norwegii używają Galaxy S2, a tam ciągle zimno.

12 października 2011

Focus & deliver - centrum rozwojowe Google w Warszawie otwarte

8 komentarzy
Kilka dni temu otrzymałem od Google (bez nazwisk tym razem) zaproszenie na "a small, informal gathering, during which you will be able to find out more about the office and the projects the engineers will be working on", które odbyło się właśnie dzisiaj na 10 piętrze Warsaw Financial Centre (ul. E. Plater 53 w Warszawie). Przy mojej obecnej sytuacji rodzinnej do końca nie byłem pewien, czy będę mógł w nim uczestniczyć i, z klauzulą potencjalnej nieobecności, przyjąłem zaproszenie.

Najciekawsze w tym było to, że "Apart from Kacper, you will hear from two speakers from Mountain View: Joshua Bloch and Walfredo Cirne." Joshua Bloch w Warszawie?! Nie mogłem przegapić tego spotkania. Nie byłem specjalnie napalony na możliwość zrobienia sobie z nim zdjęcia, zebrania podpisu, czy przyjacielskiego uścisku dłoni, ale możliwość spotkania go w nowootwieranym biurze inżynierskim Google nęciło. No i to indywidualne zaproszenie podkręciło moją ciekawość, aby zobaczyć, co też Google z Joshua przygotowali dla mas...miałem napisać...nas. Najbardziej zainteresowany byłem poznaniem ludzi, którzy będą tworzyli Google w Warszawie.

Jakież było moje zdumienie, kiedy na 10 piętrze spotkałem znajome twarze z wydziału MIM UW - pani doktor, pan doktor, o i pan profesor (miało być bez nazwisk i niech tak pozostanie). Było też kilka znajomych twarzy (z widzenia, nie z bezpośredniego kontaktu) z rynku. Pachniało jednak bardziej akademickim spotkaniem.

Spotkanie oficjalnie zaczęło się około kwadrans po 17:00. Zaczął Kacper - "the engineering director for the new office" Stonowany głos, przyjemny angielski, więc miło się go słuchało. Och gdybym tylko wiedział, jak zaraz po nim "Walfredo will talk about Cluster Management at Google." Kacper przedstawił cele nowego zespołu rozwojowego Google, z czego najbardziej utkwiło mi zdanie, że "they want to contribute and contributors" (czy jakoś podobnie). Ogólnie, zespół Google chciałby stać się częścią społeczności technicznej w Warszawie, tak by społeczność mogła skorzystać na tym, a i również sam Google. Obopólna praca na rzecz rozwoju obu stron. Pomysł podoba mi się, szczególnie, że ostatnimi czasy więcej w Warszawie grup użytkowników niż spotykających się, tj. jest komu organizować, ale nie ma komu przychodzić. Szczęśliwie nie dotyczy to bardzo prężnej grupy Warszawa JUG, która, jak mogłem dzisiaj przekonać się, liczy obecnie 542 użytkowników (!) Kawał światka warszawskiego. I jeszcze jedno zdanie Kacpra utkwiło mi w pamięci: "Focus & deliver". Ostatnio wiele rozważam nt. planowania, a później wypełniania postanowień i to zdanie wstrzeliło się w sam środek mojego dywagowania, ile jest we mnie pierwszego, a ile drugiego. Powiedzmy, że pracuję nad obiema rzeczami.

O Walfredo nie będę wspominał. Dałem radę, ale nie było warto. Nuda.

Ale moment, to zasługuje na uwagę. Już na sam koniec prezentacji, Walfredo został zapytany o udostępnianie wyników dotychczasowych osiągnięć w ramach dokumentów akademickich czy podobnie. I tu padło pamiętne: "We're too busy to write papers". Gość całkowicie powalił moje postrzeganie na wielkość Google jako firmy, w której i dla której dzielenie się wiedzą i inspirowanie do takiej aktywności jest w samym sercu zainteresowania. A tu taki klaps. Oniemiałem. Jakby na dokładkę, inny Googlers z zespołu Walfredo, zaproponował nawet tezę, że to nie jest skończone, więc nie pora na tego typu aktywności. To mną wstrznąsnęło. Z wielkiego Google zrobił się...Google. Czas magii firmy, która poświęca się dla społeczności prysł i pewnie trudno będzie się mi zebrać.

Mimo, że Walfredo przedstawiał tematykę Cluster management at Google z projektem Omega, które nie interesowało mnie całkowicie, to wychwyciłem ciekawe zdanie, z którym zgadzam się w zupełności "Not how but what - declare not implement - goals not ways". Jednak ja zastosowałbym to zdanie do programowania, chociażby ostatnich moich lekcji z Androidem. Programowanie na Androida z widokami opisanymi w XML, albo wszechobecne programowanie z adnotacjami czy funkcyjne jest właśnie tego przykładem. Jest to swego rodzaju realizacja zasady odwrócenia odpowiedzialności - typowy IoC. We wszystkich, wymagamy czegoś od środowiska i deklarujemy wymagania, które mogą być realizowane na różne sposoby, poniżej naszego poziomu percepcji i w ogóle zainteresowania. Wskazywanie na tego typu podejście było później również przedstawione przez Joshua w jego prezentacji "Performance Anxiety - Performance Analysis in the New Millennium", w którym wspomniał, aby "use high-level declarative construct", bo znajomość detali może zabić swoją złożonością i czasochłonnością.

A skoro o nim. Po przerwie na scenę wkroczył Joshua. Trudno mówić o scenie, bo siedzieliśmy w otwartym pomieszczeniu, zaraz przy wejściu, co niektórzy mogliby wręcz określić jako korytarz. Sceneria mi nie przeszkadzała i delektowałem się dwoma projektorami, które wyraźnie wyświetlały slajdy, a później i sam kod źródłowy w Aquamacsie (!) Sceny nie było, chyba, że podłogę można nią nazwać.

Do zapamiętania: "We can't be perfect", więc pewien poziom niedeterminizmu w JVM, systemu operacyjnego, procesora jest dozwolony i dobrze, abyśmy zdawali sobie z tego sprawę. Ja nie zdawałem i wyszedłem bogatszy. Prezentacja była bardzo żywiołowa i dynamiczna. Czasami miałem wrażenie, że to wyginanie się Joshua zmęczy go, ale, kiedy o 19:45 skończyliśmy część prezentacji i przeszliśmy delektować się przekąskami, nie zauważyłem zmęczenia, ani u niego, ani u słuchających. Obserwowałem Joshua pod kątem jego technik prezenterskich i kilka zamierzam wdrożyć na sobotniej warsjawie, kiedy to przedstawię "Java EE 6 Web Profile z Apache TomEE". Wtedy zamierzam po raz pierwszy zastosować kacprowe "Focus & deliver"!

Tej części bałem się najbardziej. Po części prezentacyjnej, przeszliśmy do przekąsek i napoi (w tym i piwa!) Wiele uczestników znała się, więc sądziłem, że powstaną grupki bardzo hermetyczne i rozmowy będą w zamkniętych gronach. Czy to miejsce, czy jedzenie, czy po prostu uczestnicy byli powodem, ale tak się nie stało. Jedzenie było smaczne, towarzystwo otwarte i rozgadane, więc pożegnałem się z uczestnikami dopiero około 21:00. Spotkanie bardzo przyjemne i z niecierpliwością czekam na kolejne.

A jeśli o kolejnych spotkaniach, to przypominam, że w najbliższą sobotę, 15 października odbędzie się konferencja warsjawa. Wszyscy są mile widziani, a na moją prezentację Apache TomEE zachęcam ze zdwojoną, co tam, strojonąpotrójną siłą.

Do soboty pozostało kilka dni, a już jutro spotkanie z Joshua Bloch w ramach "Google Tech Talks". Będzie Kacper, Joshua i Walfredo. Będzie tym samym możliwość skonfrontowania moich odczuć na prezentowane tematy. Z tego, co mi powiedziano na wydarzenie zapisało się 500 osób, co o tyle było dla mnie zdumiewające, że nic a nic nie wiedziałem o nim. Wciąż nie mogę nadziwić się, że przy aktywnej Warszawa JUG, śledzeniu twittera, blogów i w ogóle nasłuchiwaniu wszystkiego, co związane jest z Javą, nie udało mi się wychwycić tego wydarzenia. Skoro ja już o tym wiem, Ty również. Rejestracja dostępna jest na stronie Inżynierowie z Warszawy, spotkajmy się! Podobno miejsce nie wytrzyma takiego nawału zainteresowanych, więc rozważ dwa, a nawet trzy razy, zanim zapiszesz się na spotkanie z Goooooglers. Życzę miłego spotkania i zachęcam do aktywnego udziału.

03 października 2011

Maksym jest już z nami!

17 komentarzy
Dzisiaj o godzinie 17:24 w szpitalu na Madalińskiego w Warszawie urodził się mój syn Maksym. Poród przebiegł wyjątkowo sprawnie tak, że ledwo zdążyliśmy na porodówkę. Wszystkim mamom gratuluję, a mojej Agatce szczególnie.


Długość: 60 cm, waga: 3775 g i z każdą minutą coooooraz większy.

p.s. Z trójką dzieciaków łatwiej będzie przygotowywać dema aplikacji, bo i imion więcej do listy rozwijalnej czy pola wyboru :)

12 września 2011

Pakiet certyfikacyjny na specjalistę IT wysłany

0 komentarzy
Pracuję w IBM od ponad 5 lat i jak to w dużej organizacji (zaniecham używania słowa "korporacja") wdrożono system nadawania odznaczeń za zasługi, który wymaga, aby wszelakiej maści zaangażowanie zostało spisane w postaci pakietu certyfikacyjnego. W ten sposób ranga składającego wzrasta (i czasami wręcz i jego portfel!)

Zasobność i wymagania pakietu zależą od wielu czynników, ale przede wszystkim zależą od ścieżki kariery, którą wybierzemy, np. techniczny vs architekt vs sprzedawca vs itp. oraz poziomu "wtajemniczenia". Różne ścieżki to różne cechy, którymi powinien mienić się kandydat.

Magiczne słowo "pakiet certyfikacyjny" sprowadza się do dokumentu, w którym spisujemy swoje osiągnięcia biznesowe, techniczne i inne. Słowem, wszystko to, co sprawia, że klienci czują się w projekcie potrzebni i właściwie zaangażowani. Kiedy spisujemy swoje doświadczenia w postaci bardzo bogatego w słowa wyrażające zachwyt danego osiągnięcia, delikwent staje się bardziej świadomy, co zrobił, co mógł zrobić, ale też, co należy zmienić w swoim postępowaniu. Jak teraz o tym piszę, przypomina swego rodzaju spowiedź, w którym kajamy się, że zrobiliśmy tak wiele, albo tak niewiele, ale na pewno obiecujemy poprawę. Bardzo pouczające doświadczenie (nie wnikając w jego prawdziwe motywy).

I jak to przy pracy literackiej bywa, trzeba to napisać. A to nietrywialna rzecz. Jest narzędzie, które wspiera autora, ale wkład jesteśmy zobowiązani stworzyć samodzielnie. W końcu to nasze życie opisujemy. Jeśli przechodziłeś/-aś przez męki pisemnej matury z polskiego, pracy inżynierskiej czy pracy magisterskiej, od razu wiadomo, że to może nie być lekkie zadanie, a kiedy należy opisać swoje uczynki, jest jeszcze trudniej. Wszystkie projekty wydają się takie trywialne i w ogóle jakieś takie bez naszego zaangażowania. Jakby się same robiły, a my tylko, gdzieś tam w zaciszu domowego kominka dłubaliśmy przy takim niezbyt nadzwyczajnym zadaniu, o którym pewnie sam jegomość klient nie raczy pamiętać już dzisiaj. Normalnie porażka!

Dzisiaj jednak po wielu porażkach mojego życia udało mi się poczynić właściwe decyzje i...zebrać się w sobie, aby dokończyć składanie mojego pakietu certyfikacyjnego. Nawet zakupiony dzisiaj Samsung Galaxy S II nie zdołał mi popsuć nastroju, aby dokończyć dzieło (!)


Cała literatura moich osiągnięć zawiera około 55 stron i zapewniam, że nie wynika z mojego bogactwa projektowego, ale czymś trzeba podreperować swoje doświadczenie, więc pozostaje bogactwo słowne, zwane powszechnie słowolejstwem. Limit 3000 słów na sekcję wykorzystany!

Dokument tworzyłem przez ostatnie kilka tygodni, z tymi dalszymi z mniejszym zaangażowaniem, w przeciwieństwie do tych bliższych, w których to już wręcz całe dnie spędzałem pisząc i pisząc, i pisząc, i jeszcze raz pisząc. Nuda. Ale jak to ktoś mądry powiedział kiedyś "I nuda może być twórcza". I "Jak się powiedziało 'a', to należy powiedzieć i 'b'". Termin upływał właśnie dzisiaj i z każdym dniem widziałbym go z przyjemnością dalej, ale jego nieuchronność okazała się zbawienna. Jak ja się cieszę, że mam to za sobą!

Od tej pory zdejmuję z siebie kolejne karby konieczności spisywania swoich doświadczeń projektowych w IBM i czekam cierpliwie na werdykt jury certyfikacyjnego, czy pozwolić mi na miano Certified IT Specialist, czy nie. Oby się nie pomylili w swojej decyzji.

Czy warto było? Uważam, że każda aktywność, która pozwala na podsumowanie pewnego okresu w naszym życiu jest warta zachodu. Pewnie mógłbym spędzić ten czas na innych aktywnościach, pewnie mogłyby być równie bogate w doświadczenia, ale skoro uczestniczę w grze zatytułowanej "korporacja", pewnym regułom muszę się poddać. W końcu, czy to taki problem opisać, co się takiego ciekawego robiło w projektach i gdzie możnaby szukać usprawnień? Przecież robimy to przy każdej nadarzającej się okazji z naszym CV, nieprawdaż?

Od dzisiaj, w bazce lotusowej widnieje moje złożenie pakietu i obym nie musiał już wracać do tego tematu. Było i się szczęśliwie dobrze skończyło - dokument wysłany. Czego wszystkim korporacyjnym mróweczkom życzę!


29 sierpnia 2011

Co można wypożyczyć do naszej profesji?

1 komentarzy
Ostatnia wizyta w wypożyczalni filmów video na Ursynowie (nazwę wypożyczalni zachowam do użytku własnego) zakończyła się ciekawymi doświadczeniami, które starałem się, wspólnie z żoną, przekuć w coś namacalnego i zaprząc do własnego warsztatu informatycznego, ale mam wrażenie, że wciąż bezskutecznie. Pewnie zastanawia Cię, cóż takiego interesującego mogłem doświadczyć w wypożyczalni, co zasługuje na wpis na moim blogu, a dodatkowo przyswojenie?! Wyprzedzając fakty, napiszę, że nie jest to nic innego jak zestaw usług, które wydają mi się, aż przesadnie komplementarne. Marzy mi się takie obsłużenie klienta, aby moje usługi sprowokowały go do takiego myślenia. Ale do rzeczy...

Uwielbiam obserwować innych. Lubię przyglądać się innym w pracy. Poza nią również. Nie musi to być związane z informatyką, ale jak jest, tym lepiej. Mam wrażenie, że coraz więcej osób spędza wolny czas coś konsumując, a oglądanie filmów, czy to w domu, czy w kinie, wręcz nieodparcie wiąże się z jedzeniem, żeby nie napisać z wp^H^H^Hkonsumowaniem znacznych ilości jedzenia. Robimy to z taką lubością, że odejmuje mi to smak i rozkoszuję się w obserowaniu jedzących (niezbyt to bezpieczne zajęcie, szczególnie jeśli koleś to drab dwa razy większy od obserwującego, tj. mnie).

Lubimy jeść i oglądać filmy, więc kiedy idziemy do wypożyczalni, to już nie tylko po film, ale i pożądną porcję jedzenia. Stąd też w wypożyczalni mamy możliwość zakupu chipsów różnej maści, paluszków, cola, wszystkiego, co da się jeść i kojarzy się z oglądaniem (jako czynnością wymagającą siedzenia i skupienia). Zepsuliśmy pojęcie oglądania do tego stopnia, że do kina idzie się przede wszystkim na pożądną porcję popcornu i coli, a kiedy uzupełnione o dobry film, tym lepiej.

Wracając do wypożyczalni, skoro już wypożyczamy film, to oczekujemy również strawy i trunków. Wszystko jest na wyciągnięcie ręki. I chwała za to wypożyczalni, że o tym pomyślała. Na prawdę byłem zachwycony samym podejściem do klienta, bynajmniej niekoniecznie samym towarem. Nie popieram samego etycznego utrwalania tego typu spędzania czasu podczas oglądania, ale samo wstrzelenie się w gusta jest przecudne (jednakże teraz, kiedy o tym piszę, jakaś moralna dygresja nie daje mi spokoju). Nieważne. Ważne, że można zaopatrzyć się w cały zestaw telemaniaka.

Co mnie jednak zaskoczyło, to, że przy komplecie "materiałów żywieniowo-filmowych", zabrakło takiej przyzwoitej, dopasowanej do "wystroju wnętrz", wiedzy merytorycznej u sprzedawców. Jakby do niezwykle wysokowyposażonego warsztatu samochodowego wstawić osobę do tej pory zajmującą się naprawą...telewizorów. Niby coś tam się zna na naprawie, ale nie tego się oczekuje. I właśnie tak było w tej wypożyczalni. Na półkach wszystko, czego dusza może zapragnąć, ale obsługa do bani, zero wiedzy na temat oferowanych filmów, czy wręcz ochoty dowiedzenia się, sięgnięcia po informacje na ich temat. Oczekiwałbym chociaż jakiegoś zestawienia popularności danej pozycji względem innej, czy podobnie. Czegokolwiek, co pomoże mi w podjęciu decyzji, poza..."Hmmm, niech no ja zajrzę na drugą stronę, aby przeczytać streszczenie". Taka klapa!

I tak zachwycając się na samym pomysłem wyposażenia i jego kompletności, trochę przy tym narzekając na obsługę, zastanawiałem się, jak możnaby użyć tego spostrzeżenia w moim fachu w branży informatycznej. Jak mógłbym zaoferować komplet usług klientowi, którego przecież zwykle znam, tak aby zaoferować mu wszystko, czego mógłby sobie zażyczyć, nawet jeśli tego początkowo nie chce? Nie chodzi mi o wyłudzenie od niego pieniędzy, ale na zaoferowaniu mu kompletu, a nie rozwiązania połowicznego. Zastanawiałem się, czy można podciągnąć pod to testy jednostkowe, które służą programiście, aby chociażby zagwarantować bezpieczeństwo późniejszych zmian, czego nie dostrzega klient? Jest to dosyć ukryte utrzymanie jakości produktu końcowego, więc to nie to. Kiedy założyć, że jestem wyłącznie programistą lub architektem, co należałoby oferować, aby klient poczuł się jak ja w tej wypożyczalni? Przychodzi po film, a wychodzi z całą siatą "prowiantu", wciąż zadowolony z podjętej decyzji zakupowej? Da się? A może to już zakrawa o manipulację i lepiej nie wdawać się w te gierki? Ciekawym Twojego zdania, bo mi nie daje to spokoju od kilku dni i cieszę się, że w końcu mogłem to z siebie wyrzucić.

07 czerwca 2011

01 marca 2011

Narzędzia pomocnicze, mapy myśli i Darmowy kurs UMLa

4 komentarzy
Chyba dałem się w końcu przekonać do stosowania owych map myśli i do mojego arsenału narzędziowego trafiło kolejne narzędzie XMind.


Kiedy pierwszy raz usłyszałem o tym podejściu do porządkowywania swoich obszarów działalności, miałem bardzo sceptyczne nastawienie. Zresztą do każdego rodzaju podejść miałem, co nie miało wielkiego związku z Javą i okolicami. Z każdym jednak dniem, kiedy technologii przybywało, którymi chciałbym, albo musiałem się zająć, coś musiałem zrobić, aby się nie pogubić.

Wtedy to kupiłem Things na MacOS X. Sprawdza się, aczkolwiek brakuje mi wytrwałości, aby tam zaglądać i lista zadań rośnie. W końcu samo narzędzie to nie wszystko i należałoby jeszcze z nich właściwie (= sumiennie) korzystać. Co mnie jednak irytuje, to jedynie dwupoziomowy podział zadań (potrzebowałem nieograniczonego zagłębiania zadań) i brak zarządzania per dzień/godzina, czyli wrzucam coś na dany dzień z planowanym czasem, ile może mi to potencjalnie zająć, a narzędzie kontroluje, czy faktycznie mogę. To nie jest zadanie dla Things.

Później trafiłem na kolejne narzędzie, które przydało mi się już niejednokrotnie, chociażby podczas warsztatów w Tarnowie - Apimac Timer (patrz relacja w Po wykładzie na PWSZ w Tarnowie). Narządko niewielkie i bardzo specjalizowane, które pozwala utrzymać ilość czasu na dane zadanie i w ten sposób mogę po 45 minutach skończyć pracę, przejść się, rozprostować kości, aby po przerwie znowu zasiąść przed kompem. Bajka. Niby niewiele, a jak pomaga utrzymać tempo, bez przesadnego przemęczenia.

Podczas darmowego kursu UML Grześka Kukawskiego doświadczyłem kolejnego narzędzia - XMind. Tym razem jednak, przy okazji omawiania UML, zobaczyłem, jak Grzesiek korzysta z mapy myśli, aby utrzymać płynność omawiania tematu i w ogóle zastosować narzędzie zamiast slajdów. Dla mnie było to olśniewające. Tego rodzaju przerywników potrzebuję najbardziej - odrywam się od zadania, zabieram się za odsłuchanie lekcji o UML, którego wydaje mi się, że znam, a tam dostaję za wytrwałość więcej, bo nie tylko uporządkowaną wiedzę o UML, ale i praktyczne użycie mapy myśli. Bajka.

Przejrzałem kilka filmików na stronie producenta XMind, o samej idei map myśli na YouTube i jestem wkręcony. Widzę sens stosowania narzędzia. Gdzie? Chociażby do wspomnianego uporządkowania wystąpienia (podczas mojego kolejnego nie omieszkam zastosować i spróbować praktycznie), albo do przygotowania planu spotkania zamiast kartki czy dokumentu tekstowego, gdzie włożenie pozycji do istniejącej listy może nie być tak intuicyjne jak wciśnięcie TAB czy ENTER. Podoba mi się również użycie do planowania dnia (wiele prezentacji na YouTube dotyczyło GTD z mapami myśli), albo jako notes przy rozpoznawaniu tematu.

Jestem w trakcie pisania poprawki na potrzeby OPENEJB-1433 Upgrade to Apache CXF 2.3.2 i do tej pory używałem notatek w Evernote. Samo narzędzie warte rozważenia, ale przy XMind, uważam je za nieadekwatne do problemu i mapa myśli będzie bardziej strawna. A może po prostu potraktować mapę myśli jako element notatki w Evernote, aby poradzić sobie z dystrybucją/dostępnością? Ciekawym sugestii, jak Tobie idzie z zarządzaniem planami rozwojowymi, a przede wszystkim z ich utrzymaniem. Samą mapę, którą użyję do poprawki dla OpenEJB, nie omieszkam opublikować do publicznej oceny z prośbą o możliwe usprawnienia w posługiwaniu się narzędziem.

Od razu mi lepiej, kiedy tak ustawiłem się narzędziowo. Jakbym miał więcej czasu. Co ja z nim zrobię?! Może pora już zabrać się za wykonanie jakiegoś zaplanowanego zadania?

21 stycznia 2011

A może do teatru? "Piąta rano" nie przegap!

5 komentarzy
Jak wielu z Was mogło zauważyć, od jakiegoś czasu, dokładnie od początku roku 2011, nie upubliczniam wpisów na tym blogu. Powodem jest próba uporządkowania moich aktywności, aby efekt był proporcjonalny do włożonego wysiłku. Ot, jedno z wielu deklaracji, które obiecywałem sobie, że zrealizuję, a jakoś tak nie wychodziło.

Tym razem jest inaczej. Z nowym rokiem przeniosłem się na angielskojęzyczny blog pod adresem http://blog.japila.pl. Tutaj było po polsku (i tak zostanie), ale na pewno będzie mniej technicznie, jeśli w ogóle, a tam wyłącznie po angielsku i profesjonalniej.

Rozdwojenie moich poczynań pozostanie, bo w końcu żyję i funkcjonuję w Polsce, moim językiem jest przede wszystkim polski, a jedynie/aż technicznie ujawniam swoje alter ego, które swoje poczynania opisuje na wspomnianym blogu japila.pl.

I kiedy ostatnio pojawiłem się na monodramie muzycznym "Piąta rano" Fundacji Artystycznej MŁYN zamurowało mnie - jak to muzycznie można zrobić tak ciekawe przedstawienie! Żona wiedziała, że może mnie wycofać, gdybym wiedział, że to muzyczna imprezka i kolejny raz okazało się, że często dobrze niewiedzieć, aby posmakować nowego. A było na prawdę smacznie! Występ cudo!

Zainteresowanych odsyłam na stronę monodramu, albo od razu do rezerwacji biletów, które kosztują jedynie 15 PeeLeNów:

* mailowo: rezerwacje@fundacjamlyn.pl
* telefonicznie: 0 519 672 356
* SMS-em: 0 519 672 356

Ach, bym zapomniał o gdzie i kiedy:

22 stycznia godz. 19:00
Scena Staromiejska SCEK
ul. Jezuicka 4

03 listopada 2010

Samodoskonalenie zwinnych zespołów

3 komentarzy
3 dni wolnego, to doskonały moment, aby się chwilę zastanowić. Można się było nawet zastanawiać, nad czym by się tu zastanowić (!) Szacunek dla szczęśliwców.

Mnie wzięło na rozmyślania o terminie samodoskonalenie w połączeniu ze zwinnym zespołem. Wciąż rozmyślam, jakich sposobów używać, aby zachęcić do większej aktywności w ramach społeczności typu Warszawa JUG. Niby jest ponad 400 członków, a ruch na grupie, jakby było nie więcej niż 50. Czyżby pozostali nie posiadali własnego zdania?! Niemożliwe.

W tym kontekście, rozmyślam, jak wyglądałby mój doskonały zespół, gdyby mi przyszło prowadzić jakiś. Czy byłby zwinny i tym samym samodoskonalił się? Jak stałby się zwinny? I kiedy mógłbym stwierdzić, że jest samodokonalający się?

W moim przekonaniu samodoskonalenie jest wpisane w kontrakt zwinnego zespołu. Po prostu, jeśli jesteś zwinny (technicznie), to musisz się ciągle rozwijać. Możnaby postawić tezę, że siła zwinności liczona jest przez ilość czasu poświęcanego na rozwój siebie i "okolicy". Od ludzi posiadających taką cechę, czym ona mocniejsza, tym bardziej emanuje na innych. Taki zespół nie czeka na prośbę podzielenia się wiedzą, ale robi to regularnie i otwarcie. Jednym z "objawów" jest m.in. posiadanie własnego bloga (przez "własny" rozumiem taki, z którym się identyfikujemy - rzeczywiście własny lub całego zespołu).

Mam nieodparte wrażenie, że powszechnie pojęcie zwinnego zespołu kojarzy się głównie z posługiwanymi się narzędziami i technikami, które określa się jako zwinne - techniki Agile. Uważam, że to tylko jeden z trybików. Zgodnie z definicją słowa na pwn.pl "zwinny" to 1. «wykonujący szybkie, zręczne ruchy», 2. «o ruchach, poruszaniu się kogoś lub czegoś: szybki i zgrabny». Dokładnie odpowiada mojemu postrzeganiu zwinnego zespołu - jest zręczny, szybki i zgrabny (wszystko w kontekście jego "wyglądu" i zachowania stricte technicznego)

W moim rozumieniu zręczność techniczna zespołu jest cechą jego przygotowania do zastosowania odpowiedniego narzędzia do problemu. Tutaj liczy się znajomość wszystkich "cudów świata" - czym więcej języków programowania, bibliotek, szkieletów, produktów, tym lepiej. Niech znajomość ich będzie pobieżna, ale wystarczająca do podjęcia decyzji o zastosowaniu jednego vs drugiego.

Szybkość zespołu jest cechą, w której sama znajomość jest poparta pewnością wyboru narzędzia i umiejętnością jego wdrożenia - implementacji. Z szybkością kojarzy mi się bardziej pewność działania (ale nie arogancja!) niż czas. Tutaj liczy się posiadanie speców od danej technologi, którzy wykazują się większą niż przeciętna znajomością tematu. Nie oznacza to jednak, że całe ich dnie wyglądają podobnie - wciąż wałkują ten sam temat, a raczej szczególniej mu się przyglądają. Powiedzmy, że ta szczególność polega na poświęceniu tematowi 20% więcej czasu.

Zgrabność zespołu jest cechą, w której umiejętnie dopasowuje się do sytuacji. "Ciągłe ćwiczenia są kluczem do sukcesu" świetnie tutaj pasuje. Ciągłe próbowanie się z nowym i ciągłe dzielenie się wiedzą, aby w końcu ciągle następował przepływ wiedzy, którą można korygować, wzbogacać i ostatecznie zastosowywać. Niech wiedzą, kto wie, abyśmy wiedzieli, że wiemy :) Łatwo wpaść w zniechęcenie, kiedy człowiek sobie uzmysławia, jak niewiele wie. Pozytywne sygnały z zewnątrz mogą być niezwykle motywujące.

Kluczem jest wiedza i chęć jej zdobywania.

To, ile czasu poświęcamy na poznawanie, zależy wyłącznie od nas samych. To, ile czasu poświęcamy na dzielenie się wiedzą, również. Zastanawiam się więc, skąd tak niewielu z nas ma na to ochotę? Poznawajmy, próbujmy, dzielmy się wynikami, spostrzeżeniami i dyskutujmy. Niech Ci, co wiedzą, wiedzą, że my nie wiemy, a Ci, którzy nie wiedzą, wręcz przeciwnie, wiedzieli, że my wiemy. W końcu musi nadejść moment, w którym komuś zacznie się wszystko składać w coś sensownego i podzieli się z innymi, oszczędzając nam wysiłku, abyśmy mogli zabrać się za kolejny problem.

W jaki sposób uczyć się? Polecam czytanie, duuuużo czytania. Kiedy skończy się czytanie, warto podzielić się swoimi przemyśleniami - zacznijmy od bloga, w postaci krótkiej notki, albo wręcz mikrobloga (ala twitter lub delicious), gdzie pojawi się choćby ślad naszej aktywności w danym obszarze. Może też być podczas 30-minutowego spotkania zespołu pod koniec tygodnia, np. w czwartek, albo wystąpienia na spotkaniu JUGowym (mamy ich ponad 10 w Polsce!) W zasadzie, niech będzie wszystko po trochu. Czym szybciej wyłożymy nasze problemy do publicznego osądu, tym szybciej uda nam się dotrzeć do rozwiązania. Ludzie z natury są życzliwi i chcą pomóc. Są jednocześnie samolubni, więc widząc, że jest gość, który przygotuje, a później zreferuje, przyjdą i zadadzą pytanie bądź dwa. W ten sposób, osoba ucząca się zdobędzie postrzeganie innych, a oni w zamian dostaną naszą relację, nasze streszczenie tematu. Obie strony będą usatysfakcjonowane. Nikt nie traci.

Podsumowując: uczmy się i innych. Starajmy się dzielić wiedzą i inspirować innych do działania, ciągłego działania. Jeśli on to robi i Ty zaczniesz, to koniec końców znajdą się wreszcie inni, którzy widząc naszej sukcesy, zechcą pójść w nasze ślady (porażki również odnotowujemy w kolumnie sukcesów, bo nic tak nie "pionuje" jak solidna dawka porażki). Któż nie chciałby osiągać celu krócej? Satysfakcja gwarantowana.

Zastanawiasz się, od czego należałoby zacząć?! Zakładasz bloga i raz w tygodniu umieszczasz podsumowanie swojej tygodniowej działalności (nie masz co pisać, powinno być odczytywane jako strata tygodnia i pora zabrać się za inne, bardziej twórcze zajęcie). Potraktuj każde z wykonywanych czynności, jako możliwość nauki. Chcą, abyś coś sprawdził, sprawdź i jeszcze dodaj coś od siebie, np. niech to kolejnym razem będzie automatycznie, albo niech będzie spisane. Pomyśl o spotkaniach zespołu, podczas których dzielicie się ostatnimi doświadczeniami - coś ala retrospekcja, czy podsumowanie iteracji, czy jak to tam się mogłoby nazywać. Chodzi o bezpośredni kontakt z zespołem. Gdzieś ostatnio przeczytałem (w wolnym tłumaczeniu) "Skoro już jesteś, bądź zauważonym". Lans jeszcze nikomu nie zaszkodził :) Tylko z umiarem.

Sądzę, że po kilku tygodniach śmiało można będzie nazwać Cię liderem zwinnego zespołu. Gratulacje!

14 października 2010

Nagradzać zaangażowanych podwyżką - wrażenia z Video from my presentation at Agile Warsaw Jakuba Nabrdalika

19 komentarzy
Jakub Nabrdalik w swojej prezentacji (patrz Video from my presentation at Agile Warsaw) przedstawił ciekawy sposób na motywowanie zespołu programistów do większej aktywności. Jest to zbieżne z moim, ostatnim apelem o udział w konferencji warsjawa (patrz O warsjawie i monadach w Clojure - nauka wspólnie jako sposób własnego rozwoju) i wpadłem na pomysł rozwinięcia myśli, aby nagradzać zaangażowanych podwyżką. Jeśli tylko takiej żądają gratyfikacji, dlaczego nie?!

Podczas wystąpienia Jakuba padło pytanie, albo przynajmniej pojawiła się kwestia, możliwości udźwignięcia tego pomysłu przez pracodawcę i sądzę, że moje rozważania pozwalają na opanowanie i tego. Nie jest to specjalnie odkrywcze i opiera się na założeniu, że miarą kwalifikacji pracownika jest tylko i wyłącznie jego możliwość wygenerowania zysku dla firmy przez różne formy jego aktywności.

Załóżmy model firmy (niekoniecznie informatycznej, ale podprogowo to ona będzie tłem), w której rozwój osobisty jest nagradzany podwyżką, bo większe kwalifikacje, to większe możliwości firmy do zwiększenia przychodów. Trywializując, pracownik przeczytał książkę i oczekuje podwyżki. Albo bardziej wyrafinowanie, skończył pomyślnie projekt i oczekuje podwyżki. Pytanie, kiedy taka "funkcja" osiągnie swoje maksimum i czy w ogóle takowe istnieje? Byłaby to funkcja zarobków od doświadczenia, a nie funkcja zarobków od dojrzałości firmy, aby skorzystać z wiedzy wykwalifikowanego pracownika.

Pierwszy fakt (a może jednak jedynie założenie?) jest taki, że w takim modelu funkcja jest niemalejąca, czyli co jest pewne, to stabilny poziom pensji. Raz otrzymawszy podwyżkę, do końca kontraktu, kwota się należy - czy się stoi, czy się leży.

Już nie jest faktem, czy funkcja ma swój punkt maksymalny. Właśnie, czy Ty uważasz, że kiedyś nastąpi zatrzymanie wzrostu pensji? Zapewne wielu odpowie, że tak, bo "przecież nie może być tak, że będę się ciągle kształcił i jednocześnie będzie mi rosła pensja!" Czyżby?

Ja uważam, że tak może być - rośnie nasza "siła nabywcza/rynkowa", więc rośnie jednocześnie siła firmy, w której delikwent jest zatrudniony. Proszę mieć na uwadze, że nigdy nie prowadziłem żadnej firmy, nawet jednoosobowej, oraz jedynym moim podwórkiem były amerykańskie korporacje - Lucent, HP i IBM.

Oczywiście, pensja jest jedynie materiałem, za który kupujemy inne dobra, więc czy to samochód, czy wycieczka do ciepłych krajów, wliczam to do podwyżki, za którą pracownik sam będzie mógł je kupić (odpowiednio rozkładając zakup na raty z pensji). Upraszczamy model firmy, w której nagrodą może być jedynie zwiększenie pensji.

Zastanówmy się na moment. Na początku pewnie będzie stosunkowo łatwo dla pracodawcy podwyższać pensję rok do roku, bo startujemy z niskiego pułapu i margines zysków firmy z naszego zatrudnienia jest duży. Stąd tak wiele firm zatrudnia kilku wysokowykwalifikowanych pracowników, a reszta to nowicjusze, najczęściej studenci (ciekawe, czy ktoś wie, gdzie uknuto powiedzenie "Każdego specjalistę da się zastąpić skończoną liczbą studentów"?) Czy zysk firmy z naszego zatrudnienia musi maleć? Nie. Musimy jednak rozważyć coś więcej niż samo czytanie książek, np. wspomniany przed momentem mentoring.

Jakie możliwe aktywności możemy rozważyć w naszej branży? Weźmy coś, co nie kojarzy się wprost z zyskiem finansowym - czytanie książek i pisanie recenzji, które publikujemy na blogu. Doświadczyłem tego nie raz i muszę przyznać, że to niełatwe przedsięwzięcie. Stąd łatwiej będzie mi go rozłożyć na czynniki pierwsze.

Po pierwsze, należy znaleźć czas, który pracownik poświęci na przeczytanie książki. To jest jego czas prywatny. W naszym modelu firma pokrywa koszt poświęconego czasu pracownika przez 8 godzin. I właśnie za tę formę aktywności firma miałaby mu zapłacić. Dlaczego? Właśnie dlatego, że robi to w wolnym czasie, który mógłby przeznaczyć na cokolwiek innego, a nie coś, co może przynieść zysk firmie przez podniesienie jego kwalifikacji. O tym zysku za moment.

Po drugie, należy znaleźć czas na spisanie własnych przemyśleń nt. książki w postaci recenzji. To znowu jest czas prywatny pracownika. Jeśli dołożymy do tego język angielski, to może okazać sie to dla wielu na prawdę niemałym wyzwaniem - nie tylko język, ale i umiejętność spisania w nim swoim myśli. Pamiętam, jak dziś, kiedy z języka polskiego zawsze miałem 3 z wypracowań i tylko dlatego zdałem maturę z polaka, że znałem wszystkie wymagane lektury i napisałem na temat bez błędów ortograficznych...3 strony A4! Dowiedziałem się, że pisałem konkretnie do bólu i ledwo mi się udało. Teraz z pisaniem jest łatwiej, ale wciąż wyrażenie swoich myśli w angielskim uważam za niebagatelną umiejętność. To znów podniesienie kwalifikacji pracownika i zwiększa jego obszar pozyskiwania wiedzy, nie wspominając już o znajdowaniu czytelników swojego "produktu" za granicą. To niemały kapitał dla firmy. Jeszcze do tego wrócimy.

Po trzecie, blog. Prywatny, bez wzmianki o pracodawcy ma inny wydźwięk niż ten ze wzmianką, albo wręcz firmowy. Tu możemy budować kapitał firmy przez aktywność pojedynczego pracownika w obszarze jej reklamy. W końcu, wielu z nas może wymienić firmy, z którymi chciałby współpracować tylko dlatego, że jej pracownicy są rozpoznawalni w tłumie. Z naszymi, lokalnymi firmami jeszcze kiepsko w temacie reklamy własnej przez pryzmat aktywności jej pracowników, ale da się zauważyć kilka, o których mógłbym powiedzieć niemało, tylko dzięki tego typu aktywnościom - przez pryzmat ich bytności na konferencjach, twitterze czy blogach. I znowu, aktywność pojedynczego pracownika jest w ramach własnego czasu, często ze zrzeczeniem się potencjalnych "zysków" z opublikowania swojej pracy - recenzji - na blogu firmowym. Rozpoznanie pojedynczego pracownika wtedy gaśnie na rzecz budowania marki firmy. To kolejny zysk pracodawcy.

Widać, że na tym przykładzie można wyróżnić zysk pracownika - własny rozwój literacki, rozbudowanie znajomości j. angielskiego, umiejętność prezentacji własnych myśli oraz zysk pracodawcy - podniesienie kwalifikacji pracownika oraz niebagatelna sprawa - reklama. Widzę w tym wzrost obu.

Rozważmy sytuację brzegową - jesteśmy na poziomie seniorskim (a może senioralnym?) i nasza pensja oscyluje w granicach 300k PLN netto jako programista. Uśmiech na twarzach wielu, zdradza nierealność tej sytuacji w Polsce, ale wierzę, że kiedyś będzie to możliwe (a może już jest?!). Trochę przekolorowałem (i śpieszę donieść, że daleko mi do tej kwoty, usprawiedliwiając jej brak, że jest mi po prostu niepotrzebna :)), ale mimo wszystko stawiam tezę, że bez względu na poziom aktualnych zarobków, firma wciąż ma możliwość podnoszenia pensji. Jak?

Czy pracownik jest jednostką w firmie, czy pracuje zespołowo? Odpowiedź nasuwa się sama - zespół przede wszystkim. Takie myślenie mi pasuje. Idźmy dalej.

Czy w pojedynkę można zarobić 300k PLN będąc na stanowisku programisty? Hmmm, być może. Zmieni się jednak nasze myślenie, jeśli rozważymy pracę całej ekipy mniej zaawansowanych programistów, sprzedawców i innych wspierających naszą pracę pracowników. Wszyscy robią rzetelnie, jak w jednym zespole. I tu się kryje tajemnica sukcesu - "wszyscy pracują rzetelnie"! W końcu, dlaczego prezes przedsiębiorstwa może tyle zarabiać, a pracownik niższego szczebla już nie? Czy wyższy szczebel w hierarchi firmy musi wiązać się z wyższą pensją niż podwładnego? Twierdzę, że nie.

Wszystko zależy od zaangażowania. Jeśli założymy, że wszystkim zależy na dobrobycie firmy, ale nie wszystkim zależy na zarabianiu więcej i więcej, to w końcu dojdziemy do sytuacji, że firma wykształci taką kadrę pracowniczą, że będzie trywialnym zdobywać kolejne projekty w kraju i za granicą, za które pokryje koszta własnych pracowników.

Czyż to nie pracownicy przynoszą kontrakty, za które oni sami są opłacani? Cudów nie ma. Czy grasz w pojedynkę, czy w zespole, moc przerobowa zależy od Twoich kwalifikacji i zaangażowania. Na moment zapominamy o takich anomaliach, jak łapówki, kontrakty z niekwalifikowanymi zespołami, itp. To z definicji są anomalie i raczej blokują rozwój społeczeństwa i krzewią złe przyzwyczajenia, jak "Tylko znajomości są ścieżką kariery w firmie i dadzą Ci podwyżkę".

Stawiam tezę, że w pewnym momencie firma będzie dostawała coraz bardziej intratne projekty, albo pracownik utworzy firmę potomną i mając wystarczająco doświadczenia spowoduje jej utrzymanie na rynku przez naukę nowych adeptów sztuki programowania. On sam, albo ona sama, ów szczęśliwiec pracując w obu przedsięwzięciach ma możliwość zarabiania więcej. I nie trzeba stawać się kierownikiem projektu czy PMem, czy co tam jeszcze wymyślono, aby utrudnić nam dostęp do zysków.

Pytanie tylko, czy nam się chce. Czy mamy wystarczająco motywacji, aby spróbować? I najważniejsze, czy jesteśmy społeczeństwem, które ceni zaangażowanych i pracowitych (i nie zarobionych, tylko pracujących)? Na to mam jedynie negatywne odpowiedzi. A Ty?

p.s. Znacznie uprościłem rozumowanie, bo pewnie nie powstałaby ekonomia, gdyby to było takie proste, ale niektóre rzeczy zdają się być w rzeczywistości proste, a tylko my sami je niepotrzebnie komplikujemy. Jak w sytuacji nieodpowiednich narzędzi do problemu.

08 września 2010

PIT-36 dla dochodów z zagranicy - zadowolony z rozmowy z US Ursynów

12 komentarzy
Dzisiejszy ranek postanowiłem przeznaczyć na małe dochodzenie odnośnie przychodów z zagranicy i ich rozliczania przez osoby nieprowadzące działalności gospodarczej. Nie pierwszy raz przychodzi mi dotknąć tego tematu i nigdy nie wiem, jak należałoby wystawić fakturę/rachunek (ang. invoice) za moją potencjalną działalność na rzecz firmy amerykańskiej.

Trzeba było widzieć moją minę, kiedy po kwadransie byłem niezwykle usatysfakcjonowany z rozmowy z Urzędem Skarbowym Warszawa Ursynów, ul. Wynalazek 3, 02-677 Warszawa.

Zaczęło się od telefonu na centralę 22 548-68-00, gdzie wybrałem tonowo 1 (mieszkaniec Ursynowa), a później 9 (operator, wcześniejsze brzmiały dosyć egzotycznie). I zaczyna się przedstawienie sprawy - firma amerykańska płaci obywatelowi polskiemu, który nie prowadzi działalności gospodarczej (aż trudno uwierzyć, że potrafiłem złożyć takie zdanie), a chciałby zgodnie z polskim prawem gospodarczym rozliczyć się jak na praworządnego obywatela przystało (końcówkę zmieniłem na potrzeby tego wpisu, bo aż tak wyniośle to nie artykułowałem sprawy). Pan przekierował mnie na Dział Rachunkowości pod numer 5486894, gdzie dowiedziałem się (po przedstawieniu sprawy), że powinienem "udać się" do Działu Podatków - i tu pojawiają się 4 możliwe numery: 5486712, 5486717, 5486708, 5486709. Zaczynam od pierwszego i po minucie rezygnuję. Drugi to samo, aby powiodło się z trzecim - 5486708. Tam dowiaduję się o kolejnym numerze 5486711. Super, dzwonię pod niego, aby dowiedzieć się, że faktura to nie sprawa dla mnie, a co najwyżej rachunek (co wydawało mi się, że jest po prostu fakturą uproszczoną, czy nieVATowską) i warto dowiedzieć się szczegółów pod kolejnym numerem 5486833 - Dział Podatku Dochodowego. Dzwonię, a tam kolejne przekierowanie na numery 5486821 lub -856 - Dział Podatku Dochodowego od Osób Fizycznych Nieprowadzących Działalności Gospodarczej. Odbiera pierwszy, aby miła pani poinformowała mnie (po konsultacjach w tle z innymi osobami, co przywołało mi na myśl, że osoba, z którą rozmawiam, to jedynie pośrednik - z naszego "proxy", albo "interceptor" z zerową implementacją poza wywołaniem docelowej metody :)), że rozwiązaniem jest PIT-36, gdzie wypisuję wszystkie dochody zagraniczne.

Trwało pewnie z kwadrans, wybrałem 10 numerów, ale cel osiągnięty. Jestem nad wyraz usatysfakcjonowany. Teraz wystarczy wystawić rachunek z wymogami płacącego i będzie cacy.

p.s. Zastanawiam się, czy byłoby łatwiej/prościej/przyjemniej, gdybym realizował to jako jednoosobowa działalność gospodarcza? Byłbym wdzięczny za wszelkie (p)odpowiedzi.