RSS

Gorrion Unplugged #3: aplikacje zasługujące na Oscara

Liczba odsłon: 163

27 wrześ­nia w gli­wic­kiej sie­dzi­bie fir­my Gorrion od­by­ło się ko­lej­ne spot­ka­nie z cyk­lu Gorrion Unplugged. Cykl ten na sta­łe wszedł już w ka­len­darz wy­da­rzeń pro­gra­mis­tycz­nych w Gli­wi­cach. Od pierw­szej edy­cji, któ­ra z po­wo­du awarii za­si­la­nia ma­ło co nie zo­sta­ła od­wo­ła­na (stąd un­plugged w naz­wie) pra­cow­ni­cy Gorrion przed­sta­wia­ją naj­cie­kaw­sze wed­ług nich na­rzę­dzia, roz­wią­za­nia i tech­ni­ki pro­gra­mi­stycz­ne. Wszystko to w mrocz­nej at­mo­sfe­rze przy­po­mi­na­ją­cej o oko­licz­noś­ciach pierw­sze­go spot­ka­nia, przy przy­ga­szo­nych świat­łach, z fluo­res­cen­cyj­ny­mi opas­ka­mi na rę­kach.

Pierwsza pre­zen­tac­ja, przed­sta­wio­na przez Tomka i za­ty­tu­ło­wa­na „Budowanie pros­te­go ser­we­ra chat”, sta­no­wi­ła wpro­wa­dze­nie do two­rze­nia opro­gra­mo­wa­nia z wy­ko­rzys­ta­niem osno­wy pro­gra­mi­stycz­nej Nest.js. Osnowa ta zo­sta­ła stwo­rzo­na przez ab­sol­wen­ta Politech­ni­ki Śląskiej, Kamila Myśliwca. Stosuje się ją w częś­ci ser­we­ro­wej apli­kac­ji Node.js. Narzuca ona archi­tek­tu­rę apli­kac­ji, usu­wa­jąc przy tym ko­niecz­ność sa­mo­dziel­ne­go za­pi­sy­wa­nia pew­nych kon­struk­cji. W za­mian za­sto­so­wa­ne zo­sta­ło roz­wią­za­nie zna­ne mię­dzy in­ny­mi z ję­zy­ka Java: ad­no­ta­cje. Za ich po­mo­cą za­rów­no opi­su­je­my po­szcze­gól­ne mo­du­ły i za­leż­noś­ci mię­dzy ni­mi, jak i wska­zu­je­my ro­lę po­szcze­gól­nych klas, me­tod i pa­ra­met­rów.

Nest.js naj­le­piej współ­pra­cu­je z ję­zy­kiem Type­Script, jed­nak jest zgod­ny rów­nież z „czys­tym” ję­zy­kiem Java­Script.

Szkielet apli­kac­ji naj­łat­wiej jest zbu­do­wać ko­rzy­sta­jąc ze stan­dar­do­we­go na­rzę­dzia CLI. Następ­nie mo­że­my przy­stą­pić do za­pi­sy­wa­nia po­szcze­gól­nych mo­du­łów ko­du. Warto sto­so­wać za­sa­dę, że je­den mo­duł od­po­wia­da jed­nej gru­pie funkcjo­nal­noś­ci apli­kac­ji.

W ra­mach mo­du­łu moż­na two­rzyć kla­sy do­staw­ców, ser­wi­sów, kon­tro­le­rów i bram. Dostawcy (ang. pro­vi­ders) rea­li­zu­ją wzo­rzec fab­ry­ki obiek­tów, dos­tar­cza­jąc skon­fi­gu­ro­wa­ne in­stan­cje obiek­tów re­pre­zen­tu­ją­cych usłu­gi. Za po­mo­cą kla­sy do­staw­cy moż­na na przy­kład na­wią­zy­wać po­łą­cze­nie z ba­zą da­nych. Stworzony obiekt po­łą­cze­nia jest wstrzy­ki­wa­ny na­stęp­nie wszę­dzie tam, gdzie reali­zu­je się ope­rac­je na ba­zie.

Serwis (ang. ser­vi­ce) udo­stęp­nia usłu­gi po­zo­sta­łym mo­du­łom. Serwisy sta­no­wią swe­go ro­dza­ju od­po­wied­nik bez­sta­no­wych zia­ren EJB. Metody reali­zu­ją­ce pe­wien inter­fejs biz­ne­so­wy są asyn­chro­nicz­ne, gdyż rea­li­zo­wa­ne dzia­ła­nia mo­gą wy­ma­gać ko­mu­ni­kac­ji z ze­wnętrz­ny­mi za­so­ba­mi.

