Příspěvky

781

Hardware / Re: Prosím o zhodnocení PC sestavy

« kdy: 02. 04. 2011, 20:58:38 »

Tady se zas sešli odborníci....
Dual/tripple chanell je úplně jedno. V praxi se to až na výjimky nepozná.
Deska, pokud nechce opřetaktovávat naprosto stačí. To co do ní chce dát se vejde, procesor na tom poběží, tak proč by měl připlácet?

Sestava CZC je blbá z vícero ohledů, nebrat. V alfě je to lepší, ale
- Procesor imho stačí i7-2500, za velkej příplatek malej podíl výkonu.
- Zdroj bych koupil Seasonic S12, tydle corsairy jsou tušim rebrandovaný CWT a nejsou tak dobrý (účinnost, ticho...)
- Skříň nic moc, bude se třást jak ratlík. V týdle ceně bych bral CM centuriona, o něco dražší pak Dominátor, Lancool K58.
- Pokud NetBeans a Javu, tak bych tam dal těch 8GB paměti. Je levná a Java žere hodně.
- V týdle ceně má smysl uvažovat i nad SSD, ale vždy se dá dokoupit.
- Chladič je dobrej, ale Gelid Tranquillo je myslím ještě o něco lepší :-)

782

Hardware / Re: Doporučte Wi-Fi tiskárnu s WPA2

« kdy: 29. 03. 2011, 21:54:27 »

Anebo k tomu připojit APčko. Komplet AP + síťová blejzrovka bude stát míň, než když to bude allinone.

783

Server / Re: Příliš dlouhý SELECT

« kdy: 29. 03. 2011, 21:51:28 »

Jestli je problémem počet tabulek, tak prostě vytvoř selectem ze čtyř tabulek jednu temporary a tu pak joinuj....

784

Windows a jiné systémy / Re: Windows ve virtualizaci a licence

« kdy: 23. 03. 2011, 18:32:40 »

No pokud máš pouze jednu instalaci, tak podle mě nic neporušuješ. I kdyby to byla oem, tak nesmí běžet na jinym PC, což neběží, takže Ok...

785

Odkladiště / Re: IT inovace od neprogramátora

« kdy: 21. 03. 2011, 11:36:24 »

JS: Samozřejmě, pokud nějakej paňáca říká programátorům, jak to maj psát, je to na zabití. Na druhou stranu vymyslet základní principy, jak se bude program chovat, jaký budou use-cases, nebo i čistě vytřískání nějaké rozumné specifikace ze zákazníka je práce, kterou často udělá lépe člověk, který není primárně programátor. A tydle činnosti jdou imho nad návrh UI a tedy "umění", je to poctivá "analitická práce".

Todle je bohužel věc, která spoustě opensource produktů schází.

786

Odkladiště / Re: IT inovace od neprogramátora

« kdy: 20. 03. 2011, 22:22:43 »

IT architekt, návrhář UI, analitik apod jsou vcelku normální povolání - a dokonce velmi často je pro ně přílišná znalost programování na škodu. To ale neznamená, že není potřeba znát zas jiné věci.
No a další možnost je - opokud máš vize - tak založit firmu, zaměstnat programátory.....

787

Hardware / Re: SCSI Disk IBM

« kdy: 20. 03. 2011, 22:15:57 »

A má ten řadič bootrom? S tim si nejsem jistej, ale mam dojem, že do některjch řadičů se musel dát extra šváb, aby to z něj bootovalo. Ale nevím, jestli je možný, aby měl SCSI řadič BIOS a neměl tu BOOTromku.

Pokud ale bude na PCB jeden šváb chybět, je to dost pravděpodobný...

788

Hardware / Re: SCSI Disk IBM

« kdy: 20. 03. 2011, 15:40:39 »

To, z čeho PC startuje není záležitost disku, ale řadiče. Nastavuje se to v biosu, zkusil bych tam nastavit něco na způsob SCSI nebo other. Řadič, na kterej je to připojený ale musí mít svůj BIOS (kus kódu, kterej podstřčí BIOSU morherboardu a pomocí něho nastartuje OS).

