Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Mirek Zvolský

Stran: [1] 2
1
Server / Re:Jak začít se současnou webařinou?
« kdy: 30. 01. 2021, 10:59:12 »
3)
O frontendu moc nevím. Design? Styluje se pomocí css a když místo .css budeš požívat .sass, přidáš si tam např. proměnné (umožní něco zadat napříč softem, třeba barvu, co pak můžeš jednoduše změnit, dávat o 20% tmavší apod. - nemáš to zadané natvrdo), teoreticky lepší deskriptory stylovaných prvků - v reálu to chce extrémní kázeň, abys nevytvořil nepochopitelné a neudržovatelné monstrum. Platí to i kdybys do toho šel jako jednotlivec, i když by to dělal tým.

Potřebuješ responzivní chování (pro mobily). To Ti dá spoustu práce. Styloval bych (sass/css) co nejmíň a určitě do toho vložil Bootstrap, který Ti rychle (pár třídami v HTML) zajistí slušné responzivní chování.

Javascript je neskutečná prasárna. Mluvím o jeho historickém dědictví. Od těch nových specifikací (ECMAScript 201x) už je to slušné (jednak okolo tříd a okolo používání this, jednak okolo modularity). Proto se začal používat Babel, aby se mohlo psát už v tom slušném a jednotném a Babel to přeložil pro starší prohlížeče, které nové vlastnosti ještě neuměly. Dnes už je podpora lepší, asi by se vyplatilo jít už bez Babelu a psát co nejstriktněji pomocí nové syntaxe - jenže do toho se těžko dostaneš, protože každý spíš máme nějaké základy toho historického balastu.
No a nějaký ten moderní framework (Vue, React) by to chtělo. Renderování až v prohlížeči, zrcadlení mezi nějakým datovým úložištěm a mezi html prvky stránky.

----------
Řekl bych, že pro jednoho člověka to dnes není - pokrýt to všechno. Můžeš to zkusit. Ale bude to trvat než to dáš (3 roky? 5 let?).
Lépe třeba jen Django a frontend buď odbýt jen nejjednodušším bootstrapem, jestli na něm zas moc nezáleží, nebo s někým spolupracovat.
Taky na to produkční nasazení by se hodil extra člověk, ale ty návody jsou a do týdne nebo 14 dnů to někde na virtuálním serveru (Forpsi?) rozchodíš. Nebo do cloudu, kde nebudeš řešit nginx+gunicorn+systemd, ale zas má každá služba svá specifika. Můžeš zkusit třeba pythonanywhere.com, přečti si to na Django girls.
Cloud Tě může dost omezovat (speciální knihovny), na virtuálním serveru zprovozníš cokoli. Do cloudu můžeš šoupnout jen média (typicky obrázky uploadnuté uživatelem), viz django-storages.

.. hodně štěstí :)

2
Server / Re:Jak začít se současnou webařinou?
« kdy: 30. 01. 2021, 10:33:58 »
2)
U (skoro) každého frameworku (já dělám se Djangem) máš vývojový server. Ten není vůbec vhodný pro finální nasazení (produkci), ale je fajn pro vývoj tedy na URL localhost (např. v Djangu se Ti automaticky refreshuje s každou změnou zdrojáku).
Proč ne pro produkci? Není vůbec myšleno na věci jako je bezpečnost a práce pod zátěží. Django jako takové dokáže vzít jeden požadavek, zpracovat, vrátit, a pak další.
Na produkci před Djangem potřebuješ něco, co bude požadavky rozhazovat do vláken, která poběží paralelně. To je gunicorn nebo uwsgi (asi skoro rovnocenné, možná jednodušší a dnes běžnější je gunicorn). Ale ani gunicorn není specializován na zátěž a další starosti webového serveru. Kvůli tomu se předřadí ještě nginx. Až budeš mít aplikaci trochu hotovou a půjdeš s ní na produkci, najdeš si návod nginx+gunicorn+django a podle toho to zprovozníš. Jedna služba pod systemd je nginx, druhá služba je gunicorn. Ještě se používal hlídač-restartér supervisor, ale to ti dnes bude dělat sám systemd.
Nginx přebírá část toho URL dispatche. Má nějaké sites-available (a -enabled), které to roztřídí podle domén (když jich obsluhuješ víc). Uvnitř každé sites-available můžeš dál třídit na to, co pustíš Djangu a na to, co vrátí hned Nginx (třeba statické soubory). Nebo když potřebuješ třeba streamovat, může to Nginx pouštět jinam (třeba k Falconu).
U těch statických souborů (obrázky, javascript) je otázka cachování: Je fajn je cachovat na klientu, aby je prohlížeč netahal stále znova (to mu dovolí hlavička HTTP). Ale je potřeba mít možnost na klientu vynutit změnu, když vývojář soubor změní. U nginxu to cca můžeš zajistit tím, že nedovolíš cache moc dlouho.
Nebo máš druhou možnost, přepouštět i požadavky na statické soubory Djangu. Přidáš tam knihovnu Whitenoise a ta to řeší přejmenováním těch statických souborů na unikátní jména po každé jejich změně (na disku i v HTML). Trochu pomalejší, ale získáš výhodu, že s tím můžeš jít i do cloudu, kde nemáš kontrolu nad tím, jestli je tam nějaký nginx.