Kontroler (ang. con­trol­ler) re­pre­zen­tu­je zbiór punk­tów do­stę­po­wych (ang. end­point) API REST. Każda me­to­da kla­sy od­zwier­cied­la je­den punkt do­stę­po­wy i jest ad­no­to­wa­na w spo­sób po­dob­ny do sto­so­wa­ne­go przez JAX-RS, z okre­śle­niem ścież­ki względ­nej oraz me­to­dy do­stę­po­wej HTTP. Kontroler po­wi­nien wstrzy­ki­wać obiek­ty ser­wi­sów i wy­ko­rzys­ty­wać je do reali­zo­wa­nia swo­ich dzia­łań.

Z kolei bra­my (ang. gate­ways) umoż­li­wia­ją ob­słu­gę ko­mu­ni­kac­ji z wy­ko­rzys­ta­niem stan­dar­du Web­Socket. Adnota­cje, któ­ry­mi opat­ru­je się po­szcze­gól­ne me­to­dy umoż­li­wia­ją po­wią­za­nie tych me­tod z kon­kret­ny­mi ro­dza­ja­mi nad­sy­ła­nych ko­mu­ni­ka­tów.

Prezentację zwień­czy­ła de­mon­strac­ja, w ra­mach któ­rej zo­sta­ła na­pi­sa­na i uru­cho­mio­na część ser­we­ro­wa apli­kac­ji po­zwa­la­ją­cej na wy­mia­nę ko­mu­ni­ka­tów mię­dzy użyt­kow­ni­ka­mi w cza­sie rze­czy­wis­tym. Za po­mo­cą API REST apli­kac­ja po­bie­ra­ła wszyst­kie do­tych­czas wy­sła­ne ko­mu­ni­ka­ty pod­czas uru­cha­mia­nia. Dalsza ko­res­pon­den­cja by­ła rea­li­zo­wa­na ka­na­łem Web­Socket, a wszyst­kie publi­ko­wa­ne ko­mu­ni­ka­ty by­ły za­pi­sy­wa­ne w ba­zie da­nych MongoDB i roz­pro­wa­dza­ne do po­zo­sta­łych klien­tów.


Druga pre­zen­tac­ja, za­ty­tu­ło­wa­na „Wprowadze­nie do Akka.net: na­pisz kod, któ­ry za­słu­gu­je na Oscara” i przed­sta­wio­na przez Dawida, prze­nios­ła uczest­ni­ków w świat ję­zy­ka C#. W ra­mach wy­stą­pie­nia po­ka­za­na zo­sta­ła bi­blio­te­ka Akka.net, im­ple­men­tu­ją­ca w tym ję­zy­ku mo­del pro­gra­mo­wa­nia ba­zu­ją­ce­go na kon­cep­cji akto­rów. Koncepcja ta zo­sta­ła opra­co­wa­na już 45 lat te­mu i wdro­żo­na ja­ko pod­sta­wa ję­zy­ka pro­gra­mo­wa­nia Erlang, jed­nak nig­dy nie zdo­by­ła szer­szej po­pu­lar­noś­ci. Roz­wią­zu­je ona prob­lem bez­pie­czeń­stwa apli­kac­ji współ­bież­nych, sze­re­gu­jąc wszyst­kie dzia­ła­nia wy­ko­ny­wa­ne w ra­mach po­je­dyn­cze­go obiek­tu tak, aby nig­dy je­go kod nie był wy­ko­ny­wa­ny w wię­cej niż jed­nym wąt­ku. Uzyskuje się to przez za­stą­pie­nie wy­wo­łań me­tod prze­ka­zy­wa­niem ko­mu­ni­ka­tów, przy czym ko­lej­ny ko­mu­ni­kat mo­że być ob­słu­żo­ny do­pie­ro po za­koń­cze­niu prze­twa­rza­nia po­przed­nie­go. Dzięki te­mu nie ma ko­niecz­noś­ci sto­so­wa­nia me­cha­niz­mów syn­chro­ni­za­cji.

