Příspěvky

826

Vývoj / Re: Jak začít s programováním DB?

« kdy: 23. 12. 2010, 17:48:24 »

Jenže s jinýma databázema se IMHO neni moc co učit.... Pokud pominu různé objektové a xml databáze, které se prakticky nepoužívají, tak zbývají jen noSql databáze - a na nich v podstatě není co k učení :-). To je jen o málo chytřejší filesystém - a ještě jsem nikoho neslyšel říkat, naučte mě pracovat se soubory....

827

Vývoj / Re: Jak začít s programováním DB?

« kdy: 23. 12. 2010, 15:14:09 »

MySQL stačí tak na úplný základy SQL - tam totiž stačí cokoli.
Na triggery atd. už ne, tam už to má natolik "zprasený", že to jen učí blbejm návykům. Autentizaci alá mysql jsem taky nikdy nepřišel na chuťm ale dejme tomu. Check constraints co vím taky nefunguje. Atd.... Jediný plus mysql je vcelku snadná instalace, ale tu má už dneska postgresql nebo firebird taky.

828

Windows a jiné systémy / Re: Programátorské znaky ve Windows XP

« kdy: 23. 12. 2010, 14:47:52 »

QWERTZ fuj. Tam ty znaky (přes pravý alt)
a) zdaleka nejsou všechny
b) jsou na roztodivných a veskrze .... hloupoučkých .... místech
Na klávesnici QWERTY jsou s pravým altem až na asi dvě výjimky tam, kde jsou na americké. Bejt Tebou se přeučím.

Další možnost je ze stránek microsoftu stáhnou software na definování vlastních klávesnic a udělat si svojí...

Programátorská je hybrid mezi českou a americkou, tu bych nebral.

829

Vývoj / Re: Jak začít s programováním DB?

« kdy: 23. 12. 2010, 00:04:21 »

Za jeden až dva dny se naučí tak základy SQL. Naučit se alespoň trochu rozumně používat takový věci jako triggery, rekurzivní dotazy (with recursive () select), window funkce atd... che trochu víc času.

A naučit se správnej design databáze chce zároveň znát trochu teorii (alespň normální formy, nejlépe relační algebru) a nemálo praxe...

830

Vývoj / Re: Jak začít s programováním DB?

« kdy: 22. 12. 2010, 12:05:50 »

Ehm, doporučovat k učení MySQL? Proč? Kdo umí pořádnou databázi, nebude mít s peučením na MySQL problémy. Ale proč se kazit takovými "zvěrstvy" jako jeden trigger na tabulku, enginy, kde v každém funguje něco, ale není žádný, kde by fungovalo  všechno (fulltext, transakce)?
 

831

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 21. 12. 2010, 21:42:54 »

Pokud se rozhraní navrhujou dobře, tak je používá víc klientů. Např. To vaše toString lze využít na různých místech v GUI, při logování, při debugování, při generování komentářů do konfiguračních souborů apod...
jinými slovy, psů je sice mnoho, ale také štěkaj všude, kam přijdou. (chudák zajíc :-)).

Ad nenaočkovaní psy a deprecated: malej problém by byl, kdybych měl myslivce, kterej najednou chce jít přes hranice či k veterináři - a tam je třeba řešit všechny psy. Jenže daleko častěji se spíš stane, že mám myslivce, kterej chodí přes hranice i k veterináři, akorát doteď měl jen jednoho psa.
A najednou za mnou přijde zákazník se slovy: "ale my tam máme myslivce, co má dvě dogy." A takovejdle překvápkům se člověk při vývoji nevyhne. 
A v tu chvíli nestačí označit jednu funkci za deprecated (což jinak máte pravdu, že je to jeden z nejrozumnějších konceptů, jak se vyrovnat se změnou rozhraní). Protože musím upravit všechnu funkčnost v klientech, které doteď předpokládali, že jeden myslivcův pes jsou všichni myslivcovi psy.

Jinými slovy. Poku chci najednou posílat myslivce přes hranice, tak je to blíž situaci, kdy implementuju novou funkčnost. Největší problémy jsou ale při změně stávající funkčnosti: (myslivec už dlouho přes hranice chodí, ale teď chce s sebou vzít o psa více...).

832

Vývoj / Re: Optimální algoritmus výpočtu

