POIT #173: Tworzenie przyjaznych środowisku i opartych o chmurę aplikacji w Java

Witam w sto siedemdziesiątym trzecim odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest tworzenie przyjaznych środowisku i opartych o chmurę aplikacji w Java.

Dziś moimi gośćmi są:

Łukasz Stefaniszyn, skuteczny architekt oprogramowania z doświadczeniem w zakresie full stack Software Delivery Life Cycle w oddziale Financial Services w Capgemini Polska. Umiejętnie zarządza i wdraża nowe innowacyjne pomysły i strategie w zespołach on-shore i off-shore. Pomyślnie wdraża aplikacje z zapewnieniem wysokiej jakości wraz z dobrze zdefiniowaną infrastrukturę chmury. Buduje profesjonale biznesowe relacje z współpracownikami,

Bartłomiej Wasiuk jest architektem oprogramowania w oddziale Financial Services w Capgemini Polska. Pełni rolę lidera technicznego w zespole pracującym dla klienta z branży ubezpieczeń. Wieloletni praktyk w dziedzienie projektowania i tworzenia złożonych systemów dla klientów z róznych branż. Preferuje stack technologiczny oparty o języka programowania Java. Zaangażowany w życie firmy jako bezpośredni przełożony grupy świetnych deweloperek i deweloperów. Doświadczony w pracy z metodykami Scrum oraz SAFe.

Sponsor odcinka

Sponsorem odcinka jest Capgemini Polska.

W tym odcinku rozmawiamy o:

  • wpływie IT na środowisko,
  • skąd bierze się ten wpływ? jakie są jego źródła?
  • co to znaczy, że aplikacja jest przyjazna środowisku?
  • jakie miary możemy stosować aby mierzyć ten wpływ?
  • jaki wpływ na omawiany temat ma chmura obliczeniowa?
  • jakie dobre praktyki i code smells możemy stosować aby wykrywać ten wpływ?
  • czy Java sprawdza się w nowoczesnych, rozbudowanych aplikacjach opartych o chmurę?
  • czy programiści są świadomi tego wpływu?
  • jakie jest obecnie zapotrzebowanie na programistów Java?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 173. odcinek podcastu Porozmawiajmy o IT, w którym z moimi gośćmi rozmawiam o tworzeniu przyjaznych środowisku i opartych o chmurę aplikacji w Java. Wszystkie linki oraz transkrypcję dzisiejszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/173

Ocena lub recenzja podcastu w Twojej aplikacji jest bardzo cenna, więc nie zapomnij poświęcić na to kilku minut. Od niedawna można wystawiać oceny podcastom w Spotify. Będzie mi bardzo miło, jeśli w ten sposób odwdzięczysz się za treści, które dla Ciebie tworzę. Dziękuję.

Ja się nazywam Krzysztof Kempiński, a moją misją jest poszerzanie horyzontów ludzi z branży IT. Środkiem do tego jest między innymi ten podcast. Wspierając mnie przez Patronite, pomagasz w realizacji tej misji. Dlatego już dziś wejdź na porozmawiajmyoit.pl/wspieram i sprawdź szczegóły. Ja natomiast bardzo dziękuję moim obecnym patronom. A teraz życzę Ci już miłego słuchania!

Odpalamy!

 

Cześć, moimi gośćmi są dziś Łukasz Stefaniszyn, skuteczny architekt oprogramowania z doświadczeniem w zakresie full stack Software Delivery Life Cycle w oddziale financial services w Capgemini Polska. Umiejętnie zarządza i wdraża nowe innowacyjne pomysły i strategie w zespołach onshore i offshore. Pomyślnie wdraża aplikacje z zapewnieniem wysokiej jakości wraz z dobrze zdefiniowaną infrastrukturą chmury. Buduje profesjonalne biznesowe relacje ze współpracownikami. Oraz Bartłomiej Wasiuk, który jest architektem oprogramowania w oddziale financial services w Capgemini Polska. Pełni rolę lidera technicznego w zespole pracującym dla klienta z branży ubezpieczeń. Wieloletni praktyk w dziedzinie projektowania i tworzenia złożonych systemów dla klientów z różnych branż. Preferuje stack technologiczny oparty o język programowania Java. Zaangażowany w życie firmy jako bezpośredni przełożony grupy świetnych deweloperek i deweloperów. Doświadczony w pracy z metodykami Scrum oraz Safe. 

Łukasz, Bartek, bardzo miło mi gościć Was w podcaście.

 

Łukasz Stefaniszyn: Witam, Hej.

 

Bartłomiej Wasiuk: Cześć.

 

Dzisiaj porozmawiamy sobie o dwóch istotnych trendach: dbaniu o środowisko i wykorzystaniu chmury. Połączymy te trendy, rozmawiając o tym, jak tworzyć przyjazne środowisku i oparte o chmurę obliczeniową aplikacje w Java.

Ale zanim do tego przejdziemy, rozpoczynam zawsze podcast pytaniem o to, czy słuchacie podcastów. Jeżeli tak, to może macie jakieś audycje, o których warto tu wspomnieć?

 

ŁS: Tak, jak najbardziej. Lubię audycje związane z software architecture, czyli takie, które umożliwiają tak naprawdę ruszenie albo popatrzenie na wytwarzanie w programie trochę w innym świetle. Coś, co jest świeże na rynku, co inni też robią i co warto tak naprawdę zaaplikować w codziennej pracy. 

 

BW: Ze względu na dużo nowości, bardzo szybko rozwijającą się naszą branżę ograniczam się do jednego agregatora treści, świetnego zresztą, InfoQ. I zależnie od tego, czy publikują ciekawy artykuł, czy ciekawą rozmowę, to albo podcast, albo artykuł. Polecam gorąco.

 

Super. Powiem szczerze, że nie wiedziałem, że InfoQ publikuje podcasty, z pewnością sobie zerknę.

 

BW: Nie takie regularne podcasty, ale bardziej, powiedzmy, rozmowy z ciekawymi gośćmi. Taka forma, jak u Ciebie. 

 

Fajnie, dzięki za te rekomendacje. Cieszę się, że też przez medium podcastowe czerpiecie wiedzę o branży. Myślę, że to jest świetny sposób na to, żeby posłuchać, co tam w trawie piszczy.

