Příspěvky

3286

Vývoj / Re:Unzip v Javě skoro tak rychlý jako 7zip?

« kdy: 09. 06. 2018, 07:48:56 »

jakto že je to sakra skoro tak rychlé jako v céčku psaný 7zip?

Proč by to tak rychlé být nemělo?

3287

Odkladiště / Re:Czechpoint nema validni certifikat

« kdy: 08. 06. 2018, 23:15:45 »

CzechPoint nejsou datové schránky. Informační web CzechPointu je na http://www.czechpoint.cz (ano, bez HTTPS). HTTPS na serveru je určené jen pro přihlášení uživatelů, kteří se přihlašují certifikátem. Datové schránky mají informační web zde: https://www.datoveschranky.info/

Neexistuje nic jako „obecně důvěryhodné autority“. Seznam důvěryhodných autorit si můžete sestavit jaký chcete – asi máte nějaký přednastavený od výrobce prohlížeče nebo operačního systému, ale to, že nějaká autorita není na vašem seznamu, není chyba té autority.

Certifikát PostSIgnum můžete ověřit jako jakýkoli jiný certifikát certifikační autority – získat jeho otisk bezpečným kanálem. Například si ho můžete ověřit na webu Ministerstva vnitra – PostSignum je kvalifikovaná autorita dle eIDAS. Certifikáty vydané kvalifikovanými autoritami mají platnost danou zákonem, důvěryhodnější autority v EU nenajdete. Komerční autority třeba z USA můžete mít mezi důvěryhodnými v prohlížeči, ale z hlediska práva nic neznamenají – když udělají chybu, maximálně řeknou „sorry“ a nic se neděje.

3288

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

« kdy: 07. 06. 2018, 07:24:54 »

Metoda send(cíl) prostě odešle data do cíle - zavolá metodu cíl.send(data). Pokud nemám gettery, tak to vlastně ani jinak nejde.

A jak taková metoda send(cíl) zapadá do oblasti zodpovědnosti objektu User? Jak už jsem psal, takových metod může mít objekt stovky – aby vytvořil unikátní identifikátor instance, aby se hezky vypsal, aby se zvalidoval, aby vrátil svou velikost v paměti…

3289

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

« kdy: 06. 06. 2018, 22:05:43 »

Ve všech případech to říkám nějaké proxy: database, email, validace, tisk...

Ne, ve všech případech to říkáte objektu User (posíláte mu zprávu „send“). A těžko pokryjete vše, co lze s objektem User dělat, jednou službou send s jedním rozhraním.

3290

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

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

To přece neříkám přímo emailu nebo databázi, ale nějakým proxy, které tento úkon udělají.

Pokud má objekt User službu „ulož se“, neříkám to žádné proxy, ale přímo tomu objektu User. A ten objekt musí vědět, že existuje nějaká proxy, která to uložení provede. Proč? Když budu chtít objekt User poslat e-mailem, budu muset jeho rozhraní rozšířit o „pošli se e-mailem“, což zase bude jen převolání nějaké proxy. To samé validace, tisk…

3291

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

« kdy: 06. 06. 2018, 20:25:45 »

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.

3292

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

« kdy: 06. 06. 2018, 20:22:04 »

Databázovou proxy můžeš do objektu injektovat stejně dobře jako logování nebo odeslání mejlu. Stačí, aby tyto služby měly stejné rozhraní. Objekt User vůbec nemusí tušit, komu ta data posílá metodou save().

Někdy to tušit musí, protože ta data k uložení budou pro každý způsob uložení trochu jiná.

Větší problém mám s tím, že to neodpovídá realitě. Já jako osoba o sobě vím, jak se jmenuju, umím to někomu říct. Ale do databáze evidence obyvatel se uložit neumím, k tomu musí přijít někdo z venku, kdo mne tam uloží (a obvykle se mne nejprve zeptá, jak se jmenuju).

Dědičnost sem však vůbec nepatří. Co bys tady chtěl dědit? User přece není ani Databáze, ani Soubor.

UserVDatabázi je User, stejně tak UserVSouboru.

3293

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

« kdy: 06. 06. 2018, 19:38:47 »

Ale já mám namysli konkrétní implementaci algoritmu, která provede uložení toho objektu User, a ta patří v každém případě jinam! Teprve potom totiž můžu ukládat do databáze, do souboru, nebo třeba do HTML. Právě tento princip např. Active Record porušuje.

Já si také myslím, že služba uložení objektu User nepatří do objektu User. Ale podle učebnicového OOP by právě do toho objektu patřila, a konkrétní implementace ukládání (databáze, soubor) by se řešila dědičností. Mimo jiné i proto, že v databázi bude mít uživatel asi nějaký identifikátor (primární klíč), který by User neměl nikam vystavovat, ale metoda pro uložení do databáze ho bude muset znát.

Jsem zvědav, co nám na to řekne Kit…

3294

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

« kdy: 06. 06. 2018, 19:28:48 »

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 už se ale nebavíme o OOP, ale o tom, že relační databáze a OOP jsou dva různé světy, mezi kterými nejde jednoduše mapovat, a už vůbec ne automaticky. Což je vidět na věcech jako JPA, které vedou k tomu, že nemáte dobře ani relační model ani OOP.

Ale já tu rozhodně „čisté“ OOP nehájím, ani nevím, jestli vlastně takhle bylo OOP myšleno, nebo jestli se tohle stalo z OOP až v učebnicích. Nemyslím si, že by se objekt User sám měl umět i uložit do databáze – je to porušení principu jedné odpovědnosti.

3295

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

« kdy: 06. 06. 2018, 19:12:42 »

Oddělení datové struktury, a "zpracovávacího mechanismu" (algoritmu) do jiné třídy, to je také "best-practice" v OOP

