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 - Ondrej Nemecek

Stran: 1 ... 18 19 [20] 21 22 ... 90
286
To je úplná hloupost. Naopak chci jako profesionál mít možnost vše konfigurovat z jednoho místa. Jedna úprava a stroj má adresu, jakou si přeji. Ze správné VLAN, kterou musím stejně z jednoho místa nastavit. Vy se bavíte o nějaké garážovce.

Slriptovat rutinní činosti není špatná ale dobrá praktika. U nás ve firmě, stovky pc, pravděpodobně přes tisíc strojů, mají všechny statickou adresu.

Podle toho, co máte na mysli. Běžná správa se scriptuje, ať už na Linuxu, nebo na Windows - resp. tam přednostně přes politiky skupin. Fungovat na statických adresách lze, ale má to své nevýhody. Podobně jako auto bez klimatizace: nemůže se sice porouchat, levněji se servisuje - ale nechladí.

Ve Windows Home jsou nástroje pro správu skupin zrušeny. Ono je to naopak, s dhcp nějak fungovat jde, prí laiky je to dobrý nástroj, protože se jim to nějak samo nastaví a nějak to většinou funguje (i když jsem si tedy užil se síťovým AVR, NAS a DLNA, které začlo být v domácnosti spolehlivé právě až po nastavení statických adres), ale pokud je síť spravovaná profesionály, kteří tomu rozumí, je jednodušší mít předvídatelné pevné/statické nastavení než náhodné dynamické.

Přesně tak, dhcp umí přidělovat statické adresy.

287
Vývoj / Re:Trait a konstruktor
« kdy: 21. 12. 2020, 15:10:59 »
im, ze je tam rozdil, ale nevidim ze by u toho traitu ta zavislost byla mene priznana.

Podle mě ses zaměřil na obecný význam slova "závislost", ale ne na skutečnou funkci DI třeba v tom konstruktoru. Trait řeší chování celé třídy (typu), DI rozhoduje o situaci či chování konkrétní instance.

Přesně. Navíc DI je zpravidla runtime kdežto traity compile time. Někdy potřebujeme to a jindy ono.

288
Vývoj / Re:Trait a konstruktor
« kdy: 20. 12. 2020, 22:07:52 »
Souhlas, že traity a DI jsou částečně zastupitelné přístupy. Vhodnost jednoho či druhého záleží IMHO na okolnostech.

289
Příkazová řádka mi přijde jako jeden z nesrozumitelnějších a nejsprávnějších přístupů, jak ukázat funkce počítače. Dialog otázka - odpověď v terminál session je názorná a analogická reálnému světu, nepoutá pozornost barvičkama a nesmyslama, které v podstatě pouze vtahují do klamavého virtuálního světa. Počítač je stroj a dítě ho má primárně jako stroj chápat.

Nejsem si tímto tak jistý. Ono je fajn, že vím, jak pracuje spalovací motor, je i fajn, že jsem různé motory v dětství "poladil" - od mopedu až po stabilní motor. Ano, dá se tak trochu víc rozumět tomu, jaká technika je v hloubce. Ale potřebuje to opravdu každý? Dnes řidičům nic neříká svíčka, zapalování, předstih - ani by tyto pojmy nepochopili, dokod by někde neviděli vačku, rozdělovač... A k čemu taky? U dnešních aut nevyřešíte svépomocí ani nesvítící světlo - ale taky to světlo odejde až po pěti, šesti letech, a ne dvakrát do roka, co pamatuju.

S IT je to stejné - stává se z toho naprosto okrajový obor, jako z autoprůmyslu. Ti, kteří pro to budou mít vlohy a zájem, cestu si najdou. I tak jich bude víc, než je potřeba. Zbytek ajťáků budou oprašovači, stejně jako se z automechaniků stali výměnáři dílů.