Okej, to może przejdźmy do naszego tematu. Chciałbym rozpocząć od aspektu środowiskowego, bo w IT oprócz zagadnień bezpieczeństwa, jakości, disability, o których się coraz częściej mówi, mam wrażenie nawet, że do jakiegoś mainstreamu te zagadnienia trafiają, to też pojawia się aspekt wpływu, jaki ma branża na środowisko.

Chciałbym Was zapytać, czy faktycznie ten wpływ jest na tyle duży, czy faktycznie jest to problem, czy jako społeczeństwo, ludzkość mamy o co się martwić, czy IT ma na tyle znaczący wpływ na to, że warto ten temat poruszać?

 

ŁS: Częściowo tak, jak wspominałeś, czyli mamy już całkiem dużo elementów, które determinują, co jest dobrym produktem jako aplikacja, a co potrzeba jeszcze ulepszyć. Na pewno to, co na dzień dzisiejszy jest takim elementem, dyferencjałem odnośnie do wyzwań IT, to jest użyteczność, utrzymanie, dostępność, jakość. Od niedawna jeszcze jesteśmy w tej części związanej z bezpieczeństwem. 

Dość klasycznym elementem są koszty i szybkość działania aplikacji, a całkowicie niedawno pojawiło się coś, co się nazywa green IT, czyli zielone IT. Ale to jest właśnie coś, co my też zauważamy w pierwszej kolejności w Europie, pewnie dalej na świecie, czyli coraz więcej mamy tych aplikacji, coraz więcej wytwarzamy, nawet ze stacjonarnych sklepów przechodzimy do świata elektronicznego. Co za tym idzie, jest zapotrzebowanie na strony internetowe czy jakieś mobilne aplikacje, więc tego jest całkiem sporo i będzie jeszcze więcej. 

To jest też dobre, bo wygląda na to, że świat się rozwija. I korzystając z danych, które są tworzone, opublikowane i weryfikowane u nas, przez firmę Capgemini, wychodzi na to, że na obecną chwilę wkład IT w wytwarzanie dwutlenku węgla z powodu działania serwerów, urządzeń elektrycznych jest na poziomie ok. 3%. I mniej więcej, biorąc pod uwagę szybkość rozwoju, szacuje się, że w 2040 r. będzie ponad 14%. Nie jest jeszcze duże, ale zaczyna rosnąć, więc to jest tak naprawdę moment, kiedy warto się nad tym zastanowić z dwóch powodów. 

Pierwszy jest najbardziej oczywisty, czyli że chcemy, żeby miejsce, w którym żyjemy, było jak najlepsze, ale też druga rzecz jest taka, że inne firmy zaczynają zwracać na to uwagę, a co za tym idzie, przy samych ofertach, jakie będziemy składać do innych firm, jest np. informacja, że aplikacja spełnia wymogi, jeśli chodzi o zielone IT, co jest dodatkiem ponadto, co jest już dotychczas, czyli użyteczności, utrzymania, dostępności.

 

Gdybyśmy spojrzeli głębiej na to, jakie branże czy jakie zastosowania IT de facto mają istotny wpływ, bo najszerzej, bo o ile najczęściej wspomina się tu blockchain, który ma trochę przebiegi przepalające prąd i mało jest z tego jakiegoś użytku, o tyle jestem ciekaw, jakie jeszcze identyfikujecie zastosowania IT, które pozostawiają znaczący swój ślad na środowisko.

 

BW: Tutaj jest dużo różnych śladów, jak to nazwałeś. Łukasz wspomniał o serwerach. Przecież, żeby utrzymać taki Google, Amazon posiada ogromne centra danych. To nie tylko prąd do podtrzymywania samych urządzeń sieciowych, ale też cała infrastruktura utrzymująca to. Jest tego bardzo dużo i dlatego my jako organizacja, wybierając dostawcę usług cloudowych, czy my jako oferent rozwiązań infrastrukturalnych, możemy opierać się na centrach IT, które pobierają zieloną energię i w ten sposób możemy trochę zminimalizować wpływ na środowisko.

Natomiast wspomniałeś o technologii blockchain. Ona jest pewnym novum w IT od kilku lat. Owszem, obserwujemy bardzo duże obciążenie maszyn w czasie operacji blockchainowych, ale w zastosowaniach komercyjnych jest jeszcze mało wykorzystywane. Ja tutaj najbardziej bym się obawiał jeśli chodzi o wykorzystanie energii w kopalniach bitcoinów. Na świecie powstają całe farmy włączonych kart graficznych, które rozgrzane wręcz do czerwoności kopią te bitcoiny i inne kryptowaluty. 

A mówię o bitcoinie, bo jest ustalona maksymalna liczba bitcoinów dostępnych w obiegu i jeszcze ona nie została osiągnięta, ale im bliżej jesteśmy tej maksymalnej liczby, tym wykopanie kolejnego bitcoina jest cięższe i konsumuje dużo więcej energii. Już kilka lat temu domowi górnicy kryptowalut, jak to się mówi, mieli problem, że opłacalność wykopania bitcoina względem poboru prądu już się obracała na niekorzyść. Więc uważam, że największe zagrożenia to chmury, ogromne centra serwerowe, sieciowe i kopalnie bitcoinów.

My jako organizacja mamy pewien wpływ na pierwszy z tych aspektów. Oczywiście jeżeli mówimy o sustainability, czyli zrównoważonym rozwoju, do tego można jeszcze dodać typowe biurowe zachowania. Czyli ograniczanie zużycia papieru na rzecz maili, ograniczanie podróży służbowych na rzecz wideokonferencji. Więc to są rzeczy, na które możemy mieć jakiś wpływ.

 

Tutaj jest dużo różnych śladów, jak to nazwałeś. Łukasz wspomniał o serwerach. Przecież, żeby utrzymać taki Google, Amazon posiada ogromne centra danych. To nie tylko prąd do podtrzymywania samych urządzeń sieciowych, ale też cała infrastruktura utrzymująca to. Jest tego bardzo dużo i dlatego my jako organizacja, wybierając dostawcę usług cloudowych, czy my jako oferent rozwiązań infrastrukturalnych, możemy opierać się na centrach IT, które pobierają zieloną energię i w ten sposób możemy trochę zminimalizować wpływ na środowisko.

 

Wspominałeś, Łukasz, wcześniej o green IT, Bartek, teraz powiedziałeś, jakie fragmenty szeroko rozumianego IT mogą mieć swój wpływ na środowisko, chciałbym się teraz przyjrzeć temu od drugiej strony, czyli spróbować ująć temat przyjazności środowisku. Kiedy w ogóle możemy mówić, że aplikacja jest przyjazna środowisku? Co to w ogóle znaczy?

 

