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 - Jiří Havel

Stran: 1 ... 20 21 [22] 23 24 ... 27
316
Studium a uplatnění / Re:Studium na VŠ po 40
« kdy: 05. 09. 2019, 09:36:50 »
V 40tke riesit VS? Zivot sa da pokazit aj krajsim sposobom, napriklad chlast, prostitutky ..  :)

V 40tke by si uz mal byt zabezpeceny z kazdej strany, venovat sa konickom, rodine, dovolenkam a uzival si kludnu jesen zivota..
Ale no tak... Jestli ho to láká, tak ať jde do toho.

Mozek je třeba pořádně namáhat, jinak to pak na stará kolena dopadá hodně špatně.

317
Vývoj / Re:Python Opencv load videa vysvetlenie
« kdy: 04. 09. 2019, 13:08:09 »
Petr Blahos
s readNet mate pravdu nahraval som rozne modely a ramka sa menila zhruba o velkost modelu +10%

s tym VideoCapture to nie je tak jednoznacne. Pokial je to webkamera alebo stream (uz tam je to diskutovatelne) nema load to ramky vyznam ale pri tom spracovani videa by to vyznam malo. Problem je ze neviem dohladat relevantne informacie ako to pripadne spravit load video file do ramky a spracovat skrz opencv
Co přesně myslíte tím loadem do ramky? Jakékoliv video z jakéhokoliv zdroje se musí načítat do ramky a tam dekódovat.

VideoCapture interně dělá to, že načítá komprimované packety a ty dekóduje na jednotlivé snímky. Použité packety ani snímky v paměti nedrží déle než je nutné. Nic jiného moc nedává kvůli potřebnému množství paměti smysl. Pokud potřebujete nějakou historii dekódovaných snímků, musíte si je držet sám. Více průchodů nebo seekování znamená že se jednotlivé snímky budou pravděpodobně dekódovat znova a znova.

OpenCV videocapture je hodně jednoduchý nástroj. Neumí toho o moc víc, než přečtení videa snímek po snímku.

318
/dev/null / Re:Auta na baterky - má to budoucnost?
« kdy: 03. 09. 2019, 15:34:00 »
Končím, tohle nemá cenu. Fakt se nedivím, že to Bystroushaak hned zabalil. Ale jsem rád za informaci, že mezní doba pro to, kdy může být firma ve ztrátě, je 8 let. Pak už jsou to jen vzdušné zámky. Boha jeho.
Poděkuj sám sobě. Přece jenom jsi s tím číslem přišel ty. 8)

319
/dev/null / Re:Auta na baterky - má to budoucnost?
« kdy: 03. 09. 2019, 14:08:15 »
Když firma investuje do vývoje, sotva může být v plusu.

To je ale kravina.
Tak mě pouč, jak firma vydělává na tom, že vyvíjí.
Je to kravina, protože do vývoje investují úplně všechny automobilky. Tesla je ve ztrátě protože nezvládá výrobu.

320
/dev/null / Re:Auta na baterky - má to budoucnost?
« kdy: 03. 09. 2019, 13:37:11 »
Tesla model S battery pack 75kWh, pouzite a pry jen 6 mil najeto. A pry je to dobre pro solar, takze s tou baterii neco je v neporadku.

https://www.ebay.com/itm/Tesla-Model-S-Battery-Pack-75-kWh-Capacity-low-miles-great-for-solar/183811813767?hash=item2acc09b187:g:q3YAAOSwcfNcrlJu

708850,- Kc :D


A ted tu o Jenickovi a Marence prosim. 1kWh vyjde na techto POUZITYCH bateriich na 9500,-. Kolik by staly nove?

Takze nejaky z prstu vyvucany graf o poklesu ceny baterii, ktery nahore nekdo postoval, a z ktereho je jeste predikovany pokles ceny baterii na dalsich 10 let, si muzete strcit za klobouk. A co rika ten sejdir Musk, jehoz Tesla je uz nekolik let ve ztrate, to uz je uplne jedno.

9500CZk ~ 400$.

Cena za 1kwh nove baterie je pod 200$. Tolik k te ebay.
Kde se za takovou cenu dají koupit?

321
/dev/null / Re:Auta na baterky - má to budoucnost?
« kdy: 02. 09. 2019, 12:36:20 »
Mimochodem, nahradni baterie pro Teslu 3 by mely byt mezi 5-7k$.
Měly by ... Což v případě Muskovy firmy může znamenat úplně cokoliv. Tu firmu neživí prodej aut ale vzdušných zámků.