Każdy obiekt, na­zy­wa­ny akto­rem, ist­nie­je w ra­mach hie­rar­chicz­nej struk­tu­ry. Każdy aktor mo­że two­rzyć włas­ne obiek­ty pod­rzęd­ne, zle­cać im dzia­ła­nia i mo­ni­to­ro­wać ich stan. Błąd wy­stę­pu­ją­cy w jed­nym z akto­rów mo­że zo­stać ob­słu­żo­ny przez akto­ra-ro­dzi­ca lub prze­ka­za­ny (eska­lo­wa­ny) do dal­szej ob­słu­gi tak, aby za­rea­go­wał na nie­go aktor dys­po­nu­ją­cy od­po­wied­ni­mi moż­li­woś­cia­mi. Aktor, w któ­rym wy­stą­pił błąd mo­że zo­stać przy­wró­co­ny do dzia­ła­nia lub od­two­rzo­ny ze sta­nem po­cząt­ko­wym. Takie moż­li­woś­ci re­ago­wa­nia na błę­dy, w po­łą­cze­niu z moż­li­woś­cią wy­mie­nia­nia im­ple­men­tac­ji akto­rów w cza­sie dzia­ła­nia sys­te­mu, skut­ku­ją bar­dzo wy­so­ką od­por­noś­cią na błę­dy i łat­woś­cią usu­wa­nia zna­le­zio­nych uste­rek.

Aktor mo­że zle­cać pra­cę in­nym obiek­tom al­bo w spo­sób asyn­chro­nicz­ny (bez cze­ka­nia na in­for­mac­ję zwrot­ną), al­bo syn­chro­nicz­ny (z ocze­ki­wa­niem na wy­nik). Oczywiś­cie, ze wzglę­dów wy­daj­no­ścio­wych pre­fe­ro­wa­ne jest po­dejś­cie asyn­chro­nicz­ne. Każda ope­rac­ja syn­chro­nicz­na po­wo­du­je wstrzy­ma­nie akto­ra do mo­men­tu uzys­ka­nia od­po­wie­dzi na ko­mu­ni­kat, co po­wo­du­je brak moż­li­woś­ci od­po­wia­da­nia przez nie­go na ko­lej­ne nad­cho­dzą­ce wia­do­moś­ci.

System ba­zu­ją­cy na ak­to­rach moż­na łat­wo ska­lo­wać. Poszcze­gól­ni akto­rzy mo­gą być two­rze­ni na wie­lu kom­pu­te­rach, a wia­do­moś­ci mo­gą być prze­ka­zy­wa­ne mię­dzy ni­mi po­przez sieć. W ra­zie stwier­dze­nia nie­wy­dol­noś­ci sys­te­mu spo­wo­do­wa­nej wy­so­kim ob­cią­że­niem za­so­bów moż­na za­tem szyb­ko roz­pro­szyć prze­twa­rza­nie bez ko­niecz­noś­ci in­wes­to­wa­nia w szyb­szy, droż­szy sprzęt.

W ra­mach pre­zen­tac­ji zo­sta­ła przed­sta­wio­na apli­kac­ja na­pi­sa­na z wy­ko­rzys­ta­niem bi­blio­te­ki Akka.net, skła­da­ją­ca się z kil­ku ko­mu­ni­ku­ją­cych się ze so­bą akto­rów. Pokazany zo­stał spo­sób ob­słu­gi błę­dów tak, aby sytu­acja wy­jąt­ko­wa ge­ne­ro­wa­na przez jed­ne­go akto­ra mog­ła zo­stać prze­chwy­co­na i ob­słu­żo­na przez akto­ra zle­ca­ją­ce­go dzia­ła­nie.

Prelegent wy­mie­nił też naj­częst­sze błę­dy po­peł­nia­ne przy sto­so­wa­niu kon­cep­cji akto­rów oraz bi­blio­te­ki Akka.net. Do naj­częst­szych na­le­ży nad­uży­wa­nie ko­mu­ni­ka­tów syn­chro­nicz­nych, dra­ma­tycz­nie ogra­ni­cza­ją­cych wy­daj­ność. Może to też pro­wa­dzić do za­pęt­le­nia za­py­ta­nia­mi syn­chro­nicz­ny­mi, gdy aktor, od­po­wia­da­jąc na ko­mu­ni­kat syn­chro­nicz­ny, do­ma­ga się – rów­nież syn­chro­nicz­nie – da­nych od uśpio­ne­go w tym cza­sie akto­ra wy­sy­ła­ją­ce­go orygi­nal­ne za­py­ta­nie. Powinno się uni­kać two­rze­nia mu­to­wal­nych klas wia­do­moś­ci, aby nie do­puś­cić do zmia­ny treś­ci żą­da­nia w cza­sie, gdy cze­ka ono do­pie­ro na reali­zac­ję. Operacje rea­li­zo­wa­ne przez akto­rów po­win­ny być krót­kie, a w mia­rę moż­li­woś­ci na­le­ży je roz­dzie­lać mię­dzy kil­ku akto­rów pod­rzęd­nych.


