var Sovia = new Tech();

29 Marca odbyła się w Warszawie konferencja VarSoviaNewTech organizowana przez Polski oddział firmy Microsoft. Chodź nie było o niej głośno i organizowana była chyba w pośpiechu, gdyż rejestracja ruszyła 3 tygodnie przed samym wydarzeniem, to muszę przyznać, że była to jedna z najbardziej profesjonalnych konferencji, na jakich byłem do tej pory. Największą niespodzianką był fakt, że miał na niej prezentować sam Satya Nadella, szef Microsoftu. Sam się na początku zastanawiałem, czy to nie jest jakiś chwyt marketingowy, ale wszystko wskazywało na to, że jednak jest to prawda i będzie można zobaczyć, posłuchać CEO największej firmy komputerowej na świecie – na żywo.

Poniżej możecie obejrzeć skrót z konferencji, który zmontowaliśmy razem z moją drugą połówką. Mam nadzieję, że zachęci on Was do przyjścia na kolejną konferencję 🙂

Organizacja

Konferencja odbyła się w Muzeum Historii Żydów Polskich. Wspaniałym budynku, do którego można dojechać w 15 min z Dworca Centralnego. Chodź organizatorzy zalecali przyjazd o 8:30 to nawet moje godzinne spóźnienie nie zmieniło faktu, że miałem dużo czasu na zapoznanie się ze wszystkimi atrakcjami, jakie przygotowali na miejscu. Na początek, przez półtorej godziny można było pozwiedzać stanowiska firm, rozwijających aplikacje na HoloLens i zobaczyć magię hologramów na własne oczy. Dodatkowo, jeśli ktoś już się znudził hologramami, były do dyspozycji Xboxy oraz Surface-y, na których można było porozwiązywać zagadki z CodeHunt.

Prezentacje były prowadzone w bardzo ciekawy sposób. Pojawiło się trochę faktów i liczb, ale praktycznie każdy prelegent pokazywał jakieś krótkie dema i kawałki kodu. Bardzo fajne było również to, że prezentacje trwały około 30 min, więc prelegenci zmieniali się bardzo szybko, a słuchacze byli cały czas zaciekawieni. W połowie dnia wystąpił w końcu gość specjalny. Przez ponad 45 minut, Satya opowiadał o tym, w którą stronę zmierza Microsoft oraz pokazywał na przykładach, jak w Polsce prężnie rozwijają się firmy korzystające z rozwiązań Microsoftu. Pokazywał również jakie okazje stoją przed nami, programistami, aby zmienić otaczający nas świat.

