#main, 11 kwietnia 2016

Powoli wracamy do świa­ta żywych (i pracu­ją­cych) i przy­go­towu­je­my kole­jne tek­sty na blo­ga. W między­cza­sie zaprasza­my do kole­jnego #maina z lekko his­to­ryczną notką biograficzną!

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 ;)

Podsumowanie ankiety z zeszłego tygodnia

Czytel­nika­mi blo­ga najwyraźniej są głównie podróżni­cy i miłośni­cy kąpieli słonecznych :) Jeśli planu­jesz jakieś konkretne wypady w tym roku, pochw­al się w komentarzu!

Nowy obraz Rembrandta

Ostat­nio w sieci pojaw­ił się ciekawy przykład zas­tosowa­nia Machine Learningu i tech­nik 3D — opra­cow­ano algo­rytm, który ‘uczy się’, jak mal­owali mis­tr­zowie, a następ­nie odt­warza ich tech­nikę tworząc nowe dzieła. Nie są to jed­nak kopie ist­nieją­cych — algo­rytm ten poza tech­niczny­mi aspek­ta­mi (sposób kładzenia far­by, styl obrazu itp) uczy się także sty­lu danego malarza (co mal­ował najczęś­ciej, w jakiej per­spek­ty­wie ) i na tej pod­staw­ie generu­je zupełnie nowe dzieło od pod­staw. W przy­pad­ku Rem­brand­ta uznał, że kole­jnym dziełem powinien być biały człowiek w wieku 30–40 lat, z brodą i w kapeluszu. Następ­nie wydrukowano je na drukarce 3D tak, aby efekt przy­pom­i­nał ory­gi­nalne malunki.

Podob­no ‘fałsz­erst­wo’ to jest bard­zo trudne do wykrycia przez osobę nie będącą ekspertem na tem­at twór­c­zoś­ci danego malarza.

Więcej w artykule w ser­wisie NEXT.

HTC Vive

Rzeczy­wis­tość wirtu­al­na to od cza­su pre­miery firmy Ocu­lus gorą­cy tem­at — i słusznie, bo możli­woś­ci są ogromne, od gier i rozry­w­ki, poprzez wiz­ual­iza­c­je danych i e‑learning, na real­isty­cznych wideokon­fer­enc­jach kończąc. I o ile pier­wszy raz o Ocu­lus Rift usłyszeliśmy rok temu i dopiero od niedaw­na moż­na składać zamówienia (będą real­i­zowane w sierp­niu), o tyle HTC postanow­iło zro­bić rewolucję. HTC Vive to nie tylko oku­lary VR — to cały sys­tem, wraz z urządzeni­a­mi wskazu­ją­cy­mi i pozy­cjonu­ją­cy­mi w przestrzeni. Inny­mi słowy — kom­plet­ny sys­tem do różnych zas­tosowań. Przy cenie 899 EUR i dostęp­noś­ci już w czer­w­cu, może być sporą konkurencją dla Ocu­lusa (same oku­lary w cenie 599$). Jedyny minus — aby w pełni z niego korzys­tać (w bez­pieczny sposób) potrze­ba sporo przestrzeni.

Ofic­jal­na strona
Filmik z prezen­tacją dzi­ała­nia w ser­wisie cnet.

Nauka programowania z Billem Gatesem

Na kanale Code.org pojaw­iły się filmy, w których znane oso­by, jak Bill Gates czy Mark Zucker­berg uczą pod­sta­wowych kon­cepcji związanych z pro­gramowaniem — pole­camy dla osób zaczy­na­ją­cych naukę lub jako zachętę dla zna­jomych rozważa­ją­cych czy nie nauczyć się programować ;)

Jeden z filmów — Bill Gates o kon­strukcji ‘if’ i pętlach
Wszys­tkie filmy z tej serii

Vivaldi