Právě že pokud nechcete, aby byli z lidí ti oprašovači nebo podlehli zcela digitální demenci, je nutno jim od začátku rozšiřovat vědomí. Čili ta logika je podle mě přesně opačná: Nemusím se podřizovat obecnému trendu, mohu si vědomě udržovat částečný odstup a samostatnost alespoň v myšlení. To je IMHO důležité ve všech oblastech života :-) Ale je to věc osobního vkusu a rozhodnutí. Jinými slovy, je na rodiči do jaké školy svoje dítě dá...

290
Ahoj,

pracuji na malé škole, máme Linux, a to jak pro učitele, tak pro děti. Důvodů je spousty, jak pro, tak proti, ale podle mne je jeden velmi důležitý, a to, že děti mají možnost poznat alternativu. Microsoft se snaží jak může uvrtat lidi pouze pro Windows (což chápu), ale je důležité mít nadhled i informaci, že existuje i jiná možnost. Jako hezký příklad je i Microsfot Teams a Google Calssroom. Ten první můžete provozovat pouze a jenom na Windows, ten druhý jen přes prohlížeč,a  to je mému srdci blíže.

D

Třeba moje děti (4 třída ZŠ) nemají problém s příkazovou řádkou. Příkazová řádka mi přijde jako jeden z nesrozumitelnějších a nejsprávnějších přístupů, jak ukázat funkce počítače. Dialog otázka - odpověď v terminál session je názorná a analogická reálnému světu, nepoutá pozornost barvičkama a nesmyslama, které v podstatě pouze vtahují do klamavého virtuálního světa. Počítač je stroj a dítě ho má primárně jako stroj chápat. Děti nemají problém poslat mail, vyhledat něco na internetu, tam používají GUI, ale didakticky dává smysl jít od příkazové řádky.

291
Vývoj / Re:Trait a konstruktor
« kdy: 20. 12. 2020, 01:34:06 »
V první otázce zní: Nezneužívat dědičnost, radši na to vzít traity. Já říkám: Ale já vidím kompozici, k té traity nepotřebuju. Odpověď: V kontextu OOP je to jinak. Tak jak je to? Co je trait?
To máš buřt.

Abych nebyl za kverulanta, já bych prostě inicializoval v konstruktoru, kde bych volal konstruktor traitu. Nebo je myšlena nějaká automatická inicializace? Asi nerozumím té otázce. Je to otázka po syntaxi, sémantice, runtime? Všechno je možný - můžu inicializovat aspektem, anotací...

Takhle?:
Kód: [Vybrat]
class Foo {
    use A;
    use B;
    public constructor(int id, string name) {
        A.constructor(id);
        B.constructor(name);
    }
}

Asi nerozumím té otázce. Je to otázka po syntaxi, sémantice, runtime? Všechno je možný - můžu inicializovat aspektem, anotací...
Syntaxe.

Jak tyto vlastnosti inicializovat, případně když ta inicializace má nějakou komplexní logiku. Proč by to měl být problém souvisí poněkud s tím, že ty fieldy z traitu jsou privátní, mají nějaký provázaný stav, který by si měl hlídat ten trait.

Jo, jestli jde o syntax, líbí se mi to jak to uvádíš výše. Všechnu logiku bych dal do konstruktorů jako programový kód, IMHO to je nejčitelnější. Co se týče chování, nedělat bych tam žádnou automagii, to se vyplatí až při násobném použité té magie. Co se týče čitelnosti traitu a srozumitelnosti z čeho je výsledný objekt poskládaný, tak podle mě mají traity smysl právě tehdy, když je nemusím moc číst. Já mám traity třeba WithLogger, WithImages, WithRelations apod. kde právě dělám kompozici. Ten trait přidává jednu jednoduchou pochopitelnou vlastnost (logger, obrázky...). Výhoda je samosebou znovupoužitelnost spojená s flexibilitou. Takže pokud mám nějaký objekt a k němu chci obrázky, tak jen připojím trait. Přidám jedno slovo a je hotovo. Razantně lepší než dědičnost, citelně lepší než kompozice. Pokud pak v objektu intenzivně metody traitu používám a chci jeho chování zase odstranit, stačí trait odpojit a opravit chyby kompilátoru. Zase lepší než dědičnost a srovnatelné s kompozicí.

