Maciej Aniserowicz's Blog, page 37

Wednewsday #20 – programistyczne nowinki

Cześć i czołem. Zapraszam na kolejną porcję ciekawostek. W tym tygodniu wybrałem dla was 12. Enjoy!

The complete elimination and eradication of JavaScript’s this – pozbądź się ‘this’ z JS’a … ileż to programistów przez to cierpiało bóle, męki …
StoragePedia: An Encyclopedia of 5 Blockchain Storage Platforms – w artykule znajdziecie powiązanie do dwóch innych ‘Pedi’ – ConsensusPedia oraz ContractPedia
15 Engineers Building the Tech of the Future – trochę spoza obszaru IT. Poznajcie 15 przełomowych wynalazków i inżynierów pracujących nad nimi.
Escaping tutorial purgatory as a new developer – tak dla przypomnienia zanim wpadniecie w szał powakacyjnego nadrabiania wiedzy.
Software Security is a Programming Languages Issue – because all programmers need to know something about security! Zdecydowanie polecam. Jest trochę mięsnie ale dacie rade!
The Problems and Promise of WebAssembly – czyli dlaczego wprowadzenie kodu binarnego do przeglądarki może stanowić problem.
FASTER: An Embedded Concurrent Key-Value Store for State Management – Microsoft udostępnił nowy storage typu klucz-wartość
Google’s ARCore, an SDK for augmented reality developers: Cheat sheet – może nie taki typowy ‘cheat sheet’ ale i tak spora garść informacji na temat Augmented Reality na Androida.
eBay Announces New APIs and AI Capabilities for the Developer Community
Introducing Sonatype DepShield: Free for GitHub Developers – darmowa aplikacja dostępna dla projektów na GitHub informująca o lukach wykrytych w OSS.
How To Write Unmaintainable Code – poradnik jak zapewnić sobie pracę na całe życie ;)
Want to attend a full MIT course on Computer Science and Programming? – jest akademicko :)

Zapraszam również do śledzenia audycji podcastowej, w której prezentuję najnowsze wiadomości, ciekawostki, wpadki oraz wydarzenia ze świata IT:

http://devsession.pl/podkast/

The post Wednewsday #20 – programistyczne nowinki appeared first on devstyle.pl.

Prowadzisz bloga? Oto Twoje zbawienie: CoSchedule

W moim życiu social media mają dwie strony: prywatną i marketingową. Prywatnie: utrzymuję kontakt ze znajomymi i dzielę się swoimi refleksjami. Marketingowo: promuję “devstyle” i wszystko co z tym terminem związane.

Fair enough.

Manual vs auto

Do niedawna wychodziłem z założenia, że wszystko w socialach “powinno” być robione ręcznie, by nie utracić autentyczności i szczerości. A to… generowało wiele problemów. Życie stało się o wiele prostsze, gdy wykrystalizował się wspomniany wyżej podział.

Prywatnym zastosowaniom sociali nie zależy na zasięgach, na “odpowiednim czasie publikacji”, na numerkach i klikach. Tam pierwsze skrzypce grają emocje. U mnie tak działa większość mojego Twittera, prywatne konto na fejsie (od niedawna) i Instagram (a wcześniej Snapchat). W skrócie: na “prywatnych” socialach nie zarabiam. I do nich faktycznie pięknie stosuje się zasada: serducho i własne palce, a nie bezduszny automat.

Ale druga strona medalu to sociale “zawodowe”. Fanpage, “promocyjna” część Twittera czy LinkedIn… one służą do promowania treści i docierania do jak największej rzeszy odpowiednich osób. To część pracy. A im mniej pracy, tym lepiej, c’nie? ;). No właśnie. I tu jest social pogrzebany.

W przypadku devstyle stało się to o tyle istotne, że od kilku miesięcy z “bloga” zrobił się “portal” i nasze teksty są teraz pisane przez wiele par rąk, a nie tylko moje. Jeszcze do niedawna nastawiałem budzik (sic!), żeby o odpowiedniej godzinie puścić na fanpage informację o nowym tekście. Uwiązany do komputera, przyciśnięty do wirtuala, skuty cyber-kajdanami.

Oczywiście wiem, że da się “zaschedulować” treści na przyszłość. Ale – w przypadku facebooka czy LinkedIn – dopiero, gdy post na WordPress jest już opublikowany, co mocno sprawy komplikuje.

I wtedy, na białym rumaku, dumnie wjeżdża…

CoSchedule

O CoSchedule dowiedziałem się ze SmartPassiveIncome (a z Patem z SPI miałem niedawno zaszczyt porozmawiać przed mikrofonami :) ). Najpierw temat olałem, ale w końcu coś mnie tknęło i… postanowiłem sprawdzić.

Jest to narzędzie do “ogarniania” sociali. Miałem wcześniej romans z dwoma innymi programami tego typu, ale się nie polubiliśmy. Dlatego też tym razem podchodziłem do sprawy bardzo sceptycznie. Ba, umówiłem się nawet na skype z zaoceanicznym supportem, żeby porozmawiać o tym rozwiązaniu, zanim się w nie zaangażuję!

Porozmawiałem. Poznałem. Zaangażowałem się. Uzależniłem się. Wykupiłem i zostałem klientem. A teraz polecam dalej.

Dlaczego? Poniżej pokażę trzy funkcje, z których korzystam regularnie. CoSchedule oferuje ich więcej, ale mi na razie wystarcza tylko to. Zaoszczędziłem dzięki temu masę czasu. I – co dla mnie ostatnio bardzo ważne – odzyskałem odrobinę wolności.

Zobaczcie:

Po pierwsze: promocja postów

Napisanie tekstu to jedno. Potem trzeba go puścić na WordPressa i… wypromować, oczywiście! Tej części nigdy nie lubiłem. Skakania po oknach, pilnowania odpowiednich godzin… Eh.

Teraz? CoSchedule daje plugin do WordPressa, dzięki któremu kilkoma kliknięciami planuję wysyłkę informacji o tekście na wszystkie swoje kanały:

Siup! Bezpośrednio z widoku edycji posta.

Ale to nie wszystko, bo… po co tyle klikać? Można zapisać sobie szablon (social template), który jednym klikiem zaplanuje wiadomości w odpowiednich godzinach na różne kanały:

Potem tylko wypełniam teksty (moje własne placeholdery: txt1, txt2 i tags) i… i już! Gotowe!

Oczywiście mógłbym zrobić “scheduling” z każdej platformy bezpośrednio. I tak robiłem przez lata. Jednak z tym wiąże się problem, o którym już nieco wspomniałem: to (na Facebooku i LinkedIn) działa tylko dla już opublikowanych treści! Te portale zaciągają i cache’ują sobie graficzną reprezentację linków. WordPressowy szkic zwróci im 404. Z CoSchedule ten problem znika! Lowe Wielkie za to.

Zresztą w podobny sposób planuję promocję odcinków VLOGa, publikowanych tylko na YT, nie na WordPress. Upload i schedule na YouTube to jedno. Ale od razu, w tym samym momencie, mogę zaplanować informacje wysłane na wszystkie social-kanały. A potem bezpiecznie wyłączam komputer i wszystko magicznie dzieje się samo.

W poszukiwaniu utraconego czasu? To właśnie tutaj!

Bardzo, bardzo wielka oszczędność czasu. A z moich raportów finansowych można łatwo wywnioskować, że z chęcią kupuję czas.

Co więcej: dzięki CoSchedule mogę dać dostęp do tych kanałów innym osobom, na przykład mojej asystentce Ani, bez nadawania uprawnień na każdej platformie po kolei (czego robić nie chcę)! Idealny flow: autor pisze tekst, Andrzej robi korektę i redakcję, Ania ogarnia resztę (graficzka i promocja w socialach), a ja biję brawo. Perfect!

Bonus: headline analyzer

Po polsku działa to średnio, ale jeśli piszesz po angielsku, to może Ci się spodobać:

U mnie wszystko jest po polsku, więc nie korzystam, ale pokazuję jako ciekawy bajer.

Po drugie: kalendarz

Nawet pisząc w pojedynkę czasami mieszałem terminy różnych publikacji. Wrzucałem na Google Calendar wszystkie potrzebne informacje: kiedy co i gdzie ma być opublikowane. I to działało pięknie… dopóki nie nastąpiła jakakolwiek zmiana. Bo kto zsynchronizuje kalendarz z rzeczywistością? Ano nikt.

Nikt? A jednak ktoś! Proszę bardzo:

To jest jeden z tygodni lipca. Tu są wszystkie WordPressowe teksty i wszystkie “marketingowe” wiadomości na sociale. I tutaj synchronizacja już działa! Jeśli przesunę wiadomość na inny dzień lub inną godzinę, to ona faktycznie zostanie opublikowana w tym nowym terminie.

