Příspěvky

376

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 13:11:31 »

OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
Zkousel jsem to dneska rano v koupelne, byl jsem tam ja, zena a deti a normalne to fungovalo, zarovka svitila presne podle pozadavku.

Jistě to skvěle funguje i v případě, že ty a manželka chcete mít rozsvíceno, ale děti chtějí mít zhasnuto. Ve chvíli, kdy je objektů Osoba víc, musíš zajistit (ne)svícení buď fackováním, tedy soutěží mezi objekty Osoba, anebo technicky, kdy k žárovce je přidán doplněk, který nedovolí změnu stavu častěji, než např. jednou za minutu.

OMG, pokud chci resit problem prioritizaci pristupu jednotlivych Osob k Zarovce, tak budu resit prioritizaci, s vlastni Zarovkou to nema nic spolecneho. To je tupe zarizeni, ktere sviti, kdyz do nej tece proud a nesviti, kdyz ne.
Alespon v mem svete to tak je.
Opravdu netusim, proc by proboha zarovka mela resit, jestli ji nekdo nezapina moc casto...

Pro reseni tohoto pozadavku zkratka pred zarovku predradim autorizacni ci jinou proxy, v pripade moji koupelny to budu ja, vystarano.

Pokud ti nestačí běžná žárovka, tak si zkus představit jinou, například v datovém projektoru. Také můžeš síťovým vypínačem ovládat své PC.

377

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 11:37:05 »

Pokud objekt má atributy, ale nemá chování, je  anemický. Může jím být třeba ta žárovka, která reaguje na vypínač. Teprve vnitřní chování z něj činí objekt ve smyslu OOP, který může (nemusí) nejen reagovat na povel (zprávu) "lehni", ale i na událost "přišel cizinec".

BTW: Ta lingvistika nám to pěkně zamíchala.

378

/dev/null / Re:Těžké OOP problémy

« kdy: 07. 11. 2019, 09:08:55 »

OOP model zarovka s metodami rozsvit, zhasni je naprosto korektni model. Nechapu blaboleni, proc by jako zarovka mela sama něco delat, zarovka je pouze objektem, se kterym se manipuluje. Iniciatorem akce je objekt Osoba, která implementuje Runnable.run a zde je kod manipulujici se zarovkou.
Zkousel jsem to dneska rano v koupelne, byl jsem tam ja, zena a deti a normalne to fungovalo, zarovka svitila presne podle pozadavku.

Jistě to skvěle funguje i v případě, že ty a manželka chcete mít rozsvíceno, ale děti chtějí mít zhasnuto. Ve chvíli, kdy je objektů Osoba víc, musíš zajistit (ne)svícení buď fackováním, tedy soutěží mezi objekty Osoba, anebo technicky, kdy k žárovce je přidán doplněk, který nedovolí změnu stavu častěji, než např. jednou za minutu.

379

/dev/null / Re:Těžké OOP problémy

« kdy: 06. 11. 2019, 22:12:02 »

Pocitani referenci je ten nejmensi problem, relativne trivialne resitelny. Problem je v tom, ze (dnesni, takzvane) OOP uplne automaticky pocita s tim, ze objekt je entita a pritom klidne do te entity necha vlezt nekolik vlaken. Cista schizofrenie.

Ilustrace:

Ucebnicovy priklad:  zarovka.zhasni(); zarovka.rozsvit();

Realita: vlakno1.zhasni(zarovka) ...a zaroven klidne... vlakno2.rozvit(zarovka)

Ten, kdo v (dnesnim, takzvanem) OOP kona neni objekt, ale vlakno. I kdyz abstrakce se tvari jinak a timpadem i ucebnice tvrdi neco jineho.

Tohle je dost nicneříkající příklad, ale když už, tak ty dvě metody se syncnou na logice spínání relé.

Řekl bych, že Mirek Prýmek na to kápl. Souběhy z více vláken dokáží nadělat v OOP pěknou paseku. Netvrdím, že to nejde vyřešit, ale triviální úloha to rozhodně není.

380

Software / Re:Sledování průběhu práce na SW projektu

« kdy: 06. 11. 2019, 13:13:45 »

Samozřejmě je vhodné mít svá data zálohována. U gitu to lze dvěma způsoby - buď svůj lokální repositář napojíte na server (který nemusí být na internetu, vše, co je potřeba, je ssh spojení) a budete tam posílat své změny („git push“), nebo budete zálohovat složku „.git“ jakýmkoliv způsobem, kterým si zálohujete ostatní data (Firefox profil, dokumenty, atd.) (já k tomu třeba používám program Unison).

Ještě je několik dalších způsobů, například mít bare na externím disku. Připojit, push, odpojit.

381

/dev/null / Re:Těžké OOP problémy

« kdy: 04. 11. 2019, 17:26:36 »

Podívej se na zásady SOLID. Všechny jsou porušovány naprosto běžně. Stačí si tedy každé pravidlo znegovat a dostaneš nejčastější problémy.

382

/dev/null / Re:Těžké OOP problémy

« kdy: 04. 11. 2019, 16:38:01 »

Obecným problémem bývá nadužívání dědičnosti, nevhodné užití návrhových vzorů, chybně provedená injekce závislostí, třídy, které toho umí příliš mnoho a nic pořádně, nadužívání přístupových metod k atributům, příliš mnoho atributů, chybná dekompozice. Kde je nějaký atribut "protected", tam jsou problémy.

383

Vývoj / Re:Jak vytvořit vlastní debugger?

« kdy: 03. 11. 2019, 23:39:47 »