Czego się dowiedziałem

  1. Do tej pory myślałem, że HoloLens to tylko gadżet, który podobnie jak okulary VR służy do zabawy, ewentualnie Microsoft tworzy aplikacje na ten sprzęt, aby pokazać je na demach i zachęcić innych do kupna. Prawda natomiast jest taka, że istnieje całkiem duży rynek aplikacji na te urządzenia i całkiem sporo startupów wybija się tworząc aplikacje holograficzne. Przykładem korporacji, korzystających już z HoloLensów może być Volvo. Sam sprawdziłem działanie hologramów i muszę przyznać, że robi wrażenie, gdyby udało się same okulary zminiaturyzować, żeby nie nosić takiego hełmu na głowie to by było coś!
  2. Dowiedziałem się, że Gutek woli .NET Framework od .NET Core 😉 A tak na serio, to Kuba i Bojan Vrnhovnik pokazali różnicę między starym a nowym rozwiązaniem. Na pierwszy rzut oka było widać, że stary framework jest bardzo dopracowany i spełnia większość wymagań programistów, ma jednak również wady. Jest mniej elastyczny i działa tylko pod Windowsem. Osobiście uważam, że .NET Core jest rozwiązaniem, które zastąpi całkowicie .NET Framework, potrzeba tylko jeszcze trochę czasu na dopracowanie samego frameworka jak i narzędzi, takich jak VSCode.
  3. Na prezentacji Karola Żaka można było zobaczyć jak połączyć ze sobą wiele serwisów do zarządzania cyklem życia aplikacji mobilnych pisanych w Xamarin. Pokazał integrację pomiędzy Visual Studio Team Services, Xamarin Test Cloud oraz HockeyApp, by na końcu powiedzieć, że nie trzeba wcale tych rozwiązań integrować samemu, bo powstaje nowe rozwiązanie mobile.azure.com, które łączy je wszystkie. Dlaczego w takim razie nie pokazać tego wszystkiego już na nowym rozwiązaniu?
  4. Dowiedziałem się o sile botów oraz o tym, kiedy napisanie bota jest rozsądniejsze niż napisanie własnej aplikacji mobilnej. Boty działają wszędzie, korzystając z takich aplikacji jak skype, czy messenger można napisać własny serwis, który będzie odpowiadać na wiadomości użytkowników na każdym urządzeniu. Ponadto boty mogą również rozpoznawać mowę, dzięki czemu można ich używać nawet prowadząc samochód, czy biegając.
  5. Nawiązując do poprzedniego punktu, zastanawiacie się jak można rozpoznawać mowę, nie pisząc samemu bardzo skomplikowanych algorytmów? Tutaj z pomocą przychodzi ostatnia rzecz, o której dowiedziałem się na konferencji. Mianowicie, Azure może pochwalić się całkiem dużym zasobem Cognitive Services – serwisów, które mogą za nas zdziałać cuda. Pośród oferowanych aktualnie serwisów jest: rozpoznawanie mowy i twarzy, określanie wieku lub emocji, a także serwis rekomendacji, który można podpiąć do własnego sklepu internetowego.

Ogólna ocena konferencji

Konferencję oceniam bardzo dobrze. Prelegenci pokazali wszystko o czym mówi się ostatnimi czasy i każdy mógł znaleźć coś dla siebie. Z racji tego, że prezentacje były krótkie, nie przekazano na nich jakiejś dużej wiedzy merytorycznej, ale na pewno zainspirowano do dalszego jej zgłębiania. Mam nadzieję, że nie będzie to jednorazowa edycja i za rok Microsoft również zorganizuje coś podobnego, bo dawno nie byłem na tak dobrej konferencji.

Ocena:

Jak dostać pracę jako Junior Software Developer.

Zaczynasz swoją przygodę z programowaniem za pieniądze i szukasz firmy, która spełni Twoje oczekiwania, a jednocześnie chcesz wypaść jak najlepiej na rozmowie kwalifikacyjnej? Czytaj dalej a dowiesz się tego oraz wiele więcej.

Ostatnimi czasy rynek pracy dla programistów jest tak chłonny, że każdy znajdzie coś dla siebie. Niekiedy należy się jednak zastanowić, czy warto iść do pracy, w której biorą programistów „jak leci”, bez żadnego sprawdzenia ich umiejętności. Moim zdaniem, im trudniejsza rozmowa kwalifikacyjna, tym większa ochota na pracę. Jeśli firma dobrze sprawdza kompetencje kandydatów, to istnieje duża szansa, że będzie się pracować z najlepszymi. Ale jak pokazać, że należy się właśnie do nich?

1. Dowiedz się w jakich technologiach prowadzone są projekty.

Przede wszystkim należy dowiedzieć się, czego pracodawca wymaga od kandydata. Z ogłoszenia o pracę należy wyłapać technologie, z którymi pracują programiści w tej firmie. Najczęściej pracodawcy podają znajomości jakich technologii wymagają od kandydata oraz znajomość jakich będzie atutem. Wypisz sobie wszystkie jakie znalazłeś w ogłoszeniu. Może to być jakaś konkretna baza danych (MSSQL), framework (ASP.NET WebApi), czy biblioteki JavaScriptowe (Angular, React). Postaraj się przyswoić przynajmniej podstawy tych technologii. Włącz sobie jakiś tutorial i zapamiętaj co ważniejsze kwestie. Jeśli jakaś technologia znajduje się w ofercie pracy, to na rozmowie, na 90% o nią zapytają. Jeśli popiszesz się znajomością chociaż podstaw, ale ze wszystkich, to już znajdziesz się na uprzywilejowanej pozycji i będziesz postrzegany jako osoba pasująca do tej firmy.