A dlaczego niektóre elementy się wyróżniają? Bo najechałem myszką na jedną z wiadomości. A wtedy CoSchedule pokazuje, które inne pozycje są z nią powiązane w jednej “social kampanii“. W tym przypadku widać (dość agresywną) kilkudniową kampanię promującą mój post o Gicie.

Zajarałem się, gdy to zobaczyłem. I jaram się do dziś.

Po trzecie: republikacja

Blog założyłem ponad dekadę temu. Przez ten czas pojawiło się prawie tysiąc tekstów. W trakcie doszedł podcast i VLOG. Jest tego MASA.

I… i to się marnuje. Przynajmniej te uniwersalne, ponadczasowe teksty/odcinki. Jasne, w swoim czasie każda treść dotarła przed oczy i uszy X Czytelników, Widzów i Słuchaczy. Ale to grono ciągle rośnie! A mało kto chodzi po archiwach.

Z pomocą przychodzi ReQueue, czyli mechanizm ponownej promocji już istniejących treści. Wybieram tekst, klikam “OKEJ”, a CoSchedule robi resztę, czyli automatycznie publikuje te teksty w odpowiednich godzinach na wybranych przeze mnie kanałach. Pilnując jednocześnie, by zbytnio nie spamować, trzymając się ustalonych limitów X wiadomości dziennie per kanał.

Oczywiście są inne narzędzia, które także to robią. Ale tutaj mam wszystko “w pakiecie”. A dodatkowo – co się niezmiernie przydaje – NOWE teksty mogą zostać automatycznie dodane do wybranych grup republikacji.

Efekt?

Od -nastu (czy -dziesięciu?) miesięcy liczba UU na devstyle.pl krążyła wokół 20-25tys. Były wzloty i spadki, ale to taka średnia.

Natomiast lipiec 2018… o proszę, w porównaniu do poprzedniego miesiąca:

W lipcu uruchomienie CoSchedule nie było jedyną zmianą. Oprócz tego pojawiło się więcej tekstów niż zwykle dzięki nowym świetnym Autorom i Autorce. Więcej niż zwykle wydałem też na reklamy na FB.

ALE! Nawet jeśli CoSchedule nie przełożyło się na ten ruch bezpośrednio (choć jestem przekonany, że tak było), to na pewno pomogło w osiągnięciu takiego wyniku.

Czego nie używam?

Napisałem, że CoSchedule oferuje więcej niż potrzebuję. Co zatem olewam? Przynajmniej dwa duże ficzery:

Pierwszy z nich to analityka. Pewnie powinienem nad tym przysiąść, ale… no cóż, po prostu mi się nie chce.

Drugi to “project management”/kolaboracja. Od tego mam inne narzędzia, które sprawdzają się bardzo dobrze.

Czego mi brakuje?

Zgłosiłem to już do supportu, napiszę więc i tutaj.

Bardzo chciałbym zobaczyć trzy dodatkowe funkcje: łatwą duplikację wiadomości, wyszukiwanie wiadomości oraz integrację z ConvertKit (jest MailChimp i ActiveCampaign, a mojego CK akurat nie).

Uprościłoby to korzystanie, choć i bez tego jestem kontent.

Więc?

Tak jak pisałem, narzędzia używam od około dwóch miesięcy. Jest rewelacyjne i zostaję przy nim. Polecam także Tobie!

Ku jawności: w tekście znajduje się link afiliacyjny: http://devstyle.pl/coschedule. Będzie mi bardzo miło, jeśli zapoznasz się z tą usługą korzystając właśnie z niego. Ale nawet jeśli olejesz mój link i pójdziesz bezpośrednio na stronę produktu, to i tak będę zadowolony. I… jestem przekonany, że Ty też.

Pozdro!

Procent,

Taki Dojrzały Marketer Że Hej

The post Prowadzisz bloga? Oto Twoje zbawienie: CoSchedule appeared first on devstyle.pl.

Programowanie funkcyjne w Twojej przeglądarce

Witaj w czwartej odsłonie cyklu! Pierwsze trzy odcinki poświęciłem na przedstawienie Ci podstaw programowania funkcyjnego w C#. Czas na mały plot twist – tym razem zajmiemy się JavaScriptem.

Dlaczego? Po pierwsze dlatego, że ten najpopularniejszy na świecie język programowania jest funkcyjny (wg raportu Stack Overflow)! Wzgardzony przez wielu i często traktowany jako niepoważny JavaScript w rzeczywistości zawiera wiele elementów wspierających programowanie funkcyjne. Za chwilę zobaczysz, że niektóre koncepcje poznane w poprzednich osłonach cyklu wyrażają się w JavaScripcie w sposób dużo bardziej naturalny niż w C#.

Po drugie chcę Ci pokazać, że idee w programowaniu funkcyjnym są uniwersalne i tak naprawdę nie ma znaczenia, jakim językiem się posługujemy.

Po ostatnie to właśnie w świecie frontendu programowanie funkcyjne przeżywa swój niespodziewany renesans. Nowoczesne biblioteki JavaScriptowe takie jak React, Redux czy RxJS pełne są odwołań do tego paradygmatu programowania.

Zanim przejdziemy do rzeczy, mam dla Ciebie niespodziankę – bonus!

POBIERZ PDF: Cztery praktyczne zastosowania programowania funkcyjnego we frontendzie

Po tym wstępie zapraszam do lektury!

Funkcje obywatelami pierwszej kategorii

Pierwsze, najważniejsze kryterium, które musi spełniać język funkcyjny, to możliwość traktowania funkcji w taki sam sposób jak traktowane są dane. Jak w tej kwestii spisuje się JavaScript?

Z łatwością możemy przypisać funkcję do zmiennej (lub stałej):

const calculateTax = function(employee) {
return employee.salary * 0.19;
}