789

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 20. 03. 2011, 11:27:42 »

ondra: jo, souhlasím, že to je už debata o drobnostech - prostě mě to C++ řešení připadá hodně krkolomný (co se týče syntaxe), to je celý. Prostě by to chtělo nějak líp pocukrovat....

790

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 19. 03. 2011, 18:37:57 »

Já netvrdím, že do konstruktoru nepatří nic. Samozřejmě, pokud stav objektu bez někajech hodnot nemá smysl a nejsou ani k dispozici rozumný "defaultní" hodnoty, je asi nejlepší ho inicializovat rovnou v konstruktoru. Takových hodnot ale zase zpravidla nebývá 15.....

Pokud je hodně "povinných" parametrů nějaké funkce či konstruktoru, bývá to většinou proto, že daný objekt(funkce) dělá dvě věci najedou. V tu chvíli je rozumné ten objekt rozdělit na dva (a třeba ten druhý objekt poslat do konstruktoru toho prvního).

791

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 19. 03. 2011, 17:24:07 »

Ad házení výjimek, jakej je rozdíl mezi

Kód: [Vybrat]

try:
  a=b(a=1,b=2,c=3);
catch:

a

Kód: [Vybrat]

try:
  a=b();
  a.seta(1);
  a.setb(1);
  a.setc(1);
catch:

Jeden rozdíl tam přesně vidím - i když to spadne na nějakou obecnou výjimku, v případě 2) vidím, která vlastnost to způsobila, aniž bych musel lízt do definice objektu.

Další výhoda přístupu 2 je při modifikacích kódu - když budu mergovat patche, tak při přístupu 2 vidím hned a daleko lépe, co daný patch změnil. To, že každá řádka má dělat pokud možno jen jednu věc není pravidlo zbytečné (byť samozřejmě jako všechny ostatní velmi často odůvodnitelně porušitelné).

----

Objekty uživatelskýho rozhraní zpravidla maj hromadu parametrů, ale pokud člověk programuje rozumně, tak např. používá themes, takže většina těch parametrů je danejch... Stejnětak font člověk málokdy vytváří "adhoc". Samozřejmě, existují případy, kdy je třeba tydle objekty vytvářet - ale to jsou poměrně řídké výjimky.

----

Co se týče funkcí - tak samozřejmě existují funkce, kde je více argumentů opodstatněných. Ale příliš časté nejsou. Co se týče např. toho popen, tak tam např. místo předání pole deskriptorů (což by umožnilo dát subprocesu víc než jen standardní tři vstupy/výstupy) se dává každej v spešl argumentu. A navíc je to implementace "děravá", viz varování u atributů vzniklého objektu.

Dál jsou tam flagové proměnné - a to jen jiný zápis bitového pole, který pokládám za o něco vhodnější (líp se uchovává stav volání, loguje, kvůli přidání přepínače se nemusí přidávat argument fce...). Pokud nesouhlasíš, tak prostě tydle argumenty pro účely pravidla počítej jako jeden.
No a pak jsou tam dva argumenty, svázané s implementací té funkce na jednom konkrétním OS, což je poměrně úlet (až se python rozšíří na deset OS, tak tam bude těch proměnejch dvacet??).
A je to kontruktor (takže opět by to šlo rozepsat do následných volání).

No a naposled ta třída dělá x věcí (např. hraní si s deskriptorama), pro který by asi bylo výhodný udělat spešl třídu, protože hrát si s deskriptorama je potřeba i jinde a tak je užitečný, aby se to dělo jednotnym způsobem.
Takže design tý třídy za nějak extra dobrej nepovažuju.