292
Vývoj / Re:Trait a konstruktor
« kdy: 19. 12. 2020, 01:34:00 »
V první otázce zní: Nezneužívat dědičnost, radši na to vzít traity. Já říkám: Ale já vidím kompozici, k té traity nepotřebuju. Odpověď: V kontextu OOP je to jinak. Tak jak je to? Co je trait?

Abych nebyl za kverulanta, já bych prostě inicializoval v konstruktoru, kde bych volal konstruktor traitu. Nebo je myšlena nějaká automatická inicializace? Asi nerozumím té otázce. Je to otázka po syntaxi, sémantice, runtime? Všechno je možný - můžu inicializovat aspektem, anotací...

293
Vývoj / Re:Trait a konstruktor
« kdy: 18. 12. 2020, 20:45:10 »
V Rustu, pokud vím, trait nemá fieldy. Proč je tam potřebuješ mít, patří tam vůbec?

Předpokládejme, že ano.

Motivace traitů, tak jak o ní v tomto vlákně mluvím, je komponovat "objekt" z částí. Tedy něco na co se zneužívá dědičnost, ale bez nevýhod dědičnosti.

Eee?! Tomu co vidím tady https://forum.root.cz/index.php?topic=24024.msg341967#msg341967 se říká kompozice a traity k tomu nepotřebuju. Traity mi k objektu přimíchají další chování aniž bych si musel uložit do fieldu jejich instance.

Nebo mi něco uniká?

Souhlasím, že construktory by měly být součástí rozhraní. Vlastně bych kostruktory nejradši zrušil a zavedl místo nich kategorii pro faktory metody a těm umožnil být (volitelně) součástí do rozhraní/traitu. Fieldy mi v traitech nevadí.  S dynamických dispatch by to byl super jazyk.

Pragmaticky a přitom docela dobře to má udělané Groovy http://docs.groovy-lang.org/next/html/documentation/core-traits.html

294
Windows a jiné systémy / Re:Mini-posix knihovna s Win32 API
« kdy: 18. 12. 2020, 20:34:06 »
Mingw a cygwin jsou tradiční možnosti. Proč nevyhovují?

295
Osobně nevidím důvod, proč popsané principy nepoužít i při výuce IT.

Já ano.

IT je už velmi složitá oblast, nedá se ani řádově srovnat se složitostí, jakou jsme zažívali v devadesátých letech. Tenkrát si člověk mohl vybrat (z toho, co bylo trochu dostupné) DOS, DESQview, Windows 3.x, později Windows 95, OS/2, NT, SCO, Mac a Linux. Kouzlo bylo v tom, že se řešily poměrně triviální úlohy a postupy k jejich řešení byly plus minus obdobné jako v některém dalším ze systémů.

Podle mě říkáte pouze tolik, že se mají učit jak praktické dovednosti tak koncepční. A že ty koncepční jsou náročnější na výuku. To nikdo nerozporuje.

V devadesátých letech se v IT obecně (!) určitě neřešili jen triviální úlohy. Naopak se řešily věci, které vedly pak k současnému stavu (protože se rodily ty složitější technologie). Jde právě o ten úhel pohledu, zda se koukáme do domácností nebo k otcům technologií. Ale to je jedno, své jsme řekli a nemá cenu živit vlákno dalším textem (za mě alespoň).

296
To je zase snůška názorů.

Ne, to je pluralita, víme? :)

MS je všude protože má schopný marketing.

Což patří k jakémukoliv produktu, a což stálo za prakticky každým vynálezem, který dnes běžně používáme. Naopak spousta zajímavých nápadů ve své době zapadla, protože je nikdo neuměl prodat.


Že někdo něco zažil (jak argumentují někteří diskutující) ještě neznamená, že stávající stav je jediný možný.