Trzecią pre­zen­tac­ję, za­ty­tu­ło­wa­ną „Skomponuj so­bie coś faj­ne­go z docker-com­pose”, przed­sta­wił Łukasz. Na po­cząt­ku przed­sta­wił on prob­lem: jak za­pew­nić łat­wość i po­wta­rzal­ność wdro­że­nia apli­kac­ji i wy­ma­ga­ne­go przez nią śro­do­wis­ka, czy to na kom­pu­te­rze pro­gra­mis­ty, czy u klienta? Rozwią­za­niem jest kon­te­ne­ry­zac­ja, w któ­rej apli­ka­cję wraz ze wszyst­ki­mi po­trzeb­ny­mi na­rzę­dzia­mi i bi­blio­te­ka­mi roz­pro­wa­dza się w po­sta­ci go­to­we­go obra­zu i uru­cha­mia się w wir­tu­al­nym, od­se­pa­ro­wa­nym śro­do­wis­ku.

Kontenery­zac­ja przy­po­mi­na wir­tu­ali­zac­ję, róż­niąc się od niej jed­nym istot­nym szcze­gó­łem. W przy­pad­ku wir­tu­ali­zac­ji każ­da ma­szy­na wir­tu­al­na za­wie­ra kom­plet­ną ko­pię do­wol­ne­go sys­te­mu opera­cyj­ne­go i cha­rak­te­ry­zu­je się ob­cią­że­niem za­so­bów nie­wie­le mniej­szym, niż to sa­mo śro­do­wis­ko uru­cho­mio­ne na od­dziel­nym kom­pu­te­rze. W przy­pad­ku kon­te­ne­ry­zac­ji sys­tem opera­cyj­ny ist­nie­je tyl­ko w jed­nej kopii, a po­szcze­gól­ne śro­do­wis­ka wir­tu­al­ne są wy­dzie­la­ne tyl­ko za po­mo­cą je­go wbu­do­wa­nych me­cha­niz­mów prze­strze­ni nazw. Dzięki te­mu ko­lej­ne uru­cha­mia­ne kon­te­ne­ry, choć po­wie­la­ją część śro­do­wis­ka, ob­cią­ża­ją za­so­by w du­żo mniej­szym sto­pniu, niż ma­szy­ny wir­tu­al­ne.

Najpopular­niej­szym obec­nie sys­te­mem kon­te­ne­ry­zac­ji jest Docker. Jego użyt­kow­nik sta­je jed­nak przed prob­le­mem: w ja­ki spo­sób udos­tęp­nić nie tyl­ko włas­ną apli­ka­cję, ale też wszyst­kie po­trzeb­ne jej na­rzę­dzia i bi­blio­te­ki? Można oczy­wiś­cie stwo­rzyć plik docker­file sca­la­ją­cy wie­le obra­zów w je­den, jed­nak nie jest to roz­wią­za­nie ele­ganc­kie.

Alterna­ty­wą jest na­rzę­dzie docker-com­pose, opi­sa­ne przez pre­le­gen­ta. Wykonuje ono in­struk­cje za­pi­sa­ne w pli­ku YAML naz­wa­nym docker-com­pose.yml, uru­cha­mia­jąc nie­za­leż­ne kon­te­ne­ry w usta­lo­nej ko­lej­noś­ci. Dla każ­de­go tak uru­cha­mia­ne­go kon­te­ne­ra po­da­je się też tab­li­cę trans­lac­ji por­tów. Oczywiś­cie, nie zwal­nia to z obo­wiąz­ku sca­le­nia obra­zów ściś­le ze so­bą współ­pra­cu­ją­cych ele­men­tów, jed­nak wy­dzie­lo­ne frag­men­ty in­fra­struk­tu­ry, ko­mu­ni­ku­ją­ce się z po­zo­sta­ły­mi po­przez sieć, mo­gą zo­stać uru­cho­mio­ne z go­to­wych obra­zów.