Dzięki wprowadzonej w standardzie ES6 notacji arrow functions jest to jeszcze łatwiejsze (i przypomina lambda expressions z C#):

const calculateTax = employee => employee.salary * 0.19;

Mając taką możliwość, możemy bez problemu przekazać funkcję jako argument innej funkcji. Poniżej przykład wywołania metody wyższego rzędu map na obiekcie tablicy:

const squares = [1, 2, 3, 4, 5].map(x => x * x);

JavaScript posiada kilka takich wbudowanych metod tablicowych, które dają namiastkę możliwości oferowanych przez LINQ. Istnieją biblioteki znacznie rozszerzające zakres funkcji wyższego rzędu na kolekcjach, np. lodash.

Nie ma problemu ze zwracaniem funkcji z funkcji:

function getTaxMethod(employee) {
if (employee.salary > 10000) {
return e => 1900 (e.salary - 10000) * 0.32;
} else {
return e => e.salary * 0.19;
}
}

const calculateTax = getTaxMethod(employee);
console.log(calculateTax(employee));

Czyste funkcje

Trudno mówić o jakimś konkretnym wsparciu języka dla czystych funkcji, ale JavaScript posiada konstrukcje, które ułatwiają niemodyfikowanie obiektów i tablic. Jeśli nie wiesz, czym są czyste funkcje, to odsyłam do części pierwszej.

Pisząc czyste funkcje operujące na obiektach, nie wolno nam mutować podanego argumentu. Zamiast tego zwracamy nowy obiekt będący kopią argumentu rozbudowaną o pożądane modyfikacje.

Standard ES2018 języka wprowadza tzw. operator spread dla obiektów. Dzięki niemu możemy w łatwy sposób skopiować pola jednego obiektu do drugiego, przy okazji mając możliwość dodania nowych lub nadpisania starych pól:

function calculateTax(employee) {
const getTax = getTaxMethod(employee);
return { ...employee, tax: getTax(employee) };
}

Już w standardzie ES6 funkcjonował wariant operatora spread działający na tablicach. Dzięki niemu możemy z łatwością implementować niemutowalne operacje na tablicach:

function addItem(items, item) {
return [ ...items, item ];
}

Pisanie takich funkcji może rodzić obawy o niepotrzebne mnożenie obiektów. Biblioteka adresuje ten problem, bazując na koncepcji structural sharing.

Currying i częściowa aplikacja

Jak pamiętamy z części drugiej, funkcje jednoargumentowe są kluczowe w kwestii funkcyjnej kompozycji.

W JavaScripcie możemy z łatwością zapisać funkcje w postaci curried. Jest to przyjemniejsze niż w C#, ponieważ nie jesteśmy zmuszeni wypisywać typów kolejnych argumentów oraz typu zwracanego przez funkcję.

Na ogół silne systemy typów dobrze współgrają z programowaniem funkcyjnym, jednak tylko jeśli mamy do dyspozycji inferencję typów (kompilator sam zgaduje, o jaki typ nam chodzi). W C# mamy słowo kluczowe var, ale typy argumentów funkcji oraz typ zwracany muszą być jawnie podane. W tej sytuacji dynamiczny JavaScript okazuje się dużo wygodniejszy.

const calculateTax =
getTax => employee => getTax(employee.salary) * employee.salary;

const calculateLinearTax = calculateTax(x => x * 0.19);

console.log(calculateLinearTax({ name: "Jan", salary: 100 }));

Funkcyjna kompozycja

Ponownie brak sprawdzania typów ułatwia nam trochę życie. W JavaScripcie możemy w niezwykle elegancki sposób zapisać generyczną funkcję compose służącą do składania innych funkcji.

const compose2 = (f, g) => x => g(f(x));
const compose = (...args) => args.reduce(compose2);

Najpierw definiujemy funkcję compose2 służącą do składania dwóch funkcji. Następnie definiujemy funkcję compose. Za pomocą poznanego już operatora spread przypisujemy wszystkie argumenty funkcji (może ich być dowolna liczba) do tablicy args. Tablica ta będzie zawierać wszystkie funkcje, które mamy złożyć.

W kolejnym kroku wywołujemy na tablicy args metodę wyższego rzędu reduce. Zachowuje się ona w podobny sposób co Aggregate w LINQ. Jej magia polega na tym, że podając jej sposób na złożenie dwóch funkcji (compose2), otrzymamy złożenie wszystkich funkcji w tablicy args.

Funkcja compose jest często znana pod nazwą pipe. W takiej formie weszła do użytku w niezwykle popularnej ostatnie bibliotece RxJS wspomagającej programowanie reaktywne w JavaScript. Funkcja pipe służy w tym przypadku do składania transformacji, którym poddajemy obserwowalne strumienie zdarzeń.

number$.pipe(
map(n => n * n),
filter(n => n % 2 === 0)
);

Przykład ten jest o tyle ważny, że pokazuje, iż programowanie funkcyjne to nie jest jakieś akademickie bajanie, tylko źródło koncepcji, na których opiera się tworzenie nowoczesnych aplikacji webowych.

Monady

Po dłuższe wyjaśnienie tego, czym są monady, zapraszam do części trzeciej cyklu.

W JavaScripcie, ponownie, brak silnego systemu typów upraszcza tworzenie i użycie monad. Nie ma tutaj składni LINQ pozwalającej na zwięzły zapis monadycznego kodu. Zamiast tego można użyć generatorów – kolejnego elementu języka wprowadzonego w standardzie ES6.

Warto nadmienić, że monady są – często nieświadomie – używane przez wielu programistów JavaScript na co dzień. Otóż obiekt Promise reprezentujący asynchroniczne obliczenie (np. pobranie danych z serwera) jest niczym innym jak monadą, którą można składać za pomocą metody then. Koncepcja ta jest bardzo podobna do klasy Task z C#, z tym że w JavaScripcie Promise’y wykorzystywane są bardzo często.

Podsumowanie

Na tym kończę ten krótki przegląd funkcyjnych elementów JavaScriptu. Jak widzisz, język ten jak najbardziej nadaje się do pisania funkcyjnego kodu, a w wielu miejscach jest wygodniejszy niż C#.

Wspomniałem kilka razy, że brak silnego systemu typów jest w tym kontekście pomocny. Warto jednak pamiętać, że hardcore’owe języki funkcyjne, takie jak Haskell czy F#, mają bardzo silny system typów świetnie współgrający z funkcyjnością.

Co o tym sądzisz? Czy udało mi się pokazać Ci, że JavaScript to całkiem poważny język, w którym możesz także pisać funkcyjnie? Zapraszam do sekcji komentarzy oraz na kolejną część cyklu, z której dowiesz się, jak w JavaScripcie stworzyć pełnoprawną aplikację webową w sposób funkcyjny!

Pamiętaj o bonusie, do zgarnięcia poniżej :)

POBIERZ PDF: Cztery praktyczne zastosowania programowania funkcyjnego we frontendzie

The post Programowanie funkcyjne w Twojej przeglądarce appeared first on devstyle.pl.

Wednewsday #19 – programistyczne nowinki

Dziś dzień wolny. Pewnie część z Was pomyśli, że to dobry dzień do nauki czegoś nowego. Poniżej krótka ilustracja jak to może wyglądać. I jak zawsze zapraszam na przegląd ciekawostek dla programistów.

View post on imgur.com

 

Table of Disruptive Technologies & Innovation – przełomowych technologie i innowacje ukazane w formie tablicy Mendelejewa.
Learn ML Algorithms by coding: Decision Trees – seria postów (dopiero startuje) dotycząca nauki ML poprzez kodowanie. Na początek drzewa decyzyjne.
Snapchat’s leaked source code is clean, literally – na jakie kwiatki można się natknąć w kodzie. I nie mówię tutaj o błędach ;)
react-typescript-cheatsheet – wypróbuj TypeScript razem z Reactem.
Julia 1.0 – Julia język do wysokowydajnej analizy numerycznej oficjalnie wydany! Tutaj możecie podejrzeć moment na konferencji w której chłopaki oficjalnie wypychają wersję i nieźle się przy tym bawią :)
The Trap of Sales Driven Development – “Dlaczego cenisz potencjalnych klientów bardziej niż dotychczasowych klientów?”
25 Tips for New Developers – no taka pigułka różnych bla bla …
Hollywood Casts Open Source Software in Starring Role – OSS zagości a bardziej będzie rozwijane w Hollywood.
EVEN ANONYMOUS CODERS LEAVE FINGERPRINTS – A po kodzie ich poznacie. Co za czasy nadchodzą.
Human readable time diffs – Ile razy wyliczałeś w pamięci miniony czas pomiędzy wpisami w logu? Ten projekt jest zbawieniem!
Fairytale about performance in web application – bajka o programiście, który nie sprawdził jak działa aplikacja na cieniutkim, słabiutkim telefoniku. Zawsze lepiej uczyć się na czyichś błędach :)
The 10:1 rule of writing and programming – czyli ile idzie pary w przygotowanie książki, projektu a ile z tego zostaje na końcu.
NDC Conferences – w ostatnich dniach pojawiło się sporo nagrań z lipcowej edycji NDC Oslo. Mega content – koniecznie zajrzyjcie!

Zapraszam również do śledzenia audycji podcastowej, w której prezentuję najnowsze wiadomości, ciekawostki, wpadki oraz wydarzenia ze świata IT:

http://devsession.pl/podkast/

The post Wednewsday #19 – programistyczne nowinki appeared first on devstyle.pl.

Lipiec 2018 na devstyle: podsumowanie i raport finansowy.

Na swoim profilu na Patronite obiecałem publikować co miesiąc “raport finansowy”. Dodatkowo zamieszczam podsumowanie tego, co działo się w imperium devstyle w ostatnim miesiącu. Pokazuję… wszystko. Bez tajemnic. Enjoy!

Dzisiaj później niż zwykle. Ale wakacje w pełni! Sierpień mam w 80% wczasowy, stąd obsuwa. Ale… to nic.

Lipiec to miesiąc, w którym odważnie przyznałem: oszukujesz sam siebie, zią! Twoja praca nad Kursem Gita to Jedna Wielka Ściema. Po przerobieniu większości “kursu o robieniu kursów” (o którym pisałem poprzednim razem) naprawdę mocno wziąłem się do roboty. Nie było łatwo, ale pomogła mi ta piękna trylogia:

Piękna #trylogia, polecam każdemu! #dip #onething #deepwork #books #książki

A post shared by Maciej Aniserowicz (@maciej.aniserowicz) on Jul 31, 2018 at 11:41pm PDT

Focus prawie całkowity właśnie na tym jednym celu: wreszcie zrobić co jest do zrobienia i ruszyć dalej. Z efektów PRACY jestem zadowolony. Choć… nie jest łatwo, wcale a wcale:

No ale nic to, cały ten rok to najłatwiejszych nie należy.

Na szczęście cała devstylowa otoczka nie jest tylko na moich barkach, bo by już się dawno posypała. Jak można zauważyć, pojawia się sporo tekstów kilku innych świetnych osób. Co w lipcu zaskutkowało takim oto rekordem:

Bardzo duży wzrost, elegancko! Wszystkim Panom i Paniom współtworzącym devstyle – dziękuję! :) Zadebiutował Marek, także zadebiutowała Nela. A i pozostali nie zasypiają gruszek w popiele, jak to się mawia. Świetna robota!

