#main, 14 listopada 2016

By 14 November 2016 #main

I połowa listopa­da minęła! W dzisiejszym #mainie, będzie o bańce infor­ma­cyjnej, konkur­sie… resztę musi­cie doczy­tać sami!

Cykl #main to punkt początkowy Waszego tygod­nia,  prasówka, w której zbier­amy ciekawe lin­ki, dzie­limy się infor­ma­c­ja­mi, a także podsyłamy pro­gramisty­czne zadanie. Mamy nadzieję, że w ten sposób umil­imy Wam poniedzi­ałkowy powrót do rzeczywistości ;)

22–23 listopada DevOpsDays Warsaw

Pro­gramowanie to nie tylko tworze­nie… to też rozwój i utrzymy­wanie pro­duk­tu! Dlat­ego warto być na bieżą­co i uczest­niczyć w wydarzeni­ach sku­pi­onych wokół tego tem­atu. My z przy­jem­noś­cią zaprasza­my na DevOps­Days War­saw i przy­pom­i­namy, że do wtorku na naszym blogu trwa konkurs, w którym do wygra­nia wejś­ciówka na to wydarzenie.

Więcej szczegółów na tem­at kon­fer­encji zna­jdziecie na stron­ie wydarzenia.

Żyjemy w bańce informacyjnej

Czy kiedykol­wiek zas­tanaw­iałeś się jed­nak, jak to jest po drugiej stron­ie? Warto zdawać sobie sprawę z mech­a­nizmów doboru treś­ci, bo wpły­wa­ją one na nasze codzi­enne życie. Poniżej zna­jdziecie link do pro­jek­tu, który pokazu­je jak wyglą­da face­book osób o prze­ci­wnych poglądach.

Link do pro­jek­tu blue feed, red feed

#MamoPracujwIT we Wrocławiu

Inic­jaty­wa, której szcz­erze kibicu­je­my zawi­ta do Wrocław­ia. Pod­czas spotka­nia (28.11) poz­na­cie his­to­rie mam, które zmieniły branżę na IT, a także posłucha­cie o lokalnych inic­jatywach dla kobi­et. Jeśli zas­tanaw­iasz się nad prze­branżowie­niem to spotkanie może rozwiać wąt­pli­woś­ci zapraszamy!

Link do wydarzenia

TurnOff.us

Dobrego, geekowego humoru nigdy za dużo. Dzisi­aj pole­camy komiks turnoff, który nie tylko bawi, ale i uczy w fajny sposób tłu­macząc poję­cia związane z programowaniem ;)

Książki o VR

VR stało się rzeczy­wis­toś­cią. Warto być może zain­tere­sować się tym, jak tworzyć takie pro­jek­ty. W poniższym artykule zna­jdziecie spis książek, które poz­wolą Wam tworzyć VR.

Link do artykułu

Odpowiedź na pytanie z zeszłego tygodnia

A pytal­iśmy o to: jak zwięk­szyć dostęp­ność aplikacji (oraz odporność na prob­le­my)? — chodzi o to jak zapo­biec sytu­acji, w której awaria jed­nego ele­men­tu powodu­je awarie całego systemu.

