DevTalk Menu

Uncategorized

Permalink:

14 – CQRS with Udi Dahan

(comments are closed)

udi-dahanPost po polsku poniżej / Polish version below


14th episode of DevTalk is a special one. First of all: this is the first episode in english! Second: my guest is a well-known, widely respected expert, the one and only Udi Dahan!

Udi is a creator of NServiceBus and founder of Particular Software. His thoughs about software architecture and best development practices – that often define the “industry standards” – can be found on a fascinating blog. Udi is one of the best-known speakers worldwide. He also offers advanced technical courses. Follow him on Twitter: @UdiDahan.

We talk about CQRS – Command Query Responsibility Segregation. Udi – together with Greg Young – was one of the first promoters and teachers of this approach to building complex software systems. BUT we do not discuss various CQRS implementation details. This conversation focuses on something that is often ignored by developers: what should we do to meet end users’ needs, not always putting our own desire to implement the “newest and shiniest” at the top of our priority list? And how can CQRS help us with that?


Odcinek 14 jest kolejnym odcinkiem wyjątkowym. Po pierwsze: bo to pierwszy odcinek po angielsku! A po drugie: bo mój gość to szanowany na całym świecie, znany wszem i wobec, niewymagający przedstawienia: the one and only Udi Dahan! Gdyby pół roku temu ktoś powiedział mi, że DevTalk wyjdzie poza granice Polski, i to od razu z Gościem tego kalibru, to bym się tylko w czoło popukał. A tu proszę…

Udi to twórca NServiceBusa – projektu, którego sukces spowodował założenie firmy Particular Software. Swoimi myślami odnośnie architektury oraz najlepszych praktyk programistycznych, definiującymi niejednokrotnie postrzeganie wielu zagadnień na całym świecie, dzieli się na fascynującym blogu. Jest jednym z najbardziej rozpoznawalnych prelegentów na największych światowych konferencjach. Prowadzi również szkolenia. Na Twitterze: @UdiDahan.

Tematem odcinka jest CQRS – Command Query Responsibility Segregation. Udi – wraz z Gregiem Youngiem – był jednym z pierwszych promotorów i nauczycieli tego podejścia do tworzenia oprogramowania. Nie wchodzimy jednak w szczegóły implementacyjne – w tym spotkaniu szkoda na to czasu! Ten temat pewnie jeszcze się pojawi w DevTalku w czysto technicznym kontekście, jednak z Udim rozmawiam z trochę ogólniejszej perspektywy. Udi tłumaczy dlaczego technologie i wzorce często nie są najważniejsze i na interesującym przykładzie pokazuje, jak wymagania biznesowe oraz modelowanie pomagają rozwiązać najtrudniejsze problemy. Programiści słysząc CQRS myślą od razu o klasach, szynach, cache itd, bardzo często pomijając kluczowy krok: refleksję nad źródłem i naturą rozwiązywanego problemu. Słuchając tego odcinka każdy dev zastanowi się pewnie: czy przypadkiem ja nie ignoruję faktycznych potrzeb użytkowników?

Bardzo zachęcam do posłuchania, bo taka okazja nie zdarza się co dzień.

Ten odcinek ma partnera specjalnego: firmę JIT Solutions z Gdyni. Gdybyście chcieli sprawdzić w praktyce jak m.in. NServiceBus jest wykorzystywany w dużym rozproszonym projekcie to macie okazję dołączyć do ich zespołu. Szczegóły znajdziecie na pracuj.pl lub bezpośrednio w tym PDF.

JIT_solutions

Konkurs: po raz drugi (wcześniej w odcinku o DDD) do rozdania mam “Implementing Domain-Driven Design” Vaughna Vernona. Poza anteną wprost spytałem Udiego jaką jedną książkę poleciłby programistom, a on wskazał na tę konkretną pozycję. Właśnie ją zatem wyślę do autora jednego z komentarzy pod tym postem. Jak zwykle apeluję: piszcie swoje uwagi! Zarówno do odcinka, jak i samej idei “importowania” gości z zagranicy :). Mi się pomysł podoba – i ciekawą znajomość można nawiązać, i po angielsku pogadać, i nowych słuchaczy przyciągnąć. Co Wy na to?

