Maciej Aniserowicz's Blog, page 36

Protokół blockchain cz. 1

W poprzednim wpisie przybliżyłem technologię blockchain. Zbudowałem prosty łańcuch bloków i przedstawiłem podstawowe elementy, z których się składa. W tym artykule chciałbym przedstawić protokół blockchain i jak on może wyglądać na podstawie krótkiego opisu i implementacji.

Ten wpis będzie pierwszą częścią dwuczęściowego artykułu poświęconego protokołowi. Ten fragment skupia się wokół tematu komunikacji między węzłami oraz algorytmu konsensusu.

Teoria

Żeby zrozumieć ten temat, musimy wprowadzić kilka dodatkowych pojęć:

protokół – zbiór zasad, za pomocą których różne urządzenia mogą się komunikować między sobą,
decentralizacja – brak centralnej jednostki nadzorującej całym procesem komunikacji między węzłami,
algorytm konsensusu (zgodności) – rozwiązanie problemu uzgadniania przez zbiór jednostek jednej wartości spośród zbioru wartości zaproponowanych wstępnie przez te jednostki.

Protokół w świecie blockchain to zbiór zasad, za pomocą których węzły komunikują się ze sobą. Inaczej mówiąc, definiuje reguły, dzięki którym węzły mogą stać się częścią sieci tworzonej z wykorzystaniem tej technologii. Każdy projekt bazujący na metodyce blockchain może działać, wykorzystując inny protokół.

Decentralizacja i algorytm konsensusu

Głównymi cechami, które przyczyniły się do spopularyzowania technologii blockchain, są decentralizacja i bezpieczeństwo. Żeby system był zdecentralizowany, sieć musi składać się z co najmniej dwóch węzłów, z których żaden nie jest nadrzędny. Takie urządzenia w celu zachowania równej ważności muszą być zgodne, co wiąże się zwykle z przechowywaniem identycznego łańcucha.

W tym celu istnieje zbiór reguł, za pomocą których zdecentralizowana sieć dochodzi do porozumienia w takich kwestiach jak np. aktualna wartość łańcucha bloków. Taki zbiór reguł to algorytm konsensusu.

Istnieje kilka popularnych algorytmów. Są to m.in.:

Proof of Work (dowód pracy)

W tym algorytmie użytkownicy sieci rozwiązują zagadkę w celu utworzenia bloku.

Węzeł, który pierwszy utworzy kolejny blok, będzie miał najdłuższy łańcuch, a co za tym idzie, wygra w procesie rozwiązywania konfliktu dotyczącego tego, który łańcuch jest autorytatywny, ponieważ za taki uznawany jest ten najdłuższy,

Proof of Stake (dowód posiadania)

W tym algorytmie bloki tworzone są przez tych użytkowników, którzy posiadają tokeny lub monety.

Jeśli pojawia się konflikt, to węzły głosują za pomocą swoich tokenów na odpowiedni łańcuch. Jeżeli dany użytkownik zagłosował na łańcuch, który nie wygrał głosowania, to tokeny wykorzystane przez niego do oddania głosu zostają mu zabrane,

Delegated Proof of Stake (delegowany dowód posiadania)

W tym algorytmie bloki tworzone są przez delegowane węzły wybierane przez użytkowników sieci za pomocą głosowania.

Ze względu na niewielką liczbę węzłów tworzących bloki system jest w stanie zaplanować dla każdego z delegatów odpowiednie przedziały czasowe na publikację bloków. Wybrane węzły mogą być zmieniane przez system w drodze głosowania, jeśli zachodzi ku temu potrzeba, np. delegowany węzeł nie wywiązuje się poprawnie ze swoich obowiązków. W tym modelu węzły współpracują ze sobą, zamiast rywalizować jak w modelach PoW i PoS,

Proof of Authority (dowód władzy)

W tym algorytmie bloki są tworzone przez węzły, których konta zostały poddane pozytywnej walidacji. Wspomniane elementy sieci rozwiązują konflikty i decydują o stanie systemu. Model taki wykorzystuje się zazwyczaj w prywatnych sieciach z uwagi na pewną centralizację, która w nich występuje.

Jestem pewny, że w nowych projektach wykorzystujących tę technologię powstały lub powstają obecnie różne wariacje i kombinacje korzystające z wymienionych algorytmów albo tworzone są zupełnie nowe koncepcje.

W dalszej części i w przykładowej implementacji skupiłem się na chyba najbardziej popularnym obecnie algorytmie Proof of Work.

Proof of Work, czyli kopanie, koparki i górnicy

Tak jak pisałem wcześniej, zdecentralizowana sieć składa się z co najmniej dwóch punktów. Właścicieli węzłów wchodzących w skład takiej sieci nazywa się potocznie górnikami, ponieważ muszą oni zazwyczaj wykonać jakąś pracę w celu wykopania kolejnego bloku. Cały proces kopania zachodzi na urządzeniu zwanym koparką, praca wykonywana przez górników za pomocą takiego sprzętu nazywa się potocznie kopaniem, a cały proces wydobyciem, ponieważ w pewnym stopniu te dwie czynności są do siebie podobne.

Zarówno górnicy, jak i właściciele węzłów wykonują pracę za pomocą odpowiednich narzędzi w celu uzyskania pewnego dobra. Inaczej mówiąc, zamieniają pracę na materiał, który uzyskuje wartość przez to, że dana jednostka czasu lub surowca została zużyta w celu jego otrzymania. Dlatego wirtualne jednostki powstałe w wyniku tego procesu, czyli kryptowaluty lub tokeny, mogą mieć wartość i mogą być wymieniane na inne dobra, tak jak to obecnie ma miejsce na różnych giełdach.

Przykładowy proces tworzenia bloku z wykorzystaniem prostego protokołu

Jak przebiega tworzenie bloku z wykorzystaniem prostego protokołu?

Uruchomienie węzła – uruchomienie odpowiedniego programu umożliwiającego komunikację z innymi punktami sieci,
rejestracja węzła – wysłanie do pozostałych węzłów sieci informacji o nowym węźle,
dodawanie transakcji,
dodawanie bloku (kopanie),
rozwiązywanie konfliktów (uzyskiwanie konsensusu wśród węzłów).

Poniżej opisałem prostą implementację takiego protokołu.

Implementacja

Implementacja poniższego przykładu została oparta na moim poprzednim programie umieszczonym tutaj, który powstał na potrzeby poprzedniego artykułu – znajdziecie go tutaj. Są tam opisane podstawowe obiekty wchodzące w skład łańcucha bloków. Zachęcam do zapoznania się z tamtym materiałem przed przystąpieniem do poniższego.

Założenia

Węzły komunikują się ze sobą za pomocą protokołu HTTP w modelu klient–serwer, gdzie każdy może być klientem, a serwerem jest węzeł, na którym uruchomiony jest serwer web, zaś jego url jest zarejestrowany na pozostałych węzłach.
Algorytm konsensusu oparty jest na modelu Proof of Work.

Celowo nie skupiałem się na szyfrowaniu, walidacji transakcji i bloków oraz dystrybucji transakcji między węzłami. Nie ma też w poniższej implementacji kwantu czasowego, od którego uzależnione byłoby tworzenie bloku.

Tym zagadnieniom będzie poświęcona kolejna część artykułu dotyczącego protokołu blockchain. W poniższym przykładzie położyłem nacisk przede wszystkim na zapewnienie komunikacji między punktami sieci i na algorytm konsensusu.