K volbě frameworku: Jestli to myslíš vážně, vol fullstack framework (v Pythonu: Django). S mikroframeworky (Flask) se nezdržuj. Django není velká výhra, je přesložitělé, některá vývojářská rozhodnutí jsou dost rigidní. Ale 70% těch složitostí si webová aplikace opravdu vyžaduje, 30% bude overhead na tu rigiditu. Naivně jsem si myslel, že Django řeší skoro všechno, ve skutečnosti počítej, že i tak budeš ke každé aplikaci muset přidat 5-30 thirdparty knihoven. Výhoda je, že knihovny jsou, musí se samozřejmě pozorně vybírat, aby to byl mainstream s pár vývojáři, co jsou za danou knihovnou, delší historií a častými aktualizacemi. Když půjdeš do mikroframeworku, budeš tam k těm 5-30 mít ještě X dalších, aby ses dotáhl na level Djanga. Navíc si tenhle stack vybereš sám a musel bys být ultra profík, abys vybral lépe, než za Tebe vybírá tým Djanga. V reálu spíš vytvoříš bezpečnostní díry atp.

Např. s Djangem nebudeš psát SQL (použiješ jeho (slušné) ORM). Nebudeš řešit migrace mezi verzemi databáze apod, máš vestavěnou autentifikaci/autorizaci, máš admin pro údržbu číselníkových dat apod.

3
Server / Re:Jak začít se současnou webařinou?
« kdy: 30. 01. 2021, 10:01:23 »
Chtěl bych se naučit alepoň základy technologií vytvářeni dynamických webů ale dost plavu v technikach a pojmech.

Tak to chce opravdu trpělivost, zkusím..
1)
Backend je jasný - server v jednom místě. Frontend být vždy nemusí. Na server může jako klient chtít příkaz, robot, aplikace pro pár dat.. Pokud tam chce prohlížeč tak máš frontend, protože odpověď se v něm má zobrazit a nějak vypadat.
Takže klient sestaví požadavek (request), nejčastěji metodou GET (vše v URL adrese) nebo POST (kromě URL jsou navíc přilepena data). Zabalí ho do HTTP (přidá pár povinných a nepovinných věcí do hlavičky).
To doputuje na server. Server si to podle URL roztřídí, jak to bude řešit (URL dispatch). Zavolá nějakou funkci (controller, v Djangu se tomu prasácky říká view), aby mu sestavila odpověď (response). Než controller sestaví odpověď, tak řeší, jestli přišla data (což je typicky v tom POST požadavku). Zvaliduje je, pokud jsou špatná, připraví jeden typ odpovědi (typicky na stejné adrese, aby se uživatel mohl snažit do blba to zadat lépe). Pokud jsou dobrá, zapíše je do databáze a obvykle v tenhle moment víc do odpovědi nedává, ale jako odpověď pošle Redirect (tedy pokyn, že prohlížeč by měl teď jít na jinou adresu).
Pokud se příchozí data neřeší (nebo už jsme je vyřešili), většinou se dále chce získat data z databáze. A to je buď celá odpověď (ve formátu JSON) nebo má být odpovědí celá stránka (HTML). Ve druhém případě se při neprasáckém přístupu rozdělí část získání dat (controller) a jejich prezentace, tj. to sestavení HTML, tj. renderování šablony (templaty). Výsledná odpověď neobsahuje přímo obrázky nebo javascriptový kód - je tam jenom pomocí src= v tagu <script> nebo <img> popsáno, na které URL se tyto statické soubory najdou. V moderním webu může být místo HTML předána nevyrenderovaná HTML šablona a renderování provede frontend (Vue nebo React) za pomoci dat. která si vyžádá ajaxem.
Ajax je požadavek, který nepřekresluje stránku. Jinak je to ale zase totéž: přijde request, vrátí se response. Response jsou typicky json data (ale mohl by to být třeba fragment html, která si javascript vloží do stránky). Pokud json data, tak se serializují na string, protože jen string můžeme přenést na klienta.
Ve všech výše uvedených případech je tedy response string a ten se obalí HTTP hlavičkou a tahle kompletní response se vrátí.