ŁS: Tak, w sumie bardzo fajne pytanie, ponieważ musimy pamiętać o tym, że w ogóle cała ta inicjatywa przyjaznych aplikacji to jest tak naprawdę rozłożenie na dwa główne składniki, tj. aplikacja sama w sobie, czyli jej sposób działania, a więc w tym przypadku mówimy o tym, w jaki sposób się zachowuje aplikacja, która była napisana w danym języku programowania, jeżeli chodzi o zużycie CPU, RAM-u, sieci czy zapisu/ odczytu z dysku. Ale jest też ta druga rzecz – sama infrastruktura. Czyli czy komponenty, z których zbudowaliśmy naszą infrastrukturę, która będzie wspierać rzeczywiście naszą aplikację, jest też optymalna. 

Bo czasami może być tak, że przedobrzymy z jakimiś usługami albo sama koncepcja realizacji biznesowego działania aplikacji może być lepiej zrobiona przy użyciu innych komponentów. Bo sami wiemy, że w IT, żeby napisać jakąś jedną funkcjonalność, można to zrobić na mnóstwo różnych sposobów, łatwiej, bardziej lub mniej czytelnie, szybciej, wolniej. Jest bardzo dużo różnych podejść, w jaki sposób zrealizować dokładnie to samo zadanie i idąc o jeden szczebel w górę, dokładnie tak samo można zrobić z infrastrukturą. 

Czyli tę samą funkcjonalność czy funkcjonalność biznesową można zrealizować przy użyciu różnego zestawu usług, co za tym idzie, musimy pamiętać, że najczęściej tak naprawdę mówimy o rozwiązaniach chmurowych. Z naszej perspektywy to jest na kliknięcie jednego przycisku, natomiast tysiące kilometrów dalej faktycznie zaczynają się uruchamiać maszyny, które zaczynają realizować to, co sobie kliknęliśmy tylko u siebie na ekranie. Więc trzeba wziąć to pod uwagę. 

I mając to na myśli, pojawia się taka cienka granica między wydajnością aplikacji a tym, czy aplikacja i zarazem też infrastruktura jest zielona (green IT). Jest jeszcze zagadnienie, czy jak szybko działa mi aplikacja, to czy ona jest zielona. Czyli kwestia tego czy i w jaki sposób będziemy mierzyć sobie ten green IT, ale sądzę, że możemy tu zadać pytanie, w jaki sposób moglibyśmy się powoli zacząć przymierzać do tego, w jaki sposób to mierzyć i warzyć.

 

To jest bardzo ważna rzecz, dlatego pozwolę sobie podkreślić, że o przyjazności aplikacji mówimy wówczas, kiedy jest zadbany ten obszar aplikacji samej w sobie, czyli wydajnie napisanej aplikacji, która wykorzystuje zasoby w jak najmniejszym stopniu, ale też infrastruktury. Nie możemy o tym komponencie zapominać, ponieważ tutaj to wykorzystanie energii i ten wpływ może być duży. I czasami też złudnie w chmurze obliczeniowej coś, co jest dostępne jednym klikiem, de facto może mieć całkiem spory impakt. 

Do tego zaraz przejdziemy. Chciałbym teraz może faktycznie przejść do tego wątku, o którym wspomniałeś, bo ciężko jest zarządzać czymś, czego się nie mierzy. Dlatego pytanie teraz, jakie narzędzia, jakie miary mamy dostępne w procesie wytwarzania i utrzymania aplikacji (bo przed chwilą sobie powiedzieliśmy, że ta infrastruktura i utrzymanie też ma znaczący wpływ), aby właśnie ten wpływ na środowisko zidentyfikować, wiedzieć, jaki jest ten wpływ, a w perspektywie długoterminowej minimalizować?

 

ŁS: Wracając znowu do poprzedniej części, czyli mamy ten podział, jeżeli chodzi o działanie aplikacji i działanie infrastruktury. Jeżeli chodzi o infrastrukturę, i idąc troszkę bardziej tak naprawdę, już korzystając z takich rozwiązań typu chmura, AWS, Azure czy Google, to oni już tak naprawdę, nie w bezpośredni sposób, ale pośrednio, optymalizują, tzn. informują danego użytkownika, że słuchaj, tę funkcjonalność, którą odpaliłeś, prawdopodobnie można byłoby lepiej uruchomić. 

To też wszystko zależy od tego, w jakim pakiecie jesteśmy, czyli że dany dostarczyciel chmury od razu te informuje nas o możliwej optymalizacji użycia zasobów, więc to już w jakiś sposób się tam dzieje. Bo nie ukrywajmy, że tak naprawdę w jakimś stopniu koszt, który my ponosimy za działanie jakiejś usługi, jest bardzo często kosztem, który przekłada się na zużycie energii. Więc poniekąd ci więksi dostawcy chmurowi już informują nas o tym, w jaki sposób moglibyśmy lepiej zrealizować naszą funkcjonalność biznesową.

Natomiast jeśli chodzi o drugą część, czyli samą aplikację, to jest to już tylko i wyłącznie po naszej, czyli deweloperów, stronie. I teraz: co można byłoby zrobić? W sumie jest trochę tak, że Capgemini jest całkiem sporą firmą, ona jest rozłożona w ok. 50 krajach, ponad 300 tys. pracowników i to też daje całkiem sporą wartość. Wartość tego typu, że w różnych częściach świata różne działy zaczęły się trochę zastanawiać nad tym, w jaki sposób być tym sprzedawcą usług, który się tak naprawdę zacznie wybijać. 

I tym elementem może być np. właśnie w dzisiejszych czasach to zielone IT. I w oddziale francuskim zaczęto współpracować z kilkoma uniwersytetami, też firmy z innej branży IT, federacje zrzeszające informatyków wygenerowały bardzo fajny i ciekawy raport, który robi nam zestawienie, co można byłoby zrobić lepiej, jeśli chodzi o samą aplikację. Umieścili to w dość ciekawej koncepcji, mianowicie nakładając, jak łatwo dałoby się zaimplementować daną regułę do aplikacji i jaki ma to wpływ. Najczęściej tego typu weryfikację można robić przy użyciu statycznej analizy kodu. 

