Brainscape's Knowledge GenomeTM

Browse over 1 million classes created by top students, professors, publishers, and experts.


See full index

FAV > PIA > Flashcards

PIA Flashcards

1
Q

kvalita SW se da merit

A

pocet stiznosti od uzivatelu
pocet chyb nalezenych v produkci
cena za udrzbu
naklady na dalsi vyvoj

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
2
Q

validace

A

= aplikace dela to co si zakaznik preje

dosazeno pomoci komunikace se zakaznikem

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
3
Q

verifikace

A

overeni ze aplikace dela co rika specifikace

  • dosazeno pomoci testovani
  • je dulezity s tim jak aplikace roste
  • je nutne mit dobry vyvojovy cyklus a automatizaci
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
4
Q

testovani - cíl

A

nalezt chyby, rozbit aplikaci

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
5
Q

debuggovani

A

cil: nalezt priciny chyb
- jednoduche pri vyvoji
- tezke na produkci
- nemuzeme si jen tak pripojit debugger
- aplikace uz obsahuje realna data

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
6
Q

specifičnost webové aplikace při testování

A
  • muze se rychle menit (HTML, …)
  • prirozene je to vicevlaknova aplikace
  • potencialni muze celit vyssi zatezi nez je ocekavano (DoS utok)
    => nutne zotaveni
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
7
Q

Unit Testy

A
  • testuji malou cast kodu (vetsinou funkci nebo metodu)
  • vytvareny programatory
  • mely by byt na sobe nezavisly
  • idealne jedna mnozina unit testu testuje jednu tridu/modul
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
8
Q

Unit Testy - co testují

A
  • korektni vstup
  • krajni hodnoty
  • nekorektni vstup (vyhozeni vyjimek, …)

= jedna metoda vetsinou vyzaduje vice testu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
9
Q

Pokrytí testy a důsledky

A

> 90% aplikacni logiky
pomahaji pri refaktoringu, pridavani funkcionalit, …
specialni pripad je kdyz se testy pisou jeste pred zacatkem programovani - kriticke systemy, nuti nas premyslet o navrhu aplikace

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
10
Q

pri zajisteni nezavislosti testu mame dva pristupy

A

stubs

mocks

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
11
Q

stubs

A
  • specialni implementace zavislosti, ktere metoda vyzaduje
  • napriklad vlastni implementace DAO rozhrani -> ulozeni dat do pameti
  • nevyhoda je kdyz mame velkou aplikaci -> muze se stat ze budeme mit velky pocet stubu (musime se snazit je napsat co nejvic genericke)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
12
Q

mocks

A

frameworky dynamicky za behu vytvari obrazy rozhrani (ktere potrebujeme) s dynamicky definovanym chovanim

musime mit dobrou architekturu (SoC)
je jednodussi vytvaret objektu nez volat primo HTTP pozadavky -> nemusime mit aktivni HTTP server
levne
netestuji funkcionalitu celeho systemu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
13
Q

funkci testy

A
  • testovani funkcionality aplikace jako celku
  • typicky se definuji use-casy, scenare
  • testovani proti bezici aplikaci
  • v jednodussich pripadech plni funkci i integtacniho testu -> pri testovani testujeme i komunikaci s DB atd
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
14
Q

Funkční testy - možnost

A

testovaci scenare

automatizovane funkci testy

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
15
Q

testovaci scenare

A

krok po kroku co ma uzivatel delat
kam ma kliknout, jaky data kam zadat, jaky vystup ma ocekavat
vyvojari by nemeli psat funkci testy protoze vi jak se aplikace ma chovat a za jakych okolnosti pada

mely by je psat lidi co nejsou seznameni s tim jak aplikace vnitrne funguje

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
16
Q

automazitované funkční testy

A
  • scripty
  • levne pri dlouhodobem pouzivani (SW nedela chyby)
  • nakladnejsi na napsani a udrzbu (ID v HTML, XPATH, atd se meni pomerne casto)
  • jednodusi pro testovani API webove sluzby
  • postman, insomnia
  • vyzva pri testovani Weboveho rozhrani
  • moderni frameworky umi simulovat browser (i headless mode - nemusi se vytvaret okno)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
17
Q

Selenium

A
  • sada nastroju pro testovani aplikace s pouzitim prohlizece
  • muzeme je bud nahrat (manualne naklikat) nebo napsat pomoci IDE
  • musime pri navrhu stranek mit v pameti ze se budou testovat -> napr definovat ID
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
18
Q

Robot framework

A
  • dovoluje definovat tetovaci scenare bez programovani
  • “vygeneruje” kod (pomoci klicovych slov)
  • naprvni pohled je videt co ten test dela
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
19
Q

integracni testy

A

testovani ze pripojeni a posilani zprav mezi dvouma systemama funguje tak jak ma

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
20
Q

vykonostni testy

A
  • mely by se pouste proti production-like prostredi
  • overeni ze aplikace zvladne zatez jako pri realnem provozu
  • overeni ze nove verze aplikaci nemaji vykonostni dopad
  • overeni jak se aplikace chova pri velke zatezi
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
21
Q

smoke testy

A
  • podmnozina nasi testovaci sady
  • jejich ukolem je overi ze nasazeni aplikace probehlo v poradku, aplikace odpovida (zda se ze funguje)
  • nesnazime se aplikaci zatizit
  • nechceme po sobe nechat data v DB
  • pouziva se na produkci (nechceme poustet celou testovaci sadu)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
22
Q

testy “nepouzitelnosti”

A
  • testovani jak jednoduche je pouziti daneho UI - user experience
  • zeptame se nekolik uzivatelu jak se jim aplikace pouziva
  • zjistime jak uzivatele pouzivaji nasi aplikaci (nemusi byt tak jak jsme ocekavali)
  • nedaji se automatizovat
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
23
Q

typy logu

A
  • aplikacni logy - zpravy popisujici co se v aplikaci deje (jaka trida, jaka metoda, …)
    => info, warn, error, debug, trace
  • pristupovy logy - vsechny volani funkci aplikace z vnejsi site (ip, date, response, POST, GET, …)
    => neobsahuje data (mohou byt citlive)
  • auditacni logy - sledovani co dany uzivatel dela
    => mohou obsahovat i citlive udaje
    => nejsou pristupne vsem lidem ve firme
    => kdo, kdy, co za akci, kontext (muze obsahovat data/udaji)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
24
Q

Moderni logovani

A
  • logy se neukladaji primo na aplikacni server
  • logy ukladame do cloud storage
  • ma smysl napriklad pri skalovani aplikace
  • mame jedno misto kam ukladat logy
  • audit logy NESMIME ztratit (aplikacni logy ani tolik nevadi)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
25
Q

HTTP

A
  • bezstavovy (server si nepamatuje kdo kdy poslal jakej pozadavek - nijak se neovlivnuji)
  • textovy protokol

Verze:
verze 1 - nejvice pouzivana
nevyhoda: pro kazde stazeni souboru, poslani pozadavku => jedno TCP spojeni (desitek css, js souboru)
verze 2 - umoznuje posilat vice pozadavku pres jedno TCP spojeni
verze 3 - bezi ne pres TCP ale UDP

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
26
Q

HTTP request

A

…

Example:
GET /index.html HTTP/1.1
Host: www.kiv.zcu.cz

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
27
Q

typy HTTP metod

A

GET, OPTIONS, HEAD, TRACE - nemeni stav
OPTIONS vraci jake metody jsou k dispozici
POST, PUT, DELETE - meni stav

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
28
Q

priklady hlavicek v HTTP requestu

A

host (povinna) - jmeno serveru
origin - jmeno serveru ze ktereho by request poslan
Content-Type - JSON, HTML, TEXT, …
Authorization - jmeno/heslo

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
29
Q

HTTP response

A

<code></code>

…

Example:
HTTP/1.1 200 OK
Content-Type: text/plain
Content-Length: 14
...
Hello, world!</code>
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
30
Q

typy kodu odpovedi:

