„Uszanowanko Programowanko”: magia urządzeń IoT

Liczba odsłon: 64

Czy chcesz za­raz po wy­łą­cze­niu bu­dzi­ka czuć za­pach świe­żo pa­rzo­nej ka­wy? Lub by błę­dy wdro­że­nia naj­now­szej wer­sji apli­kac­ji po­wo­do­wa­ły za­pa­le­nie się wiel­kie­go ostrze­gaw­cze­go świat­ła w sa­li? Jeżeli tak, to po­le­cam lek­tu­rę re­lac­ji z XXIX spot­ka­nia „Uszanowanko Programowanko”, któ­re mia­ło miej­sce 11 lip­ca 2018 ro­ku w gli­wic­kiej sie­dzi­bie The Software House i by­ło po­świę­co­ne in­te­grac­ji apli­kac­ji front-end z urzą­dze­nia­mi IoT.

Pierwsze wy­stą­pie­nie po­pro­wa­dził Marcin Gajda, senior front-end deve­lo­per w The Software House. Zaczął on od przed­sta­wie­nia ko­lej­nych eta­pów po­to­ku prze­twa­rza­nia stron WWW w no­wo­czes­nej prze­glą­dar­ce ob­słu­gu­ją­cej Java­Script oraz CSS. Potok ten da­je apli­kac­jom sie­cio­wym bar­dzo nie­wiel­kie moż­li­woś­ci in­ge­ro­wa­nia w po­szcze­gól­ne eta­py prze­twa­rza­nia. Skrypty Java­Script ma­ją do­stęp tyl­ko do DOM oraz częś­ci obiek­to­we­go mo­de­lu sty­lu. Utrudnia to two­rze­nie dyna­micz­nych efek­tów wi­zu­al­nych przy nie­wiel­kim ob­cią­że­niu pro­ce­so­ra. Niemożliwe jest też emu­lo­wa­nie cech nie­obec­nych lub błęd­nie za­im­ple­men­to­wa­nych w da­nej wer­sji prze­glą­dar­ki.

Źródło: https://www.smashingmagazine.com/

Rozwią­za­niem są kla­sy work­let. Obiekty tych klas moż­na re­jes­tro­wać w po­szcze­gól­nych eta­pach po­to­ku prze­twa­rza­nia tak, aby na bie­żą­co uczest­ni­czy­ły w pra­cy prze­glą­dar­ki. Czasem funk­cje ob­słu­gi ist­nie­ją­ce w obiek­tach tych klas bę­dą wy­wo­ły­wa­ne tyl­ko przez chwi­lę, w cza­sie wczy­ty­wa­nia stro­ny lub mo­dy­fi­ko­wa­nia jej ukła­du, a cza­sem bez przer­wy, po­zwa­la­jąc po­ka­zy­wać ani­mac­je rea­li­zo­wa­ne przy 60 klat­kach na se­kun­dę.

Rozpropa­go­wa­niem idei klas work­let oraz za­bie­ga­niem o za­im­ple­men­to­wa­nie no­wych funkcjo­nal­noś­ci w prze­glą­dar­kach WWW zaj­mu­je się gru­pa ro­bo­cza Houdini. Jednym z pod­sta­wo­wych, naj­szyb­ciej znaj­du­ją­cych za­sto­so­wa­nie ele­men­tów jest CSS Painting API. Pozwala ono na bie­żą­co, wraz z każ­dą klat­ką ani­ma­cji, mo­dy­fi­ko­wać wy­gląd ele­men­tu za po­mo­cą auto­ma­tycz­nych trans­for­ma­cji CSS lub bez­po­śred­niej mo­dy­fi­ka­cji atry­bu­tów sty­lu. Istotne jest oder­wa­nie ani­ma­cji od bie­gu cza­su: ko­lej­ność kla­tek mo­że za­le­żeć od in­nych war­toś­ci, na przy­kład stop­nia prze­wi­nię­cia za­war­toś­ci wska­za­ne­go ele­men­tu stro­ny. W ten spo­sób nie­któ­re dyna­micz­ne zmia­ny ukła­du stro­ny, do­tych­czas uzys­ki­wa­ne za po­mo­cą dość skom­pli­ko­wa­ne­go ko­du Java­Script, moż­na opi­sać dek­la­ra­tyw­nie za po­mo­cą zwar­te­go, przej­rzy­ste­go ko­du.