Czytaj dalej…

  • Szymon

    Super odcinek, świetny gość i temat. Bardzo podobało mi się to co powiedział Udi, aby CQRS traktować jako podejście, a nie tylko jako wzorzec! Myślę, że bardzo dobrze, że poszliście w rozmowie w tą stronę, zamiast omawiania CQRS jako wzorca. O tym można sobie przeczytać w mądrej literaturze albo internetach. 😉 Domena, która pojawiała się w przykładach jest mi bliska i mam dzięki trochę świeższe spojrzenie na projekt, przy którym pracuję. Dzięki!

  • Maciej Aniserowicz

    Dzięki wszystkim za miłe słowa.
    Książka wędruje do Marcina, mail z prośbą o adres już wysłany.

  • pokaż wszystkie komentarze (20)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

13 – O agile z Grzegorzem Rycajem

(comments are closed)

grzegorz-rycajSzczęśliwy, trzynasty, odcinek to chwilowy odpoczynek od technikaliów. Tym razem wraz z Grzegorzem Rycajem serwujemy Wam dywagacje na popularny temat: agile. Grzegorz od wielu lat programuje i kieruje zespołami programistów. Prawdopodobnie wielu z Was niejednokrotnie miało okazję oglądać go na scenie, gdyż regularnie występuje na różnych eventach. MVP w kategorii Visual Studio ALM.

40-minutową rozmowę rozpoczynamy od historii agile. Nie zagłębiamy się jednak w teorię – tę pewnie ogromna większość Was zna (jeśli nie – zapraszam do sekcji z linkami). Zastanawiamy się czym różni się agile w zależności od modelu pracy zespołu: “wewnętrzne zasoby” vs “dostawcy oprogramowania”. Jaki wpływ na projekt ma typ klienta: bank czy startup? Bardzo ważna część konwersacji to przestrogi: na co uważać stosując agile, jakie są najczęściej popełniane błędy w tym zakresie? Grzesiek dzieli się też swoimi spostrzeżeniami odnośnie radzenia sobie z “wrzutkami z produkcji” skutecznie demolującymi plany na dany sprint, czyli: jak radzić sobie z utrzymaniem systemów? Albo: jak dbać o dokumentację projektową? Rozmawiamy też o bardziej niskopoziomowych praktykach, takich jak code review, daily standup meeting, retrospekcje czy wreszcie continuous integration.

Konkurs: rozdajemy egzemplarz polecanej przez Grześka książki “Agile Project Management with Scrum“. Pewnie już wiecie kto ją dostanie, prawda?:) Tak, autor jednego z komentarzy pod niniejszym postem! Gorąco zapraszam zatem do dyskusji na temat zarówno tego odcinka, jak i DevTalka w ogóle.

Czytaj dalej…

  • PaSkol

    Niniejszym dziękuję 😉

    A tak przy okazji – jak się okazuje – szukając ostatnio pracy, miałem też ofertę od Billennium ;). Świat jest mały :D.

  • PaSkol

    Jeszcze uzupełnię, bo dopiero teraz zauważyłem Twoje odniesienie do dokumentacji. Jako “dokumentację” rozumiałem w tym wypadku jedynie tę techniczną i to też w sensie użycia metody/klasy. W żadnym zaś przypadku nie twierdzę, że testy zastąpią _całą_ dokumentację (albo że nie są potrzebne , itd.)

    Oprócz uzupełnienia także autokorekta. Nie piszę się “szlak trafił”, ale “szlag trafił”, a dlaczego, to już ewentualnych zainteresowanych odsyłam do słownika.

  • pokaż wszystkie komentarze (13)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

12 – O mockach z Pawłem Klimczykiem

(comments are closed)

pawel-klimczykW dwunastym już odcinku (czas leci!) mam przyjemność ponownie podywagować na temat bardzo mi bliski: testy. A konkretnie: testowanie w kontekście wykorzystania “isolating frameworks”, czyli po ludzku: mocków. Partnerem w rozmowie jest Paweł Klimczyk – programista, prelegent i “szef dotnetów na fejsie” :), czyli grup .NET Developers Poland oraz .NET Developers Poland Job Market. Na Twitterze: @pwlklm.

Podczas audycji możecie posłuchać o tym co to są mocki i na jakie grupy się je dzieli (i czy ma to sens). Jakie frameworki w świecie .NET pozwalają na wykorzystanie mocków (i jak je można skategoryzować). Do tego wpada kilka pobocznych wątków, jak na przykład: jak testować metody prywatne?

