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 - BoneFlute

Stran: 1 ... 75 76 [77] 78 79 ... 133
1141
Vývoj / Apple Cocoa bez XCode
« kdy: 12. 09. 2018, 21:28:32 »
Zdravím.

Nevíte někdo o nějaké knihovně, tutoriálu, něčem, kde bych mohl vytvářet okýnkové aplikace pro macos a ios bez použití xcode a jeho UIBuilderu? Nevadí mi swift, ale chtěl bych to vytvořit a přeložit čistě pomocí příkazové řádky. Něco jako http://zetcode.com/wxpython/firststeps/

Možná je to jednoduché a jedná se jen o mou neznalost. Ale zatím umí vytvořit aplikaci jen v gtk/qt, což se mi na mac moc nezamlouvá.

Předem dík.

1142
Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?
« kdy: 12. 09. 2018, 20:59:06 »
Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.

Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.

Myslel jsem, že ORM má skrývat fakt, že data jsou v relační databází a prezentovat mu je, jako by byly v nějakém úložišti objektů. Pak mi ale připadá přirozené, že programátor s objekty pracuje po jednom a explicitně přechází mezi nimi pomocí vzájemných odkazů a při tom neřeší, že každý krok znamená dotaz do databáze. Není mi moc jasné, jak by mělo ORM vypadat, aby navádělo k efektivní práci s databází a zároveň nevypadalo jako SQL přebalené do jiné syntaxe.

Možná to tak někteří chápou, pak by měl Pavel s tím COBOLem pravdu.

Mě na SQL přijde revoluční právě ten deklarativní zápis. Pošleš engine algoritmus, a on ti vyplivne výsledky. Něco podobné je možné pozorovat u LINQ, nebo GraphQL. Díky tomu se opravdu můžu oprostit od detailů práce s databází (na druhou stranu mi přijde zase škoda vzdát se pokročilejších možností) aniž by to začalo být brutálně neefektivní.

V některých svých hračkách, co jsem dělal jsem měl specializovaný DSLko, kterým jsem se dotazoval na objekty, a pokoušel jsem se to mé pseudoORM přinutit, aby generovalo SQLka, která bych napsal stejně. Celkem to šlo.

Nebo jiný způsobem. Nette/Database to dělá tak, že dokáže zoptimalizovat i ten tvůj kód. Při prvním průchodu to provede všechny dotazy, to si nakešuje, a při dalších už to načítá hromadně. Mě ten způsob není moc sympatický, ale funguje to.

1143
Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?
« kdy: 12. 09. 2018, 20:10:52 »
To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
Kde jsem něco podobného už jenom slyšel... "Komunismus principiálně může v pohodě fungovat. Bohužel, zatím to všichni dělali blbě."

A to nevíš, že já ORM nemám rád, a to hlavně pro tu jejich snahu o objektovost :-P

1144
Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?
« kdy: 12. 09. 2018, 20:09:16 »
To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

Připadá mi, že ORM svádí k programování ve stylu:
Kód: [Vybrat]
sum = 0
foreach a = collection_of_a()
  if test(a) then
    b = collection_of_b(a.b_id)
    if test(b) then
      sum += b.val
return sum
Není mi jasné, jak tohle dobré ORM zoptimalizuje, i když je jasné, že se to dá přepsat do jednoho SELECTu s JOINem dvou tabulek.
Jsi si jist, že za to může to ORM?
Setkal jsem se s kódem, který ORM nepoužíval a dopadlo to stejně.

Já na ORM pohlížím jako na něco, co by mě mělo usnadnit rutinní práci. Neočekávám, že zajistí, že se nebudu střílet do nohy.

1145
Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?
« kdy: 12. 09. 2018, 20:05:10 »
To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.
Za pravnika bych te nechtel  ;D

Tak dělám, co umím. Co neumím, nedělám :-)

1146
Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?
« kdy: 12. 09. 2018, 17:19:39 »
To je to COBOLovské myšlení, které se nepodařilo vymýtit - jen převléklo kabát, a objevilo se pod jinou jmenovkou - ORM.

Nechci ORM obhajovat, ale musím :-) Principielně není problém, aby dobré ORM posílalo optimální SQLka. Problém není myšlení, ale to, že ta ORM jsou blbě napsaná. Bohužel všechna, a to dělá pak ten blbej dojem.