Nikoli, OOP je pravý opak, tedy spojení dat a s nimi souvisejících funkcí do jednoho objektu.

Jenže dnes se málokde programuje skutečně v OOP – spíš se používá strukturované programování s oddělením datových struktur a výkonného kódu, přičemž obojí (struktury i výkonný kód) je na úrovni programovacího jazyka implementován pomocí objektů. Často z toho vzniká zmatení, protože programovací jazyky obvykle mají jenom jeden typ objektů, takže na úrovni zdrojového kódu se nedá přímo rozlišit, co jsou struktury a co výkonný kód. Rozlišuje se to pojmenováním – datovým strukturám se říká třeba datové třídy, POJO, entity nebo přepravky, výkonnému kódu pak třeba služby. Ještě zřetelnější je to u vzdálených služeb, kdy výkonný kód je implementován jako služba na vzdáleném serveru, a ta služba na vstupu bere a na výstupu dává datové struktury, např. XML nebo JSON.

Akorát mi připadá, že to není moc teoreticky zpracované, protože programovací paradigma „datové struktury a vedle oddělený kód, který s nimi pracuje“ je podle mne považováno za obecné best-practice (ať už se tak programuje ve strukturovaném C nebo v objektové Javě), přitom pokud vím nemá ani žádné jméno. A to, že se ty datové struktury a služby interně implementují pomocí OOP podle mne taky nemá žádné jméno – přitom je to jen klasické zapouzdření, protože i u struktury je lépe definovat ji rozhraním, implementace uvnitř se ale může měnit; stejně tak služba, i bezestavová, často potřebuje mít uložena nějaká data.

3296

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

« kdy: 06. 06. 2018, 18:55:41 »

Jenže v modetě save() v Userovi se přece nemůže zpracovávat i Company a Address, to je kravina.

Také to tak v čistém OOP být nemá. Metoda User.save() má uložit stav uživatele – asi to bude znamenat i uložit nějaké vazby na Company a Address, např. jejich ID. A Company a Address zase budou mít své metody save(), které se postarají o uložení konkrétních objektů.

3297

Sítě / Re:Přesměrování na jinou IP adresu pod určitým portem

« kdy: 06. 06. 2018, 10:28:55 »

Chápu to správně, že máte doménové jméno nasměrované na váš router, kde HTTP požadavky na nestandardním portu (jiném než 80) směřujete do vnitřní sítě na nějaký webserver? A nyní chcete toto doménové jméno přesměrovat na nějaký webhosting? Tam ale nepůjde, webhosting vám nedovolí změnit port webového serveru a už vůbec vám nedovolí NATem nebo nějakým proxy serverem přesměrovávat komunikaci na nestandardních portech. To byste musel mít vlastní server nebo VPS, tam si můžete síť nakonfigurovat jak chcete.

Nejjednodušší by bylo oddělit ty DNS záznamy, jeden DNS název nechat pro ten web, který chcete mít na webhostingu, a jiný DNS záznam ponechat pro komunikaci těch zařízení a ten nasměrovat přímo na ten váš router.

3298

Server / Re:Lokální DNS server

« kdy: 05. 06. 2018, 20:53:09 »

Většina rad poněkud nebere v úvahu, jak DNS ve skutečnosti funguje.

Za prvé, neexistuje obecně použitelný způsob, jak zjistit všechny subdomény nějaké domény. Naopak jsou protokoly klem DNS záměrně navržené tak, aby subdomény vylistovat nešlo, pokud správce nechce. Takže např. seznam všech domén 2. úrovně v doméně .cz nejde z DNS získat. Takže Lojzův požadavek, aby nějaké adresy získal předem, je nerealizovatelný – o tom, zda daný doménový název existuje, se dozvíte teprve tehdy, když ho zkusíte přeložit.

Dále v době cloudů se domény používají k řízení provozu. To znamená, že teď se vám DNS název může přeložit na IP adresu a.b.c.d, ale za hodinu na té IP adrese dotyčný web či služba už dostupný nebude – a ničemu to nevadí, protože bude dostupný na jiné IP adrese a DNS záznam bude ukazovat už na to novou IP adresu.

S tím souvisí cacheování odpovědí. Aby se takhle pomocí DNS dal řídit provoz, nastavují se krátké časy platnosti záznamů. A běžné DNS cache se dobou platnosti řídí, protože když to dělat nebudou, mohou způsobit uživateli problémy. Takže si u běžného kešujícího resolveru sice můžete nastavit obrovskou cache, ale když vám někdo zabrání překládat adresu www.google.com, tak se tam za 5 minut stejně nedostanete, protože záznamu v cache vyprší platnost.

Takže je spíš otázka, jaký problém vlastně chcete řešit. Funguje špatně DNS resolver vašeho ISP? Pak můžete použít nějaký veřejný resolver – čtyři jedničky od CloudFlasre, čtyři devítky od IBM, čtyři osmičky nebo 8.8.4.4 od Googlu. Nebo řešíte jiný problém?

3299

Server / Re:Jak vyřešit www a non www na apache2

« kdy: 05. 06. 2018, 11:41:36 »

Srovnat to s temi RewriteRule/RewriteCond...

Jenže ty RewriteCond jsou tam nesmyslné. Konfigurace Apache může být úplně stejná, jako vaše konfigurace nginxu, nahradil by se řádek za řádek.

3300

Server / Re:Lokální DNS server

« kdy: 04. 06. 2018, 17:05:01 »

Šlo, kdybyste nějak dokázal zjistit všechny ty záznamy. Což nejde. Veřejný je seznam všech TLD, a tím to končí, úplný seznam všech domén druhé úrovně nezískáte.