Category Archives: Uncategorized

Focus i bindowanie w Windows Phone

Posted in Uncategorized by

Pewnie starzy wyjadacze Windows Phone’owi problem znają, a nawet zapomnieli, że istnieje, ale mi się od czasu do czasu odbija czkawką, gdy próbuję zbudować nową aplikację. Chodzi mianowicie o następującą sytuację.

Budujemy aplikację, mamy w niej stronę, a na stronie kontrolkę z bindingiem. Niech będzie to TextBox.

<TextBox Text="{Binding MyText, Mode=TwoWay}" />

Jak widać nasz TextBox jest związany z polem MyText. Oznacza to, że jeśli w kontrolce wpiszemy jakąś wartość tekstowa powinna ona wylądować w polu MyText.

Nasza aplikacja może wyglądać np. tak:

Binding

Dodam, że pod przycisk w AppBar podpięte jest jakieś zachowanie, które wykorzystuje wartość wpisywaną do pola tekstowego. A jednak gdy wpiszę coś do kontrolki i spróbuję użyć tej wartości w metodzie, to widzę, że MyText jest nullem. Czyli pole się nie zaktualizowało.

image

Po długich rozkminach i czytaniu internetów, w końcu doszłam do wniosku, że nie jest to moja wina. Chodzi mianowicie o to, że bindingi się nie aktualizują, jeśli wciąż na kontrolce jest focus. Co więcej, kod zadziała jeśli najpierw wpiszę tekst, potem tapnę gdzieś poza pole tekstowe (aby stracił focus), to nagle property jest wypełnione.

image

Rozwiązanie jest proste, trzeba podpiąć zdarzenie Click pod AppBarButton, by znalazł naszą kontrolkę (w tym wypadku TextBox), zaktualizował binding i ustawił focus na stronie głównej:

private void ApplicationBarIconButton_OnClick(object sender, EventArgs e)  
{
    var focusedElement = FocusManager.GetFocusedElement() as TextBox;

    if (focusedElement != null)
    {
         var binding = focusedElement.GetBindingExpression(TextBox.TextProperty);
         if (null != binding)
             binding.UpdateSource();
    }
    Focus();

    // do something with MyText value
}

Tylko ja się po raz kolejny na tej platformie pytam… why? Dlaczego muszę to robić sama…? I to dla każdej kontrolki, dla każdego AppBar… Dlaczego to nie jest coś out of the box?

Does great power come with great responsibility? vol. 1

Posted in Uncategorized by

… parafrazując słowa Bena Parkera, wujka Spidermana (wiem, że dla niektórych to żenada tego nie wiedzieć, lecz mimo to wyjaśniam)…

Temat wyszedł z moich refleksji o architekturze oprogramowania, więc postanowiłam zrobić z niego prezentację, którą przedstawiłam po raz pierwszy w Białymstoku na grupie .Net. Wiele wątków, które tu umieszczę pochodzi od słuchaczy, post będzie więc kumulacją naszych wspólnych przemyśleń.

O co więc chodzi z tą władzą i odpowiedzialnością? Zacznę od tego, że każdy z nasz developerów chce lub kiedyś chciał zostać architektem (ew. managerem, ale nie o tym odłamie programistów chcę teraz pisać). Jeśli nigdy nie chciałeś i nie chcesz, to podejrzewam, że jesteś na początku swej drogi i wizja ciebie jako architekta jawi ci się jako cos jeszcze zbyt nieosiągalnego.

Otóż jest taki moment w życiu programisty, w którym ktoś obdarza nas i nasze kompetencje zaufaniem. Powierza nam odpowiedzialność w postaci decyzji architektonicznej. Możemy mieć wpływ na kształt projektu, być może tylko na wybór frameworka, a jednak w efekcie uderza nad woda sodowa do głowy. Teraz, myślimy, pokażemy wszystkim jak to się robi dobrze…

Architektura?

Ale zanim o rządach, to może słów kilka o tym, czym właściwie jest architektura. Jak się pogógla, to znajdziemy tysiąc definicji i perspektyw na zjawisko. Dla jednych to fizyczne komponenty systemu – serwery, szyny, chmury, dla innych podział systemu na warstwy, dla jeszcze innych pewne niefunkcjonalne wymagania, jak bezpieczeństwo czy niezawodność.

