TIP: Přetáhni ikonu na hlavní panel pro připnutí webu
Nevím jestli někdo poradí něco konkrétního. Já můžu doporučit jen obecně.
Prostuduj "Návrhové vzory", v angličtině "Design patterns", od Gang of Four. Není to o řešení Tvého konkrétního problému, ale o způsobech, jak spolu mohou jednotlivé třídy/instance spolupracovat a co takové uspořádání přináší za výhody/nevýhody.
http://cs.wikipedia.org/wiki/N%C3%A1vrhov%C3%BD_vzor
a podrobněji možná tady:
http://www.itnetwork.cz/navrhove-vzory-objektovy-model-architektura
#9 Kit
Ten Lisp je myšlený vážně?
Matus psal, že chce najít uplatnění jako programátor a ptal se na grafiku a tak. Nemyslím, že by po Lispu byla velká poptávka v nabídkách zaměstnání.
Nebo to bylo myšleno jako aby na něm pochopil programování?
Vím že se k pochopení OOP doporučoval Smalltalk, ale nevím o nikom, kdo by to masochisticky zkusil, když je všude tolik tutoriálů k rozšířeným jazykům :)
Tady najdeš tutoriály k jednotlivým jazykům. Pro mne byly dostatečné, abych si rozběhal vývojové prostředí a něco menšího, ale funkčního dovedl udělat:
C#
http://www.itnetwork.cz/c-sharp-programy-hry-zdrojaky
Java
http://www.itnetwork.cz/java-programy-zdrojaky-priklady-navody
C++
http://www.itnetwork.cz/c-plus-plus-tutorialy-navody-programy
Pročti si z toho alepsoň pár prvních článků (nejsou dlouhé) a měl bys znát odpověď na vše, co jsi se ptal. Já doporučuju hned při čtení si ty věci prakticky vyzkoušet. Až si vybereš jazyk, který Ti vyhovuje, můžeš pokračovat studiem nějakých knížek. Dobré (ale v angličtině) najdeš třeba tady:
#15 Dan
Nelíbilo. Tím neříkám, že se tam nemůže líbit Tobě.
V neschopnosti to rozhodně nebude. Šlo o lidi, kteří předtím dokázali samostatně dělat na projektech pro velmi náročné zákazníky (např. banky) a na podobných projektech dělají i teď.
Já Tě od té práce neodrazuju, však to zkus a uvidíš.
Odhlédněme od Unicornu. Když chodíš na pohovory kvůli zaměstnání, není to jen o tom že oni se ptají a Ty dokazuješ svoje schopnosti. Musíš se ptát taky Ty jich a tím získat informace o poměrech ve firmě. Ptát se na stravenky je blbost. Ptej se na školení, na přesčasy, na možnost práce z domu, na to zda dostaneš k sobě seniora a nebo se budeš od začátku plácat sám. Po kolika budete sedět v kanceláři, nebo zda jde o openspace. Jak budeš práci dělat - dojíždět k zákazníkovi a programovat s notebookem na klíně, zatímco Ti zákazník dýchá na krk, nebo pěkně v kanceláři? Mají verzovací systém, testují, mají automatické buildy? Dělají code review? Jak se přijímají úkoly a jak a komu se odevzdává práce - mají něco na bugtracking? Jak se dělá dokumentace změn, jak se sdílejí znalosti (mají třeba wiki)? A pak ty opravdu srandovní věci, třeba: kdo dělal na tom projektu přede mnou a proč už na něm nedělá?
Samozřejmě Tě bude zajímat něco jiného, pokud máš v korporátní firmě vyvíjet informační systém a nebo pokud jsi na volné noze a budeš dělat pro někoho jen webové stránky. Hodně věcí je vidět i bez ptaní, už jen když přijdeš na pohovor. Sedí dvacet lidí namačkaných v jedné místnosti a polovina z nich se překřikuje při telefonování, zatímco druhá má sluchátka a se zarudlýma očima zírá nepřítomně na monitory? Tak to bude super práce :)
To nevím. Déle než 2 měsíce to u nich nikdo z mých známých nevydržel, takže netuším, jaký je tam plat po roce. Nicméně předpokládám, že je pro ně levnější najmout čerstvého studenta zase za nástupák, než ošoupanému přidávat.
Běžná firma se takto nechová, protože zaškolení zaměstnance a získání dostatečné praxe na projektech firmy, než začne být pro firmu užitečný, je časově i finančně drahá záležitost a často na to zkušební doba nestačí. Takže si zkušené lidi neradi nechávají utéct. No a vypadá to, že Unicornu je to jedno. Asi to souvisí s tím, jaké projekty dělají. Nevím. Možná dokonce své zaměstnance "prodávají" na projekty dalších firem (outsourcing), pak by mi to dávalo smysl.
Abych odpověděl na otázku. Čip se ze psa dá vyjmout a dát mu nový. Akorát musíš být veterinář nebo řezník. Zatímco zavedení je bezbolestné a dělá se větší jehlou, k vyjmutí je potřeba skalpel a šití.
Přeprogramovat (nahrát na čip nový údaje) podle mne nejde. Ale proč bys to dělal? Čip se ze psa nevyndavá ani nepřeprogramovává, zůstává mu doživotně.
Dejme tomu, že potřebuješ přejmenovat psa (což je sice absurdní požadavek, ale pro naši úvahu předpokládejme, že to jde). Jméno psa není v čipu, tak není důvod čip měnit nebo přepogramovávat.
Čip je pro psa něco jako pro člověka otisk prstu. Když se ženská vdá a změní se jí jméno, taky se jí nezmění otisk prstu a policajt ji dokáže jednoznačně identifikovat.
Vypadá to, že nevíš, jak to celé funguje, tak to zkusím popsat. Veterinář koupí od výrobce čipy, na kterých jsou jedinečná čísla (dejme tomu tři čipy s čísly 123, 124, 125). Do ordinace mu přijde paní Nováková s Alíkem a nechá si psa očipovat. Veterinář hrábne mezi čipy, vybere z nich namátkou třeba ten 124 a psovi ho píchne. Do papírů mu nalepí číslo čipu (paní Nováková si papíry později odnese) a veterinář zadá do počítačové databáze údaje psa (Alík, majitel Nováková, rasa a kdovícoještě) a mezi těmi údaji zadá i číslo čipu 124.
Když pak policajti najdou zaběhlýho psa, odvezou ho do útulku, tam ho prověří čtečkou a zjistí, že má čip. No tak to číslo čipu 124 zadají do databáze a zjistí, že pod číslem 124 je pes Alík, co patří paní Novákové. Úplně stejně to funguje při převozu psa přes hranice, kdy je potřeba ověřit, zda vyvážíš/dovážíš přesně to zvíře, které vykazuješ v papírech.
No a kdybys teda potřeboval změnit psovi jméno, tak se to udělá v té databázi, z Alíka ho přepíšeš na Pajdu, ale číslo čipu v databázi zůstává u toho záznamu beze změny a psovi pod kůži se kvůli tomu taky nehrabe.
Prostě ten čip funguje jen jako jednoznačný identifikátor, údaje o psu, majiteli a pod. na něm nejsou. Není žádný důvod ho "přeprogramovávat".
Pokud vím, UNICORN je považován za průtokáč. Neustále nasávají nové lidi, protože z druhé strany jim ti "opotřebovaní" pořád odcházejí. Zaměstnanci jsou pro ně jen snadno nahraditelný materiál.
Když k maturitě, tak třeba "čtenářský deník". Dá se začít jednoduše jako taková databáze - autoři, díla (knihy, filmy). Dá se to časem rozšiřovat, např. o příznaky co jsem viděl/četl a co ještě ne, o vlastní poznámky k dílu, o vazbu mezi souvisejícími díly (Krakatit kniha, Krakatit filmy). Nakonec se dají vymýšlet i roztomilé vychytávky, např. načítání televizního programu z webu a upozorňování, že půjde film se stejným názvem, jako kniha, kterou jsem ještě nečetl, apod.
Ať už vybereš jakékoliv téma, vždy začni tím, že uděláš jednoduchý funkční celek, který by sám o sobě byl obhajitelný, a teprve pak ho budeš rozšiřovat. Nejhorší co se může stát je na začátku se velkolepě rozmáchnout a pak to odevzdat nedodělané.
Teď jsem na ty stránky koukal a je to nanic. Ta knihovna neumí převod MSSQL->Oracle, má jen pomocné funkce, které Ti mohou pomoci, pokud bys převod sám programoval:
Translate SQL query between different databases is a very big topic, and there is no such tool available there can do all jobs for you automatically.
Here we provide some guidelines and little utilities(based on general sql parser) to help you to convert SQL statements from one RDBMS implementation to another.
Pokud Ti jde jen o to napsat program, který poběží proti různým databázím, a jestli Ti stačí jednoduché selecty, zkus se podívat jak fungují ORM. Můžeš se tím oprostit od závislosti na konkrétní databázi.
http://cs.wikipedia.org/wiki/Objektov%C4%9B_rela%C4%8Dn%C3%AD_mapov%C3%A1n%C3%AD
Převádět automaticky selecty mezi MSSQL a Oracle je o hubu, radím velkou opatrnost. Ty databáze mají jinou filozofii, není to jednoduše jedna k jedné, že by se jen přejmenovala klíčová slova. Jen pár příkladů. To co projde ve vnitřním selectu MSSQL, nemusí projít v Oracle, protože ten z něj nevidí na vnější. Jak dopadne přičtení dne k datu na konci měsíce v MSSQL a jak v Oracle je legendární. Zatímco MSSQL umí pracovat s prázdným řetězcem, Oracle si ho plete s NULL. A tak můžu pokračovat donekonečna, neb jsem převody mezi nimi dělal. Jesti na to máš nějaký nástroj, tak prima, ale absolutní nedůvěra je na místě. Výsledek vždycky zkontroluj a hlavně otestuj aplikaci, jestli se chová stejně pro MSSQL i Oracle.
#1 kukba159
Ano a ne.
Pro běžné programy (počítačové hry, kancelářské aplikace) to nejde.
Pro některé serverové to je možné. Databázové servery, webové služby apod. je možné napsat/nastavit tak, aby příchozí požadavky rozdělovaly na více serverů a pak je možno výkon zvyšovat připojením dalších mašin - škálovatelnost.
Z Tvé otázky není jasné, na kterou z variant se ptáš.
Jojo, textury v několika rozlišení a případné zmenšování je taky cesta. To co jsem psal se hodí spíš na strategie a stolní hry. Samozřejmě když se dělá simulátor (auto, letadlo), tak kokpit a palubní deska nejde ořezávat dle mého doporučení.
Jen jsem se snažil ukázat možnost, jak se nedřít s množstvím konfigurací, ze kterých si uživatel má vybrat, což je IMHO špatná cesta. Ono to bylo docela dobře použitelné v minulosti, kdy byly jen CRT monitory 4:3 a těch rozlišení bylo jen pár a standardizovaných. V dnešní době kdekdo vyrábí kdeco. Dokonce jsou monitory, které lze otočit na výšku. A člověk nikdy neví, kdy nějakého číňana napadne vyrábět další rozlišení, které dosud nikdo nepoužil. Lepší je, když je okno aplikace "gumové" a dokáže se (aspoň do nějaké míry) přizpůsobit použitému rozlišení monitoru.
Pod pojmem "neomezovat to na rozlišení" si představuju chytře udělané rozhraní. Všechny textury, modely apod. zůstávají jen v jedné velikosti, ale třeba když se vykresluje herní plocha, tak se na větším rozlišení vykreslí větší část. Asi jako když máš Notepad na malém monitoru a pak na velkém - tak písmenka i text jsou stejné, ale na větším se to okno roztáhne a vidíš víc textu bez scrollování. Nejlíp je to vidět na strategických hrách (realtime, turnbased), kde prostě větší obrazovka znamená, že hráč vidí větší část mapy. Však proto si lidi větší monitory pořizují, aby měli výhodu nebo lepší zážitek, a ne aby se jim rozmazalo to co na starém monitoru viděli ostře :)
Co se týče obrázků (třeba podklad v menu), tak místo černých pruhů na okrajích se to dá řešit tím, že se obrázek použije tak velký, jaké předpokládáš největší rozlišení, a pak se na menších monitorech z něho vyřízne menší část podle rozměru monitoru. Obrázek musí mít samozřejmě vhodnou kompozici, aby to důležité bylo víc uprostřed a na okrajích měl už jen nějaké nepodstatné křoví nebo krajinku, aby uříznutí okraje nevadilo.
Těch důvodů je hodně a na většinu si každý přijde časem sám, když je nucen napsat něco většího než Hello world nebo krátký domácí úkol do školy. Velký program se rozdělí na menší kusy, z nich každý řeší ucelenou sadu problémů. Jeden kus může vytisknout dokument na tiskárnu, jeden kus vypočte daně, jeden kus umí vykreslit graf... No a pak ty kusy můžeš vzít a vzájemně použít (vypočtu daně, výsledek vykreslím do grafu v dokumentu a dokument pošlu na tiskárnu). Výhody jsou např.:
Dělba práce - na každém kusu kódu může samostatně pracovat programátor a nijak si nepřekáží s ostatními, protože pracují na nezávislých kusech.
Testování - samozřejmě se lépe testuje každá část samostatně, než celek propletený závislostmi. Dejme tomu že potřebuji vyvíjet a testovat tisk. To se snadno udělá, když mám samostatnou část kódu pro tisk. Horší by bylo, kdybych kvůli tisku musel napřed počítat daně a dělat z nich graf - každá z těchto částí může být ještě nehotová nebo obsahovat chyby, které mi budou při tisku překážet a celý vývoj se tím zdržuje.
Údržba - lépe se opravuje malá část než celek. Jsou blbě čísla? Jdu do té části daní. Mám moc malé písmo v grafech? Jdu do té části pro kreslení grafu. Je to snazší než mít nerozdělený moloch o milionech řádků a nevědět, odkud kam vedou dráty. Navíc se často o program stará někdo jiný než původní autor a vyznat se v cizím kódu není snadné, ani když se dodržují všechny konvence.
Znovupoužitelnost - děláš úkol do školy a potřebuješ kreslit graf. Úkol je samozřejmě po odevzdání naprd, ale tu část s kreslením grafu si schováš a až budeš v budoucnu psát jeden program na výpočet daní a další na zobrazování vytížení sítě, tak sáhneš do šuplíku a máš zadarmo kreslení grafu. A to nejlepší - někdo při používání Tvého programu na počítání daní nahlásí chybu v grafech, tu chybu opravíš a ona je tím pádem opravená i v tom programu na vytížení sítě.
Prostě je těch výhod moc.
Rozděl a panuj! :)
Stejně jako jsi kreslil na formulář, tak kresli na PictureBox. Je to jenom jiná komponenta, postup je stejný.
Kam se kreslí tou metodou Paint? Pokud na formulář, tak je to důvod, že není to kreslení vidět. Picture box na formuláři je nad plochou formuláře, takže kreslit na formulář znamená kreslit pod PictureBox.
Ahoj, možná je to blbost, ale napadlo mne: okenní aplikace (Winforms) používají tzv. partial classes. Prostě máš kód jedné třídy rozdělený do dvou souborů, jeden je editovaný programátorem a v druhém je kód vygenerovaný návrhářem. Toto se u konzolových aplikací nepoužívá. Není možné, že k chybě dochází v tom vygenerovaném kódu, kde nejsou ošetřené vyjímky? Nebo v tom vygenerovaném kódu může být nějaká reference, se kterou nepočítáš.
Ale je to jen nápad.
Já jen doplním, že datum a čas patří do jednoho datetime sloupce. Komplikace, které teď zažíváš při psaní podmínek, jsou ještě sranda. Máš tím ale navíc zaděláno na hnusné problémy, až se budeš muset vypořádávat s přechody na letní/zimní čas nebo s převody mezi časovými zónami.
Podívej se třeba na příklady kódu na MSDN, obhlídni tam to formátování a drž se ho.
Ale je pravda, že dělám v korporátní sféře. Kreativní jedinci to možná vidí jinak :)
Mezera za "if" je správně, "if" není funkce. Stejně jako se mezera píše za "for", "foreach", "using", "switch" apod.
"Break" nepatří na stejnou úroveň jako "case", naopak, patří mezi příkazy "uvnitř" case. Každé "case" nemusí mít svůj "break", prostě to není úplně to samé co uzavírací závorka.
Obecně - doporučuju zvyknout si na defaultní barvy a hlavně defaultní formátování. Teda pokud programuješ (a vždy budeš) na projektu sám, tak je to skoro jedno. Ale jakmile se na projektu podílí víc lidí a každý má nějaké individuální choutky, tak jsou s tím pak potíže. Např. porovnat změny mezi verzemi v SVN/GITu, pokud si každý programátor nastavil jiné formátování a před každým commitem se celý zdroják přerovná pokaždé jinak, je opruz. Nebo koukat někomu přes rameno při revizi kódu, když má každý své barvičky - to se pak člověk mnohem hůř orientuje.
Vlastně ani nemusíš být v týmu, abys zvyk na defaultní formátování ocenil. Předpokládám že čteš různá fóra a tutoriály a tam jsou zdrojáky taky formátované defaultně.
Někomu, kdo nerozumí programování? To se asi tak snadno nedá. Dotyčný by měl napřed alespoň vědět, co je to typ a co je proměnná. Bez toho bych se do vysvětlování seznamu nepouštěl.
Nerozumím, v čem spočívá ta originalita. Blog už má dneska skoro každý a tak není v silách žádného člověka přečíst to, co internet denně vychrlí zdarma ke čtení.
Pokud jde o to placení, vidím tři problémy:
1. část platby si strhává platební systém, část padne na daně a část na hosting/provoz serveru. Při malém počtu platících čtenářů na autory zbyde kulový a dokonce můžeš prodělávat.
2. někteří lidé (např. já) za čtení zásadně neplatí - když na nějakém serveru není článek zadarmo, tak si ho můžou nechat, protože během vteřiny si vygooglím alternativu zdarma.
3. někteří lidé za čtení platí, ale necítí potřebu hledat server s "jedním číslem časopisu", když existují obří sbírky s dobře utříděným obsahem miliónů knih. Sám posuď šíři nabídky a ceny např. na Google Play Books:
http://cs.wikipedia.org/wiki/Google_Play
No a i kdyby ta myšlenka byla životaschopná, tak asi není nutné na zelené louce programovat nový redakční systém. Třeba by šel přiohnout nějaký stávající a podívat se, jestli je možné omezit přístup k článkům - dát práva jen tomu, kdo zaplatí.
http://cs.wikipedia.org/wiki/Syst%C3%A9m_pro_spr%C3%A1vu_obsahu
Možná by na začátek, na vyzkoušení jestli se ten byznys rozjede, stačila dokonce jen nějaká wiki. Prostě s co nejmenší investicí ověřit, jestli by se to dalo rozjet.
Podle mne k přerušení přehrávání dojde vždy, když se načte nová stránka. Takže ten požadavek na rozdílné URL u každé stránky a nepřerušení přehrávání se navzájem vylučují a jeden z nich se musí obětovat. Řešením by asi bylo zahodit to rozdílné URL, mít jednu stránku a dočítat její obsah AJAXem. Ovšem nevím, jestli se to přehrávání nebude kousat i tak.
Tak ještě to nebylo ono. Předchozí sice fungovalo, frontu to vymetlo, ale při ukončování se zavolalo dispose na localPrintServer a tam to opět padalo na nějaká práva. Nepovedlo se mi to vyřešit, nicméně zachránilo mne to, že k defaultní tiskové frontě se dá dostat i bez vytvoření serveru (přes statickou metodu):
PrintQueue printQueue = LocalPrintServer.GetDefaultPrintQueue();
if (printQueue != null)
{
PrintJobInfoCollection jobs = printQueue.GetPrintJobInfoCollection();
foreach (PrintSystemJobInfo job in jobs)
{
job.Cancel();
}
}
Teď už je to snad dobře.
Možná jsem to vyřešil. Spláchnout celou frontu nejde, ale zdá se, že mi funguje projít postupně úlohy v té frontě a zrušit je jednu po druhé:
if (printerQueue.NumberOfJobs > 0)
{
//printerQueue.Purge(); nelze, access denied
PrintJobInfoCollection jobs = printerQueue.GetPrintJobInfoCollection();
foreach (PrintSystemJobInfo job in jobs)
{
job.Cancel();
}
}
Někde jsem četl, že lze zrušit jen dokumenty, které sám tisknu (k cizím dokumentům nemám právo), ale teď to zkouším a ruší mi to vše. Jde o lokální tiskárnu, přihlášen jsem jako administrátor - nevím jestli to má vliv.
Potřebuju vyprázdnit frontu tiskárny, která je připojena lokálně k PC. Znáte někdo funkční řešení?
Já mám zatím toto. Názvy připojených tiskáren zjistím:
ManagementObjectSearcher searcher = new ManagementObjectSearcher(query);
foreach (ManagementObject printer in searcher.Get())
{
string printerName = printer["DeviceID"].ToString();
...
Když znám jméno tiskárny, podaří se mi podívat se do její fronty a dokonce vidím, že není prázdná:
LocalPrintServer localPrintServer = new LocalPrintServer(PrintSystemDesiredAccess.AdministrateServer);
PrintQueue printerQueue = localPrintServer.ConnectToPrintQueue(printerName);
if (printerQueue.NumberOfJobs > 0)
{
printerQueue.Purge();
}
ovšem příkaz Purge v podmínce pak spadne kvůli právům. Vygooglil jsem tedy řešení, kde se fronta otevře s vyššími právy:
LocalPrintServer localPrintServer = new LocalPrintServer(PrintSystemDesiredAccess.AdministrateServer);
PrintQueue printerQueue = new PrintQueue(localPrintServer, printerName, PrintSystemDesiredAccess.AdministratePrinter);
Jenže to mi padá už na příkazu new PrintQueue s chybou:
Attempt by security transparent method 'MS.Internal.PrintWin32Thunk.PrinterDefaults.Dispose(Boolean)' to access security critical method 'MS.Internal.PrintWin32Thunk.PrinterDefaults.InternalDispose(Boolean)' failed.
Nepotřebuju vyřešit konkrétně tuhle chybu. Prostě hledám nejjednodušší cestu, jak smazat tiskové fronty, a tady jsem zakysnul. Jestli máte jiné vyzkoušené řešení, budu za něj rád.
Na rovnoměrnější rozdělení mám takovou fintu. Množinu rozdělit na podmnožiny a teprve na nich rozmisťovat náhodně.
Dám příklad - mějme šachovnici 8x8 polí a chtějme rozmístit 8 figur. Při náhodném rozmístění by se mohlo stát, že budou všechny v jednom rohu. Rozdělím tedy šachovnici pomyslně na čtyři kvadranty (každý o velikosti 4x4 pole) a pak v každém kvadrantu náhodně rozmístím 2 figury (na kolik dílů jsem rozdělil pole, na tolik skupin rozdělím figury). Aplikováno na Tvé potřeby, pokud by některá pole na šachovnici reprezentovala moře a pevniny bylo v kvadrantu méně, upravil bych počet figur podle počtu polí s pevninou.
To s tím ukrajováním, jak popisuješ, bych řekl, že možná povede k rovnoměrné (ne náhodné) distribuci potvor. Nevím jak máš vymyšlený gameplay, ale menší shluky potvor by třeba nemusely být na škodu.
Řešil jsem podobný problém jako máš s rozmístěním příšer. Potřeboval jsem náhodně vybrat testové otázky. Žádná nesměla být vybraná dvakrát. Při kolizi jsem další výskyt nehledal náhodně, jak doporučuje Satik, protože by to mohlo vést k další kolizi. Místo toho jsem vybral další výskyt tak, že jsem našel nejbližší další možné řešení.
Kdybych měl rozmisťovat příšery, vygeneroval bych náhodně pozici a tam se pokusil příšeru umístit. V případě, že je pole už obsazené, pokusil bych se příšeru umístit na některé sousední pole - prohledával bych blízké okolí a postupně prohledávání rozšiřoval, dokud bych nenašel volné místo.
Satikův postup je jednodušší a je rychlejší v případě, že příšery jsou rozmístěné řídce (třeba 4 duchové v pacmanovi, kdyby nezačínali v komůrce). Můj postup je rychlejší v případě, že příšery jsou ve výsledku rozmístěné hustě - pak dochází při náhodném generování k mnoha opakovaným kolizím. V extrémním případě, kdybys měl na mapě jedno poslední volné místo, tak se na něj náhodnými výstřely nemusíš nikdy trefit a program může pořád generovat náhodné pozice, které kolidují.
----------------------------
Příšera v bludišti, to je klišé. Co to něčím ozvláštnit? Budou po tom bludišti chodit? Když potká příšera příšeráka, tak by na to mohli skočit a příšera by snesla vejce, ze kterého by se časem něco vylíhlo :) A tam co se příšera vyvenčí, tak bude úrodná půda, na které vyroste lysohlávka a po jejím požití bude moct hlavní hrdina létat :) Případně by šlo vydráždit příšeru rudým hadrem a rozeběhnutá příšera by měla sílu prorazit zeď :)
Pokud potřebuješ tvořit webové aplikace a PHP lidi máte, tak bych volil Javascript a k němu případně nějaké frameworky (je jich moc, žádný konkrétní nedoporučím, jen se zkus podívat třeba na http://qooxdoo.org/ ať víš co tím myslím).
A co umět testování webových aplikací? Znáš Selenium?
http://cs.wikipedia.org/wiki/Selenium_(software)
Pokud umíš programovat v některém z jeho podporovaných jazyků, je to prima, ale i bez znalosti programování se dá Selenium použít - na jednodušší věci stačí firefox s nainstalovaným pluginem.
Nevím jestli je to přesně to co myslíš, ale možná zkus hledat
Color Variations
Obrázky jak to vypadá:
#1 Matěj Andrle
Prosímtě, nezlob se, nestudoval jsem to do hloubky - co vlastně potřebuješ vyřešit? Nalezení cesty v existujícím bludišti, nebo vyrobit nové bludiště?
Mrkni sem:
http://www.itnetwork.cz/algoritmy-pro-bludiste-nejkratsi-cesta-a-generovani-nahodneho
Zejména ten článek o generování náhodného bludiště se mi hodně líbil.
Neskáčeš náhodou na políčko, ze kterýho jsi přišel? Zdá se mi, že jednu path odebereš, ale vzápětí se čtyři přidají (a měly by se přidat 3, protože jedna je asi ta, ze které se přišlo).
Jestli ne, omlouvám se, je to jen první dojem.
#11 peter
Jakmile se mluví o tom, že by něco mohlo být "nápadné", znamená to, že se spoléháte na to, že útočník nezná postup, jak text dešifrovat. To je špatné, protože:
1. na postup lze přijít matematickými metodami - to že tvůrce šifry nevystudoval matfyz a tudíž nemá ponětí, že to jde, ještě neznamená, že to nejde. Nemyslím to jako urážku, někdo si prostě sám nespraví auto, někdo si sám nezaplombuje zub, no a někdo si sám nespočítá hash - na tom není nic špatného, jen je třeba si to uvědomit.
2. na postup lze přijít snadno reverzním inženýrstvím - pokud získám program, který umí data dešifrovat, tak ho prostě disasembluju (nemusím být matfyzák, u .NET aplikací je to brnkačka i pro nezletilé).
A proto: každé šifrování, které si někdo navrhne sám doma, bude zákonitě horší než to, které máte vestavěné v .NETu. Já vím, že ty nápady s posouváním a přehazováním písmenek (Cézarova šifra, šifrovací tabulka apod) fungovaly na letních táborech. Mějte na paměti, že tam byli vašimi protivníky stejně staré děti a ne týmy profíků s akademickým vzděláním. Jestli si to vymýšlíte pro zábavu, OK, to je v pořádku. Jen byste měli mít představu, že takové podomácku vymyšlené šifry ve skutečnosti nejsou bezpečné ani pro Vaše soukromé účely, natož pak pro nějakou firemní zakázku, neřku-li banku nebo státní instituci.
Pokud potřebuješ opravdu šifrování, použij raději to co už je hotové. Součástí .NET je podpora šifrování, najdeš to v namespace System.Security.Cryptography.
http://www.aspnet.cz/Articles/147-symetricke-sifrovani-aes-rijndael-v-net.aspx
Pokud jde o neprolomitelnost, běžný člověk (amatér bez hlubokých znalostí matematiky) rozhodně spolehlivější šifry nevymyslí. Pokud jde pouze o nečitelnost (a neprolomitelnost není nutná), pak můžeš použít obyčejné XORování. Ale proč, když už tam ten šifrovací namespace stejně je a stačí zavolat jednu funkci...
Vlastní šifrování nevymýšlej. Amatérsky vymyšlené šifrování (obvykle spočívající v náhradě nebo přesouvání nějakých písmenek) nechrání text silou šifry, ale pouze předpokládá, že útočník nezná algoritmus dešifrování. A algoritmus dovedou experti najít, jsou na to šikovné metody (např. frekvenční analýza). Skutečná síla spočívá v tom, když je znám algoritmus a přesto bez znalosti klíče není možné text dešifrovat.
Přesně tak, to co potřebuješ, se jmenuje rekurze.
Rekurze znamená, že metoda (funkce) ve svém těle volá sebe samu.
Často se jako příklad uvádí výpočet faktoriálu. Zavoláš funkci pro výpočet faktoriálu z čísla x a uvnitř té funkce je napsáno x * faktoriál z čísla (x-1).
Ještě je další možnost. Vytvořit třídu s jednou (prázdnou) metodou jako předka. Z tohoto předka pak dědit potomky, kteří dle potřeby přepisují tu původně prázdnou metodu. Ve svém dotazu (první příspěvek) předpokládáš, že budeš načítat seznam nějakých čísel. Místo čísel bys mohl ze seznamu načítat názvy tříd, pokaždé pak vytvořit instanci třídy, jejíž jméno znáš, a zavolat na ní tu metodu.
Jak se získá instance třídy, když znáš její název, je popsáno třeba tady:
http://stackoverflow.com/questions/223952/c-sharp-create-an-instance-of-a-class-from-a-string
http://stackoverflow.com/questions/493490/converting-a-string-to-a-class-name
© 2003–2024 Programujte.com