Příspěvky

91

Vývoj / Re:C++ no default constructor exists for class

« kdy: 22. 09. 2019, 12:49:53 »

Ahoj, zkus použít "constructor initialization list".  Přecházíš ze C# nebo Javy?

Kód: [Vybrat]

    
class CustomSlot
...
    public:
        CustomSlot(
            const unsigned int index,
            const KeyboardShortcut copy_shortcut,
            const KeyboardShortcut paste_shortcut
        )
            :_index(index),
            _copy_shortcut(copy_shortcut),
            _paste_shortcut(paste_shortcut)
        {}
...
};

92

Studium a uplatnění / Re:Myslite v...

« kdy: 08. 09. 2019, 18:54:52 »

jen pokud nenajdu odpověď v offline dokumentaci

Offline dokumentace? To existuje?

Zeal https://zealdocs.org/
Dash https://kapeli.com/dash
atd., atp.
Zkus si příště zadat "Offline Documentation Browser" do "online" vyhledávače.

93

Studium a uplatnění / Re:Učebnice programovania

« kdy: 28. 08. 2019, 21:22:03 »

Úč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.

V obecnější podobě používám jako getter metodu toString() a jako setter konstruktor. Jinak se objektu na nic neptám, protože mě stav jeho atributů nezajímá.

A jak to vlastně děláš? Mějme třeba objekt `Color` (RGB). Určitě dělám něco blbě, ale já bych tam viděl nějaký getter či accessor, to už je jedno jak to nazvu.

94

Vývoj / Re:Python 3 os.path.join vracia zvlastnu hodnotu

« kdy: 17. 08. 2019, 16:07:08 »

Já bych ještě podotknul, že join v takovém případě moc nemá smysl. Spíš bych to viděl takhle:

Kód: [Vybrat]

icons = os.path.join(output_path, 'data', 'g1.ico')

Jo, to je zdaleka nejlepší řešení.

95

Vývoj / Re:Python 3 os.path.join vracia zvlastnu hodnotu

« kdy: 17. 08. 2019, 11:59:09 »

Koukni na "Python special characters" ať předejdeš dalším problémům. Další možnost je použít raw string, takže prefixuješ pomocí r: `os.path.join(output_path, r'data\racking.png')`.

96

Vývoj / Re:Python 3 os.path.join vracia zvlastnu hodnotu

« kdy: 17. 08. 2019, 11:49:54 »

Všimni si, že v posledním řetezi máš 'data\racking.png'), kde '\r' character je tzv. "carriage return".
Koukám že jsi na Widlích viz ty zpětný lomítka. Doporučím ti použít místo os.path moderní Pathlib https://docs.python.org/3/library/pathlib.html, která za tebe řeší např. formát cesty. Pokud chceš rychlý řešení, tak escapuj '\\r'.

97

Vývoj / Re:Váš názor na kombinaci několika technologií

« kdy: 03. 08. 2019, 11:20:18 »

Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.

Nesmysl, dospělí lidé přeci taky řeší jazyky (byť rozhodně ne způsobem vedeným v této diskuzi).

Ano, řešíme jazyky, ale ne na téhle úrovni. Takže jste to pochopil (?)

98

Vývoj / Re:Váš názor na kombinaci několika technologií

« kdy: 02. 08. 2019, 14:49:42 »

Každej, kdo věří tomu, že Java je na tom tak špatně jak tu prezentuje pan Mocik, by se měl striktně držet papírových peněz, protože bankovní systémy jsou postaveny z velké části na Javě.

K tomuto napíšu len jedno. Nepsal som nič o "nebezpečnosti" ale o tom jak je programovací jazyk špatný. To ale neznamená že pre uživatela je program naprogramovaný v Jave striktne "nebezpečný na použitie". Len tvrdím že to čo je naprogramované v Jave by v iných jazykoch šlo naprogramovať omnoho lepšie. To je veľký rozdiel.

Vsteky tvoje argumenty boli vyvratene a ti si tu aj tak bezdovodne kopes do Javy, pricom tvoja povodna otazka bola o niecom uplne inom.

to áno, ale kto tu prvý spomenul pojem Java? ne ja, ale "Javista".
Ešte k tomu ďalšiemu o Linusovi čo si psal. Kopíruješ moje argumenty. "Javista" tvrdí že je expert, a teraz urážate Linuse v podobnom význame? Pff... To vypovedá o logike "Javistov"...  A áno mám z Javy trauma, ako každý kto programuje udržitelný software, a nie problematický balast, u ktorého když chcete pridať nejakú funkcionalitu, tak to ovplivní beh 200 iných funkcionalít. Tady končím s kecmi o Jave. OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?

Máte dost nedospělý pohled na svět. Dospělý člověk řeší problém, puberťák jazyk. "OK, vratme sa späť k pôvodnej otázke, je teda Gotron vhodný pre CMS?" Ne.

99

Vývoj / Re:Váš názor na kombinaci několika technologií

« kdy: 30. 07. 2019, 17:19:08 »

Na druhú stranu, keby sa každý držal iba overených technológií, tak teraz asi všetci píšeme vo Fortrane a nikdy nevzniklo alebo sa nerozšírilo C, Java [...]

