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 - BoneFlute

Stran: 1 ... 107 108 [109] 110 111 ... 133
1621
Vývoj / Re:Dědičnost dnes
« kdy: 30. 01. 2017, 21:01:25 »
Ani ne, v Javě se už dávno nepoužívá. Možná jinde je pořád cool.
Pokud se v Javě dávno nepoužívá, jenom dobře. Pokud tedy jde o tu variantu s private konstruktorem, to bych jako anti-pattern bral.

Přesně tak. Jde o všechny varianty. Vtipné je, že většina lidí, když se ptá na pohovorech, ani neumí všechny a zároveň umí jen ty nepoužitelné. Ale pořád se na to ptají :D Alespoň člověk ví, co tam bude za lidi.

Singleton sa nezvykne pouzivat, ak je k dispozicii dependency injection framework. Ale inac neviem si predstavit, ako by sa riesila jedna jedina zdielana instancia pre celu aplikaciu v plain jave ... 
Omluv můj sarkasmus: já si nedovedu představit situaci, kdy bych potřeboval sdílenou instanci pro celou aplikaci.

HTTP request, FileSystem, DB connection - u ničeho z toho nepovažuji za žádoucí vynucovat si jen jednu jedinou instanci by design.

1622
Vývoj / Re:Dědičnost dnes
« kdy: 30. 01. 2017, 14:43:12 »
Jadro Armstrongova argumentu je v tom, ze michani funkci a dat neni dobry napad.

Měl jsem za to, že v Haskellu (při troše fantazie) je všechno funkce, nic nejsou data. I takový symbol 42 je jen nulární funkce.

1623
1) Aktualizace pod jednou strechou. To znamena jednim prikazem nebo spravcem balicku aktualizuju vse (zalezi na tom, jetli mate radi prikazovy radek, nebo vokynka). Moc dobre si pamatuju, co to bylo rucne stahovat veskery software a instalovat ho, jak id**t. A jak jsem u znamych nachazel roky stare programy, ale Windows, ten aktualizace mel :-).
Ano, je fajn že jedním příkazem aktualizujete všechny balíčky. Bohužel pokud jste něco nainstaloval mimo balíčkovací systém (řekněme Oracle, Lotus Domino, nebo účetnictví - pokud jste nějaké našel), tak jste na tom úplně stejně jako ve Windows. Ve Windows si u klasických aplikací aktualizace zařizují autoři, u aplikací z Windows Store (včetně Win32 apps zabalených pro Store) šíří aktualizace MS.
Supr, takže jestli to pročítám dobře, tak je to jednoznačně bod pro Linux.

1624
Potvrzuji že horizontální scrolling mimo aktivní okno u mě nefunguje. Upřímně by mě nikdy nenapadlo ho používat :). Ale zkuste ty utility které jsem linkoval, třeba to pomůže.
Jako kdyby na tom záleželo. Když se bavíme o tom, že linux má nějakou vychytávku, kterou windows nemá, a ty jsi windowsák, tak nepřekvapí, že to nebudeš znát a používat.

Já to používám hodně, a je to extrémně užitečné.

1625
ono pouzivanie linuxu je dost casto spojene s pouzivanim google, pretoze inak si neskrtnete, aspon nie ako normalny user. ked som fungoval isty cas pod linuxom, tak jediny moj pomocnik bol google a bolo to stylom, najst, pouzit a zabudnut
To by mohl být ten problém.

Ony se pak ty znalosti kumulují. A po nějaké době zjisíte, že ty programy mají parametre, které mají určitou logiku, a většinou se to dá snadno dohledat úplně stejně jako v GUI dohledáváte, co tak asi znamená tato položka menu.

1626
to stahovanie packageov ma zabudovane aj Visual Studio a je to velmi dobra vec. Cez nuget stiahnete co potrebujete a mozte pracovat :)
Pokud se ošklivě nepletu, tak NuGet není package manager ve smyslu aplikací, ale ve smyslu knihoven pro vyvíjenou aplikaci. Takže IMHO dost něco jiného.

1627
no jo a opet nejakej specifickej argument pro specifickou oblast. co takhle se bavit normalne, to znamena, ze clovek majici linux na notasu si jen tak neupravuje kernel, jak se mu zamane.
No, ono to není tak docela špatnej argument.
Pokud chci počítač čistě jen jako user, tak si koupím (a taky jsem tak učinil) Apple.
Pokud chci s počítačem dělat náročnější věci, tak chci co největší prostor. Nikdy nevíš, kam tě tvůj vývoj zavede. Takže v takovém případě je Linux jasná volba.
Windows je v tomto ani ryba, ani rak. Nemám pro něj využití. Na domácí počítač je moc nespolehlivej, a na develop zase nespolehlivej a omezující.

