Příspěvky

3226

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 13:08:55 »

Když jednou v xml máte EAN zboží "1231238901560" a jindy od jiného dodavatele ve stejném formátu 1231238901560, tak to chyba v datech není. To jaké typy datům přiřadíte je vnitřní abstrakce programu, a ta by měla být podřízena vnější realitě, takže když program vyhodí chybu, tak to sice není špatně, alespoň se o té chybě ví, ale požadovaná činnost v realitě vlastně neproběhla  a událost je hodnocena jako havárie. Takže program nemá skončit s chybou, ale buď provést automatickou konverzi a nebo danou větu vyřadit ze zpracování, ostatních datových vět se to týkat nemá.

Pokud někde chci mít možnost stringu nebo intu, tak ten typ je "string nebo int" a pokud chci, dál si to převedu na jeden z nich. Přesně takhle se to třeba v tom Elmu dělá - viz Decode.oneOf.

Opakuju: jak dělá Python "automatickou konverzi"? Nijak. Nedělá ji. Je to další lež. Pokud chci konverzi, musím si ji tam napsat - tj. projít celou strukturu, ocheckovat všechny typy, převést některé na jiné. Čili úplně přesně totéž jako v tom Elmu, akorát to musím dělat ručně.

Sorry, už mě ta snůška polopravd a lží nebaví, končím.

3227

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 13:00:13 »

jaký typ máfunkce json.load? Má typ struktury nejčastěji načítaných dat. Tady můžete specifikovat pravidla, které to nějakým způsobem redukují. Takže rozpoznáte, zda jde o nehomogenní data, o kterých je dáno, že mají povahu nějakého slovníku, nebo jde o konkrétní strukturu, která se stále opakuje. data získáte během ladění a provádění jednotkových testů a zaznamená je a zpracuje IDE, následně pak použije k nápovědě.

Proč zase mateš pojmy?! Prostě json.load žádný typ NEMÁ. Struktura dat, které vrací, je NEZNÁMÁ a NIJAK se nekontroluje, protože se ji NEPŘEDÁVÁ žádné schema.

Hele, já mám Python rád, je to jazyk, který používám jako druhý nejčastější, a myslím, že na některé věci (výuka, jednodušší aplikace) je naprosto skvělý a jsem rád, že se tak rozšířil, ale tyhle lži mu dělají fakt medvědí službu.

Monitorovat riziko chyby je nesmysl,  lépe je připravit systém na to, že chyba nastane, tedy definovat co nesmí nastat a připravit se na to, když to nastane.

Ano, to je filosofie Erlangu. Python pro to ale narozdíl od něj nemá prostředky. Nemá (jednoduše použitelné) procesy, supervisory, monitorování a provázání procesů, neumí restartovat část aplikace po selhání. Čili tohle by šlo, ale NEDĚJE se to. Existují snahy jako např Pykka, ale oproti Akka jí chybí některé zásadní věci, takže je to stejně nepoužitelné.

3228

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 12:41:17 »

Klasická chyba, v xml datech místo čísla je číslo ve formě řetězce, nebo naopak, staticky typovaný přístup vede na spadnutí v produkci, dynamicky typovaný projde, protože se provede automatická konverze.

To je naprostý nesmysl. Ve staticky typovaném jazyce buď dojde k načtení struktury, protože je korektní, nebo je vrácena chybová hodnota - viz http://package.elm-lang.org/packages/elm-lang/core/3.0.0/Json-Decode - dekódování vrací Result - tj buď přesně ty typy, které jsem tam chtěl mít, nebo hodnotu (Err "some error message").

V pythonu dojde k automatické konverzi? Odkdy? A jak fce json.load ví, na co má konvertovat, když jí nedávám žádné schéma?

3229

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 12:27:41 »

ale nedostanete se do situace, kdy typ bude naprosto neznámý.

Jaký typ má fce json.load?

To je základ filosofie dynamických programovacích systémů, rozhodovat se na základě informací, které jsou v daném čase k dispozici

...přičemž ale "v daném čase" znamená "při běhu v produkci". Čili pokud se při běhu v produkci zjistí, že se někde objevil neočekávaný typ, tak to prostě celé spadne.

Systém je programován tak, aby se uměl z chyby sám zotavit, protože se počítá s tím, že nastanou.