Z jedną rzeczą wszystkie te strony zazwyczaj się zgadzają – architektura, niezależnie od obecności pilnującej jej osoby – zawsze jest. Na domiar złego, to że nie jest nadzorowana, może doprowadzić do kłopotów. Makaronowy kod to najmniejsza z konsekwencji. Architektura dotyczy takich zagadnień jak niezawodność, bezpieczeństwo czy skalowalność. Polega na nadaniu kierunku implementacji systemu i komunikowaniu tego kierunku wszystkim osobom zaangażowanym w realizację. Architektura to fundamenty, wysokopoziomowe, trudne do zmiany w późniejszych etapach decyzje. Albo … jak podsunął mi jeden ze słuchaczy z Białegostoku: decyzje, które pozwolą reszcie zespołu na łatwiejsze rozwiązywanie problemów w przyszłości.

Po co?

Po co w ogóle zajmować się architekturą? Ano po to, by popatrzeć się na system pod kilkoma kątami. A w każdym z nich chodzi o jakość. Tylko cóż to jest ta jakość? Pominę tym razem internety i powiem nieco asekurancko – to zależy. Zależy m. in. od tego, kto tej jakości wymaga. Jeśli pod uwagę weźmiemy projekt systemu, ważne okażą się takie cechy jak integralność, reużywalność i utrzymywalność. Rozważając działanie trzeba pomyśleć o dostępności, wydajności, niezawodności, skalowalności czy bezpieczeństwie. Wdrożeniowców z pewnością zaciekawi łatwość serwisowania, czy testowalność. Dla użytkowników jakość to przede wszystkim użyteczność systemu, szeroko rozumiane UX.

O czym należy pamiętać budując architekturę? Przede wszystkim o tym, że nie jest ona tworzona raz, tak jak i całe oprogramowanie. Musi być zmieniana i musi być tak budowana by zmiany w łatwy sposób umożliwiać. Po drugie należy się skupić zarówno na modelach (które są uproszczeniem rzeczywistości) jak i kodzie (by w tych chmurach nie pozostać). Po trzecie należy wszystkie te decyzje komunikować, bo model, nawet najlepszy, jeśli nie zostanie przekazany, to nie zostanie użyty. Po czwarte i ostatnie, projekt powinien koncentrować się na kluczowych decyzjach, nie da się zamodelować wszystkiego, bo wtedy model przestaje być modelem, a staje się implementacją.

Jak się ocenia architekturę?

Jest kilka metod tzw. formalnych, które pozwalają na ocenę tego, czy nasz architekt dobrze wykonał swoją robotę. Takie metody jak ATAM, SAAM czy ARID polegają z grubsza na analizie scenariuszy. Pierwszą rzeczą jaką należy zrobić jest stworzenie tych scenariuszy i nadanie im wag/punktów/priorytetów. Ten etap sam w sobie jest wartościowy dla projektu, gdyż efektem są wymagania systemu.

W SAAM oceniane jest to, czy scenariusz jest możliwy do zaimplementowania w danej architekturze systemu bez wysiłku. Jeśli tak nie jest, to pytanie brzmi ile komponentów należy zmienić by to osiągnąć i jak trudne to będzie. ATAM bazuje na atrybutach powiązanych z danym scenariuszem. Rozważa się takie aspekty jak wydajność, czy bezpieczeństwo i określa się tzw. sensibility points, czyli punkty istotne z punktu widzenia tych aspektów. ARID z grubsza polega na zabawie jak za pomocą danej architektury zrealizować dany scenariusz i czy jest on w ogóle wykonalny.

Z mojego doświadczenia wynika jednak, iż architektura oceniana jest głównie “na oko” i na dodatek subiektywnie. Istnieje zbiór dobrych praktyk, które gdy się je stosuje, pozwalają nam, z w miarę wysokim prawdopodobieństwem, założyć, że architektura powstałej aplikacji jest dobra. Niekoniecznie trzeba podążać sformalizowanym procesem, żeby to zauważyć. Najważniejsze zwykle jest zdanie interesariuszy projektu, którym jest każdy kto ma jakikolwiek związek z budowaną aplikacją – klient, PM, developer, architekt, tester, gość od platformy systemowej czy deploymentu, oficer bezpieczeństwa. Każdy z nich ma swoją perspektywę i swoje priorytety. Architektura jest dobra jeśli żadnego z nich nie uwiera.

Rola architekta