« kdy: 21. 12. 2010, 02:49:46 »

To cos napsal není ani definice složitosti (v NP úplnosti), ani definice třídy P. Jestli nevěříš, tak běž na MFF na přednášku Úvod do složitosti a NP úplnosti, nebo si přečti o NP úplnosti nějakou knihu.

PS: http://mj.ucw.cz/vyuka/0910/ads2/11-np.pdf
úloha batoh optimalizace je v podsatatě to samé a je tady uvedena mezi NP-úplnými úlohami.

PPS: To, cos napsal, je parafráze definice asymptotické složitosti. Ta se hodí pro sledování složitosti algoritmů řešících konkrétní problém v závislosti na daném kritériu. Nejde však použít k srovnání různých algoritmů, protože nemusí mít shodné kritérium.... tedy, jedno shodné kritérium dva libovolné algoritmy mají: délku vstupu....

833

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 20. 12. 2010, 23:09:24 »

Samozřejmě, když se objektu přidává NOVÁ funkcionalita, má mít nové rozhraní. To jsem tvrdil u metody toString, to jsem tvrdil u onetouch/multitouch (porotože IMHO ani jedno z těch rozhraní není nadstavba druhého, jak jsem ukázal v minulém postu). Ale onepes a multipes není implementace různých služeb, jde o tu samou službu.

V původním příkladu nešlo o novou funkčnost - ta si samozřejmě nové rozhraní zaslouží - ale o zpřesnění staré funkčnosti. Neexistuje myslivec, který má jednoho psa a nemá psy - a každý myslivec, který má psy je myslivec, který má psa. Takže každý myslivec se psy bude chtít být použitelný i tam, kde je použitelný myslivec se psem a vice versa. Takže mezi Vašimi příklady a původním není analogie.

Prostě budu-li chtít implementovat myslivce s x psy, tak ať modifikuju staré rozhraní, nebo udělám nové, tak jestli budu chtít pustit multipsa do systému, musím opravit všechna místa, kde klient zpracovává JEDNOHO mysliveckého psa a ve skutečnosti je chtěl zpracovávat VŠECHNY. Pokud to neudělám, tak program nebude korektní (za hranice budou chodit nenaočkovaní psy, budu vybírat málo poplatků za psí známky atd...) Takže se úpravě klientů nevyhnu.

A co se týče dilematu, jestli změnit staré rozhraní, nebo definovat nové, tak v tomto případě je to v podstatě dilema: přinutí mě kompilátor projít všechna místa, kde se pracuje s mysliveckým psem (což stojí hromadu času), nebo mě nepřinutí a já budu muset nějak přijít, na kterých místech je ta oprava nutná, protože se tam má pracovat se všemi psy a ne s jedním. To samozřejmě záleží na situaci, ale první možnost mi zaručí, že v programu nezůstane (logická) chyba. Druhá nikoli. Tím neříkám, že je ta druhá vždy horší, jen ukazuji, že má i nevýhody.

834

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 20. 12. 2010, 20:27:23 »

Já začal diskuzi tím, že někdo argumentoval, že nevýhoda rozhraní je ta, že když se změní, musí se pak změnit všechny objekty, které to rozhraní používají. Což je pravda, ale ne vždy je nutné to řešit změnou rozhraní.

Pokud chci, aby všechny objekty, které používali staré rozhraní, šly použít na místě, kde potřebuji nové rozhraní, tak ať už to vyřeším novým rozhraním, nebo updatem starého, do těch všech objektů prostě šáhnout musím. Srovnávalo se řešení, kdy navrhnu rozhraní od začátku tak, aby vyhovělo úpravám a tomu, kdy nikoli.

Definice nového rozhraní oproti modifikaci starého sice řeší to, že nemusím upravovat jiné klienty, pořád ale musím upravovat všechny servery a navíc mám dvě rozhraní řešící stejnou věc (a jelikož obě používám ke stejné věci, většina objektů bude muset implementovat obě).

třeba k tomu je důvod. Nevíte, jen vaříte z vody.

Pokud je k tomu důvod, pak už dané zařízení není čistě multitouch - protože má důvod prioritizovat nějaký klik. Prostě buď tam ten důvod je, pak to rozhraní ale je onetouch (protože umí určit prioritní klik), nebo ten důvod nemá a pak nemá co implementovat onetouch.

