Příspěvky

901

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 06. 06. 2018, 21:23:48 »

Tak tohle co píšeš je typické zmatení, je to totiž tvůj subjektivní dojem a neuvědomuješ si to. Řekněme, že děláš inf. systém typu sociální tíť. Místo sendEmail() tam dáme raději sendPM(), to víc pasuje. User z hlediska OOP v tomto systému představuje prostě Usera, který se přihlašuje do ystému, odhlašuje, na něco kliká, atd. Proč by tam nemohl mít metodu sendPM(msg), ale save() ano? To je totiž tvoje vlastní subjektivní asociace, že si třídu User bereše jako něco strikně vztahujícího se k databázi. User v OOP nemá mít save() o nic víc, než sendPM(msg).

Nejspíš tam bude nějaká Service, která dostane kontext (uživatele, adresáta, text zprávy) a která tu zprávu pošle. Ale dokážu si představit, že by i User->sendMessage bylo obhajitelné řešení - záleží na zbytku aplikace.

902

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 06. 06. 2018, 21:19:01 »

Nicméně původní problém je spíš v tom, že "učebnicové OOP" je těžko prakticky použitelné na architekturu/design aplikace. Ne že by to nešlo, ale prostě to dře. Čím vyšší úroveň, tím je to horší.

Přesně tak. Něco jiného je programovací jazyk a něco jiného architektura/design aplikace. Takové ty klasické příklady s osobami, psy nebo geometrickými tvary svádějí k myšlence, že se popisuje architektura aplikace, ve skutečnosti se ale OOP používá na úrovni programovacího jazyka, zatímco architektura aplikace je spíš řešená jako data + služby.

Učebnice by měla jasně sdělit, že se v dané kapitole řeší jen doménové objekty (tj. entity) a že architektura aplikace jako taková se bude řešit jindy.

A mělo by tam být vysvětleno, že mají být entity vyčleněny do samostatného balíčku a že mají mít co nejmenší, dobře definovanou závislost na zbytku aplikace.

903

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 06. 06. 2018, 19:34:55 »

Ano, to by bylo krásné, jenže nemůžete uložit jen tak Usera s id Company, když Company ještě není uloženo a tudíž ten klíč zatím v DB neexistuje.

To záleží na tom, jak má ten který ORM framework vyřešeny závislosti entit. Může například uložit nebo aktualizovat všechny závislosti nebo naopak žádnou (pak je musíte uložit ve správném pořadí sám). Navíc může rozlišovat, zda je ta entita attached:

904

Vývoj / Re:OOP jazyk - problém klasického stříhu

« kdy: 06. 06. 2018, 19:20:35 »

Ve slušné učebnici bude spíš popsán rozdíl mezi Active Record a Data Mapperem. Na to se tazatel asi ptá. IMHO každý přístup má svoje výhody a nevýhody:

• https://cs.wikipedia.org/wiki/Active_Record
• https://cs.wikipedia.org/wiki/Data_Mapper

Navíc obě varianty mají různé implementace, které se liší v jednotlivostech (například nakládání se session - zda se rozlišuje mezi attached a ne-attached instancí).

905

Studium a uplatnění / Re:Výběr vhodného OOP jazyka

« kdy: 31. 05. 2018, 22:04:15 »

Doporučuju sledovat vývoj jazyků postavených na jvm (Clojure, Groovy, Kotlin, Scala).

906

Vývoj / Re:JavaFX a Swing nikde nic

« kdy: 31. 05. 2018, 17:29:46 »

Ke kritice běhu javy ve virtuální mašině - zrovna kolem JVM se soustřeďuje dost nových progresivních  jazyků, všechny těží z propojení legacy kódu s moderním jazykem. Navíc je tu GraalVM, která v tom jde ještě dál.