A 
200 - OK
204 - OK, ale neposilam ti zpet zadny obsah (napr u POST)
301 - redirect
401 - unauthorized (musis se prihlasit)
403 - forbidden (nemas prava)
404 - stranka nenalezena
500 - chyba na strane serveru
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
31
Q

Cookies:

A
  • zavadeji stavovost do jinak bezstavoveho protokolu
  • klient odesila cookie spolu s requestem -> server vi ze se jedna o daneho klienta a nacte jeho session (napr z distribuovane cache v pripade horizontalniho skalovani)
  • pouziva se napr i k sledovani uzivatelu - viz reklamy
  • cookie obsahuje session ID
  • muze vest k bezpecnostnim rizikum - ukradeni cookie
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
32
Q

nastavení cookie přes http hlavičku

A

Set-Cookie: name=value [; EXPIRES=dateValue]
[;DOMAIN=domainName][;PATH=pathName][;SECURE][;…]

  • secure: odesli pouze pokud se jedna o HTTPS
  • expires: doba platnosti cookie
  • domain: nastavene browserem, napr zcu.cz, kdyz pujdu na FB tak se cookie posilat nebude
  • path: cesta pro kterou se ma cookie odesilat napr zcu.cz/admin
    => klient posle vsechny cookie pokud sedi domena, cesta, nevyprsela doba platnosti a pripadne se jedna o HTTPS (ne jen HTTP)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
33
Q

HTML WebStorage API

A

alternativa misto cookie
aplikace si mohou ukladat data v prohlizeni
nemusi se posilat na sever s kazdym requestem (narozdil od cookie)
pristupne z JS
data jsou ulozena dokud nezanikne session/nezavre se tab

Window.localStorage
sessionStorage.setItem('key', 'value');
let data = sessionStorage.getItem('key');
sessionStorage.removeItem('key');
sessionStorage.clear();
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
34
Q

Forward proxy

A

requesty do externi site
nahrazuje IP addr zroje svoji IP
dovoluje restrikci kam se uzivatel pripojuje (napr z firemni site)
client → proxy → internet

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
35
Q

Reverse proxy

A

requesty do externi site
nahrazuje IP addr zroje svoji IP
dovoluje restrikci kam se uzivatel pripojuje (napr z firemni site)
client → proxy → internet

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
36
Q

Separation of Concerns

A
  • kod ktery delat neco jinyho (jinou praci) by mel byt oddeleny (lepsi testovani, znovupouzitelnost, prehlednost)
  • napr registrace uzivatele a validate stupnich dat by mely byt oddelene
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
37
Q

Single Responsibility Principle

A
  • kazda trida by mela zajistovat prave jednu cinnost

- mixovani funkcionalit vede ke spatnemu testovani, neprehlednosti, atd.

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
38
Q

zapouzderni

A
  • kazda instance ma svuj stav (dano hodnotamy atributu)
  • zabranit prime zmene stavu instance tridy
  • hodnoty atributu se maji menit vnitrne prostrednictvim definovaneho API
  • automaticke generovani getteru/setteru porusuje princip zapouzdreni
  • ve webovych applikacich komunikujeme pres rozhrani - nemusime znat implementaci
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
39
Q

DRY

A

Don´t Repeat Yourself

  • kopirovani kodu
  • neustale prepisovani dokumentace
  • prekreslovani schemat
  • testovaci pripady
  • po case nejsou synchronizovane s aktualnim stavem projektu
  • > lepsi je puzit nastroj pro automaticke generovani
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
40
Q

Dependency Inversion

A

trida A ma tesnou zavislost na tridu B:

  • tezke nahradit tridu B za jinou
  • lepsi mit zavislost pouze na rozhrani
  • imlementaci pak muzeme zmenit
  • velke urovne abstrakce by nemely zaviset na implementacnich detailech
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
41
Q

Explicit Dependencies

A
  • aplikace/moduly/tridy by mely specifikovat jake zavislosti potrebuji pro svuj beh
  • napr Linux - balickovaci system, pip - requirements.txt, maven, …
  • v pripade kodu je to konstruktor, parametry funkce
  • funkce by mely mit jako parametr vsechny potrebne zavislosti pro sve vykonani
  • tridy maji vsechny potrebne zavislosti definovane v konstruktoru - po jeji inicializaci je trida plne funkci - ma vsechny zavislosti; nepovinne zavislosti -> pres settery
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
42
Q

Inversion of Control

A
  • obecne nas kod neridi tok (beh) programu ale dela to napriklad nejaky framework
    => dependency injection
  • window GUI
  • inversion of control != dependency injection
  • dependency injection reprezentuje princip IoC a ne naopak
  • priklad NEvyuziti IoC - platebni brana pozaduje unikatni ID kazde transakce - klient jej musi vygenerovat. Jak ma ale vedet ktere uz jsou zabrazene? -> generovani by mela dalat sama platebni brana
    => bylo by to v pohode v pripade jednoho zakaznika
    => mozne reseni: alokovat mnozinu ID pro daneho zakaznika ze kterych on bude => nahodne generovat unikatni ID
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
43
Q

Dependency Injection

A

hlavni myslenka: oddeleni kodu pro vytvareni objektu a jejich nastavovani zavislosti od zbytku

  • v kodu jsou nadefinovane zavislosti pomoci kontruktoru
  • pak mame separatni konfiguracni tridu nebo soubor (napr xml nebo json) kde definujeme “naskladani” zavislosti jakych budeme potrebovat
  • snadne nahraznovani zavislosti za jine (vime presne kam jit a kde to zmenit)
  • napriklad pri testovani nahradime DB nejakou in-memory DB
  • povinne zavilosti - pres konstruktor (@RequiredArgsContructor)
  • dobrovolne zavislosti - settery (@Autowired)
  • injectovani primo do atributu (nemusime vytvaret ani konstruktor ani setter) - ani-pattern (ve Springu @Autowired); spise nepouzivat
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
44
Q

Service Lookup

A
  • alternativa k DI
  • existuje objekt ktery zna vsechny instance v danem projektu
  • dao = applicationContext.getBean(“dao”) - vraci instance daneho rozhrani podle jmena ktery pak muzeme priradit jako hodnotu atributu v dane tride
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
45
Q

Dependency Injection vs Service Lookup

A
  • DI vyuziva princip IoC
  • DI muze byt tezsi na debuggovani
  • Service Lookup neni tak flexibilni ale je jednodussi na pouziti
    kdybychom to implementovali sami - pouze mapa instanci
  • Service Lookup vyzaduje mit instanci na globalni objekt ktery drzi vsechny instance
    => v pripade knihoven vynutime uzivatele aby taky pouzival Service Locator
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
46
Q

Web Application Architectures - dva pohledy

A

1) jak je aplikace nasazena - jeji repliky, skalovatelnost, atpd.
=> nasazeni + udrzba
2) jak je aplikace uvnitr organizovana - monolit, micro-services, …

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
47
Q

Web Application Architectures - škálování

A

horizontalni skalovani - mame vice replik dane aplikace

vertikalni skalovani - tunime dany server - vic ram, vic CPU atd

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
48
Q

Monoliticka aplikace

A
  • aplikace je jeden funkci celek, ktery se sklada z vice modulu
  • dela vice cinnosti napr registraci uzivatele, ucetnictvi, tisknuti dokumentu atd
  • jednodussi na testovani, debuggovani, vyvoj - mame jen jedno IDE (repozitar), nasazeni
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
49
Q

Monolitická aplikace - škálování

A
  • v pripade skalovani musime skalovat celou aplikaci i kdyz jsou vytizenne napr jen nektere jeji casti
  • horsi to zacne byt az se aplikace zacne zvetsovat
  • neprehlednost kodu, prace vice programatoru
  • vyzauje dobrou vnitrni architekturu a rozlozeni trid
  • aplikace dlouho startuje
  • cela aplikace musi byt napsana s pouzitim stejne technologie
  • pri zmene frameworku musime celou app prepsat
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
50
Q

SOA - popis

A