Budowanie łańcucha bloków

Musiałem zmodyfikować nieco klasę bloku pod kątem algorytmów, jakie wykorzystałem w swoim protokole. Obecnie klasa bloku składa się z następujących właściwości:

indeksu – numeru bloku (liczby porządkowej),
stempla czasowego – czasu utworzenia bloku,
nonce – dowodu pracy (rozwiązania zagadki),
hasza poprzedniego bloku,
listy transakcji.


public class Block
{
public int Index { get; set; }
public DateTime Timestamp { get; set; }
public int Nonce { get; set; }
public string PreviousHash { get; set; }
public List TransactionList { get; set; }
}

Następnie utworzyłem klasę Blockchain, która składa się z następujących właściwości:

identyfikatora węzła – adresu użytkownika, który może być wykorzystywany do przesyłania jednostek rozliczeniowych,
pustej listy aktualnych transakcji – do tej listy są dodawane nowe transakcje, które są umieszczane w nowym bloku po jego wykopaniu,
pustej listy bloków – ta lista będzie zawierała wszystkie sprawdzone i zatwierdzone bloki, tworząc łańcuch bloków,
listy węzłów sieci – listy wszystkich węzłów, które zostały zarejestrowane w sieci.


public class Blockchain
{
public string NodeId { get; }
private readonly List currentTransactionList = new List();
private List blockList = new List();
private readonly List nodes = new List();
}

Łańcuch bloków po zainicjalizowaniu wygląda tak:

{
"blockList":[
{
"Index":0,
"Timestamp":"2018-11-01T10:52:11.7555162Z",
"Nonce":100,
"PreviousHash":"",
"TransactionList":[]
}
],
"length":1
}

Tworzenie nowych bloków

Podczas inicjalizowania łańcucha bloków tworzony jest bazowy blok, tzw. genesis block. Jest to blok, który nie ma przodków (poprzednich bloków), hasz wcześniejszego bloku jest pusty, a dowód pracy – ustawiony na stałą wartość (nie jest obliczany).

Uzupełniłem klasę Blockchain o dodatkowe metody dołączania nowego bloku CreateNewBlock, dodawania transakcji CreateTransaction oraz generowania hasza bloku GetHash:

private Block CreateNewBlock(int nonce, string previousHash = null)
{
var block = new Block(this.blockList.Count, DateTime.UtcNow, nonce,
previousHash ?? this.GetHash(this.blockList.Last()),
this.currentTransactionList.ToList());

this.currentTransactionList.Clear();
this.blockList.Add(block);
return block;
}

internal int CreateTransaction(string from, string to, double amount)
{
var transaction = new Transaction
{
From = from,
To = to,
Amount = amount
};

this.currentTransactionList.Add(transaction);
return this.LastBlock?.Index + 1 ?? 0;
}

private string GetHash(Block block)
{
string blockText = JsonConvert.SerializeObject(block);
return Helper.GetSha256Hash(blockText);
}

Tworzenie bloku odbywa się podczas procesu kopania (metoda klasy Blockchain):

internal string Mine()
{
int nonce = this.FindNonce(this.LastBlock.Nonce, this.LastBlock.PreviousHash);

this.CreateTransaction("0", this.NodeId, 1);
Block block = this.CreateNewBlock(nonce /*, _lastBlock.PreviousHash*/);
}

W procesie kopania następuje praca polegająca na poszukiwaniu dowodu, tzw. nonce. W omawianym przykładzie przebiega to w pętli, w której nonce, począwszy od wartości 0, jest sprawdzany pod kątem poprawności. Jeśli jest poprawny, to następuje wyjście z pętli, a jeśli nie, to nonce zwiększany jest o 1 i operacja w pętli się powtarza.

Sprawdzanie poprawności polega na generowaniu ciągu znaków składającego się z ostatniego dowodu pracy (lastNonce), aktualnie sprawdzanego dowodu (nonce) i hasza poprzedniego bloku (previousHash). Następnie taki ciąg jest haszowany i sprawdzane jest, czy początek hasza zaczyna się od trzech zer. Po znalezieniu odpowiedniego dowodu dodawana jest do nowego bloku transakcja o wartości 1 jednostki rozliczeniowej, której odbiorcą jest bieżący węzeł. Jest to nagroda za wykopanie bloku.

private int FindNonce(int lastNonce, string previousHash)
{
int nonce = 0;
while (!this.IsValidNonce(lastNonce, nonce, previousHash))
nonce++;

return nonce;
}

private bool IsValidNonce(int lastNonce, int nonce, string previousHash)
{
string guess = $"{lastNonce}{nonce}{previousHash}";
string result = Helper.GetSha256Hash(guess);
return result.StartsWith("000");
}

Algorytm konsensusu – rozwiązywanie konfliktów

Algorytm porozumienia polega na tym, że każdy z węzłów pobiera łańcuch bloków od każdego innego węzła zarejestrowanego w sieci i porównuje długość swojego łańcucha z tym pobranym. Jeśli długość pobranego łańcucha jest dłuższa, to łańcuch w źródłowym węźle jest nadpisywany. Chodzi o to, że węzeł o najdłuższym łańcuchu jako pierwszy znalazł dowód pracy i jego blok został dopisany do łańcucha.

private bool ResolveConflicts()
{
List newChain = null;

foreach (Node node in this.nodes)
{
var url = new Uri(node.Address, "/blockchain");
var request = (HttpWebRequest) WebRequest.Create(url);
var response = (HttpWebResponse) request.GetResponse();

if (response.StatusCode == HttpStatusCode.OK)
{
var model = new
{
blockList = new List(),
length = 0
};
Stream stream = response.GetResponseStream();
if (stream != null)
{
string json = new StreamReader(stream).ReadToEnd();
var data = JsonConvert.DeserializeAnonymousType(json, model);

if (data.blockList.Count > this.blockList.Count && this.IsValidBlockList(data.blockList))
{
newChain = data.blockList;
}
}
else
{
Debug.WriteLine("Unable to get response stream");
}
}
}

if (newChain != null)
{
this.blockList = newChain;
return true;
}

return false;
}

Serwer web

Do implementacji serwera web, za pomocą którego węzły komunikują się ze sobą, została wykorzystana prosta biblioteka TinyWebServer. Za jej pomocą możliwe jest odbieranie i przetwarzanie żądań. Na tym serwerze przygotowałem kilka metod. Służą one do wykonywania odpowiednich operacji na łańcuchu bloków danego węzła:

mine – kopanie – tworzenie nowego bloku,
transactions/new – dodawanie nowej transakcji,
blockchain – pobieranie łańcucha bloków,
nodes/register – rejestracja węzłów,
nodes/resolve – rozwiązywanie konfliktów.

Do uruchomienia serwera została napisana prosta aplikacja konsolowa. Tworzy ona nowy obiekt Blockchain i na jego podstawie inicjalizuje serwer web, który zaczyna nasłuchiwać na danym adresie i porcie ustawionym w pliku konfiguracyjnym appsettings.json.

static void Main(string[] args)
{
IConfiguration config = Helper.GetConfigFromFile("appsettings.json");

var blockchain = new Blockchain.Blockchain();
var unused = new WebServer(blockchain, config["server"], config["port"]);
Console.WriteLine($"Serwer o adresie {config["server"]}:{config["port"]} został uruchomiony");
Console.Read();
}

Uruchomienie i test systemu