Proměnné nejsou problém. To si prostě na to vytvoříš objekt řešící scope, uchovávající lokální proměnné (v případě neexistence dohledáváš v nadřazeném, etc). Mnohem větší pruda speciální formy IF, FOR, WHILE...

Přesně. Rozhodování, skoky, cykly, podprogramy, funkce. Pokud bych měl něco takového dělat v míře větší než malé, použiji hotový jazyk, ke kterému jen napíši nějaký doplněk. Jinak riskuji, že mi to bude trvat zbytečně dlouho a stejně ten výsledek nebude odpovídat vynaloženému úsilí.

384

Vývoj / Re:Jak vytvořit vlastní debugger?

« kdy: 03. 11. 2019, 23:31:53 »

Velmi zajímavé! Jak byste na to šli?
Vytvořením virtuálního procesoru?
Pokud zkusím připravit virtuální procesor, znamená to, se postarat i o správu paměti.

Příklad, kdybych si chtěl napsat vlastní interpret "BASICU", resp. ten jazyk by se dal nazvat dialektem BASICu, ale chci používat velmi specifické vlastnosti, které nemají odpovídající paradigma (funkcionální, procedurální...atd).

Především se zbav potřeby univerzálního jazyka. Na to je dostatek interpretů, ze kterých si vybereš, dopíšeš pár knihoven nebo si uděláš framework a jedeš.

Pak jsou ještě doménově specifické jazyky, které jsou mnohem jednodušší a takový interpret splácáš za chvíli. Přečteš řádek a podle prvního slova vyhodnotíš, co s tím zbytkem uděláš a jak změníš stav. Můžeš to udělat jako Moorův nebo Mealyho automat. Cykly neřešíš, o správu paměti se postará hostitelský jazyk, ve kterém si uděláš asociativní pole (slovník).

Taková blbinka se dá slepit třeba v AWK na pěti řádcích, ale můžeš si vybrat takový jazyk, který ti pro daný účel vyhoví nejlépe.

385

Vývoj / Re:Jak vytvořit vlastní debugger?

« kdy: 03. 11. 2019, 11:51:21 »

To se týká jen univerzálních interpretů. Pokud jsou však doménově specifické, mohou být velmi praktické a užitečné.

nemohou, nikdy se nedostanete na úroveň zavedených interpretů, co se týče dokumentace, odladěnosti, podpory v nástrojích třetích stran

Pokud zavedené interprety nesplňují mé doménové požadavky, tak mi nezbývá nic jiného, než si napsat vlastní. Není to tak složité, jak to vypadá. Pár desítek či stovek řádek se dá napsat třeba i za hodinu.

386

Vývoj / Re:Jak vytvořit vlastní debugger?

« kdy: 03. 11. 2019, 10:12:55 »

OT: Psal už někdo z vás vlastní interpret?
Například pro Basic, Pascal, Lua nebo něco podobného?

Docela rád bych si jeden takový napsal (taková specialitka) a pár rad by se hodilo.

in-house vyvýjené interprety jsou zlo, jak ukazuje tato diskuze.

To se týká jen univerzálních interpretů. Pokud jsou však doménově specifické, mohou být velmi praktické a užitečné.

387

Vývoj / Re:Jak vytvořit vlastní debugger?

« kdy: 02. 11. 2019, 19:10:39 »

Místo debugu zkus raději testy jednotek. Aspoň to nebudeš muset ladit ručně.

388

Vývoj / Re:Jak zkrátit kód v Jquery?

« kdy: 02. 11. 2019, 17:16:33 »

Nefunguje, ale může to být tím, že jsem v Jquery dělal změny...

To byl docela blbý nápad.

389

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 26. 10. 2019, 15:47:39 »

Pomiňme, že Google pro tento účel nepoužívá SQL, ale vlastní databázi Big Table.

Jenže i v SQL tohle umíme. Stačí jen tu databázi normalizovat. Tabulka se nám rozpadne na tři tabulky a ejhle, najednou našeptávač neprochází milióny záznamů se štítky, ale jen stovky. Navíc je tabulka se štítky velmi úzká a tedy i rychlá. Samozřejmě má i svůj index.

Jenže tady vůbec nejde o databázi, ale o index. Našeptávač opravdu nemůže dělat fullscan tabulky, ani malé. Našeptávač musí vždy pracovat nad indexem. Teda pokud budete našeptávat z deseti hodnot, nemusíte to vůbec řešit v databázi a vyřešíte to na klientovi, ale o takovém případu se snad nebavíme.

Fullscan tabulky do tisíce záznamů je rychlejší, než použití indexu. Index pro více záznamů má význam až při selekci, tedy výběru podmnožiny, např. klauzulí WHERE, která vybere méně než cca 10-50 % záznamů.

Distinct je proveden teprve z této podmnožiny.

390

Vývoj / Re:MySQL - podmíněný SELECT přes dvě tabulky

« kdy: 26. 10. 2019, 15:30:55 »

Když nebude mít ten index, musí načíst všechny záznamy z tabulky, jejich hodnoty seřadit – a pak může konečně začít dělat to, co před tím dělala nad indexem. Když těch štítků bude málo, takže nepotřebujete stránkovat, bude to podobné, akorát je podle indexu vypíše všechny. To, k čemu tam ten index je, je to řazení záznamů – odpadne ta potřeba vše načíst a seřadit až v okamžiku dotazu, protože už je to uložené v tom indexu.

Takhle se to skutečně nedělá. Záznamy se sekvenčně sypou do datové struktury, ve které je text štítku klíčem. Duplicita je rozpoznána ihned při vložení klíče. Žádné následné řazení ani selekce se nekoná, jen se ta struktura vyleje na výstup.