Dodatko­wą za­le­tą docker-com­pose jest moż­li­wość usta­la­nia zmien­nych śro­do­wis­ko­wych do­stęp­nych w ra­mach kon­te­ne­rów. Dzięki te­mu mo­że­my stwo­rzyć ze­staw pli­ków kon­fi­gu­ra­cyj­nych uru­cha­mia­ją­cych usłu­gi z róż­ną kon­fi­gu­rac­ją. Przydaje się to w przy­pad­ku wdra­ża­nia tej sa­mej apli­kac­ji u róż­nych klien­tów lub w śro­do­wis­ku tes­to­wym i pro­duk­cyj­nym.

Prezentację zwień­czy­ła de­mon­strac­ja po­le­ga­ją­ca na uru­cho­mie­niu usłu­gi skła­da­ją­cej się z wie­lu mo­du­łów:

Wszystkie ele­men­ty zo­sta­ły przy­go­to­wa­ne w spo­sób umoż­li­wia­ją­cy prze­ka­za­nie klu­czo­wych ele­men­tów kon­fi­gu­ra­cyj­nych (mię­dzy in­ny­mi adre­sów po­szcze­gól­nych usług) za po­mo­cą zmien­nych śro­do­wis­ko­wych. Prelegent przy­go­to­wał plik docker-com­pose.yml, w któ­rym okreś­lo­ne zo­sta­ły za­leż­noś­ci mię­dzy skład­ni­ka­mi (de­cy­du­ją­ce o ko­lej­noś­ci uru­cha­mia­nia usług), od­wzo­ro­wa­nie por­tów oraz war­toś­ci zmien­nych śro­do­wis­ko­wych prze­ka­zy­wa­nych do po­szcze­gól­nych kon­te­ne­rów. Następ­nie uru­cho­mił ca­łą zło­żo­ną usłu­gę i po­ka­zał, jak na­rzę­dzie docker-com­pose ko­lej­no po­bie­ra i uru­cha­mia po­trzeb­ne obra­zy, udo­stęp­nia­jąc ca­łą uru­cha­mia­ną apli­ka­cję.


Ostatnia pre­zen­tac­ja, za­ty­tu­ło­wa­na „Dokumentacja API i in­ne ta­kie, czy­li Swagger w .NET Core” i przed­sta­wio­na przez Mariusza, do­ty­czy­ła spo­so­bu do­ku­men­to­wa­nia API REST w apli­kac­jach .NET Core. Opisywany pa­kiet Swagger jest wie­lo­plat­for­mo­wym kom­ple­tem na­rzę­dzi poz­wa­la­ją­cych za­rzą­dzać da­ny­mi opi­su­ją­cy­mi za­im­ple­men­to­wa­ne usłu­gi zgod­nie ze stan­dar­dem OpenAPI. Jego naj­waż­niej­sze skład­ni­ki to Swagger Editor, po­zwa­la­ją­cy w wy­god­ny spo­sób two­rzyć pli­ki opi­su API oraz Swagger UI, pre­zen­tu­ją­cy te pli­ki w oknie prze­glą­dar­ki w este­tycz­nej, in­ter­ak­tyw­nej for­mie, po­zwa­la­ją­cej na bie­żą­co te­sto­wać opi­sa­ne API.

Przygoto­wa­nie, a co naj­waż­niej­sze ak­tua­li­zo­wa­nie opi­su API to jed­nak bar­dzo cięż­ka pra­ca. Dużo le­piej by­ło­by zmu­sić do niej kom­pu­ter. Robi to bi­blio­te­ka Swash­buckle, in­teg­ru­ją­ca się ze śro­do­wis­kiem i apli­kac­ja­mi .NET Core. Podczas uru­cha­mia­nia prze­glą­da ona wszyst­kie kla­sy im­ple­men­tu­ją­ce punk­ty do­stę­po­we (ang. end­points) API REST i auto­ma­tycz­nie ge­ne­ru­je opis. Dodatkowo, do­łą­cza ona do apli­kac­ji mo­duł Swagger UI, dzię­ki cze­mu pod wska­za­ną ścież­ką do­stęp­ny jest gra­ficz­ny, in­ter­ak­tyw­ny wgląd w API.