Linki do wszystkich ich treści znajdziesz niżej.

Z miesięczną obsuwą udało się też ogarnąć biuro. Co prawda na razie byłem w nim dwa razy, ale bardzo przyda się po zakończeniu sezonu wakacyjnego.

Do mojego zespołu dołączył też Mateusz, który będzie montował przyszłe VLOGi. Jak widać: w ostatnich miesiącach staram się kupić sobie jak najwięcej czasu. I… dobrze mi z tym!

No i po takich wstępach zapraszam na standardowe zestawienie: zarówno finansowe, jak i “treściowe”.

Raport finansowy: przychody

Założenia:

pieniądze wpływające na konto w bieżącym miesiącu; usługa mogła być zrealizowana w innym terminie
kwoty to faktury netto (chyba, że zaznaczono inaczej)

Pozycje:

konsultacje: 3 200,00 zł
Patronite: 1 242,61 zł
książka “Zawód: Programista”: 12 139,61 zł
afiliacja “Finansowy Ninja”:  113,02 zł
afiliacja (różne): 229,62 zł

W sumie: 16 924,86 zł.

Raport finansowy: wydatki

Założenia:

kwota brutto, znikająca z konta, bez uwzględnienia odliczeń od podatków

Pozycje (linki afiliacyjne):

Księgowa: 270,60 zł
ZUS: 1 279,93 zł
PIT-4:  38,00 zł
ConvertKit: 551,45 zł
zoom.us: 55,23 zł
LeadPages: 0 zł (wykupione na 2 lata)
CoSchedule: 181,96 zł
LibSyn: 58,01 zł
MacBook Pro + słuchawki Sony: 405,13 zł (20 rat 0%)
Shoplo: 60,27 zł
współpracownicy: 1 017,88 zł
korekta tekstów na devstyle: 469,36 zł
grafiki (YouTube, szablony, reklamy): 1 574,40 zł
Google Storage: 0 zł (wykupione na rok)
DropBox: 0 zł (wykupione na rok)
infakt: 0 zł (wykupione na rok)
wFirma: 0 zł (wykupione na rok)
ToDoist: 0 zł (wykupione na rok)
Headspace: 213,01 zł (wykupione na rok)
Pajacyk (z aukcji #finninja): 115,00 zł
Patronite (wsparcie 4 autorów): 42,00 zł
Patronite (koszty): 191,76 zł
reklama Facebook: 637,68 zł
telefon Orange: 5,00 zł
aplikacja aText: 18,47 zł
przyszłe tajne przedsięwzięcie:

logo: 500,00 zł


inne przyszłe przedsięwzięcie:

domeny: 24,60 zł


książka “Zawód: Programista”

obsługa płatności: 268,74 zł
wysyłka: 1 407,12 zł
magazynowanie: 241,08 zł
poczta: 23,30 zł


książki

Rafał Ohme “Emo Sapiens”: 29,50 zł
David Allen “Getting Things Done” (EN): 28,99 zł
Stephen Covey “The 7 Habits of Highly Effective People” (EN): 23,99 zł
Gary Keller “The One Thing”: 33,53 zł
Steve Peters “Paradoks Szympansa”: 20,90 zł
Bronnie Ware “The Top Five Regrets Of The Dying”: 47,84 zł
Josh Kaufman “Personal MBA”: 64,43 zł


samochód:

leasing: 1 774,56 zł
benzyna: 406,21 zł

W sumie: 12 079,93 zł.

Raport finansowy: podsumowanie

Niby plus, ale pokazane wydatki dotyczą tylko firmy. Jeśli dodać do tego “normalne życie”, to w lipcu lekki dołek. Ale na pracowita żonka się nie leni i swoją dolę co miesiąc przynosi, więc sumasumaróm nasza poduszka finansowa i tak nieco urosła. Chociaż akurat w tym temacie mam ostatnio bardzo wiele rozkmin… jednak to nie na teraz. Pewnie w przyszłych VLOGach.

Wydałem trochę na reklamę na fejsie, co widać po zwiększonym przychodzie z książki.

Wzrosły też wydatki: pojawiła się pierwsza opłata za korektę tekstów i zdecydowałem się na opłacenie aplikacji CoSchedule (recenzja w drodze, a w skrócie: warto!). Wydałem też co nieco na nowe, przyszłe przedsięwzięcia (logo i domeny). Wreszcie wykupiłem Headspace i nakupiłem trochę książek (w samym lipcu – nie wiem jak i kiedy – przeczytałem ich aż 7, co jeszcze niedawno wydawało mi się niemożliwe).

No i… to tyle, jeśli chodzi o kasę! Czas na:

Podsumowanie aktywności devstyle 07/2018

Działo się nieco! Z moim niewielkim udziałem (bo dziubałem kurs Gita), ale to nieważne, bo nareszcie jest stan, o którym marzyłem od dawna: na devstyle jest ciekawie nawet beze mnie! Ja jestem na Instastory ;).

Teksty

Czerwiec 2018 na devstyle: podsumowanie i raport finansowy.
Wednewsday #13 – programistyczne nowinki (Grzegorz Kotfis)
5 Obowiązkowych Sposobów Na Rewelacyjną Pracę Z Gitem (I Nie Tylko)
200% asynchronicznej mocy w C# z .NET Core 2.1(Szymon Kulec)
Wednewsday #14 – programistyczne nowinki (Grzegorz Kotfis)
Co zabija programistów? Czyli: co warto zmienić w swojej pracy już dzisiaj (Marek Stój)
Niecodzienne zastosowania LINQ, czyli monady w C# (Miłosz Piechocki)
Wednewsday #15 – programistyczne nowinki (Grzegorz Kotfis)
Wasze Historie #18: Uciekłem z życia
#bstoknet 83: programistyczny sposób na wakacyjny letarg (Nela Brzozowska)
Wednewsday #16 – programistyczne nowinki (Grzegorz Kotfis)
Testy jednostkowe na iOS (Piotr Tobolski)

Podcasty

DevTalk #83 – Idea Validation with Pat Flynn

VLOGi

5 MITÓW pracy ZDALNEJ [devstyle vlog #176]
Idę na ODWYK [devstyle vlog #177]

Video

Jak pracować z GITem? (i innymi systemami kontroli wersji) [devstyle LIVE]
devstyle LIVE o Produktywności (na nowo)
O wadach i zaletach branży IT (u Poli z Brand Assist)

Wyjazdy

brak (uff znowu!)

====

Jak co miesiąc mam nadzieję, że taki ekshibicjonizm przynosi Tobie nieco wartości i inspiracji…

…albo chociaż zaciekawia :).

Do przeczytania wkrótce!

Ja

P.S. Jak zwykle, jeśli masz jakiekolwiek pytania: nie wahaj się, tylko je zadawaj! Naprawdę nie mam żadnych tajemnic i chętnie na wszystko odpowiem.

The post Lipiec 2018 na devstyle: podsumowanie i raport finansowy. appeared first on devstyle.pl.

Wednewsday #18 – programistyczne nowinki

Ho ho ho. Dziś obchodzimy osiemnastkę! Życzenia przyjmujemy w komentarzu :)

A na dobry początek imprezy urodzinowej komiks.

World created by programmer

 

Major Quantum Computing Advance Made Obsolete by Teenager – młody geniusz przysiadł do tematu i udowodnił, że klasyczne komputery mogą rozwiązać pewne problemy tak samo skutecznie jak komputery kwantowe.
Getting started with Mu, a Python editor for beginners – prosty edytor Pythona, przeznaczony dla osób początkujących
Introducing Docker Application Guides – przykładowe architektury i wskazówki dotyczące wyboru obrazów i ich wdrażania
Dynamic Programming for Brute-Forcers – artykuł opisujący wstęp do programowania dynamicznego.
Introducing Codier – Front-end Coding Challenges and Creations – potyczki online dla front-endowców.
VS Code extensions for the discerning developer palate – poznaj ulubione rozszerzenia dla VS Code programistów MS Azure Team.
Creating a Simple AI with Unity and C# – jak krok po kroku zaimplementować proste AI w Unity.
Fusion.js – dzień bez nowego frameworka na froncie to dzień stracony. Tym razem coś od Ubera.
Raspberry Pi now officially supports Google’s TensorFlow software – malinka dostała wsparcie dla Tensorflow.
6 Ways to Deal With IT Incidents – 6 sposobów na
Shuffling algorithms and randomization to improve algorithm‘s runtime – Przedstawienie algorytmów tasujących i randomizujących.
Why We Need Open Source Now More Than Ever
Black hole in the movie ‘Interstellar’ – jak została wytworzona czarna dziura w filmie “Interstellar”. Użyto masy czarnego C++ kodu ;)
Google Filament – Google udostępnił silnik renderujący dla platform Android, Linux, MacOS oraz Windows.