Service-Oriented Architecture
- pokus o vyreseni problemu s monolitickou aplikaci
- kazda service je black box
=> komunikujeme pouze pres rozhrani

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
51
Q

SOA - typy komunikace, protokoly

A

Typy:

1) na primo
2) pres frontu zprav - odpoved je jen “jo dobry prijal jsem zpravu - nekdy ji zpracuju”

Protokoly:
HTTP, WebSocket, SOAP, AMQP, MQTT, Stomp

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
52
Q

SOA - nevýhody (5x)

A

1) v pripade SOA komunikujeme pres sit
=> musime mit v pameti transakce (kdyz spadne pripojeni napr), bezpecnost (HTTPS)
- kazda service by mela byt bezstavova - bud vratime error nebo odpoved

2) tezsi debuggovani - danou sluzbu nemusime spravovat my
3) casto jedna aplikace = vice repozitaru, nestaci jedno IDE (ruzne technologie)

4) integracni testy jsou slozitejsi
=> NEJHORSI PRIPAD JE KDYZ DO TOHO INTEGRUJEME MONOLITICKOU APLIKACI - prinasi nevyhody obou reseni

5) pri nastartovani muze zalezet na poradi stupusteni jednotlivych sluzeb

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
53
Q

Microservices - popis

A
  • jedna aplikace rozdelena do vice malych sluzeb
  • kazda sluzba je separatni proces ktery muze/nemusi bezet na stejnem stroji
  • zalozeno na Unixove filozofii - deleje jednu vec a delej ji poradne
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
54
Q

Mirkoservices - výhody (5x)

A

1) jednotlive mikro sluzby jsou jednoduche na vyvoj a udrzbu
2) mikro sluzby nemusi byt napsane ve stejne technologii
3) jednotlive mikrosluzby mohou spravovat jine tymy lidi
4) nemusime skalovat celou aplikaci ale jen dane vytizene mikro sluzby
5) pri aktualizaci nemusime vypinat celou aplikaci

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
55
Q

Mikroservices - nevýhody (5x)

A

1) tezsi na nasezeni kvuli tomu jak je aplikace distribuovana
=> diky Dockeru mame testovaci prostredi (dost pomáhá)
2) vyzaduje intenzivni integracni testy
3) potencialne muze byt vice nakladna - vice serveru, pripojeni
4) kazda mikro sluzba by mela mit sve uloziste
5) use-casy mohou pokryvat vice mikrosluzeb -> nutna dobra komunikace jednotlivych tymu

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
56
Q

Monolith vs Microservices

A
  • zalezi jaky mame use-case
  • monolit je lehci na vyvoj, nasazeni a udrzbu - dokud aplikace prilis nenaroste
  • pro male aplikace se nevyplati komplexita mikro sluzeb
  • pro velke aplikace uz ano
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
57
Q

Common Web Application Design Principles

A
  • kod aplikace je rozdelen do vrstev
  • jednotlive vrstvy implementuje a zapouzdruji danou funkcionalitu
  • komunikace mezi vrstvami probiha pres rozhrani -> jednodussi nahrazeni za jine implementace (napr jiny typ DB) a testovani
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
58
Q

Application Layers – Clean Architecture

A
  • hlavni pavidlo: zavislosti jdou vzdy ze shora dolu
  • entities: data (objekty - napr objednavky) sdilene napric systemem
  • Use Cases: co se da delat nad danyma objektama - aplikacni logika
  • Controllers: pristup ven/dovnitr; rozhrani pro pristup k databazi; vytvareni DAO
  • posledni vrstva: externi frameworky, drivery
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
59
Q

bezne pouzite vrstvy architektury

A

1) prezentacni vrstva
2) aplikacni vrstva (aplikacni logika)
3) datova vrstva

dulezite mit na pameti

  • bezpecnost
  • transakce
  • logovani
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
60
Q

datova vrstva resi:

A
  • format ukladani dat
  • relacni schema v pripade relacnich DB, format v pripade souboru, …
  • mapovani na aplikacni objekty (tridy - DTO, entity)
    cteni/zapis
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
61
Q

business logika resi:

A
  • implementace aplikacni funkcionality
  • zmena stavu entiti
  • volani funkci datoveho uloziste (nizsi vrstvy)
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
62
Q

prezentacni vrstva resi:

A
  • vstup od uzivatele
  • vola nizsi vrstvu (aplikacni logiku)
  • prezentuje vysledky uzivateli
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
63
Q

MVC

A

Model - data a aplikacni logika
View - zobrazuje data z modulu
Controller - zpracovava vstupy od uzivatele

User - uses -> Controller
Controller - manipulates -> Model
Model - updates -> View
View - sees -> User

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
64
Q

Model-View-Presenter

A
  • odebrani propojeni view a modelu
  • Presenter je Controller ktery slouzi jako prostrednik mezi View a Modelem
    View predstavuje jednotlive Widgety (tlacitka, input field, …)
    => kazdy widget ma vlastni presenter ktery obslouzi danou udalost a nastavi nova data na zobrazeni
  • napriklad kazdy formular mas svoji obsuznou funkce - Presenter, ktera se zavola pri odesilani formulare, data se odeslou na server a po prijeti odpovedi se zobrazi vysledek uzivateli
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
65
Q

Model – View - ViewModel

A

dalsi zpusob oddeleni vazby mezi modelem a view (ASP.NET/WPF)

ViewModel poskytuje:

  • data pro view
  • formatuje data z interniho modelu na nejakou zobrazitelnou podobu
  • Prikazy - reakce na vstup od uzivatele (prikazy jsou namapovane na tlacitka, input fieldy atd.)
  • komunikace s View
  • zmena view funguje pres DataBinding a Notifikace
  • komunikace s Modelem
  • ViewModel vola funkce module (aplikacni logika)
  • ViewModel je zpusob implementace Clean Architecture na prezentacni vrstve
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
66
Q

Cross-Cutting Concerns - architektura

A

jista funkcionalita je vyzadovana na vsech vrstvach

1) Bezpecnost - user authentication
=> nutnost implementovat jak na severu (operace nad daty)!! tak i na strane klienta (co vidi/nevidi)

2) Logování
=> vsude abychom vedeli co uzivatel a aplikace delaji

3) Trasnakce
=> aplikacni a datova vrstva musi zajistit atomicnost operaci

Naivni implementace techto veci ma za nasledek tezsi testovani, drahe zmeny, …

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
67
Q

Cross-Cutting Concerns - přístupy

A

1) zavislost na rozhrani (API) + konfigurace
- aplikace je zavisla pouze na rozhrani loggeru a konkretni implementace je pote definovana v konfiguraci -> jednodussi testovani a vymena
- problem je napriklad kdybychom vyvijeli knihovnu -> nutili bychom uzivatele pouzivat konretni implementaci napr loggeru

2) Aspect-Oriented Programming (AOP)

How well did you know this?
1
Not at all
2
3
4
5
Perfectly
68
Q

AOP

A

Aspect-Oriented Programming

Co je to aspekt?
- module (typicky trida) co obsahuje kod ktery bychom museli rozkopirovavat do vsech trid (vsude kde ho chceme pouzit)

Frameworky zajustuji ze ten kod napiseme na jednom misto a on se pote dostane na vsechna mista kde ho chceme mit

  • neco jako makra v C
  • napriklad kdyz budeme logovat - cheme zalogovat casove razitko, nazev metody a logovaci zpravu => tenhle kod chceme napsat jenom jednou
  • nebo napriklad bezpecnost - uzivatel musi mit urcitou roli kdyz chce volat konretni metodu - v jave se pouzivaji anotace
How well did you know this?
1
Not at all
2
3
4
5
Perfectly
69
Q

Terminologie AOP

A

1) Join Point: misto vykonani aspektu (typicky volani metody); misto napojeni
2) Pointcut: predikat ktery vyjadruje to kdy se ma ten aspekt provest - ktery vsechny metody to ma postihovat
3) Advice: kdy se ma provest aspekt v ramci volani - before, after, around, ..
around: napri pri logovani - metoda bere objekt jako parametr - zalogujeme (before), na konci zalogujeme i navratovou hodnotu (after)