Stejně tak psycopg2.connect() má v podstatě jeden argument - buďto řetězec, nebo struktura či asociativní pole parametrů pro spojení. Zbytek je syntax sugar  pythonu, umožněná hlavně konstrukcí **pole (jinak bych za takovoudle syntaxi "vraždil", protože si ty parametry člověk většinou schovává někde v konfiguraci v nějaké struktuře a rozbalovat je ručně je blbina).

Samozřejmě, tři (já ani nevím, jestli v originále pravidla je tři, čtyři nebo kolik, prostě "málo") je velmi striktní číslo a najdou se příklady, kdy je rozumné mít argumentů víc. Jako každé z pravidel to samozřejmě není pravidlo striktní, ale ukazuje na možné chyby v designu aplikace a když si to sám před sebou obhájím, tak ho klidně poruším. To ale nic
nemění na tom, že má velmi často pravdu....

To, jak python zachází s argumentama je úžasný, asi nejlíp z jazyků, co znám (automatické rozbalování polí, pojmenované parametry). Občas se mi ale zdá, že to vede k přílišnému "zplošťování funkcí"

----

Ondra: to je vnořená, ne anonymní třída. To, že něco pojmenuješ anonymní, tak tím ještě anonymní třídu neuděláš :-). Proto jsem psal také, že to jde nejhůř (syntax je rozvleklá, vyžaduje zbytečnej identifikátor a nedá se napsat "inplace", což vše ztěžuje čitelnost programu) a ne že to nejde.
S readonly objejkty máš samozřejmě pravdu, ale ty málokdy bývají příliš komplexní (a nebo jdou rozložit na agregaci menších komplexních objektů).

792

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 18. 03. 2011, 13:11:24 »

Jo, s tím, že často vhodnější než callback je interface souhlasím.

Ale zaujalo mě, že to říká zrovna člověk píšící v C++, kde se to pomocí interfaců dělá snad nejhůř ze všech jazyků :-) (např. neexistence anonymních tříd, byť to nested classes trochu zachraňují)- ale jak vidět, C++ je mocné a jde v něm všechno snadno a rychle, jen si to holt člověk musí nejdřív sám napsat. :-)

793

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 18. 03. 2011, 13:02:07 »

Co není pravda? Že metoda s patnácti argumentama je trochu zvrhlost? Sice konstruktor je jediná výjimka, kdy to může mít opodstatnění, ale ve výsledku je daleko čitelnější jednoduchej konstruktor a následný nastavení vlastností. Srovnej

Kód: [Vybrat]