To tak naprawdę wszyscy znamy, wytwarzając każdą aplikację, najczęściej używamy. W pierwszym kroku to jest statyczna analiza kodu. I w takiej analizie można by wykryć jakieś wzorce, które podpadają pod za duże zużycie zasobów. Najprostszym, który wszystkim pewnie przychodzi do głowy, może być np. select *. Czyli tak naprawdę konsumujemy strasznie dużo operacji nad czymś, co tak naprawdę można byłoby zoptymalizować przez konkretny zestaw filtrów czy tabel. 

I to jest najtłustsza metoda, która może zeżreć najwięcej zasobów, ale twórcy tego raportu tak naprawdę nie skupili się tylko na takich standardowych elementach, jak konstrukcje aplikacji pisanych w Javie czy Java Script, jeśli chodzi o strukturę do baz danych, ale też wzięli na warsztat takie struktury jak CSS, DOM czy Cookies, gdzie od razu można by wykryć tego rodzaju nadużycia, jeśli chodzi o konsumpcję za dużego właśnie procesora, RAM-u, sieci bądź zapisu / odczytu na dysku. I to nie tylko lokalnie dla tej aplikacji, ale też jeśli np. mówimy sobie o jakichś stronach internetowych, to jest oprócz tego chociażby np. ten Cookies, gdzie raz wygenerowany jest dystrybuowany do wszystkich odbiorców. 

Więc np. optymalizacja jeżeli chodzi o Cookies, byłaby taka, że nie wysyłać zawsze, albo wysyłać tylko i wyłącznie Cookies, kiedy są faktycznie potrzebne. I dzięki temu ten rozmiar wysyłanych danych jest mniejszy, a co za tym idzie, po drodze te wszystkie routery, sieci itd. mają też mniejsze obciążenie w przetworzeniu tej samej informacji albo tak naprawdę zbędnej informacji.

Więc autorzy tego raportu wzięli na warsztat wiele aspektów, rozłożyli je na elementy takie, jak łatwo da się zrealizować daną regułę i jaki ma ona wpływ na środowisko. I w pierwszej kolejności co można byłoby np. zrobić, to jeśli weźmiemy sobie na warsztat naszą javową aplikację, to można bezpośrednio zaaplikować ten zespół reguł do statycznej analizy kodu, czyli np. do SonarQube można wrzucić zestaw reguł, które od razu nam wykryją, że może i aplikacja działa okej, jest według standardowych reguł statycznej analizy kodu, ale ma jakąś strukturę, która np. będzie za dużo zużywać pamięci. 

I można byłoby już zacząć optymalizować ten kod pod kątem samego wykorzystania energii, a też nie ukrywajmy, że jest to bardzo fajny element, który można zaświecić, jeżeli chodzi o konkurencję. Czyli tak naprawdę jest to coś, co można względnie łatwo zaimplementować i od razu też powiedzieć, że my już na to patrzymy pod kątem takiego zielonego IT.

 

Twórcy tego raportu tak naprawdę nie skupili się tylko na takich standardowych elementach, jak konstrukcje aplikacji pisanych w Javie czy Java Script, jeśli chodzi o strukturę do baz danych, ale też wzięli na warsztat takie struktury jak CSS, DOM czy Cookies, gdzie od razu można by wykryć tego rodzaju nadużycia, jeśli chodzi o konsumpcję za dużego właśnie procesora, RAM-u, sieci bądź zapisu / odczytu na dysku.

 

Bardzo podoba mi się ta koncepcja, że już na etapie wytwarzania kodu jesteśmy w stanie zoptymalizować ten wpływ, że mamy ku temu narzędzia, bo wiadomo, że im wcześniej taką optymalizację wprowadzimy, tym po pierwsze, będzie ona mniej kosztowała, a po drugie, będzie miała zdecydowanie mniejszy wpływ, niż nastąpiłoby to dopiero na etapie wdrożenia czy utrzymania.

Przypominam, że dzisiaj z gośćmi z Capgemini rozmawiamy o tworzeniu przyjaznych środowisku i opartych o chmurę aplikacji z wykorzystaniem głównie języka Java. I tak trochę tutaj przemyciliśmy temat chmury obliczeniowej jako potencjalne zminimalizowanie wpływu, jaki aplikacje mogą wywierać na środowisko.

Stąd teraz moje pytanie pogłębiające ten wątek: czy faktycznie wykorzystanie chmury obliczeniowej ma jakiś znaczący wpływ, czy oparcie architektury aplikacji o chmurę może się przełożyć na zmniejszony wpływ na środowisko?

 

ŁS: Zdecydowanie. My jako wytwórcy aplikacji, ale bardzo często jest tak, że zespoły już teraz są odpowiedzialne za wszystko, czyli od samej koncepcji, idei aplikacji, poprzez napisanie jej i przetestowanie, ale też są odpowiedzialne za ustawienie środowiska, czyli właśnie włączyć się do tej chmury, stworzenie infrastruktury do tego i wdrożenie aplikacji na to środowisko chmurowe. Więc niewłaściwa wiedza znajomości chmury może spowodować, że użyjemy nie takich usług, jakie chcielibyśmy użyć. Czyli biznesowo będzie wszystko działać, natomiast kosztowo może się to nie spinać tak, jak chcieliśmy, oraz możemy po prostu wykorzystywać za dużo zasobów, które są nieoptymalnie dopasowane do tego, co chcielibyśmy zrealizować. 

Przykładem są same strony internetowe. Jeżeli napiszemy sobie aplikację w Java Script, to na obecną chwilę można to dwojako zrobić, jeśli chodzi o użycie clouda. Albo bierzemy naszą aplikację i stawiamy sobie serwer, na którego wkładamy naszego Java Scripta i wtedy jest udostępniony jako strona internetowa, gdzieś tam działająca. Albo możemy wykorzystać gotowe już komponenty, które dostawcy nam dają. Czyli np. albo na AWS-y na S3 wrzucić sobie taką aplikację javascriptową jako statyczną aplikacją, albo wrzucić na Azure, na storage. I biznesowo zrealizujemy dokładnie to samo, bo na samym końcu aplikacja webowa będzie nam działać, natomiast koszt i konsumpcja energii będą całkowicie inaczej rozłożone. 

Więc oprócz tego, jakie usługi są, trzeba by też wiedzieć, co się stanie jeśli je wszystkie uruchomimy, jakie to będzie przełożenie na wykorzystanie energii. Dostawcy chmurowi powoli też nam podpowiadają, w jaki sposób można by zoptymalizować działanie naszej aplokacji w oparciu na ich usługach, więc to trochę już się zaczęło dziać. Nie ukrywajmy, że dostawcy chmurowi zbierają też pieniądze na tym, żebyśmy wykorzystywali jak najwięcej ich zasobów. Ale też nie są aż tak chciwi, bo pomagają nam to zrobić lepiej.

 