70
Q

Weaving

A

U AOP - způsob jakým zavoláme kód aspectu

1) pri kompilaci
- kompilator to musi dovolovat (napr kompilator javy to neumi)
- defakto jako makra v C
- problem pri debuggovani
- je rychlejsi nez ostatni zpusoby

2) pri nacitani
- zajistuje class loader (analyzuje binarky a hleda aspekty pro pointcut)
- nacte modivikovanou verzi class souboru
- vyzauje specialni class loader
- problem pri debuggovani

3) za runtime
- bez modifikace kodu
- casto pouzivano v Jave
- dela se to pres volani proxy trid (namisto puvodnich objektu), ktere obsahuji kod aspektu + zavolaji puvodni metodu
+ vyhoda: puvodni trida je nezmenena
- nevyhody:
1) vice pameti (vytvareni proxy trid)
2) volane metody musi byt public -> nemozne vytvorit pointcut pro private metody
3) nelze pouzit pokud volame metody v ramci jedne tridy (uvnitr) -> vzdycky musi volani probehnout z vnejsku

71
Q

Vrstva persistence dat

A

Vrstva perzistence dat je v architektuře vícevrstvých aplikací zodpovědná za poskytování dat aplikační vrstvě a zajištění jejich perzistence. Nejčastěji bývá realizována pomocí relační databáze, může jít však i o jiný zdroj dat (např. CRM nebo ERP systém, či jiný informační systém).

72
Q

Dopad vrstvy persistence dat na mimofunkční požadavky:

A

1) výkon (performance)
2) bezpečnost (security)
- nachází se vetšinou na jiném místě než aplikace
- nechceme aby je někdo získal (velká hodnota dat)
3) Trvanlivost
nutnost se zotavit i z HW nehod

73
Q

Možnosti uložení dat

A

1) Relační databáze
2) NoSQL
3) Souborový systém

Další možnosti:

  • Alfresco
  • Elastic Search
  • Amazon S3
  • Object databases
74
Q

Relační databáze

A
  • MariaDB, MySQL, PostgreSQL, OracleSQL, Derby, H2, Microsoft SQL Server
  • pro ukládání dat u kterých existuje vazba (tabulky - relace)
  • Relace potřebujeme protože v aplikacích potřebujeme znát vazby mezi nimi
75
Q

NoSQL

A
  • databázové enginy se specifickým použitím
  • lépe škálují než relační DB, dobře replikují
  • špatná podpora transakcí

1) Document-based: MongoDB, CouchDB
struktura podobná JSON
- pro data s fixní nebo stromovou strukturou
- nehodí se pokud je potřeba znát vazba mezi daty
- naopak se hodí pokud jednotlivé záznamy nepotřebují odkazovat na jiný

2) Key-Value: Redis
- pro Cache
- rychlý (klíč - indexy)

3) Wide-Column: Cassandra, DynamoDb
- organizují data podle sloupců namísto řádků
- použití pro případy kde je více zápisu než čtení a nedělají se aktaulizace

4) Grahp: Neo4J, Giraph
- pro grafy (mapy, ontologie)
- rozpoznávání obrazu, medicínské softy (zadají se příznaky a výsledek je např. styl léčba)

76
Q

Souborový systém

A
  • tam kde běží aplikace
  • při více instancí je problém se sdílení dat
  • těžké škálování, přístup, zvětšení GB při runtime
  • omezené indexování, cachování, dotazování
77
Q

Další možnosti uložení dat (kromě SQL, NoSQL, souborů) (4x)

A

1) Alfresco
- souborové úložiště
- metadata k souborům, dotazování, škálování

2) Elastic Search
- storage engine pro vyhledávání dat, analýzy, skvělý pro indexaci logů nebo big dat

3) Amazon S3
- objektové úložiště, dobrý pro data ke kterým se moc často nepřistupuje (backupy)

4) Object databases
- ObjectDB, pro ukládání objektů, dědičnost, metody pro práci s objekty

78
Q

Datový model

A
  • Ovlivňuje výkon (rychlé čtení/zápis)
  • požadavky na konzistenci a prostorové nároky
  • návrh podle toho co budou běžné dotazy

1) Normalizovaný model
- žádné duplicity informace (méně místa na uložení, rychlejší aktualizace)
- čtení více dat vyžaduje JOIN nebo více dotazů (horší výkon)

2) Jedna tabulka navržena write-once, čti a analyzuj později (př. Warehouses)
- předem vypočítává data, duplikace
- pomalé aktualizace, těžké udržet konzistenci
- rychlé čtení

79
Q

Bezpečnost dat - 2 problémy

A

1) může někdo zachytit komunikaci s úložištěm?

2) může někdo obelhat aplikaci aby vykonala nechtěný dotaz/zápis?
- SQL injection - dotaz rozdělí pomocí řetězce na dva
- ochrana - validace parametrů, nastavení přístupových práv, neopouštět složky s daty a neumožnit neprocházet filesystem

80
Q

Výkon při práci s daty

- jak dlouho zabere jeden dotaz?

A
  • nepoznám pokud mám málo dat a uživatelů
  • nastane pokud mám složité dotazy
  • NoSQL DBs rychlejší kvůli jednoduchým dotazům
  • závisí na datovém modelu

Indexy

  • rychlejší vyhledávání
  • kolik? které položky budou indexy?
  • naopak ještě zpomalím zápis

Důležitá optimalizace - změřit a zjistit kde je pomalá část aplikace a pokusit se zrychlit

81
Q

Výkon při práci s daty

- kolik dotazů posílám?

A
  • problém SELECT N+1 - jeden dotaz získá N záznamů a pro N záznamů získám dalších N pro detaily
  • Počet dotazů by měl být konstantní nehledě na to jak velký seznam zobrazujeme (pro 1 objednávku nebo 100)
82
Q

Konzistence dat

A

Při více akcí v úložišti nemusí všechny skončit úspěšně

- pokud nějaká akce selže musím provést rollback změn

83
Q

Transakce + ACID

A

sekvence akcí která proběhne celá nebo vůbec
!!!Každá funkce aplikační logity by měla běžet jako samostatná transakce!!!

Atomicity - atomická operace - celá nebo vůbec
Consistency - změny transakce neporuší integritu
Isolation - Více paralelních transakcí se nemohou ovlivňovat souběžně
Durability - po (úspěšných) transakcích pád systému neovlivní změny způsobené transakcemi

84
Q

Úrovně izolace transakcí (3x)

A

1) Dirty Reads
- T1 transakce může přečíst změny T2 transakce která ještě není commitnutá

2) Nonrepeatable Reads (U druhého dotazu můžeme vidět změny v řádkách)
- T1 čte data
- T2 commitne aktualizaci/odstranění těchto dat
- T1 zopakuje dotaz a získá jiná data

3) Phantoms (oproti nonrepeatable reads mohou při druhém dotazu přibýt i nové řádky)
- T1 čte data
- T2 commitne vložení/aktualizaci která modifikuje atributy pro vyhledávání
- T1 zopakuje dotaz a získá odlišné výsledky

85
Q

Zámky v databázi

A

1) Čtení
více transakcí může číst paralelně stejná data
při zápisu musí transakce počkat až se záznam uvolní od všech čtenářů

2) Zápis
Při zápisu se záznam zamkne pro čtení i zápis ostatním dokud neskončí

86
Q

Úrovně zámků

A

1) Read uncommitted
- ruší izolaci, umožňuje paralelizaci
- jen pokud budou jen paralelně čte

2) Read committed (většinou výchozí nastavení - kompromis)
- čtení jen committed dat
- transakce drží čtecí zámek pokud pracuje se záznamy
- transakce drží zápisový zámek dokud neudělá commit nebo rollback
méně paralelizace

3) Repeatable read
- transakce drží čtecí i zápis. zámky drží dokud nenastane commit nebo rollback
- update není možný dokud ho jiná transakce nepustí zámek

4) Serializable
- transakce zamkne záznamy které spadají do rozsahu dotazu
- nelze upravovat existující záznamy ale ani je přidávat