1628
repozitare...ano, to je jedna z velkych vyhod, ale treba takovy yum na aptitude nema ani omylem, kazdopadne od W8 ma i MS repozitar, a stejne, pokud dany SW v repozitari neni, tak pokud je jen jako source, tak se musi instalovat pres kompilaci, zatimco Win si tyhle problemy s sebou netahaji
To je ale ošklivej kec.
- mnoho projektů má vlastní repozitář
- když nemají repozitář, tak mají alespoň balíček
- když nemají balíček (kretýnos), tak maj teda instalační script (něco jako exe ve win)
- a pak jsou ty tři aplikace, které se musí kompilovat

Většina mejch kolegů, kteří programuje ve windows ani netuší, že existuje něco jako msi. A na mé zvědavé dotazy se tvářili dost nechápavě.
O repozitáři pro Windows jsem neslyšel. Existuje jen ten od MS. Zajímalo by mě, zda něco takového existuje.

1629
Vývoj / Re:Dědičnost dnes
« kdy: 25. 01. 2017, 13:16:32 »
ze maji pomerne jasnou typovou definici.

A navic treba v Haskellu lze OOP realizovat pres typove tridy.

Proto třeba osobně rozlišuju OOP/FP versus Typování jako dva různé koncepty.

1630
Vývoj / Re:Dědičnost dnes
« kdy: 24. 01. 2017, 22:50:28 »
Obávám se, že toto je jeden z dalších příspěvků ukazujících nepochopení OOP - data z objektu nejde nijak vybalit, protože když je vybalíte, buďto získáte anemický model, nebo to není objekt (primitivní typy), takže to není OOP. Představa, že by delegace bylo nějaké "vybalování", je úplně nesmyslná.

Anemický model/objekt je taky objekt. Chyba programátora, že definuje debilní chování. Ale s OOP to nesouvisí ani ho neporušuje.

Primitivní typy v OOP neexistují. To je optimalizace Javy a spol. V OOP nemůžeš z objektu vybalit nějakou hodnotu primitivního typu. Můžeš jen objektu poslat zprávu a ona ti vrátí opět nějakou instanci nějakého objektu.

Podle mne není to vybalení nějaký problém. Prostě mám objekt, ten má stav, a ten stav si můžu vyserializovat - tedy to jsem si pojmenoval po svém to vybalení. No, a ten stav je samozřejmě taky složen z objektů (alespoň teoreticky).

Mě ta definice od JS přišla celkem trefná.

1631
Vývoj / Re:Dědičnost dnes
« kdy: 17. 01. 2017, 00:19:16 »
A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.) A taky si všímám, že spousta kódu, se kterým přijdu do styku se u dědičnosti tímto pravidlem neřídí. Možná je to proto, že ta dědičnost je těžká, a vývojáři ji neumí používat, ale pak je to tedy koncept na prd, a neměl by se používat vůbec.

Možná se tím neřídí proto, že se tím řídit nedá, protože to samotné pravidlo je blbost.

Příklad, ...

Můj názor.

OK. Ale obávám se, že jsem tvou argumentaci nepochopil.

AccountRow dědí Row - je ok
Voda dědí Náplň - je také ok.

Zda to má nějaké rozumné použití je věc jiná.
Row i Náplň je interface, protože Voda i Hrách mají specifické chování a společné pro ně je jen to, že jej lze někam naplnit.

Nevidím problém.

1632
Vývoj / Re:Dědičnost dnes
« kdy: 16. 01. 2017, 21:39:07 »
Za mě se domnívám, že dědičnost tak jak je implementována ve většině jazycích je na pytel.

Jako problém vidím hlavně to, že někteří tvrdí, že dědičnost slouží k tomu, abych znovupoužil existující funkcionalitu. I kdyby to byla pravda, tak je problém, že většina jazyků nedokáže oddělit znovupoužití chování, od definice vztahu mezi třídami. Jak tu SB popisoval, že Smaltalk má objekt, a ty ho vždycky přetěžuješ - to je sice hezký, ale s tím poděděným chováním si zároveň podědil i všechny ty vztahy. Což u typovaného jazyka může bejt dost problém. Další problém je v tom, že čím delší linie, tím méně se člověku chce opravovat chybné chování předka. Což je trapné.