4
A kdybys potreboval jeste 3.6, tak to udelas jak ? :)
pyenv. Omlouvám se za opakování.

5
Vývoj / Re:Abstrakce u OOP
« kdy: 14. 06. 2020, 08:17:50 »
a ze pak lze vytvaret hierarchii potomku a usetrit si tak psani kodu.
Code reuse dědičností se považuje za antipattern.
Inheritance, if you look at it with a very jaded eye, inheritance is the declaration of methods and variables in a subscope and it has nothing to do with ISA whatever. :)
Je to o úhlu pohledu. Tohle má moje větší sympatie.

6
Místo "make install" dělal a instaloval "checkinstall" debianí balík. Ale obávám se, že ten projekt nějak přiumřel. Nevím, jestli je něco takového.
Na přehazování verzí pythonu je pyenv.
(vím, že neodpovídám na Tvou otázku, promiň, neb nevím - a marně čtu to vlákno, jestli to někdo zodpoví)

7
Software / Re:Webový rozcestník
« kdy: 01. 06. 2020, 23:17:30 »
Proč vlastně "team"? Každý má přeci hesla svoje. A to přihlašování se snad dá automatizovat trochu i třeba v keepassx, i když já jsem taková trubka, že to věčně copy-pastuju. No, furt lepší než papírky.

8
@PetrK: V čem je psané Eclipse? To byla trochu hrůza, když jsem před 5 lety šel na PyCharm. Od té doby trochu nakynul a je už žravější na zdroje. A nepomáhá v JavaScriptu (i když uznávám, že bych mohl mít placenou verzi).
Tak jsem právě přešel na VS Code. Takže já jsem bez naděje. Vlastně taky s nadějí, z PgAdmina jsem šel na DBeaver, a to mi přijde hodně dobrý soft (na to, že je v Javě).

9
PS: pro ten system-wide python jsem místo /usr/local/bin/ měl napsat /usr/local/python-3.N.N/bin/

10
apt Ti teda nejspíš neumožňuje to bezpečně nainstalovat. To je asi chyba balíčkování v Ubuntu. Pokud míchá instalace, neměl by dovolit instalovat jedno, aniž odinstaluješ druhé. Používám Debian, ale nezkoušel jsem.
pyenv je primárně určen pro per-user instalace. Pro zkoušení, pro vývoj různých projektů pod různou verzí a pro testy pod mnoha verzemi pomocí tox.
pyenv by měl jít použít i pro system-wide instalaci, kde potřebujeme dostat python jinam než do /usr/bin/, třeba do /usr/local/bin/. Návod s pyenv je např. zde: https://stackoverflow.com/questions/41422826/install-python-of-specific-version-system-wide-with-pyenv

Než se pak pořád ručně přepínat, nainstaluj si virtualenvwrapper, pro projekty si vytvoř (příkazem mkvirtualenv -p...) prostředí s požadovanou verzí pythonu a přepínej se příkazem: workon <projekt>.

V projektu udržuj závislosti striktně v requirements(.txt apod.), ideálně pomocí pip-tools, což Ti usnadní i fix verzí, i hromadný upgrade závislostí.

