Příspěvky

616

Software / Re:Čím prohlížíte logy při ladění? A jak se vám líbí moje prohlížítko?

« kdy: 08. 08. 2019, 13:15:52 »

Používám http://glogg.bonnefon.org/

617

Odkladiště / Re:Nový OS

« kdy: 07. 08. 2019, 14:41:08 »

Já bych si představoval pokrok desktopových OS v jiných věcech. Konrétně by se mi líbilo přenést podobný princip jako je u textového rozhraní, kdy mohu kombinovat programy a předávat si mezi nimi data pomocí rour a vytvořit si tak program s vlastní funkčností. Není to nic nového, měl už to NextStep, OpenStep a něco takého má tuším i OS X, různé další OS to také mají, snažil se o to Etoilé OS, Smalltalk se tomu také dost blíží, KDE má třeba svoje KParts apod. Ale není to masově užívané a funguje to vždy jen pro omezený ekosystém. Mě by se líbilo, pokud by to bylo něco univerzálně rozšířeného.

Viz též debaty tady u  těchto, tří, blogů od Bystroushaaka.

Příklady: Mám program na úpravu obrázků (Darktable), z něj používám celkem asi 10% funkčnosti a z toho asi 2% pravidelně na jednotlivé obrázky. Líbilo by se mi, pokud by Darktable exportoval služby tak, abych je mohl volat přímo ze souborového manažera nebo abych si zobrazil jen určitý widget z Darktable a mohl jeho funkce aplikovat na vybraný obrázek. Nemusel bych tedy pracovat s celým UI Darktable a možná by ani nemusel startovat celý Darktable kvůli tomu, že chci vyvážit bílou barvu u jednoho obrázku.

Další typický příklad je spellchecker, který bych mohl aplikovat na libovolný text, nebo služba na  převedení velikosti písem či překlad textu. Kdekoli v UI bych mohl označit text a aplikovat na něj tuto transformaci.

Takové funkce bych si mohl zkombinovat tak, aby to ideálně zapadlo do mého vlastního workflow.

Bohužel, je to zřejmě minoritní část uživatelů, kteří by to dokázali využít. Stejně jako málokdo ocení kvality vimu, málokdo by asi docenil toto. Světu vládne průměrná většina (říká se tomu demokracie a nic lepšího se asi nenašlo, leč to vede k té průměrnosti...). Jedině že by to využívali vývojáři, kteří by to pak zpřístupňovali uživatelům. Jako má třeba GNU Radio bloky, tak by někdo mohl vytvářet aplikační bloky a propojovat je. Jádro systému atd. by mohl být konvenční linux. V tom problém nevidím, ani zásadní úskalí. Dělat vše od začátku - to jedině jako nějaký akademický projekt pro ověření nějakých tezí.

Ale jak říkám, moc šancí něco takového prosadit nevidím. Navíc to má některá úskalí (rychlost, bezpečnost, nutnost standardizace protokolu atd.) Ale někdy ve vzdálenější budoucnosti, kdy bude vše mikroslužba, to asi přeci jen prorazí. Ten trend je bezpochyby tímto směrem. Po desítkách let se - možná - některé ideje „otců zakladatelů“ uskuteční.

618

Vývoj / Re:Jak ve frontendu okamzite reagovat na udalost na backendu?

« kdy: 03. 08. 2019, 16:13:02 »

Požadavek na straně serveru musí počkat, dokud si ho konkrétní klient nevyzvedne. Tím je problém odstraněn a hluché místo tím pádem nebude na klientovi vadit. Takže na serveru doplnit synchronizovanou frontu (jak bylo řečeno) a registrovat klienty. Timeout na klientovi se dá myslím zrušit. Pokud je potřeba pooling na klientovi v určitý okamžik přerušit, tak počkat na odpověď serveru a vykonat prázdnou akci a další pooling už neiniciovat.

Jinak existují js knihovny, které tohle celé řeší a odstiňují od implementačních rozdílů v prohlížečích (teď si nevybavuji, socket.io vyžaduje node, to asi není ono). Například pokud prohlížeč neumí websockety, použije se long pooling. Co se týče websocketů, on se ten socket taky může zavřít a je třeba to řešit, ne? Takže tam je trochu režie s tím, navíc takové mobilní připojení apod. přináší výpadky připojení apod. Nic co by chtěl člověk mermomocí řešit, pokud to není téma které ho apriori zajímá. Radši bych použil knihovnu na bezpečné asynchronní posílání zpráv mezi backendem a frontendem.

Hodně štěstí :-)

619

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

« kdy: 03. 08. 2019, 12:40:18 »

Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.