Czyli wiemy już, że nie tylko wykorzystanie chmury, ale może bardziej umiejętne wykorzystanie chmury może być jakimś lekarstwem i może zmniejszyć faktycznie wpływ na środowisko. Zastanawiam się, czy język programowania ma równie duży wpływ. Bo jako firma Capgemini specjalizujecie się w rozwiązaniach opartych o język Java. Czy ten język właśnie sprawdza się w nowoczesnych, rozbudowanych w aplikacjach opartych o chmurę, właśnie z tym nastawieniem na zmniejszony wpływ na środowisko? Co tutaj z Waszych doświadczeń wynika?

 

BW: Z mojego doświadczenia mogę Ci powiedzieć, że bardzo ciężko jest porównać języki do siebie. Jeśli mówimy o bardzo rozbudowanych , dużych systemach, np. key backendowych systemach do obsługi transakcji, czy o ogromnych systemach wspomagających pracę na cały film ubezpieczeniowych, jest bardzo ciężko. Zobacz, napiszemy w jednym języku taki system, a często taki system jest pisany w kilku językach, w zależności od potrzeb, i bardzo ciężko z napisać drugi konkurencyjny i porównać czasy wykonywania ze sobą czy performance.

Generalnie, odpowiadając krótko, zwięźle na Twoje pytanie, tak, Java jest takim językiem. Przede wszystkim przez wiele lat za Javą ciągnęła się łatka języka strasznie powolnego. I owszem, tak było, 20 lat temu. Dzięki ciągłym pracom optymalizacyjnym na wirtualnej maszynie Java jest bardzo szybkim językiem. Widziałem test przeprowadzony rok temu przez jednego z bardzo doświadczonych deweloperów Amazonie. Porównywał wydajność aplikacji napisanych w różnych językach. Java może była delikatnie bita przez inne języki w kwestii średniego czasu odpowiedzi, ale jeżeli chodzi o performance, o przetwarzanie bardzo dużych wolumenów, a takie wręcz rozgrzewanie bebechów do czerwoności, to Java miała chyba najlepszy performance w tym momencie. 

Więc generalnie każdy język, który jest wspierany przez chmurę, jest dobry, bo każdy język znajdzie swoje fajne zastosowania. Natomiast z tego, co eksperci polecają i ja się do tego przychylam, najlepszy język do pisania kodu to ten, który Twój zespół już zna. Przy czym Java jest językiem, gdzie wg różnych statystyk mamy 5-10 mln deweloperów. Więc jest to ogromna społeczność. Sama Java jest cały czas rozwijana, mamy ogromną liczbę tooli do Javy, frameworków współpracujących z Javą. To nie tylko Spring, ale to także bardzo odchudzony, leciutki Vertex, Quercus, świetny Micronaut do integracji aplikacji javowych z chmurą. Jest cała masa różnych narzędzi, które bardzo wspierają, upraszczają, pomagają nam pracować z chmurą i które też, w kontekście oszczędzania energii, pomagają tworzyć optymalny kod po to, aby złożoność obliczeniowa była jak najmniejsza, aby kod wykonywał się sprawnie i optymalnie wykorzystywał zasoby. 

Poza tym Java ma też świetne wsparcie aplikacji wielowątkowych. Ciężko znaleźć tak dobrze rozwiniętą wielowątkowość w innych językach, np. sriptowych. Wbrew pozorom statyczne typowanie w Javie też bardzo pomaga przewidzieć zajęcie pamięci, wykorzystanie zasobów. To jest coś, co można z góry oszacować i to jest kolejny plus na rzecz Javy. I jak komuś brakuje, to zawsze można podmienić klasyczne JVM na GraalVM, które ma też fenomenalne osiągi. Dlatego jak najbardziej Java plus chmura to dobre połączenie w mojej opinii.

 

ŁS: Jest jeszcze jedna rzecz, którą warto wziąć pod uwagę. Na rynku mamy coraz częstsze wykorzystywanie funkcjonalnego oprogramowania, czyli wykorzystanie tych części Lambda w AWS-ie, a w Azure Functions, gdzie tak naprawdę wkładamy jakieś małe elementy kodu, które mają zrobić tylko jedno zadanie. Więc mając to na uwadze, trzeba się czasami zastanowić, co chcemy zrealizować. 

Bo jeśli faktycznie ma to być oparte na zasadzie mikro serwisów w postaci funkcji czy lambdy, to Java w tym miejscu nie do końca nam się sprawdzi, bo czas rozgrzewania samego kompilatora, całej wirtualnej części, zajmuje trochę czasu. I to jest kilka mikrosekund, które gdzieś tam możemy tracić w porównaniu do Java Script, ale tak jak wspomniałeś, Bartku, Java ma bardzo dużo zalet. 

Dlatego nie warto się fiksować, że jest jedno panaceum na wszystko. Trzeba bardzo często dobrać język do tego, co chcemy zrealizować. Bo Java jest bardzo fajna i jak się już rozpędzi, to tak naprawdę bardzo dobrze sobie działa. Jeśli nie ma tam jakichś specjalnych rzeczy, dodatkowe wątki się nie odpalają, ale ona jest mniej więcej też stabilna w działaniu wtedy w odróżnieniu np. do słabo typowalnych Java Scriptu czy Pythona, nie wiemy, co się zadzieje za chwilę. Bo może być nagle wielki skok do konsumpcji, a może być też mniejszy, ale to jest coś za coś, trzeba wiedzieć, co dobierać do danego rozwiązania.

 

BW: Dokładnie. Bo to jest tak, że można zbudować dom za pomocą młotka, ale do jednego zadania potrzebny jest młotek, do drugiego śrubokręt, do trzeciego packa, żeby cement nałożyć. Można to wszystko robić młotkiem, ale można stosować różne wyspecjalizowane narzędzia. I podobnie jest właśnie z chmurą. I tak jak powiedziałeś, dostosować technologię do tego, co chcemy osiągnąć i Java ma też swoją niszę, swoje fajne zastosowanie, i za jej pomocą można też tworzyć nie tylko mikro serwisowe topologie całe, ale w lambdach (mówię tu o AWS-ie, czyli tych funkcjach serwer lessowych) też mogą znaleźć fajne zastosowanie, jeśli te lambdy np. przerabiają jakieś duże wolumeny danych i potrzebne jest tu duże przetwarzanie. 