87
Q

Správa spojení s databází

A
  • Zabraňuje otevření vždy nového spojení do db pro každý požadavek
    snižuje režii pro připojení
  • Vhodné pokud se atributy připojení nemění
  • Connection pool - aplikace při startu otevře několik spojení
  • Při připojení uživatele si vyžádá spojení z connection poolu přes který posílá dotazy
  • Minimální počet: zaručený počet připojení
  • Maximální počet: kolik připojení je max povoleno, pokud je aplikace zatížená
  • Timeout: při nečinnosti je to doba po kterém se uvolní
  • Check query: kontrola zda je je spojení otevřený
88
Q

ORM vs SQL

A

JDBC priklad:

Statement psmt = new PreparedStatement(“SELECT * FROM Users”);

ResultSet set = psmt.execute();
List users = new ArrayList();
while(set.next()) {
    String name = set.get(“name”);
    String email = set.get(“email”);
    User u = new User(name, email);
    users.add(u);
}

ORM priklad:
List users = repository.findAll(User.class);

89
Q

ORM definice

A
  • premosteni mezi objektovym a relacnim svetem
    tridy = tabulky
    atributy = sloupce
    nejsou stejne! (dedicnost, public/private)
90
Q

ORM výhody a nevýhody

A

+ zjednodusseni - vyvojari se nemusi starat o to jak vypada SQL
+ jednoduche na pouziti
- past pokud nerozumime relacnim databazim nebo frameworkum - proste tomu jak to vnitrne funguje

ma to smysl?
pokud je aplikace mala - je pomalu i lepsi si SQL + mapovani psat sam

91
Q

typy ORM

A

1) plne automatizovane - dela uplne vsechno
- jednoduche na pouziti
- slozite na SPRAVNE pouziti

2) manualni ORM
- programator si musi psat SQL
- ORM pomaha s mapovanim objektu

92
Q

Výkonost ORM

A

ORM je obecne pomalejsi

  • asociativni nacitani (napr Post ma Liky) -> pres ORM jeduche, defakto automaticke, ale na pozadi vyzaduje vice SQL dotazu -> jeste vetsi problem je to pri hirearchii trid -> velky pocet pristupu do DB
  • reseni problemu SELECT N+1 = LAZY loading
    = nacti mi jen zakladni atributy a nenacitej asociativni objekty (vzdy kdyz mame relaci *-to-many)
  • nevyhoda: kdyz pote zavolame getter -> vyusti v dodatecne SQL (donacteni)
    v pripade relace *-to-one je lepsi pouzit LEFT JOIN nez vice selectu
  • mame pouze jeden SQL dotaz ale zas muzeme prenaset duplicitni data v pripade ze jeden uzivatel ma vice adres (obecne u *to-many)
93
Q

problemy mezi relacnim a objektovym svetem (4x)

A

1) v relacni DB neexistuje koncept private atributu -> vsechno je public -> kdokoliv se k DB pripoji si muze precist jaky sloupecky chce

2) abychom mohli tridu ulozit do DB pouzijem gettery/settery -> poruseni OOP navrhu
- dalsi moznosti je napr pouzit DTO (data transfer object) -> ulozime jen cast tridy do DB, po nacteni namapujeme DTO na reaalny objekt -> casove pomalejsi

3) dědičnost
- samostatná otázka

4) prijdeme o typ vztahu (pompozice? agregace?)
- v pripade tridy je prochazeni jeho komponent jednodussi nez kdyz musime v DB “skakat” pres vice tabulek

-> vsechny tyto nedostatky = leaky abstraction

94
Q

Problém dědičnosti v ORM + 3x řešení

A

= realcni DB neumi vyjadrit dedicnost

moznosti reseni:

1) kazda trida v dane hirearchii = 1 tabulka
- duplicitni atributy
- pri prochazeni hierarchii musime volat vice dotazu nad danou DB

2) jedna tabulka ktera obsahuje vsechny tridy z dane hirearchie
- hodne “blank” policek
- neefektivni zpusob uchovavani dat
- jednoduchy SQL query

3) jedna tabulka pro rodicovskou tridu
- samostatne tabulky pro potomky
- propojeni pres cizi klice
- nejsou duplicitni sloupce
- pri vyhledavani musime delat join
- efektivni ulozeni

95
Q

proc resit bezpecnost z pohledu webovych stranek?

A
  • muzeme byt pravne stihani
  • vede ke ztrate duvody
  • vede ke ztrate financi
96
Q

zakladni koncepty bezpecnosti (5x)

A

1) sifrovani/hashovani dat
2) omezit pocet zpusobu interakce s danou aplikaci
3) pouzivat dobre otestovane a zname knihovny
=> lepsi nez se neco pokouset psat sam
4) cist bezpecnostni novinky ohledne danych knihoven
5) bezpecnost v podobe nahodne cesty kterou by utocnik musel uhodnout neni bezpecnost!

97
Q

oblasti bezpecnosti (4x)

A

1) prihlaseni uzivatele
2) ochrana citlivych dat
3) bezpecnost kodu (XSS)
4) prenos dat

98
Q

bezpecnosti prihlaseni uzivatele - charakteristik

A
  • muze byt clovek/SW
  • muze byt implementovani napr pomoci Aspektu
  • zajisteni ze uzivatel ma vymezena prava na zaklade jeho role
99
Q

level of assurance = LOA

A

ruzne stupne overeni ze se jedna o daneho uzivatele

1) high-level assurance
- banky napr vyzaduji prihlaseni uzivatele + kdyz chce uzivatel provest transakci -> jeste jednou zadat heslo; pri registraci musime do banky s obcankou, pasem atd.

2) low-level assurance
e-shopy, blogy, …
prihlaseni pomoci Google, GitHub, …

100
Q

zpusoby autentikace

A
  • jmeno & heslo
  • certifikat
  • HW klicenka (telefon, USB)
  • pomoci tokenu (SMS, email)
  • vice-faktorova autentizace = kombinace predchozich
101
Q

mozne problemy pri prihlaseni uzivatele:

A
  • uzivatel se muze prihlasis s nevadidnimi udaji (napr SQL injection = “password = ‘; OR 1 = 1”)
  • uzivatel muze delat nepovolenou operaci nad datty
  • uzivatel vidi neco co by videt nemel (ma pristup na urcitou stranku)
  • ukradeni totoznosti (CSRF)
102
Q

CSRF

A

Cross-Site Request Forgery

utocny kod ktery donuti prohlizet vykonat operaci (poslat pozadavek) na stranku, kde ma uzivatel otevrenou a prihlasenou session

autentizace je sdilena pro jeden proces daneho prohlizece
kdyz se prihlasim na portal a otevru 3 dalsi taby v prohlizeci -> ve vsech budu uz prihlaseny

103
Q

same-origin policy

A

frontent muze poslat pozadavky pouze na tu stranku odkud jsme si stahli JS, CSS, HTML -> jeho puvod

104
Q

cross-origin request

A

server muze dovolovat pristup (posilani pozadavku) i z jinych zdroju

  • vycet toho odkud muze server prijmat pozadavky je definovan v hlavicce HTTP kterou prohlizec nedovoluje nijak zmenit
  • soucasti muze byt i sezman povolenych operaci (metod)
105
Q

zpusoby zabezpecni proti CSRF

A

1) overeni ze source origin odpovida target origin
2) posilani synchronizacniho tokenu (CSRF tokens)
3) Double Submit Cookie
4) nepouzivat ani session ani cookie

106
Q

zpusoby zabezpecni CSRF:

overeni ze source origin odpovida target origin