To v pythonu prakticky nejde. Respektive kdybych to chtěl udělat dobře, dostanu se do takové složitosti, že by bylo lepší použít jiný jazyk.

U statických jazyků je to naopak, snažíte se navrhnout systém tak, aby zahrnoval všechny možnosti, nemyslíte na zadní kolečka, což vede k ignorování rizika chyby a když chyba nastane, systém rovnou zkolabuje. Jístota, že systém je napsán správně je vyšší, ale zároveň je vyšší jistota, že sytém někdy bez zjevné příčiny zkolabuje díky tomu, že v něm vznikne neočekávaná chyba.

Co to je za nesmysl?! Počítat se všemi eventualitami právě znamená neignorovat riziko chyby, byť sebemíň pravdpodobné. Statický jazyk mě prostě donutí ošetřit všechny eventuality, jinak se prostě nepřeloží. U Pythonu se můžu rozhodnout, že tohle se nikdy nestane, tak to ošetřovat nebudu - a ejhle, v produkci se zjistí, že to občas nastane

3230

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 12:16:01 »

Toto je chybný přístup, IDE jako PyCharm to nedělá, protože neexistuje praktická potřeba to dělat

To jako že když píšu v Pythonu, tak se nestává, že zjistím, že mi nějaká třída narostla a bylo by fajn ji rozdělit?!

Najít v Pythonu, kde všude se používá první část a kde druhá, je peklo.

, jinak IDE jako PyCharm obsahuje gramatiku jazyka a ve spojení například s debuggerem má všechny předpoklady k tomu, aby si typy zjistilo samo a uložilo například do slovníku, nebo formou anotací do zdrojového textu. Není proto těžké udělat plugin, který by to obstaral včetně vazby na refaktoring.

Ale v Pythonu žádné typy zjistit nejde, protože formálně/striktně žádné neexistují, resp. existuje jich nekonečně mnoho. Pokud mám k dispozici možnost vytvářet úplně libovolné objekty s libovolnými atributy, tak vůbec nejde o gramatiku. Maximálně můžu použít nepovinné/volné typové anotace s tím, že jakmile checker narazí na operaci, kterou neumí rozsoudit (např. json.load), tak je typ neznámý na všech místech, kde ta data použiju, minimálně do první anotace. A i když narazím na první anotaci, bude to zase jenom předpoklad - v produkci to pořád klidně může spadnout.

3231

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 12:05:34 »

O žádných serverových věcech tazatel nenapsal ani písmeno. To si tam dofantazírovali ostatní zdejší kecálisté a na základě těchto a podobně vykonstruovaných fantasmagorií dospěli k závěru, že Python není vhodný jazyk na větší projekty.

No "větší věc" je skoro vždycky serverová věc. Pokud to není velká desktopová aplikace typu LibreOffice apod., pro kterou by platilo skoro to samý jako pro serverovou aplikaci. Akorát tam pády vadí o trochu míň, protože když to spadne, spadne to jednomu člověku.

Jde o větší projekt? Ano. Je pro něj Python vhodný? Ano. Je tedy pravdivé tvrzení, že se Python k takovým věcem nehodí? Ne.
Q.E.D.

Pro interní projekty, kde se vůbec nic nestane, když to občas spadne, je Python úplně v pohodě. O tom myslím není sporu.

3232

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 12:02:01 »

V pythonu občas lidi (hlavně začátečníci) vrací z funkcí dicty a píšou funkce, které berou dicty, protože je to jednoduché a rychlé. Pokud k tomu nedodají extenzivní dokumentaci, bývá to časem totálně neudržitelné. Tohle není problém Pythonu, ale špatného návrhu.

Ono to je ale úplně jedno, jestli vrací slovník, pole nebo n-tici. Problém je v tom, že do jakékoliv složitější datové struktury se časem může zatoulat typ, který tam být neměl. Pokud má být špatným návrhem používat jakékoliv složitější/složené datové struktury, tak je něco špatně...

Všude kde člověk pracuje s daty, které nemají (vynucované) schéma, jako třeba XML / XSD / DTD

Schema ale můžeš mít jenom mimo python. Jakmile ta data nahraješ do pythonu, můžeš stčit cokoli kamkoli a žádné schema k dispozici nemáš. Pokud si nenapíšeš objekt, který bude validovat typ při každé operaci s tou strukturou.