2. Przypomnij sobie zagadnienia teoretyczne

Na rozmowie kwalifikacyjnej bardzo często pierwszym testem sprawdzającym kandydata są pytania teoretyczne.  Dlatego właśnie, przed taką rozmową należy przypomnieć sobie kilka książkowych kwestii. Takich jak:

Oczywiście istnieją też firmy, w których pytają Cię o to jak coś jest zrobione „pod spodem” czyli coś, co dla programisty nie jest widoczne gołym okiem. Przykładem takiego pytania jest: jak kompilator interpretuje sobie funkcje anonimowe (tak spotkałem się z takim), ale już bez przesady jeśli nie będziesz wiedział czegoś takiego, nikt Cię za to nie potępi.

3. Przygotuj sobie pytania od siebie

Na początku mojej kariery, najgorszy moment rozmowy był wtedy, gdy ktoś po przeciwnej stronie stołu zapytał się czy mam do niego jakieś pytania. Wiedziałem, że powinienem o coś zapytać, żeby pokazać, że zależy mi na konkretnym stanowisku, a nie dlatego, że przyszedłem tam, bo ich oferta była najwyżej na stronie, ale nic nie przychodziło mi do głowy. Dopiero po jakimś czasie, ucząc się na błędach dowiedziałem się o co pytać, żeby nie wdepnąć w projekt, z którego szybko będziesz chciał uciec. A więc, o co pytać?

  • Zapytaj się o proces w jakim rozwijane są projekty. Jeśli odpowiedzą Ci, że pracują w Agile to poproś o wyjaśnienie jak dokładnie wygląda stosowanie tego w firmie. Czasami firmy mówią, że pracuje się u nich Agile-owo, bo to modne, ale nie są w stanie uzasadnić jak dokładnie to wygląda, wtedy powinna zapalić się pierwsza lampka ostrzegawcza, że coś w tej firmie jest nie tak.
  • Dowiedz się czy posiadają środowiska testowe, stageowe do testowania różnych wersji aplikacji. Środowisko deweloperskie, testowe dla testerów (stage) oraz produkcyjne to minimum jakie powinno być przy komercyjnych projektach. Jeśli programiści wrzucają poprawki kodu bezpośrednio na serwer produkcyjny bez jakiegokolwiek testowania to nie tak to powinno wyglądać.
  • Zapytaj się jak testują kod, czy programiści piszą testy jednostkowe, czy mają oddzielny zespół testerów. Jeśli w odpowiedzi dostaniesz „nasza aplikacja zbyt szybko się rozwija, żeby do niej pisać testy jednostkowe” lub „nasi klienci testują aplikacje na produkcji” to zastanów się zanim tam pójdziesz pracować.
  • Dowiedz się jak dbają o rozwój pracowników. Karta multisport i prywatna opieka zdrowotna to nie to o co mi chodzi. Jeśli pracujesz z konkretnymi technologiami to, żeby nie zawęzić sobie horyzontu co jakiś czas powinieneś rozwijać się w innych dziedzinach i poznawać inne technologie. Dlatego firma powinna Cię w tym wspierać i tak na przykład niektóre firmy finansują dostęp do pluralsight’a czy wyjazdy na konferencje.
  • Jeśli aplikacja, przy której będziesz pracować działa już produkcyjnie, dowiedz się jak jest z jej utrzymywaniem. Czy nie będzie tak, że przez pierwsze pół roku będziesz naprawiał bugi przy starej aplikacji, a nie napiszesz nic nowego. Najgorsze co może być to naprawianie nieswoich bugów.