Konkurs: w tym odcinku mam dla Was egzemplarz książki “The Art of Unit Testing” Roya Osherove. Jak zwykle (ale monotonnie, co? 😉 ) powędruje on do jednej z osób, które wezmą udział w dyskusji która powinna wywiązać się pod tym postem. Piszcie zarówno na temat merytoryki odcinka, jak też ogólnie o DevTalku.

Czytaj dalej…

  • Paweł Klimczyk

    @Piotr Perak:
    Odnosnie roznic stub/mock – dobrze piszesz. Ja chcialem rozwinac troche wypowiedz i pokazac wiekszy kontekst. W programowaniu przewaznie uzywam mockow.
    Metody prywatne wymagajace testowania – kurde, zrobilm bym z tego klase osobna, bo widocznie to co jest w srodku robi sporo i powinnno byc wyabstrahowane.

    @Grzegorz:
    UI Testing – temat na osobny podcast :) W tym podkascie chodzilo o pokazanie samej idei mockow.

    @Grzesiek Gałęzowski:
    Growing Object Oriented Software Guided By Tests – to juz temat TDD.
    Ksiazke przeczytam :). Nawiazajac do Twojego podejscia do mockowania DateTime i wprowadzania abstrakcji to jest ono dobre, gdy buduje sie system. Problem pojawia sie gdy lądujesz w projekcie, gdzie kod ma juz kilka lat i dodajesz nowe funkcje. Wtedy trudno abstrahowac DateTime i (może) łatwiej mockować to co jest.

    Ciesze sie, że wywiązała się tutaj taka dyskusja.

  • Grzesiek Gałęzowski

    @Paweł Klimczyk GOOS to temat TDD, ale bardzo mocno mocków właśnie (choć nie tylko). Z wstępu do książki: “Our original motivation for writing the book was to finally explain the technique of using mock objects, which we often see misunderstood.”. Chociaż owszem, mocków można używać inaczej trochę niż jest opisane w tej książce, np. do starego kodu. Tylko wtedy nie są to takie mocki w sensie stricte, gdyż oryginalne mocki rzucały wyjątki gdy otrzymały niespodziewane wywołania (w świecie C# i Javy uważa się obecnie to podejście za przestarzałe i prowadzące do kruchych testów, natomiast JMock – biblioteka autorów GOOS – wciąż opiera się na takich właśnie mockach i autorzy twardo stoją przy stanowisku, że w takim sposobie wykorzystania mocków jaki oni preferują jest to lepsze podejście, dlatego że dla nich naturalnym podejściem do projektowania jest projektowanie “protokołocentryczne”).

    Z tym Date Time w starym kodzie to zgoda, natomiast pole manewru zależy od narzędzi. Jeśli ma się dobre automatyczne narzędzie do refaktoryzacji, to najczęściej nie trzeba mockować tego co jest – w r# często sprawę załatwia kombinacja “Extract Method-> Extract Class->Introduce Parameter (jako parametr konstruktora)->Extract Interface->Use Base Type Where Possible”, którą można zrobić niemal mechanicznie.

  • pokaż wszystkie komentarze (27)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

11 – O produktywności z Marcinem Kwiecińskim

(comments are closed)

marcin-kwiecinskiOdcinek jedenasty stoi pod znakiem… czasu. Wszyscy mamy go za mało. A może mamy go wystarczająco dużo, tylko wykorzystujemy go nie do końca optymalnie? O to i inne rzeczy pytam Marcina Kwiecińskiego, który w ramach projektu Ogarnij Chaos na co dzień zmaga się z takimi problemami, pomagając swoim klientom prowadzić bardziej produktywne życie. Zarówno zawodowe, jak i prywatne. Jego blog to kopalnia spostrzeżeń i dobrych praktyk związanych z tym tematem.

Podczas rozmowy wraz z Marcinem zastanawiamy się jak poznać, czy danej osobie potrzebna jest dodatkowa refleksja odnośnie sposobu wykorzystywania czasu. A jeśli jest – to co może to dać? I najważniejsze: jak można zacząć organizować swoje życie, rozpoznając cele oraz planując drogę do ich realizacji. Dodatkowo bonus: czy postanowienia noworoczne mają jakąkolwiek wartość? :)