Małymi kroczkami doszliśmy do naszego architekta. Osoby, która analizuje, projektuje i decyduje. Od której oczekuje się, że pokaże kierunek implementacji i przypilnuje, by był on utrzymywany. Aby jego działania były skuteczne, architekt powinien być elastyczny i komunikatywny. Do jego obowiązków należy weryfikowanie i ocenianie implementacji pod kątem realizacji architektury, a także rozwiązywanie pojawiających się w związku z nią problemów. Dodatkowo dochodzi tu kwestia planowania przyszłych kroków implementacji i zarządzania ryzykiem.

Aby wszystkie te działania miały miejsce, a przede wszystkim by zostały zaakceptowane przez zespół, na architekta wybiera się zazwyczaj osobę z dużym doświadczeniem i wiedzą. No i stąd ta kwestia władzy – jeśli mianujemy kogoś architektem, od razu stawiamy go na piedestale. Dając mu w ręce tyle odpowiedzialności, naturalnym odruchem jest myślenie, że wiąże się z tym decyzyjność.

Z premedytacją użyłam słowa rola, a nie stanowisko. Myśl/i rozwinę w przyszłych postach, w różnych ujęciach takich jak style podejmowania decyzji, dojrzałość zespołu, czy moje własne doświadczenia związane z architektami.

Białystok .Net i Basia

Posted in Uncategorized by

Kolejny tydzień, więc czas na opis kolejnego zeszłorocznego wystąpienia. Również wschód, ale bardziej na północy. No i tym razem bardziej technicznie, bo w tematyce około .Netowej.

4 grudnia, notabene, w dniu moich imienin, wystąpiłam w Białymstoku na spotkaniu tamtejszej Grupy .Net. Ponieważ z Krakowa daleka jest droga do stolicy Podlasia, podróż zajęła mi jakieś 2 dni. Nie narzekam jednak, bo ostatnio okazało się, że bardzo lubię podróżować, zwłaszcza pociągami, gdzie mam czas spokojnie pomyśleć i popracować, tylko internetu czasem brak (tak, wiem wiem, muszę zmienić operatora Uśmiech). Obecny post także w tym środku transportu powstaje.

Oprócz mnie prezentację miał mieć także Leszek Kwaśniewski, lider warszawskiej grupy SQL Server, do niedawna trener i specjalista od baz danych. Spotkaliśmy się wtedy w pociągu w Warszawie, gdzie dość gładko wprowadził mnie w tajniki SQL Server 2014, a jednocześnie części treści swojego wystąpienia. I dobrze, bo jestem tuman jeśli chodzi o bazy danych i być może właśnie dzięki tym korkom zrozumiałam, o czym później mówił.

Dojechaliśmy na miejsce, z dworca odebrał nas Marcin Iwanowski, szef Białostockiej grupy .Net. Gdy już znaleźliśmy się w sali, gdzie miało odbyć się spotkanie, byłam pełna obaw, czy te kilka osób, które tam zastaliśmy, to całe audytorium. Na szczęście okazało się, że jestem jak zwykle panikarą. Punktualnie o godzinie zero, sala była pełna ludzi, a kolejni napływali.

Nie do końca rozumiałam dobór tematyki około sqlowej, jeśli chodzi o grupę developerów, ale powstrzymałam się od uwag. Stwierdziłam, że przecież to może być jedynie moje zdanie. No i oczywiście potem okazało się, że na widowni oprócz programistów byli także administratorzy. Leszek zrobił, nazwane przez niego twardym, wprowadzenie, abym ja mogła wejść później, znów jego nomenklatura, bardziej na miękko. Opowiadał o ficzerach nowego (lub o ile dobrze pamiętam jeszcze wtedy przyszłościowego) Sql Server 2014. Było coś o indeksach kolumnowych, cenach i…? Hmm… Najważniejsze, że wtedy rozumiałam Uśmiech

Potem przyszła kolej na mnie. Temat by mniej techniczny, gdyż opowiadałam o architekturze. O moim jej rozumieniu kiedyś i obecnie. O swoich doświadczeniach i marzeniach by architektem zostać. Ponieważ przez 10 lat pracowałam w kilku firmach i wieeeeelu zespołach, miałam okazję spojrzeć na te kwestie z różnych punktów widzenia. Po pierwsze, chciałam je więc przedstawić, ale po drugie i najważniejsze, dowiedzieć się, co na ten temat myślą inni.

