Diskuze: LitheDoe

Tvůrce

Zobrazeno 51 zpráv z 51.
//= Settings::TRACKING_CODE_B ?> //= Settings::TRACKING_CODE ?>
Oprava - jak z obrázků vidíte, docházelo k zkracování inteligentně nezalamovatelných řádků.
Soubor zde:
http://www.ulozto.cz/…lithedoe-zip
(Samozřejmě dále budu updatovat po velkých krocích.)
Moc se omlouvám - skutečně poslední oprava - všechno se muselo sejít ve
chvíli, kdy už to mělo být OK... Teď už fakt končím.
Možná by nemuselo bejt špatný schovávat menu a vyvolat ho přes nějakou
klávesu, třeba když jsem prohlížel devbook, tak jsem musel pokaždý
seskrolovat pod menu, po každý změně stránky a začalo to bejt otravný
.
A ještě bych upravil adresní řádek - na stránku bych skákal i jen po zadání adresy - bez příkazu go - stačí vzít string po první mezeru a pokud to nevypadá jako žádný vnitřní příkaz, tak to načíst jako stránku.
Proto používej nt - a přecházej mezi taby (next/prev/tab) - tím ti zůstane pozice původní stránky nezměněna. Také si můžeš nastavit rychlost scrollování, či používat PageUp/Down Každopádně plánuji jak panely, tak dolní statusovou lištu. Takže i ProgressBar načtení stránky. Napsal jsem pouze nejbližší změny.
Pro lepší orientaci bude mít seznam tabů obdobný dialog jako links. (v budoucnu i forms)
Jo a s tou URL jako příkaz - dost blbě by se s tím pracovalo - tak 2
písmena tě nezabijí - ne?
Můj zákazník = můj pán... => kouknu na to.
A je to! HTTPS oficiálně
jede. Můžete tedy konečně prohlížet třeba Facebook. Bohužel na
formuláře nemám čas - škola. Ale snad to ještě dnes stihnu...
Svého parseru jsem se nevzdal - chybí mi tam jen jedna kravina - takže si to pak porovnám - a nechám, co z toho vyjde lépe... Zdroják dám do funkční verze. Zde to je jen pro nápady, bugy, atd.
Zapomněl jsem dodat, že krom pár chybiček jsem přidal i ten příkaz tabs. Nyní jsem ještě opravil další chyby. Až dodělám formuláře, dám to již do normálního článku - i se zdrojáky.
Ten tvůj slavný HtmlAgilityPack neumí zpracovat formuláře - nenalezne jejich koncovou značku...
HtmlAgilityPack není můj. Tag form samozřejmě zpracovává stejně jako jakýkoliv jiný tag, nebo jsem nepochopil, jak to myslíš?
Nedokáže si poradit s errorem - nenačte zbytek, který mu patří. To tem
můj bez problémů...
Já tam vidím MonoDevelop, na něm linuxovou konzoli, ale .NET nikde.
Aha, to je Linux, já viděl .cs soubory a útržky c# kódu, tak jsem
předpokládal taky .NET
Zrovna jsem se dočetl, že .NET nemusí být jen na MS platformě, ale je dán specifikací bajtkódu. Takže jsi měl vlastně pravdu. Je to .NET. Výsledné programy se dají spustit na Linuxu i ve Windows. Jen je to na linuxových OS minoritní záležitost.
Jak je to na Linuxu netuším, Linux jsem zkoušel před sedmi lety a nezaujal mě, tak se o tenhle směr moc nezajímám.
Když jsem Linux poprvé zkoušel asi před 15 lety, tak mě také moc nezaujal. Dnes sleduji, jak MS uvádí jako novinky vlastnosti, které byly na Linuxu běžné už před 5 lety.
To mě ani tak nevadí, já jsem na OS (co se týká funkcí) celkem
nenáročnej, takže jsem spíš proti velkým novinkám (kterým se nedá
vyhnout), protože se zas musím učit něco nového
To je taky jeden z hlavních důvodů, proč mě Linux nezaujal - než bych se s ním naučil aspoň na úroveň srovnatelnou s tím, jak se teď orientuju ve Windows (žádný zázrak, ale na vše co potřebuji mi to stačí), než bych našel alternativy programů, které používám, než bych se s nima naučil, tak by to zabralo spoustu času...
Já bych Linux klidně používal, ale nikdy mi moc dobře nefungoval, vždy jsem měl problém s nějakým kusem HW nebo mi prostě najednou spadl.
Je fakt, že než jsem si vytunil své linuxové systémy, tak to byla trnitá cesta. Dodnes si vylepšuji Vim o různé šablony, makra a další doplňky, protože bez nich je Vim horší než IDE.
Já si Linux složil jako Puzzle - baví mne právě to, že se pořád něco děje... Ale nevžil jsem se tak dobře jako do C# do žádného jiného jazyka - tak zatím dělám majoritně v .NET... Bash Shell skripty se občas hodí - ovšem nenašel jsem s k nim cestu - menší věci dělám v interpretovaných jazycích - JS, Python,... (Zajímavé byly začátky s IDLE.)
Každopádně k Windows se již nikdy nevrátím. (Měl jsem nedobrovolnou přestávku, která jasně ukázala, že Windows není pro mne.) Neberte mne jako jiné fanatiky - schválně píši, že Windows není pro mne - ne že je to strašné, že by měli zrušit Microsoft, atd... Každý má své, jen některé důvody se dají brát jako pokus o satiru...
A tos mi připomněl, že jsem furt ještě nějak nepochopil, proč jsi mi
psal, že vyvíjet v IDE je odvážné... Teď už to teda asi chápu - že jako
frajeři kódujou v textovym editoru? V tom případě tady nejde o odvahu, jen
o stupeň masochismu
Správně. Frajeři IDE nepoužívají, protože si vystačí s textovým editorem. Nejlépe Vim nebo Emacs. Ostatní editory jsou jen náhražkami Notepadu.
Minulý týden jsem si vyzkoušel Eclipse i NetBeans. Ani jedno mě neoslovilo, připadlo mi to takové těžkopádné.
Eclipse a Netbeans přišly težkopádné i mně (dělal jsem v nich PHP a
Javu), Visual Studio je (na čistý C#) svižné, s ASP.NET už je to horší
No, to je asi co člověk to názor. Já si tedy myslím, že minimálně v případě .NET Visual Studio udělá opravdu hodně práce za člověka. Ale samozřejmě v hobby sféře na tom tolik nezáleží. Já bych tedy bez intellisense už programovat nechtěl. Máme 2013...
Intellisense mi také vyhovuje. Proto používám Vim. Udělá hodně práce za člověka. Máme přece rok 2013.
Vůbec netuším, jak moc je Vim propojený třeba s kompilátorem apod., ale ukazuje třeba syntaktické chyby v kódu při kompilaci?
Jak řešíš debugování - třeba krokování programu apod?
Vim mám propojený z kompilátorem přes Make, ale možností je víc. Každý si to udělá tak, jak mu to nejlépe vyhovuje. Barví syntaxi, takže první filtr je už v editoru a chyby ukazuje přímo kompilátor. Dá se nastavit, že kurzor naběhne na místo chyby, ale já to nepoužívám.
Když používám TDD, tak debugování ani krokování programu nepotřebuji. V TDD dělám i profilování.
Když používám TDD, tak debugování ani krokování programu nepotřebuji.
Hustý
No co? Testy to udělají všechno za tebe. Záleží jen na tom, jak dobře je umíš psát.
Můžu se zeptat, jen pro představu, jaký cca (rozsahem, určením...) systém jsi takhle někdy dokončil? Nemyslím to nějak rejpavě, jen pro mě je tohle trochu nepředstavitelné. Neumím si představit, jak bych dělal takový test třeba na práci se síťovým streamem, což aktuálně řeším a bez breakpointu a masivního krokování bych nedal dohromady asi nic...
Připojuju se k dotazu m.tecla, bez breakpointu, krokování a nahlížení
do obsahů proměnných bych se i u některých "jednodušších" věcí asi
zbláznil.
Např. v minulém zaměstnání, kde jsme dělali na jednom projektu do škol
(70 000 řádků), kde se využívalo renderování 3D scény, síťová
komunikace, více vláken, fyzikální engine apod. si bez těchto debugovacích
pomůcek představit moc nedovedu, i s nimi se občas některé chyby hledaly
dost špatně.
Rozsah není podstatný. Vždy se testuje jen malá část kódu, která je do cca 15 řádek a vzniká postupně. Proto jsem také psal, že se nemají psát delší metody než těch 15 řádek, protože na těch delších by se už muselo krokovat a dávat breakpointy.
Luboš Běhounek Satik: V krátkých metodách je jen minimum proměnných. Místo nahlížení do proměnných si je nechám vypisovat testem. Po odladění to vypisování v testu nahradím assertem.
Zajímavé, zajímavé... Musím říct, že se mi myšlenka TDD hrozně líbí, ale nějak často narážím na to, že bych měl testy výrazně rozsáhlejší než samotný program, na což v praxi prostě nebývá čas. Tedy čistý TDD, to znamená nejdřív test a potom kód, jsem nezkoušel, ale párkrát jsem se snažil pokrýt testy existující funkcionalitu, abych měl jistotu, že nějakou změnou nerozložím něco funkčního. Ale dělat mockupy na databázi, nedej bože nějak souběžně testovat server a klienta, to mě zkrátka nějak nepřesvědčilo o efektivnosti.
Moment, teď mě něco napadalo - ty v tom tvém textovém editoru předpokládám nemůžeš zapnout break na výjimkách uvnitř catch? Tak to už si ale vůbec neumím představit - někde na vrchu ti vyskočí výjimka, která probublala bůh ví odkud a ty nemůžeš ani krokovat, ani zastavit na té výjimce. Tak tohle nemůže být v reálu efektivní, to se na mě nezlob...
A ještě se připtám - píšeš takhle i vícevláknové aplikace?
Testy mám obvykle 2× delší než produkční kód. Čas ušetřený nepsáním testů strávíš ručním laděním. Testy jedou automaticky a prověřují program i po změně běhového prostředí. Tím ten čas šetří. Vždy je něco za něco.
Pokrývat testy stávající funkcionalitu je pozdě. Program se musí přizpůsobovat testům, nikoli naopak.
Mocky na databázi dělám běžně. Je to jednodušší, než to na první pohled vypadá. Server a klient se testují zvlášť.
Výjimku si mohu vyvolat kdy chci jakou chci. Stačí si napsat vhodný mock, který podstrčím konstruktoru přes DI. Výjimku vzniklou v produkčním kódu si zase mohu odchytit v testu.
Jak chceš jinak ladit vícevláknové aplikace než přes TDD? Jak chceš jinak simulovat race condition? Jak simuluješ odpojenou databázi nebo chybné heslo? jak simuluješ chybnou strukturu databáze? Bez TDD to moc nejde.
Obrovská výhoda testů je, že se napíší jednou a poté testují sami. Zatímco při ručním testování je třeba aplikaci testovat stále znovu a znovu na ty samé funkčnosti, které mohla rozbít nová funkčnost.
Ono to zpočátku připadne dost nelogické psát nejprve testy a teprve pak program. Jenže když ty testy pojmeš jako specifikaci zadání, tak už to nějakou logiku získá.
Když si pak třeba klient stěžuje, že při určité kombinaci hodnot program dává špatné výsledky, tak nejprve testy rozšíříš o tyto vstupní hodnoty (případně o mocky třeba na různé stavy databáze) a doplníš assert na správnou výstupní hodnotu.
TDD hlavně donutí programátora psát kusy kódu tak, aby byly mezi sebou provázány pokud možno pouze přes nějaká rozhraní. Na taková rozhraní pak lepíš z jedné strany mocky a z druhé strany testy.
Zní to zajímavě, ale přijde mi, že ta časová režie psaní testů musí být hrozně velká (trojnásobek kódu), nehledě na to, že třikrát více kódu = větší šance udělat chybu, třeba i v unit testech.
A předpokládám, že i u TDD se může stát, že člověk něco opomene otestovat, nebo je nějaký postup, kdy se to stát nemůže.
A hlavní problém vidím v tom, že většině zákazníků (pokud to není nějaký bankovní/armádní software) nejde o kvalitu, ale hlavně o cenu, takže ve většině vývojářských firem se věci jako unit testy nepíšou většinou vůbec nebo jen pro nějaká problémová místa kódu.
Kit: ještě k tvému podpisu ("Hodnotit kvalitu programu podle délky kódu
je stejné jako hodnotit kvalitu letadla podle hmotnosti.")
Je sakra rozdíl mezi tím, když sám programuješ malou aplikaci o pár
tisících řádků, kterou si navrhneš, napíšeš testy a naprogramuješ -
pak je jednoduché mít ten program kvalitní, ale u velkých projektů se něco
takového dodržuje mnohem hůř - u programů, které mají třeba i stovky
tisíc řádků, dělá na nich spousta lidí, kde každý má na programování
jiný názor a jiné znalosti, vedení jde jen o to, aby to bylo co nejdříve a
stálo to co nejmíň peněz...
(Na konci druhého odstavce mého příspěvku měl být místo tečky otazník.)
Režie psaní testů je časovou investicí, která se zpočátku moc nevrací, ale po zaběhnutí je součet časových nákladů testy+aplikace menší než součet aplikace+ladění. Jednotkové testy sice nenahradí testy integrační, ale ty jsou pak o poznání jednodušší.
Chyby v unit testech samozřejmě dělám také, ale přijde se na to hodně brzo, takže není problém. Psaní testů a aplikace se neustále střídá, za hodinu to může být i několik desítek iterací.
Pokud máš kvalitní zadání, v testech na nic nezapomeneš.
Podstatné na TDD je, že ladění děláš ručně, ale testy děláš automatizovaně. Sice napíšeš 3× více kódu, ale při ladění uděláš těch úhozů na klávesnici stejné množství a dvě třetiny nenávratně zmizí. Takže ve výsledku vidíš jen tu třetinu výsledného kódu. U TDD ti testy zůstávají napořád.
Ano, je velký rozdíl mezi Cesnou a Jumbem. To druhé je větší, těžší, kvalitnější a unese víc cestujících. Hmotnost však nemůže být jediným kritériem.
V programování je to stejné. Někdo napíše program na tisíc řádek a já udělám totéž na třech řádcích třeba využitím té správné knihovny. Znamená to snad, že jeho program je kvalitnější, když je delší?
Vedení vůbec nemusí tušit, že děláš TDD. Vývoj to nezpomaluje, ale zrychluje.
Kvalitní zadání jsem snad ještě neviděl, často ani zákazník
pořádně sám neví, co chce.
A když se nějaký základní návrh dělá, tak je to většinou zhruba na
úroveň důležitých tříd a jejich nejdůležitějších funkcí.
Některé problémy se podle mě při návrhu ani najít nedají, takže ti
je testy neohlídají.
Např. jsme v předchozím zaměstnání ve hře řešili problém s fyzikou,
kdy jsme využívali cizí fyzikální engine a nastal problém, že když se
hráč přiblížil k domečku, tak ho to občas vystřelilo někam do
vesmíru.
Ve hře je také možné do věcí kopat a nakonec jsme zjistili, že stačí
dostatečně dlouho kopat do domečku a ten (i když je zafixovaný, takže se
sám hýbat nemůže) se jakoby "nabije" energií a při kolizi ta obrovská
energie hráče odmrští někam pryč.
I kdybych měl celý program sebelépe zadaný, tak by mě tohle nenapadlo.
Ladění jsme většinou prováděli až ve chvíli, kdy něco nefungovalo, nebo fungovalo špatně/pomalu, rozhodně jsme každou nově přidanou věc neladili hned ručně, takže pořád jsme cca na trojnásobku práce - na jedné straně psaní kódu a ladění chyb (až když se vyskytnou) a na druhé straně psaní testů vždy, psaní kódu a ladění chyb (až když se vyskytnou).
K té délce programu: já tím nechtěl říct, že delší program je
kvalitnější, ale že u krátkých programů je mnohem jednodušší je
udržet kvalitní, protože na tom většinou dělá jen jeden nebo dva lidi a
celý program je jednodušší -> menší prostor k udělání chyby.
Na těch dlouhých programech obvykle dělá mnohem víc lidí, a jsou prostě
mnohem komplikovanější -> více prostoru na udělání chyby.
Zobrazeno 51 zpráv z 51.