Z przeglą­dark­a­mi jest trochę jak z tele­fon­a­mi komórkowy­mi — na początku dosta­je­my wyda­jne rozwiązanie, które po kilku miesią­cach zamienia się w ‘sło­nia’. Swego rodza­ju rewolucję zapro­ponował Chrome, który jed­nak ma coraz więcej funkcji i jest przez to coraz bardziej zasobożerny. Ostat­nio pojaw­iła się nowa alter­naty­wa — przeglą­dar­ka Vival­di. Z założe­nia ma ona być szy­bką, min­i­mal­isty­czną przeglą­darką, którą w prosty sposób moż­na dos­tosować do swoich potrzeb (wygląd, układ okna itp). Jest twor­zona w dużej mierze przez oso­by wcześniej związane z Operą. Ma też kil­ka ‘bonusów’, które uprzy­jem­ni­a­ją pracę, np. kolor okna dopa­sowu­je się do kolorysty­ki aktu­al­nej strony (co daje zaskaku­ją­co przy­jem­ny efekt), ale co najważniejsze — bazu­je na sil­niku Chromi­um (open-source­owa część przeglą­dar­ki Chrome, która zaw­iera głównie sil­nik ren­derowa­nia stron), przez co jest w 100% zgod­na z dodatka­mi dla przeglą­dar­ki Google Chrome (i moż­na je bez prob­le­mu instalować). Póki co nasze wraże­nia są pozy­ty­wne, zobaczymy za jak­iś czas czy tym razem przeglą­dar­ka dotrzy­ma słowa!

Strona głów­na przeglą­dar­ki Vivaldi
Artykuł z recen­zją w ser­wisie techspot.com

Odpowiedź na pytanie z zeszłego tygodnia

A pytal­iśmy o to: Jak wyglą­da trójwarst­wowy podzi­ał aplikacji w praktyce?

O trójwarst­wowym podziale aplikacji pisal­iśmy już w lekcji #14.1 doty­czącej ser­wisów, tą odpowiedź moż­na trak­tować jako uzu­pełnie­nie tamtej wiedzy.

W stan­dar­d­owym pode­jś­ciu wyróż­ni­amy trzy warst­wy aplikacji (wraz z  ich funkcjami):

• Warst­wę kon­trol­erów / ser­wisów REST 
  • zapew­nia inter­fe­js do komu­nikowa­nia się z sys­te­mem przez użytkown­ików lub inne systemy
  • dokonu­je wal­i­dacji danych przychodzących
  • jest odpowiedzial­ny za uwierzytel­ni­an­ie, może być częś­ciowo odpowiedzial­na za autoryzację
  • obsługu­je błędy z punk­tu widzenia użytkown­i­ka — np. zamienia wyjąt­ki na przy­jazne uzytkown­ikowi komunikaty
  • kon­wer­tu­je obiek­ty z dome­ny zewnętrznej (DTO, API) na wewnętrzną
• Warst­wę logi­ki biz­ne­sowej / ser­wisów wewnętrznych 
  • real­izu­je logikę biz­ne­sową (funkcjon­al­ność systemu)
  • dostar­cza obsłu­gi wyjątków (np. logikę związaną z powtórze­niem oper­acji czy anu­lowaniem jej efektów)
  • inte­gru­je aplikację z inny­mi sys­tema­mi, obsługu­je błędy związane z inte­gracją itp
• Warst­wę per­sys­tencji / źródło danych 
  • kon­wer­tu­je wewnętrzną domenę na obiek­ty specy­ficzne dla sposobu zapisu danych, z jakiego korzystamy
  • utr­wala dane lub je odczy­tu­je, kon­weru­je wyjąt­ki na taki, które są wyko­rzysty­wane w aplikacji

Poniższa grafi­ka obrazu­je jak to dzi­ała — ‘Warst­wa’ to zbiór wszys­t­kich obiek­tów (np. ser­wisów, kon­trol­erów) w danej warst­wie, a ‘Mod­el’ to obiek­ty domenowe i ich ‘zasięg’ (obra­zowe przed­staw­ie­nie, gdzie są wykorzystywane).

Wyni­ka z tego kil­ka pod­sta­wowych zasad, przestrze­ga­jąc których znacznie uproś­cisz sobie życie w przyszłości:

• warst­wy komu­niku­ją się tylko ‘w dół’ i tylko bezpośrednio
• NIGDY dom­e­na wewnętrz­na nie może być uży­wana w zewnętrznych inter­fe­jsach sys­te­mu, podob­nie jak nie może być uży­wana zapisu­jąc dane 
  • jeśli jest potrze­ba udostep­nienia dokład­nie takich samych infor­ma­cji na zewnątrz lub utr­wale­nie infor­ma­cji nie wyma­ga żad­nych zmi­an tego obiek­tu, i tak warto utworzyć dokład­nie iden­ty­czny obiekt i ‘przepisy­wać’ dane w odpowied­niej warstwie
• inter­fe­jsy warst­wy logi­ki biz­ne­sowej i warst­wy per­sys­tencji uży­wa­ją wewnętrznej domeny 
  • oznacza to, że warst­wy skra­jne muszą dokony­wać kon­wer­sji pomiędzy dom­e­na­mi, i jest to ich odpowiedzialność