Na zwięk­sze­nie efek­tyw­noś­ci mo­dy­fi­ko­wa­nia wy­glą­du stro­ny wpły­nie też no­we API do­stę­pu do atry­bu­tów sty­lu. Obecny CSS Object Model jest pros­ty i sku­tecz­ny, lecz ma­ło do­kład­ny: war­toś­ci wszyst­kich atry­bu­tów za­pi­sy­wa­ne są tek­sto­wo, nie ma też moż­li­woś­ci sto­so­wa­nia bar­dziej skom­pli­ko­wa­nych wy­ra­żeń. Pomóc na to ma CSS Properties and Values API, któ­re da­je moż­li­wość wglą­du w atry­bu­ty sty­lu oraz ich mo­dy­fi­ka­cji z uwzględ­nie­niem ty­pów da­nych Java­Script oraz na­tu­ral­nych jed­nos­tek CSS. Ponadto, twór­cy stron mo­gą re­jes­tro­wać włas­ne atry­bu­ty sty­lu ob­słu­gi­wa­ne przez obiek­ty work­let i w ten spo­sób al­bo wpro­wa­dzać włas­ne efek­ty gra­ficz­ne, al­bo emu­lo­wać za­cho­wa­nia nie ob­słu­gi­wa­ne przez da­ną prze­glą­dar­kę.

Dość kon­tro­wer­syj­nym no­wym po­mys­łem jest Scroll Customi­zation API, za po­mo­cą któ­re­go apli­kac­je mo­gą wpły­wać na za­cho­wa­nie stro­ny w mo­men­cie wy­stą­pie­nia zda­rzeń prze­wi­ja­nia ini­cjo­wa­nych za po­mo­cą my­szy, kla­wia­tu­ry lub in­nych urzą­dzeń ste­ru­ją­cych. W nie­któ­rych przy­pad­kach mo­że to po­zwo­lić na znacz­ne zwięk­sze­nie moż­li­woś­ci pro­gra­mis­ty oraz funkcjo­nal­noś­ci apli­kac­ji sie­cio­wych, jed­nak wi­dzę tu rów­nież du­żo za­gro­żeń zwią­za­nych z blo­ko­wa­niem lub zmia­ną tem­pa prze­wi­ja­nia treś­ci stro­ny.

Innymi, mniej zna­czą­cy­mi, choć mo­gą­cy­mi mieć du­że zna­cze­nie roz­sze­rze­nia­mi pro­po­no­wa­ny­mi przez gru­pę Houdini są CSS Layout API, Box Tree API oraz CSS Parser API. Dwa pierw­sze z nich umoż­li­wia­ją mo­dy­fi­ko­wa­nie ukła­du stro­ny oraz re­jest­ro­wa­nie włas­nych me­cha­niz­mów wy­zna­cza­nia po­ło­że­nia po­szcze­gól­nych ele­men­tów, dzię­ki cze­mu apli­kac­ja mo­że sku­tecz­niej do­pa­so­wy­wać się do roz­mia­ru oraz orien­ta­cji ok­na oraz ska­lo­wa­nia wi­do­ku. Z kolei ostat­ni umoż­li­wia wpły­wa­nie na dzia­ła­nie inter­pre­te­ra CSS, dzię­ki cze­mu moż­li­we jest roz­sze­rze­nie je­go moż­li­woś­ci, ko­ry­go­wa­nie błę­dów oraz emu­lo­wa­nie nie­dos­tęp­nych me­cha­niz­mów.

Wszystkie opi­sy­wa­ne me­cha­niz­my zo­sta­ły przed­sta­wio­ne przez pre­le­gen­ta na ży­wo za po­mo­cą krót­kich przy­kła­dów. Zaintereso­wa­ni mo­gą od­wie­dzić stro­nę na któ­rej zo­sta­ły one za­miesz­czo­ne. Niestety, do ich prze­te­sto­wa­nia nie­zbęd­na jest co naj­mniej naj­now­sza wer­sja prze­glą­dar­ki Google Chro­me, gdyż tyl­ko ona za­wie­ra obec­nie im­ple­men­tac­ję więk­szoś­ci nie­zbęd­nych API. W nie­któ­rych przy­pad­kach mo­że być wręcz nie­zbęd­ne sięg­nię­cie po nie­sta­bil­ną wer­sję Chro­me Canary, eks­pe­ry­men­tal­nie reali­zu­ją­cą nie­któ­re z wy­mie­nio­nych po­my­słów.