Nodejs vs. java - až najdete benchmark, který porovnává porovnatelné, pak se můžeme o něčem bavit. Porovnatelností myslím porovnat projekty srovnatelné svým rozsahem, stejnými požadavky na udržitelnost a s podobnou dobou existence. Do té doby si každý může nastavit metriku tak, aby vyhrál jeho oblíbený jazyk nebo devstack. IMHO je problém porovnat i frameworky v rámci jednoho jazyka a běhového prostředí, udělat vypovídající porovnání mezi různými jazyky a běhovými prostředími je dost těžký úkol. Takže se ohánět nějakým srovnáním je sice zajímavé, ale dělat z toho nějaké závěry moc nejde.

907

Vývoj / Re:JavaFX a Swing nikde nic

« kdy: 30. 05. 2018, 21:17:00 »

Ale ne dpč. v bance a pojišťovnách, kde se píšou tisíciřádkové business logiky pro intranet appky a oni do toho takhle mermomocí cpou ten gaylordský javascript - to tam prostě nemá vůbec co dělat.

Tebe vzbudili z hibernace, ze jo? JavaScript se uz pevne zabydlel i na serveru a ty same knihovny pak nemusis mit dva krat, jednou v jave a jednou v javascripte. Java proste bezi tak nejak se setrvacnosti a za deset let na ni budeme koukat jak na Basic nebo Perl. Neco z praveku IT :-) JavaScript proste vyhral. Muzete nesouhlasit, muzete bucet, muzete plakat a nebo se smat nic s tim nenadelate.

JS je jednoduchy, computational complete a tedy v nem udelas vse. Ze nema nejakou vychytavku z jineho jazyka a je nutno pouzit nejaky design pattern je jen implementacni detail. Stejne mas milion knihoven a z toho zhruba stovku prvotridni kvality a tak nikdo uz kolo nevynaleza. Puntickari a puristi muzou sahnout po TypeScriptu nebo jinem jazyku co transpiluje do JS. Je od zakladu event driven, asynchronni, da se v nek kodit jak proceduralne tak objektove ci funkcionalne.

No hejeteri ted zacnou neco o 0.1 + 0.2, nepochopeni operatoru +, == atd. ty si nevsimej , jdou jen puknout zavisti a zalem.

Vývoj v jazycích je velký, rozhodně nelze říct že vyhrál js. Pokud js přežije, tak asi v jiné podobě než je dnes, buď se rozšíří o featury běžné v jiných jazycích anebo se z něj stane jen intermediate jazyk, do kterého se bude transpilovat. Oboje se děje již dnes (viz es6 anebo typové varianty javascriptu - TypeScript, Dart atd.).

908

Vývoj / Re:JavaFX a Swing nikde nic

« kdy: 30. 05. 2018, 21:09:27 »

Nebo si snad myslíš, že ve Facebooku objevili Ameriku nebo co? To je prostě tak, že v Javascriptu se dělaly pořád jen webové srágory. Jednoho dne přišel někdo, kdo řekl, že teď už se v tom budou psát i aplikace. Jenže se zjistilo, že dosavadní zázemí a knowhow v javascriptu je dobré výlučně pro jednoduchý webový bordel a jakmile chtěli ty aplikace začít dělat, viděli, že se to pořádně nedá - zaprvé pro to neexistují frameworky a knihovny a zadruhé pracovaní síla, javascriptáři, mají místo mozku z css kostku a nesjou schopni složité aplikace napsat tak, aby je potom i někdo přečetl. Tak začali znovu vynalézat kolo a kopírovat to, co už na desktopu existovalo několik dekád. A vznikl React, Redux, a vznešené pičoismy jako je reaktivní programování. Všechno jsou to krycí jména pro postupy, které už dávno existovaly, ale javascriptáři si na to udělali patent a svůj vlastní svět a teď si myslí, že stvořili něco nového. Ty jsi jeden z nich.

Je to tak. V tomhle by mělo hrát roli vzdělání, aby měli vývojáři širší obzor a historické souvislosti.

909

Vývoj / Re:JavaFX a Swing nikde nic

« kdy: 30. 05. 2018, 14:11:13 »