A takie mniejsze funkcje, o jakich wspomniałeś, to świetnie np. działają te języki scriptowe, które mają minimalne lub żadne opóźnienia przy starcie. Więc zgadzam się z Tobą w 100%.

 

Myślę sobie, że doświadczonych architektów i deweloperów poznać po tym, że rozumieją, że narzędzia są tylko narzędziami. Z tego, co powiedzieliście, to Java lubi się z chmurą, ale oczywiście ma swoje przymioty. Ale ma też takie obszary, w których być może inne narzędzie sprawdzi się lepiej. I tutaj dużo zależy od tego, w jaki sposób to narzędzie wykorzystamy.

Idąc tym tropem, chciałbym Was zapytać, czy macie być może jakieś zidentyfikowane dobre praktyki, może jakieś code smells, na podstawie których jesteście w stanie powiedzieć, czy aplikacja napisana z wykorzystaniem Javy będzie mniej lub bardziej przyjazna środowisku?

 

ŁS: Naprawdę warto było przejrzeć sobie ten raport. On niestety jest napisany w języku francuskim, więc to nie jest takie super łatwe, ale teraz Google Translatory świetnie działają. Szczególnie że to jest dalej IT, więc często wiemy, co tam jest mniej więcej napisane, bo są tam bardzo konkretne przykłady, że taka a taka linka kodu powoduje takie i takie przełożenie, jeżeli chodzi o konsumpcję. Nawet nie trzeba czasami tłumaczyć tego, co tam jest napisane. 

Bardzo ciekawa też rzecz, na którą ja też swojego czasu nie zwracałem uwagi, to samo wykorzystanie if / else w stosunku do klasycznego switcha. W każdym języku programowania ta konstrukcja jest i jest to bardzo ciekawe, bo kiedy mam naprawdę mało tych if / else (powiedzmy, poniżej 5), to jest to jeszcze okej, jeśli chodzi o prędkość działania, a co za tym też idzie, zużycie CPU. 

Natomiast powiedziałbym, że optymalne jest wykorzystanie switcha, bo w momencie, kiedy program wpada nam w część switcha, to tak naprawdę ten switch ma od razu dostęp do wszystkich opcji, więc w tym momencie odpala się taka „wielowątkowość”. Chodzi o to, że taka odpowiedź ze switcha będzie szybsza niż z if / else. I jeśli mówimy konkretnie w kontekście konsumpcji energii, to w tym momencie switch jest lepszym rozwiązaniem, bo zadziała nam trochę szybciej i zeżre mniej CPU. Więc to jest taki jeden mały detal, warto sobie przejrzeć ten raport, bo ta jest naprawdę bardzo dużo reguł (ponad 200 do samej Javy).

 

BW: Inny klasyczny przykład, kiedy potrzebujemy stworzyć dłuższy ciąg tekstowy za pomocą konkatenacji, kleimy ze sobą kilka stringów w jeden, to nie używamy do tego stringa, tylko używamy StringBuildera albo StringBuffera. Ze względu na cechę i motability stringa. Wtedy używamy takiego buildera czy buffera w aplikacjach wielowątkowych, jeśli kilka wątków ma mieć do tego akces. 

Generalnie w mojej opinii ma bardzo dużo tych takich dobrych praktyk. Jeśli chodzi o pisanie kodu wydajnego energetycznie i zrównoważonego, bardzo dużo tych praktyk pokrywa się z generalnie dobrymi praktykami tworzenia kodu. Kodu optymalnego, kodu wydajnego, kodu łatwego w lekturze i kodu, który bardzo łatwo się rozszerza. Nie modyfikuje, tylko rozszerza. 

 

Inny klasyczny przykład, kiedy potrzebujemy stworzyć dłuższy ciąg tekstowy za pomocą konkatenacji, kleimy ze sobą kilka stringów w jeden, to nie używamy do tego stringa, tylko używamy StringBuildera albo StringBuffera. Ze względu na cechę i motability stringa. Wtedy używamy takiego buildera czy buffera w aplikacjach wielowątkowych, jeśli kilka wątków ma mieć do tego akces. 

 

I właśnie może istotne też jest tutaj, żeby powiedzieć, że niektóre z tych elementów (czy też może większość z nich, bo właściwie mam wrażenie, ze doszliśmy do takiego wniosku, że dobry, czysty kod jest automatycznie kodem wydajnym energetycznie), zastosowanie pipelinów w CICT jest takim statycznym sprawdzaniem tych elementów. Albo dodatkowymi regułami właśnie w kierunku przyjazności środowisku jest czymś, co praktycznie każdy zespół może zastosować. 

Jak jesteśmy przy zespole, to myślę sobie, że możemy wymyślać różnego typu zasady, świetne, zoptymalizowane technologie, ale jeśli zespół nie będzie chętny, żeby używać tych rozwiązań, to właściwie nic po nich. 

Więc chciałbym Was zapytać, czy wg Was programiście obecnie są świadomi wpływu, jaki aplikacje przez nich napisane mogą wywierać na środowisko, albo czy być może tego typu świadomość będzie się dopiero niedługo pojawiała. Co o tym myślicie?

 

BW: Ja myślę, że programiści są świadomi tego, że soft, który piszą, musi działać szybko i wydajnie. Natomiast myślę, że ta wiedza, w jaki sposób ta wydajność przekłada się na oszczędny energetycznie kod, nie jest jeszcze tak rozpowszechniona. Myślę, że to jest wiedza, którą należy popularyzować, poczekać na dobrą translację raportu. Chociaż zdałem maturę z francuskiego, to mogę troszkę pomóc. 

Wracając do tematu, uważam, że to jest wiedza, którą trzeba popularyzować, trzeba pokazywać przykłady takiego kodu, który optymalnie wykorzystuje zasoby, który pomaga w obniżeniu kosztów zużycia energii. Ale tak, jak wcześniej wspomniałem, często to się pokrywa z takimi ogólnymi zasadami pisania dobrego kodu i generalnie, jak zaczniemy uczyć programistów pisania dobrego, optymalnego kodu, będzie można do tego płynnie przejść do propagowania wiedzy o kodzie zrównoważonym

 