Podle mne je to tím, že přístup k syntaxi je v Groovy je přesně opačný než v Javě. Java je založená na tom, že každá věc se dělá právě jedním způsobem, takže když dva programátoři budou psát totéž, napíšou stejný kód. (Samozřejmě to neplatí úplně stoprocentně, ale v Javě je tenhle rys hodně silný.) Groovy naopak dává programátorovi spoustu možností, jak napsat jednu a tu samou věc. Takže když píšu nějaký kód, můžu ho napsat přesně tak, jak by se mi to líbilo. Problém ovšem je se čtením takového kódu. Groovy mi tímhle připomíná Perl… Jako skriptovací jazyk je Groovy super, closures zavedl dávno před tím, než měla Java lambdy, ale ta rozvolněná syntaxe je podle mne pro lidi zvyklé na Javu spíš matoucí. Je otázka, zda by se Groovy neuchytilo třeba spíš u lidí zvyklých na JavaScript.

Máte nějaké příklady (nejsem Groovista)? Mě se líbí ta nulová bariára Java -> Groovy (Groovy používám na skriptování).

620

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

« kdy: 03. 08. 2019, 12:30:53 »

Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.

Zbytecne, naco, proc by to nekdo mel chtit delat? to uz mi prijde lepsi nez Groovy Typescript. To uz bych se radeji naucil Python nez Groovy.

Mohl by to chtít dělat, protože je mu java příliš těsná a chce featury, která java nemá. Třeba ty lepší traity.

621

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

« kdy: 03. 08. 2019, 12:27:08 »

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 (?)

Měl jsem na mysli, že bude skupina praktiků kteří budou řešit praktické problémy a volba jazyka pro ně bude víceméně vedlejší věc a pak tu bude skupina teoretiků či akademiků, kteří budou jazyky studovat případně vyvíjet nové. Potřebné jsou obě skupiny - dospělostí bych se neoháněl (byť v mládí člověka skutečně zpravidla zajímají ideály a v pozdějším věku víc praxe, nicméně ani to není 100% pravidlo).

622

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

« kdy: 02. 08. 2019, 23:42:23 »

Překvapuje mne vlažné rozšíření Groovy. IMHO jakýkoli javista může začít psát v Groovy a postupně adoptovat jeho vylepšení oproti javě. A přitom je to jvm jazyk.

623

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

« kdy: 02. 08. 2019, 16:00:56 »

Proč by měla být kopírka potomkem tiskárny a skenneru? Kopírka je kompozitní zařízení, které uvnitř obsahuje obojí, ale rozhodně není přímým potomkem ani jednoho. Zřejmě implementuje spoustu společných rozhraní (Má napájení, má uživatelské rozhraní, atd.), ale implementace je úplně jiná. Navíc "umí tisknout" (jako tiskárna), "umí skenovat" (stejně jako skenner). Tiskárna i skenner jsou v kopírce od vnějšího světa odstíněné vrstvou kopírky. Všechno z toho lze rozpadnout do malých rozhraní, ale přímá dědičnost je rozhodně špatně. Možná to tak vypadá na první pohled, ale až by se autor dostal na detaily, zjistil by, že to v reálu dědičnost není. A každé nesprávné namodelování skutečnosti se u živého projektu jednou vymstí a bude se muset předělat. A tam nastoupí typová kontrola javy a předělání bude celkem bezbolestné a bezpečné, pokud se nepoužily nerefaktorovatelné techniky (reflexe a spol.).

Takže můžete ty kompozitní části buď přímo vystavit  a pak je přímo voláte - copier.getScanner().scan() - anebo je schováte za rozhraní a voláte copier.scan() Druhý způsob lépe zapouzdřuje, ale přidává nějaký režijní kód navíc, kde se budou interně nejspíš jen volat metody kompozitu. V „opravdovém“ OOP by stačilo metodu přeposlat.

Při použití traitů můžete navíc, pokud jsou dobře navrženy, funkčnost skeneru přidat pouhým připojením toho traitu - s minimální nutností něco implementovat, protože sdílená funkčnost může být v tom traitu už implementovaná. Nově se bude implementovat například jen hardwarově závislá část, který zajistí získání InputStreamu apod. Zpracování a operace nad těmi daty bude v traitu. To samé pro tiskárnu. Stále při zachování toho, že kopírka nemusí dědit z tiskárny a skeneru. Pokud to shrnu, trait je v porovnání s dědičností flexibilnější způsob sdružování implementace do balíčků.

624

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

« kdy: 02. 08. 2019, 15:41:41 »

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).

625

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

« kdy: 02. 08. 2019, 15:37:13 »

Odkaz 1) Java - chybí rozumně udělaná kompozice (tj. vícenásobná dědičnost). Autoři Javy to samozřejmě ví a snaží se "tunit" interfacy, ale dokud v něm nebude interní field a protected metoda, je to pořád napůl.

(...)

Pevně věřím, že se rozhraní v javě postupně změní na variantu traitu. Již to tak pár let od zavedení defaultních metod používáme, ale citelně chybí fieldy a protected default metody, aby se nenafukovalo API.

Přesně tak, rozhraní může být přeci i interní, kéž by to už v javě bylo! Omezení na veřejné metody v rozhraní mi přijde dost umělé a nesmyslné. IMHO by úplně stačilo mít vícenásobnou dědičnost s tím, že by rozhraní jen kontrolovalo přítomnost metod a nic jiného nenabízelo. Tak to ale v javě nebude, to je jasné. Místo toho se namísto tříd začnou víc používat rozhraní. Trochu absurdní řešení, ale dá se s tím asi žít.