Grupa, choć na początku obawiałam się, że nierozruszana, okazała się bardzo responsywna. Albo temat, albo moje kontrowersyjne tezy, wywołały bardzo ciekawą dyskusję, która ciągnęła się nawet po zakończeniu prezentacji, już przy piwie i kanapkach. Dostałam nawet feedback, że dawno tak nikt ich nie zaktywizował. No i najlepsze – pamiętali o moich imieninach <3. Dostałam nawet prezent Uśmiech.

Afterparty  było dość grzeczne i skutecznie trzymało się tematów branżowych. Nie żebym była zaskoczona, skoro odbywało się w pokoju obok Uśmiech. Omawialiśmy oprócz architektury, o kwestiach związanych z zawodem programisty, edukacją w IT oraz kolejnymi wystąpieniami. Nadszedł jednak czas, kiedy ja i moi gospodarze zdecydowaliśmy się wyjść, głównie po to, by zdążyć posilić się czymś smaczniejszym niż kanapki i mocniejszym niż piwo.

Joanna i Procent zabrali mnie do jakiejś knajpy (było ciemno i daleko od domu, więc nawet po groźbą rozstrzelania, nie trafiłabym tam po raz drugi), w której zjedliśmy pyszne podpłomyki, wypiliśmy śliwkowe piwo przerywane wściekłymi psami i porozmawialiśmy na wiele interesujących tematów. Wieczór był długi i ciągnął się jeszcze w zaciszu domowym, a rano uwieńczony został dodatkowo leniwym śniadaniem “na mieście” Uśmiech, po którym szczęśliwie wróciłam do domu. Procentom dziękuję za super gościnę!

ABC aplikacji mobilnych

Posted in Uncategorized by

Jak już ostatnio pisałam, będąc w Rzeszowie, opowiadałam o tworzeniu aplikacji mobilnych. Skupiłam się głównie na synchronizacji danych, ale wspomniałam również o kilku innych cechach, które odróżniają je od np. webowych, czy desktopowych. Tematyka może być niezbyt odkrywcza dla kogoś, kto pracuje z aplikacjami mobilnymi, ale gdy ja po raz pierwszy siadłam do komputera, by zostać developerem Windows Phone, zupełnie nie wiedziałam z czym to się je. Myślałam, że zwyczajnie siądę do Visual Studio, otworzę projekt stworzony w specyficznym szablonie i… zacznę programować.

Okazało się, że to nie takie proste, nie tylko dlatego, że zanim cokolwiek dało się zrobić musiałam zainstalować tysiące rzeczy, ale również ze względu na fakt, iż nie jest to zwykła aplikacja warstwowa. Więc jaka? Z grubsza aplikacje mobilne można podzielić na dwa rodzaje – natywne i webowe.

Aplikacja webowa, czy też responsive desing, to tak naprawdę strona internetowa zaprojektowana dla mniejszego ekranu. Aplikacja natywna z kolei, to taka, która jest ściągana i instalowana na urządzeniu. Którą wybrać i kiedy używać? Jak zwykle – to zależy… Wybrałam kilka aspektów, które przedstawiłam podczas spotkania, ale oczywiście jest ich o wiele więcej.

Wieloplatformowość

Jeśli planujemy działanie naszej aplikacji na wielu platformach (albo choćby na dwóch), to mniejszego nakładu pracy będzie wymagało stworzenie wersji webowej. Dzisiaj jedynie niewielka ilość działa tylko na jednym systemie. Głównie z uwagi na to, by nie skazywać użytkowników na  kupno odpowiedniego sprzętu, albo nie skazywać nas na klęskę rynkową, bo użytkownicy raczej nie kupią odpowiednich telefonów tylko dla naszej aplikacji. Poza tym dostęp do funkcjonalności z różnych źródeł może być cechą bardzo pożądaną ze względu na UX. W przypadku aplikacji natywnych, każda platforma to tak naprawdę odrębne środowisko i wymagać będzie adekwatnych umiejętności developerskim. To może oznaczać, że będziemy potrzebowali wiedzy na temat każdej z platform i zapewne również różnych ludzi, którzy tę wiedzę posiadają.

Wykorzystywanie funkcji smartfonów

Czy twoja aplikacja będzie używać funkcjonalności specyficznych dla urządzenia? Będzie dzwonić, wysyłać smsy, robić zdjęcia? Chociaż aplikacje webowe rozwijają się w kierunku wykorzystania coraz większej ilości funkcjonalności telefonów wciąż, jeśli bardzo chcesz na nich polegać – wybierz aplikacje natywną.