Zapraszam również do śledzenia audycji podcastowej, w której prezentuję najnowsze wiadomości, ciekawostki, wpadki oraz wydarzenia ze świata IT:

http://devsession.pl/podkast/

The post Wednewsday #18 – programistyczne nowinki appeared first on devstyle.pl.

Z głową w chmurach, czyli na spotkaniu Białostockiej Grupy Azure

Jak ja nie cierpię upałów!!! Czy to stoisz, czy to leżysz, czy może siedzisz przy włączonym na maksa wiatraku w pracy, pot i tak niemiłosiernie spływa po twojej twarzy, rozmazując linijki w trudem wydobytego z otchłani rozgrzanego niczym Góra Przeznaczenia wnętrza twojej głowy. I nie, nie kłamię – przed chwilą widziałam jakiegoś małego człowieczka pytającego, czy to nie tędy do Mordoru. PRZYPADEG???

Królestwo, królestwo za chociaż małą chmurkę na niebie, w której cieniu znajdę chwilę wytchnienia. Niestety, tam na górze bez zmian, ale za to w siedzibie Hacklagu przy Sienkiewicza 1/1 znalazłam to zbawcze zjawisko pogodowe. I chociaż przybycie do nich przy tych temperaturach było dla mnie wyczynem na miarę zdobycia Nanga Parbat, to było warto pojawić się 1 sierpnia o godzinie 18.00 na białostockim 4 spotkaniu Microsoft Azure User Group. W siedzibie naszych przyjaciół jak zwykle panował przyjemny chłodek, a przekąski i zimne napoje sprzyjały programistycznym rozmowom.

Krótki rekonesans po biurze, przechwycenie napoju, którego sama chytra baba z Radomia by się nie powstydziła, i byłam gotowa na dawkę ochłody od naszych programistycznych chmurek. ;)

Jak to już jest w zwyczaju, Rafał Hryniewski z firmy Elastic Cloud Solutions powitał nas i w kilku słowach opowiedział, czego możemy się dzisiaj spodziewać. Po nim głos zabrał nasz pierwszy gość.

Microsoft Flow – Get things connected

Na pierwszy ogień (koniec śmieszków z temperatury, tutaj klima działa :D) tego wieczoru ruszył Marcin Tyborowski na co dzień pracujący jako .Net Developer w Elastic Cloud Solutions. Jego pomysł na prezentację wziął się z chęci pogłębienia wiedzy na temat Microsoft Flow, z którym zaczął przygodę w pracy. Jak sam powiedział:

W pracy nacisk nie jest kładziony tylko i wyłącznie na programowanie, ale również na umiejętności miękkie, jak np. publiczne wystąpienia, które sprzyjają pogłębianiu oraz lepszemu poznaniu danego zagadnienia.

I tutaj ukłon w stronę firmy. Bo ilu z nas ma wiedzę, ba, nawet chęci, aby ją szerzyć, ale problem z jej przekazaniem? Ile razy chcieliśmy pomóc koledze, ale biedaczysko nie rozumiało, co autor ma na myśli? Elastic Cloud Solutions – owacje na stojąco.

Marcin pomimo małego doświadczenia poradził sobie bardzo dobrze. Temat rzeka, można o nim było opowiadać długo, ale udało mu się wybrać te elementy, które spowodowały, że jako osoba kompletnie niezaznajomiona z tematem byłam w stanie dotrzymać mu tempa i zrozumieć wszystkie zagadnienia. Nie bał się mówić otwarcie o zaletach, ale również o wadach produktu Microsoftu, co – nie oszukujmy się – nie zawsze jest tak oczywiste. Pokusił się też o krótki tutorial, dzięki czemu łatwiej było mi wpaść na pomysł, jak zintegrować swoją pocztę z Facebookiem, aby otrzymywać powiadomienia za każdym razem, gdy dostanę nowego maila. Dzięki, Marcinie. :)

Na pewno będę chciała jeszcze posłuchać, co ciekawego Marcin ma do przekazania, ponieważ zdradził mi, że pracuje już nad nowym tematem. Jeżeli interesuje Was, co takiego zaintrygowało mnie w Microsoft Flow, łapcie link do prezentacji: https://www.slideshare.net/MarcinTyborowski1/microsoft-flow-10826402.

Po zakończeniu wystąpienia przyszedł czas na krótką przerwę, która pozwoliła mi na luźną rozmowę z przyjaciółmi. I chociaż frekwencja nie była powalająca – co pewnie wynika z faktu, że grupa działa dopiero od kilku miesięcy, w dodatku mamy okres wakacyjnej posuchy – taki kameralny klimat bardzo mi odpowiadał.

Tymczasem z oddali zbliżała się prawdziwa chmura gradowa, którą poprzedzał ogromny wiatr doświadczenia. Na scenę wkroczył kolejny prelegent.

Serverless – are you ready for revolution?

Ladies and gentlemen, przedstawiam Państwu Michała Jankowskiego. Z zawodu murarz, tynkarz, akrobata. :) Serio, ten człowiek robi w firmie tyle rzeczy, że sam śmieje się z tego, ile miejsca na slajdzie musi poświęcać na swoje stanowisko. Tak naprawdę jest Architektem, Software Deweloperem oraz Team Leaderem w firmie Objectivity. Michał przyjechał na nasze piękne tereny aż z Wrocławia, ponieważ – jak sam wielokrotnie ironizował – to właśnie na wschodzie jest cywilizacja. Ehhh, to Podlasie… :D Celem naszego prelegenta było przybliżenie nam idei Serverless oraz tego, jak może ona zmienić nasze podejście do programowania.

I znowu zaskoczenie. Nadchodząca godzina prelekcji przyniosła ze sobą mnóstwo przykładów z życia. Michał sypał anegdotami jak z rękawa. Dzięki temu bardzo łatwo – nawet w momencie, gdy nie do końca zrozumiałam, o co chodziło – mogłam szybko poprzez proste analogie zapamiętać i skojarzyć zamierzony sens wypowiedzi. Pozytywnie wypadła także interakcja ze słuchaczami. W trakcie i na koniec prezentacji pojawiło się wiele pytań do prelegenta. To według mnie najlepszy dowód, że zrobiło się dobre wystąpienie.

Także z tej prezentacji udało mi się wynieść sporo ciekawych informacji. Po spotkaniu zainstalowałam nawet dodatek do mojego VS, aby móc się pobawić Azure Functions. Jej! Pierwsze koty za płoty! :)

Michał przygotował świetną prezentację, do której podrzucam Wam link: https://www.jankowskimichal.pl/2018/07/serverless-czy-jestes-gotowy-na-rewolucje/. Na jego blogu znajdziecie również wiele przydatnych informacji, nie tylko związanych z chmurą.

I tak oto dobrnęliśmy do końca oficjalnej części. Teraz każdy miał czas na ściganie prelegentów i zadawanie im pytań po tym, jak rozbudzili we wszystkich głód wiedzy.

Coś się kończy, coś się zaczyna…

Bardzo się cieszę, widząc, jak kolejna grupa w moim pięknym mieście rozkwita. Mam nadzieję, że choć to dopiero jej początek, a początki nie są łatwe, to poradzi sobie, ponieważ ma ogromny potencjał. Dlatego z całego programistycznego serduszka zapraszam Cię, drogi czytelniku – odwiedź grupę na kolejnym spotkaniu i na własnej skórze przekonaj się, że warto. Kto wie – może spotkamy się tam następnym razem i to z Tobą przeprowadzę wywiad…?

The post Z głową w chmurach, czyli na spotkaniu Białostockiej Grupy Azure appeared first on devstyle.pl.

Jak Grupa Pracuj stworzyła w C++ aplikację mobilną dla tysięcy użytkowników

Użytkownicy portalu Pracuj.pl mają dostęp do zróżnicowanych funkcjonalności i narzędzi. Poprzez serwis mogą korzystać m.in. z Kreatora CV, raportów wynagrodzeń i kalkulatora wynagrodzeń. Dla urządzeń mobilnych z systemami Android i iOS napisaliśmy dwie aplikacje: Pracuj.pl – Oferty pracy (tutaj iOS) oraz Kalkulator wynagrodzeń (tutaj iOS).

Autor tekstu: Patryk Nadrowski

Starszy Programista iOS w Grupie Pracuj.

 

Jesienią 2017 r. udostępniliśmy nową wersję Kalkulatora wynagrodzeń. Wcześniej kody dla poszczególnych platform (iOS, Android, WWW) były od siebie całkowicie niezależne. Aplikacje bazowały na płynących od Apple’a oraz Google’a zaleceniach dotyczących pisania aplikacji dla ich systemów.