Upgrade verze pythonu bych v konkrétním virtualenv nedělal. Vytvoř si nové samostatné prostředí pomocí mkvirtualenv, a ten příkaz (s -r <nefixnutezavislosti>) Ti nainstaluje i všechny závislosti. Ty si pak pomocí pip-tools (příkaz pip-compile) znovu fixneš pro novou verzi pythonu.

11
Odpověď je: pyenv

12
>> tomnatom
tady máš knížky o Javě, jestli jsi je ještě nečetl.
https://link.springer.com/book/10.1007/978-3-319-99420-8
https://link.springer.com/book/10.1007/978-3-319-89491-1
Nebo jdi na Python+js:
https://link.springer.com/book/10.1007/978-3-030-20290-3
https://link.springer.com/book/10.1007/978-3-658-21077-9
Jinak Tě lituju, tohle je peklo, programátor má dneska v podstatě jedinou šanci - přizpůsobovat se kontinuálně - což nelze, pokud jeho technologie skončí (týká se hlavně komerčních, kde to může být politické rozhodnutí). Jinak chtít být juniorem ve 40+ letech je peklo. Správný junior přece musí být ovladatelný a mladý (vždyť nám jistě ve firmě vydrží 40 let!).
Doporučuji Ti trochu víc asertivity, o jedné věci prostě tvrď, že ji umíš perfektně a že jsi v tom hodně dobrý (ideálně něco tak na okraji zájmu té firmy, aby je to zajímalo, ale nebyli schopní to moc prověřit) --no, na toto každý není, já vím. Ale určitě nepolevuj, pořád vybírej firmy a choď na výběrka. Jednou se chytneš, a čím dřív, tím líp. Protože sám se (aspoň v této fázi) nejspíš dotáhneš jen na level, kde budeš odborně vlát o 3 roky opožděný a budou Ti úplně chybět zkušenosti z týmové práce - neboli budeš trvale nepoužitelný. A být úspěšný v sólo projektech, když jsi současně jen ten junior, tak to je trochu sci-fi (a možná ani nemáš takové ambice).
Jo a až tu první firmu seženeš, tak se jí drž, když bude fakt na úrovni doby, ale protože skoro jistě nebude, tak tam nezkejsni víc než 2 roky.

13
Vývoj / Lehká modernizace JavaScriptu
« kdy: 17. 04. 2020, 10:02:07 »
Ahoj.
Chci začít nějaký nový vlastní hobby projekt, backend v klasice, frontend javascript - jen minimalisticky.
TypeScript - zásadně ne (nespamujte prosím na toto téma).
React, Vue - něco bych chtěl do budoucna, snad Vue, ale teď nedokážu najít čas se to naučit.
Takže asi jen jQuery a otázka k modernizaci je:
1) spouštět lokální nebo CDN/cloudovou verzi js knihoven?
2) je vhodné jít přes Babel a pracovat v nějaké moderní verzi js/ecmascriptu? Ve které? - což mi možná vyřeší i některou z následujících otázek?
3) jak nejlíp pracovat se šíleným javascriptovským this? Tady asi odpověď znám, jestli mě nenasměrujete ještě líp: (function() {..}).bind(this)
4) jak je dnes moderní a perspektivní js do html připojit? Jednotlivé js? Nebo bundlovat do velkého souboru a čím? Jak pracovat s externími jmény proměnných místo prastaré prasárny (jména z dříve spuštěných skriptů přístupná jako window.xxx). Používá se import? Nebo require?
Díky za tipy.

14
Vývoj / Re:Správné procesy při vývoji vlastního projektu
« kdy: 10. 03. 2020, 14:26:33 »
1. verzování kódu, 2. deployment, 3. verzování databáze, 4....

3 Tě asi ani tolik netrápí, protože po těch letech asi měníš strukturu tabulek minimálně. Můžeš něco jako číslované sql s ALTER TABLE (i když lepší je, když jsou změnové příkazy generované z nějakého popisu výsledné struktury - já to znám jen pro Python/Django, ale snad už je něco i pro PHP - jenže jak říkám, při minimálních změnách to není priorita).