Konkurs: w tym tygodniu rozdaję książkę Davida Allena “Getting Things Done“. Otrzyma ją autor jednego z komentarzy pod tym postem, więc bardzo zachęcam do udzielania się. Piszcie swoje spostrzeżenia, doświadczenia, wrażenia. Odcinek spoko, czy słaby? Liczycie na kontynuację tematu, czy to nudy? :) Zadawajcie pytania, drążcie temat. Marcin i ja będziemy aktywnie w dyskusji uczestniczyć.

Czytaj dalej…

  • Maciej Aniserowicz

    Dzięki wszystkim za dyskusję :). Książkę o GTD otrzymuje Dawid Wekwejt. Mail z prośbą o adres wysyłki już poszedł, poposzę o kontakt jeśli z jakichś względów nie dotrze.

  • Dawid Wekwejt

    Dziękuję serdecznie :) Książka już dotarła. Teraz czas na lekturę! xD

  • pokaż wszystkie komentarze (40)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

Special#01 – O dev-eventach z ich organizatorami

(comments are closed)

cover_400Odcinek był tydzień temu, odcinek będzie za tydzień, więc… co ja robię tu dzisiaj?

Oto pierwszy odcinek DevTalk Special. Pięcioro Gości, kilka tematów, jeden motyw przewodni. Pomysł, który narodził się niechcący, w nocy, ot tak, spontanicznie. Realizacja wymagała zaangażowania, dobrej woli, chęci i synchronizacji wielu osób. Dzięki wszystkim za udział.

Ale o co się rozchodzi? W nadchodzących miesiącach nas, programistów III RP, czeka cała masa atrakcji. Aż ciężko się w tym połapać. Postanowiłem w ciągu kilkudziesięciu minut przedstawić Wam organizatorów pięciu ciekawych inicjatyw, o których każdy programista słyszeć powinien.

Ogłoszenie: zanim przejdę do rzeczy: małe przypomnienie. Od tygodnia możecie zapisać się na newsletter DevTalk. Dzięki temu informację o nowych (także tych nieplanowanych 😉 ) odcinkach otrzymacie bezpośrednio na skrzynkę mailową. Zachęcam do zapisów: http://eepurl.com/bem-oP .

Zapraszam do słuchania:

Czytaj dalej…

  • dotnetomaniak.pl

  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

09 – O programowaniu w parach z Krzysztofem Szabelskim

(comments are closed)

krzysztof-szabelskiMoim towarzyszem w odcinku dziewiątym jest Krzysztof Szabelski. Jako doświadczony programista i lider pomaga różnym zespołom w firmie ogarniać trudne tematy. Występuje na konferencjach i grupach pasjonackich. Techniczne treści tworzy na blogu firmowym Future Processing. Więcej o Krzyśku możecie poczytać na stronie http://krzysztofszabelski.com. A na Twitterze występuje jako @kszabelski.

Temat naszej rozmowy to Pair Programming – czyli programowanie w parach ;). Odcinek ten jest tym samym najbardziej spójny koncepcyjnie, gdyż w sumie jest nas dwóch! Ale suchar, nevermind. Podczas tych kilkudziesięciu minut posłuchać można o tym skąd wywodzi się programowanie w parach, jak to robić oraz jak tego nie robić. Dodatkowo: jakie zalety idą za tą praktyką, ale też: na co uważać. Pair programming w pigułce.

Konkurs: w tym tygodniu mam do rozdania wejściówkę na konferencję 4Developers: najbardziej interdyscyplinarny event programistyczny w kraju. 20 kwietnia, Warszawa – warto tam być. Chcesz bilet? Puszczaj tweeta! Zasady są proste: napisz na Twitterze która ścieżka na konferencji wydaje Ci się najbardziej interesująca oraz dlaczego. Lista ścieżek dostępna jest na stronie http://4developers.org.pl/about/. Tweet musi dodatkowo zawierać nazwy @devtalkpl oraz @4Developers, więc na treść zostaje znaków mniej niż w esemesie – trzeba odrobinę wytężyć mózgownicę ;). Do dzieła! Autor najbardziej oryginalnej odpowiedzi dostaje wejściówkę. Przewidziane są również dwie nagrody pocieszenia.