Co było źle?

Negatywny efekt tego rozwiązania widoczny był zwłaszcza na początku każdego roku kalendarzowego, kiedy to aktualizowane są stawki podatkowe. Zmiany trzeba było wprowadzać niezależnie na wszystkich trzech platformach. W takiej sytuacji zwiększało się też ryzyko popełnienia błędu i stworzenia rozbieżności.

Mając na uwadze powyższe kwestie oraz fakt, że planowaliśmy zmodernizowanie interfejsu użytkownika po stronie aplikacji mobilnej oraz serwisu WWW, postanowiliśmy napisać aplikację od nowa. Decyzja ta miała przede wszystkim na celu:

stworzenie modułu do wyliczania stawek i algorytmu podatkowego wspólnego dla wszystkich platform,
współdzielenie kodu odpowiadającego za logikę biznesową pomiędzy aplikacjami na iOS oraz na Androidzie,
ogólne ulepszenie systemu i poprawę jakości jego funkcjonowania,
odświeżenie interfejsu zgodnie z trendami mobile.

Jaki język i dlaczego C++?

Idea współdzielenia kodu wydaje się ciekawa. Logikę biznesową kodujemy raz i używamy jej na wielu platformach. Znacznie skraca to czas potrzebny na realizację zadań. W takiej sytuacji łatwiej też dostrzec błędy i wprowadzić odpowiednie poprawki.

Odrzuciliśmy React Native i Xamarin. Zdecydowaliśmy się na C++, Objective-C i Java.

W przypadku aplikacji mobilnych najpopularniejsze rozwiązania odnośnie do pisania współdzielonego kodu bazują na językach JavaScript oraz C#. W głównej mierze podyktowane jest to faktem, że wiele osób chętnie wykorzystuje gotowe frameworki takie jak React Native, Xamarin itp.

Nam zależało jednak na ograniczeniu warstw abstrakcji występujących pomiędzy bibliotekami oferowanymi przez producentów obydwu platform i korzystaniu z pełni ich możliwości. Dlatego też odrzuciliśmy możliwość bazowania na tego typu frameworkach.

W przypadku naszej aplikacji zdecydowaliśmy się na język C++. Warstwa UI powstaje natomiast w językach Objective-C++ (iOS) oraz JAVA (Android).

W odróżnieniu od C# czy JavaScript C++ jest oficjalnie wspierany na obydwu platformach przy pisaniu natywnych aplikacji. Możliwość ręcznego zarządzania pamięcią umożliwia nam pisanie efektywniejszego kodu (co prawda piszemy aplikację mobilną, a nie grę, ale wydajność wykonywanego kodu jest dla nas istotna).

Dodatkowym jego atutem jest też fakt, że stwarza zdecydowanie większe możliwości przy projektowaniu architektury danego systemu. Zamiast architektury nastawionej na obiektowość (object oriented design) można bez przeszkód korzystać z podejścia, w którym najważniejszym elementem są przetwarzane dane, a dokładnie ich reprezentacja w pamięci (data oriented design).

Istotnym elementem tego języka są z naszej perspektywy również szablony. Typy generyczne, dostępne chociażby w języku C#, są daleko w tyle pod względem możliwości. Nie można ich traktować jako odpowiednika szablonów.

Nie bez znaczenia pozostawał też fakt, że część naszego zespołu posiadała duże doświadczenie w posługiwaniu się tym językiem. W przypadku zespołów bez takich osób należy liczyć się z tym, że C++ jest zdecydowanie bardziej rozbudowany i wymaga większego nakładu czasu przeznaczanego na jego naukę niż C# czy JavaScript. Często jest to odbierane jako czynnik negatywny.

Gdybym miał krótko podsumować wybór języka – zdecydowała po prostu większa elastyczność C++ niż w przypadku konkurencyjnych rozwiązań.

Aplikacja mobilna – serwer

Patrząc na architekturę aplikacji, możemy zaobserwować, że składa się ona z dwóch części. Jest to rozwiązanie zbliżone do architektury klient–serwer.

Część pierwsza (w dalszej części artykułu określana jako serwerowa) napisana jest w całości w języku C++14. Możemy tu wyróżnić podział na pojedyncze moduły aplikacji, z których każdy odpowiada jednemu ekranowi aplikacji. Mogą się one między sobą bezpośrednio komunikować i wymieniać informacje.

W modułach zawarta jest cała logika biznesowa aplikacji. To tutaj zapadają decyzje o tym, czy chcemy przełączyć się na następny moduł, wysłać zapytanie do serwera w odpowiedniej kolejności itd.

Każdy moduł przechowywany jest w zarządcy modułów za pomocą inteligentnych wskaźników (w tym przypadku z std::shared_ptr). Krótko mówiąc: jest to zwykły stos.

Warstwa klienta przetrzymuje tylko uchwyt (std::weak_ptr) do danego modułu. Po wykonaniu asynchronicznej operacji moduł komunikuje się z klientem za pośrednictwem callbacka.

W tym przypadku nie korzystamy z typowych interfejsów, czyli klasy z abstrakcyjnymi metodami, lecz wykorzystujemy pojedyncze obiekty typu std::function. Dzięki temu w przypadku testów nie musimy tworzyć wielu klas z różnymi wariantami metod – po prostu podmieniamy pojedynczy obiekt std::function, co redukuje ilość pisanego kodu.

Obecnie część ta posiada wsparcie dla systemów iOS, Android, Linux oraz macOS. Nie planujemy wsparcia dla platformy Windows, ponieważ wymagałoby to od nas dużych zmian w skryptach budujących, a nie widzimy w tym wartości biznesowej.

Fakt oddzielenia logiki biznesowej od warstwy UI ułatwia nam również pisanie testów jednostkowych. Dzięki odrzuceniu warstwy UI – zależnej przecież od platformy – separujemy się od wywoływania kodu zbędnego w praktyce testowania jednostkowego. Stwarza nam to również możliwość wykorzystania własnego, prostego, bazującego na asercjach narzędzia do wykonywania testów zamiast rozbudowanego frameworka do testów interfejsu użytkownika.

Aplikacja mobilna – klient

Drugi element aplikacji (w dalszej części artykułu określany jako część kliencka) dedykowany jest interfejsowi użytkownika i – w zależności od systemu operacyjnego – napisany został w innym języku.

W przypadku iOS-a wybór padł na Objective-C. Swift obecnie jest niestety krokiem wstecz w stosunku do Objective-C, jeśli mówimy o integracji z językiem C++ – musielibyśmy wrócić do pisania mostków.

W przypadku Androida zdecydowaliśmy się wykorzystać język Java. Wybór ten pociągnął za sobą konieczność napisania mostków w JNI. Z reguły mostek taki składa się z funkcji typu setCallbacks, w której ustawiamy wszystkie callbacki potrzebne do komunikacji warstwy UI z modułem. Dodatkowo zawarte są tam pozostałe, bardzo krótkie funkcje opakowujące publiczne metody dostępne w module.

Poniżej można zobaczyć przykładowy fragment modułu jednego z naszych produktów:

class OnboardingLocation : public Module
{
public:
class Callbacks : public Module::Callbacks
{
public:
Callbacks() = default;
Callbacks(const Callbacks& pOther) = delete;
Callbacks& operator=(const Callbacks& pOther) = delete;

void setFetchRecommendedLocation(std::function pCallback);
void setGetLocations(std::function lpLocations)> pCallback);
void setOpenOnboardingJobType(std::function lpModule)> pCallback);
void setValidation(std::function pCallback);

private:
// private fields
};

void openOnboardingJobType();
void close();

void fetchRecommendedLocation();
void getLocations(std::string pInput);
void setActiveLocation(size_t pIndex);

protected:
OnboardingLocation();
virtual ~OnboardingLocation();

private:
// private fields
};

Hermes

Część serwerowa aplikacji wykorzystuje na szeroką skalę bibliotekę Hermes naszego autorstwa. Hermes odpowiada za kilka podstawowych zadań stawianych przed większością aplikacji mobilnych. Opublikowaliśmy kod tej biblioteki na GitHubie, zachęcam do zerknięcia: https://github.com/GrupaPracuj/hermes.

Hermes składa się z kilku modułów:

Network Manager

Odpowiada za obsługę zapytań sieciowych ze wsparciem dla grupowania ich pomiędzy poszczególnymi API. Dla każdej takiej grupy możemy zdefiniować tryb odtwarzania nieudanych zapytań, co jest szczególnie istotne np. przy odświeżaniu wygasłych tokenów.