class A {
   {
   __init__(vlastnosta=1, vlastnostb=2,vlastnostc=3, vlastnostd=4, vlastnoste=5, vlastnostf=6, vlastnostg=7, vlastnosth=8, vlastnosti=9, vlastnostj=10)
             {
             self.vlastnosta=vlastnosta;
             self.vlastnostb=vlastnostb;
             self.vlastnostc=vlastnostc;
             self.vlastnostd=vlastnostd;
             self.vlastnoste=vlastnoste;
             self.vlastnostf=vlastnostf;
             self.vlastnostg=vlastnostg;
             self.vlastnosth=vlastnosth;
             self.vlastnosti=vlastnosti;
             self.vlastnostj=vlastnostj;
             }
  }
a=A(vlastnostc=1, vlastnostd=2);

s

Kód: [Vybrat]

class A:
   def __init__():
             self.vlastnosta=1;
             self.vlastnostb=2;
             self.vlastnostc=3;
             self.vlastnostd=4;
             self.vlastnoste=5;
             self.vlastnostf=6;
             self.vlastnostg=7;
             self.vlastnosth=8;
             self.vlastnosti=9;
             self.vlastnostj=10;
a=A();
a.setVlastnostc(1);
a.setVlastnostd(2);

I když uvažuju jazyk, kde se nemusí definovat proměnné, tak druhá varianta je rozhodně mnohem čitelnější. Navíc je to řešení rychlejší, neboť nemusí na stacku vytvářet všech těch 15 defaultních parametrů konstruktoru (metody setVlastnostc se inlinují, takže tam režie není).

Pokud bych bral jazyk, kde se definují vlastnosti objektu, tak je rozdíl ještě markatnější, neboť zatímco v první variantě by každá vlastnost zabrala dva řádky (jedna definice a jedna v konstruktoru) zatímco varianta dvě by si vystačila s inicializací v definici. A definice vlastností není vůbec "zbytečná věc", neboť pomocí ní lze odchytit typo v přiřazování do vlastností.

Další věc je, že pokud změním požadavky (omezení) na jednu z vlastností, stačí mi upravit setVlastnostx(). V řešení A musím upravit navíc ještě konstruktor. Takže je to i řešení náchylnější k chybám.

No a last but not least: No a klíčová je zkušenost, že zpravidla třída, kterej potřebuje v konstruktoru 15 vlastností má špatnej design: většinou jde o sloučení funkčností více entit do jedné třídy, a mělo by se to rozdělit do víc samostatnejch tříd....
PS: Nesouhlasíš-li, dej příklad objektu s 15 parametry, který je opravu nejlépe implementovat monoliticky.

794

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 17. 03. 2011, 23:49:47 »

Předat referenci v konstruktoru můžeš, pokud je ta reference jedna. Pokud je těch callbacků x.... Někde to lze vyřešit pojmenovanými parametry, ale pořád zůstává naprosto zbytečně "nafouknutej" konstruktor a naprosto nečitelné jeho volání. Známá programátorská pravda říká, že víc než cca 3 argumenty metody znamená, že je něco špatně....

V každym případě prostě není jediný důvod, proč by měli být metody, které jdou za běhu měnit, implementované úplně jiným způsobem, než metody, které měnit nejdou.

Co se týče zaměňování, tak ty definice jsou asi různý - to co píšeš je něco mezi silnym/slabym a statickym/dynamickym typováním, podle autora. V každém případě to, že do seznamu můžeš nacpat cokoli naprosto nesouvisí s tím, jak je řešená resoluce volaných metod. Můžu mít klidně silně staticky typovanej jazyk s prototypovou dědičností a možností modifikovat objekt za běhu. Anebo jazyk v podstatě bez jakékoli typové kontroly, kterej ale modifikovat objekty za běhu neumkožňuje (např. některé verze visual basicu).

795

Vývoj / Re: Triedne vs. Prototypové OOP

« kdy: 17. 03. 2011, 13:33:00 »

Řešení callbackem sice jde, ale srovnej kód:

Kód: [Vybrat]

function nothing() {};
class C
   {
   void (* callback)();
   C() { callback = nothing; }
   }

oproti

Kód: [Vybrat]

class C
   {
   callback() {};
   }

Druhá možnost je daleko jednodušší a bez rizika, že zapomeneš callback inicializovat (byť v nějakém jazyku s anonymními fcemi by to asi nebyl tak velký rozdíl). Spotřeba paměti s callbackem je také větší (musíš držet všechny callbacky, ne jen ty předefinované). No a javovské anonymní třídy maj ještě složitější syntax, byť mají také své přednosti...

Vypadá to jako blbnutí o pár znacích, ale když má daná třída těch callbacků 10, každej s jinejma argumentama, ale z toho se ale reálně použije vždy tak jeden dva, tak je rozdíl v čitelnosti značnej.

Na co narážíš aritmetickými typy nevím, v každém případě směšuješ silné a slabé typování se statickým a dynamickým jazykem. Je sice pravda, že většina slabě typovaných jazyků je dynamických a vice versa, ale platit to nemusí.

PS: Já netvrdím, že to v statickém jazyce nejde, jen tvrdím, že dynamický přístup je prostě přímočařejší. Řešení s callbackem je prostě řešení "za roh", až na to, že jsou na něj všichni zvyklý a tak nám nepřipadá divný. Proč ale když měním chování objektu, tak bych měl měnit vlastnost? Proč jsou měnitelné a neměnitelné metody objektu implementovány úplně jinou technikou?