ŁS: Mamy już całkiem sporą wiedzę odnośnie do budowania tych oprogramowań CI/CD, co tam powinno być, a czego nie powinno być. Czasami brakuje tylko takiego wytłumaczenia dlaczego. Dlaczego to robimy. Bo zawsze można mieć tendencję do narzucania całkiem sporego zestawu reguł, bo to jest względnie prosto narzucić, stworzyć strasznie dużo ograniczników, natomiast ludzie nie lubią zbyt wielu ograniczeń, nie wiedząc, dlaczego to się dzieje. 

Każdy z nas pamięta, jak był mały, pytał, dlaczego, dostawał odpowiedź: bo tak. Teraz jesteśmy dorośli i trochę w inny sposób nam przekazują tę samą informację: dlaczego? – bo tak. Bo tak mają działać reguły. Trzeba też tłumaczyć dlaczego. Jako deweloperzy, jako informatycy jesteśmy coraz bardziej świadomi tego, co robimy, i chcemy tak naprawdę wiedzieć, dlaczego to robimy. Dlatego też warto szerzyć tę wiedzę, dlaczego np. ten green IT jest taki istotny i w jaki sposób się to przekłada na życie nas wszystkich. Nie jest to namacalne, ale taka wiedza byłaby istotniejsza niż narzucanie zestawu reguł i wytykania palcem: patrz, nie przechodzi ci virt, popraw to.

 

Chciałbym Was teraz zapytać o zapotrzebowanie na programistów Javy, bazując na Waszych doświadczeniach w Capgemini. Ale takich programistów Javy, którzy również mają te kompetencje chmurowe. Czy kiedy te osoby są przyjmowane, tom zauważacie, że te umiejętności chmurowe czy związane z chmurą obliczeniową również są? Pytam dlatego, że do tej pory bardzo często myślano o takim klasycznym podziale osób, które zajmowały się programowaniem, deweloperką, i osób, które zajmowały się, ogólnie rzecz biorąc, chmurą czy też utrzymaniem. Teraz już wiemy, że te kompetencje jednak się przenikają i zgodnie z takim duchem DevOpsowym dobrze jest je łączyć. Jakie doświadczenia z tym ma Capgemini?

 

BW: Tak, zapotrzebowanie na programistów Javy jest ogromne. Z tego względu, że z Javy korzysta wielu naszych klientów, wielu klientów buduje systemy oparte o cały ekosystem javowy, a to oznacza, że ten język ciągle jest żywy, ciągle jest wybierany przez klientów. 

Większość naszych klientów też przenosi albo już przeniosła swoje systemy w chmury. Tak że programiści javowi z umiejętnościami pracy w chmurze są jeszcze milej widziani. Ale jeśli tych umiejętności związanych z pracą w chmurze brakuje, my pomagamy je nabyć. Pomagamy w przeszkoleniu, w zdobyciu certyfikatów. Mamy ścieżki szkoleniowe, więc to nie jest problem. Wystarczy, żeby kandydat znał Javę, umiał programować, a my z chęcią pomożemy w rozwoju. 

Natomiast odpowiadając na drugą część Twojego pytania, z mojej perspektywy to jest tak, że nie ma i nigdy nie było programisty, który ograniczałby się tylko do znajomości języka. Każdy język to jest jednak pewne środowisko – wdrożeniowe, uruchomieniowe, które trzeba znać. Kiedyś mieliśmy J2E, to było to JBoss, Glashfish do obsługi jako pełne kontenery J2E. A potem wszedł Spring, ale jakoś zdebuggować Tomcata, czemu mi się nie chce uruchomić, czemu moja WARka się nie zdeployowała poprawnie. Każdy deweloper musiał umieć takie rzeczy. 

Teraz mamy tę chmurę, czy nawet jeszcze wcześniej, jak wrzucaliśmy jakieś monolity na farmę, na wirtualną maszynę, będącą gdzieś na farmie. Też kwestia podstawowej znajomości troubleshootingu czy deploymentu była jednak wymagana. Teraz mamy chmurę i DevOpsi dalej są potrzebni do chmury z tego względu, że chmura udostępnia różne rzeczy, ale trzeba pokonfigurować regiony, pokonfigurować konta, subnety, sieci, routingi itd. Natomiast my jako deweloperzy możemy bardzo blisko współpracować z DevOpsami w tej kwestii i nawet przykład Amazonu. 

Amazon wypuszcza taki framework do pracy, do tworzenia i usprawnienia aplikacji chmurowych, AWS CDK. Są też inne frameworki na Amazona. One de facto umożliwiają nam tworzenie czego, co się nazywa Infrastructure as a Code. Tzn. ja nie muszę wchodzić przy każdym deploymencie na chmurę, tylko robię to, co każdy programista lubi. Dostaję pewne Api, pewne biblioteczki i sobie z nich korzystam. Oczywiście jakiś najprostszy troubleshooting , trzeba wejść, sprawdzić w logach, co się dzieje. W mojej opinii każdy deweloper powinien umieć robić takie rzeczy i u nas jest to pewna norma, pracujemy z tym na co dzień, więc to nie jest nic nowego, że trzeba coś wiedzieć o tym, co się dzieje dookoła. To jest coś, co było od zawsze.

 

ŁS: Warto też dopowiedzieć, że nasz model jest oparty na tym, że dostarczamy całe zespoły, a co za tym idzie, zespół jest interdyscyplinarny, czyli tak naprawdę ma całą plejadę różnych ról i tak naprawdę poszukujemy też takich osób, które są w stanie zapełnić te różne role, czyli np. rolę Screw Mastera ze znajomością technicznego elementu aplikacji, osoby, które są bardziej DevOpsami trochę, ale znają się też na developments, osoby, które zajmują się testowaniem i oczywiście też programowanie. 

Chodzi o to, ze coraz częściej jest tak, że klienci, jak składają zapotrzebowanie na stworzenie aplikacji, to bardzo często składają zapotrzebowanie na szeroko pojęty DevOps. Klient różnie może rozumieć, co się kryje pod pojęciem DevOps, ale częściej pojawia się taka informacja, że dla klienta DevOps to jest osoba, która jest w stanie napisać aplikację, przetestować, stworzyć infrę i zdeployować tę aplikację. Natomiast jest różna wiedza, wszystko zależy od konkretnego projektu. Ale poszukujemy osób, które są w stanie dopasować się do różnych ról w projektach, gdzie Java jest głównym elementem napędzającym. Więc to jest całkiem spore spektrum ról, ale wokół takiej technologii, jaką jest Java.

 