Ponadto polecam 12 zasad lepszego kodu, które wymyślił i spisał Joel Spolsky, jeden z twórców StackOverflow. Polecam spisać sobie te pytania i pytać pracodawców o każdy punkt, im więcej punktów spełniają, tym lepiej jest u nich pracować.

4. Sprawdź czy ktoś z firmy nie mógłby Cię polecić.

W wielu firmach prężnie poszukujących programistów, działa system poleceń. Jeśli osoba z firmy poleci swojego znajomego, a ten dostanie pracę i utrzyma się 3 miesiące, to dostanie bonus pieniężny. Zastanów się więc, przejrzyj jeszcze raz znajomych na facebooku/linkedin czy w firmie, w której chcesz pracować nie ma żadnego Twojego znajomego. Jeśli jest, pogadaj z nim o tym jak pracuje się w jego firmie i poproś o przesłanie swojego CV do kogoś z działu HR. Twój znajomy na pewno chętnie to zrobi licząc na bonus pieniężny, a Ty nie będziesz kolejnym kandydatem z ulicy, a już kimś poleconym, więc wartym przesłuchania.

Mam nadzieję, że powyższe punkty pomogą Ci dostać wymarzoną pracę. Myślę, że w chwili obecnej jest tyle ofert dla programistów, że nie ma co brać pierwszej, która wpadnie Ci w ręce. Lepiej pójść na kilka rozmów, zobaczyć jakie są różnice pomiędzy ofertami i wybrać najodpowiedniejszą dla Ciebie. Jeśli miałeś jakieś ciekawe historie podczas rozmów rekrutacyjnych podziel się nimi w komentarzach 🙂

Typowe błędy programistów.

Pisałem już kiedyś o błędach popełnianych przez młodych programistów. Byłem wtedy na początku swojej programistycznej kariery i myślałem, że już dużo wiem. Teraz wiem ile jeszcze nie wiem 😉 Niemniej jednak z większością z tamtych punktów zgadzam się do dziś. Postanowiłem więc, po kilku latach jeszcze raz zebrać kilka najczęstszych błędów, które zauważyłem już w aplikacjach enterprise. Poniższe punkty nazwałem błędami architektonicznymi, czyli odnoszącymi się bezpośrednio do kodu programu. Jak wiadomo praca programisty składa się jeszcze z wielu innych aktywności, ale o nich napiszę w innym poście.

1. Nadużywanie statycznych metod

Statyczne metody nie powinny być zbyt często używane. Programiści często idą na skróty i dopisują funkcje statyczne, które zawierają logikę biznesową bądź zmieniają stan aplikacji. Logika biznesowa w metodach statycznych to najgorsze, co może być. Dlaczego? Dlatego, że dla takiej metody jest bardzo trudno napisać jakikolwiek test jednostkowy. Metody statyczne powinny być używane dla bardzo prostych helperów, służących tylko do prostych obliczeń, niewymagających testowania. Chodź i tak do tego lepiej nadają się extension methods. Przykład błędnego użycia metody statycznej znajdziecie poniżej.

var user = User.GetUserById(userId);

public class User
{
    public static User GetUserById(int userId)
    {
        //Implementation
    }
}

Zamiast tego powinno się używać serwisów, które mogą być wstrzyknięte poprzez DI i z łatwością zmockowane.

2. Niekorzystanie z interfejsów

Punkt ten często wiąże się z poprzednim, gdyż metod statycznych nie można umieścić w interfejsie. Często myślimy, że jeśli aktualnie do dostępu do bazy używamy ADO.NET, to tak będzie już zawsze i tworzymy metody pobierające/zapisujące dane w klasie, do której odwołujemy się bezpośrednio. Niestety takie podejście ma bardzo wiele wad. Przede wszystkim, tak samo jak w przypadku metod statycznych bardzo ciężko jest testować taki kod. Nie można stworzyć żadnego mocka, który symulowałby nam dostęp do bazy danych. Drugim problemem z tym związanym jest brak możliwości zmiany aktualnie używanego rozwiązania. Jeśli już w całym programie używa się bezpośrednich połączeń do metod z ADO.NET, to nie przepiszemy wszystkiego na Entity Framework w jeden tydzień.