Dostępna jest również funkcja pozwalająca w optymalny sposób wykonywać wiele podobnych zapytań naraz, np. pobranie kilku elementów graficznych.

Redukcji wykonywania zbędnych zapytań służy mechanizm cache dla odebranych danych.

Do samego przetwarzania zapytań „pod maską” korzystamy z biblioteki libcurl, która jest jedną z najpopularniejszych na rynku służących do wykonywania tego typu operacji.

Task Manager

Deleguje zadania na odpowiednie wątki wchodzące w skład zdefiniowanych przez programistę puli.

Odpowiada on również za wykonywanie zadań z opóźnieniem czy za wymuszanie przetwarzania danego zadania na wątku głównym.

Data Manager

Podstawowym zadaniem tego modułu jest po prostu przechowywanie poszczególnych obiektów z danymi.

Dodatkowo oferuje on możliwość szyfrowania w bardzo prosty sposób danych zapisywanych na dysku, a następnie – rzecz jasna – ich odczytywania oraz deszyfrowania.

Rozszerzenia

Oprócz tego Hermes oferuje szereg innych rozszerzeń. Jednym z nich jest wspomniany w sekcji opisującej część serwerową naszej aplikacji komponent nazwany modułem. Moduł to klasa zawierająca metody do przetwarzania logiki biznesowej oraz callbacki, dzięki którym odpowiedź jest przekazywana do warstwy UI.

Warto także wymienić serializer oraz deserializer, które znacząco upraszczają proces przetwarzania wysyłanych oraz otrzymywanych danych w formacie JSON (nic nie stoi na przeszkodzie, aby w prosty sposób dodać również obsługę innych formatów, np. XML).

W formie rozszerzeń oferowanych w bibliotece Hermes przygotowaliśmy również zestaw metod pomocniczych do pisania mostków w JNI oraz integrację wbudowanego Data Managera z androidowymi assetami.

Hermes wykorzystywany jest również z powodzeniem w aplikacji mobilnej Pracuj.pl dla systemów iOS oraz Android.

LUA

Istotną częścią aplikacji jest też skrypt napisany w języku LUA. Odpowiedzialny jest on za wyliczanie stawek podatkowych.

Skrypt ten jest wykorzystywany zarówno przez aplikację mobilną, jak i przez serwis WWW, dzięki czemu aktualizacja stawek jest prosta, a użytkownik ma gwarancję, że korzystając z naszej aplikacji na dowolnej platformie, otrzyma zawsze ten sam wynik. Wcześniej niestety nie mogliśmy tego zapewnić.

Obsługa skryptu LUA jest wpięta w część serwerową naszej aplikacji. Klient otrzymuje już gotowe do prezentacji kwoty.

Specyfika działania skryptów sprawia, że element ten może być niezależną częścią pliku wykonywalnego aplikacji, dzięki czemu możliwa jest jego aktualizacja niezależnie od reszty aplikacji.

Z takiego też rozwiązania skorzystaliśmy w naszym projekcie. Nawet osoby, które nie pobiorą najnowszej wersji aplikacji z App Store czy Google Play, będą posiadały aktualną wersję skryptu odpowiadającego za stawki podatkowe (proces aktualizacji wymaga chwilowego połączenia z Internetem).

Oczywiście oprócz języka LUA na rynku dostępnych jest wiele podobnych rozwiązań, choćby Angel Script czy Squirrel. Za wyborem języka LUA przemawia fakt, że przez wiele lat swojego istnienia zyskał on miano bardzo stabilnego rozwiązania, które z powodzeniem jest wykorzystywane niemal we wszystkich grach AAA.

Organizacja pracy

Aplikację mobilną rozwijało czterech programistów: dwóch dedykowanych dla platformy iOS oraz dwóch dla platformy Android.

Dwie osoby spośród tej czwórki mają również duże doświadczenie w pisaniu oprogramowania cross-platform w języku C++, co bardzo pomogło w wybranym przez nas procesie. Odpowiadali oni w głównej mierze za rozwój części serwerowej oraz biblioteki Hermes. Część kliencka aplikacji była z kolei pisana przez osoby dedykowane dla danych platform.

Wnioski

Przygotowanie aplikacji należących do Grupy Pracuj z wykorzystaniem wymienionych rozwiązań pozwoliło znacznie zredukować ilość kodu aplikacji – około 40% kodu jest wspólne. Udało nam się także zminimalizować niemal do zera ryzyko rozjazdu działania aplikacji na poszczególnych platformach od strony biznesowej.

Jak wynika ze statystyk, ponad połowa aplikacji dla danego systemu operacyjnego zawarta jest we wspólnej dla wszystkich systemów części serwerowej. Oczywiście pozytywnie wpływa to na czas potrzebny na napisanie aplikacji. Zysk jest tym większy, im większą liczbę platform planujemy wspierać.

Napisanie dedykowanego dla danej platformy kodu w przypadku części klienckiej umożliwia stworzenie interfejsu użytkownika wyglądającego w sposób naturalny dla danego systemu operacyjnego i zachowującego wszystkie jego funkcjonalności.

W zasadzie jedynym minusem, który w naszym przypadku dotyczył tylko Androida, była konieczność napisania mostków w JNI. Na pierwszy rzut oka może wydawać się to mało przyjazne rozwiązanie. Jednak w miarę szybko staje się całkiem intuicyjne.

Podsumowując…

Jesteśmy zadowoleni z podjętych decyzji i podjęlibyśmy je ponownie. Ta droga pozwoliła zrealizować projekt w terminie i budżecie, co nie zawsze się zdarza. :)

Zachęcamy do pobrania i przetestowania aplikacji (Android, iOS).

Warto również zerknąć na omawianą bibliotekę Hermes – można tam znaleźć dużo ciekawego kodu!

The post Jak Grupa Pracuj stworzyła w C++ aplikację mobilną dla tysięcy użytkowników appeared first on devstyle.pl.

Wednewsday #17 – programistyczne nowinki

Ze mną nie ma mowy o nudzie. Mam nadzieję, że znajdujecie co tydzień czas na zapoznanie się z tym wszystkim ;) Sam chciałbym jak najwięcej z tego przyswoić ale czasem jest tego za dużo! Tyle się dzieje w naszej branży. Dziś mam dla was równo 23 linki ale zanim do nich zajrzycie dosyć istotna informacja. Jeszcze tylko przez kilka godzin trwa promocja na produkty JetBrains – ceny licencji obniżone o 50%!

W tle zapraszam do posłuchania mojego podcastu, w którym usłyszycie o plusach i minusach programowania.

Machine Learning

How to Calculate McNemar’s Test to Compare Two Machine Learning Classifiers – jak wykonać test McNemara służący do porównania dwóch klasyfikatorów ML
OpenCV Object Tracking – śledzenie obiektów z wykorzystaniem biblioteki OpenCV i Pythona.
Do You Know The Mathematics For Machine Learning ? – kręci cię ML ale masz zaległości w matematyce? Oto lista rzeczy, które musisz znać.

 Nowości

Windows UI Library Preview released! – Microsoft udostępnił preview kontrolek dla Windows 10 UWP w postaci paczek NuGet.
Google App Engine finally ready for Python 3 (and PHP 7.2)
Elixir v1.7 released
Announcing F# 4.5 Preview
Blazor 0.5.0 experimental release now available
Bing Surfaces Code Snippets, Boosting Usefulness to Developers – wyszukiwarka Bing w wynikach wyszukiwania może zwrócić kawałek kodu rozwiązujący twój problem. Demo
MSON (pronounced Mason) – New programming language – taka ciekawostka. Język programowania oparty o składnie Json.

Programowanie

C# 8 Ranges and Recursive Patterns – wyjaśnienie dwóch z ważniejszych rzeczy, które pojawią się w C# 8
Architecture Workshop – July 2018 – 7 streamów dotyczących architektury od Jeffrey T. Fritz. Między innymi DDD, CQRS, Clean Architecture, Serverless.
javascript-algorithms – potężne repozytorium wszelakiej maści algorytmów zaimplementowanych w JavaScript.
layoutit.com – interaktywne narzędzie online do budowania szablonów opartych o CSS Grid.
Code Shrew – poznaj podstawy programowania, tworząc zabawne rysunki i animacje.
You Can Teach Your Kids Programming With the Harry Potter Coding Kit – a jeśli rysunki i animację to za mało zawsze może użyć magicznej różdżki.
Google Web Designer Skip to content – edytor WYSIWYG od Google do tworzenia stron zgodnych HTML5, responsywnych itp. itd.
Cross-Browser Testing Checklist Before Going Live – zanim wypuścisz swoją stronę online sprawdź te wszystkie punkty.
Top 15 Java Multithreading, Concurrency Interview Questions

 Artykuły, ciekawostki