Přijde mi mnohem šikovnější a čistější rozdělení v některých moderních jazycích. Jednak máš rozhraní/interface/class, a druhak máš trait/mixin. První slouží k určení vztahů, k vynucování požadavků na signaturu, etc. A to druhé slouží k reusable kódu. Výhoda je v tom, že mohu opravdu jen použít existující chování a přidat ho jinam.

A abych si trochu hejtnul: Za celou mou relativně dlouhou kariéru jsem si u dědičnosti vystačil s pravidlem, že potomek musí být specielní verzí předka. (Všimněte si, že tam není nic o chování.) A taky si všímám, že spousta kódu, se kterým přijdu do styku se u dědičnosti tímto pravidlem neřídí. Možná je to proto, že ta dědičnost je těžká, a vývojáři ji neumí používat, ale pak je to tedy koncept na prd, a neměl by se používat vůbec.

1633
Vývoj / Re:Dědičnost dnes
« kdy: 16. 01. 2017, 21:22:17 »
...Napriklad pouzivani vyse zminenych protected pristupu tam, kde by byt nemely(skoro nikde). Kdyz davate neco protected, tak to je skoro stejne jako kdyby to bylo public...

To je samozřejmě nesmysl, právě protected dovoluje díky dědičnosti znovuvyužití hotové funkcionality v rámci zřetězení tříd bez nutnosti složitého delegování či opakování, na zapouzdření instance to pochopitelně vliv nemá.
A není to spíše naopak? Že protected umožňuje horkotěžko vyladěné chování rodičovské třídy nabourat a znepřehlední flow života instance, namísto jednoduchého, přímočarého a hlavně dobře otestovatelného delegování?

Protected je ekvivalent public. A jak tu bylo řečeno, nese si problém s tím, že se jedná o veřejné api, které je nutné dodržet. Což zvyšuje komplexitu.

1634
Vývoj / Re:Který PHP framework je perspektivní
« kdy: 08. 11. 2016, 01:49:19 »
Já teda Davida jako člověka moc nemusím, ale kód mu musím uznat.
Precetl sis poradne na co reagujes? Fajn, posledni veta je tam mozna trochu jako rypnuti, ale kod je v zasade nepodstatny detail pri vyberu. Duvody proc bych nebral Nette ja:
- dokumentace
- komunita
Ani s dokumentací to není pravda.

1635
Vývoj / Re:Který PHP framework je perspektivní
« kdy: 07. 11. 2016, 03:33:05 »
Na maly projekt s nekolika DB tabulkami ti postaci Nette, ktere postrada nejakou modelovou vrstvu a ma pouze jednoduchy query builder. Jeho vyhodou je ze uci dobrym navykum a jako zacatecnik ocenis promakane chybove hlaseni a ladenku.

Já bych si právě těmi dobrými návyky nebyl tak zvyklý. Vycházím z toho, že začátečník nabírá návyky nejvíc z toho, co vidí v dokumentaci (a StackOverflow apod.). U Nette vidím spoustu věcí, které za dobré návyky nepovažuju:

- zapisování stavových informací aplikace na disk (https://doc.nette.org/cs/2.4/caching, https://doc.nette.org/cs/2.4/sessions#toc-konfigurace-session)
- míchání PHP kódu s SQL (https://doc.nette.org/cs/2.4/database#toc-dotazy)

Tohle je dokonce do očí bijící:
https://doc.nette.org/cs/2.4/quickstart/authentication - jméno a heslo v plaintextu v konfiguráku

Věřím, že se to i v Nette dá dělat jinak, ale nacházím to jak v oficiální dokumentaci, tak i v několika reálných aplikací (od různých autorů), se kterými jsem se setkal (kromě té autentizace samozřejmě).

Nette ma velmi slabu dokumentaciu, zmeny sa musia zistovat na fore. Ma malu (cz only) komunitu, takze na beznych programatorskych weboch ako stackoverflow o nom toho vela nenajdes. Ak chces vyvijat v nette musis poznat Grudla osobne, idealne ked si jeho sused a na vsetko sa ho spytas. Spatna kompatibilita hrozna, vykon tiez nic moc (toto sa uz mozno zlepsilo). Tiez je to velmi ukecany framework a mnoho veci sa v nom robi zlozito. Na ko0d radsej ani nepozeraj.
Ty máš zdá se nějaký problém...

Já teda Davida jako člověka moc nemusím, ale kód mu musím uznat.

Stran: 1 ... 107 108 [109] 110 111 ... 133