(ad CAPS/RTTI souhlasím - u emulátoru se musí nějak vyřešit, aby ex-multitouch umící z něčeho poznat primární dotek nebylo zbytečně emulováno. To však není ve sporu s mým tvrzení, že onetouch by mělo implementovat pouze to zařízení, které opravdu je schopno samo poznat, který klik je primární).

Co rozhodne? Zdali umí poznat prioritní dotek? No pokud neznám schopnosti zařízení, těžko pro něj mohu navrhovat vyhovující rozhraní. A pokud je znám, tak rozhodují schopnosti toho zařízení.

Bohužel tohle vždycky narazí na křivku zvyšujících se nákladů. Zvýšení kvality produktu o jeden stupeň generuje dvojnásobné náklady. V jednom okamžiku jsou náklady tak vysoké, že další zvyšování kvality je ve finále dražší, než všechny náklady, které to ušetří v budoucnu. Tady je třeba ctít ekonomiku. Prostě nelze vyrobit dokonalé rozhraní, protože v konečném důsledku bude jeho používání dražší, než nějaké primitivnější a mnohem levnější řešení.

Takže již se mnou souhlasíte, že je to řešení lepší, akorát někdy může být neúměrně drahé? To je dobrý posun. :-)

No a ted se stačí zamyslet nad tím, o kolik aplikaci zdraží rozhraní myslivce s více psy oproti jednomu. IMHO marginálně
(pokud budu vždy pracovat např. s prvním psem) a proto je lepší od začátku navrhnout multipsa.

835

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 20. 12. 2010, 13:43:02 »

Asi podvanácté: debata nezačla o tom, jak upravovat nevhodně napsaná rozhraní, ale jak je navrhovat tak, aby se pokudmožno nemusely upravovat nebo nutnost jejich opravy obcházet napsáním duplicitních rozhraní. S tím, že když bylo původně napsané rozhraní nevhodně, že se s tím někdy nedá dělat nic lepšího než nadefinovat rozhraní nové, souhlasím.

---

Ad multitouch emulace onetouch. Jsou dvě možnosti. Buďto má multitouch inherentně nějaký vlastní způsob, jak zjistit, který klik je preferovaný (např. detekuje ukazováček a bere ho jako primární). V tomto případě by nejčistší řešení bylo, kdyby v rámci multitouch rozhraní dával hint, která souřadnice je ta správná.

V každém případě již ale nejde o čistý multitouch, ten mezi stisky nerozlišuje - takovéto zařízení je schopno přijímat více informací než klasický multitouch. A pokud opravdu vždy v každém okamžiku umí rozhodnout, který stisk je ten preferovaný, pak má zároveň schopnosti rozhraní oentouch a není důvod, proč by ho neimplementoval.

Anebo takový mechanismus nemá a programátor ovladadače by si při implementaci onetouch rozhraní musel vycucat z prstu. Pak má být v systému opravdu onen emulátor, který zachází se všemi true-multitouch zařízeními jednotně, napíše se jen jednou a je konzistentní. V takovém případě je ale IMHO ŠPATNĚ, pokud multitouch zařízení "obejde" systém a svévolně si implementuje onetouch: např. proto, že uživatel bude zmateně hledat, kde se to nastavuje, proto, že v systému bude zbytečně duplicitní kód atd...

Co je ale závěr: v žádném ze scénářů není správně, když zařízení, které má pouze schopnosti multitouch implementuje onetouch přímo. V každé variantě je vždy nějaké lepší řešení. A to je přesně to, co tvrdím: pokud člověk implementuje rozhraní na objekt, který nemá schopnosti tohoto rozhraní, udělal špatně analýzu a dekompozici.

Ad CAPS/RTTI souhlasím - u emulátoru se musí nějak vyřešit, aby ex-multitouch umící z něčeho poznat primární dotek nebylo zbytečně emulováno. To však není ve sporu s mým tvrzení, že onetouch by mělo implementovat pouze to zařízení, které opravdu je schopno samo poznat, který klik je primární.