Czytaj dalej…

  • pawel

    Słucham sobie podcastu a tu nagle slysze kolege z roku ze studiów. Cześć Szabel! Co do pair programingu, pierwszy raz sie z nim spotykam. W mojej firmie by to nie przeszło, bo stawia się tu raczej na ilość a nie na jakość. Bardzo ciekawa metodyka, szczególnie podoba mi sie to, że programiści uczą się od siebie nawzajem. I to nie tylko ci mniej doświadczeni od tych bardziej doświadczonych, ale również na odwrót. Pozdrawiam

  • Grzegorz

    Super wskazowka co do przerw – zawsze zastanawialem sie jak kntrolowc zmeczenie w trakcie pracy.
    Ja bardzo czesto stosowalem pp do wdrozenia (mnie/kolegi) do nowychtematow – aby zlapac srodowisko.
    Co do dwoch klawiatur to jest wymog… ale zdarzylo mi sie pracowac na dwoch sklonowanych monitorach i to naprawde dobrze dzialalo.

  • pokaż wszystkie komentarze (6)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

08 – O community z Pawłem Łukasikiem i Pawłem Sawiczem

(comments are closed)

pawel_lukasik_pawel_sawiczW ósmym odcinku pora na test: czy da się rozmawiać z dwoma osobami jednocześnie? Wychodzi na to że chyba tak :).

Dzisiaj goszczę dwóch Pawłów. Paweł Łukasik bloguje, występuje na konferencjach, jest założycielem dotnetomaniaka, jednym z organizatorów Wroc.NET oraz opiekuje się devPytaniami a tweetuje jako @pawel_lukasik. Paweł Sawicz również bloguje i jest prelegentem, a dodatkowo jednym z trzech organizatorów świetnej inicjatywy dotnetconfPL… a to wszystko robi w połączeniu ze studiami, tweetując jako @sawiczpawel.

Zawsze przedstawiam swoich Gości dość szczegółowo prezentując ich działalność i osiągnięcia, ale dzisiaj ma to szczególne znaczenie. Tematem naszej rozmowy jest bowiem community – szeroko rozumiana społeczność programistów. Chcesz wiedzieć dlaczego ludzie udzielają się w społeczności? Albo “jak zacząć”, niezależnie od tego czy jesteś studentem czy starszym już dziadem? To zapraszam do słuchania. W trakcie odcinka wymieniamy też kilka ciekawych “inicjatyw społecznościowych” wartych poznania.

Ogłoszenie: wspominałem o tym na Twitterze, Facebooku oraz aktualnym odcinku, ale podlinkuję i tutaj… DevTalk jest gotów na komercyjną współpracę! Pomysłów mam masę, plany ambitne, a do rozwoju potrzeba… wiadomo czego. Zerknijcie zatem na stronę “Współpraca“, podeślijcie linka w swoich firmach komu trzeba, niechaj się kręci! Dziękuję wszystkim za dotychczasowe życzenia powodzenia oraz szerzenie tego słowa. Aż miło się robi. Ciekawostka: pierwszego partnera już mamy, logo do obejrzenia w pasku bocznym :).

Konkurs: Miło mi również poinformować, że DevTalk zostaje “partnerem medialnym” bardzo ciekawych konferencji programistycznych. W chwili obecnej szczególnie polecam Waszej uwadze konferencję WROC#. Zapowiada się po prostu znakomicie. 12 marca 2015 nad Wrocławiem zapłonie wielki znak #, a wszystkie programistyczne dusze połączą się w dzikim tańcu. Rejestracja na tę imprezę startuje dzisiaj, ale znając życie: dostanie wejściówek nie będzie łatwe. Good news everyone: DevTalk ma do rozdania dwa bilety! Jeden z nich powędruje do osoby, która zrobi na Twitterze retweet informacji o tym poście (uwaga: @devtalkpl musi być wspomniany w tweecie, żebym zobaczył informację o tym; najlepiej zrobić RT tweeta puszczonego z konta @devtalkpl). Drugi z kolei bilet, jak łatwo się domyślić, dostanie jedna z osób które zrobią “share” tego posta (uwaga: share musi mieć ustawienie prywatności “public”, żebym został o tym poinformowany; najlepiej kliknąć “share” na poście puszczonym na fanpage devtalkpl). Na aktywności te czekam do środy, wtedy podam wyniki na odpowiednich kanałach.