Drugą pre­zen­tac­ję przed­sta­wił Szymon Piecuch, full-stack deve­lo­per w The Software House. Poświęcona ona by­ła prob­le­mo­wi zwięk­sze­nia tem­pa re­ago­wa­nia roz­pro­szo­nych apli­kac­ji sie­cio­wych na zmia­ny za­cho­dzą­ce w jed­nym z węz­łów sie­ci. Sposobem na to jest za­sto­so­wa­nie me­cha­niz­mu Web­Socket, w któ­rym po­łą­cze­nie HTTP za­ini­cjo­wa­ne przez klienta mo­że zo­stać prze­kształ­co­ne w dwu­kie­run­ko­we łą­cze po­zwa­la­ją­ce na na­tych­mias­to­we prze­sy­ła­nie in­for­mac­ji, bez ko­niecz­noś­ci re­gu­lar­ne­go od­py­ty­wa­nia.

Samodziel­ne opro­gra­mo­wa­nie ta­kiej ko­mu­ni­kac­ji mo­że być kło­pot­li­we. Na szczęś­cie na ra­tu­nek ru­sza­ją nam go­to­we roz­wią­za­nia, ta­kie jak Crossbar.io. Oprogra­mo­wa­nie to, na­pi­sa­ne w ję­zy­ku Python, ob­słu­gu­je ma­gi­stra­lę zda­rzeń dzia­ła­ją­cą w try­bie pub­lish/sub­scribe, auto­ma­tycz­nie prze­ka­zu­jąc właś­ci­we zda­rze­nia do za­re­jes­tro­wa­nych od­bior­ni­ków. Dzięki te­mu mi­ni­ma­li­zu­je się ruch w sie­ci oraz lik­wi­du­je ko­niecz­ność im­ple­men­to­wa­nia funkcjo­nal­noś­ci tra­se­ra ko­mu­ni­ka­tów na włas­ną rę­kę.

Działanie roz­wią­za­nia zo­sta­ło za­pre­zen­to­wa­ne na dwóch przy­kła­dach. Pierwszy miał wy­miar bar­dzo prak­tycz­ny i po­le­gał na zdal­nym mo­ni­to­ro­wa­niu tem­pe­ra­tu­ry ele­men­tu wy­ko­naw­cze­go. W mo­men­cie prze­kro­cze­nia tem­pe­ra­tu­ry kry­tycz­nej uru­cha­mia­ny był kli­ma­ty­za­tor, któ­re­go na­dmuch chło­dził nad­zo­ro­wa­ny ele­ment aż do mo­men­tu osiąg­nię­cia od­po­wied­nio ni­skiej tem­pe­ra­tu­ry. Ponie­waż zgod­nie z in­for­mac­ja­mi pro­du­cen­ta Crossbar.io mo­że ob­słu­gi­wać na­wet set­ki ty­się­cy węz­łów jed­no­cześ­nie, moż­li­we jest je­go sto­so­wa­nie w sys­te­mach au­to­ma­ty­ki oraz nad­zo­ru.

Drugi przy­kład bliż­szy był pro­gra­mis­tom apli­kac­ji użyt­ko­wych. Mechanizm Web­Socket mo­że zo­stać wy­ko­rzy­sta­ny do na­tych­mias­to­wej ko­mu­ni­kac­ji inter­ne­to­wej, a Crossbar.io świet­nie so­bie ra­dzi z prze­ka­zy­wa­niem in­for­mac­ji o obec­no­ści osób w po­szcze­gól­nych po­ko­jach roz­mów oraz o wy­sy­ła­nych ko­mu­ni­ka­tach. Pokazywa­ny mini-czat zo­stał na­wet zin­te­gro­wa­ny ze ste­row­ni­kiem oświet­le­nia, dzię­ki cze­mu w re­akcji na je­den z ko­mu­ni­ka­tów świat­ło w sa­li za­pa­la­ło się lub gas­ło.

Przedsta­wio­ne roz­wią­za­nie świet­nie na­da­je się do du­żych, roz­pro­szo­nych sys­te­mów w któ­rych naj­istot­niej­sza jest szyb­kość wy­mia­ny in­for­mac­ji, a nie­za­wod­ność dzia­ła­nia nie jest czyn­ni­kiem kry­tycz­nym. Niestety, ser­wer Crossbar.io nie jest wy­po­sa­żo­ny w fil­try po­zwa­la­ją­ce uci­nać po­dej­rza­ne lub błęd­ne stru­mie­nie ko­mu­ni­ka­tów, po­cho­dzą­ce z usz­ko­dzo­ne­go czuj­ni­ka lub złoś­li­we­go opro­gra­mo­wa­nia. Ze wzglę­du na po­ziom skom­pli­ko­wa­nia nie za­stą­pi też ra­czej sys­te­mów wbu­do­wa­nej au­to­ma­ty­ki prze­my­sło­wej, w któ­rych nie ma miej­sca nie tyl­ko na przer­wy w dzia­ła­niu, ale wręcz na nie­de­ter­mi­nis­tycz­ne opóź­nie­nia w do­sta­wie ko­mu­ni­ka­tów.

