tag:blogger.com,1999:blog-3408745507091232422.comments2023-03-05T06:57:23.320+01:00Robert DreslerRobert Dreslerhttp://www.blogger.com/profile/16401744220939465418noreply@blogger.comBlogger104125tag:blogger.com,1999:blog-3408745507091232422.post-38901235918154553142023-02-09T06:01:55.124+01:002023-02-09T06:01:55.124+01:00Каждый, у кого есть инстаграм аккаунт, хочет, чтоб...Каждый, у кого есть инстаграм аккаунт, хочет, чтобы его учетная запись была наиболее успешной и востребованной. Достижение подобных результатов может оказаться сложным, в случае если применять только естественные виды получения популярности - <a href="https://krutiminst.ru/" rel="nofollow">накрутка лайков в инстаграме ru</a>. KRUTIMINST.RU - это сайт, позволяющий наращивать количество подписчиков, лайков, просмотров и комментариев в Instagram.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-75004182506810982592022-02-01T21:09:46.077+01:002022-02-01T21:09:46.077+01:00Super počtení, nechystáš pokračování s popisem &qu...Super počtení, nechystáš pokračování s popisem "starého juniora" - jaký přístup k práci, vlastnosti, prostředí může způsobit, že se vývojář přestane vyvíjet a zůstane juniorem? Lubošhttps://www.blogger.com/profile/00788896445068233908noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-53147048011906020672018-02-23T10:00:17.493+01:002018-02-23T10:00:17.493+01:00A kontravariance a kovariance u Liskovove se speci...A kontravariance a kovariance u Liskovove se specificky tykaji dedicnosti, uvedene priklady jsou zcela irevevantni. Vetsina jazyku neumoznuje kontravarianci parametru metod v potomcich (viz Wiki, i tam to je a to Wiki je zdroj vetsinou k nicemu).Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-4665160038376225752018-02-23T09:54:59.767+01:002018-02-23T09:54:59.767+01:00Celý článek bohužel ukazuje na nepochonení nejen L...Celý článek bohužel ukazuje na nepochonení nejen Liskovové, ale i Martina - obdélník NENÍ A NEMŮŽE být bázovou třídou pro čtverec, o tom je celý slavný rectangle - square příklad i motivace!!!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-58435307074315077972016-10-25T21:40:49.771+02:002016-10-25T21:40:49.771+02:00Ahoj Svaťo,
díky za komentář. Fajn řešení. Měl by...Ahoj Svaťo,<br /><br />díky za komentář. Fajn řešení. Měl bych k němu pár připomínek na zamyšlení:<br />- Zdá se mi, že factory toho ví příliš hodně. Obsahuje totiž definici všech pravidel. Možná tak porušuje SRP ze SOLID.<br />- OCP ze SOLIDu nám říká, že každá případná změna by měla mít co nejmenší dopad na stávající implementaci. Měla by ji ideálně pouze rozšiřovat. Tento princip se často zajišťuje právě separací do samostatných tříd. Přidat nové pravidlo ve tvém případě znamená rozšířit rozhranní RuleFactory o metodu createNewRule() a naimplementovat ji. Při mém řešení F by vznikla nová třída NewRule a NextGenerationStateCalculatorF by jen přidal instanci této třídy do _rules.<br /><br />Pokud by pravidla v F byla definována jako disjunktní (museli bychom upravit implementaci NoReproductionRule), pak by na pořadí nezáleželo a mohli bychom využít IoC container a dependency injection:<br /><br />public NextGenerationStateCalculatorF(IEnumerable rules)<br />{<br /> _rules = rules;<br />}<br /><br />V takovém případě bychom změny při přidání nového pravidla provedli jenom v příslušných XRule třídách. A v NextGenerationStateCalculatorF by k žádné změně nedošlo.<br /><br />Robert Dreslerhttps://www.blogger.com/profile/16401744220939465418noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-25966069904967128122016-10-25T11:22:30.901+02:002016-10-25T11:22:30.901+02:00Ahoj,
co říkáš na další zamyšlení nad kódem? Jedn...Ahoj,<br /><br />co říkáš na další zamyšlení nad kódem? Jednotlivé implementace `RuleBase` nijak nespecifikují jeho chování, jde podle mě o zneužití dědičnosti. Přijde mi, že potřebujeme jen pravidlo konfigurovat, ale neměnit jeho chování (ponechme stranou, že žádné pořádné chování nemá).<br /><br />Co kdyby existovala `Rule`, která bude mít stejnou funkcionalitu jako `RuleBase`, jen nebude abstraktní? Tím by šla sama o sobě i otestovat.<br /><br />Jednotlivá pravidla pak může tvořit továrna. Kód nebude tratit na přehlednosti, nebudeme zneužívat dědičnost a snížíme počet tříd.<br /><br />Výsledek by mohl vypadat cca takto:<br /><br /> _rules = new RuleBase[]<br /> {<br /> ruleFactory.createUnderPopulationRule(),<br /> ruleFactory.createSurvivalRule(),<br /> ...<br /> }<br /><br />class RuleFactory {<br /><br /> public createUnderPopulationRule(): Rule {<br /> return new Rule((state, neighbours) => state == CellState.Dead && neighbours == 3, CellState.Live);<br /> }<br /><br /> ...<br />}<br /><br />SvaťaAnonymoushttps://www.blogger.com/profile/16306668769992193336noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-75841898342636786412015-05-24T07:29:01.522+02:002015-05-24T07:29:01.522+02:00Ahoj Michale, díky za komentář. Jen abych to vysvě...Ahoj Michale, díky za komentář. Jen abych to vysvětlil. Tento blogpost nechce popírat objektivní pozitiva on-site práce. Chtěl jsem probrat pár argumentů, které se rády používají proti remote worku. Často je ale samotný problém někde jinde.<br /><br />Uvědomuju si důležitost socializace týmu. Jsem rád, když se s kluky z týmu občas potkáme, dáme si společně kafe a probereme důležité blbosti. Vznikají tak nové nápady a souvislosti, které by třeba remote ani nevznikly. Stejně jako ty organizuju akce pro lidi z IT, protože mě baví se s nimi potkávat a zjišťovat jak to funguje jinde. To nás všechny obohacuje.<br /><br />Už delší dobu jedu v režimu 2 dny on-site a 3 dny remote. Hodně procesů jsme si vyladili a zvládáme to řešit bez problémů na dálku. Ne všechno je sice ideální, ale obvykle za to nemůže vzdálenost. Dobíhá nám jeden projekt na kterém jsme jeden ze čtyř distribuovaných týmů. Zákazník v Německu, designérská firma připravující UI taky v Německu, pražská firma, která dodá mobilní aplikace a my, kteří máme na starosti platformově nezávislé části architektury. Řídit takový projekt vyžaduje podobný přístup, jako by byl rozházený samotný tým.<br /><br />Co se týče Znalomatu, za více jak půl roku jsme se oficiálně sešli jen jednou. Jinak jedeme naším vlastním klonem remote scrumu říznutého kanbanem. :)Robert Dreslerhttps://www.blogger.com/profile/16401744220939465418noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-88210966427566083572015-05-23T19:53:29.545+02:002015-05-23T19:53:29.545+02:00Nic není černobílé Roberte, každý to máme jinak.
...Nic není černobílé Roberte, každý to máme jinak.<br /><br />Jsou lidi kterým delší doba v remote režimu nesvědčí (třeba mě). Jsem rád že jsem mohl (přes 10 let) a stále ještě můžu takhle dělat, ale když to srovnám s chozením do kanclu, tak kanclík a *přimeřené* množství kolegů okolo jasně vyhrávají.<br />Ono se to nezdá, ale v tomhle režimu dobře fungují takové ty rádoby náhodné interakce, při kterých ti docvakne spousta věcí. Všichni okolo tebe makají, tak makáš taky. Možnost promluvit si s někým osobně je pořád tisíc mil před emailem či skajpem. Doma s rodinou to funguje taky lépe, během přechodů mezi kanclem a bytem si to v hlavě nějak přepnu a doma mám čistší hlavu.<br /><br />Být šéfem tak asi nemám problém s tím že by lidi dělali z domu. Spíš z uvědomění, že kdyby seděli alespoň část týdne pospolu, tak by toho dokázali víc.Anonymoushttps://www.blogger.com/profile/15775667232038503506noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-6418711732453404532014-06-01T06:53:09.042+02:002014-06-01T06:53:09.042+02:00Na posledním projektu jsme dělali dva typy estimac...Na posledním projektu jsme dělali dva typy estimací. Dostali jsme hromadu zákaznických požadavků a přes planning poker jsme naestimovali hrubou pracnost každého z nich (1). Každý story point jsme pak mapovali na zhruba 8h práce. Tím jsme uspokojili projektového vlka našeho chlebodárce a získali orientační představu o pracnosti. Odhady se však dělaly ve fázi projektu, kdy jsme ještě neměli ani prototypy ani ideální znalost problémové domény. Celou realizaci jsme rozdělili do "sprintů" podle logické souvislosti požadavků a hrubých estimací. V rámci jednotlivých sprintů jsme dělali rozpady na menší celky a ty ještě na koncové tasky, u kterých jsme se už pohybovali v řádech hodin. Ty jsme dokázali poměrně přesně estimovat (2). Tyto estimace byly užitečné pro krátkodobé plánování v horizontu několika dní pro interní potřeby týmu. Díky jemnému rozpadu na tasky jsme byli schopni spoustu věcí dělat paralelně a těžili jsme z výhod popsaných v příspěvku.<br /><br />Projekt trval zhruba 20 člověkoměsíců, rozsekali jsme ho na téměř 1k tasků, při celkem 2k commitech s 5,6k LOC a více jak 2,6k unit testů.Robert Dreslerhttps://www.blogger.com/profile/16401744220939465418noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-59992040708851696852014-05-31T14:57:57.205+02:002014-05-31T14:57:57.205+02:00Stávají mi všechny vlasy na hlavě, když vidím v tý...Stávají mi všechny vlasy na hlavě, když vidím v týdenním sprintu týdenní tasky. Základem přesného odhadu náročnosti je dekompozice, když už si to rozsekám, proč to spojovat zase dohromady? :)AoJhttps://www.blogger.com/profile/15050815007726725915noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-26028161284116389952014-05-07T15:24:31.345+02:002014-05-07T15:24:31.345+02:00Zkušenost z aktuálního zaměstnání: legacy kód je s...Zkušenost z aktuálního zaměstnání: legacy kód je směsicí češtiny a angličtiny (je ho hodně), moderní kód je čistá angličtina; legacy komentáře spíš čeština, moderní omezujeme (struktura kódu), jinak angličtina. Projektová dokumentace, bugtrack, help desk — všechno v angličtině.<br /><br />Občas to drhne, ale funguje to. Největší problém je se dvěma českými zákazníky, kde nám ta čeština prosakuje do dokumentací a bug trackeru, do kódu už prostě nesmí (neprojde code review).dondhttps://www.blogger.com/profile/08080326955910250485noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-71781237278907263442014-05-05T15:51:37.968+02:002014-05-05T15:51:37.968+02:00Ideály jsou pěkné. Jenže v angličtině je rozdíl čí...Ideály jsou pěkné. Jenže v angličtině je rozdíl číst, psát rozumět a mluvit. Jsou to 4 samostatné dovednosti. Pokud nemám špičkový tým, bude nejspíš fungovat kód v angličtině, vše v ostatní česky. Komentáře IMO možno vždy prelozit, ve chvíli, kdy do projektu vstupuje někdo z venku.<br /><br />Tomáš Tintěrahttps://www.blogger.com/profile/09875908505886783954noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-60057445085847096722014-05-05T15:21:46.461+02:002014-05-05T15:21:46.461+02:00Musím jedině souhlasit. V mém případě byl zpočátku...Musím jedině souhlasit. V mém případě byl zpočátku s angličtinou trochu problém, ale právě jejím používáním jsem si ji výrazně zlepšil.Anonymoushttps://www.blogger.com/profile/06103732386802246852noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-82141674298074259442014-05-05T07:05:05.918+02:002014-05-05T07:05:05.918+02:00Jsem programátor, který se neustále učí a s postup...Jsem programátor, který se neustále učí a s postupem času mění své názory. Jednou z věcí, kterou mě život naučil, je nebýt dogmatický. Nesoudit lidi podle jedné vlastnosti nebo úrovně jedné dovednosti. Dogmatismus zabraňuje vidět problém z mnoha odlišných pohledů. Programování je hodně komplexní obor náročný na technické i sociální dovednosti. Jsou firmy technologicky špičkové, kde jsou také špičkoví programátoři. Pak jsou regionální firmy, kde jsou lidé méně ambiciózní, neumí toho tolik, ale je fajn s nimi spolupracovat z jiných důvodů. Každé prostředí tě navíc nějak formuje. Pokud děláš roky na projektu, kde aktivně angličtinu nepotřebuješ, pak ji nějak víc neřešíš. A to byl právě můj případ. ;)<br /><br />Měj se fajn a díky za komentář.Robert Dreslerhttps://www.blogger.com/profile/16401744220939465418noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-59558135716209553232014-05-04T23:09:54.808+02:002014-05-04T23:09:54.808+02:00Je to opravdu příspěvek od Roberta Dreslera, toho,...Je to opravdu příspěvek od Roberta Dreslera, toho, kterého s oblibou sleduji na tweeteru, a který má většinou velmi trefné - byť často převzaté, glosy?!<br /><br /> V IT se profesionálně pohybuji 10 let a nikdy, opravdu nikdy mě nenapadlo psát komentáře nebo dokumentaci v češtině. Považuji to v IT za velmi těžké faux pas, omluvitelné jen u studentů bakalářských programů. No way!<br />Anonymoushttps://www.blogger.com/profile/15582903664666003566noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-2526533854944332722014-05-04T21:35:24.475+02:002014-05-04T21:35:24.475+02:00Kolega dělal na projektu, kde byla dokumentace (a ...Kolega dělal na projektu, kde byla dokumentace (a občas i proměnné) ve španělštině. No, nezáviděl jsem mu to.<br /><br />Nemám rád angličtinu, ale v IT to asi jinak fakt nejde.Tacohttps://www.blogger.com/profile/08055170389804517183noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-65442804327355731082014-05-04T19:45:31.103+02:002014-05-04T19:45:31.103+02:00Moc děkuji za zmínění doménového slovníku. Bez něh...Moc děkuji za zmínění doménového slovníku. Bez něho to podle mě smysluplně nejde: co programátor, to různá úroven jazyka. Ne nadarmo je správné pojmenování jedním ze dvou nejsložitějších úkolů programování.Tomáš Benedahttps://www.blogger.com/profile/03097415158887089260noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-86282770750061187842014-05-04T18:21:30.027+02:002014-05-04T18:21:30.027+02:00Ja osobne jedu a tlacim "vse v anglictine&quo...Ja osobne jedu a tlacim "vse v anglictine". Nemyslim, ze by bezny programator dneska tohle nezvladl a do budoucna to ma jen vyhody. A samozrejme odpadaji patvary jako prave MlekoFactory atp. <br /><br />Snazim se to delat i u domenovyhc objektu a zjistit si nejaky "oficialni" preklad toho terminu. Kdyz nejde tak zkusim neco v anglictine podobneho - pristup "aspon neco" - ale uz jsem parkrat zoufale pouzil i spojeni v cestine. <br /><br />Vseho vsudy kod nepiseme do skaly, zmenit se da vsechno.Jiri Cincurahttp://blog.cincura.netnoreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-57621533871329897182014-04-26T15:50:51.162+02:002014-04-26T15:50:51.162+02:00Tak to my děláme úplně stejně (oba body), jen míst...Tak to my děláme úplně stejně (oba body), jen místo YT máme JIRA, a hlavně máme navíc Crucible - ten nejen, že pěkně zobrazuje diffy, ale umožňuje jednotlivé commity sdružovat do jednoho CR, a umožňuje komentovat nejen na úrovni CR, ale i na úrovni souboru a dokonce jednotlivých řádků (využíváme nejčastěji). Takže člověk dokáže velmi bezbolestně poukázat třeba na nevhodné jméno lokální proměnné.<br />Ptal jsem se hlavně proto, protože mě zajímalo, jestli používáte nějaký speciální nástroj na CR, a protože by mě zajímali reálné zkušenosti s něčím jiným, než je námi používaný Crucible.<br />Třeba se chytne někdo jiný ;-)Augihttps://www.blogger.com/profile/11667246313332382403noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-48025990658688564282014-04-26T11:59:34.590+02:002014-04-26T11:59:34.590+02:00ad 1) U nás to zatím máme jednoduché - jsme v týmu...ad 1) U nás to zatím máme jednoduché - jsme v týmu pouze tři vývojáři. Dopředu neřešíme, kdo review udělá. Revidujeme všichni a kdo má zrovna čas, tak se k tasku přiřadí jako Reviewer a zreviduje ho. Jedeme takovým hybridním kanbanem, takže když se nahromadí příliš tasků v Ready for Review, tak polevujeme s kódováním a vrháme se na review.<br /><br />ad 2) Tasky evidujeme v YouTrack. Jako repository využíváme Mercurial. Do commit zpráv uvádíme odkaz na task z YT a strávený čas. Buildujeme přes TeamCity, kde máme speciální build, který odkazujeme z YT. S jeho využitím si YT namapuje změny v kódu (a strávený čas na úkolu) k příslušnému tasku. Review pak obvykle probíhá tak, že od tasku se doklikáme ke změnám mimo IDE. Ty umí TC docela hezky zobrazit, takže rozsah změny je pěkně dohledatelný. Když je potřeba jdu do VS a hrabu se přímo tam. Pokud se objeví drobnosti, pak je přímo revidující opraví a pošle task do Finished. Pokud jsou tam větší problémy, do kódu přidáme připomínky ve formě speciálního TODO komentáře, commitneme připomínky opět s odkazem na task. Task se vrátí do stavu Dev in Progress a autor se "nadšeně" vrhá na úpravy. :)Robert Dreslerhttps://www.blogger.com/profile/16401744220939465418noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-27004742147010174432014-04-26T10:24:42.789+02:002014-04-26T10:24:42.789+02:00Naše zkušenosti s CR jsou také pozitivní :-) Jen d...Naše zkušenosti s CR jsou také pozitivní :-) Jen dvě poznámky/otázky:<br /><br />1) Trošku jsme bojovali s tím, kdo by měl dělat CR. Nejdříve jsme to měli nastavené tak, že autor kódu musel určit, kdo má dané CR udělat. Nakonec jsme to ale změnili tak, že autor kódu nemusí určovat reviewera (ale může). Takže nám to teď funguje tak, že když je člověk ve stavu, že by mohl udělat nějaká CR, tak se mrkne do Crucible a případně nějaká čekající CR udělá. Když o nějaké CR dlouho nikdo nejeví zájem, tak autor kódu určí, kdo má CR udělat.<br /><br />2) Jaké používáte na CR podpůrné nástroje? My máme Crucible od Attlasianu, což funguje moc pěkně. Ale víc by se mi líbilo něco přímo integrované do IDE (VS), protože když třeba někdo změní implementaci nějaké metody, tak bych se chtěl podívat, odkud všude se ta metoda volá - a to ve webovém Crucible jednoduše neudělám (a ve VS by to bylo easy). Takže to často u mě vypadá tak, že mám vedle sebe otevřené Crucible a VS.Augihttps://www.blogger.com/profile/11667246313332382403noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-62451705469077670352014-04-20T16:56:05.027+02:002014-04-20T16:56:05.027+02:00Děkuji za článek.
Naprosto s tebou souhlasím. Ned...Děkuji za článek. <br />Naprosto s tebou souhlasím. Nedávno jsem měnil práci, takže mám čestvou zkušenost. Prvně jsem šel do korporátní firmy, kde se vyvíjí legacy systém (spíše brownfield). Nevypádalo to zajímavě, ale nabídli mi nadprůměrný plat, tak jsem to zkusil.<br />Bohužel se ukázalo, že mě to šíleně nebaví a již po měsící jsem odešel. Nyní dělám v menší firmě, kde mám tak o 15% menší plat, ale velmi zajímavou práci. Jsem štastný a věřím, že jsem si vybral dobře. <br />Díky že jsi mi potvrdil, že nejsem jediný kdo tak myslí. <br /><br />I práce na starých projektech může být výzva! Mohu jen doporučit skvělou knihu, která Vás o tom přesvědčí:<br />http://www.amazon.com/Brownfield-Application-Development-Donald-Belcham/dp/1933988711/ref=sr_1_1?ie=UTF8&qid=1398005638&sr=8-1&keywords=brownfield+application+development+in+.net<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-75706820348795797622014-01-21T09:34:26.004+01:002014-01-21T09:34:26.004+01:00Super popis! Rád vidím, že existují lidé, kteří sv...Super popis! Rád vidím, že existují lidé, kteří svou práci berou takhle zodpovědně :)Ondřej Mirteshttp://ondrej.mirtes.cz/noreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-4033425845433487082014-01-15T15:36:05.272+01:002014-01-15T15:36:05.272+01:00Pěkný článek, osobně nesnáším oprašování starých p...Pěkný článek, osobně nesnáším oprašování starých projektů :( Proto ani neuvažuji, že bych se po rodičovské vrátila do bývalé práce, protože to byla nuda a hlavně žádná perspektiva nových projektů :(<br />Teď si doma programuju, co mě baví a každou chvíli něco jiného :)))<br />Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-3408745507091232422.post-72001784779825345192014-01-14T16:33:02.282+01:002014-01-14T16:33:02.282+01:00Absolútny súhlas !!! Tento článok si vytlačím a pr...Absolútny súhlas !!! Tento článok si vytlačím a preberiem s oddelením ľudských zdrojov u nás.<br />Doplnil by som: <br /> - Hoci sa zdá, že programátori nepoznajú nič iné, len počítač a programovanie, predsa len sa aj oni radi z času na čas stretnú so zákazníkom alebo užívateľom ich aplikácie.<br /> - Ľudia v riadiacej pozícii častokrát nepočúvajú hlasy zdola, napr. keď programátori upozorňujú na zlé technologické rozhodnutie, alebo ignorujú návrhy programátorov na zlepšenie napr. zavedením testovania, kontinuálneho buildovania, použitím novej (často open source) technológie apod. Takéto prostredie dlhodobo vedie k tomu, že aj "dobyvatelia" začnú byť pasívni a zmenia sa na "usadlíkov". Alebo odídu.<br /> - Celkovo sa v IT branži veľmi málo pozornosti venuje "ľudskému" v nás. Vyhorenie nie je doménou iba pomáhajúcich profesií. Vidím okolo seba programátorov, analytikov, menežérov ktorí vyhasli a len zo zotrvačnosti pokračujú v tej istej práci. Skúste sa spýtať vo svojom IT okolí otázku "si v práci šťastný?" a ľudia vás vysmejú. Naozaj sme tu na to, aby sme pretrpeli 8 hodín denne len preto, že práca ktorú máme patrí medzi najlepšie platené?Anonymousnoreply@blogger.com