Informacje uzys­ka­ne z ana­li­zy me­tod po­zwa­la­ją umieś­cić w opi­sie API tyl­ko pod­sta­wo­we da­ne tech­nicz­ne. Jeżeli do­ku­men­tac­ja ma być bar­dziej szcze­gó­ło­wa, pro­gra­mis­ta mu­si wło­żyć pra­cę w uzu­peł­nie­nie ko­men­ta­rzy XML po­szcze­gól­nych me­tod. Swash­buckle roz­poz­na­je też kil­ka do­dat­ko­wych znacz­ni­ków ko­men­ta­rzy, poz­wa­la­ją­cych opi­sać na przy­kład zwra­ca­ne ko­dy od­po­wie­dzi HTTP. Włożona pra­ca zwra­ca się w dwój­na­sób, gdyż uzu­peł­nio­ne ko­men­ta­rze bę­dą przy­dat­ne i pro­gra­mis­tom pra­cu­ją­cym nad pro­jek­tem, i użyt­kow­ni­kom API apli­kac­ji.

Również ta pre­zen­tac­ja za­wie­ra­ła część prak­tycz­ną, w ra­mach któ­rej ist­nie­ją­ca apli­kac­ja REST zo­sta­ła uzu­peł­nio­na o ob­słu­gę opi­su zgod­ne­go z OpenAPI oraz moż­li­wość gra­ficz­ne­go pre­zen­to­wa­nia i tes­to­wa­nia API. Prelegent roz­bu­do­wał też API o no­wą me­to­dę i po­ka­zał w ja­ki spo­sób moż­na uzu­peł­nić kon­fi­gu­rac­ję Swash­buckle tak, aby sku­tecz­nie te­sto­wać no­wą funkcjo­nal­ność.


Organiza­to­rzy za­dba­li o utrzy­ma­nie cha­rak­te­ry­stycz­nej at­mos­fe­ry spot­ka­nia. Wszyscy uczest­ni­cy otrzy­ma­li na wejś­ciu fluo­res­cen­cyj­ne opas­ki na rę­kę, świe­cą­ce w pa­nu­ją­cych w sie­dzi­bie fir­my ciem­no­ściach. Pomieszcze­nia roz­jaś­nia­ły je­dy­nie lamp­ki oz­dob­ne oraz rzut­nik. Wyjątko­wo świat­ło włą­czo­no na czas przer­wy, pod­czas któ­rej uczest­ni­cy zo­sta­li po­czę­sto­wa­ni pizzą. Cały czas do dys­po­zyc­ji po­zos­ta­wa­ły też na­po­je.

Ze wzglę­du na du­że za­in­te­re­so­wa­nie po­przed­nim spot­ka­niem, or­ga­ni­za­to­rzy wpro­wa­dzi­li li­mit licz­by uczest­ni­ków. Spowodowa­ło to jed­nak drob­ne kło­po­ty or­ga­ni­za­cyj­ne. Część za­re­jes­tro­wa­nych osób nie przy­szła, przez co roz­po­czę­cie opóź­ni­ło się nie­co, gdyż trze­ba by­ło po­cze­kać na nie­co więk­sze za­peł­nie­nie sa­li. Dłużej niż za­kła­da­no trwa­ły też sa­me pre­zen­tac­je. Zaplanowa­ny na ko­niec spot­ka­nia po­czę­stu­nek do­tarł z kolei nie­co przed cza­sem i trze­ba by­ło zor­ga­ni­zo­wać przer­wę już po pierw­szych dwóch pre­zen­tac­jach. W efek­cie za­koń­cze­nie na­stą­pi­ło do­pie­ro oko­ło 22:00.

Warto pod­kre­ślić wy­so­ki po­ziom me­ry­to­rycz­ny spot­ka­nia. Osoby za­in­te­re­so­wa­ne two­rze­niem częś­ci ser­we­ro­wej opro­gra­mo­wa­nia mog­ły do­wie­dzieć się o wie­lu no­wych tech­ni­kach i zdo­być in­spi­ra­cję, by pod­nieść ja­kość two­rzo­nych roz­wią­zań przez właś­ci­we do­ku­men­to­wa­nie API, kon­te­ne­ry­zo­wa­nie do­star­cza­ne­go ko­du i ko­rzy­sta­nie z roz­wią­zań archi­tek­to­nicz­nych za­pew­nia­ją­cych bez­pie­czeń­stwo ko­du współ­bież­ne­go.

Zgodnie z za­po­wie­dzia­mi, ko­lej­ne spot­ka­nie z cyk­lu Gorrion Unplugged bę­dzie mia­ło miej­sce już w no­wej sie­dzi­bie fir­my, na uli­cy Błogosła­wio­ne­go Czesława. Powinno to po­zwo­lić zwięk­szyć ska­lę wy­da­rze­nia i ułat­wić je­go or­ga­ni­za­cję.