1 a 2 bych rozhodně obojí začal Gitem (v ostatních odpovědích si "nebo jiný verzovací systém" škrtni). Git se Ti hodí jako základ elementárního vzdělání, zálohování, přesuny mezi počítači (a tím i deployment, i když se tomu někdo bude smát), případně vývojové větve nebo vracení ke starému stavu.
Založíš si tzv.repozitář na Gitlabu (pro private projekt) nebo Githubu (pro opensource) <-tato volba není dogma, na rozdíl od výše zmíněné volby Gitu.
git clone <tvůj-projekt> (tenhle příkaz si zkopíruješ z Githubu/Gitlabu) - tím si to nahraješ na kteroukoli svou mašinu.
A když už ty zdrojáky někde máš, tak v dalším kroku je nakopíruj (jen jednou, napoprvé!, na první mašině) do toho naklonovaného adresáře.
git status - Ti řekne, které soubory se odminule změnily (po předchozí akci to tedy bude milión souborů)
git diff - Ti řekne, co se zmenilo v jednotlivých souborech
úpravou souboru .gitignore odstraníš z "git status" všechny soubory, které sledovat/zálohovat/přenášet nechceš (soubory s hesly,tokeny)
git add . - všechny soubory naplánuješ, že se zapíší do příští dávky změn (místo tečky můžeš uvádět jednotlivé soubory)
git commit -m "popis/název další dávky změn" - zapíšeš dávku změn
git push - odešleš všechny commity na server Github/Gitlab
git pull - na kterékoli jiné mašině si takto stáhneš všechny změny z jiných mašin. Tím máš tedy vyřešen i ten deployment, samozřejmě musíš mít na to otevřené příslušné porty, řekl bych 443, když jsi klonoval s https, nebo 22, když jsi klonoval s ssh (což je lepší).
Jo a taky to takhle půjde asi jen na VPS, jestli jedeš na obyč. hostingu (nemáš VPS) budeš potřebovat nějaký jiný nástroj na nakopírování pouze změn. Pro ftp a Git je např. Gitftp. Když už teda jsi byl u toho Ftp, což ale není právě perspektivní protokol. Pro ssh si vhodný nástroj musíš najít nebo někdo poradí.

git log -n 10 - prohlédneš historii (nebo si přidej nějaký nástroj: gitk, tig, ..)
No a to je vše. Jestli používáš Windows, možná se to tam nepatrně liší (s těma "tečkama"?).
Časem se zlepši tak, že začneš používat větve/branch.
git branch - ukáže Ti, jaké větve máš (než se s tímto rozjedeš, bude to jen "master").
git checkout -b <pojmenování-větve> - na vývojářské mašině si takhle založ větev a commitama v ní směřuj třeba k dotvoření nějaké nové vlastnosti.
Dál už se přepínáš bez -b:
git checkout <pojmenování-větve> - když chceš dělat na té nové vlastnosti (commity a pushe se Ti nemíchají do master)
git checkout master - když chceš dělat na tom, co máš nasazeno (třeba drobnou opravu chyby)
git merge <pojmenování-větve> - novou větev jsi dodělal a celou ji bereš do "hlavního vývoje"

15
Distribuce / Re:Hledá se skutečně profesionální distribuce
« kdy: 06. 02. 2020, 15:29:42 »
My laici ovšem na KDE nic nenastavujeme. Já si tak leda přetáhnul lištu nahoru, do menu zařadil běžné programy do Oblíbené a možná něco do menu přidal (RightClick, upravit aplikace).
Jo, asi nečekej, že Ti nějaká distribuce vyhoví instantně out of the box. Je to plno různých donastavení, doinstalací a konfigurací, tak půl dne práce jistě. Jestli chceš můj postup s Debianem+KDE z posledně (vývojářská mašina pro Python/Django), napiš mi na zvolsky@seznam.cz.
Mimochodem Ubuntu, pokud vím je taky derivát Debianu, ne? Stejně jako Mint nebo MX Linux. Za Debianem je komunita, ne firma. Soustředí se na výhradně volné licence. To nemusí vždycky vyhovovat, je potřeba sáhnout po instalátoru s nonfree ovladači. Asi tady:
http://cdimage.debian.org/cdimage/unofficial/non-free/images-including-firmware/10.2.0-live+nonfree/amd64/iso-hybrid/
Čímž bych taky upřesnil, pro které hlavní distribuce je KDE taky 1st class.

Stran: [1] 2