Chápu, že desktop UI už tolik nefrčí, ale dpč. jenom 6 nabídek práce v celé ČR? Oni se snad v těch korporátech zbláznili, že všechny ty svoje intranetové bastly už dělají na webu.

Na druhou stranu se už i na webu v tom javascriptu používají pokročilé postupy, které se dříve používaly jen na serveru nebo desktop aplikacích. Dekompozice, MVC, junit testování. V tom vidím pokrok a oba světy (desktop a web) tu docela konvergují.

Ale nástroje, které to vůbec umožňují, jsou bohužel dost komplikované. Ve výsledku si myslím, že web vývoj není ani jednoduchý ani levný. Osobně nechápu, proč víc nefrčí javafx, dají se v tom dělat opravdu atraktivní aplikace a nemusí se do toho tahat celý webový devstack.

910

Vývoj / Re:Dva stejné regulární výrazy

« kdy: 29. 05. 2018, 19:33:48 »

Cygwin = GNU OSS + cygwin dll implementující POSIX API pro windows. Jaký dopad to bude mít na regexp knihovny nedokážu odhadnout, ale není vyloučeno ani to, že tam ta knihovna funguje trošku jinak (byť má stejné API).

911

Vývoj / Re:Dva stejné regulární výrazy

« kdy: 29. 05. 2018, 13:41:34 »

Pro regulární výrazy neexistuje žádný standard, každá knihovna je má trochu jinak.

Každá knihovna to má sice jinak, nicméně náznak standardizace tu existuje Regular_expression#Standards

Jinak existuje mnoho debuggerů pro regexp, některé jsou on-line a někdy umožňují i porovnat i různé implementace (často php/pcre, javascript, perl, ruby). Některé umožňují i krokovat a sledovat postupné vyhodnocování. Osobně žádný nepoužívám, takže nedoporučím, ale Google poradí.

Že bude cygwin fungovat jinak než linux bych nečekal, je potřeba se podívat, jaká knihovna ty regexpy v daném nástroji/jazyku implementuje a porovnat verze v cygwin a linuxu.

912

Vývoj / Re:Kompilace na Linuxu pro Windows

« kdy: 26. 05. 2018, 17:37:29 »

Zkuste nejdřív hello world s použitím vlastní hello world knihovny - přeložit si jednotlivé fáze na linuxu ručně, zkusit knihovnu slinkovat staticky, dynamicky, výsledek nainstalovat, spustit statickou i dynamickou verzi, podívat se, na jakých dynamických knihovnách spustitelná binárka závisí. Až to budete mít tohle prošlapené na linuxu, zkuste to samé pro windows třeba s mingw nebo cygwin, možná dnes další možnosti, nemám tušení. Záleží, jestli jen ten prográmek „linuxový“ a chcete ho jen spustit na windows anebo zda v linuxu vyvíjíte prográmek, který závisí na nějakém windows api nebo na windows knihovně. Takže ideálně by to chtělo vidět ten program nebo alespoň adekvátní příklad (pokud dokážete zhodnotit, co je v daném případě adekvátní).

Omlouvám se obecnou odpověď, ale nechce se mi vymýšlet konkrétní příklady když nevím, zda se trefím do vaší situace. Hlavní poselství příspěvku je, že nemůžete moc rozumět crosscompilaci, když nemáte v ruce normální kompilaci. Jděte na to postupně, je ti IMHO docela zábavné.

913

Desktop / Re:Názor na Gnome Photos a Gnome Documents

« kdy: 21. 05. 2018, 22:31:04 »

A kde je problém si vyznačiť fotky napríklad od 1.7. do 14.7. Tunis a kliknúť na album?

Proc delat veci navic? Mam adresare a aplikaci ktera je prochazi a nemusim nic vyznacovat. Stejne, jednotlive soubory ma smyslplne pomenovane malo kdo tak ze vyhledavani - hlavni vyhoda knihovem nefungune.