Czytaj dalej…

  • Łysy

    m4jq
    W 9 na 10 przypadkach “naturalna rozmowa” będzie, delikatnie mówiąc, nieproduktywna. Dla mnie najlepsze porównanie, z własnych doświadczeń, to …. bezposrednie spotkania z klientami. Najlepiej wychodzą, właśnie wtedy, gdy wcześniej wymienimy się zagadnieniami i głównymi pytaniami.

  • Maciej Aniserowicz

    Słuchajcie, o ile początkowo chciałem, żeby DevTalk był czymś w rodzaju całkowicie spontanicznej pseudo-sesji Q&A to przyjmuję feedback, że być może nie do końca, nie zawsze, się to sprawdza. Do tej pory (tzn do 8 odcinka) z reguły Goście wiedzieli tylko jaki będzie główny/ogólny temat naszej rozmowy (czyli właściwie: jaki będzie tytuł posta). Siłą rzeczy była to prawie zawsze całkowita improwizacja. I o ile w większości przypadków takie podejście się sprawdzi, to jednak czasami – nie musi.

    Dopiero po takim czasie sam postawiłem się w sytuacji Gościa, który musi na bieżąco, walcząc z tremą (wierzcie mi: nagraniu towarzyszy trema:) ), wymyślać sensowne odpowiedzi na moje pytania. I, zgadzając się z częścią krytycznego feedbacku (od tego on jest i dzięki za niego!) zmieniłem trochę strategię.

    Teraz, a mam już nagranych kilka kolejnych odcinków, Gość wie nie tylko o czym ogólnie będziemy rozmawiać, ale zna też zarys mojego planu rozmowy. Nie jest to nic szczegółowego, nie ma to nic wspólnego z “wyreżyserowanymi scenkami”, ale pozwala na chwilę refleksji i przygotowania do odcinka.

    Mam nadzieję że dzięki temu DevTalk będzie jeszcze lepszy.

    Wszystko czytam, wszystko analizuję, krytykę przyjmuję i wyciągam wnioski. Dzielcie się nadal swoimi spostrzeżeniami, to bardzo pomaga.
    Stay tuned zatem :).

  • pokaż wszystkie komentarze (17)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

07 – O pracy zdalnej z Andrzejem Krzywdą

(comments are closed)

andrzej_krzywdaSiódmy odcinek to drugie podejście do tematu “miękkiego”. Towarzyszy mi Andrzej Krzywda – lider polskiej społeczności Ruby, założyciel firmy Arkency, blogger, autor książek (m.in. “Fearless Refactoring: Rails controllers“), prelegent, jeden z twórców podcasta Rails refactoring, organizator konferencji wroc_love.rb… I tak dalej i tak dalej :). Obecny również na Twitterze: @andrzejkrzywda.

Zarówno Andrzej jak i ja od lat pracujemy zdalnie. Ja głównie z domu, on – z różnych miejsc. Podczas rozmowy wymieniamy się doświadczeniami odnośnie korzyści płynących z takiego modelu pracy. Porównujemy także narzędzia które umożliwiają efektywną pracę w rozproszonym zespole. Jak różni się tutaj świat Ruby od świata Microsoftu? Przekonajcie się sami!

Konkurs: Andrzej sponsoruje książkę “Developers oriented project management“, której jest współautorem. Tradycyjnie: otrzyma ją autor jednego z komentarzy pod niniejszym postem, a zwycięzcę wyłoni Andrzej.