Personalizacja

Jedną z największych zalet aplikacji mobilnych jest możliwość użycia personalizacji urządzenia przy jak najmniejszych ograniczeniach. Ponieważ aplikacje natywne są ściśle związane z urządzeniem, pozwalają na lepsze wykorzystanie ich możliwości.

Praca offline

Jasne jest, że jeśli mamy mieć możliwość pracy offline, to nie ma wyboru – należy zdecydować się na aplikację natywną. Ale po co w ogóle pracować bez sieci? Czy dzisiaj w ogóle istnieje taka potrzeba? No cóż, pewnie są takie miejsca na świecie, gdzie odpowiedź jest negatywna, ale gdy myślę o moich niedawnych podróżach z Krakowa do Warszawy, kiedy to przez jakieś 60-80% czasu nie miałam zasięgu, to niestety muszę przyznać, że tak.

Więc kiedy potrzebujemy takiej formy pracy? Niestety jeszcze przez jakiś czas nie tylko w lesie czy w samolocie. Oczywiście nikt nie wyobraża sobie “pracy” z facebookiem w trybie offline, ale jeśli myślimy o aplikacjach, do których wprowadzane są dane (np. Evernote), to uniemożliwianie pracy użytkownikowi, bo jest on odcięty od sieci, nie wydaje się sensowne. Miejmy nadzieję, że to się niedługo zmieni, wi-fi będzie praktycznie wszędzie, a tam gdzie jej nie zaznamy, poratuje nas XG/LTE czy jakiś następca. Ale póki co, jeśli chcemy pracować z przesyłem dużej ilości danych, to wielu z nas wybrałoby opcję, by działał jedynie gdy mamy internet.

Czego więc potrzebuje aplikacja działająca offline? Przede wszystkim lokalnej bazy danych. Bazy która najczęściej jest spersonalizowana – zawiera jedynie dane dla konkretnego użytkownika, więc nie jest to kopia bazy globalnej.

offlineapp

A teraz najlepsze – siedzimy sobie w lesie, pracujemy nad naszym zbiorem danych i wszystko jest fajnie dopóki… jesteśmy offline. Bo jeśli chcemy z tych danych skorzystać na innym urządzeniu, to potrzebna będzie synchronizacja.

Jak ona się odbywa? Po pierwsze nasza aplikacja mobilna pobiera dane, których brakuje w stosunku do tego co jest w globalnej bazie danych. Można to zrobić np. używając timestampów. Po drugie do bazy globalnej należy wysłać lokalne zmiany wprowadzone na urządzeniu. W najprostszym przypadku rozpatrywanymi zmianami są utworzenie, usunięcie i zmiana stanu obiektów.

I tu pojawić się mogą konflikty. Na przykład skąd wiadomo które dane mają być zaakceptowane jako finalne? Te z serwera, czy lokalne? Można odpowiedzieć, że te które są nowsze, ale co jeśli zmiany w tym samym obiekcie zostały wprowadzone równolegle, na dwóch różnych urządzeniach? Które powinny zostać uznane za ostateczne, skoro zostały wprowadzone na podstawie stanu bazy globalnej?

W przypadku dodawania nowych obiektów częstą praktyką jest użycie lokalnych identyfikatorów na urządzeniach mobilnych. W trakcie synchronizacji, obiekty takie są rozpoznawane jako nowe, dodane do globalnej bazy danych, gdzie nadawane jest im globalne id. I tu pojawia się kolejny aspekt, który powinien być obsłużony w trakcie synchronizacji, czyli relacje między obiektami. Jeśli np. dodajemy nowy obiekt i obiekt z nim powiązany, to skąd wiadomo na którym id bazuje ta relacja? I co się stanie gdy połączymy nowy obiekt z już istniejącym? Jak serwer czy nawet nasza logika sobie z tym poradzi?

Aktualizacje

Aktualizacje są zawsze bardziej bolesne w przypadku aplikacji natywnych, dla których należy je wprowadzić na wszystkich platformach. Dodając do tego kwestie bazy danych, dochodzi tutaj wzięcie pod uwagę jej aktualizacji. Każda nowa wersja oprogramowania może skutkować zmianami w schemacie danych i potrzebą dostosowania lokalnych baz do globalnej. Jeśli więc planujesz częste update’y, lepiej to robić w responsive design, bo wiąże się to ze zmianą aplikacji i bazy tylko w jednym miejscu.