A
  • jine stranky nemohou na dany server pristupovat
  • overeni pres HTTP hlavicky
  • origin = kombinace protokolu, hostname a portu
    => napr https://mypage.com/index.html neni to same jako https://mypage.com:8080/index.html
  • target - zalezi jestli je cilovy server za nejakoy proxy
  • kdyz neni proxy -> funguje jednoduse, neni s tim problem
  • pokud je proxy
    => vyzaduje nastaveni serveru (aplikace)
    => hlavicka host bude obsahovat URL serveru, ktery tam vlozi proxy, puvodni URL bude v X-Forwarder-Host
  • funguje v pohode pokud mam omezenou domenu, co kdyz ale mame verne API a chceme povolit pristup komukoliv -> potrebujeme jiny zpusob zabezpeceni
  • spolehame se na prohlizec ze same-origin policy implementuje bez chyby
107
Q

zpusoby zabezpecni CSRF:

posilani synchronizacniho tokenu (CSRF tokens)

A
  • nahodne vygenerovany token pro kazdy request/pri prihlaseni uzivatele
  • musi byt dostatecne slozity aby ho nikdo nemohl uhodnout
  • ulozen v session na strane serveru
  • vlozen do HTML stranky ktera se posila uzivateli, HTTP hlavicek
  • kazdy request musi obsahovat dany token
    => viz semestralka reset hesla
  • potencialne nebezpecne v pripade GET, DELETE pozadavku
    => token musi byt soucasti URL -> je viditelny, prohlizec si ho uklada do historie, uklada se do logu, …
108
Q

zpusoby zabezpecni CSRF:

Double Submit Cookie

A
  • nahodne vygenerovani token (dostatecne nahodny) pri prvni requestu
  • ulozen prostrednictvim cookie na strane klienta
  • vlozeny do HTTP hlavicek/HTML s kazdym odeslanym dotazem
  • hodnoty v parametrech a odeslana cookie se musi shodovat (server tyto hodnoty pouze overuje -> nemusi si hodnotu tokenu ukladat do session)
  • jina stranka nemuze prepsat cookie jine stranky
  • musime mit dobre nakonfigurovany cely system
  • v pripade vice aplikaci v jedne domene si cookie muzou menit navzahem (je sdilena) -> podvrzeni jedne stranky muze zpusobit potencialni CSRF utok
109
Q

zpusoby zabezpecni proti CSRF:

nepouzivat ani session ani cookie

A
  • token se vytvori pri prihlaseni uzivatele

- kazdy request obahuje zasifrovany token a server jej rozsifruje a zkontroluje validitu

110
Q

Problém nezabezpečené komunikace

A
  • vetsina aplikace vyzaduje posilani citlivych udaju mezi klientem a serverem (heslo, token, …)
  • pokud mame nezabezpecnenou komunikaci, kokoliv na ceste od klienta k serveru si ji muze odposlechnout
  • > komunikace musi byt zasifrovana
111
Q

Man in the middle attack

A

1) Alice sends a message to Bob, which is intercepted by Mallory:
Alice “Hi Bob, it’s Alice. Give me your key.” → Mallory Bob

2) Mallory relays this message to Bob; Bob cannot tell it is not really from Alice:
Alice Mallory “Hi Bob, it’s Alice. Give me your key.” → Bob

3) Bob responds with his encryption key:
Alice Mallory ← [Bob’s key] Bob

4) Mallory replaces Bob’s key with her own, and relays this to Alice, claiming that it is Bob’s key:
Alice ← [Mallory’s key] Mallory Bob

5) Alice encrypts a message with what she believes to be Bob’s key, thinking that only Bob can read it:
Alice “Meet me at the bus stop!” [encrypted with Mallory’s key] → Mallory Bob

6) However, because it was actually encrypted with Mallory’s key, Mallory can decrypt it, read it, modify it (if desired), re-encrypt with Bob’s key, and forward it to Bob:
Alice Mallory “Meet me at the van down by the river!” [encrypted with Bob’s key] → Bob

7) Bob thinks that this message is a secure communication from Alice

112
Q

sifrovani komunikace pomoci SSL/TLS

A
  • asymetricka sifra se pouziva pro vymenu symtreckeho klice
  • po vymene spolecneho klice chceme pouzivat symetricke sifrovani -> rychlejsi
  • protokoly vyssich vrstev zustavaji nezmenene
  • kazdy server muze pouzivat SSL/TLS -> to ale nenzamene ze je bezpecny -> potrebujeme overit jeho certifikat
  • CA (certifikacni autorita) je zodpovedna za vydavani certifikatu
    => musi zjistit ze skutecne jsme to my vlastni ten server -> rekne neco jako “vystav mi tenhle soubor na tuhle adresu” -> tim dokazeme ze mame kontrolu nad danym serverem
  • sluzby si mohou vytvorit vlastni certifikat pro interni testovani v ramci vyvoje
  • knihovny kolikrat odmitaji pripojeni kdyz neni verohodny certifikat -> da se to vypnout -> ale je to silne nedoporucovany
113
Q

problém nevalidace uzivatelskeho vstupu

A

kazdy zpusob interakce s nasi aplikaci je potencialni bezpecnostni riziko
1) injection utoku (napr SQL)
- vetsina frameworku poskytuje funkce na validaci vstupu od uzvatele pred tim nez jsou poslany do SQL dotazy
2) Cross-Site Scripting (XSS)
- Client-side script injection attack
- neosetreni vstupu od uzivatele
- viz posty v semestralce -> po vlozeni kusu kodu ho prohlicec vykonna - utocnik muze tak nasi aplikaci donutit komunikovat se serverm jinak nez chceme
ochrany proti CSRF utokum nebudou funguovat protoze jsme donutili tu samotnou aplikaci vykonavat utocny kod

114
Q

Webová služba - motivace

A

Jak propojit různé aplikace?
Napsanou různými programovacími jazyky
Nasazenými na různé platformy
Vytvořena různými lidmi

115
Q

Webová služba - charakteristika

A
  • SW navržený pro komunikaci mezi stroji po síti
  • Je to rozhraní popsané ve strojově zpracovatelném formátem
  • Systém komunikuje s web. službou
  • Black box pro klienty
  • Bezstavová - lehčí design a škálovatelnost
116
Q

Možnosti připojení aplikace na web:

A

1) Standardizované otevřené protokoly (HTTP, SOAP)
2) Standardizované otevřené datové formáty (JSON, XML)

Výhody:
Nestarám se o to v jak a v jaké technologii jsou ostatní applikace napsané

117
Q

Agent ve webových službách

A
  • konkrétní implementace pro posílání a příjímání zpráv
  • stejná web. služba může být realizována více agenty (v různých prog. jazycích)
  • realizace web. služby/klienta
118
Q

Užití webových služeb

A
  • znovupoužití komponent (autentizace, počasí)
  • propojení s jiným SW
    => nezávislý na programovacím jazyce (web. standardy)
    => nezávislý na platformě (Raspberry PI, Win, Linux)

Implementace WS API v MVC

  • Controller definuje endpoint a zpracovává požadavky
  • View je format který posílá data např. soubor JSON
119
Q

SOAP - charakteristika

A
  • komunikační protokol
  • definuje formát kterým posílá data - XML-based
  • definuje kodování pro datové typy
120
Q

SOAP - složení

A
  • Envelope (Obálka) obaluje SOAP zprávu
  • Header (hlavička) poskytují další funkce pro zprávu
    => zabezpečení (podpisový certifikát)
    => metadata (jazyk zprávy)
  • Body (tělo) zprávy
  • Fault chybové hlášky pokud nastala chyba
121
Q

SOAP - výhody

A

1) flexibilní
2) rozšiřitelný
3) XML - definuje jak má vypadat takže definuje fixni strukturu, namespace, XSD

122
Q

SOAP - nevýhody

A

1) nestandardizovaný API design (pro každá služba může mít jiné API - jmenné konvence)
2) XML
=> velikost zprávy a složitost roste rychleji s počtem dat
=> nepřehledný pro mnoho dat a mnoho zanoření
=> Výkonostní issue - parsování

123
Q

WDSL - charakteristika

A

webservice description language

  • xml schéma popisující web. služby
  • Neomezuje se na SOAP ale běžně se s ním používá
  • umožňuje generování kódu
124
Q

WDSL - elementy

A

1)
=> (xml schéma) definuje datové typy používané web. službou