Už s Fortranem tu byly jazyky, které se na něco hodily víc než Fortran (1957), třeba Lisp (1958). Není chyba jazyk, že není pro všechno vhodný, právě naopak. Dnešní Fortran je velice čitelný jazyk a má i některé věci, které bys tam nečekal (http://fortranwiki.org/fortran/show/Fortran+2008), třeba `pure` funkce http://www.lahey.com/docs/lfpro78help/F95ARPURE.htm

100

Odkladiště / Re:Kurz práce v Maya 2017

« kdy: 29. 06. 2019, 11:39:00 »

Maya se přejmenovala na Blender!

101

Vývoj / Re:Alternativa k Excelu eventualne k VisualBasic

« kdy: 27. 06. 2019, 12:54:49 »

Excel tedy nemusím, ale 1000 řádků zvládne. Běžně pracujeme s cca 40 000 -- máme ho jako frontend -- mezičlánek pro ruční zpracování dat. Máte tam nějaké boty. Jinak alternatva je prostě použít Python, Pandas aj. nebo zkuste Orange https://orange.biolab.si/screenshots/ nebo Knime Ale je to prostě víc práce než s Excelem.

102

Vývoj / Re:Použití Python Flask v komerční sféře

« kdy: 26. 06. 2019, 20:20:28 »

Ako napisal gill, taky hello world do prehliadaca je tusim na 3 riadky kodu. Zaklad Flask-u sa da pochopit za jeden den, mozno potom este chvilku trva, kym clovek dobre pochopi kontexty a pracu s nimi (Application context, Request context), ale je to naozaj jednoduche. Sqlalchemy sa s Flaskom moze, ale nemusi pouzivat, ale stoji za to s nim vediet pracovat. Dnes si uz neviem predstavit zlozitejsiu databazovu aplikaciu bez tohoto ORM.

Naopak orm se hodi na nejake primitivni weby, nedokazu si predstavit slozitejsi databazovou aplikaci s orm. To proste nikdy nefunguje. Par takovych zoufalych firem znam co to zkusilo, pak jsou radi, ze jsou schopni zaplatit nekoho, kdo je z toho bordelu vyseka.

Moje řeč.

103

Vývoj / Re:Použití Python Flask v komerční sféře

« kdy: 26. 06. 2019, 20:16:03 »

V asynchronnim svete tu otazku musite polozit jinak: ktera SQL databaze je schopna obsluhovat 10k pripojenych klientu.

to znamena co? I v asynchronnim svete coroutiny sdili nejaky connection pool, ktery je urcite mensi nez 10k spojeni, typicky radove desitky. Bottleneck je databaze, ne aplikace.

Presne tak, takze je uplne zbytecne, aby vam databaze (nebo cokoliv jineho, pomaleho) blokovalo process/threadu, kdyz se vlastne jen ceka.
Pekne jste si odpovedel, proc je asyncio dobre i pro komunikaci s databazi :-)

vykon aplikace je omezen databazi. je jedno jestli cekani na vysledek dotazu blokuje aplikacni proces, protoze databaze by stejne vic nezvladla.

Já se async v Pythonu zatím vyhýbám, kde můžu, ale proč by pak někdo dělal asynchronní knihovnu jako tato:
https://github.com/MagicStack/asyncpg ?

104

Vývoj / Re:Použití Python Flask v komerční sféře

« kdy: 25. 06. 2019, 14:29:32 »

Zvláštní, mám to přesně naopak, vůbec nevím k čemu je tahle vrstva dobrá.

aby ušetřila práci. Zjednodušuje dotazování, nemusíte stále dokola psát stejné podmínky joinů. Když dlouhodobě pracujete se složitější databází, tak se ORM vyplatí.

že ti ORM postaví rozumný schéma.

ORM postaví takové schéma, jaké definujete. SQLAlchemy nijak neomezuje.

Máme s SQLAlchemy zkušenost a v ničem nám nepomohla.

Jak dlouho, na kolika projektech jste ji používali? Zvýšená produktivita se projeví až po čase.

To že schovává SQL mi přijde jako nevýhoda.

nic neschovává, dotazy generuje transparentně. Jen nemusíte psát stále dokola stejné části dotazů.

Co se týká generování schématu, ne děkuji. Pracujem s Postgresem, nepotřebujem nějaký magický nástroj co si poradí s každou databází. Schéma se verzuje, každá změna je jako SQL skript, nic v Pythonu tam nechcem.

Máte příklad tabulky, kterou SQLAlchemy nedokáže vygenerovat? Příklad dotazu, který nelze formulovat?

Co s tím má společného, jak dlouho jsme co použivali? Nám ta knihovna nepomáhala, já nepíší, že něco snad neumí, ale přímočarost je pro nás přednější a jediná výhoda mi přišla, že se teoreticky dá migrovat na jinou DB. Žádné komplexní věci neděláme, tak ji asi nepotřebujem -- už vůbec ne schéma generované z modelu.

105

Vývoj / Re:Použití Python Flask v komerční sféře

« kdy: 24. 06. 2019, 17:17:28 »

Zvláštní, mám to přesně naopak, vůbec nevím k čemu je tahle vrstva dobrá.

aby ušetřila práci. Zjednodušuje dotazování, nemusíte stále dokola psát stejné podmínky joinů. Když dlouhodobě pracujete se složitější databází, tak se ORM vyplatí.

že ti ORM postaví rozumný schéma.

ORM postaví takové schéma, jaké definujete. SQLAlchemy nijak neomezuje.

Máme s SQLAlchemy zkušenost a v ničem nám nepomohla. To že schovává SQL mi přijde jako nevýhoda. Co se týká generování schématu, ne děkuji. Pracujem s Postgresem, nepotřebujem nějaký magický nástroj co si poradí s každou databází. Schéma se verzuje, každá změna je jako SQL skript, nic v Pythonu tam nechcem.