Podsumowując – łatwiej jest zbudować aplikację webową, natomiast jeśli chcemy stworzyć coś poważniejszego, nie obejdzie się bez aplikacji natywnych.

Rzeszów, Karotki i aplikacje mobilne

Posted in Uncategorized by

Jak już wcześniej wspomniałam 18. października odbyło się 3. spotkanie rzeszowskich Karotek. Tematem wiodącym miały być aplikacje mobilne i kwestie z tym związane, co w tym konkretnym przypadku sprowadziło się do dwóch aspektów: marketingu mobilnego i architektury. Ale to za chwilę…

Tamten piątek był dla mnie bardzo trudny. Za sobą miałam intensywny dzień, w nocy prawie nie spałam, a w perspektywie pozostawała podróż do Rzeszowa, stres prezentacji i kolejny długi wieczór. Każdy kto mnie zna, wie, że byłam o krok od znalezienia mniej lub bardziej wiarygodnej wymówki i pozostania cały dzień w łóżku by odespać wszystko co mnie już spotkało i co jeszcze miało mnie czekać. A jednak, zebrałam się i po południu zawitałam do stolicy województwa podkarpackiego.

Na szczęście spotkałam tam Olgę, organizatorkę GGC w Rzeszowie, która swoim entuzjazmem potrafi zarazić nawet taką marudę jak ja. Zorganizowała wszystko tak, iż mimo zmęczenia wykrzesałam nie tylko trochę, ale nawet całkiem sporo energii.

Pierwsze prezentację przeprowadziła Monika Mikowska – oczywiście w szpilkach z gigantycznym obcasem Uśmiech Monika ma niesamowitą wiedzę na temat marketingu mobilnego. Dowiedziałam się o wielu, mniej lub bardziej spełniających swoją funkcję, aplikacjach dostępnych w na różnych platformach. Jedna z nich (wg prelegentki jedna z tych mniej sensownych) mi osobiście bardzo się spodobała. Po raz kolejny przekonałam się jak seks dobrze się sprzedaje. Niestety nie ma jej na WP…

Moje wystąpienie miało dotyczyć budowy aplikacji mobilnych. Miałam pewien kłopot związany ze stopniem techniczności. Nie znałam backgroundu audytorium i nie wiedziałam na ile mogę poszaleć i jak nisko zejść. Przedyskutowałam to wcześniej z Olgą i postanowiłyśmy, że przedstawię słuchaczom szersze kulisy pracy programistycznej.

W efekcie zdecydowałam się na opis architektury aplikacji mobilnych. Skupiłam się na tych działających w trybie offline, bo responsive design z tej perspektywy sprowadza się do aplikacji webowej tyle, że na telefonie/tablecie. Aplikacje, które mogą działać gdy nie ma internetu, wprowadzają za to pewien ciekawy aspekt – synchronizację danych.

I o tym właśnie opowiadałam. Wciąż nie byłam pewna jaki poziom szczegółowości zapewni zrozumienie zarówno tego co ja mowie jak i złożoności samego tematu. Postanowiłam skupić się na nakreśleniu kilku kwestii, jakie należy rozważyć przy projektowaniu synchronizacji danych, w tym na obsłudze konfliktów. Opisałam jak się przechowuje dane w relacyjnej bazie danych i okrzyknięta zostałam ID girl. Podobno mówiłam zrozumiale, więc uważam to za swój wielki sukces Uśmiech Więcej o samej zawartości merytorycznej opiszę (jak obiecałam) w osobnym poście.

Sama organizacja wydarzenia miała dość kameralną atmosferę. Pochodzę z okolic Rzeszowa i miło było poczuć podkarpacką atmosferę. Żeby tego było mało, uraczeni zostaliśmy pysznym ciastem marchewkowym.

Po naszych prelekcjach nadszedł czas na postintelektualne pifffko. Miałam okazję zobaczyć piękny rzeszowski rynek i zjeść pyszny vyprazany syr (wybaczcie mnie puryści językowo ortograficzni). Monika co prawda miała lekki kłopot przy chodzeniu po kocich łbach, ale dała radę.

Wspomniałam, że dzień był ciężki dla mnie z powodu niewyspania. A ponieważ sen (a zwłaszcza jego brak) to dla mnie kwestia może nie życiowa, ale wpływająca na samopoczucie, poważnie obawiałam się o swój stan dnia następnego. Szczególnie, że znów położyłam się późno. Na szczęście Olga i jej współlokatorka okazały się na tyle gościnne i wyrozumiałe, by nie budzić mnie do 11. Naładowałam akumulatory i następnego dnia z humorem wróciłam do domu. Dzięki dziewczyny!