2)
=> obálka okolo dat. typů, definuje datové operaci

3)
=> možné operace, zprávy zahrnuté jako vstup, výstup a při chybě

4)
=> vazba na protokol (SOAP)

125
Q

REST - charakteristika

A

Representional State Transfer

  • architektonický vzor pro návrh web. služeb
  • nejedná se o protokol
  • sada pokynů pro návrh API rozhraní
  • cíl: vytvořit API s jednoduchým použitím
    zdrojově-orientovaný
    => endpoint pro Like: /posts, /users, /categories
  • použití HTTP metod (GET, PUT, DELETE, …)
  • Bezstavový
  • Podobný adresářové struktuře
126
Q

REST - nevýhody

A

není to silver bullet…

  • potřeba znát user-casy před návrhem API
  • Potencionálně nadměrné/nedostatečné načítání (fetching)
127
Q

PUT vs POST

A

POST

  • známe přesné umístění resource: POST /posts/ HTTP/1.1 (generování id pro zdroj)
  • při opakovaném volání POST server negarantuje že proběhne vždy stejně pro stejný požadavek
  • PUT pokud nevíme kde přesně se nachází resource: PUT /posts/12 HTTP/1.1
  • garance že probehně více požadavků stejným způsobem
  • je indempotentní operace
128
Q

HATEOAS

A

Hypertext As The Engine Of Application State

  • možnost užití hypertext napříč API
  • Dobré API definuje entry-pointy a množinu zdrojů (entit)
  • Init volání entry-pointu vrátí seznam odkazů na zdroje (klienti nemusí znát strukturu předem)
129
Q

GraphQL

A

API query language (i runtime)

= pokus vyřešit problémy RESTful API

  • Silný typový systém
  • over/under fetching
130
Q

GraphQL - výhody a nevýhody

A

+ netřeba znát všechny use-case při návrhu
+ není over/under fetching

  • špatné škálování
  • formát jen JSON
  • složité ukládání do cache - každé API se chová jinak
  • těsná vazba mezi klientem a serverem
131
Q

GraphQL vs REST

A

GrapgQL je obvykle lepší než REST

GraphQL:
- rychlý vývoj aplikací bez server-driven state

REST

  • distribuovaný systém
  • Se silnou potřebou řídit stav na serveru
  • Vysoké požadavky na škálovatelnost a výkon
132
Q

Webové sockety - motivace

A
  • je potřeba často si posílat zprávy s klientem nebo je nutné notifikovat klienta o nové události
  • server jinak posíla zprávu klientovi jen pokud od něj dostane požadavek
  • klient se jinak musí periodicky ptát na nové info - při více uživatelů se může zahltit server
133
Q

Polling

A
  • klient často posílá požadavek na data a server hned odpoví zda má nebo ne
134
Q

Long-Polling

A
  • odpoví pokud bude mít co poslat klientovi nebo vyprší timeout a pošle že nic nemá co by poslal
  • neýhoda že spojení drží než odpoví klientovi
135
Q

Webové sockety - charakteristika

A
  • zprávy se posílají v rámcích (obálkách)
  • oboustranný komunikační protokol (založený na TCP)
  • navázání spojení pomocí HTTP protokolu (ws:// nebo wss:// (secure))
  • používá stejný port jako HTTP 80 a 443
136
Q

DevOps - význam zkratky

A

Deployments, operations

= vývoj a provoz v těsném kontaktu

137
Q

DevOps - ovlivňuje: (3x)

A

1) bezpečnost
2) výkon
3) downtime během aktualizace

138
Q

DevOps - protředí (4x + 1)

A

1) Development
2) Testing
3) Před-produkční
4) Produkční

+ speciální testovací prostředí

139
Q

Development prostředí

A
  • používají developeři k testování na svém počítači
  • požadavek na výkon: nízký
  • požadavek na stabilitu: nízký (vývojáři si mohou kdykoliv aktualizovat)
  • požadavek na bezpečnost: nízký (nereálná data)
140
Q

Testing prostředí

A
  • používají testeři, vlastníci produktu k validaci a verifikaci implementace
  • požadavek na výkon: nízký-střední (potřeba odpověď v přiměřeném čase, málo uživatelů)
  • požadavek na stabilitu: střední (potřeba čas na testování)
  • požadavek na bezpečnost: střední (nereálná data, natavení podobné produkčnímu)
141
Q

Před-produkční prostředí

A
  • používají testeři, operátoři k testovacímu nasazení v prostředí podobném produkčnímu, testování výkonu a bezpočnosti
  • požadavek na výkon: vysoké (prostředí co nejvíce podobné produkčnímu)
  • požadavek na stabilitu: střední-vysoké (downtime issue je považován za hrozbu, nasazení podle nějakého plánu)
  • požadavek na bezpečnost: vysoké (nereálná data, požadavky jako by bylo produkční prostředí)
142
Q

Produkční prostředí

A
  • nasadím novou instanci s novou verzí a začnu přesměrovávat uživatele x nějaký čas odstavení třeba brzo ráno, půlnoc
  • používají zákazníci
  • požadavek na výkon: vysoké (problém způsobí naštvaného zákazníka)
  • požadavek na stabilitu: vysoké (nasazení v předem definovaném čase)
  • požadavek na bezpečnost: vysoké (reálná data, zranitelnosti v zabezpečení je vážný problém)
143
Q

Speciální testovací prostředí

A
  • testování výkonu
  • údržba produkčního nastavení je nákladná - zde se může otestovat
  • testování pro velké funkce
  • dlouho vyvíjené featury
144
Q

Přístup k nasazení (5x)

A

1) Naivní vývoj
2) Nasazení skritpy
3) Automatický
4) CI (continous integration)
5) CD (continous delivery)

145
Q

Naivní nasazení (1 z 5 přístupu k vývoji)

A
  • všechno manuálně - sestavení, vývoj, configurace, nasazení
  • není potřeba extra infrastruktura
  • sklon k lidských chybám
  • pomalý
146
Q

Nasazení skripty

A
  • pokus co nejvíce automatizovat pomocí skriptů

Postup:

  • nasazení na server
  • použití konfigurace
  • restart služby
  • testování
  • potřeba spuštění těchto skriptů na serveru
147
Q

Automatické nasazení

A
  • Všechno plně automatizované od sestavení po testování
  • navržený sestavovací server
  • minimum lidské činnosti např. jedním tlačítkem
  • celý nasazení vždy projde stejným procesem
148
Q

CI

A

Continous Integration

  • praktika co nejrychlejší integrace nových změn do kódové základny (master)
  • potřeba vysoce kvalitního testovacího procesu pro zajištění stability kódu
  • build server - nakonfigurován tak aby mergoval nové commity co nejrychleji do masteru
  • chyby nalezeny velmi rychle
  • vývojáři mohou dál pracovat než to server dokončí a otestuje
149
Q

CD

A

Continous Delivery

-praktika zaměřená na nasazení změn v malých cyklech
změny by měli být menší
- flexibilní přístup pro poskytování nových funkcí, opravu kritických chyb
- celý tým potřebuje znát jak dopadl build, testy, reporty = snazší na reakce
- kvůli automatizaci je možné nasadit kteroukoliv verzi na jakékoliv prostředí kdykoliv

150
Q

Sestavovací servery

A 
1) Jenkins
open-source, široce používaný, mnoho pluginů
2) Gitlab Pipeline
pro projekty na gitlabu
3) TeamCity
4) Travis CI
CI server pro github projekty
151
Q

DevOps - charakteristika

A
  • přístup zužující propast mezi vývojem a provozem
  • vývojáři a správci systému musí spolupracovat
  • týmy sestaveny tak aby každý mohl:
    1) dodávat funkčnost
    2) testovat
    3) nasazovat
    4) udržovat
  • prakticky
    1) automatizace
    2) kontejnery
    3) bezpečnostní konfigurace
    4) monitorování + škálování
    5) zálohování + bezpečnost
152
Q

DevOps - automazice

A

Je kritická:

  • omezení manuální práce
  • méně chyb (někdo zapomene něco nakonfigurovat, přepíše se)
  • rychlé doručení