Domyślam się, że w takich zespołach cross funkcjonalnych poszukujecie nie tylko specjalistów Javy czy specjalistów od chmury, Slash, DevOpsów, ale również wielu różnych ról wspomagających.

 

BW: Owszem, bo Java to typowo backendowy język. Kiedyś były próby robienia widoków za pomocą Javy, słynny Vaadin na przykład, JSP, JSF itd. Teraz się z tego wycofaliśmy jako deweloperzy Javy, bo mamy od tego bardzo dobre frameworki javascriptowe oparte na Java Script, mamy Dupe Script, mamy Angular, React View itd. Tak że frontendowców też poszukujemy, też by się przydali do pracy. Specjalistów do testów, zarówno manualnych, jak i automatycznych. 

Bo kiedy mówimy o chmurze, to skupiamy się głównie na deweloperach, którzy tworzą te lambdy czy mikroserwisy, czy jeszcze inne rzeczy, natomiast to jest, tak jak Łukasz powiedział, cała grupa ludzi, która dba o to, żeby ten software był wyprodukowany w jak najlepszej jakości, zarówno od wyglądu, UX Designerzy, testerzy, analitycy, którzy zajmują się pozyskiwaniem wymagań funkcjonalnych od klientów, którzy próbują te wymagania przekuć na user stories, które nam ułatwiają pracę, więc dużo różnych ról jest potrzebnych wokół chmury. Zespoły cross funkcjonalne, o których mówił Łukasz, które są w stanie wykonać całą robotę. Więc my jako firma czy jako dział financial services nie jesteśmy tylko dla programistów Javy. Dostarczamy jakość dzięki temu, że dostarczamy zespoły pełne zupełnie różnych ludzi.

 

Java to typowo backendowy język. Kiedyś były próby robienia widoków za pomocą Javy, słynny Vaadin na przykład, JSP, JSF itd. Teraz się z tego wycofaliśmy jako deweloperzy Javy, bo mamy od tego bardzo dobre frameworki javascriptowe oparte na Java Script, mamy Dupe Script, mamy Angular, React View itd. Tak że frontendowców też poszukujemy, też by się przydali do pracy. Specjalistów do testów, zarówno manualnych, jak i automatycznych. 

 

Myślę, że nic tak nie przyciąga, jak dobre, ciekawe i fajne projekty. Może bez wchodzenia w zbędne szczegóły, ale powiedzcie , z jakimi projektami mogą mieć do czynienia osoby, które pracują u Was w tego typu zespołach nad aplikacjami opartymi o Javę w chmurze?

 

BW: Są różne takie projekty. Jak sama nazwa naszego biznesu wskazuje, wszystko kręci się w sektorze usług finansowych, financial services. Ale co to znaczy? To znaczy, że pomagamy głównie bardzo dużym instytucjom, dużym bankom, ubezpieczycielom. Pomagamy im tworzyć ich systemy wewnętrzne, które przede wszystkim muszą być skalowalne, bezpieczne, szybkie. Kiedy mówimy o jakichś systemach opartych o giełdę, to mówimy tu już o Hyper-threadingu, więc bardzo szybkie mielenie ogromnych wolumenów danych jest niezbędne i tam się każda mikrosekunda liczy. Więc mamy dużą różnorodność projektów sektora finansowego i zależnie od klienta mamy też dużo wspomagających technologii, czyli poza samą Javą jeden klient będzie używał Spriga, drugi będzie używał Quercusa, jeden klient będzie używał chmurę Amazona, drugi chmurę Azure, czyli z Microsoftu, która też jest, wspiera i bardzo dobrze współpracuje z Javą. 

Więc jest w czym wybierać. Technologie w projektach mogą być różne, od jakichś backendowych systemów transakcyjnych, systemów do raportowania, poprzez systemy wspierające pracę w poszczególnych działach, od średnich po bardzo duże, rozbudowane systemy, gdzie każdy znalazłby miejsce dla siebie i może nie tylko od siebie coś dać, ale myślę, że każdy może się naprawdę sporo nauczyć.

 

ŁS: Warto dodać, że klienci są z tego powodu, że firma jest całkiem spora, mamy swoje oddziały w 50 krajach, to też mamy w Polsce jako delivery klientów tak naprawdę z całego świata. Zaczynając od naszego podwórka, czyli jeśli chodzi o Europę, to mamy klientów z Niemiec, Holandii, Wielkiej Brytanii, Włoch, Szwajcarii, z krajów skandynawskich. Dodajmy jeszcze Stany Zjednoczone, Kanadę, więc tak naprawdę tych krajów jest całkiem sporo, a mówimy tylko o delivery jeśli chodzi o samą Polskę. Więc to jest też miejsce na taką faktycznie pracę z dużymi klientami, z dużym portfolio, a co za tym też idzie, na różnych poziomach. Czyli projekty od frontendu po backend, po bazę danych, projekty związane z wirtualizacją systemów, projekty z migracją, więc przekrój jest całkiem spory z tego powodu, że firma jest też całkiem spora i ma dużo kontaktów na całym świecie.

 

Jestem przekonany, że każdy znajdzie tam interesującą dla siebie część tego technologicznego tortu, a ja Wam za dzisiaj bardzo dziękuję . Łukasz Stefaniszyn i Bartłomiej Wasiuk z działu financial services w Capgemini Polska byli moimi gośćmi. Rozmawialiśmy o tworzeniu przyjaznych środowisku i opartych o chmurę aplikacji w Java.

Łukasz, Bartek, bardzo Wam dziękuję za rozmowę.

 

ŁS: Dzięki.

 

BW: Dziękujemy.

 

W notatce do tego odcinka znajdą się linki do Capgemini Polska oraz do raportu, o którym Łukasz wspomniał podczas naszej rozmowy.

Bardzo Wam jeszcze raz dziękuję.

Do usłyszenia! Cześć!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Po więcej wartościowych treści zapraszam Cię do wcześniejszych odcinków. A już teraz, zgodnie z tym, co czujesz, wystaw ocenę, recenzję lub komentarz w aplikacji, której słuchasz lub w social mediach. 

Zawsze możesz się ze mną skontaktować pod adresem krzysztof@porozmawiajmyoit.pl lub przez media społecznościowe. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tworzeniu przyjaznych środowisku i opartych o chmurę aplikacji w Java. Zapraszam do kolejnego odcinka już wkrótce.

Cześć!

 

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
Tags:
,
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się web-developmentem i zarządzaniem działami IT. Dodatkowo prowadzę podcast, kanał na YouTube i blog programistyczny. Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.