1147
Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?
« kdy: 12. 09. 2018, 17:04:36 »
IMO to vypadá jako hodně blbý nápad. Pokud nutně potřebuješ zaplnit log mraky záznamů, tak si ty upravené záznamy můžeš vytáhnout selectem. Ale fakt si nejsem jistý, co se dá z takového logu vykoukat, pokud je těch upravených záznamů víc než pár desítek.

Např. se může udržovat historický log změn konkrétního "byznys" objektu. Kdo co kdy jak změnil. A nemusí to být do souboru, ale třeba do úplně jiné DB (např. zrovna to mongo).
Dělám to - mám na to něco jako verzování.

V prvé řadě bych to plnil do spešl tabulky na stejné databázi.

Nevím, proč by to měla být jiná databáze, ale pokud opravdu je ten důvod jinej než jen "třeba", tak postgre umí spousta věcí. Napsal jsem si v něm Python funkci, která mi při insertu ověřovala, zda IČO existuje dotazem do ARESu. Bylo to pomalý jak prase, ale pro danný případ dostačující. Takže nevidím důvod, proč bych se podobným, nebo lepším způsobem nemohl napojit na cokoliv. Třeba i Filesystem.

1148
Vývoj / Re:jak navrhovat robustni systemy
« kdy: 10. 09. 2018, 20:21:22 »
Takze mame formular, jedna sluzba na jmeno, druha na prijmeni,...  na PSC radeji 2. Napsano pekne v jave, kazda sluzba aspon 500 MB RAM, ze...
Bastl muss sein.

BTW: nevite, jestli existuje neco jako .NET byte code interpret psany v jave? ;-)

Chápu tvou nadsázku. Problém je v tom, že se míjíš se zadáním. Nebo chceš tvrdit, že je špatný psát robusní aplikace jen proto, že je to drahý? To spíše vymyslíme jak je psát, aby to nebylo drahý, ne?

V roce 86 ve firmě Ericsson tento problém zkoušeli řešit. A opravdu tam každá blbost má vlastní process. A je to malé a rychlé.
A dnes už v Erlangu spíš jen udržují stará řešení, než že by v něm psali něco nového...

I kdyby, no a?

1149
Vývoj / Re:Zapouzdření C++: Co dělám špatně?
« kdy: 10. 09. 2018, 20:18:59 »
Pro účely zpětné kompatibility se taky zavedly inline namespace. Překladač vidí všechny namespacy s číslem verze, takže manglované názvy jsou pořád stejné. Pokud se zvedne verze, tak se vytvoří nový namespace s vyšším číslem verze a ty předchozí se nechají být. A v headeru se do neverzovaného namespace nainlinuje ten s nejvyšší verzí, takže při překladu se automaticky používá nejnovější verze.

Tohle mě zajímá. To jsi v reálu někde viděl? Kde?

1150
Vývoj / Re:jak navrhovat robustni systemy
« kdy: 09. 09. 2018, 22:20:53 »
Takze mame formular, jedna sluzba na jmeno, druha na prijmeni,...  na PSC radeji 2. Napsano pekne v jave, kazda sluzba aspon 500 MB RAM, ze...
Bastl muss sein.

BTW: nevite, jestli existuje neco jako .NET byte code interpret psany v jave? ;-)

Chápu tvou nadsázku. Problém je v tom, že se míjíš se zadáním. Nebo chceš tvrdit, že je špatný psát robusní aplikace jen proto, že je to drahý? To spíše vymyslíme jak je psát, aby to nebylo drahý, ne?

V roce 86 ve firmě Ericsson tento problém zkoušeli řešit. A opravdu tam každá blbost má vlastní process. A je to malé a rychlé.

1151
Vývoj / Re:Mají tabulkové databáze v dnešní době smysl?
« kdy: 08. 09. 2018, 20:43:38 »
To je ta genialita některých vývojářů, že už dopředu vědí, že jejich výtvor bude rychlý. Já osobně si sice pamatuji, že relační databáze měly jeden veliký nedostatek - oproti tehdejším databázím byly pomalé. Nakonec i dnes je pan Stěhule živ z toho, že obchází firmy a zrychluje ty jejich aplikace. Samozřejmě by pan Stěhule udělal ty aplikace hned zpočátku rychlé - ale on nemůže bý u každého projektu - ledaže by si vzal k ruce pana Jirsáka.
Tak Pavla Stěhule bych se zastal, ten tomu aspoň rozumí a dá se s ním bavit.