= Sestavení a nasazení je automatické
= Automatizace infrastuktury
- DevOps používá stejné principy pro instrastrukturu jako pro vývoj
- popis infrastruktury v konfiguračním souboru
=> verzuje se

153
Q

Virtualizace (DevOps)

A
  • Cloud dovoluje dobře škálovat

- virtualizační nástroje jednoduše vytvoří identickou instanci serveru (AWS, OpenStack, vagrant)

154
Q

Kontejnery (DevOps)

A

(Docker, Kubernetes)

  • jiná úroveň virtualizace
  • dovoluje dodat aplikaci společně s runtime prostředí
  • Build once, run anywhere
155
Q

Monitoring (DevOps)

A

= Sběr infa

  • dashboard a vidíme data na jednom místě
  • Kolik RAM používám, místa na disku, odpovídá a jak rychle
  • při problému dostat notifikaci (SMS, email, chat)

External:

  • nemusí být na serveru
  • monitoring odpovědí na požadavky
  • response time
  • validace HTTPS cetifikátů

In-place:

  • musí být nainstalován na server
  • monitoruje CPU, volné místo na disku, operační paměť RAM
156
Q

Zálohy (DevOps)

A

= data jsou nejcennější věc

  • V případě chyby lze obnovit data bez příliš velkých ztrát (např.):
    => útok
    => neúspěšný upgrade s nefunkční migrací dat
    => SW/HW chyba
    => chyba uživatele
  • Záloha nesmí trvat dlouho a nesmí sebrat moc prostředků (runtimu)
  • uložena na odděleném místě
  • Full x Incremental
  • Kontrola záloh zda existují a jsou funkční Load-Balancer, který řeší:
    1) výkon
    2) stabilita
157
Q

Prototyp (UX)

A
  • návrh ve skutečném rozměru (grid)
  • používat odstíny sedi pro zobrazení priorit
  • nepoužívat černé pozadí
  • jasné nadpisy
  • reálná data, obrázky
  • popisné placeholdery
  • srozumitelné popisky
  • propojení prototypu s poznámkami
158
Q

Kontejnery

A
  • abstrakce aplikace z produkcniho prostredi
  • dovoluje vyvojarum si vytvorit testovaci prostredi, ktere odpovida realnemu nasazeni
    => v cloudu
    => na notebooku
    => na vlastnich serverech
    => relativne jednoduche na pouziti temer na jakekoliv plaforme (ale Linux je lepsi)
  • pripominaji hodne virtualni stroje ale jsou jinak implementovany
159
Q

Rozdíl kontejnery - virtual machines

A
  • VM maji vetsi rezii nez konterjnery
  • kontejnery rychleji startuji
  • kontejnery virtualizuji SW ne HW
160
Q

Image X Kontejner

A
  • image = binarni obraz behoveho prostredi
  • kontejner = instance obrazu
  • images jsou ulozeny v repozitari (lokalni, verjny) napr https://hub.docker.com/
161
Q

LXC

A

implementace kontejneru - starsi nez Docker

  • vyuziva funkce Linuxoveho jadra
  • API pro vytareni Linuxovych kontejneru
  • kontejnery = plne bezici OS
  • stejny vysledek jako VM ale implementovano pomoci kontejneru
  • ma flexibilitu jako VM
  • ma rychlost startovani jako kontejner (min narocne na zdroje)
162
Q

LXD

A
  • image manager zalozen na LXC
  • poskytuje image ve vzdalenem repozitari
  • jednoduche, bezpecne
163
Q

Docker

A
  • novější než LXC
  • jiny pristup: jedna aplikace = jeden kontejner
  • docker neobsahuje kompeltni OS
  • poskytuje izolovane prostredi
  • vytvareni docker image
  • textova specifikace = Dockerfile
  • s kazdym prikazem se prida nova vrstva (kopie FS) -> navysuje se celkova velikost image
    => povazovano za hlavni nevyhodu Dockeru
  • vsechny jsou read only
  • po sestaveni ma image pouze jednu RW vrstvu (ta posledni) -> muze slouzit k vytvoreni dalsiho image
164
Q

Docker úložiště

A

FS v Dockeru se nema povazovat za permanentni
- v pripade updatu kompletne zrusime dany kontejner a spustime jiny -> jak uchovat data permanentne?

moznosti ulozist
1) Bind mounts
= namountovani slozky hostitelskeho OS do slozky v Docker kontejner

2) Volumes
- jsou vytvoreny ve FS hostitelskeho OS a namountovany do kontejneru
- rozdil oproti bind mounts: volumes jsou vytvoreny Dockerem v miste ktere spravuje Docker (typicky napr /var/lib/docker)
- volumes muzou byt vytvoreny nezavisle na kontejnerech
- mohou byt sdilene mezi vice kontejnery

165
Q

Docker - síťování

A

Docker poskytuje vice moznosti toho jak resit sitovani

  • vytvareni vnitrnich siti
  • pripojovani kontejneru k internetu

Bridge networks
- vytvoreny v ramci dockerovskyho demona
- izolace kontejneru je realizovana na IP vrstve
- kontejnery ve stejne siti spolu mohou komunikovat
- defaultni bridge je vytvoren pri spusteni Dockeru
= jsou tam prirazeny vsechny kontejnery, pokud to neni specifiky jinak definovano
- ve vychozim stavu vsechny kontejnery vystavuji vsechny jejich porty (ale jen mezi sebou, ne do vnejsi site - host)
- abychom k nim mohli prisoupit musime explicitne specifikovat jake porty chceme nabindovat - 80:8080

166
Q

Dockerizace aplikace

A
  • aplikace se musi nakonfigurovat pres environment variables
  • sila Dockeru se projevi pri nasazovani (testovani) aplikaci ktere vyuzivaji vice sluzeb
  • moznosti konfiguraci:
    1) Docker Compose
    2) Kubernetes, Docker Swarm
    3) AWS, Google Cloud, Azure…
167
Q

Docker Compose

A
  • obsahuje konfigurace jednotlivych kontejneru
    => vystaveni portu
    => image
    => sit
    => volumes
    => poradi v jakem skuzby spoustet
  • velice jednoduche
  • nehodi se na nasazeni dal nez jen ve vyvoji
    => neresi load balancing
    => neresi automaticke nastartovani aplikaci kdyz spadnou
168
Q

Docker Swarm

A
  • nasazovani kontejneru v klastru
  • jeden klaster se navenek tvari jako jeden spusteny proces
  • propojeni vice Docker uzlu do jednoho klastru
    => manipulace pres jedno API
  • uzivatel porad vyuziva Docker-compose konfiguraci
  • Swarn se pote postara o nasazeni jednotlivych kontejneru
  • Swarm obsahuje interni DNS server
  • kazda sluzba obsahuje zaznam v DNS
  • Swarm resi load balancing
169
Q

Kubernetes

A
  • zalozeny na internich projektech Google
  • poskytuje lepsi funkcionalitu nez Docker Swarm
    => automaticke skalovani
    => “health-check” on containers
170
Q

Kubernetes vs Docker Swarm

A

nevyhody Kubernetes:
=> “do-it-yourself” (je slozity)
=> potreba dalsiho nastroje

vyhody Docker Swarm
=> jednodussi, stejne API jako Docker

Kubernetes je pouzivany a podporovany hlavnimi cloudovymi providery

171
Q

Kde hostovat Docker klastry? (3x)

A

1) vlastni VM/servery
=> tezsi a slozitejsi
=> pokud to myslime vazne s daty a dostupnosti

2) Openshift (RedHat)
=> cela platforma postavena na Kubernetes
=> velmi dobra vizualizace

3) Google Cloud, AWS, Azure
=> bud si muzeme spusit vlastni Docker image
=> nebo poskytuji Kubernetes cluster

nevyhody vsech techto reseni je jejich cena

FAV (46 decks)

Brainscape helps you reach your goals faster, through stronger study habits.
© 2024 Bold Learning Solutions. Terms and Conditions