Do testu przygotowałem dwie wersje aplikacji konsolowej różniące się plikiem konfiguracyjnym, a następnie uruchomiłem je.

PS C:\> dotnet C:\#Temp\publish1\MySimpleBlockchainWithPoW.ServerCore.dll
Serwer o adresie localhost:12345 został uruchomiony
PS C:\> dotnet C:\#Temp\publish2\MySimpleBlockchainWithPoW.ServerCore.dll
Serwer o adresie localhost:54321 został uruchomiony

Dzięki temu pojawiły się dwa węzły – jeden pod adresem localhost:12345 (numer f0f673698fa04d10bd3be1c457a2f9b6), a drugi pod adresem localhost:54321 (numer 54dd864a5b3444b3b30ed07568163629).

Następnie używając aplikacji Postman, wysyłam żądania do węzłów. Żeby połączyć te dwie końcówki w sieć, muszę je wzajemnie zarejestrować, wysyłając żądania nodes/register:

REQUEST POST url: http://localhost:54321/nodes/register body: {"url": "localhost:12345"}
REQUEST POST url: http://localhost:12345/nodes/register body: {"url": "localhost:54321"}

W rezultacie otrzymują odpowiedź odpowiednio:

RESPONSE body: "Węzeł localhost:12345 został zarejestrowany"
RESPONSE body: "Węzeł localhost:54321 został zarejestrowany"

Kopię pierwszy blok (pusty):

REQUEST GET url: http://localhost:54321/mine

RESPONSE body:

{
"Message": "Nowy blok został wygenerowany",
"Index": 1,
"Transactions": [
{
"Amount": 1.0,
"From": "0",
"To": "54dd864a5b3444b3b30ed07568163629"
}
],
"Nonce": 862,
"PreviousHash": "515a53f26e8047ff2cfe84ca5a632dfb56c05099c2096a5d7cfa3801839bfb48"
}

Następnie wykonuję synchronizację bloków:

REQUEST GET url: http://localhost:12345/nodes/resolve
REQUEST GET url: http://localhost:54321/nodes/resolve

Po tej transakcji węzeł o numerze 54dd864a5b3444b3b30ed07568163629 posiada 1 jednostkę i łańcuchy są zsynchronizowane. W kolejnym kroku dodaję transakcję:

REQUEST POST url: http://localhost:54321/transactions/new body: { "Amount":0.5, "From":"54dd864a5b3444b3b30ed07568163629", "To":"f0f673698fa04d10bd3be1c457a2f9b6" }
RESPONSE body: Twoja transakcja zostanie dodana do bloku 2

Kopię kolejny blok:

REQUEST GET url: http://localhost:54321/mine

RESPONSE body:

{
"Message": "Nowy blok został wygenerowany",
"Index": 2,
"Transactions": [
{
"Amount": 0.5,
"From": "54dd864a5b3444b3b30ed07568163629",
"To": "f0f673698fa04d10bd3be1c457a2f9b6"
},
{
"Amount": 1.0,
"From": "0",
"To": "54dd864a5b3444b3b30ed07568163629"
}
],
"Nonce": 1593,
"PreviousHash": "1e582c742100802ee887497ad69c6a69abe520ce57d0061aeaeebf8987c7bf3e"
}

Na koniec znowu wykonuję synchronizację bloków:

REQUEST GET url: http://localhost:54321/nodes/resolve

RESPONSE body:

{
"Message": "Nasz blockchain jest autorytatywny",
"BlockList": [
{
"Index": 0,
"Timestamp": "2018-11-12T10:02:55.7210083Z",
"Nonce": 100,
"PreviousHash": "",
"TransactionList": []
},
{
"Index": 1,
"Timestamp": "2018-11-12T10:11:18.5521277Z",
"Nonce": 862,
"PreviousHash": "515a53f26e8047ff2cfe84ca5a632dfb56c05099c2096a5d7cfa3801839bfb48",
"TransactionList": [
{
"Amount": 1.0,
"From": "0",
"To": "54dd864a5b3444b3b30ed07568163629"
}
]
},
{
"Index": 2,
"Timestamp": "2018-11-12T10:33:20.1480628Z",
"Nonce": 1593,
"PreviousHash": "1e582c742100802ee887497ad69c6a69abe520ce57d0061aeaeebf8987c7bf3e",
"TransactionList": [
{
"Amount": 0.5,
"From": "54dd864a5b3444b3b30ed07568163629",
"To": "f0f673698fa04d10bd3be1c457a2f9b6"
},
{
"Amount": 1.0,
"From": "0",
"To": "54dd864a5b3444b3b30ed07568163629"
}
]
}
]
}


REQUEST GET url: http://localhost:12345/nodes/resolve

RESPONSE body:

{
"Message": "Nasz blockchain został zamieniony",
"BlockList": [
{
"Index": 0,
"Timestamp": "2018-11-12T10:02:55.7210083Z",
"Nonce": 100,
"PreviousHash": "",
"TransactionList": []
},
{
"Index": 1,
"Timestamp": "2018-11-12T10:11:18.5521277Z",
"Nonce": 862,
"PreviousHash": "515a53f26e8047ff2cfe84ca5a632dfb56c05099c2096a5d7cfa3801839bfb48",
"TransactionList": [
{
"Amount": 1.0,
"From": "0",
"To": "54dd864a5b3444b3b30ed07568163629"
}
]
},
{
"Index": 2,
"Timestamp": "2018-11-12T10:33:20.1480628Z",
"Nonce": 1593,
"PreviousHash": "1e582c742100802ee887497ad69c6a69abe520ce57d0061aeaeebf8987c7bf3e",
"TransactionList": [
{
"Amount": 0.5,
"From": "54dd864a5b3444b3b30ed07568163629",
"To": "f0f673698fa04d10bd3be1c457a2f9b6"
},
{
"Amount": 1.0,
"From": "0",
"To": "54dd864a5b3444b3b30ed07568163629"
}
]
}
]
}

Jako że kopaliśmy na węźle localhost:54321, to tam był dłuższy łańcuch i dlatego on był autorytatywny, a na końcówce localhost:12345 został zamieniony. Jak widać, po rozwiązaniu konfliktów oba łańcuchy są identyczne i zawierają transakcje, które dodałem.

Źródła do tego przykładu są dostępne na GitHubie: MySimpleBlockchainWithPoW.

Podsumowanie

W tym tekście teoria i implementacja protokołu blockchain była skupiona wokół komunikacji między węzłami i algorytmu konsensusu.

Przedstawia wykorzystanie podstawowych algorytmów i mechanizmów składających się na protokół, które są obecnie używane w praktycznym zastosowaniu technologii blockchain. Są zachowane najważniejsze cechy metodyki, czyli niezmienność i decentralizacja.

W kolejnej części dodam jeszcze dodatkowe mechanizmy takie jak walidacja, szyfrowanie i synchronizacja transakcji opartych na algorytmach klucza prywatnego. Wprowadzę określone fragmenty czasu do tworzenia bloków.

Daj znać w komentarzu: co o tym sądzisz? O czym chcesz się jeszcze dowiedzieć?

The post Protokół blockchain cz. 1 appeared first on devstyle.pl.