• poza warst­wą ser­wisów (i w wyjątkowych przy­pad­kach per­sys­tencji), komu­nikac­ja pomiędzy różny­mi kom­po­nen­ta­mi danej warst­wy (np. dwoma kon­trol­era­mi czy dwoma DAO) nie powin­na ist­nieć w aplikacji

Choć cza­sem nie jest to łatwe, a niekiedy aż prosi się o pójś­cie na skró­ty, dzię­ki stosowa­niu się do tych zasad dosta­je­my kil­ka ważnych korzyści:

• zmi­ana tech­nologii prze­chowywa­nia danych nie wpły­wa na reszte aplikacji i jest ‘przezroczys­ta’
• obiek­ty domenowe (wewnętrzny mod­el) pozbaw­ione są adnotacji/logiki związanych z zapisy­waniem danych i ich wal­i­dacją czy przesyłaniem poza system
• mając dzi­ała­jącą aplikację może­my stworzyć do niej dodatkowe API czy inter­fe­js, nie wpły­wa­jąc na ist­niejące elementy
• jeśli w aplikacji jest prob­lem, wiado­mo gdzie go szukać w kodzie
• użytkown­ik przy­pad­kowo nie uzys­ka dostępu do wewnętrznych infor­ma­cji (np. uży­wa­jąc wewnętrznego obiek­tu ‘user’ moglibyśmy udostęp­nić na zewnątrz hasło czy inne wrażli­we dane)
• inter­fe­js aplikacji (lub jej zewnętrzne API) może być zor­ga­ni­zowane inaczej, niż aplikac­ja wewnętrznie

Oczy­wiś­cie to jed­na z wielu kon­cepcji budowy aplikacji (choć najpop­u­larniejsza i najbardziej uni­w­er­sal­na). W przyszłoś­ci przy­bliżymy inne opc­je i ich wady/zalety.

Czym jest JVM (maszyna wirtualna Javy)?

Oczy­wiś­cie zachę­camy do samodziel­nego odpowiedzenia na pytanie. Za tydzień nasza odpowiedź.

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

James L. Buie

Bohaterem tej edy­cji #main jest mniej znana postać, która jed­nak znaczą­co wpłynęła na współczes­ną branżę IT. Mowa o Jame­sie Buie, wynalaz­cy logi­ki TTL.

James był weter­anem II wojny świa­towej, po wojnie zatrud­nił się w lab­o­ra­to­ri­ach TRW (obec­nie Northrop Grum­man) gdzie zaj­mował się elek­tron­iką i elek­trotech­niką, głównie na użytek wojs­ka. Jego najbardziej znanym odkryciem z 1961 roku jest TTL (ang. Tran­sis­tor — Tran­sis­tor Log­ic), która to do dzisi­aj uży­wana jest do pro­dukcji układów scalonych i kom­put­erów. Odkrycie to miało fun­da­men­talne znacze­nie, ponieważ wcześniej uży­wane tech­nolo­gie (RTL, DTL) korzys­tały z różnego rodza­ju kom­po­nen­tów do budowy bramek log­icznych — z tego powodu były one duże (fizy­cznie), i ich rozmi­ar ograniczał możli­woś­ci zas­tosowa­nia i zwięk­szał koszt pro­dukcji. TTL to w uproszcze­niu sposób na budowę bramek log­icznych (czyli elek­tron­icznych odpowied­ników oper­acji ’ | ‘, ’  & ’ i podob­nych znanych z języków pro­gramowa­nia) uży­wa­ją­cy wyłącznie tranzys­torów. To poz­woliło na budowę pier­wszych układów scalonych z prawdzi­wego zdarzenia (patent na układy scalone pochodzi z 1949 roku) — ówcześnie zas­tosowanych oczy­wiś­cie najpierw w raki­etach i innego rodza­ju broni. Co ciekawe, seria układów która pow­stała w tam­tym cza­sie (74xx, seryjnie pro­dukowane od 1964 roku) do dziś jest jed­nym z pop­u­larniejszych ele­men­tów wśród elek­tron­ików-ama­torów (i nie tylko).

Pracę w TRW kon­tyn­uował do swo­jej emery­tu­ry w 1983 roku, sku­pi­a­jąc się przede wszys­tkim na układach scalonych i sys­temach zin­te­growanych. W tej dziedzinie posi­a­da też kil­ka innych paten­tów, m.in. na kon­strukcję układów mnożą­cych jak też sposób przek­sz­tał­ca­nia ‘wafla’ na układy scalone.

Pytanie na ten tydzień