Ten článek bych si rád přečetl - klidně mi jej můžete poslat privátně, jestli máte obavy o redakci roota. Mail na mne se válí na netu - nebo někde u piva můžeme podiskutovat a výhodách a nevýhodách RDBMS.
Nebyl by si sám.

24.9. bude Postgres meetup - u piva můžeme dát řeč.
Kde? Dáš link prosím?

1152
Vývoj / Re:Proč ten hype okolo Go?
« kdy: 08. 09. 2018, 13:52:11 »
Je to psuedokod, ale aby ste boli spokojni
Kód: [Vybrat]
file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

To podtržítko považuji právě za tu aktivní snahu ignorovat chybu.

Bloky try-catch jsou spíše k seskupení chyb, aby si nemusel odchytávat každou jednu. Nepolemizuji nad tím, zda je to dobře nebo špatně.

No a když tedy tento kód použijeme a funkce open() vrátí chybový stav, co se stane?
To samé, jako když v java-like napíšeš:
Kód: [Vybrat]
try {
   file = os.Open("/path/to/file.txt")
}
catch (Exception e) {}

Já v go nikdy nic nepsal, ale naprvní pohled mi tento přístup přijde pozadu oproti tomu jak to dělá Rust nebo i oproti klasickým vyjimkam,
Co konkrétně by si tomu vytknul?


Je to psuedokod, ale aby ste boli spokojni
Kód: [Vybrat]
file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

Takže to podtržítko není dostatečný projev aktivity? OK, pro někoho může být.

1153
Vývoj / Re:Maji tabulkove databaze v dnesni dobe smysl?
« kdy: 07. 09. 2018, 19:32:46 »
Částečně má pravdu.

Problém je v tom, že 1/ SQL je unifikovaný API, kterému všichni všude rozumím. A 2/ relační databáze jsou extrémně dobře odladěné.

Takže i když někdy je jejich použití na projekt poněkud neintuitivní, tak furt tak nějak není alternativa.

U NoSQL databází bych viděl výhody hlavně v tom škálování. Jinak se domnívám že ještě potřebují dozrát, než budou na stejné úrovni jako SQL.

1154
Vývoj / Re:Proč ten hype okolo Go?
« kdy: 07. 09. 2018, 19:28:12 »
Je to psuedokod, ale aby ste boli spokojni
Kód: [Vybrat]
file, _ := os.Open("/path/to/file.txt")

Proste ide o to, ze pri vynimkach musite pre ignoraciu chyby nieco aktivne urobit

To podtržítko považuji právě za tu aktivní snahu ignorovat chybu.

Bloky try-catch jsou spíše k seskupení chyb, aby si nemusel odchytávat každou jednu. Nepolemizuji nad tím, zda je to dobře nebo špatně.

No a když tedy tento kód použijeme a funkce open() vrátí chybový stav, co se stane?
To samé, jako když v java-like napíšeš:
Kód: [Vybrat]
try {
   file = os.Open("/path/to/file.txt")
}
catch (Exception e) {}

Já v go nikdy nic nepsal, ale naprvní pohled mi tento přístup přijde pozadu oproti tomu jak to dělá Rust nebo i oproti klasickým vyjimkam,
Co konkrétně by si tomu vytknul?

1155
Vývoj / Re:Proč ten hype okolo Go?
« kdy: 07. 09. 2018, 19:23:51 »
Kód: [Vybrat]
file, _ := os.Open("/path/to/file.txt")
No a když tedy tento kód použijeme a funkce open() vrátí chybový stav, co se stane? Já v go nikdy nic nepsal, ale naprvní pohled mi tento přístup přijde pozadu oproti tomu jak to dělá Rust nebo i oproti klasickým vyjimkam,
vrati chybu kterou zahodis a v ty promenny file bude nil, s cim nekde dal musis pocitat

Nevýhodou tohoto přístupu je, že se už nedozví, proč se ten soubor nepodařilo otevřít.

Neřešíme tu skutečnost, že když chybu zahodíš, tak se nedozvíš, proč se nepodařilo soubor otevřít.

Bavíme se tu o tom, že způsob, jak s chybou pracuje Go a jak třeba Java je v určitých ohledech stejný.

Stran: 1 ... 75 76 [77] 78 79 ... 133