Self-compassion [devstyle vlog #182]

The post Self-compassion [devstyle vlog #182] appeared first on devstyle.pl.

Sierpień 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!

W sierpniu jak w garncu? Nie, w sierpniu jak na wakacjach. Bo wakacje, i wczasy, i większość miesiąca spędzona na Mazurach i Majorce. Najs. A jak to się odbiło na wynikach?

Nieco :).

A w treściach? Tylko jeden VLOG:

Na szczęście pozostali Redaktorzy devstyle nie próżnowali i pojawiło się parę ciekawych tekstów – linki znajdziesz niżej.

U mnie nadal focus w czasie pracy na Kursie Gita. Idzie wolno, ale do przodu. To już nieco Urban Legend się robi, c’nie? No ale cóż… to dużo trudniejsze, niż przypuszczałem. Albo coś robię źle.

I lecimy standardowo: kasa i linki!

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 292,86 zł
książka “Zawód: Programista”: 7 486,91 zł
nadwyżka podatku:  10 000,00 zł
afiliacja (różne): 331,88 zł

W sumie: 22 311,65 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 237,21 zł
PIT-4: 90,00 zł
ConvertKit: 562,12 zł
zoom.us: 0 zł (anulowanie subskrypcji)
LeadPages: 0 zł (wykupione na 2 lata)
CoSchedule: 181,27 zł
LibSyn: 54,91 zł
MacBook Pro + słuchawki Sony: 405,13 zł (20 rat 0%)
Shoplo: 60,27 zł
współpracownicy:

asystentka: 722,63 zł
montaż video: 90,00 zł
korekta tekstów na devstyle: 249,77 zł
grafika modyfikacja logo devstyle: 50,00 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: 0 zł (wykupione na rok)
Patronite (wsparcie 4 autorów): 42,00 zł
Patronite (koszty): 211,86 zł
poczta: 76,00 zł
reklama Facebook: 2 197,70 zł
telefon Orange: 50,00 zł
książka “Zawód: Programista”

obsługa płatności: 172,77 zł
wysyłka: 3 261,96 zł
magazynowanie: 421,89 zł


biuro

czynsz 553,50 zł
wykładzina: 285,04 zł
plakaty: 18,23 zł


książki

4x Ryan Holiday: 151,76 zł


samochód:

leasing: 1 774,56 zł
benzyna: 205,84 zł
wulkanizacja: 50,00 zł
parking SkyCash: 50,95 zł

W sumie: 13 497,97 zł

Raport finansowy: podsumowanie

Tak jak miesiąc temu: NIBY plus ;). Ale oszukany.

Do zarobków doliczyłem dyszkę “buforu” podatkowego. Na firmowym koncie zostawiam nadwyżkę na podatki i przelewam sobie raz na jakiś czas, gdy nazbiera się jej dość sporo. A ten miesiąc dodatkowo na tym skorzystał, bo bez niej biednie by wyglądał. Chociaż przy naszych wydatkach “wczasowych” ta kwota i tak blednie. Ale to nic, tym większa motywacja do wytężonej pracy jesienią! Co ma miejsce już teraz.

Wydatki na reklamy na FB po raz pierwszy przekroczyły 2tys. Zwrot wynosił co prawda więcej, ale nie tyle, ile bym oczekiwał. Coś robię źle. Więc póki co zaprzestaję puszczania stałych kampanii, tego będę się uczył gdy liczba oferowanych przeze mnie produktów wzrośnie z JEDNEGO do >1.

Po raz pierwszy w wydatkach pojawia się BIURO. I fajnie, bo dobrze mi tu jest. Co można we wrześniowych VLOGach pooglądać.

I czas na:

Podsumowanie aktywności devstyle 08/2018

Ponownie: mnie mało, ale ciekawa treść JEST. Hurra!

Teksty

Wednewsday #17 – programistyczne nowinki (Grzegorz Kotfis)
Jak Grupa Pracuj stworzyła w C++ aplikację mobilną dla tysięcy użytkowników
Z głową w chmurach, czyli na spotkaniu Białostockiej Grupy Azure (Nela Brzozowska)
Wednewsday #18 – programistyczne nowinki (Grzegorz Kotfis)
Lipiec 2018 na devstyle: podsumowanie i raport finansowy.
Wednewsday #19 – programistyczne nowinki (Grzegorz Kotfis)
Programowanie funkcyjne w Twojej przeglądarce (Miłosz Piechocki)
Prowadzisz bloga? Oto Twoje zbawienie: CoSchedule
Wednewsday #20 – programistyczne nowinki (Grzegorz Kotfis)
Wednewsday #21 – programistyczne nowinki (Grzegorz Kotfis)
Parostatkiem w piękny… re.js? meet.js special w Białymstoku (Nela Brzozowska)

Podcasty

brak

VLOGi

Work / life IMBALANCE [devstyle vlog #178]

Video

brak

Wyjazdy

brak

====

A i małe ogłoszenie, kto nie wie to niech się dowie: we wrześniu zapraszam na minimum 4 VLOGi tygodniowo! Dobrze jest na tym jutubie :).

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 Sierpień 2018 na devstyle: podsumowanie i raport finansowy. appeared first on devstyle.pl.

Pozytywne UZALEŻNIENIE [devstyle vlog #181]

The post Pozytywne UZALEŻNIENIE [devstyle vlog #181] appeared first on devstyle.pl.

Testy UI na iOS

W poprzednim tekście opisałem wyzwania i narzędzia służące do testów jednostkowych przy pisaniu aplikacji na platformę iOS. Zgodnie z obietnicą w tej części opiszę zagadnienie testów UI, czyli interfejsu aplikacji.

Temat ten jest moim zdaniem znacznie ciekawszy, głównie z uwagi na to, że rzadziej poruszany, ale także stosowane rozwiązania są jakby… bardziej graficzne. Oglądanie aplikacji, po której w zawrotnym tempie klika automat, jest dziwnie satysfakcjonujące. :-)

Wyzwania

Testy UI są z definicji testami integracyjnymi, nie skupiamy się bowiem na małych fragmentach kodu, ale na aplikacji jako całości. Sprawdzamy, jak części naszego kodu współpracują nie tylko ze sobą, ale także z zewnętrznymi bibliotekami, przede wszystkim do obsługi interfejsu graficznego.

Rodzi to niestety wiele problemów i wymaga stosowania specjalnych narzędzi – opiszę najpowszechniejsze z nich.

Testy białej czy czarnej skrzynki?

Pierwsze pytanie, jakie powinniśmy sobie zadać, to: jaki typ testów preferujemy? Z dostępem do kodu aplikacji czy bez niego? W przypadku testów UI różnica polega na tym, czy mamy dostęp do tzw. backdoorów, czyli możliwości wykonania kodu z poziomu skryptów testowych.

Istotnie wpływa to na sposób, w jaki będziemy pisać nasze testy. Jeśli nie mamy dostępu do kodu, możemy napotkać duże problemy w testowaniu niektórych funkcjonalności, ale z drugiej strony takie testy dużo lepiej oddają rzeczywiste interakcje z aplikacją.

Jak nawigować po aplikacji?

No właśnie – jak? Aplikacje na iOS są obsługiwane niemalże wyłącznie przez interakcje z ekranem dotykowym, ale raczej nie chcemy za każdym razem podawać współrzędnych dotknięcia (co z różnymi rozmiarami wyświetlacza? Co, jeśli elementy nie będą na ekranie zawsze w tych samych miejscach?). Jeszcze większy problem sprawiłoby odczytywanie wyświetlanej zawartości. Na myśl przychodzi mi jakieś rozwiązanie OCR, ale to by była katorga, więc lepiej przejdźmy do sedna.

Na iOS istnieje bardzo rozbudowane Switch Control). I właśnie ten mechanizm możemy wykorzystać na nasze potrzeby. Oczywiście nie ma sensu robić tego bezpośrednio, lepiej użyć odpowiednich bibliotek.