322
/dev/null / Re:Auta na baterky - má to budoucnost?
« kdy: 30. 08. 2019, 16:56:17 »
Důležité je, že i ti vědci kteří stojí za "Teorií globálního oteplování" o ní stále mluví jako o teorii. Ale tohle téma je asi k diskuzi do jiného vlákna. Založte takové a můžeme zkusit sílu svých argumentů.
Bacha, v kontextu vědy má slovo teorie o dost jiný význam než v běžné řeči. I o kvantové mechanice nebo deskové tektonice se stále mluví jako o teoriích. Není žádný vyšší stupeň. Kdyby o tom mluvili jako o hypotéze, pak by to byla jiná. Pokud vědec o něčem mluví jako o teorii a ne jako o hypotéze, pak si je dost jistý.
https://en.wikipedia.org/wiki/Scientific_theory
Citace
A common misconception is that scientific theories are rudimentary ideas that will eventually graduate into scientific laws when enough data and evidence have been accumulated. A theory does not change into a scientific law with the accumulation of new or better evidence.

Na tenhle argument opravdu bacha. Celkem spolehlivě znevěrohodní i všechno ostatní, co člověk říká. Někdo by vás mohl hodit do jednoho pytle s mladozemními kreacionisty a plochozemci. Ti mají "Je to jen teorie" obzvlášť rádi.

323
/dev/null / Re:Auta na baterky - má to budoucnost?
« kdy: 29. 08. 2019, 16:39:52 »
Já tady za fakta nic nevydávám, přečti si noviny, poslechni si Grétu. Většina publikujících vědců, celebrit i politiků má za to, že tyto klimatické změny způsobil člověk. To je ten fakt.
Zrovna Grétu bych teda raději netahal. Teda aspoň pokud chceš někoho přesvědčovat o tom, že jde primárně o vědu a ekologii a ne o propagandu a ideologii. Klausové a jim podobní musí slintat blahem.

324
Studium a uplatnění / Re:Učebnice programovania
« kdy: 29. 08. 2019, 14:25:14 »
Např. implementace nepožadovaných funkcí. Kromě one-man-show firem není programátor ta správná osoba, která by si měla vymýšlet zadání.
Pokud je tou "funkcí" myšlena nějaká uživatelem viditelná funkčnost programu, pak naprostý souhlas. Pokud to má znamenat funkci nebo metodu v kódu, pak nesouhlasím. A do jakých funkcí je ten program uvnitř rozložený v zadání obvykle nebývá.
Citace
"Prozíravý" programátor myslí "dopředu" a zaprasí kód nadbytečným obtížně udržovatelným balastem, aby byl "rozšiřitelný". Až po dlouhé době přijde nový požadavek, nejen že ten balast nic nepomůže, protože programátor není orákulum, ale ještě to zkomplikuje, protože je víc kódu k přepisování.
Prozíravý programátor myslí dopředu hlavně na to, že po něm ten kód bude někdo číst. A ten čtenář bude muset zrekonstruovat spoustu předchozích myšlenkových postupů. Když píšu kód, tak nepíšu jednotlivé funkce ve vakuu. Navrhuju celé třídy. Tady mi dává smysl udělat takovou třídu komplet, ne jenom nezbytné části. Pak čtenář nemusí dedukovat, jestli nějaká metoda nedává smysl, nebo jenom nebyla třeba.

Jak už jsem psal, jde mi o granularitu. Nebudu psát hromadu wrapperů a interfaců jen kvůli budoucí rozlišitelnosti. Ale taky se nebudu bránit přidat pár metod do třídy, kde dávají smysl. A psal jsem to jako reakci na příspěvek, který to bral stylem "Ani jediný setter nazmar". To mi přijde spíš kontraproduktivní.

325
Studium a uplatnění / Re:Učebnice programovania
« kdy: 29. 08. 2019, 09:55:36 »
nechtěl jsem začít diskuzi o getterech a setterech, jen jsem chtěl ukázat, že to heslo YAGNI na wikipedii se týká psaní nadbytečného kódu, ne funkcionality.
Nemusíme vést diskuzi konkrétně o getterech, můžeme přejít do trochu obecnější roviny. :)

Problém s YAGNI (a to samé platí pro jakékoliv jiné jednoduché a univerzální pravidlo) je v tom, že je složité ho interpretovat a aplikovat. Třeba co přesně je ten "nadbytečný kód"? Ty gettery jsem rozepsal právě abych ilustroval že ta nadbytečnost rozhodně není nějaký přímočarý koncept. Dost záleží na kontextu a zkušenostech.

Kód není jen k tomu aby se přeložil nebo vykonal. Slouží i ke komunikaci s jinými vývojáři. A na základě zkušeností počítám jako jiného vývojáře i sebe po pár měsících. Dokonce bych si troufl tvrdit, že když píšeme kód, tak je to primárně pro lidi a ne pro stroj.