Proč by to měla být práce navíc? Stáhnu si fotky do počítače a místo, abych je dával do jednoho adresáře "Tunis", je jedním úkonem otaguju "Tunis". Výsledek pro vyhledávání a zobrazení je ten samý. Výhoda databáze oproti adresářové struktuře je v tom, že těch pohledů tam můžu mít řadu (vlastní tagy, informace z EXIFu,...). Nevýhoda potom v tom, že ty informace nejsou často přenositelné mezi programy, a taky v tom, že pokud člověk doteď žil na adresářové struktuře, tak to zorgazovat vyžaduje nějakou energii, pokud ten software nebere názvy adresářů automaticky jako atribut fotky.

Prace navic to rozhodne je, a v pripade klihoven ktere jsou nekompatibilni casto i zbytecna. Nekolik let budu budovat knihovnu abych zjjstil ze soft konci a zacinal znovu?

Pak nechapu vyznam otagovani celeho adresare fotek nebo pouzivani jmena adresare jako atributu? fotek. Ceho tim dosahnu? Pri takhle obecnem popisu nema klihovna vyznam protoze ji stavis na uroven adresaroveho prochazeni.

Zatim nevidim v knihovne pro fotky zadnou vyhodu. Snad kdyby se jednalo o fotobanku ... mozna. Ale u cloveka co se chce podivat na fotky z dovolene to nedava smysl. V cem je rozdil jestli budu v knihovne hledat island 2018 nebo otevru chlivek island 2018?

Tak ideálně ten katalogizační software zapíše metadata přímo do EXIF dat těch fotek, takže půjdou použít i při změně softwaru. V praxi to tak ideální není, protože způsobů jak zapsat uživatelská data do EXIFu je vícero a myslím, že úplně standardizované to není.

Pokud katalogizaci nepotřebujete, tak ji nepoužívejte, stačí pak úplně jednoduchý prohlížeč fotek a náhledy ve správci souborů. Pak je asi nejlepší se Gnome Photos zbavit (což předpokládám lze).

914

Desktop / Re:Názor na Gnome Photos a Gnome Documents

« kdy: 21. 05. 2018, 19:34:56 »

A kde je problém si vyznačiť fotky napríklad od 1.7. do 14.7. Tunis a kliknúť na album?

Proc delat veci navic? Mam adresare a aplikaci ktera je prochazi a nemusim nic vyznacovat. Stejne, jednotlive soubory ma smyslplne pomenovane malo kdo tak ze vyhledavani - hlavni vyhoda knihovem nefungune.

Proč by to měla být práce navíc? Stáhnu si fotky do počítače a místo, abych je dával do jednoho adresáře "Tunis", je jedním úkonem otaguju "Tunis". Výsledek pro vyhledávání a zobrazení je ten samý. Výhoda databáze oproti adresářové struktuře je v tom, že těch pohledů tam můžu mít řadu (vlastní tagy, informace z EXIFu,...). Nevýhoda potom v tom, že ty informace nejsou často přenositelné mezi programy, a taky v tom, že pokud člověk doteď žil na adresářové struktuře, tak to zorgazovat vyžaduje nějakou energii, pokud ten software nebere názvy adresářů automaticky jako atribut fotky.

Tohle má smysl ale jen jako rozšíření adresářového přístupu. Snad nikdo nenahrává fotky do jediného obrovského adresáře, ale dává je spíš do nějakých podadresářů. Katalogizační software mu pak s těmi fotkami umožní pracovat dalším způsobem, což je samozřejmě výhoda té katalogizace. Ale ta pokud neumožní pracovat s umístěním na disku, je něco špatně, protože pořád existuje řada postupů, které jsou na fyzickém umístění založené (zálohování, posílání mailem, předání externímu softwaru...).

915

Desktop / Re:Názor na Gnome Photos a Gnome Documents

« kdy: 18. 05. 2018, 17:07:38 »

Není to náhodou inspirací u Google Photos? Podle mě je plochá struktura s vyhledáváním dobrý koncept, pokud ovšem umožní pohodlné hledání dle tradičních kritérií (adresář, název souboru).