Diskuze: Desktop Launcher
V předchozím kvízu, Test znalostí C# .NET online, jsme si ověřili nabyté zkušenosti z kurzu.
Já mám všechny často používané programy v dolní liště vedle startu,
tu lištu mám roztaženou na dva řádky, i když teď zrovna mám obsazený
jen jeden řádek, takže já bych to asi nevyužil 
Tak já bych využití rozhodně našel 
Vypadá to docela užitečně.
Co přesně se skrývá pod ikonkou chromu?
David Jančík:4.3.2013 20:39
Když klepnu na ikonku chromu, spustí se mi chrome Si nadefinuješ jak to má vypadat.
Naházíš si tam co chceš, jaký chceš ikonky, jaký chceš názvy...
Vojtěch Pospíchal:4.3.2013 20:43
Tak to je rozhodně užitečný . Každopádně já bych spíž ocenil aby to umělo takové věci jako
otevřít nějaký předem nadefinovaný seznam stránek. Kupříkladu kliknu na
chrome a vyjede mi seznam skupin stránek které bych si chtěl otevřít.
Třeba pracovní kdy by se mi otevřel google, gmail atd...
Luboš Běhounek Satik:5.3.2013 11:48
Aha, tak to pak jo, mě to tam nijak neruší
99% programátorů debugování používá, takže IDE je asi pro těch 99%
zbylých programátorů
Luboš Běhounek Satik:5.3.2013 12:16
Evidentně vidíš pod pojmem debugování něco jiného než já, jinak by
jsi nemohl napsat, že debugování je pracné a testování pohodlné
Testy píšeš vždy, i když je testovaný kód správný, což mi přijde jako zbytečná práce navíc.
Debugování provádíš až ve chvíli, kdy narazíš někde na chybu -
třeba nějaká funkce vrací něco jiného než by měla - tak ji jen
prokrokuješ příkaz po příkazu a najdeš místo, kde je chyba
Myslím, že je evidentní, která metoda je pohodlnější a stojí méně
práce
Samozřejmě jsou situace nebo části programu, kde je důležité, aby nebyla žádná chyba, tam používání testů schvaluji.
David Hartinger:5.3.2013 12:49
To je debata mezi dvěma extrémy Když uděláš v metodě chybu, může se to projevit úplně jinde,
od toho jsou testy, chyba se ti vždy neprojeví jen na té části, kterou teď
zrovna píšeš a testuješ. Test uděláš jednou a pokud si něco rozbiješ,
přijde ti na to starý test, co jsi dělal předtím.
Teoreticky bys opravdu při dobrém pokrytí testy a dekompozici na jednoduché metody debugování nepotřeboval, prakticky to bude ale vypadat trochu jinak a nahlížení do obsahu proměnných se hodí, stejně tak i krokování.
Luboš Běhounek Satik:5.3.2013 13:36
Zase více kódu (testy), větší šance udělat chybu, to se pak musí
špatně hledat, když uděláš třeba chybu v testu a honíš neviditelnýho
draka, ne?
Luboš Běhounek Satik:5.3.2013 14:36
Bylo prokázáno, že při TDD je zpravidla prováděno více úhozů.
Ano, myslím, pokud to není nějaký kód, kde je cílem nulová chybovost.
Psát metody na 1000 řádek zvyklý nejsem, v takovém špagetovém kódu
bych se nevyznal, mám rád přehlednost (I když to tak občas v mém kódu
nevypadá, hlavně po různých úpravách ).
Drahomír Hanák:5.3.2013 15:10
Podle mě jsi moc nepochopil ten princip testování. Nejde o to testovat funkčnost, která právě teď funguje, ale funkčnost, která by někdy fungovat nemusela (tj. většinou celý kód krom pár věcí - samozřejmě, jak už bylo řečeno, nejde testovat všechno). Kód, kde je cílem nulová chybovost, je alespoň pro mě (a klienty) každý. Nulové chybovosti nedosáhnu nikdy, ale testování mi k tomu pomůže. Krom toho mi testování pomohlo psát lepší kód. Nutí člověka zamyslet se nad tím, co dělá.
Celkem bych i věřil tomu, že když testuješ, napíšeš méně kódu, protože když netestuješ, máš mnohem větší pravděpodobnost chyb. Celkem mě taky zaráží, že to v C# není běžné. Myslel jsem, že právě v C# se už testování bere jako samozřejmost.
Ale teď k tématu
David Jančík plánuješ zveřejnit zdrojový kód?
Luboš Běhounek Satik:5.3.2013 15:33
Já chápu, jak TDD funguje, ale nemyslím si, že se hodí vždycky, je to jen jeden z možných postupů a rozhodně není ten jediný správný, podobně jako není jediné správné objektové programování, prostě jsou situace, kdy se hodí jeden postup a situace, kdy se hodí jiný postup.
Dalším problémem je to, jak to ve většině firem funguje - tam si o
těchto věcech, které vás učí ve škole, můžete často nechat jen
zdát.
TDD jsem zatím nepotkal nikde (a sám programovat přes TDD je asi nesmysl),
návrh aplikace většinou není moc detailní a požadavky na (i docela velké)
změny přicházejí často.
Přepisovat kvůli nějaké větší změně půlku testů by mě asi moc
nebavilo.
Navíc nikdy nevíte, jaké spolupracovníky do týmu dostanete, občas člověk
nestačí zírat, čeho jsou někteří "programátoři" schopní
Samozřejmě každý se snaží mít počet chyb minimální, také občas nějaký test napíšu, ale jen pro nějaká kritická místa, kde je větší pravděpodobnost, že jsem nějakou chybu udělal.
Může to výborně fungovat, pokud máte pevné a neměnné zadání (nebo jen opravdu malé změny) a pokud váš tým včetně vedení je na TDD připravený, ale v praxi to tu zatím moc nefunguje.
David Jančík:5.3.2013 15:51
Jop, když je zájem, přidám ho Jen musím udělat ještě nějaké úpravy, trochu to zjednodušit a
popsat. Je to tam samá rekurze Ale celkem jsem si to tam zjednodušil. Když hledám cestu k danému
prvku:
DesktopLauncher
- Menu1
- SubMenu1
- SubSubmenu1 -> chci cestu sem
- SubMenu2
- Menu2Tak jdu jako v rodokmenu, od potomka až po všechny známé předky. A abych nemusel data dávat do nějakého Listu, tak využívám rekurze:
private string GetParrentText(MenuItemExtended menu)
{
string prefix = "";
if (menu.Parrent != null)
prefix += GetParrentText(menu.Parrent);
if (menu.Parrent == null)
prefix = "DesktopLauncher." + prefix;
else
prefix += menu.Text.RemoveInvalidCharacters() + ".";
return prefix;
}To si myslím, že sem celkem vyšéfil. Teď mám jiné povinnosti, ale
myslím, že v pátek bych to mohl vypustit
Zobrazeno 39 zpráv z 39.