, tak bude narážet na problémy stejného druhu. Pokud si uděláš třeba JSON API, nebo connector na microservices v Javě, budeš to muset taky řešit a reagovat na všechno možné, co ti tam kdo posílá chybovými hláškami. Řešením imho není tohle prohlásit za nemožné a zapovězené, ale naučit se, že vyvolání výjimky, když program data neumí zpracovat je prostě součást protokolu komunikace.

Pokud nějaké službě podstrčím nevalidní data, tak je samozřejmě správně, když zareaguje chybovou hláškou, o tom vůbec není řeč, to je v pořádku a jinak to udělat nejde. Při komunikaci zvnějšku to nikdo za zapovězené neprohlašuje, proč by to dělal?!

Jediný problém je v tom, že unittesty z principu nikdy nemůžou otestovat všechno a tímpádem máš vždycky šanci, že to v produkci spadne (což máš i u té Javy, díky mj. null-u).

Vážně? Pro mě je největší bolest Unicode, překlepy se mi od doby co v editoru používám linter (pep8, pyflakes a pylint) prakticky nestávají.

To taky, ale to je návrhová nedostatečnost Pythonu 2 (vzhledem k době vzniku to nebyla chyba). On to nemusí být překlep typu místo "abcde" napíšu "abcd". Může to být třeba to, že omylem použiješ jinou proměnnou/metodu.

3233

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 28. 03. 2016, 03:34:05 »

Programování v pythonu je docela jednoduše získatelný žážitek. Pokud vás fakt tak hrozně zajímá, jak se v něm dělá, nemá smysl si řádku za řádkou vyměňovat zkušenosti, nebo čekat, až technologie umožní přenos myšlenek, ale prostě si to zkuste. Mám z toho pocit, že by to zabralo míň času, než tyhle věčné spekulace. Možná sedne, možná ne.

Python ze začátku (možná po chvilce) sedne každému, protože je to prostě fajn jazyk na rychlé věci. Debata je o tom, za jakých podmínek je to i vhodný jazyk na velké a serverové věci. A myslím, že tady zaznělo několik názor ze zkušenosti, která se těžko získává. Jistě, zkusit si můžeš všechno, ale nepřál bych nikomu strávit rok vývojem něčeho, aby pak zjistil, že šel slepou uličkou. Ne že by to tak nutně muselo skončit, ale nějaká netriviální pravděpodobnost tam je. Koneckonců asi nikdo (možná kromě Franty Fuky) nebude doporučovat psát velké a serverové věci v Lua...

Život je moc krátký, abych ho mohl trávit výrobou abstraktních továren továren, které stejně používám jen proto, abych mohl nějak ojebat typový systém.

Pokud potřebuješ (víc než jednou za uherský rok) ojebávat typový systém, tak něco děláš špatně. Typový systém je od toho, aby zamezil věcem, které bys z dobrého důvodu dělat neměl.

Občas tam nějaké bugy v typech jsou, ale většinou je to výsledkem špatného návrhu

Nebo prostě překlepu, který neodhalily unittesty. To je právě ta největší bolest.

3234

Vývoj / Re:Funkcionální frontend - zkušenosti?

« kdy: 27. 03. 2016, 14:27:54 »

For record:

Tak jsem se trochu víc ponořil do Elmu, ze začátku to bylo trochu náročnější, než jsem si občerstvil haskellovský styl a pochopil, jak to vlastně mají celé vymyšlené, ale jakmile se to zlomilo, můžu říct, že jsem fakt nadšenej. Pro programátora je to jednoduché, přímočaré a jakmile jsem si napsal kostru (připojení na websockety, správné předávání zpráv komponentám a jeden widget), jsem schopnej nový widget vytvořit během chviličky, prakticky jenom přejmenováním a úpravou modelu a view.

Hodně se mi líbí, jak mají vymyšlenou komunikaci (signály, mailboxy, porty) - FRP je fajn, cítím se v něm skoro jako v Erlangu Líbí se mi možnost celkem bezproblémové komunikace s javascriptem (přes port, takže čistě) a mile mě překvapilo, že existuje nečistá funkce Debug.log, kterou se dají kdekoli v případě potřeby dělat ladící výpisy. Vypadá to, že autor je pragmatik a ne pure-fašista, což kvituju