Żółta kaczka i efekt terapeutyczny

Posted in Uncategorized by

Zbierałam się z założeniem tego bloga już … pewien czas.  Tak długi, że wstyd się przyznać. Właściwie miałam innego wcześniej, ale częstotliwość pojawiania się na nim wpisów była tak mała, że szkoda w ogóle o moim wkładzie wspominać. Tym razem, postanowiłam, będzie inaczej.

Punktem zwrotnym w tej kwestii był moment, gdy zmieniłam pracę, by zostać kierownikiem działu oprogramowania. Teraz, pomyślałam sobie, będę mieć tysiące tematów do opisywania: budowanie zespołu, decyzje architektoniczne, konkretne techniczne rozwiązania, radzenie sobie z konfliktami, które się najpewniej pojawią, rozwój kompetencji programistów… a to tylko kilka, które mi się pojawiły w tamtym momencie.

No ale ideały ideałami, a życie życiem 🙂 Tematy oczywiście się pojawiały i to wszelakiej maści, ale zawsze znajdzie się jakaś wymówka, by się za robotę nie zabrać. W tym roku miałam przecież jeszcze zacząć biegać, zdać kilka egzaminów M$, wystąpić na kilku konferencjach, czy przeczytać stos mądrych książek. Tym którzy mnie znają wiadomo co z tego wyszło, a tym którzy tej wiedzy nie mają łatwo się pewnie domyślić.

Temat na poważnie poruszyłam przy okazji rozmowy z Gosią. Opowiedziałam jej o moim głodzie pisania, a także o innych niespełnionych postanowieniach noworocznych :). Pożaliłam się, iż mimo moich doświadczeń, nie mam pomysłów na posty. Ku mojemu zdziwieniu, dostałam prostą radę, by napisać o tym co się u mnie aktualnie dzieje. Na przykład o moich wystąpieniach prelegenckich. Wtedy przyszło mi do głowy, że dobrym tematem będą nie tylko same eventy, ale także ich treść merytoryczna. Na koniec doszłyśmy do wniosku, że mogę nawet opisać obecnie trwającą rozmowę, co tez niniejszym czynię.

Gosia miała problem jakby z drugiej strony. Wpisy na blogu pojawiają się u niej dość regularnie, zastanawiała się jednak nad tematami wystąpień. Tutaj ja wkroczyłam do akcji, stwierdzając, że temat można zrobić z czegokolwiek (bo przecież wpisu na bloga to nie :)), ale najlepiej z tego, nad czym się aktualnie pracuje, zarówno technicznie jak i procesowo.

W efekcie obydwie spełniłyśmy dla siebie rolę żółtej kaczki, bo zwyczajnie potrzebowałyśmy się wygadać. No i dodatkowo ruszyć choć trochę z tematami, zmotywować się. Jak na kozetce u terapeuty :). Na dodatek każda z nas miała świetne rady dla drugiej, przy kompletnej blokadzie ze swojej strony. Mimo, iż problemy bardzo od siebie nie odbiegały.

Gosia szybko ogarnęła temat, mi natomiast zajęło to trochę czasu i striggerowane zostało groźbą publicznego linczu z jej strony w razie gdyby mój pierwszy post się nie pojawił… do końca tygodnia. Pozostała więc do spełnienia moja część umowy. Założenie bloga okazało się dziecinnie proste i niezbyt czasochłonne, mimo to chwilę leżał odłogiem. Aż do teraz…

No więc, jak commitment, to commitment. Idąc za radą, zobowiązuję się publicznie do opisu następujących wydarzeń (i zawartości merytorycznych):

Na następny rok mam póki co zaplanowane 4 wystąpienia:

  • Spotkanie Warszawskiej Grupy .Net (16.01.2014)
  • Women in Technology we Wrocławiu (28.01.2014)
  • Spotkanie Wrocławskiej Grupy .Net (18.03.2014)
  • ??? konferencja w Łodzi (12.04.2014)

Lista się, mam nadzieję, powiększy, więc we właściwym czasie pojawią się odpowiednie wpisy.

Jeśli drogi czytelniku dotarłeś aż tutaj, to dziękuję za poświęcony czas – na przyszłość postaram się o krótsze teksty.