Stało się, dojrzałam.
Przenoszę bloga na nowy adres, taki mój własny dorosły: barbarafusinska.com.
Wszystkich wiernych fanów zapraszam właśnie tam.
Koniec nadawania… Stąd 🙂
Stało się, dojrzałam.
Przenoszę bloga na nowy adres, taki mój własny dorosły: barbarafusinska.com.
Wszystkich wiernych fanów zapraszam właśnie tam.
Koniec nadawania… Stąd 🙂
Po ostatnim wpisie dostałam pytanie: Czy coś w ogóle z tej wycieczki zarekomendujesz? No cóż… był gulasz, fajne towarzystwo z Polski, ładne miejsce konferencji i ławeczka nad Dunajem (zainteresowanym szczegółami mogę podać lepsze koordynaty)… Ale rozumiem – mało. Postaram się więc teraz, lecz na cuda nie liczcie
Ostatni dzień konferencji rozpoczął się od tradycyjnego zaspania, pysznego śniadanka, niewybrednych białostockich żartów i tłumnego pójścia na sesje.
Na keynote’a spóźniłam się sporo, ale ponieważ wszyscy bardzo go chwalili, dość szybko nadrobiłam to po powrocie. Co myślę? Że fajnie, ale d… nie urywa. Prezentacja była dobrze przygotowana i poukładana. Przedstawione sytuacje były dość ciekawie, działały też nieźle na wyobraźnię. Na przykład od tej pory, kiedy tylko jestem w McDonald’s, albo chociaż widzę ich szyld, wspominam ideę marketingową z początków tej firmy. Myślę: Jem kopię hamburgera . Ale wracając do samej sesji – znów nie do końca zrozumiałam, co było jej tematem przewodnim i brakowało mi tego. Ale to chyba jest problem wielu dzisiejszych prezentacji. Wciąż też szukałam tego czegoś niesamowitego, o czym słyszałam z wielu ust. Może po prostu zawiodłam się przez rekomendacje?
Aż strach pisać dalej…
Poza faktem, że slajdy wyglądały jakby ktoś je przerobił z folii do starodawnego rzutnika (i to jakimś kiepskim konwerterem), dodał pstrokate kolory i śmieszną czcionkę, wystąpienie było naprawdę dobre.
Już na początku okazało się, że nie dostanę tego, czego się spodziewałam, po tak atrakcyjnym tytule. Jednak mimo, iż nie było tu może nic rewolucyjnego, temat przedstawiony został bardzo rzetelnie i przystępnie. Tytułowy poziom abstrakcji okazał się ładowaniem logiki do odpowiednich klas, a sesja poprowadzona była w formie refaktoringu – na prezentacji co prawda, ale zawsze.
Nie mogliśmy wytrzymać do końca i pierwsze dyskusje nawiązały się już w trakcie wystąpienia. Slajdy jednak raziły i już mi chyba nikt nie powie, że nie mają one znaczenia. Natomiast kilka poruszonych kwestii prześlizgnęło się nam nawet do późno wieczornych rozważań podrinkowych.
To od początku był long shot. SOLID na poważnej konferencji w dzisiejszych czasach? Srsly? Przypomina mi się pierwszy DevDay… Ale ja mimo wszystko lubię taką tematykę, więc zazwyczaj się na nią nabieram.
Niestety potem było tylko gorzej. Dwie osoby mogły wprowadzić dużo dobrego mimo słabego przedmiotu sesji, ale ci panowie temu nie podołali. Jeden z nich (ten po prawej ) momentami ratował prezentację, ale człowiek łatwo o tym zapominał, gdy do głosu dochodził drugi, który co kilka zdań podchodził do laptopa i czytał ze notatek (sic!). To było strasznie lame. W sesji podobało mi się chyba jedynie porównanie różnych styli architektur do włoskiego makaronu
Wyglądało zachęcająco, ale okazało się ze tytułowe data to… dane statystyczne. O wpływie na produktywność i jakość. Pominę już fakt, że dla mnie badanie produktywności programisty to jakiś pomysł rodem z kosmosu, ale pewnie mogę sobie wyobrazić jakieś metryki, które wypluwają mniej lub bardziej sensowne liczby. Niech więc będzie. Natomiast jakość? No cóż, to już dla mnie totalna zagadka. Ale pewnie się nie znam na tych mądrościach i po prostu wszystko hejtuję.
Z tego co pamiętam obydwie te wartości brane były z ankiet pracowników, więc jakoś zagubił mi się ich obiektywizm. Stąd też nie rozumiem, jaki sens miało przedstawianie kilkuprocentowego wpływu takich czynników jak udział testerów w procesie czy refaktoring. Dla mnie nie było żadnego – wiec wyszłam. Słyszałam, że potem coś się poprawiło, pojawiały się wpływy kilkudziesięcioprocentowe. Ale średnio w tę poprawę wierzę. Jeśli więc kiedyś zdecyduję się obejrzeć tę sesję, to z pewnością nie będzie ona moim priorytetem.
No i wreszcie! Świetne prowadzenie, życiowy temat i mięso. Czyli to co Basia lubi najbardziej Żeby wiele nie zdradzić (bo tę prezentację trzeba koniecznie zobaczyć) powiem jedynie, że wystąpienie dotyczyło historii kilku projektów i absurdów związanych głównie z projektowaniem architektury, ale również z obowiązującymi w nich procesami czy metodykami zarządzania.
Momentami miałam nawet wrażenie, że uczestniczyłam w niektórych z nich . No i natchnęło mnie to do zrobienia podobnej prezentacji z moich doświadczeń. Dokładnie w tym momencie Stefan stwierdził, że on już wpadł na ten pomysł i od teraz tylko takie tematy zobaczymy w jego repertuarze
Już kilkanaście minut przed prezentacją, w sali zaczęli się zbierać grouppies Greg zaczął świetnym hasłem, którym od razu wszystkich rozbawił, a jednocześnie skupił. Jak to on – był świetnie przygotowany do tematu, którego przecież był autorem. Ta sesja powinna również być pozycją obowiązkową!
I tak właśnie konferencja dobiegła końca. W tym momencie pozwolę sobie na kilka uwag dotyczących organizacji. Właściwie moim zdaniem można się przyczepić jedynie do dwóch rzeczy:
Wieczorem pierwszy raz wybraliśmy się w szerszym gronie w bardziej turystyczną część Budapesztu. Po burzliwej dyskusji nad miejscem, zjedliśmy pyszny posiłek – przynajmniej ja, Mirek i Andrzej, bo reszta jadła coś innego .
Tego wieczora pożegnaliśmy wcześnie część towarzystwa, z uwagi na wieczorne i poranne powroty do domów. A ja się pytam po co? Nie można było zostać na weekend? Zupełnie tego nie przemyśleliście. Adamie – specjalnie dla ciebie, poniżej uwieczniona jedna z naszych ostatnich wspólnych chwil w Budapeszcie.
Dalsza część wieczoru odbyła się w fantastycznej knajpie. Nazwać ją jedynie hipsterską, byłoby lekkim nadużyciem.Zaadaptowana została z podwórka, a zagospodarowane lokale kryły w sobie wszelakie dziwactwa, jakie może podsunąć wyobraźnia. Nie moja co prawda, ale czyjaś na pewno Ciekawym (choć nie najoryginalniejszym tam) siedzeniem była polowa wanny, chętnie przez nas wykorzystana. Chociaż niedawno miałam okazję zobaczyć ten sam patent w Gdyni w knajpie stylizowanej na lata PRLu.
Chyba trochę jestem już za poważna (czyt. sztywna), by się aż tak jarać barem, czy jego wystrojem. Niemniej jednak muszę uznać kunszt osób, które się tym zajęły. Z jednej strony zrujnowane ściany, z drugiej elementy sztuki nowoczesnej, z trzeciej psychodela jakaś. Dla mnie – majstersztyk.
Zebraliśmy się dość wcześnie, bo zmęczenie trochę nas złamało. Jednak po drodze złapaliśmy drugi wiatr i tak intensywnie spędzony dzień trzeba było uczciliśmy browarkiem na … przydunajowej ławeczce
Rześcy i gotowi zebraliśmy się całą kupą (tak, tak, znów białostocką, choć zupgrade’owaną o przyjezdną tego dnia Joasię), by rozpocząć podbój Budapesztu i jego zabytków. Poprzedniego dnia umówiliśmy się z Mirkiem i jego rodziną, by razem zaliczyć zwiedzanie. Zebraliśmy się więc w kierunku parlamentu, by paręset metrów przed nim usiąść w knajpce w środku jakiegoś parku. I tak nie wiadomo skąd, zrobiła się godzina 13. Po drodze odnalazł nas Gutek, ale szybko oddalił się w swoją stronę, zresztą tak samo jak Marcin. Chyba ocenili nasze tempo i postanowili jeszcze dzisiaj coś zobaczyć.
A my posileni piwkiem ruszyliśmy dalej. Po parlamencie odłączyli się od nas Robert z Joasią, a reszta skierowała się w stronę wzgórza zamkowego. Wjechaliśmy tam kolejką Sikló i to chyba było dla mnie ciekawsze niż cały ten zamek. Wkrótce poczuliśmy też głód, naszą uwagę skupiło więc poszukiwanie odpowiedniego lokalu gastronomicznego. Rozsiedliśmy się tak miło przy gulaszowej i kolejnym browarze, że niestety przegapiliśmy godziny otwarcia Kościoła Św. Macieja. Na szczęście baszta rybacka otwarta jest cały dzień Było tam po prostu pięknie.
I od tego momentu zaczął się dla mnie dramat… Obcierające buty zaczęły mi bardzo dokuczać.Kilka kilometrów dalej (w mojej głowie sto, ale w rzeczywistości może ze dwa) moje ciało odmówiło posłuszeństwa. Usiadłam i powiedziałam: Dalej nie idę. Ale ponieważ poszłam (dzięki Basiu za pożyczenie japonek), chyba do końca nie wszyscy wzięli mnie na serio. Niewierni – nie zdawali sobie sprawy, że gdy mówię o braku kondycji, to jest to szczera prawda i tylko prawda. Towarzystwo (a szczególnie Karol) stali się w końcu ofiarą wykończenia mojego organizmu. Gutek, który odnalazł nas po raz drugi tego dnia, dość szybko uciekł od naszych kłótni
Zbawienna okazała się Meggy, gdyż szlaki wędrowne ponownie skierowały nas w stronę Bálna Budapest. Na szczęście po pewnym czasie wstąpiło we mnie drugie życie i byłam w stanie wieczorkiem rozkoszować się atmosferą kolejnej fajnej knajpy, umiejscowionej w podwórku. Można było tu spróbować kilkudzieściu gatunków piw, pojawiło się więc kilka konkursów, kto zasmakuje ich największej liczby. Ta impreza była dla mnie osobiście okazją do zawarcia nowych znajomości (tak Michał, o tobie mówię) i chwilowej chociaż rezygnacji z towarzystwa wzajemnej adoracji.
W niedzielę już prawie nikogo nie było “na mieście”. Większość rozjechała się tuż po śniadaniu lub jeszcze wcześniej. Dzień zaczęliśmy więc z Pawłem ok. południa Przypomnieliśmy sobie o Marcinie i razem popłynęliśmy tramwajem wodnym na wycieczkę po Dunaju. Ze względu na zakwasy i wspomnienia dnia poprzedniego, była to preferowana przeze mnie forma uprawiania turystyki. Niestety stateczek dość się ociągał, a mieliśmy w planach jeszcze coś zobaczyć i oczywiście zdążyć na samolot. Trzeba było się więc ewakuować w okolicach Wyspy Św. Małgorzaty.
Nie znalazłam w sobie tyle siły by całą drogę powrotną przejść pieszo, chłopaki stali się więc ofiarą mojej pospacerowej traumy. Mam nadzieję, że bardzo nie narzekają, bo starałam się jak mogłam, a przy okazji poznaliśmy uroki budapesztowego transportu publicznego. Zahaczyliśmy jeszcze o wczorajszy (dla mnie) zamek i Kościół Św. Macieja (gdyż znałam już drogę), ale odpuściłam tym razem zwiedzanie na rzecz ocienionego miejsca na schodach i schłodzonego tokaja (btw. świetny pomysł, Paweł ). Ostatkiem sił (i za pomocą tramwaju) doczołgałam się z powrotem do hotelu, skąd czas był już wracać. Co niniejszym uczyniliśmy.
Ot i koniec relacji. Podsumowując – było świetnie, o wiele lepiej niż się spodziewałam biorąc pod uwagę tłumy ludzi (które działają na mnie stresująco), kilkudniowy pobyt za granicą (zwykle wieczorem pierwszego dnia włącza mi się homesick) oraz niezbyt wysoką jakość sesji.
Rozpocznę trochę niechronologicznie, ale narobiło mi się tyle konferencyjnych zaległości, że to, co już jest nieświeże, może chwilę jeszcze poleżeć. Poza tym, zdarzenia aktualnie, lub te co zadziały się całkiem niedawno, z pewnością są ciekawsze niż to co wydarzyło się w dalekiej przeszłości.
Więc… pod koniec kwietnia odbyła się wyczekiwana przez wielu (w tym mnie samą) konferencja CraftConf. Już sama nazwa dawała wiele nadziei, a potem miało być tylko lepiej. Obietnica 2 dni konferencji, ciekawych warsztatów oraz meetupów zorganizowanych w tym czasie przez lokalne społeczności, ściągnęła do Budapesztu rzesze spragnionych chleba i igrzysk programistów. Oczywiście nie samym chlebem człowiek żyje , ale nie będę się tu rozwodzić nad tym po co jeżdżę na konferencje. Myślę, że zrodzi się z tych refleksji odrębny wpis.
Przedstawię natomiast kronikę zdarzeń widzianych moimi oczami. Może komuś zaoszczędzi to oglądania prezentacji, których nie polecam. Albo wręcz przeciwnie – polecę komuś jakąś sesję. Może zachęcę do urlopu w Budapeszcie, albo zareklamuję jakieś lokalne danie czy trunek Zobaczymy. Zachęcam jednak mimo wszystko do wyrobienia sobie własnego zdania na każdy z tych aspektów. Dodam jednak, że uczestniczyłam jedynie w samej konferencji, ominęły mnie warsztaty, więc na ich temat wypowiadać się nie będę. A jeśli chodzi o sesje, to konferencja zorganizowała 3 ścieżki, stąd wniosek, iż widziałam maksymalnie (sic!) 1/3 z nich. Więc sama już zasiadłam do nadrabiania zaległości i oglądania ich online.
Przyleciałam zbyt późno by zdążyć na meetupy… Niby trochę żałowałam, ale szybko okazało się, że nie jestem jedynym leniem w Budapeszcie Niemal prosto z taksówki zgarnęła mnie ekipa Białostocka (Maciek, Joanna, Karol, Mariusz oraz Robert) i razem poszliśmy do bardzo klimatycznej knajpy, gdzie wszyscy zakosztowaliśmy prawdziwego (na tyle, na ile byliśmy w stanie stwierdzić) węgierskiego gulaszu. Siedzieliśmy tam dłuższą chwilę słuchając muzyki na żywo, granej przez panów o aparycji członków mafii, popijając napoje orzeźwiające.
A gdzieś tam w czeluściach melanżowego Budapesztu odbywała się prekonferencyjna impreza, na którą … nie chciało się nam iść. Bardziej atrakcyjną opcją był zakup odpowiednich trunków i spożycie ich w przy Dunaju, w klimacie nieco menelskim . Pogoda była świetna, a mi udało się uwiecznić widok z “naszej” ławeczki.
Co prawda Robert kupił okropne drugie wino, ale z racji tego właśnie, że było ono drugie – smak przeszkadzał tylko trochę i tylko na początku. Po kilku godzinach pewna część (głównie polska) wspomnianej wcześniej imprezy przeniosła się do nas. Nie dla każdego starczyło więc miejsca siedzącego, ale panujący klimat zaowocował chyba tym, że nikomu specjalnie to nie wadziło. Dzień zakończył się późno, choć nie aż tak, by był problem ze wstawaniem następnego dnia.
Po w miarę przyzwoitym śniadaniu zebraliśmy się na krótki spacer w stronę Bálna Budapest. Chociaż do organizacji jeszcze się przyczepię, to muszę przyznać, że chyba nie widziałam dotąd ładniejszego miejsca na konferencję – zarówno z zewnątrz jak i wewnątrz. Poniżej lista recenzji sesji, w których uczestniczyłam. Kilka opuściłam, bo było piffko, ładna pogoda, czy ciekawsze okazały się dyskusje kuluarowe. Nie mniej jednak trochę widziałam.
Nieco się spóźniłam na tego keynote’a, ale żałuję, że nie bardziej. Nie do końca wiem o co chodziło, ale gdybym miała strzelać, to powiedziałabym, ze o jakąś metaforę, porównanie postaci My Little Pony ze stylami zespołów programistycznych/ języków programowania/ samych programistów…? Nie w pełni to zrozumiałam. Żeby nie było – jestem w sekcie kucyków, znam bohaterki, ich temperamenty i zwyczajnie uwielbiam tę bajkę. Jednak sposób prowadzenia, a przede wszystkim monotonny styl tej pani, spowodowały, że z utęsknieniem wspominałam niedawno opuszczone lóżko.
Wystąpienie było dość przyjemnie i zaskakująco merytoryczne, ale … nieco banalne. Dziewczyna ma 10 lat doświadczenia w IT, głównie jako programistka .Net, więc od początku poczułam coś na wskroś spotkania bratniej duszy. Ale o ile potrafiłam się z nią zidentyfikować, w dalszej części prezentacji skończyły się już porównania. Spodziewałam się ciekawszych historii do opowiedzenia, a nawet konkretnych rad-algorytmów dzięki którym zespół będzie ciągle dostarczał . A wyszło, … jakoś tak nijako.
I niestety doczekałam się sesji typu Story of some project. Na każdej konferencji jest taka, zwykle jako konsekwencja sytuacji: nie mam tematu na prezentację, to opowiem o tym co robię na co dzień. Napiszę o zjawisku jeszcze bardziej szczegółowo, a teraz podsumuję tylko: ten projekt i ta historia nie były ciekawe. Wszystko co zostało powiedziane można streścić w jednym zdaniu: Projekt poprowadzony był źle, a potem zaczął się proces refaktoringu. Gdzie tu legacy? Gdzie fight?
Maciek namówił mnie bym twittnęła co tym sądze i teraz żałuję, że nie napisałam czegoś bardziej dosadnego, bo śledzenie feeda dostarczało nam o wiele więcej rozrywki niż sesja. Dlaczego się nie zmyliśmy? Bo durni usiedliśmy na przedzie i jakoś tak głupio było wychodząc pchać się przed kamery.
Poza tym, stwierdziliśmy, że wytrzymamy, bo za chwilę miała na scenie stanąć … legenda
No i nadeszło … największe rozczarowanie tego dnia i pewnie całej konferencji. Zapowiedź gwiazdy zwykle kreuje wiele wygórowanych oczekiwań, więc to, że nie będzie fajerwerków byłoby do przełknięcia. Ale sytuacja przedstawiała się dużo gorzej. Nieśmiertelny (bo najwyraźniej nie da się go uśmiercić) temat cargo, fatalne slajdy i przede wszystkim jednostajny ton prezentacji można podsumować jednym słowem – nuuuuudy. Wiem, ze kilku osobom mimo to sesja bardzo się podobała, może więc chodzi o moją kumatość, czy brak dogłębnego rozeznania w temacie, ale praktycznie od początku czułam się jakby ktoś odciął mi kabelek łączący uszy z mózgiem. Nie zrozumiałam prawie nic, a po chwili zwyczajnie słuchać przestałam.
Nareszcie! Ja i cała konferencja doczekaliśmy się najlepszej prezentacji tego dnia. No suprise here – Dan po prostu dał czadu, jak zwykle. Uwielbiam metafory, a ta, która została przedstawiona w kontekście procesu uczenia się, była po prostu genialna. Sam warsztat prelegencki – nie wiem czy umiem to ująć jakoś sensownie. Każdy kto kiedykolwiek widział jakąś jego prezentację, wie co chcę powiedzieć. A kto nie widział, powinien to jak najszybciej nadrobić. Nie byłabym jednak sobą, gdybym się do czegoś nie przyczepiła. To była sesja nietechniczna, co samo w sobie nie jest złe. Natomiast (wiem wiem – wyklniecie mnie) dla mnie było w niej za mało mięsa. Zabrakło mi konkretów, wiedzy, pojęć, definicji.
I tak – szykuje się z tego kolejny wpis
Nie wiem czy to efekt niesamowitości poprzedniego wystąpienia, czy po prostu sesja była słaba, ale to co mówił Bruce wydało mi się tak nudne, że po kilku minutach postanowiłam zrezygnować ze słuchania. Teraz siadłam strategicznie z tyłu sali, skąd można było się bezpiecznie ewakuować. Obiecałam sobie, że jednak dam tej prezentacji szansę jakiej nie miała przez fatalny timing i odtworzę ją w zaciszu domowym.
Po zakończeniu części prezentacyjnej zorganizowana była impreza. Ale chyba nie wyszła za dobrze. Ludzie się zmywali dość wcześnie – jednym było za głośno, innym za gorąco, jeszcze inni zaczęli szukać miejsca gdzie można coś zjeść. Nie pomógł wiele występ niesamowitego zespołu Little G. Weevil. A choć nie jestem fanką improwizowanej (ani stylizowanej na improwizację) muzyki, to muszę przyznać, że akurat przy tej świetnie się bawiłam.
Na szczęście tuż za “rogiem” był świetny bar, gdzie znalazłyśmy wraz z Joanną nasze piwo szczęścia – Meggy. Po kilku przetasowaniach, spacerach, poszukiwaniach jedzenia (wczorajszy gulasz niektórym mocno utkwił w pamięci ) i zmianach knajp, choć w różnych konfiguracjach i czasach wszyscy wrócili do swoich(?) łóżek.
28. stycznia we Wrocławiu odbyło się 8. spotkanie Women in Technology. Niecnie wykorzystałam swoją znajomość z szefową i wkręciłam się wtedy na prelekcję ze swoim cyrkiem obwoźnym, czyli wstępem do programowania w Windows Phone. Sam łysogórski zlot odbył się na 25 piętrze SkyTower. Przypomniało mi się dość szybko, że mam lęk wysokości, więc przez całe spotkanie unikałam wielkiego okna z tyłu sali. Mimo wszystko trochę go przełamałam i udało mi się uchwycić widoczny stamtąd uliczny zgiełk.
Gosia rozpoczęła spotkanie od przedstawienia kilku nowości technologiczno-konferencyjno-sponsoringowych (jakkolwiek dziwacznie to brzmi ). Następnie po krótkim przedstawieniu się wszystkich, rozpoczęłam prezentację.
Po ostatniej porażce konfiguracyjno-przygotowawczej, mój poziom pewności siebie oscylował w okolicach –10. Dlatego tego dnia pojawiłam się na miejscu dużo wcześniej i sprawdziłam, czy na pewno wszystko dobrze działa.
Działało … do momentu, gdy miałam rozpocząć. Na pierwszy ogień poszedł rzutnik – nie chciał wyświetlić niczego co miałam na ekranie, choć robił to zaledwie 15 min wcześniej. No ale powiedzmy, że się na mnie obraził za to, że udostępniłam go Gosi zamiast tkwić wiernie przyczepiona kabelkiem. Nie obyło się bez jego restartu, co wprowadziło nieco ożywienia, bo pilot również odmówił współpracy. Pozostała więc drabina i ręczne użycie guzika prezentera przyczepionego do sufitu.
Potem oczywiście padła mi sieć i wywalił się emulator, ale… wpadłam na iście genialny pomysł. Zamiast miotać się z szukaniem problemów w konfiguracji, postanowiłam zastosować najstarszą sztuczkę w świecie IT – turn it off and on again… wiedząc, że mój komp wstanie w czasie ok. 5 sekund. Decyzja ta zbawiła moje wystąpienie, a dalsza część przeszła już gładko i bez zbędnych przerywników.
W kilku momentach pojawiły się dyskusje, ponieważ na sali obecne były ekspertki od Windows Phone. Sama też dowiedziałam się kilku rzeczy, dzięki czemu moja prezentacja po raz kolejny została ulepszona. Przekonywałam jak zwykle, by w codziennej pracy używać urządzenia zamiast emulatora. A z racji takiego, a nie innego grona, wzbudzałam mniej kontrowersji, gdy machałam różowym telefonem.
Po mnie nastąpiła kolej na ćwiczenie networkingowe, za przygotowanie którego należy się wielki szacun dla Kasi. Dowiedziałyśmy się (pewnie po raz kolejny) jak ważna jest komunikacja i jak różne może przybierać formy. Poznałyśmy się trochę lepiej i już w całkiem luźnym, choć nadal licznym gronie wybrałyśmy się na afterowego browara.
W sobotę odbyła się łódzka konferencja GET.NET (o czym jeszcze napiszę), w trakcie której tuż przed moją, odbyła się prezentacja Procenta o Dependency Injection. Samo wystąpienie było świetne, a moją ciekawość podsyciła dodatkowo obietnica (powtórzona dwukrotnie) wyjaśnienia całego zamieszania wokół pojęć DI (Dependency Injecton i Inversion) oraz IoC. Jakie było moje rozczarowanie, gdy upragniony moment nadszedł, a Maciek skwitował wszystko zdaniem, że definicje nie są ważne.
Oj wkurzyłam się… Pomyślałam – naprawdę? Czy to, że ludzie mylą te pojęcia oznacza, że powinniśmy to olać i pozwolić, by żółć sączyła się z rany? Oczywiście zgadzam się z ogólnym stwierdzeniem, że w sumie nie ważna jest nomenklatura, byle dobre praktyki stosować, ale… czy na pewno tak jest do końca? Czy SRP pod inna nazwą równie by pachniała? Czy od teraz powinniśmy się komunikować opisując co dana zasada czy wzorzec robi, zamiast operować ich nazwami? Jakoś tego nie widzę, zajmowałoby to stanowczo za dużo czasu.
No to jak to jest z tym IoC i DI? Ano bardzo prosto, aż szkoda, że tyle przekłamań w internetach. Zacznijmy od ogółu.
IoC jest zasadą, która przeciwstawia się tradycyjnemu proceduralnemu podejściu do programowania. Polega na odwróceniu kontroli (tak, wiem, że rozumiecie ), w taki sposób, by miał ją zewnętrzny kod zamiast głównego flowu.
A oto obrazek przedstawiający ideę, zapożyczony z ok kolegi z fb, gdyż stwierdził (a ja się zgodziłam), że go tu brakuje.
W tradycyjnym podejściu nasz program wykonuje kroki, wywołując metody bibliotek, do których posiada on referencje. W podejściu IoC natomiast, to zewnętrzny software wywołuje nasz kod by wykonać pewne akcje. Relacje wtedy układają się zupełnie na odwrót. Dlatego zasada ta jest często żartobliwie nazywana regułą Hollywood: Don’t call us, we’ll call you.
Jest to więc bardzo szerokie pojęcie, dużo szersze niż wstrzykiwanie zależności, czy Service Locator. Przykładami z innej bajki są eventy, callbacki, czy zwykłe programowanie bazujące na interfejsach (np. wzorzec strategii).
Czyli wiemy już, że DI jest po prostu jedną z implementacji IoC. Wzorcem projektowym polegającym na tym, że przekazujemy (injection) zależność (dependency) do obiektu. Zależność staje się częścią stanu klienta (np. polem klasy lub jego property). Kluczową sprawą jest fakt jej przekazania, by nie pozwalać na tworzenie lub pozyskiwanie jej po stronie używającego obiektu.
A jak się ma do tego Dependency Inversion? Jest to jedna z zasad SOLID faworyzująca taką budowę modułów, by odwrócić zależności i wprowadzić jak najbardziej luźne powiązania między nimi. DI oraz Service Locator się do niej stosują. A brzmi ona następująco:
(Błędnie stosowana często prowadzi do tego, że po prostu wrzucamy na każdym poziomie interfejs, który jest implementowany przez dokładnie jeden moduł, ale to temat na zupełnie inny post.)
Mylić więc Dependency Injection i Dependency Inversion to całkiem normalna sprawa. Natomiast wrzucanie tego do jednego wora z IoC, to już lekkie nadużycie, bo wór ten jest o wiele obszerniejszy.
Jeśli zdarza się nam pracować z plikami .xaml i korzystamy z dobrobytu jakim jest bindowanie kod-widok (niezależnie od tego czy będzie to MVVM czy code behind), po pewnym czasie nadchodzi moment, gdy szlag nas trafia i musimy napisać po raz kolejny zamiast prostego ładnego property:
public class MyClass { public string MyProperty { get; set; } }
jakiegoś takiego potworka:
public class MyClass { public event PropertyChangedEventHandler PropertyChanged; string _myProperty; public string MyProperty { get { return _myProperty; } set { if (value != _myProperty) { _myProperty = value; OnPropertyChanged("MyProperty"); } } } public virtual void OnPropertyChanged(string propertyName) { var propertyChanged = PropertyChanged; if(propertyChanged != null) { propertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } }
Pojawiają się w naszej klasie: event, implementacja metody OnPropertyChanged, oraz jej wykorzystanie w setterach. Pomijam tu “smaczek” podawania nazwy w stringu. To i tak nie jest najgorsze co się nam może przydarzyć. Moglibyśmy mieć property, które odwołuje się do kilku innych. Wtedy musimy dodatkowo pamiętać, by OnPropertyChanged dla niego wykonać w setterach składowych.
Bleh…
Z pomocą przychodzi np. Fody. Jest to prosty pakiet, który należy ściągnąć (np. stąd, lub nugetem), zainstalować i nakazać projektowi, by go używał (Project > Fody > Enable). Dodatkowo, przyda się konfiguracja weavera. Jest na to kilka opcji, a tu już odsyłam do dokumentacji.
Ja akurat używam pliku .xml:
<?xml version="1.0" encoding="utf-8" ?> <Weavers> <PropertyChanged EventInvokerNames="raisePropertyChanged"/> </Weavers>
Dzięki temu nie muszę w swojej klasie ani w moim property robić nic poza czystym get i set. Moje ViewModele stają się zwykłymi klasami, bo chyba do tego zostały wymyślone.
Fody oczywiście sporo od siebie dodaje i kod przybiera inną formę. Nasza klasa zaczyna implementować interfejs, dostaje event, ma zaimplementowaną metodę OnPropertyChanged, a wszystkie property są poorane w przedstawiony wcześniej sposób, nawet te złożone z kilku innych. Ale czego oczy nie widzą, tego sercu nie żal
Po frekwencji na poszczególnych eventach, wnioskować można, że wiele osób wie, iż Base organizuje od czasu do czasu hackatony. Jednak zdziwienie przyszło ze środowiska .Net, najpierw z powodu tego, że Base w ogóle .Netem się bawi, potem, że wpadliśmy na pomysł zorganizowania Hack.KRK specjalnie dla programistów tej platformy.
Base kojarzy się raczej z Railsami. Choć wiele osób dopuszcza myśl, że jako firma wyznająca zasadę post PC, zatrudnia programistów systemów Android, czy iOS, to .Net nie jest nasuwającą się na myśl technologią. Wydarzenie było więc dobrą okazją by uświadomić brać programistyczną, że takowych programistów również mamy i potrzebujemy. 24.01.2014 odbył się więc pierwszy Hack.Krk .Net, którego gwiazdą i przyciągaczem tłumów miał być Procent. Informacje o evencie pojawiły się dość późno, ale i tak zebrał się niemały tłumek ludzi chętnych o gry w statki.
Z chłopakami wymyśliliśmy właśnie taką formę challengu. Wymyśliliśmy to raczej nadużycie – byliśmy na piwie w tej sprawie i gdy ja akurat wróciłam z toalety, dowiedziałam się, o pomyśle Kuby. Podobno miał go już dawno, czekał jedynie na nasz odpowiedni stan upojenia by go jednogłośnie przepchnąć.
Zaczęły się więc prace – głównie w trakcie okresu świątecznego. Koncepcyjnie pomysł przeszedł od fazy pojedynku do końcowej wersji – losowej planszy z określonymi wcześniej ilością i rodzajami statków, którą to mieli rozpracowywać gracze. Punktów dostawało się więcej jeśli zatopione zostały wszystkie statki przy jak najmniejszej liczbie ruchów. Dodatkowo brana była statystyka z kolejnych prób, by zminimalizować szczęśliwe trafy algorytmów losowych.
Przyszedł piątek i do Krakowa, w siedzibie Base pojawiło się sporo .Netowców. I nie tylko, bo zadanie zastali w formie API restowego, więc niemal każda technologia się nadawała. Wprowadzeniem była Randka z Nancy Procenta, a po niej nastąpił fight. Wszystko odbywało się w luźnej atmosferze przy towarzystwie browarów i dobrego jedzonka. Większość obecnych pilnie kodowała, ale było jedna grupa… ehm… moja, siadła w kącie i … kłapała zamiast programować.
Ok. 21:30 ruszyły zaplanowane wcześniej lightning talks. Roman mówił o stateless code, ja o tym jak wszyscy powinniśmy być architektami i jak świetnie jest w tej materii w Base, a Natalia i Jan namawiali nas do uczestniczenia w hack4good. Każdemu wyszło nieco dłużej niż błyskawicznie, ale to chyba niczemu nie szkodziło. Zaraz po wystąpieniu dostałam zaproszenie na wygłoszenie wersji rozszerzonej na wroc.net.
Cieszę się, że namówiłam Adriana by przyszedł (choć przyznaję, że bardzo się nie opierał), gdyż inaczej całe podium należałoby do Base’owców. A tak przynajmniej srebro zgarnął ktoś z zewnątrz. Dwa pierwsze miejsca nagrodzone zostały czołgami, które miały wziąć udział w pojedynku, ale… Adrian zepsuł baterie do swojego Pozostało nam więc oficjalnie zakończyć wieczór.
Dla mnie zdarzenie to było okazją by zaprosić kilku znajomych do Krakowa i spędzić wspólnie weekend. Ponieważ uwielbiam mieszkać sama, bo jestem silna niezależną kobietą , na co dzień nie do końca trawię gości. Albo inaczej – śmiało mogę powiedzieć, że za nimi nie przepadam. Coś mnie jednak podkusiło i postanowiłam przełamać to w sobie, przynajmniej na ten jeden weekend. I nie było łatwo.
3 osoby w piątek i 4 w sobotę, to coś co można określić jako zupełne przeciwieństwo mojego dotychczasowego aspargera i aspołeczności. Ale dało się. Pomimo trudności, tego, że po mroźnej nocy nie zapaliło mi auto, że musiałam łózko dzielić z koleżanką i skazać dwóch gości na nocleg na podłodze. Zaliczyliśmy wspólnie Schindlera, hamburgery, wieczorne winko i towarzyszące temu dyskusje.
W niedzielę byłam bardzo zmęczona towarzystwem, ale również zadowolona, że udało mi się spędzić trochę czasu z ludźmi, których lubię. A Maciek suma summarum okazał się gwiazdą TV.
Gdy zaczynałam swoją przygodę z programowaniem w Windows Phone (jakoś w maju zeszłego roku) okazało się, że to nie jest po prostu kolejny rodzaj projektu w Visual Studio. A szkoda, bo samo rozpoczęcie pracy, czy przeglądnięcie kodu, który zastałam w nowej pracy, wymagało wielu instalacji. Jasne, że wiele z nich dotyczyło konkretnych bibliotek użytych w projekcie, jednak kilka ruchów było niezbędnych, by w ogóle zacząć pracę z platformą. Postanowiłam opisać dla potomności te moje pierwsze kroki, a nuż ktoś skorzysta z opcji #lazyweb.
By zacząć programować na WP8 (dla WP7 wymagania są mniejsze) potrzebne nam są przynajmniej :
Tak jest na początek – samo SDK instaluje nam:
Tuta mała notka – emulator wymaga Hyper-V, więc jeśli chcemy go używać, wersja Windows powinna być przynajmniej przynajmniej Pro. Ale o samym Hyper-V za chwilę.
No i teoretycznie można zaczynać programowanie.
Tutoriali do WP jest całe mnóstwo. Nie ma sensu bym się powtarzała. Powiem tylko, że po instalacji SDK w VS pojawia się cała sekcja Windows Phone, można wybrać jeden z kilku rodzajów projektów i zacząć programować. Fazy budowy aplikacji przedstawię w kilku kolejnych wpisach.
Gdy już stworzymy jakąś funkcjonalność lub jeśli chcemy sprawdzić jak działa szablonowy projekt, to trzeba go jakoś uruchomić. Tutaj mamy dwa wyjścia – emulator lub telefon.
Aby użyć emulatora potrzebujemy Hyper-V, które wymaga pewnych ustawień w BIOSie, DHCP, 4GB RAM i tego, by użytkownik należał do grupy Hyper-V Administrators. Tak naprawdę tych wymagań jest trochę więcej (odsyłam tutaj), ale widocznie miałam (tym razem) ogromne szczęście i mój lapek je wszystkie spełniał, nie musiałam więc nic dodatkowo konfigurować.
A jednak nie polecam zbytnio pracy na emulatorze. Jest wolny w działaniu (maaasaaaaakryyyycznieeee, chociaż, to się poprawiać pewnie będzie), bardzo wolno się uruchamia i nie zawsze zgodny z tym jak aplikacja zachowuje się na telefonie (chociaż tych różnic jest naprawdę niewiele). Dodatkowo, jeśli sobie go wyłączymy (np. przez przypadek, jak mi się często zdarzało), a nasza appka ma bazę danych, byliśmy do niej zalogowani, czy jej start trochę zajmuje, to przy kolejnym uruchomieniu emulatora musimy poczekać na to, aż on sam się rozkręci, aż nasza aplikacja wystartuje, trzeba się będzie zalogować oraz stracimy wszystkie zcachowane dane (również te z bazy danych).
Jakie w takim razie mamy wyjście? Słuchawkę 🙂 Podpinamy ją kabelkiem i uruchamiamy aplikacje na telefonie. Działa to trochę wolniej w trybie debuggowania (jednak to normalne), natomiast aplikacja zachowywać się będzie tak jak w rzeczywistości. Hola, hola, czy to takie proste? Tak, ale… Trzeba wykupić sobie konto developerskie i zarejestrować w nim telefon. Teraz to koszt ok 20$ rocznie i zapewniam, że jest warte nerwów, które można stracić przy walce z emulatorem.
Co z debuggowaniem? Tutaj nie ma nic szczególnego w stosunku do innych platform – możemy to robić zarówno na emulatorze jak i telefonie.
Miłego zaczynania!
W styczniu miałam dość gorący okres, więc moje Windows Phonowe tournee postanowiłam kontynuować w Krakowie, by już daleko nie jeździć. Drugi gig zaplanowałam więc 22 stycznia na 85. spotkaniu KGD.NET. Ogólnie rzecz biorąc… nie poszło mi za dobrze. Dlaczego? To za chwilę, bo najpierw zrelacjonuje wieczór.
Weszłam na styk, powiedziałam co wiedziałam (i parę dodatkowych rzeczy też) i z podkulonym ogonem zebrałam się z miejsca na widoku w bardziej ustronny kąt. Po przerwie publikę na szczęście przejął Paweł, który opowiadał o tym jak budować efektywne zespoły (tak Pawle, wiem, że polskie słowo nie oddaje tego co chciałeś przekazać ). Wskazał na znaczenie różnorodności członków zespołu i przedstawił jak w to wpasowują się kobiety i ich naturalne predyspozycje. Nie z wszystkim się zgadzałam, ale w przeciwieństwie do prelegenta nie stały za mną wyniki badań naukowych
Jak to często na spotkaniach KGD.NET bywa, punkt 21. przyszedł personel sprzątający, czego efektem było pospieszne losowanie nagród i zakończenie spotkania. After party odbyło się przy ciekawych smakach piwa i… cydru gruszkowego(?), a pod koniec pojawiły się nawet jakieś shoty. W gronie ograniczonym do 5 osób (organizatorzy, czyli Marta i Jarek, Szymon, Andrzej i ja), posiedzieliśmy do ok. północy poruszając dość szerokie spektrum tematów, choć w większości technologiczno-pracowych.
No a teraz… kilka wskazówek jak położyć wystąpienie publiczne
… dzień przed wystąpieniem. Tak było – we wtorek poprosiłam o informację zwrotną osoby, które były obecne na mojej prelekcji w Warszawie. Choć ogólna ocena była dobra i niemal każdy powtarzał, że mu się podobało, to… no cóż, mamy skłonność do skupiania się na negatywach. Zresztą na tym właśnie najbardziej mi zależało.
No i mi się dostało Nie, no trochę żartuję, ale spisałam sobie te uwagi i zaczęłam intensywnie myśleć jak tych samych błędów już nie popełnić, zwłaszcza, że miałam okazję sprawdzić to następnego dnia. Dość powiedzieć, że zabrałam się za mission impossible. Może gdybym wzięła na warsztat jedną rzecz, to miałoby to szanse powodzenia w tak krótkim czasie jakim była doba. A w tej sytuacji, zamiast prezentować, co chwilę przypominałam sobie moją listę niedostatków i szarpałam się chcąc wprowadzić implementację rozwiązania ad hoc.
Pomyślałam, jestem u siebie, więc wiele osób przychodzących na KGD znam. Kilku znajomych uprzedziło mnie o swojej obecności tego dnia (innych zobaczyłam na liście zapisanych osób). Wiedziałam, że pojawi się jeden kolega z pracy i jeden z moich studentów. Nie spodziewałam się jednak, że ok połowa audytorium, to będą znane twarze – z dawnych prac, z obecnej, ze studiów, z twittera, a także moi studenci. Można byłoby się spodziewać, że znajomi to dobre wsparcie, w końcu nie życzą źle i wybaczą potknięcia. A jednak – mój stres wzrósł niebotycznie. Tak jakby zwiększyło się we mnie poczucie odpowiedzialności – trochę mniej wstyd wyłożyć się przy obcych
Nie żeby to była jakaś wyjątkowa sytuacja w moim wydaniu. Ja się wszędzie spóźniam, chyba, że planuję, że będę godzinę wcześniej – wtedy istnieje pewna szansa na punktualność. No ale nie stało się tak tego dnia, kiedy to byłam starą dobrą spóźnialską Basią. Dodałam przez to stresu również organizatorom, bo wg planu występowałam pierwsza, Paweł pojawić się miał później. Publika, chyba nie do końca to zauważyła, ale mi przybyła cegiełka stresu i kilka siwych włosów.
To już była zupełna porażka… Wstyd mi do tej pory. Zamiast zwyczajnie, gdy do takiej sytuacji doszło stwierdzić: “Nie wiem, nie znam się, zarobiona jestem”, zaczynałam po prostu mleć ozorem. Tylko, że na moje nieszczęście, na sali było kilku ekspertów od WP, no i moje “mądrości” były szybko weryfikowane.
Dlaczego tak robiłam? Do dzisiaj nie wiem do końca. Chyba przejęłam się wnioskiem, który padł na początku autoprezentacji. Pracuję z WP już ok pól roku, więc powinnam występować z pozycji osoby bardziej doświadczonej niż początkujący programista tej platformy. A ponieważ zazwyczaj nie mam w naturze przyznawania się do poziomu advanced w jakiekolwiek dziedzinie (chyba, że mówimy o spaniu, oglądaniu seriali czy innych technikach marnowania czasu), więc… naprawdę nie wiem.
Czy też, jeśli już o tym mówimy, nie przetestować uruchomienia VS, emulatora, programu. Ale od początku. Aplikacja, która pokazuję łączy się z Twitterem, więc potrzebuje internetu. W siedzibie ABB (bo tam się spotkania odbywają) nie udostępniają wifi dla gości, umówiłam się więc z kolegą, że mi jej trochę pożyczy. Ponieważ byłam spóźniona, przetestowaliśmy to łebkach, no i oczywiście efekt tego był taki, że gdy chciałam wyświetlić listę tweetów, internet przestał działać. Potem do buntu maszyn dołączył emulator, uruchamiając się we wszystkich rozdzielczościach. W pewnym momencie rozłożyłam ręce, bo już nic się nie dało zrobić. Byłam wdzięczna losowi, że pozostało mi VS i miałam jak pozywać kod.
Pech, wiem, ale też rzecz, która tak naprawdę najmocniej z przedstawionych tutaj zadziałała na negatywny odbiór. Jak coś nie działa, cała prezentacja spada w głęboką przepaść laaaaame i jest jej bardzo ciężko się z niej wykaraskać.
Tak naprawdę nie wiem, czy było tak źle jak opisuję, bo większość feedbacku z tego wystąpienia brzmi: “Miałaś wyjątkowego pecha”. Czy to oznacza, że miała pecha, była klapa, więc trudno, let’s move on, czy miałam pecha, ale mimo to pokazałam coś wartościowego? Nie wiem. Osobiście mam nadzieję, że szala przechyla się w tę drugą opcję. A ja mam materiał do pracy na kolejne razy, z których pierwszy odbył się tydzień później we Wrocławiu. Ale to już w kolejnym odcinku…
O architekturze było już trochę, a potem jeszcze trochę, ale więcej teorii górnolotnych niż życiowych przykładów. Czas więc i na to. Przedstawiam dziś, przefiltrowaną przez architekturę właśnie, historię mojego życia.
Przygodę ze światem IT zaczęłam jakaś chwilę temu i przez to miałam okazję znaleźć się w różnych firmach, zespołach i rolach. Pracowałam zarówno w małej firmie, która dopiero od kilku lat istniała na rynku, jak i w międzynarodowej korporacji. Jak wiadomo, wiąże się to z doświadczeniem różnych środowisk, sposobów na organizację pracy, a co za tym idzie – podejść do architektury.
Zacząć pracować postanowiłam jeszcze w trakcie studiów. Dziś nie jest to nic nadzwyczajnego, ale taki sposób na życie dopiero się wtedy rodził. Zatrudniłam się w małej firmie i byłam tam może 30. osobą. Na tym etapie rozwoju, tworzyło ją kilka zespołów, z których każdy miał swojego kierownika-guru. Ja byłam Johnem Snow, nie wiedziałam więc nic. Bardzo chciałam uczestniczyć w budowie czegoś, co zobaczy rzeczywisty, płacący klient, ale przede wszystkim moim celem było nauczyć się jak najwięcej.
Decyzje architektoniczne podejmował oczywiście kierownik, co mi małemu żuczkowi bardzo odpowiadało. Byłam pełna zachwytu dla wiedzy starszych stażem kolegów i do głowy mi nie przyszło, że mogę choćby zaproponować jakieś rozwiązanie. Kończyło się więc na tym, że ktoś coś wymyślał, a ja to wykonywałam. Pełniłam więc rolę nieco bardziej zaawansowanej maszyny do pisania… w Visual Studio.
Off topic: Nie wiem jak dawałam sobie radę z pracą, domem, studiami (tak, tak, był jeszcze drugi kierunek). Chyba bezpiecznie jest powiedzieć, że sobie jej nie dawałam. O ile nabieranie doświadczenia to super motywator, by zacząć jak najwcześniej, to jednak dzisiaj stwierdzam, że nie do końca skóra warta była wyprawki.
Firma się rozrosła, moje kwalifikacje wzrosły i tak zaczęła się rodzić współpraca między członkami zespołu, wspólne szukanie rozwiązań, proponowanie zmian. Wciąż mieliśmy kierownika, który w wskazywał stronę w którą finalnie szliśmy, ale pojawiły się mniej lub bardziej indywidualne projekty. Było więc miejsce na pewną autonomię.
Zespoły były wzbogacane ludźmi o różnym doświadczeniu, powodowało to trochę tarć, ale najczęściej stanowiło pozytywne zjawisko. Poza jednym czynnikiem – odpowiedzialnością. Niewielu programistów miało podejście, w którym celem był projekt. Każdy raczej pilnował jedynie, czy na jego podwórku wszystko gra.
Architekturą zajmował się nasz kierownik, jako osoba o największym doświadczeniu. Jednak dochodziło mu wiele obowiązków administracyjno-zarządczych. Do mnie i kolegów dość szybko doszła świadomość tego, że architekt to nie stanowisko, lecz rola. Rola, z którą z jednej strony wiąże się duża odpowiedzialność, a z drugiej gruntowna wiedza. Zapragnęłam wtedy zostać architektem (jak już będę duża i mądra) i to właśnie wpisałam w swoim planie 3-letnim.
I… udało się. Urosłam, zmądrzałam i marzenia się ziściły. W efekcie razem z kolegą, poprowadziliśmy kilka projektów w roli architektów. Było po prostu cudownie, żyć nie umierać. Codzienny standup, pilnowanie czy wszyscy rozumieją DDD (nie rozumieli), czy szablon projektu się nie rozjeżdża (rozjeżdżał się), czy claimy działają tak jak powinny (nie działały).
Jak coś było nie po naszej myśli robiliśmy minę doświadczonych mędrców i dobrodusznie karciliśmy młody narybek programistów. I jeszcze raz … rysowaliśmy diagramy, przekazywaliśmy linki do przydatnych stron. Wszystko po to by projekt był robiony tak jak my chcemy… eeee tzn. tak jak powinien być robiony.
Dla mnie skończyło się na kompletnym oderwaniu od rzeczywistości. Wydawało mi się, że bardzo dobrze rozumiem projekt, ale straciłam kontakt z kodem i po pewnym czasie techniczne detale były dla mnie zwykłym bełkotem. Wtedy zrozumiałam, że stałam się modelowym architektem z ivory tower.
Nadszedł czas pokory, nabrałam dystansu do całej sprawy. Przeszłam też do innej firmy, gdzie miałam zamiar budować system i jego architekturę (tym razem) razem z innymi. A przede wszystkim chciałam znów programować, bo zrozumiałam, że bez tego modele są jedynie obrazkami.
Tyle, że… na miejscu już był architekt. I to taki pełną gębą – nie programujący i na dodatek daleko, w kontakcie głównie telefonicznym. Ogólnie bardzo fajny facet, ale niewiele już dla projektu robiący, gdyż to ja docelowo miałam przejąć system. Czułam jakbym zrobiła krok w tył, co samo w sobie nie było jakieś mega straszne. Ot jestem znów doświadczonym programistą, któremu mówi się co ma robić. Jak się postarałam, to miałam nawet własne poletko do zabawy, trochę odpowiedzialności… nie za dużo
Tak się więc trochę kisiłam. Kroplą goryczy przelewającą czarę okazała się dość niskopoziomowa decyzja architektoniczna – wybór ORMa i brak możliwości zakwestionowania tej decyzji. Well… wiem, że tak w korporacjach jest, nie powinnam się była dziwić. Dobrze, że mogłam to zmienić.
I tak… znów zmieniłam pracę. Tym razem zostałam kierownikiem działu. Brzmi dumnie, ale dział był niewielki – 10-osobowy. Teraz, postanowiłam, o architekturze decydować będą ludzie, nie nadworny decydent. Sama zajmę się uprawianiem servant leadership, a w wolnych chwilach, pomogę w programowaniu.
Tylko, że… mój zespół nie za bardzo chciał o czymkolwiek postanawiać. Może chodziło o to, że byli to ludzie niedoświadczeni i taka odpowiedzialność to było dla nich za dużo. A może przyzwyczajeni byli do modelu słuchania i nie spodziewali się, że może istnieć inny. Suma summarum, stwierdzili, że finalne decyzje należą do mnie, bo w końcu jestem szefem i za to mi płacą. Chcąc nie chcąc zostałam Wielkim Architektem.
Trochę miałam już tego dość, a przede wszystkim szukałam miejsca, gdzie pracuje się inaczej. Nie zrozumcie mnie źle, wiem każda firma ma swoją kulturę organizacyjną. Zdaję sobie sprawę z roli odgórnych decyzji. Wiem też, że nie każdy gotowy jest na przyjęcie odpowiedzialności z całym dobrodziejstwem inwentarza. Mi jednak to co miałam nie do końca wystarczało.
Teraz pracuję w startupie, gdzie widzę diametralną różnicę. Przede wszystkim – nie ma czegoś takiego jak odgórne decyzje dotyczące architektury, a jeśli już o tym mowa, to nie istnieją odgórne decyzje dotyczące kwestii technicznych. Każdą z nich poprzedza dyskusja i to nie tylko w gronie osób to w końcu implementujących, ale również całego zespołu, a nawet osób spoza.
Model jest prosty – jesteś częścią teamu, więc funkcjonujesz na takich samych prawach jak inni. A to wiąże się również z pewnymi obowiązkami. Udział i wkład każdego z nas staje się wymaganiem, a nie jedynie możliwością.
Nie mamy więc architektów, a raczej każdy z nas nim jest. I każdy powinien, bo nie zrezygnowanie z tej roli oznacza często zrzucenie z siebie odpowiedzialności. W zespole każdy z nas architekturę zna, rozumie, buduje wg niej i jest za nią odpowiedzialny.
KONIEC!
aplikacje mobine architektura aspołeczność blog community craft conf feedback hackaton konferencje networking odpowiedzialność podejmowanie decyzji prelekcje proces tworzenia oprogramowania relacja sql Windows Phone WiT
WP Cumulus Flash tag cloud by Roy Tanck requires Flash Player 9 or better.