Ono totiž ve skutečnosti onetouch rozhraní není rozhraní pro zařízení, schopné kliknout na jeden bod. To je rozhraní, pomocí kterého jde z každého kliku uživatele určit primární bod, ať již uživatel klikne na jedno nebo pět míst současně.
Z toho mj. plyne, že multitouch není zobecněním onetouch, jde vlastně o zcela jiné zařízení.

---

Ano: programátor má svobodu. Člověk má taky svobodu. To však neznamená, že všechno, co programátor napíše, je dobré, stejnětak, jako všechno, co člověk udělá je dobré. Tvrzení: ať se bude objekt reportovat okolí jak chce, je správně je ekvivalentní tomu, kdybyste obhajoval anarchii a absenci pravidel.

Mohu to brát jako budhismus: špatný čin člověka mu pokazí karmu a v příštím životě na to doplatí. Špatný čin programátora pokazí kódu karmu a při dalším vývoji na to programátor doplatí :-)

836

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 20. 12. 2010, 12:05:19 »

Pokud prohlašujete, že je opravdu lepší, aby každý multitouch po svém (a tedy jinak) implementoval onetouch rozhraní, než aby v systému existovala vrstva, která všechny multitouch rozhraní konzistentně převádí na onetouch (aniž by programátor multitouch musel hnout prstem!), pak se opravdu neshodneme.

Rozdíl mezi námi je v tom, že já jsem řekl několik argumentů, proč je to tak lepší: konzistentnost chování všech multitouch device, možnost centrálního nastavení, menší množství kódu (emulace je napsána jednou a ne x-krát).
Váš argument je pouze "naprosto fatálně se mýlíte" a že mi aplikace pro onetouch nebudou s multitouch fungovat, což ale není pravda (stačí si pořádně přečíst, co píšu, a ne do mých příspěvků projektovat své představy).

837

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 20. 12. 2010, 10:41:11 »

1) To je dokolečka. diskuse nezačla o tom, jak upravit staré rozhraní, ale o tom, jestli je správný návrh jednoho rozhraní do RPG. Na tématu úpravy jsem pouze demonstroval následný problémy (např. to, že pak mám v systému zbytečně dvě rozhraní a tedy staré objekty nejsou kompatibilní s novými).

2) onetouch a multitouch rozhraní jsou opravdu dvě odlišná rozhraní, neboť v době (a i teď) kdy rozhraní vznikalo, nikdo olutitouch nevěděl. Naopak v době, kdy vzniklo rozhraní IMyslivce, tak většina myslivců už měla více psů. Takže v tomto směru analogie nesedí. Jinými slovy: getPos() pro popis myši dostačuje, getPes() pro popis psa nikoli.
Navíc multitouch/onetouch je klíčová charakteristika ukazovátka, počet psů není klíčová charakteristika myslivce - takže dá se čekat, že multitouch a onetouch se budou užívat jinak, zatímco onepes a multipes se budou používat stejně. Proto multipes a onepes by měli rozhraní sdílet, zatímco multitouch a onetouch nikoli.

3) I tak, kdyby v době vzniku onetouch rozhraní vzniklo multitouch rozhraní, bylo by to lepší. Vzhledem k tomu, že drtivá většina zařízení je onetouch, bylo by nejlepší řešení obě rozhraní, plus ve WINAPI převodní funkce z multi na onetouch. Tím by se zajistila konzistence. V současné době každý multitouch může implementovat onetouch jinak a to vede k zmatení uživatele - jednou to vezme první stisk, jednou všechny..... Navíc každý, kdo implementuje multitouch, tak musí psát sám emulaci onetouch, místo toho, co by byla ve WINAPI napsaná jednou.

4) ". Protože klient se tváří, že sice ho zajímá více pozic, ale využije jen jednu. A tuhle informaci server nezná. "
Právě proto ho nebudu nutit si ji vymýšlet. Pokud klient chce pracovat s jednotlačítkovou myší, proč má touchscreen o sobě lhát, že je jednotlačítkovej?? Něco podobnýho je už u myši teď: když zmáčkneš tlačítko u myši, tak zdali je to pravý nebo levý nerozhoduje přeci myš, ale až nastavení ve WINAPI (jestli je to pro praváky nebo pro leváky).
Stejně tak když zmáčkneš a držíš klávesu, tak proč by měla klávesnice rozhrodovat o tom, jak rychle bude stisk opakovat? Taky o tom nerozhoduje, rozhoduje o tom až winapi a emuluje z "multiklávesy" (ONKEYDOWN/ONKEYUP) "oneklávesu" (ONKEYPRESS). Tak proč by multitouch měl rozhodovat o tom, jak má systém interpretovat stisknutí x bodů naráz. To prostě není jeho práce.
Opět jsme u toho - mulittouch není onetouch. Když se mu někdo snaží onetouch rozhraní vecpat, tak je někde chyba v designu.