Pochopitelně. A všichni se těšíme, co budoucnost přinese. Lišíme se v tom, že někdo by rád alternativy tlačil (třeba i do škol), a druhý by raději, aby si vybrali lidé sami a do škol se dostávalo to, co se používá.

Ve školství má být pluralita od začátku, protože formuje vnímání a myšlení lidí. Uniformita vede k omezenosti. Proto bych s tím začal od mala, ne až na vysoké.

Škola musí nejprve rozvinout základy a teprve pak přidávat prvky diverzity. Představte si, že by učitel matematiky učil - kvůli oživení výuky a diverzitě - třeba v šestnáctkové soustavě. Pomohlo by to žákům? Vždyť desítková soustava není jediná možná cesta... Nojo, jenže co by si pak žáci počali v obchodě při placení, nebo jak by na učivo navazoval učitel fyziky? S těmi IT technologiemi je to stejné: potřebujete naučit nejprve Windows, pak Mac a pak jako oživení Linux. Nic proti tomu, zasívat do omladiny semínka něčeho nového, ale nedávejme alternativním směrům neúměrnou váhu. Např. Linux má už startovací pozici dobrou, už to není outsider, o kterém si každý myslí, že je to jen hračka pár nadšenců (tak to bylo v devadesátých letech).

Ohledně pedagogiky - právě že jsou směry, které učí jiné soustavy hned od začátku. Nenásilně, jde o propracovaný systém. Má svoje slabá místa, ale je to funkční a široce používané - koukněte na Hejného metodu. Ono vědomí člověka není lineární, mnoho věcí se člověk učí nejdříve nevědomě (podvědomě), pak to prochází různými fázemi až (v ideálním případě) k vědomému rozumovému uchopení. Takže zkušenost a dovednost probublává jednotlivými vrstvami vědomí podle toho, jak se jednotlivé vrstvy úměrně věku vyvíjejí. Například počítání souvisí s rytmem, který i ve složitých variantách nemá problém vnímat a opakovat i malé dítě (v rytmicky orientovaných kulturách lze ilustrovat). Tuto nevědomou dovednost lze pak přetransformovat až do početních operací. Podobně geometrické vnímání, smysl pro řeč.  Uvedený fakt je podrobně popsán u vývoje pohybu a řeči (psychomotorický vývoj) nebo při učení jazyků.

Dítě se učí jazyk naráz v celé komplexitě, pouze jeho užití přichází postupně od jednoduchého užití ke složitému. Takže známé Komenského pravidlo „od jednoduchých věcí ke složitým“ platí pouze na dané vrstvě vědomí, kde dochází zrovna k osvojování. Ale současně platí, že při bohaté zkušenosti a dovednostech na nižších vrstvách vědomí je potenciál dítěte v pozdějším věku mnohem širší. Tvůrčí prostředí musí být pestré a školy by měly vést ke kreativitě. To zahrnuje i práci s podněty tak, aby nebylo dítě zahlceno (potenciální problém různých alternativ).

Shrnul bych to tak, že podněty mají být široké, jejich uvědomování postupné a s ohledem na individuální vývoj jednotlivce.

Samozřejmě, učitelé si musí volit metodu, kterou mohou zvládnout a ke které mají vztah. Je lepší konvenční metoda a dobrý učitel než alternativní metoda kterou učitel nezvládnul. Ale jsou to propojené nádoby.

Osobně nevidím důvod, proč popsané principy nepoužít i při výuce IT.

297
Je to jednoduché na použití. U Linuxu (možná teď už ne, stará zkušenost) na 90% potřebujete znát jakési divné příkazy i k nejjednoduchším operacím. Když něco nefunguje u Windows máte vysokou šanci, že to vygooglujete i v češtině. U linuxu kdysi dávno byla odpověď na všechno RTFM. Když jste to z návodu nepochopily a chtěli jste ať to někdo chytřejší přeloží do srozumitelné řeči odpovědí bývalo , RTFM , vrať se na Windows apod. . Když používám auto taky nemusím být automechanik. A tak to dopadlo. Všude jsou Windows bo je lid žádá , nikomu se nechce něco kompilovat nebo podobné věci.
Ohledně Office , bohužel zase většina návodů odkazuje na MS Office. u Open Office nebo Libre Office sem tam něco nefunguje tak jak by mělo podle návodu třeba na Excel.