W ostat­niej pre­zen­tac­ji Tomasz Kajtoch, front-end deve­lo­per w The Software House, za­de­mon­stro­wał spo­sób na pod­łą­cze­nie prak­tycz­nie każ­de­go urzą­dze­nia do sie­ci IoT. Polecił do te­go ce­lu mi­nia­tu­ro­wy mo­duł na­daw­czo-od­bior­czy WiFi ESP8266. Ponie­waż za­wie­ra on rów­nież mi­kro­pro­ce­sor, moż­li­we jest uru­cha­mia­nie w nim opro­gra­mo­wa­nia ste­ru­ją­ce­go oraz ko­mu­ni­ko­wa­nie się z urzą­dze­nia­mi ze­wnętrz­ny­mi za po­mo­cą kil­ku do­stęp­nych złącz. Pierwszym za­de­mon­stro­wa­nym urzą­dze­niem dos­to­so­wa­nym w ten spo­sób do współ­dzia­ła­nia z kom­pu­te­ra­mi by­ła lam­pa ostrze­ga­ją­ca o błę­dzie wdro­że­nia apli­kac­ji. Gdy sys­tem CI wy­kry­wa prob­lem, wy­sy­ła po­le­ce­nie uru­cho­mie­nia lam­py po­sta­wio­nej w sa­li pro­gra­mis­tów i już po chwi­li błys­ka ona, po­wia­da­mia­jąc o wy­kry­tym prob­le­mie.

Dużo więk­sze wra­że­nie zro­bi­ło jed­nak dru­gie do­sto­so­wa­ne urzą­dze­nie. Za po­mo­cą mo­du­łu ESP8266 zwyk­ły eks­pres do ka­wy zo­stał pod­łą­czo­ny do sie­ci i opro­gra­mo­wa­ny tak, by rea­go­wać na po­le­ce­nia REST. Należy po­dzi­wiać po­ziom de­ter­mi­na­cji Autora, któ­ry od­krył spo­sób po­ro­zu­mie­wa­nia się z eks­pre­sem za po­mo­cą łą­cza ser­wi­so­we­go, od­na­lazł in­for­mac­je po­zwa­la­ją­ce od­szyf­ro­wać pro­to­kół ko­mu­ni­ka­cyj­ny i przy­go­to­wał opro­gra­mo­wa­nie za­mie­nia­ją­ce czy­tel­ne wy­wo­ła­nia REST na cią­gi zna­ków ro­zu­mia­ne przez ste­row­nik eks­pre­su. Dzieło zo­sta­ło uwień­czo­ne stwo­rze­niem apli­kac­ji mo­bil­nej peł­nią­cej funk­cję bu­dzi­ka, mo­ty­wu­ją­cej do opu­szcze­nia łóż­ka za­pa­chem świe­żo pa­rzo­nej ka­wy wy­do­by­wa­ją­cym się z uru­cho­mio­ne­go zdal­nie eks­pre­su.

Tak jak po­przed­nio, spot­ka­nie by­ło bar­dzo do­brze przy­go­to­wa­ne or­ga­ni­za­cyj­ne. Należy pod­kre­ślić spój­ność te­ma­ty­ki, dba­nie o do­trzy­ma­nie har­mo­no­gra­mu oraz wy­so­ki po­ziom pre­lek­cji. Każda pre­zen­tac­ja by­ła uzu­peł­nio­na de­mons­trac­ja­mi pro­wa­dzo­ny­mi na ży­wo, w tym z wy­ko­rzys­ta­niem od­po­wied­nio przy­go­to­wa­ne­go i do­sto­so­wa­ne­go sprzę­tu. Wszystko to spra­wia­ło, że wy­stą­pie­nia oglą­da­ło się z za­in­te­re­so­wa­niem, a po każ­dym z nich uczest­ni­cy zgła­sza­li wie­le py­tań.