To co powinno się robić, to używać interfejsów zawsze. Nawet jeśli sposób implementacji w danym momencie jest tylko jeden.

3. Wrzucanie funkcji do jednego worka

Jeśli myślimy zbyt obiektowo, nadchodzi czas gdy biznes przerasta nasze obiektowe pojęcie. Wtedy właśnie zdajemy sobie sprawę, że nasza klasa User trochę się rozrosła i każda operacja mająca cokolwiek wspólnego z użytkownikiem, nie powinna znajdować się w tej jednej klasie. Często osoby, które nie stosują żadnych wzorców architektonicznych, popadają w pułapkę klas Bogów. Zamiast myśleć o obiektach jako encjach bazodanowych, należy pomyśleć o obiektach w kontekście biznesu. Bardzo przydatna w zrozumieniu tego zagadnienia jest książka Domain Driven Design. Pomocne w rozdzieleniu funkcji mogą być również wzorce projektowe, takie jak CQRS.

4. Wykorzystywanie tych samych DTO w wielu, niepowiązanych miejscach.

Najtrudniejsze w programowaniu jest wymyślanie nazw. Dlatego często idziemy na łatwiznę i nadajemy nic nie znaczące nazwy. Załóżmy, że mamy klasę do edycji użytkownika, więc nazwiemy ją UserDto. Po kilku miesiącach zapominamy, piszemy inną funkcjonalność i dajmy na to, że musimy wyświetlić wszystkich użytkowników z daną rolą. Jakiej klasy użyjemy? Prawdopodobnie UserDto, pomijając, że klasa ta posiada znacznie więcej pól niż potrzeba przy prostym wyświetleniu użytkowników. Jest to kolejny błąd, który ciężko naprawić, bo im więcej odwołań do danej klasy tym ta klasa jest trudniej edytowalna.

5. Pisanie nieczytelnych funkcji

Temat pisania nieczytelnych funkcji, poruszany jest w wielu wątkach i opisywany w niejednej książce, mimo to myślę, że wciąż są problemy z czytelnym pisaniem funkcji. Przede wszystkim problemy występują w instrukcjach warunkowych, które potrafią być całkiem sporym kawałkiem logiki. Istnieje nawet kampania anty-ifowa, której członkowie namawiają do programowania bez użycia instrukcji if oraz switch. Nie jestem za popadaniem ze skrajności w skrajność i wiem, że czasami użycie if jest czytelniejsze niż przerobienie architektury, niemniej jednak należy zwrócić uwagę na to, czy inni programiści zrozumieją, kiedy kod wchodzi do bloku if.

Poniższy przykład pokazuje świetnie ewolucje oprogramowania. Pierwsza linijka jest akceptowalna, bo to tylko jeden warunek, do tego w miarę czytelny i logiczny- ma pieniądze, więc może kupić. Po dodaniu funkcjonalności ról, umieszczamy kolejny warunek i już zaczyna się robić mało czytelnie. W tym momencie powinniśmy opakować cały warunek w jakąś ładnie brzmiącą metodę. Niestety wiele razy widziałem, że ostatni krok jest pomijany i zostaje taki tasiemiec z instrukcji warunkowych, nad którym trzeba spędzić kilka minut, żeby go zrozumieć.

// this is readable
if (user.AccountBalance >= productCost) { }

// we add Roles to program and code is ugly
if (user.AccountBalance >= productCost && user.Roles.Any(r => r.AllowInAppPurchases)) { }

// after refactor it is better
if (user.CanBuyProduct(productCost)) { }

To tylko kilka uwag, które zamierzałem przedstawić, żeby przestrzec innych. Często w pośpiechu sam zapominam o niektórych zasadach, ale mam nadzieję, że dzięki opisaniu ich tutaj, sam zacznę się bardziej pilnować. 🙂