838

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 19. 12. 2010, 23:02:59 »

Žere mi to příspěvky (než to dopíšu, tak mě to odhlásí a příspěvek je v čudu), tak nemám náladu to posiovat, tak krátce.
---
Blek:
právě, že myš je v 99% klasická myš. 3D myš je jiný objekt - slouží k něčemu jinému.
naopak většina myslivců má dva psy a myslivec s jedním psem se v účelu neliší.

(třeba otázka - když uživatel klikne současně do víc oken, má se event rozdvojit a doručit více oknům nebo se má doručit do okna kam kliknul dříve nebo do okna, které leží v těžišti těch všech kliknutí, nebo...?)

No právě, todle je problém právě, když žádné takové rozhraní není. Protože pak každý multitouch implementuje to jednoklikové rozhraní jinak. Takže nějaká konzistentnost UI je v háji.
Naopak, pokud mám rozhraní pro multitouch, tak není problém napsat jednoduchou emulační vrstvu pro onetouch. A ta jednoduchá emulace bude zpracovávat jak pravá onetouch device, tak i např. první klik z multitouch. A aplikace se může rozhodnout, jestli použije složitější rozhraní pro multitouch, nebo jednodušší rozhraní pro onetouch. Bude však všechno konzistentní a předvídatelné. A ani implementátři ovladačů ani kodéři aplikací nebudou muset napsat řádku navíc....

Pro Ondru: Je to ale opět rozdíl mezi onepsem a multipsem: zatímco myslivec zůstává myslivcem, ať už má jednoho nebo více psů, podstata myslivcovství není v tom mít jednoho nebo více psů, Podstata one/mulitouch device je ale v příjmání právě jednoho či více kliků.
Pokud by existovalo něco jako svébytný myslivec s jedním psem, pak by rozhraní pro něho mělo smysl. Nedovedu si ale v praxi představit situaci, kde by opravdu se vyskytoval právě jen myslivec s jedním psem....

---
Ondra:
Rozdíl je ten, že u 99% formulářů (takže zbylé mohu považovat za jinou entitu) je jasné, co znamená odešli se. Naopak polovina myslivců, když je požádám o psa, tak se zeptaj: a kterýho?

--

1) Pokud navrhnu rozhraní reusabilně, pak ten poměr není 1:n
2) Právě proto, že ten poměr je 1:n :-) tak je daleko lepší přizpůsobit clienta (ten co používá) než server (ten co implementuje). Protože u klienta ho musím upravit na jednom místě, zatímco u serveru budu muset upravit vždy každý nový objekt, který rozhraní bude používat.
Když budu mít objekt, který požaduje chrochtající sedminohé zvíře a budou k nim chodit pes, kočka, člověk, prase a roboprase, tak daleko jednodušší je u toho klienta počítat s tím, že přijde ISavec, než u každého zvířete implementovat, jak má kamuflovat sedm nohou a chrochtání.
Navíc tak získám užitečné rozhraní ISavec, které použiji daleko spíš než sedminožku a ještě navíc se v praxi ukazuje, že potřebuji-li obskurní rozhraní, něco jsem blbě navrhnul.

Rozhraní se proto podle mě mají navrhovat nikoli čistě podle potřeb klienta, ale podle předpokládaných serverů. Kdybych ještě přitvrdil, tak řeknu, že servery inherentně nesou kopy "abstraktních" rozhraní, podle toho, kdo jsou (např člověk je humanoid, savec, pojmenovávatelný, okradnutelný.....). Klient si pak pouze "vybírá" rozhraní ze všech dostupných. A má li vybráno, pak to  abstraktní rozhraní jen programátor "konkretizuje" zapsáním do kódu. Tzn. ne že programátor rozhraní vytváří, ale akorát popisuje patřičné charakteristiky objektů.  Asi jsem platónista.