Czytaj dalej…

  • Gutek

    Fajnie ze poruszyliscie temat pracy zdalnej, ale z jakiegos powodu czuje niedosyt w tym odcinku. Po kilku dniach zastanowienia sie, doszedlem do wniosku ze to wina tego, ze obydwaj pracujecie od lat zdalnie. Nie jestem pewny czy Andrzej nie wspominal ze to prawie od zawsze tak pracuje ale moge sie tutaj mylic a drugi raz sluchac nie mam czasu 😉 Tak czy siak, cala dyskusja byla o pracy zdalnej przez dwie osoby ktore od lat nie pracowaly w firmie. Z czego Procent jak pamietam miales fatalne doswiadczenia z praca w biurze ale to bylo dawno temu i juz pewnie nie prawda :) Nie biore tutaj pod uwage pracy w biurze w pewnej firmie z ostatnich 2-3 lat. Bo jak sam zauwazyles, podobalo Ci sie (albo znow zle pamietam rozmowe;))

    A wiec, to sie zmienia i duzo ciekawsza dyskusja byla by gdyby polaczyc te dwa swiaty – praca w biurze i prace zdalna, 3 osobowa dyskusja, albo lepiej 2 osobowa, ale prowadzona przez 3.

    Kilka rzeczy ktore byly poruszane a jednak… mialem wrazenie ze to wlasnie “dzieki pracy zdalnej” moge to miec i gdzie indziej bedzie trudniej.

    1. Uprawianie sportu (to ogolnie jak i do rozmowy)

    Mhhh, to tak jak z czytaniem blogow, chodzeniem na spotkania offline itp. albo sie za to czlowiek wezmie albo nie. Tutaj nie ma znaczenia czy praca zdalna czy praca w biurze. Oczywiscie pewnie sa firmy dev ktore wyraznie mowia, ze nie mozesz wyjsc gdzies itp. i to samo tyczy pracy zdalnej. Jednak jezeli chcesz biegac, plywac, chodzic na silke, to naprawde to czy pracujesz w biurze czy zdalnie nie ma znaczenia. Wszystko zalezy od tego jak zorganizujesz sobie czas.

    Nigdy z tym problemu nie mialem – czy to byla praca w firmie do ktorej mialem dojazd 1.5h busami, czy praca z domu, czy tez praca w biurze do ktorego mam 500m. Wszystko zalezy od organizacji. Do dwoch firm dojezdzalem na rowerze systematycznie, codziennie. W tych samych firmach 1h na lunch przeznaczalem na silke lub dlugi spacer. Tak samo jak z pracy zdalnej. Wszystko zalezy od swojej wlasnej organizacji – i oczywiscie polozenia fizycznego miejsca pracy (czy blisko do silki/basenu/trasy do biegu/rowerowej whatever). Baa w tej firmie co Procent pracowales w biurze w bialym to z tego co wiem ludzie w trakcie popoludniowej przeprwy chodza na baseny czy na scianki wspinaczkowe.

    Wiec nie wiem skad w ogole poglad ze jakakolwiek praca wpodowuje ze nie mamy jak uprawiac sportu.

    A skoro pracuje zdalnei to mam ta 1h wiecej czasu (brak dojazdow), ktora wlasnie moge na luzie wykorzystac na spacer czy cokolwiek innego

    2. Zakupy

    Tego argumentu w ogole nie zrozumialem :) moze dlatego ze od dluzszego czasu wieksze zakupy robimy on-line. Wiec w ogole nie ma problemu z tym by cos kupic, a specjalnei podczas dnia isc na zakupy bo jest mniejsza kolejka… moze jakies w malych miastach, bo akurat w warszawie to jakos nie widze roznicy o jakiej godzinie jestem w oszolomie czy tesco. zawsze jest full :)

    3. email zamiast telefonu

    ok to moze ja, ale email jest najgorsza forma komunikacji bo jest ona wykorzystywana do zbyt wielu rzeczy. Ba, liczba maili jest tak duza, ze nawet tam nie wchodze przez ponad pol dnia jak nie dluzej. Zgadzam sie ze email lub jakas inna forma notatki powinna byc. Ale jak ktos mi mowi ze email to jest to, to jakos tak nogi mi sie robia miekkie. rownie dobrze ta sama osoba moze krzyczec na dworzu – uslusze, ale raczej szybko zapomne.

    i to nie ma znaczenia jak sie zarzadza emailami. W szczegolnosci jak trzeba cos przedyskutowac lub zadac jakies pytanie. email is eveil i tyle. Dziwie sie ze w ogole byl poruszony zamiast kontynuowac zreszta fajnie rozpoczety temat innych aplikacji.

    4. spotkania voip

    ok zgadzam sie, ze wiekszosc spotkan powinna byc bez video bo i po co? Ale rozwalil mnie troche tekst, ze ludzie mimo ze razem pracowali dopiero przez jakis przypadek poznali sie na grupie i poznali sie po glosie. Fajne, jakby firma byla stacja radiowa :) Moim zdaniem video powinno byc stosowane raz na jakis czas – nie mowie caly czas, chociazby wlasnie po to by poznac nowego czlonka zespolu i by on poznal innych. PEwnie sa ludzie dla ktorych w ogole bez kamerki jest super, ale szczerze zastanawiam sie jak wtedy oni moga nawiazac jakakolwiek wiez z firma jak tam wszyscy sa anonimowi bez twarzy. Wiem macie spotaknia itp, ale glownie chodzi mi o rozumowanie uzyte w rozmowie jezeli chodzi o kamerki.

    5. dyskusja dlaczego firmy nie chca pracownikow z praca zdalna

    Chlopaki :) a kiedy wy ostatnio pracowaliscie w firmie w biurze? Oczywiscie kilka waznych punktow bylo wymienionych i fajnie. ale tutaj by sie przydala osoba ktora by wyraznie dala wam kontr przyklad. z miejsta jestem wstanie wymienic pare takich przypadkow.

    Do tego to sie zmienilo. Od 2006 roku nie jest az tak zle jak bylo.

    5. Koniec

    to chyba tyle z tych punktow ktore pamietam, ale mam wrazenie ze mialem wiecej uwag.

    A teraz, by nie bylo 😉 to co mi sie podobalo:

    1. Zestaw narzedzi

    super, dzieki Andrzej! o czesci nie slyszalem. Super sprawa.

    2. Praca zdalna

    to oglnie swietny temat i super fajnie Andrzej ze prowadzisz taka firme i to sie udaje – w sensie z tego co mowisz ty jestes zadowolony i reszta tez :) i o to chodzi.

    3. chyba najwazniejsze: komunikacja asynchroniczna

    bardzo mi sie podobalo ze naciskales na to sformulowanie i duzo o tym mowiles. Zgadzam sie ze to jest klucz do udanej pracy nie tylko zdalnej.

    PODSUMOWUJAC

    Z checia posluchalbym odcinka gdzie dwa swiaty sie lacza i prowadza dyskusje na temat pracy zdalnej i w biurze. Moim zdaniem dopiero taka dyskusja da dobry obraz tego co sie dzieje. Ta byla swietna jezeli chodzi o narzedzia i o nacisk na komunikacje asynchroniczna.

    ot tyle :)

    i jak zawsze nikogo nigdzie nie chcialem urazic, jak urazilem to sroki, przepraszam itp itd. wytknijcie mi gdzie urazilem i pewnie jeszcze raz przeprosze bo to nie mialo byc tak ze mialem kogos obrazac :) a napewno tego nie chcialem :)

  • Andrzej Krzywda

    Ksiazke otrzymuje Marcin Biegała za komentarz i blogpost, bardzo dobrze pasujący do dyskusji. Jak ktos jeszcze nie przeczytal, to polecam :) https://blog.biegala.net/2015/01/06/praca-zdalna-czy-biuro-dla-programisty/

  • pokaż wszystkie komentarze (32)
  • Thanks for leaving a comment, please keep it clean. HTML allowed is strong, code and a href.