Doporučuju kouknout na https://www.youtube.com/watch?v=kYVxGyido9g&t=1s Je to sice o C++, ale ten princip je daleko obecnější a není omezený jen na jednotlivá klíčová slova. Spousta věcí v kódu nemá svůj protiklad. Buď tam je, nebo není. A pokud věci píšu když dávají logicky smysl a ne jenom, když je zrovna potřebuju, pak každá taková chybějící věc je informace pro další vývojáře. Pokud budu všechno psát jen ve chvíli, kdy to bude opravdu nutné, tak budoucí čtenář kódu o tuhle informaci přijde.

326
Studium a uplatnění / Re:Učebnice programovania
« kdy: 28. 08. 2019, 17:09:10 »
Účelem getterů a setterů není samotný přístup k členským proměnným. Jejich účelem je aby zvenku nebylo poznat, jestli nějaká taková proměnná vůbec existuje.

Ve svých aplikacích gettery ani settery nepoužívám. Proč? Jednoduše nepotřebuji žádný přístup ke členským proměnným.
Ani v obecnější podobě, jakou jsem popisoval v dalším odstavci? Zpráva, která se objektu ptá na nějakou hodnotu nebo stav, je v vlastně taky getter. Jestli tomu vevnitř odpovídá nějaká členská proměnná nebo ne by přece mělo být zvenku úplně jedno, ne? Osobně beru jako getter cokoliv, co se objektu na něco ptá a při pohledu zvenčí nijak neovlivňuje jeho stav.

327
Studium a uplatnění / Re:Učebnice programovania
« kdy: 28. 08. 2019, 16:24:58 »
mimo jiné citují tento zdroj https://ronjeffries.com/xprog/articles/practices/pracnotneed/ , kde se píše

Citace
You find that you need a getter for some instance variable. Fine, write it. Don’t write the setter because “we’re going to need it”. Don’t write getters for other instance variables because “we’re going to need them”.
Tak k téhle citaci mám dost zásadní výhrady. Asi tuším, co chtěl autor říct, ale řekl to IMO dost extrémním způsobem.

Účelem getterů a setterů není samotný přístup k členským proměnným. Jejich účelem je aby zvenku nebylo poznat, jestli nějaká taková proměnná vůbec existuje.

Třída není jenom náhodný shluk proměnných a funkcí. Je to balík, který je úzce provázaný dohromady. Pokud má ten balík nějakou vlastnost, kterou dává smysl číst zvenku, pak dostane getter. Pokud má tuhle vlastnost smysl z venku i měnit, pak dostane i setter. Jestli té vlastnosti odpovídá nějaká proměnná je úplně jedno. U takhle psaných tříd je samotná existence setteru užitečná dokumentace. Rozhodně užitečnější, než existence nějaké podobně pojmenovaného membra. Odhadovat, jestli nějaká metoda chybí protože není rozumné danou proměnnou měnit jen tak, nebo to jenom zatím nebylo potřeba, nemusí být až taková sranda.

Souhlasím s tím, že není dobré psát zbytečný kód. S čím nesouhlasím je granularita. Ono co vlastně je nebo není potřeba není samotný getter nebo jedna třída. Potřeba je nějaká funkce celého systému.

328
Studium a uplatnění / Re:Učebnice programovania
« kdy: 28. 08. 2019, 12:32:48 »
Spousta toho "balastu" tam není nezbytně nutná teď, ale je to investice do budoucna.

https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
YAGNI je přece o nadbytečné funkcionalitě. Ne o tom, že ta požadovaná funkcionalita musí být implementovaná tak minimalisticky, jak to jen jde.
Požadavky se mění nepříjemně často. Takže je rozumné od začátku psát tak, aby pozdější změny tolik nebolely. A všechny ty návrhové vzory a další osvědčené praktiky prostě znamenají kód navíc.

329
Studium a uplatnění / Re:Učebnice programovania
« kdy: 27. 08. 2019, 17:22:03 »
proč autor detailního návrhu rovnou nenapíše ten kód? Nebylo by to rychlejší?
No nebylo. Na papír není třeba házet všechen boilerplate kód, na kterém není nic k vymýšlení. Zrovna Java v tomhle nějak extra úsporná není.

kdyby ten co to vymýšlí, psal rovnou kód, nadbytečný boilerplate by se zredukoval.
Jo, akorát že +- ve stejném poměru jako ten ostatní kód.
Při návrhu jsou daleko důležitější věci, než minimalizace množství textu. Spousta toho "balastu" tam není nezbytně nutná teď, ale je to investice do budoucna. Vždyť i každé rozhraní, které od sebe odděluje dva moduly, znamená hromadu psaní.

330
Studium a uplatnění / Re:Učebnice programovania
« kdy: 27. 08. 2019, 10:06:17 »
proč autor detailního návrhu rovnou nenapíše ten kód? Nebylo by to rychlejší?
No nebylo. Na papír není třeba házet všechen boilerplate kód, na kterém není nic k vymýšlení. Zrovna Java v tomhle nějak extra úsporná není.

Stran: 1 ... 20 21 [22] 23 24 ... 27