Musím říct, že ve staticky typovaném frontendu se po těch letech s JS cítím jak Alenka v říši <div>ů - člověk přidá nějakou událost na tlačítku a kompilátor ho upozorní, že tuhle akci ještě v update funkci nezpracoval. Žádný chyby po nasazení, funguje pověstné haskellovské "pokud se to zkompiluje, tak to funguje"

Takže, pánové, díky moc za cennou konzultaci, rady a tipy. Zdá se, že habemus framework!

3235

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 27. 03. 2016, 04:23:10 »

Je elixir, který zde často propagujete, v tomto jiný?

Ano. Všechno, co jsem psal o Erlangu, platí (až na drobnosti) i o Elixiru:

V Erlangu taky typy de facto nejsou, ale dá se použít buť velice silné "manuální typování" (místo čísla dám dvojici {number_of_seconds_since_mireks_birth, 2453461}) nebo typové anotace + docela kvalitní statická analýza (dialyzer). Plus má teda Erlang oproti Pythonu výhodu v tom, že má excelentní podporu pro práci s chybovými stavy. To Python jenom těžko může dohnat, ale tu statickou analýzu by mohl mít snad poměrně dobrou...

Největší rozdíl je v tom, že Erlang/Elixir počítá s tím, že dochází k chybám, a umí se s nimi skvěle vypořádat. Mottem se stalo heslo "Let it crash!" Viz např. http://c2.com/cgi/wiki?LetItCrash

3236

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 26. 03. 2016, 15:19:56 »

největší omyl?

Tyjo, super článek, dík! ...a jako obvykle, největší zmatek a prasárna je v C++, ten bod 6 je fakt výživnej

3237

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 26. 03. 2016, 14:42:12 »

Koukám, že čumil napsal paralelně se mnou prakticky to samý

...což mi připomnělo Jistě pane ministře:

- Celá státní správa je tu proto, aby vám radila!
- Všichni radíte stejně!
- To svědčí o správnosti udílených rad.

)

3238

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 26. 03. 2016, 14:35:30 »

Např. my máme v Pythonu udělaný docela rozsáhlý (a stále rostoucí) testovací framework a pracuje se s tím velice příjemně. Původně to vznikalo ve Visual Basicu, což byl porod. Takže to už zachováváme jen kvůli starším projektům a nové děláme na Pythonu. Čili navzdory rádoby akademickým kecům místních "géniů" to jde.

Nikdo myslím netvrdil, že to nejde. Znám projekt, který je postavený na Pythonu a má desetitisíce řádků. Otázka je, jestli je to racionální volba. Python má prostě svoje specifika, který člověk musí znát a zvážit, než se do toho pustí.

Jenom tak namátkou, co mi slina na jazyk přinese (při skutečném zvažování je potřeba to vzít z gruntu):

Ze začátku mě naláka rychlost vývoje, snadnost úprav, dostupnost vývojářů a "živost" projektu.

GIL! - pokud uvažuju nad serverovou aplikací, je GIL koule na noze. Vyřeší se to tím, že se spustí X oddělených VM. Musím řešit jejich komunikaci na vyšší vrstvě. PyPy není AFAIK dostatečně zralé, aby se na něj dalo spolehnout. Můžu zkusit async.io apod., ale dostávám se do oblasti poněkud dobastlené, bez first-class podpory v jazyce (docela připomíná promises v JS).

Dynamičnost/beztypovost - musím si setsakramentsky dávat pozor na štábní kulturu. Když třeba někam ukládám nějaká data, musím zevrubně zabezpečit, aby mi tam semtam nespadla hodnota, která tam být nemá (z vlastní zkušenosti: není nic otravnější než když člověk má proces, který běží hodiny, načítá nějaká data a po pár hodinách spadne, protože se někde objevil None místo []. Ok, nemělo to tam být, tak to ve zdrojáku ošetříme, spustíme znovu a ono to po pár hodinách spadne na None někde jinde).

Ať jsou unittesty jaké chtějí zevrubné, chyby v produkci budou. Musím nasazovat nějaký logovací systém, který mi podá dostatečně dobré informace, k jaké chybě a kde došlo (Sentry apod.)

Nakonec mě to donutí skončit u nějakých úplně oddělených komponent (buzzword: microservices), cena komunikace a náročnost na schopnosti analytika/designéra roste.

Na větším pojektu se snadnost úprav přehoupne do nesnadnosti úprav. Co bylo na začátku výhodou, se stane nevýhodou.