IMHO je komplexita opravdu srovnatelná. Používal jsem Linux, Max i Windows a neměl jsem dojem, že by jeden systém něco usnadnil víc než druhý. Odlišnosti byly v zaměření a přístupu, ale ne v komplexitě. Jinak řečeno, krásné řešení přebalené úhlednou červenou stuhou jsem nenašel. Řidičák byl na všechno. Českých zdrojů je obecně méně, s tím samozřejmě souhlasím.

298
To je zase snůška názorů. MS je všude protože má schopný marketing. Zejména dnes, kdy běží spousta věcí v prohlížeči, by ve spoustě případů na stanicích nemusel MS být. MS samotný to reflektuje a změnil strategii směrem ke cloudu, opensource a WSL. Že někdo něco zažil (jak argumentují někteří diskutující) ještě neznamená, že stávající stav je jediný možný. Ve školství má být pluralita od začátku, protože formuje vnímání a myšlení lidí. Uniformita vede k omezenosti. Proto bych s tím začal od mala, ne až na vysoké. Většina technologií stejně konverguje ke stejné komplexitě a stejným problémům, jak MS tak Linux tak Apple a další. Žádné zázračné řešení není. Nejvíc je k pláči ten celkový stav IT a technologií, ale nad tím momentálně nemá cenu filosofovat.

299
Vývoj / Re:Vlastní SSD caching pro klasické FS
« kdy: 16. 12. 2020, 16:42:40 »
Některé databáze běží nad holým diskovým oddílem bez FS. Tj. si FS implementují samy a v podstatě dělají to co popisujete. Akorát speciálně pro účel SQL. Ty implementace by šlo použít pro zhodnocení náročnosti a problémů, které to přináší.

IMHO by se to vyplatilo jedině při detailní znalosti aplikčaních dat, ty ale zná jedině aplikace sama. Také některé aplikace řeší cachování ve své režii. Například ty video editory. To je další kandidát na analýzu.

IMHO pro obecné použití je bcache dobrá volba a nic lepšího obecného nevymyslíte.

Tím nechci říct že to není zajímavý výzkumný problém třeba na diplomku. Ale chce se to nejprve seznámit s existujícími řešeními.

300
Odpověď je daleko jednodušší, než si myslíte. IT ve školách neslouží pouze k výuce IT, ale i pro obyčejnou práci. Pokud hledáte jakýkoliv pracovní nástroj, vždy hledáte optimální poměr mezi pořizovací cenou, cenou údržby, cenou zaškolení personálu (a žáků) a užitkem, který daná věc přinese. To platí pro hřebíky a kladivo, a platí to i pro software.

Až na to že školy jsou různého typu a ne všechny jsou praktického zaměření. Škola nejen připravuje na praktický život, ale má být i etablon úrovně a nezávislosti (v různých oblastech - lidské poznávání má být zcela svobodné). Tím se dost omezuje platnost shora uvedené argumentace.

Jak sám říkáte, na IT školách mohou zkoumat, proč se žárovka přepálí a pochybuju, že by tam nějak obdivovali MS technologie. Naopak, akademické prostředí by mělo představovat protiproud vůči mainstreamu. Obecně na technických školách by mělo být co nejširší povědomí o šíři všech možných technologií, schopnost ty technologie zhodnotit - tořádná škola by měla člověku otevřít oči pro šíři oboru.

Technologie velkých monopolních korporací přináší vždy zásadní problémy a nebezpečí. To by se mělo také učit. Je to holá pravda a je to dnes již veřejně diskutované téma. A bude to čím dál tím významnější téma, s řadou nevyřešených otázek (je technologie vůbec přínosná, pokud ji nelze diverzifikovat?).

Stran: 1 ... 18 19 [20] 21 22 ... 90