Mała dygresja: nie zapominajmy o mechanizmach dostępności podczas programowania, ponieważ korzysta z nich więcej osób, niż może się wydawać. Dla przykładu statystyka, która podaje, że aż 40% użytkowników korzysta z niestandardowego rozmiaru czcionki!

Jeśli używamy mechanizmu dostępności, to siłą rzeczy trzeba dostosować naszą aplikację np. do wspomnianego czytnika ekranu. Z jednej strony wymaga to od nas dodatkowej pracy, z drugiej strony przygotowanie testowalnego kodu również wymaga pracy, a nie niesie za sobą wartości dodanej w postaci umożliwienia korzystania z naszej aplikacji osobom niepełnosprawnym.

Mockowanie

Mockowanie jest niestety trudniejsze niż w przypadku testów jednostkowych. Jeśli mamy dostęp do backdoorów, może ono być bardzo podobne, choć z pewnością będzie trzeba zrobić zaślepkę dużo większych rozmiarów.

Gdy jesteśmy ograniczeni tylko do zewnętrznych interakcji z aplikacją, musimy posiłkować się innymi sposobami, takimi jak np. serwery proxy modyfikujące odpowiedzi HTTP.

Wybór odpowiedniego frameworka

Sporym wyzwaniem jest też wybór właściwego frameworka do testów UI. Standardowy dostarczany z Xcode XCUITest jest prosty w obsłudze, ale oferuje też dość małe możliwości, jest powolny i praktycznie nie pozwala na dostęp do kodu aplikacji.

Aby wybrać najlepsze rozwiązanie, musimy odpowiedzieć sobie na kilka pytań: Testy będą pisać programiści czy testerzy? Czy chcemy, aby scenariusze testowe mogły być przenoszone pomiędzy platformami? Chcemy je wykonywać tylko na symulatorze czy również na prawdziwych urządzeniach? A może mają być wykonywane w chmurze na całej farmie urządzeń?

Z uwagi na wiele czynników nie da się odpowiedzieć jednoznacznie, który framework jest najlepszy. Istnieje duża szansa, że żaden dostępny nie będzie spełniał wszystkich oczekiwań. Z jednej strony jest to oczywiście problem, ale z drugiej… Może komuś brakuje pomysłu na projekt open source? ;-)

Narzędzia

Jestem programistą, więc skupię się na najlepszych rozwiązaniach z mojej perspektywy – z pewnością nie będą one jednak najlepsze dla każdego. Jeśli chcesz się podzielić swoim zdaniem na ten temat, zapraszam do komentowania!

XCUITest

Już po nazwie można rozpoznać, że jest to framework dostarczany przez Apple.

Tak jak wspomniałem kilka akapitów wyżej – jest on powolny i nie pozwala na łatwy dostęp do kodu aplikacji. Może się wydawać, że będzie stabilny i rozbudowany, ale niestety tak nie jest. Podczas użytkowania zdarzają się pewne problemy z synchronizacją (framework nie czeka, aż aplikacja skończy wykonywać jakieś zadania w tle). Nie ma też możliwości wykonania skomplikowanych gestów ani zastąpienia ich backdoorem. XCUITest jest też zamknięty, przez co nie da się łatwo rozszerzyć jego funkcjonalności. Wykonanie własnych skryptów podczas testów nie jest łatwe, co w połączeniu z brakiem backdoorów jest dla wielu czynnikiem decydującym o porzuceniu tego rozwiązania.

Framework ten ma jednak też sporo zalet. Stworzenie pierwszego testu przy jego użyciu jest bajecznie proste. W rzeczywistości nie trzeba napisać nawet linijki kodu, ponieważ ten pisze się sam w trybie nagrywania. Oczywiście nie jest to metoda, która się sprawdzi na dłuższą metę, ale może przyspieszyć integrację tego frameworka. XCUITest dobrze integruje się z systemem i np. pomijanie systemowych powiadomień (choćby zezwolenia na usługi lokalizacyjne) jest automatyczne. Wszystkie jego funkcje działają na urządzeniu równie dobrze co na symulatorze.

EarlGrey

Ten framework dostarczany przez Google jest – z tego, co słyszałem – bardzo podobny do Espresso na Androidzie. Z tego drugiego niestety nie korzystałem, więc proszę, poprawcie mnie, jeśli się mylę.

Zdradzę od razu, że jest to mój wybór – jeśli jesteście programistami iOS chcącymi dodać testy UI do swojej aplikacji, możecie zapisać sobie tę nazwę i nie czytać dalej. ;-) EarlGrey jest bardzo szybki, choć nie aż tak szybki jak KIF. Ma za to zaawansowany mechanizm synchronizacji, co czyni go bardzo stabilnym. Charakteryzuje się dużymi możliwościami interakcji z aplikacją, pozwala na pisanie własnych rozszerzeń, a gdy napotka błąd, drukuje w konsoli bardzo dużo informacji, co często pozwala na znalezienie jego przyczyny na podstawie tylko tych danych.

Ma też wady w postaci np. problemu z pomijaniem systemowych alertów, ale lada dzień ma wyjść wersja 2.0, która powinna naprawić tę usterkę. Wydanie jej miało nastąpić co prawda już pół roku temu, ale według najnowszych wiadomości z ich Slacka (do którego warto dołączyć) jest ona obecnie w ostatniej fazie akceptacji.

KIF

Do czasu powstania EarlGrey KIF był najlepszym rozwiązaniem do testów UI na iOS. Nie uważam, żeby obecnie był sens stosowania go w nowych projektach, ale jeśli ktoś potrzebuje np. małego zestawu superszybkich testów, to nadal może skorzystać z tego frameworka.

Jest bardzo podobny do EarlGrey (choć według mnie trochę gorszy w różnych mniejszych kwestiach) i – co ważne – nie posiada synchronizacji. Oznacza to, że śmiga po interfejsie aplikacji szybciej niż cokolwiek innego, ale jeśli nasz kod nie jest doskonały lub dużo dzieje się w tle, to KIF będzie się czasem zawieszał lub wywalał. Nie jest też rozwijany tak dynamicznie jak EarlGrey.

Inne

Istnieje jeszcze kilka innych frameworków do testowania UI. Każdy czytający to tester pewnie pomyśli, że zapomniałem o Appium lub Calabashu. Choć z tym drugim miałem nawet sporo do czynienia, to nie jestem ich fanem.

Ich wspólnymi cechami są multiplatformowość, powolność i duże wymagania co do czasu implementacji. Niestety dostępność na wielu platformach często nie idzie w parze ze zmniejszeniem czasu implementacji, ponieważ z uwagi na różnice między platformami trzeba poświęcać dużo czasu na debugowanie testów. W dodatku frameworki te wymagają nie tylko znajomości jednej platformy, ale często też drugiej (lub współpracy z inną osobą) oraz dodatkowo Ruby, Basha, JS i Gherkina. Z mojego doświadczenia wynika, że lepszym rozwiązaniem są szybkie natywne testy na każdej platformie i synchronizowanie ich zawartości wedle potrzeb.

Bonus