Ist­nieje kil­ka sposobów na zwięk­sze­nie dostęp­noś­ci aplikacji, w zależnoś­ci od potrzeb częs­to imple­men­tu­je się kil­ka / więk­szość z nich. Najważniejsze aspek­ty to:
  • Zapewnie­nie zapa­sowych zasobów, czyli np. uru­chomie­nie aplikacji na wielu ser­w­er­ach jed­nocześnie oraz upewnie­nie się, że awaria jednego/kilku z nich nie spowodu­je prob­lemów z resztą
  • Zapewnie­nie odpowied­niego mon­i­toringu i reakcji — jeśli jeden ser­w­er zaczy­na zachowywać się inaczej (np. nie odpowia­da na zapy­ta­nia), konieczne jest zapewnie­nie mech­a­nizmów aby go odłączyć od aplikacji i zastąpić możli­wie szy­bko (najlepiej w sposób automatyczny)
  • Pro­jek­towanie sys­te­mu w taki sposób, aby kom­po­nen­ty mogły dzi­ałać możli­wie nieza­leżnie od siebie (ang. decou­pling) oraz aby w miarę możli­woś­ci nie prze­chowywały stanu sys­te­mu lokalnie (ang. state­less) — celem jest sytu­ac­ja, w której dowolne zapy­tanie może być obsłużone przez dowol­ny fizy­czny ser­w­er (czyli obsłu­ga zapy­ta­nia nie wyma­ga kon­tek­stu, lub kon­tekst ten jest prze­chowywany w sposób umożli­wia­ją­cy jego odczyt przez dowol­ny serwer)
  • Rozprosze­nie geograficzne — ser­w­ery powin­ny zna­j­dować się fizy­cznie w kilku ser­werow­n­i­ach, przez co awaria jed­nej z nich nie ma wpły­wu na dzi­ałanie systemu
  • Redun­danc­ja — najważniejsze kom­po­nen­ty powin­ny być zdublowane i na wypadek awarii jed­nego z nich, pozostałe powin­ny prze­jąć jego zadania/funkcje bez prz­er­wy w dzi­ała­niu (doty­czy to zarówno ele­men­tów fizy­cznych — zasi­lanie, połącze­nie sieciowe itp, jak i log­icznych — np. prze­chowywanie plików w kilku kopi­ach, rep­li­ki bazy danych, macierze dyskowe itp)
  • Pro­ce­dury przy­wraca­nia — nawet jeśli sys­tem był do tej pory nieza­wod­ny, konieczne jest posi­adanie pro­ce­dur (i narzędzi) odt­worzenia sys­te­mu po jego 100% awarii — sce­nar­iusz taki powinien też być testowany względ­nie reg­u­larnie aby upewnić się, że nie jest tylko teo­re­ty­czną listą życzeń i założeń
Oczy­wiś­cie to tylko najważniejsze ele­men­ty, które niekoniecznie są możli­we do imple­men­tacji w każdym sys­temie — dokładne kro­ki muszą zależeć od konkret­nych potrzeb i real­nych kosztów imple­men­tacji vs potenc­jal­nej awarii.

 

Zadanie programistyczne

Napisz pro­gram, który zna­jdzie najdłuższy wspól­ny ciąg znaków dla dwóch wyrazów.

Przykład:

“kot”, “samolot” –> “ot”

“beton”, “beto­niar­ka” –> “beton”

“zupa”, “ilość” –> “”

 

Więcej pytań tech­nicznych z poprzed­nich mainów wraz z linka­mi do odpowiedzi zna­jdziesz tutaj! 

Tayo Sobomehim

Olatayo “Tayo” Sobome­hin, ma 11 lat, gra w koszykówkę, jest muzykiem a także programistą! 

W 2015, został najł­mod­szym uczest­nikiem Street­Code Academy’s Inno­va­tion Accel­er­a­tor i zaczął tworze­nie: Spike Rush, aplikacji na iPhona. Została ona zaak­cep­towana w App Store we wrześniu 2016 i okaza­ła się prawdzi­wym sukce­sem.  Sam Mark Zucker­berg dał jej 5 gwiazdek i napisał na swoim face­booku: “My first games were sim­pler than Tayo’s … I’m look­ing for­ward to see­ing what Tayo builds next!”  

Z niecier­pli­woś­cią czekamy na kole­jny pro­jekt młod­szego kole­gi po fachu.

Pytanie na ten tydzień

W tym tygod­niu nieco zmieni­amy for­mułę – zami­ast pytań od nas, czekamy na Two­je pytanie! Napisz w komen­tarzu, na FB lub w mailu do nas swo­je pytanie, a my w każdym tygod­niu wybierze­my jed­no z nich!