Permalink:

06 – O programowaniu funkcyjnym z Michałem Łusiakiem

(comments are closed)

michal_lusiakOd razu po Nowym Roku wracamy z mocnym uderzeniem: na warsztacie tym razem znalazło się programowanie funkcyjne! Mój gość to Michał Łusiak – programista, prelegent, blogger. Możecie go znaleźć również na Twitterze: @mlusiak.

W temacie programowania funkcyjnego rozprawiamy o tym po co odchodzić od “standardowego” obiektowego podejścia, jakimi językami warto się zainteresować a nawet: jak zacząć z F# nie mając możliwości jego komercyjnego zastosowania w żywym projekcie. Pojawiają się też wzmianki o wielu interesujących narzędziach i bibliotekach.

Konkurs: firma Tretton37, w której pracuje Michał, sponsoruje książkę “Real-World Functional Programming“. Tak jak już bywało, otrzyma ją autor jednego z komentarzy pod niniejszym postem. Autora tego wybierze Michał, dzisiejszy Gość. Komentujcie, pytajcie, dzielcie się doświadczeniami!

Czytaj dalej…

Permalink:

05 – O prowadzeniu zespołu z Rafałem Barszczewskim

(comments are closed)

rafal-barszczewskiDzisiaj przekraczamy kolejne granice: poruszamy temat “miękki”! Rozmawiam z Rafałem Barszczewskim, a tematem naszych wywodów jest prowadzenie zespołu programistycznego – bycie team leaderem. Rafał od wielu lat pełni taką rolę w pracy zawodowej. Doświadczeniami i refleksjami dzieli się między innymi na swoim blogu.

Mówimy między innymi o motywowaniu programistów, jak i ich krytykowaniu. O tym, jak zespół może podnosić swoje kompetencje. Na co uważać stając się liderem. Dodatkowo zahaczamy o jakże interesującą kwestię “gdzie się podziewają starzy programiści” :). A na koniec dywagujemy o code reviews.

Czytaj dalej…