Pisanie testów UI ma jeszcze jedną zaletę – bardzo ułatwia tworzenie zrzutów ekranu aplikacji do publikacji w App Store. Przy użyciu fastlane snapshot dzieje się to niemal magicznie. 10 zrzutów pomnożone przez 7 rozmiarów oraz 28 języków to sumarycznie 1960 obrazków. Z pewnością nie chcecie robić tego ręcznie nawet raz, a co dopiero przy każdej aktualizacji!

Podsumowanie

Testy UI to bardzo rozległy temat, więc nie da się wszystkiego opisać w tak krótkiej formie. Mimo to mam nadzieję, że ten tekst wam się przydał i przybliżył trochę tematykę testowania UI na iOS. Jeśli macie propozycje kolejnych tematów, zapraszam zostawiania komentarzy. Prędzej czy później na wszystkie odpowiem!

A teraz…

Zobacz poprzednie teksty!

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

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

Środa dla Śeb’ie [devstyle vlog #180]

The post Środa dla Śeb’ie [devstyle vlog #180] appeared first on devstyle.pl.

Wednewsday #22 – programistyczne nowinki

Jak w każdą środę zapraszam was na porcje nowości i ciekawostek dla programistów.

Sorting Algorithms Animations – animacje porównujące efektywność algorytmów sortujących.
Artwork Personalization at Netflix
Postmortem — why Allegro went down – w lipcu Allegro padło na chwilę z powodu niezwykle okazyjnej oferty na telefon. Postmortem z tego inceydentu.
Programming Languages are not Languages
Microsoft Rewards – system lojalnościowy od Microsoft.
Web Design Museum – muzeum designu stron internetowych.
Comparing OSS on GitHub –  gh-compare to aplikacja terminalowa pozwalająca porównać właściwości projektów hostowanych na GitHub.
60 Days RL Challenge – dołącz do 60 dniowego wyzwania i zdobądź wiedzę nt Reinforcement Learning.
GoLang School IS LIVE –  szkoła języka GO osadzona w  “Królestwie, w którym Gophers wszelkiego rodzaju żyją w pokoju, dzielą się, kształcą i rozwijają pragmatyczne, idiomatyczne oprogramowanie GoLang.”
My way of Conducting an Interview – Adam Sitnik dzieli się poradami na przeprowadzanie z kandydatem rozmowy o pracę.
This is my bag of tricks – Autor strony dzieli się swoimi zapiskami, notatkami, ciekawymi linkami. Taki worek z wszystkim co może się przydać.
Why do we count starting from zero? – w 12 punkcie (albo 11 licząc od zera) zerknijcie dlaczego liczymy od zera.
Wasabi – dynamic analysis framework for WebAssembly.
PYPL PopularitY of Programming Language – to znana strona, która prócz rankingu popularności języków programowania zawiera także ranking edytorów. Moją uwagę zwrócił Light Table
HACKTOBERFEST 2018 — COMING SOON – już w październiku kolejna edycja Hacktoberfest.

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 #22 – programistyczne nowinki appeared first on devstyle.pl.

Fotograf czy programista? [devstyle vlog #179]

The post Fotograf czy programista? [devstyle vlog #179] appeared first on devstyle.pl.

Parostatkiem w piękny… re.js? meet.js special w Białymstoku

Ja się pytam: co to ma być?! Czy ktoś na górze brał prysznic i zapomniał zakręcić kurek z zimną wodą? Jak można w ostatnie dni wakacji zepsuć pogodę i usilnie starać się, aby Białystok odzyskał dostęp do morza?! Proszę zaprzestać!!! I tak, wiem, ostatnio narzekałam, że jest za gorąco, ale hej! Nie byłabym Polką, gdybym tego nie robiła.

A więc plany wakacyjne diabli wzięli. Weekend wolny, zatem trzeba pobuszować w internetach i znaleźć jakieś zajęcie dla siebie. A gdyby tak… Aha! Wiedziałam! Jedną z propozycji wyświetlanych na twarzoksiążce było meet.js special summer edition 2018 (w skrócie: meet.js). Po szybkim przejrzeniu agendy stwierdziłam, że może być ciekawie, zwłaszcza że jako student nie pogardzę darmowym obiadem (PIZZA!!! :D).

Szybkie pakowanie, klucze, telefon i jazda do siedziby Instytutu Informatyki na kampusie Uniwersytetu w Białymstoku przy ulicy Konstantego Ciołkowskiego 1M. Trzeba się było streszczać, gdyż już przed godziną 9 można było załatwić rejestrację, a przy okazji dostać fajny upominek w postaci gift baga z przydatnymi fantami od organizatorów i sponsorów wydarzenia. Dzięki, chłopaki.

Po zagarnięciu przekąsek – bo oczywiście nie zdążyłam zjeść śniadania – i przywitaniu się z przyjaciółmi swoje kroki skierowałam ku auli, na której miały niedługo rozpocząć się prezentacje. Po drodze natknęłam się na przedstawicieli firm Pagepro oraz Instapage – jednych ze sponsorów wydarzenia. Oba stoiska od samego rana były oblegane przez uczestników chętnych do zadawania pytań i brania udziału w konkursach w celu wygrania ciekawych nagród.

Gdy już się przedarłam przez gąszcz ludziów, wpadłam na aulę i zajęłam swoje miejsce. Po krótkiej chwili na scenę wszedł Maksymilian Zyskowski – jeden z tegorocznych organizatorów wydarzenia, a prywatnie fanatyk JS w każdej postaci. Szybko przedstawił nam sponsorów i opowiedział, co nas czeka, a następnie zaprosił na scenę pierwszego prelegenta.

Progressive web apps with Ionic – Build amazing cross-platform apps, with the web

Panie i Panowie, na scenę wkroczyła Marta Wiśniewska – web developer z firmy Eversis. Nie ukrywam, miło było zobaczyć koleżankę po fachu jako prelegenta. Przyjechała do nas z Warszawy i to był jej pierwszy raz w tej roli na naszym meetupie. Jej prezentacja to tak naprawdę temat pracy magisterskiej, więc zna go bardzo dobrze. Ale chwila, chwila… Czy ja się przesłyszałam? „One, two, three, check, check”. Co się dzieje? Ha ha! Niespodzianka prawie tak samo zaskakująca jak hiszpańska inkwizycja. Marta poprowadzi prezentację w języku angielskim. SZOK! Do tej pory nie spotkałam się z tym na naszych meetupach, ale dostałam w późniejszym wywiadzie wyjaśnienie, że w stolicy to norma. Moim zdaniem świetny pomysł i fajnie, żeby wprowadzić to jako standard na naszych programistycznych spotkaniach. W końcu jesteśmy programistami, więc posługiwanie się językiem angielskim nie powinno być dla nas obce, a ponadto takie wystąpienia mogą pomóc nam go podszlifować. A Wy co o tym myślicie?

Wracając do samej prezentacji… Temat bardzo ciekawy. W czasie wystąpienia dostaliśmy konkretne informacje, jak od A do Z zbudować własną wersję Gadu-Gadu (swoja drogą, pamiętacie jeszcze swoje numery?). Marta opowiedziała szczegółowo o aplikacjach PWA i o różnicach pomiędzy nimi a aplikacjami natywnymi. Przedstawiła również kilka firm korzystających z rozwiązań z użyciem PWA, m.in. AliExpress czy Forbes. Może znacie jakieś inne firmy, które mogłyby się pochwalić takimi rozwiązaniami? A jaki jest Wasz stosunek do tego? Zostawcie informacje w komentarzu. ;)

Jeżeli miałabym podsumować prezentację jednym słowem, powiedziałabym: SUPER! Dziewczyna ma wiedzę i chce się nią dzielić. Jeżeli ciekawi Was ten temat i chcielibyście się czegoś więcej dowiedzieć, Marta bardzo aktywnie udziela się w social mediach (Twitter, Facebook) i na pewno Wam odpowie.

Oczywiście nawet najciekawsze wystąpienia nie trwają wiecznie, więc prezentacja Marty dobiegła końca. Publiczność nagrodziła ją gromkimi brawami i na scenie pojawił się Maksymilian, by ogłosić krótką przerwę, w czasie której mogłam porwać Martę na pamiątkowe zdjęcie. :D

W czasie przerwy udało mi się jeszcze dostać kawę i zwinąć kilka ciastek ze stolika z przekąskami – byłam gotowa na kolejną prezentację. Tym razem prelekcja miała dotyczyć zaawansowanych zagadnień, więc trzeba było ustawić porządny focus na target.

Zaawansowany React & Redux

I znowu niespodzianka. Na scenie pojawił się nie jeden, ale dwóch prelegentów – Norbert Kamieński jako JavaScript developer oraz Tomasz Chmiel jako frontent developer – koledzy z firmy Pagepro. Na warsztat wzięli nie lada zadanie – w czasie swojej prezentacji chcieli pokazać jak najwięcej możliwości Reacta oraz Reduxa. To nie pierwszy raz, gdy możemy spotkać chłopaków w tej roli – jak mi zdradzili, występowali z tą prezentacją dla studentów Politechniki Białostockiej, a skoro zainteresowanie było spore, chcieli iść z nią dalej. Ba, nawet wspomnieli coś o warsztatach, więc śledźcie stronę internetową Pagepro oraz fanpage na Facebooku, ponieważ tam mogą pojawić się informacje o ich poczynaniach. Panowie zdradzili też, że nie mają dużego doświadczenia w przemawianiu do publiczności, dlatego prowadzą prezentacje razem. Dobre podejście! Ilu z nas boi się wystąpić samemu, a wraz z przyjacielem jest nam o wiele łatwiej. Nawet jeśli sprowadza się to do słynnego „Ja dzwonię, ty mówisz”, to i tak jest raźniej.

Sama prelekcja przyniosła dużo przykładów użycia kodu i sporo zagadnień, ale brakowało troszkę płynności pomiędzy przejściami. Przyznam szczerze, że w pewnym momencie się pogubiłam – może to dlatego, że nie mam aż takiego doświadczenia z JS, jakim dysponują chłopaki. Na pewno zaciekawili tematem na tyle, aby został na dłużej w głowie. Myślę, że dla wielu bardziej doświadczonych developerów prezentacja mogła być rozszerzeniem tematu, zaś dla początkujących – świetną okazją do zgłębiania wiedzy na własną rękę. Oczywiście panowie przedstawili ciekawe przykłady wraz z opisem ich ewentualnych zastosowań, co pomogło usystematyzować ogrom przekazywanej przez nich wiedzy.

Podsumowując – prelekcja ciekawa i warto pochylić się nad tematem, jednak potrzeba na to trochę więcej czasu niż godzina prezentacji.

Czas minął i dostaliśmy następną krótką przerwę na rozprostowanie nóg. W tym czasie kolejny prelegent przygotowywał się do wystąpienia.

RxJS: Tailor-made, or is it?

Kolejnym naszym gościem zza granicy Podlasia był Łukasz Stankiewicz – senior developer z warszawskiej siedziby firmy Instapage. Jego prezentacja miała na celu odpowiedzieć na pytanie: czy RxJS zostanie z nami na dłużej, czy może jednak szybko o nim zapomnimy?

Łukasz przedstawił nam kilka ciekawostek o wykorzystaniu języka w projektach komercyjnych, m.in. fakt, iż uwielbiany przez wszystkich portal Netflix został stworzony z wykorzystaniem RxJS, oraz to, że Angular również korzysta z jego dobrodziejstw. Dziękujmy twórcom RxJS, bo gdyby nie oni, nudzilibyśmy się w pracy. :D

Co do samej prezentacji – ciekawie poprowadzona. Wystąpienie skłoniło wielu ludzi do drążenia tematu oraz zadawania pytań. Na pewno miło jest, gdy na koniec prezentacji publiczność jest głodna wiedzy. I tak tym razem było. Wystąpienie Łukasza skłoniło publiczność do refleksji oraz dyskusji. Ponadto dostaliśmy wiele przykładów kodu i ciekawych przypadków użycia, które mogą się przydać w pracy.

W późniejszej rozmowie Łukasz zdradził mi, że chętnie pojawi się w Białymstoku jeszcze raz i wystąpi z nową prezentacją. Po zakończonej rozmowie przyszedł czas na pamiątkowe selfie.

Gdy się rozdzieliliśmy, poczułam charakterystyczny zapach unoszący się w powietrzu. Guess what – PIZZA!!!

Pominę teraz opis zachwycania się smakiem i pałaszowania wśród rozmów o prezentacjach, które już widzieliśmy, oraz tych, na które czekaliśmy. Po sprzątnięciu wszystkich smakołyków nadszedł czas na prawdziwe mięso (i nie, nie chodzi o pizzę z dużą ilością salami). Panie i Panowie, przed Państwem senior wśród seniorów, Łuuuukaaaaasz…

Wzorcowe architektoniczne puzzle

Dobra, przyznać się – kto z Was miał wzorce projektowe na studiach? Widzę las rąk. A kto je lubił? Raz, dwa, znowu raz… Kolega się jednak rozmyślił. Nie oszukujmy się, temat wzorców projektowych sam w sobie jest bardzo ciekawy w teorii, ale jak przychodzi co do czego i trzeba go użyć, to wtedy świat nie jest już taki kolorowy. Otóż Łukasz Piotr Łuczak przyjechał do nas aż z Łodzi z misją pokazania nam, że jednak może być inaczej. Znacie wyrażenie „programistyczne mięso”, prawda? Jeżeli nie, to wyobraźcie sobie, że przy tym terminie na Wikipedii byłaby podpięta właśnie jego prezentacja. Uwierzcie mi, po wyjściu z tego wykładu czułam, że moja kopuła paruje. CO TO BYŁO?! Ale do rzeczy.

Jak stwierdził autor, pomysł na prezentację kiełkował w jego głowie już od kilku ładnych lat. Chciał zebrać wiedzę na temat wzorców architektonicznych w jednym miejscu. Konsultował się z wieloma cenionymi programistami, m.in. Maćkiem Aniserowiczem (ktoś go kojarzy?), Mariuszem Gilem, Sławkiem Sobótką (pozdrawiamy Panów), i dzięki wspomnianym rozmowom powstała ta prezentacja. Kolejnym natchnieniem do jej zrobienia był znaleziony przez Łukasza blog, na którym autor poruszał ten sam problem w formie artykułów.

A sama prezentacja… to – serio – sztos. Łukasz przez około godzinę dostarczał nam dawkę porządnej wiedzy na temat wzorców architektonicznych (tak, było nawet DDD – delete driver development). I muszę się przyznać – mimo że godzina była późna, a kilka prezentacji było już za nami, to siedziałam jak wmurowana i chłonęłam każde słowo. Niesamowite doświadczenie.

Za podsumowanie tej prelekcji niech posłuży idealnie pasująca rozmowa, jaka wynikła między Łukaszem a jednym z uczestników spotkania. Zadał on pytanie o to, czy po tym wszystkim, co przedstawił nam autor prezentacji, kodzenie nadal sprawia mu przyjemność. Łukasz stwierdził, że już od jakiegoś czasu woli doradzać, niż programować. I w sumie mu się nie dziwię. Na pożegnanie i szybkie podsumowanie całego wystąpienia przytoczył nam taką oto anegdotkę: Jeżeli zapytam juniora, ile zajmie mu to czasu, usłyszę odpowiedź: 2 dni. Jeżeli o to samo zapytam mida, odpowie, że tydzień. Senior podrapie się po głowie i uzna, że miesiąc, zaś architekt stwierdzi, że tego nie da się zrobić.

I tym miłym akcentem zakończyła się przedostatnia prezentacja. Czekało nas jeszcze ostatnie, chyba najbardziej tajemnicze wystąpienie tego dnia.

Front-end is an Art

Tego człowieka chyba nie muszę przedstawiać. Każdy coś o nim słyszał. Jego nazwisko pojawia się na wielu eventach technicznych, ale nie tylko. Maczał palce przy Programistoku i Up To Date. Można go spotkać prawie codziennie w siedzibie Hacklagu. Czy już wiecie, o kim mowa? Tututuruuuuu!!! Przed Wami Maciek Korsan (owacje na stojąco). Rok temu zaprezentował nam porządną dawkę rozrywki, a teraz miało być jeszcze więcej dźwięków i jeszcze więcej JS.

Maciek uwielbia eksperymentować z JS i tworzyć z niego użyteczne, aczkolwiek niesztampowe rozwiązania. Jeżeli potrzebujecie wtyczki do przeglądarki, która powstrzyma Was przed bezmyślnym wyrażaniem zgody na wysyłanie newsletterów, to szukajcie pod nazwą CHECKBOX UNICORN. Tylko włączcie dźwięki. ;) Jego głowa jest pełna pomysłów i – uwierzcie mi – realizacja ich wychodzi mu świetnie.

Jego prezentacja oparta była na przedstawieniu kilku z projektów, nad którymi w ostatnim czasie pracował. Pokazał nam, że nawet Krzysztof Krawczyk miał swój wkład w rozwój jednego z mało znanych frameworków, jakim jest re.js. ;) Jego występy to tak naprawdę minikoncerty, na których Maciek ma świetny kontakt z publicznością. Dzięki temu można śmiało stwierdzić, że obronił on postawioną przez siebie tezę, że programowanie frontów to sztuka. Ciekawe, czy w przyszłym roku jeszcze bardziej rozkręci swoje show i zaskoczy nas swoimi pomysłami.

Niestety nic nie może przecież wiecznie trwać, a więc i ta prezentacja dobiegła końca. Jednak hola, hola, jeszcze się nie rozchodzimy, ponieważ organizatorzy (nasi dzielni trzej muszkieterowie) w składzie Karol Rogowski, Przemysław Wiszowaty oraz wspomniany wcześniej Maksymilian Zyskowski przygotowali dla nas miłą niespodziankę.

And the winner is…

DARMOWE FANTY!!! No kto pogardzi pięknym kubeczkiem, słuchawkami, myszką czy przenośnym głośnikiem? No kto? Ale to nie wszystko. Pamiętacie, że już niedługo w naszym pięknym Białymstoku odbędzie się najlepsiejsza, najbardziej programistyczna konfa w Polsce, jaką jest Programistok? No więc organizatorzy nie zapomnieli także o tym i w losowaniu nagród mieliśmy również szansę wygrania biletu na to wydarzenie. Wystarczyło tylko zostać do końca i wziąć udział w losowaniu. I wiecie co? Niektórym nie chciało się nawet tego, w wyniku czego wielu uczestników straciło szansę na nagrodę. Tak blisko, tak blisko, jak… jak…? Po rozdaniu fantów nagrodziliśmy brawami organizatorów oraz sponsorów, bo bez nich ta konfa by się nie odbyła.

Parostatkiem w piękny reeeeeejs…

Co tu dużo mówić. Za każdym razem, gdy słyszę króla Krzysztofa w radiu, wspominam prezentację Maćka. Gdy widzę, jak kolega w pracy walczy z architekturą projektu (panie, a kto to panu tak sp… zepsuł), przypomina mi się Łukasz. Słyszę temat PWA – przed oczami mam Martę i jej appkę Gadu-Gadu. Nie działa mi axios i mam kłopot z Reduxem? Chłopaki z Pagepro służą pomocą. Oglądam ulubiony serial na Netflixie – pozdrowienia dla Łukasza Stankiewicza.

Jak sami widzicie – ile osób, tyle pomysłów na wykorzystanie JS. Co więcej, na tej konferencji można było spotkać nie tylko samych zapaleńców, ale również osoby, które dopiero zaczynają albo chcą zacząć swoją przygodę z programowaniem. Jeżeli pragniecie dowiedzieć się czegoś nowego ze świata JS lub utrwalić jakąś wiedzę, to takie spotkania są naprawdę warte uwagi. Ja ze swojej strony mogę powiedzieć tylko jedną rzecz: dziękuję. Dziękuję organizatorom, sponsorom, ale również uczestnikom, bo dzięki Wam ta cała maszyna działa i ma się świetnie. Mam nadzieję, że za rok spotkamy się na kolejnej edycji i będzie nas jeszcze więcej.

P.S. Wielkie dzięki za zdjęcia dla Korsan Studio (Maciej Korsan), który poratował mnie, gdy mój sprzęt padł. A po więcej fotorelacji zapraszam na fanpage wydarzenia.

The post Parostatkiem w piękny… re.js? meet.js special w Białymstoku appeared first on devstyle.pl.

Wednewsday #21 – programistyczne nowinki

Cześć i czołem. 21. odcinek programistycznych nowinek właśnie wylądował. Dziś w programie:
Why is there an abundance of mediocre programmers but a lack of quality programmers? – dyskusja na Quora dotycząca przeciętnych programistów i dlaczego ich liczba przeważa,
The Ultimate Course and Book list to be an expert in Mathematics and Programming – podnieś swoje skille programistyczne i zacznij być ekspertem matematycznym,
twobithistory.org – nostalgiczna strona opisująca początki komputerów i języków programowania,
Best Open Source Tools For Developers – przydatne w pracy developera otwarte narzędzia,
Announcing the Arduino Command Line Interface – zwolennicy CLI w końcu mogą porzucić GUI Arduino,
New Side-Channel Attack Uses Microphone to Read Screen Content – najnowszy rodzaj ataku pozwalający zobaczyć to, co masz na monitorze, przy pomocy mikrofonów,
The Coming Revolution In Software Development – jak będzie wyglądać nadchodząca rewolucja w wytwarzaniu oprogramowania. A może to już tak jest? Ale czy na pewno? Hmmm…,
10 Common Git Problems and How to Fix Them – remedium na 10 najczęstszych problemów z GIT-em,
100 Times Faster Natural Language Processing in Python – Python na sterydach potrafi być szybki. Tutaj przykład optymalizacji Neurolingwistyczne przetwarzania,
Agile in 2018 – Martin Fowler w prezentacji nt. Agile, jego drogi do głównej metodologii wytwarzania oprogramowania oraz sukcesów i porażek.

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 #21 – programistyczne nowinki appeared first on devstyle.pl.