Např. pořádám hon. Pokud bych použil čistě pragmatické navrhování (dle potřeb klienta), tak řeknu - ok, na honu potřebují pušku a psa. V půlce vývoje ale zjistím, že na vysokou se střílí kulovnicí, zatímco na kachny brokovnicí. A při předání mi řeknou, ale franta má dva psy a vždycky vystřelí z obou hlavní a pro každou kachnu pošle jednoho, to jsme Vám neřekli?
Naopak pokud navrhuji podle serverů, tak si řeknu. Kdo chodí na lovy? No myslivci. A co je důležitého na myslivci ve vztahu k honu: no flinta a pes. Jak je na tom myslivec s flintou a psem? No má jich X. Potřebuji je rozlišovat? No zákazník nic neříkal, tak zatím budu střílet z první flinty a posílat prvního psa....

Hmm, říkal jsem krátce :-( :-)

839

Vývoj / Re: Jste zastánci OOP programování?

« kdy: 19. 12. 2010, 17:13:39 »

Jenže pokud budete přistupovat k rozhraním takto, tak pro každou speciální věc budete muset navrhovat nové rozhraní. Jinými slovy, navržená rozhraní nebudou reusabilní.

V podstatě to, co tvrdím je, že rozhraní je tím více reusabilní, čím více odpovídá tomu, co objekt ve skutečnosti je či jaké má objekt ve skutečnosti schopnosti. (viz to rozdělení dvou typů rozhraní níže).
To ale v podstatě znamená, že dobře navržené rozhraní není jen komunikační protokol, ale vypovídá o vlastnostech samotného objektu.

Problém, na který narážíte s kovářem je ten, že dvě aplikace budou chápat pojem kovář jinak, pro jednoho je to ten, co kupuje železo, pro druhého je to ten, co do něj buší. To jsou ve skutečnosti ale dvě naprosto nesouvisející rozhraní. Tady se opravdu shoduje pouze slovo (identifikátor) a nikoli pojem.
Pokud by ale byly dvě aplikace, které obě potřebují bušiče do železa, tak doufám souhlasíte, že je ideálním stavem, když se podaří navrhnout rozhraní kováře tak, aby obě používali to samé.

----

Když bych to parafrázoval ještě z jiné strany: když si chci s někým porozumět, tak mi nestačí vědět, jaká používá slova, ale co ty jeho slova opravdu znamenají. Tzn. nestačí mi vědět, že mluví anglicky, ale musím znát jeho osobnost.
Pokud rozhraní specifikuje pouze komunikační protokol, tak znám pouze jazyk, takže nevím, jestli to co řeknu urazí, nebo poctí. Když znám i osobnost člověka, se kterým se bavím, tak se mi to nestane. Proto tvrdím, že rozhraní by mělo s sebou nést nikoli jen to, jak daný člověk mluví, ale i kdo je.


-----

Ad IButtonAction je rozhraní, které podle mne zhruba říká: objekt nesoucí toto rozhraní může přijmout pokyn k akci. V tu chvíli mu vyhoví jak tlačítko, tak i formulář. A sem v pohodě :-). Jelikož existuje spousta objektů, které v sobě inherentně obsahují možnost reagovat právě na jednu akci, tak je to rozhraní dobře navrženo. (Narozdíl od myslivce, kdy žádný myslivec v sobě inherentně neobsahuje vlastnost mít právě jednoho psa).

840

Hardware / Re: Hardware pro FreeNAS

« kdy: 19. 12. 2010, 15:59:48 »

Bejt tebou počkám na bobcat, atomy maj většinou málo SATA konektorů, takže budou špatně rozšiřitelný, bobcat bude mít plnohodnotnej čipset.

Co se týče zdrojů, tak dávaj dobrý výsledky cca do 20%, snedistelný do 10%. Pak už maj účinnost pod 60%, takže v podstatě sežerou zbytečně dvakrát tolik. Atom či bobcat v idle bude žát pár watů.... Existuje ještě seasonic 250W, ten už se v těch 10% blíží.
Druhá možnost je 12W zdroj + PC zdroje na 12W, ty maj spotřebu kolem 100W, což by mělo na NAS stačit.