Každopádně když jsem začal používat rozhraní s default metodama (traity) dalo mi to větší flexibilitu a svobodu, ale zároveň lepší konzistenci. Je to tak trochu lék na nadužívání hiearchie tříd a nepřítomnost vícenásobné dědičnosti. Ale ve stávající podobě to stále není kompletní.

626

Software / Re:Tvorba semestrálek a problémy s kompatibilitou Office, praktická zkušenost

« kdy: 31. 07. 2019, 22:47:00 »

Existuje nějaká v praxi používaná alternativa? Je s podivem, že po ní není větší poptávka. Prostě to, co (skoro) umí Word, ale tak nějak lépe a robustěji a bez nesmyslů okolo. Něco jako DocBook (či LaTex) ale víc pro laiky. A něco k tomu pro správu dokumentů, verzování, diff, prohledávání. To přece de fakto potřebuje prakticky každá kancelář? Opravdu to každý bastlí v MSOffice? Mám na mysli celosvětové měřítko.

627

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

« kdy: 30. 07. 2019, 16:09:37 »

Kdyz se na to podivam ocima stredniho managementu tak java je skvela:
1. I juniora snadno prodam zakaznikovi jako seniora, protoze to vypada, ze neco dela => vic penez pro me
2. vsechno trva dlouho => v pripade kontraktu typu "cas a material" vic penez pro me
(...)

  Jedním slovem: Enterprise a neomezoval bych se jen na javu.

Teď ještě napsat podobný bonmot na javascript. Někde jsem viděl vtipný text co zažije js nováček, nebyl to nějaký komix? Nemohu najít...

628

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

« kdy: 30. 07. 2019, 09:58:12 »

Zrovna u javascriptu mají frameworky leckdy jepičí život, ekosystém se taky dost mění. Pokud se tomu člověk věnuje na 100% procent, tak to asi nevadí, protože sleduje trend. Jako bokovka se to ale moc nehodí, režie se sledováním hype je značná.

To je třeba důvod, proč může být pro dost projektů java atraktivní. Spojuje progresivitu se stabilitou. Člověk si vybere jvm jazyk podle toho, jaké featury chce v jazyce mít, využije bohatý ekosystém, knihovny atd., zkompiluje do bytekódu a spustí nad jvm. To funguje už dnes. Pokud dozraje Graalvm budou možnosti ještě lepší. Je sice pravda, že s modulární javou se taky spousta věcí rozbilo, ale obvykle stačilo přidat pár přepínačů a funguje to dál bez dalších změn.

629

Vývoj / Re:Váš názor na kombinaci nekolik technologii.

« kdy: 29. 07. 2019, 18:43:30 »

čakal som takú reakci, ale že tam povieš "vonavucke ... v jave" tak to ma odrovnalo, Javu považujem za nejhorší a nejvíc humusácky jazyk vůbec.

Připojuji se a podepisuji v plném rozsahu .
Ještě jsem nepotkal produkční ani neprodukční Java aplikaci, která by nedumpovala na paměť .

Pro mě je Java synonymem žumpy.

Což je ve vláknu o Eletronu dost vtipný komentář Eletron není moc krásná technologie a nenáročná na zdroje také úplně není. Ale chápu že zážitky z EJB a Jbossu se jen tak nezapomínají a staly se jaksi součástí koloritu, takže se nesmí propást žádná příležitost si zašpičkovat na téma java a paměť.

IMHO ony ty technologie mírně konvergují, paměťová náročnost Qt aplikací, Electron aplikací a JavaFX aplikací je dnes často srovnatelná, tj. poměrně vysoká. Komfort vývoje bude pravděpodobně také srovnatelný. Ostatní ekosystém se liší a podle něj by si měl tazatel vybírat - dle vlastních preferencí.

To je ale jen takový pokec.

Pokud mám mít nějakou věcnou a praktickou připomínku, tak snad jedině že doporučuju v každém prostřední nejdřív projít konvenční cestu a pak teprve zkoušel alternativu (v podobě gotron apod.) Protože bez zkušenosti se standardem nebude mít dotyčný na alternativu náhled a nezjistí, zda a jaký má potenciál či problémy. Ale chce to hodně času.

Jinak bych se spíš ptal přímo uživatelů těch systémů, na root se moc konkrétních připomínek tazatel asi nedočká.

630

Odkladiště / Re:Pripojky dilny na zahrade

« kdy: 23. 07. 2019, 13:45:46 »

Ad dotaz k sitovce: je tam jen oddelovaci transformator (viz napr http://www.farnell.com/datasheets/78237.pdf ).

Tak pardon za dezinformaci, musel jsem si to s něčím splést. Podle počtu nabízených „Opto-Isolators for ethernet“ tam fakt bude asi jen trafo.