DevTalk Menu

Viewing all items for tag architecture

Permalink:

41 – O legacy code z Jarosławem Pałką

(comments are closed)

Jaroslaw Pałka41. odcinek DevTalk to nie przelewki, oj nie. Dzisiaj trochę… potaplamy się w błocie.

Do rozmowy zaprosiłem Jarosława Pałkę: znanego i uznanego programistę, architekta, managera, team leadera, prelegenta, bloggera i co tam jeszcze. Spotkać możecie go na bardzo wielu konferencjach, gdzie opowiada o Javie i ciężkiej orce w naszym zawodzie. Na Twitterze: @j_palka.

Takiego to speca do zadań specjalnych zaangażowałem, aby wraz z nim uporać się z niezmiernie trudnym tematem: Legacy Code. <…złowrogi świst zimnego wichru pomiędzy cmentarnymi nagrobkami…>. A w bonusie otrzymujecie także trochę refleksji na temat relaksu, stanu środowiska IT itede, psuć niespodzianek nie będę.

Jest to najdłuższy odcinek do tej pory, ale sami o to prosiliście. Słucham, więc jestem ;).

Uwaga, konkurs!

Dzisiaj chcę pomiędzy Was rozlosować wypasioną książkę, biblię wręcz: “Working effectively with legacy code” autorstwa Michaela Feathersa. Wejście w konkurs jest proste: wystarczy podążyć na iTunes (http://devtalk.pl/itunes) i zostawić tam recenzję podcasta. A następnie wrócić tu i zostawić komentarz informujący o tym oraz o swoim nicku na iTunes właśnie. Wyniki ogłoszę za tydzień, 10 października.

Oczywiście komentarze otwarte są również do innych celów. Temat “legacy code” to bardzo szerokie zagadnienie, jestem pewien, że pojawią się pytania merytoryczne odnośnie odcinka.

Zatem… zapraszam do radio-tele-odbiorników:

Czytaj dalej…

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

Permalink:

40 – O chmurze z Mirosławem Burnejko

(comments are closed)

Miroslaw BurnejkoPrzed Wami DevTalk po raz… czterdziesty! Ale ten czas leci, nie?

Dzisiaj prezentuję rozmowę z gościem, na którego pełne przedstawienie potrzebowałbym kilku ładnych akapitów. Mirek Burnejko! Spec od chmury: Cloud Solution Architect. A dodatkowo … 321 uwaga … : pisarz na Chmurowisku, prelegent na cloud-confach, autor codziennego vloga na YouTube, twórca bloga trzypoziomy.pl, jeden z prowadzących ProgressBar, zapalony biegacz. Niech na razie tyle wystarczy. Na Twitterze: @miroburn. Na Snapchacie: miroburn.

Przez ponad dwa lata istnienia podkastu ani razu nie poruszyłem tematu, który zmienił oblicze naszego świata: CHMURY. Chyba czekałem na właściwą osobę, i się doczekałem. To o “klałdzie” właśnie dzisiaj dywagujemy. Po co to, do czego to, jakie niesie ze sobą korzyści i jakie niebezpieczeństwa?

Zadawajcie pytania w komentarzach. Męczcie Mirka ;). A póki co… wiecie co robić:

Czytaj dalej…

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

Permalink:

25 – O Event Driven Architecture z Szymonem Kulcem

(comments are closed)

szymon-kulecW 25 odcinku DevTalk wracamy do tematu architektury. Tym razem moim Gościem jest Szymon Kulec: programista, blogger, prelegent i jeden z liderów Warszawskiej Grupy .NET. Na Twitterze: @scooletz.

Dyskutujemy o Event Driven Architecture. Z odcinka dowiecie się czym jest EDA, o jakich zdarzeniach mowa i jak z nich korzystać. Do tego: jak ma się do tego CQRS i Event Sourcing, na czym polega eventual consistency oraz jak obsługiwać/przetwarzać zdarzenia? I… oczywiście, wiele więcej :). Zapraszam do słuchania!

Czytaj dalej…

  • Michal Franc

    @dariol
    Eventual consistency nie oznacza ze cos sie zgubi, zawsze mozna to odnalezc ‘gdzies’ w systemie.

  • Jakub Kasprzyk

    Przepraszam za ewentualną ignorancję, ale czy naprawdę jest taka diametralna różnica między Event Broker i Event Bus? Pozdrawiam

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

Permalink:

22 – O wiadomościach z Szymonem Pobiegą

(comments are closed)

szymon-pobiegaDzisiaj technicznie-architektonicznie. Dwudziesty drugi odcinek DevTalka pod znakiem WIADOMOŚCI i KOMUNIKACJI stoi. Reflektor w te mgliste pojęcia kieruje Szymon Pobiega: programista/architekt, blogger, prelegent. Pracuje w Particular Software, gdzie klepie NServiceBusa dla Udiego Dahana (pamiętacie DevTalk#14 – CQRS with Udi Dahan?). Zatem: zdecydowanie wie o czym mówi!

Z rozmowy dowiecie się czym tak naprawdę jest komunikacja i dlaczego warto sobie zawracać głowę jakimiś “wiadomościami” czy “kolejkami”. Dlaczego jest to lepsze niż RPC (Remote Procedure Calls). Jakie mamy systemy kolejek, czym się między sobą różnią, oraz… po co na kolejki nakładać jeszcze service bus, czyli szynę wiadomości?

Enjoy!

Czytaj dalej…

Permalink:

20 – O mikroserwisach z Michałem Francem

(comments are closed)

michal-francWakacje, wakacje i po wakacjach. I bardzo dobrze, ile można, c’nie?

Po wakacyjnej przerwie powracamy, zamaszyście, pomału i usłużnie. Ale suchy rebus! Mału -> mikru -> mikro. Usłużnie -> serwisowo -> service. Czyli: po wakacyjnej przerwie powracamy, zamaszyście, z mikroserwisami! Towarzyszy mi Michał Franc, który z dalekiego jUKeja wskoczył mi na Skype’a. Michał bloguje na http://www.mfranc.com, przemawia oraz jest jednym z organizatorów konferencji dotnetconf.pl. Na Twitterze możecie go stalkować pod @francmichal.

Zarówno Michał jak i ja tworzymy/utrzymujemy systemy oparte o “architekturę mikroserwisów”. Dzisiejsza rozmowa to wymiana doświadczeń i próba zebrania zarówno zalet jak i wad tego rozwiązania. Jeżeli nie wiesz co to są mikroserwisy – z tego odcinka się dowiesz. Jeśli wiesz co to jest, ale nie było okazji do wypróbowania w praktyce – otrzymasz “mikroserwisy w pigułce”. A jeśli tworzysz mikroserwisy: być może dowiesz się czegoś nowego? W każdym razie: daj nam znać w komentarzach!

Czytaj dalej…

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.