Why we will always need new programming languages – no właśnie, why Leo, why?!
Dual Pivot Quick Sort : Java’s default sorting algorithm – poznaj domyślny (od wersji 7) algorytm sortowania użyty w Javie.
Where did the Microsoft Tech Stack disappear? – dlaczego w startupach tak ciężko znaleźć technologie Microsoftu?
Porn Game Developers Are Making Big Money Thanks To Crowd-Funding – tylko +18 ;)

Zapraszam również do śledzenia audycji podcastowej, w której prezentuję najnowsze wiadomości, ciekawostki, wpadki oraz wydarzenia ze świata IT:

http://devsession.pl/podkast/

The post Wednewsday #17 – programistyczne nowinki appeared first on devstyle.pl.

Testy jednostkowe na iOS

W poprzednich tekstach skupiałem się na języku programowania i narzędziach potrzebnych do pisania aplikacji na platformę iOS. Tym razem temat będzie bardziej konkretny i bezpośrednio związany z pisaniem aplikacji.

Zgodnie z założeniami TDD (z którymi nie zawsze się zgadzam, ale o tym innym razem) rozpocznę od testów jednostkowych. Przedstawię również najpopularniejsze narzędzia wykorzystywane w tym celu.

Wyzwania

Tak jak chyba na każdej innej platformie, tak i na iOS korzysta się z testów jednostkowych. Wyzwania w testowaniu na iOS są zbliżone do tych na Androidzie.

UIViewController

Podstawowym elementem interfejsu na iOS, poza UIView, jest UIViewController. Spaja on modele z widokami i odpowiada za cykl życia danego ekranu lub jego fragmentu. Krótko mówiąc: czy chcemy, czy nie – dużo tam się dzieje.

No dobra, ale w czym tu jest problem? Ano w tym, że nasze klasy muszą dziedziczyć po UIViewController, a w testach jednostkowych trzeba symulować zachowanie systemu w niezliczonej liczbie sytuacji, zaś samo to symulowanie nie należy do najprostszych.

Co z tym fantem zrobić? Wielu doświadczonych programistów, których miałem przyjemność poznać, sugeruje, żeby po prostu… nie pisać testów jednostkowych do tych klas. Oczywiście nie ma to być wymówką do wrzucania tam możliwie dużej ilości logiki, która „nie będzie musiała” zostać przetestowana. Wręcz przeciwnie – aby ułatwić sobie życie, najlepiej jest nie implementować logiki biznesowej w UIViewController, a warstwę prezentacji przetestować w inny sposób, np. przy użyciu testów UI.

Warto wspomnieć również o tym, że UIViewController jest dość ciężki, szczególnie jeśli jest tworzony z pliku NIB (wypluwanego przez Interface Buildera), i samo tworzenie wielu jego instancji potrafi pochłonąć większość czasu wykonywania się testów jednostkowych.

Systemowe API

Jeśli nasza aplikacja intensywnie używa systemowych frameworków, to mamy duży problem. Nie chcemy oczywiście testować nieswojego kodu, dlatego warto tak zaprojektować swoje klasy, aby systemowe API było łatwe do zamockowania, np. poprzez użycie wstrzykiwania zależności.

Niestety w większości przypadków mocki są konieczne, a jedyną formą zweryfikowania, czy API zostało użyte poprawnie, jest sprawdzenie, czy została wywołana odpowiednia systemowa metoda z właściwymi argumentami. Wymaga to oczywiście perfekcyjnej wiedzy na temat działania danego API.

Co więcej, nie wszystkie API są dostępne na symulatorze i pełne mockowanie ich jest jedyną możliwością testowania kodu, który je wykorzystuje.

Stan globalny

O ile w przypadku naszego kodu możemy sobie pozwolić na unikanie singletonów albo kodu posiadającego efekty uboczne, o tyle w przypadku systemu nie jest to możliwe. Względnie duża liczba obiektów polegających na stanie globalnym jest bezpośrednio związana z tym, że urządzenie fizycznie jest tylko jedno, a jego funkcje są dostępne globalnie.

Niestety Apple nie udostępnia prostej i szybkiej możliwości zresetowania stanu symulatora przed każdym testem. Trzeba więc bardzo uważać na to, czy testowany kod nie wywołuje efektów ubocznych, które mogą wpłynąć na inne testy. Jest to szczególnie dotkliwe podczas pracy w dużych zespołach, gdy nie jesteśmy w stanie śledzić wszystkiego, co jest dodawane do repozytorium.

Ciekawy przypadek tego problemu obserwuję w swoim obecnym (bardzo dużym) projekcie. Gdzieś w kodzie lub testach jest błąd, który powoduje kolejkowanie się zadań na głównym wątku. Wraz z wykonywaniem się testów (wszystko na głównym wątku) ta kolejka rośnie, a gdy natrafi na test asynchroniczny – który czeka np. maksymalnie sekundę na wykonanie operacji – ten skończy się błędem. Dzieje się tak, ponieważ w ciągu tej sekundy nie zdążą wykonać się wszystkie wcześniej zakolejkowane zadania. Z uwagi na bardzo dużą ilość kodu, testów i zależności w projekcie nie udało nam się niestety jeszcze znaleźć źródła.

Mockowanie i stubowanie Swifta

Swift jako język programowania jest bardzo szybki. Zawdzięcza to w dużej mierze wielu możliwym optymalizacjom, które mogą się odbyć dzięki statycznemu wywoływaniu metod. Ma to jednak też swoje minusy.

W przeciwieństwie do np. Objective-C albo Javy czy innych bardziej dynamicznych języków programowania możliwości refleksji w Swifcie są bardzo ograniczone. Nie można łatwo mockować wywołań ani stubować wartości zwracanych przez metody na istniejącym obiekcie. Swift wymusza więc pisanie testowalnego kodu.

Co w takim razie z mockowaniem systemowych API? Ono na szczęście zostało praktycznie w całości napisane w Objective-C i jego mockowanie jest bardzo proste przy użyciu odpowiedniej biblioteki.

Narzędzia

Tak jak na każdej innej platformie, tak i tutaj powstało wiele rozwiązań wspomagających pisanie testów jednostkowych.

Apple dostarcza tylko podstawowy framework do wykonywania testów XCTest, a Xcode potrafi dobrze zwizualizować pokrycie kodu.

Matchery

O ile wraz z XCTest dostarczany jest zestaw asercji, o tyle wielu osobom nie przypadają one do gustu.

Z tego powodu powstały takie biblioteki jak Nimble, Expecta lub OCHamcrest. Pozwalają one poprawić czytelność testów, lepiej wyrazić, co chcieliśmy sprawdzić, i – chyba przede wszystkim – uniknąć ręcznego pisania komentarzy wyrzucanych do konsoli, gdy test się nie powiedzie.

Mockowanie i Stubowanie

W przypadku Objective-C sytuacja jest prosta. Używa się głównie OCMock, ewentualnie OCMockito. Przy użyciu którejkolwiek z tych bibliotek w bardzo łatwy sposób można sprawdzić, czy metoda została wywołana (lub nie), albo zmienić wartość zwracaną przez obiekt. Można też tworzyć stuby obiektów bez potrzeby tworzenia nowych klas.

W przypadku Swifta jest wyraźnie gorzej. Możemy znaleźć narzędzia takie jak Cuckoo, które obchodzą część ograniczeń poprzez generowanie kodu, ale nadal nie da się zrobić wszystkiego, np. mockować finalnych metod.

BDD

Czytelność i jasność intencji w testach jest kwestią kluczową, więc bardzo często w projektach używa się frameworków do BDD. Obecnie najpopularniejszym na iOS jest Quick, choć nadal funkcjonują też Specta oraz Kiwi.

Polecam pisanie testów w ten sposób, ponieważ nie tylko stają się one bardziej czytelne i łatwiej je zorganizować – sprzyja to też ograniczaniu liczby błędów i unikaniu powtarzania kodu.

Podsumowanie

Testowanie aplikacji iOS nie należy do najprostszych zadań, ale warto (a może nawet trzeba) to robić, a po nabraniu pewnej wprawy napotykane problemy nie są już takimi wyzwaniami jak na początku. Sprzyja to też pogłębianiu wiedzy na temat mechanizmów działania systemu. Warto również pamiętać, że testowanie aplikacji mobilnych nie kończy się na testach jednostkowych… ale o tym w kolejnej części cyklu!

A teraz…

Zobacz poprzednie teksty!

Swift i Xcode – polemika
Narzędzia programisty iOS, część 1
Narzędzia programisty iOS, część 2

The post Testy jednostkowe na iOS appeared first on devstyle.pl.