atd. atd. atd. tohle je fakt jenom tak v rychlosti, co mě momentálně napadlo. Jenom pro ilustraci, že rozhodnout se pro nebo proti pythonu není snadná volba a hraje tam roli spousta věcí. U jazyků, které jsou designované s myšlenkou na větší serverové aplikace od začátku, je zvažování úplně jiné. U pythonu bych to shrnul asi na "Určitě to jde. Ale zvládneme to my? A stojí nám to za to?"

3239

Studium a uplatnění / Re:Proměna programátora desktop → PLC

« kdy: 25. 03. 2016, 16:37:13 »

Dobrý den,

Dobrý den, díky moc, že jste mezi nás zavítal a věnoval nám tak vyčerpávající komentář, je to velká čest! (bez ironie)

byl bych velmi nerad, aby moje přednáška vzbudila v naivněji myslících jedincích a především obchodních (s jejich nechápáním reality mám dost zkušeností) představu, že solidní HW není potřeba a vše nahradíme Raspberry Pi za pár korun.

Vzhledem k tomu, že jste reagoval na můj příspěvek: takovému dojmu jsem nepodlehl a ani ho nechtěl vyvolat. Pokud to tak působilo, je to moje chyba, nevyjádřil jsem se dostatečně srozumitelně.

ve kterých poběží jednotlivá PLC realizovaná třeba pomocí RTOS softwarově. Vlastní řízení ke strojům bude dotažené rychlými distribuovanými vstupně výstupními sběrnicemi a vlastní IO rozhraní budou tak jednoduchá, že je po mnoho let nebude nutné updatovat. Příkladem je třeba projekt Siemensu Jailhouse

https://github.com/siemens/jailhouse

To je přesně to, co mě zajímalo, děkuju moc za odpověď!

Když už vás tady máme, můžu otázku? Zajímalo by mě, jaký volně šiřitelný RTOS byste doporučil právě pro to amatérské hraní a seznamování se - ideálně aby se výsledky pokusů pak třeba daly použít i polo-profesionálně (např. nějaká ta nekritická domácí automatizace vyrobená pro sebe sama, ne komerčně prodáváná).

Krátce jsem zkoušel několik RTOSů, konkrétně pro devboard stm32f429 a nejlíp se mi pracovalo s ChibiOS v kombinaci s grafickou knihovnou uGFX. Máte případně nějaký jiný tip, co by pro takové nasazení bylo vhodné? Jaký OS používáte pro výuku? Děkuji předem za odpověď.

Pro zájemce o pochopení a pohrání si s řízením na levném (často vysloveně "pouťovém") HW, připravuji s redakcí Roota dva články shrnující moje prezentace a bude-li zájem, tak třeba bude i pokračování. [...] Bohužel z minima reakcí na přednášky mám spíš pocit, že většina se ráda nechá pobavit, ale o to trávit kvůli opravdovému pochopení hodiny s pájkou a desítky hodin před klávesnicí zájem nemá.

To je skvělé! Myslím, že by to mohlo nemálo lidí chytnout, nejrůznější články a přednášky o "domácím bastení pro zábavu" jsou myslím hodně populární. Málo reakcí na přednášky by mohlo být způsobeno tím, že jsou Vaše přednášky vyčerpávající a laik se cítí být spíš ohromen (aspoň já ano) než že by ho napadala spousta otázek Pokud byste byl schopný a ochotný napsat návod dostatečně jednoduchý a zajímavý i pro nás laiky, abychom si mohli po večerech pohrát s technologiemi a postupy, ke kterým se jinak nedostaneme, byl by o to imho zájem, nepropadal bych skepsi!

3240

Vývoj / Re:Python - dobré rady a praktiky

« kdy: 25. 03. 2016, 11:15:43 »

Stačí si pročítat odpovědi a komentáře... jak jdou proti sobě... http://stackoverflow.com/questions/964910/is-javascript-an-untyped-language;

No a hned v první odpovědi máš řešení: So the problem is that there's a few different definitions of untyped.

Ale tvůj názor už znám; Dík.

Nejde o názor. Prostě ta otázka nedává smysl. Někdo používá pojem "beztypový" v širším a někdo v užším smyslu. Je to asi tak jako by ses ptal, jestli je "správné" Ford Puma označovat jako "sportovní auto". Někdo to dělat bude, někdo ne.