Před 70 lety, 7. června 1954, ve věku 41 let, zemřel Alan Turing, britský matematik, logik, kryptoanalytik a zakladatel moderní informatiky.
NiceGUI umožňuje používat webový prohlížeč jako frontend pro kód v Pythonu. Zdrojové kódy jsou k dispozici na GitHubu pod licencí MIT.
Open source platforma Home Assistant (Demo, GitHub, Wikipedie) pro monitorování a řízení inteligentní domácnosti byla vydána ve verzi 2024.6. Z novinek lze vypíchnout lepší integraci LLM (OpenAI, Google AI, Ollama) nebo podporu Matter 1.3.
IKEA ve Spojeném království hledá zaměstnance do své nové pobočky. Do pobočky v počítačové hře Roblox. Nástupní mzda je 13,15 liber na hodinu.
Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
jmeno te firmy, na kterou si mame davat pozor, se asi nedovime, ze ?
No a jak jste na tom u vás?
Slovo kvalita a plnohodnotný by měli vyškrtat ze slovníku.
No, co k tomu dodat. Jeste, ze delam v solidni americke firme, a moji sefove chapou, co znamena delat software poradne.
Co se tyce spolecenske organizace, lidstvo se jeste ma co ucit: http://en.wikipedia.org/wiki/Maverick_(book)
hm, ale zamestnavatele nejsou tak hloupi, aby rekli - ze se to ma odflaknout. Chytry management rekne - ze treti nejlepsi reseni je to ekonomicky nejvyhodnejsi a pak mate zase cerneho petra.
Ahojda, co pišeš je důležité téma a je dobře, že se o tom mluví (či píše). Přesto si ale dovolím malou poznámku, která až tak moc s tématem nesouvisí - ten graf je docela ale docela kvalitativní. Příslušné křivky jsou podle všeho vycucané z prstu. Tj. nenašel jsem, že by byly výsledkem nějakého matematického modelu, který by se dal testovat nebo tak něco. Někdo si prostě sedl a nakreslil dvě čáry, aby to vypadalo vědecky. Myslím, že by ten dotyčný udělal lépe, kdyby si to odpustil a místo toho napsal slovy, co má vlastně na srdci.
1. Co se týká designu a stojící implemetace, tak si dovolím nesouhlasit. Já osobně vyvýjím za pomoci Test Driven Development, kde je jasně řečeno, že design vzniká při implementaci a testy řídí jeho podobu. Něco o TDD určitě bude v některém z dalších blogpostů.
2.Ano v tom máte pravdu, já jsem ovšem ještě nepracoval na takovém projektu, abych se pod tuto dělící čáru dostal. Nebylo ani mým cílem toto jakkoliv komentovat, graf o tom mluví jasně. Já jsem jen presentoval problém, na který velice často narážím.
Co se týká designu a stojící implemetace, tak si dovolím nesouhlasit. Já osobně vyvýjím za pomoci Test Driven Development, kde je jasně řečeno, že design vzniká při implementaci a testy řídí jeho podobu.no, tak misto prace na designu travite cas psanim testu. a jestli pouzivate najaky ten XP pristup tak je potreba jeste zapocitat cas na refaktorizaci, coz je dalsi duvod pro zmenu tvaru te krivku. navic, pokud o designu rozhoduji testy, tak tam nevidim moc velky rozdil od ad-hoc pristupu k programovani.
To že nevidíte rozdíl mezi ad-hoc přístupem je podle mého tím, že jste to nikdy nezkusil. Kvalita kódu, která tímto přístupem vzniká je opravdu vysoká. Co se týká ceny psaní testů, tak ta se mi zdá stejná jako jakékoliv testování, které musí každý programátor dělat, aby se ujistil, že jeho kód funguje. Výhoda napsaných testů je, že během pár vteřin si je mohu všechny zopakovat. Co se týká refaktorizace, tam něco je, ale to vše je v grafu zahrnuto. XP neprovozuji, a TDD je jen jednou malou součástí XP.
To že nevidíte rozdíl mezi ad-hoc přístupem je podle mého tím, že jste to nikdy nezkusil.
Omlouvám se, to je opravdu hodně zavádějící věta. Spíše bych napsal, že pokud zkusil, tak nevydržel. Spousta polopravd o TDD vzniká právě tím, že je velmi těžké s ním začít a vydržet u něj. Ta cena je vysoká a začne se vracet až po delší době provozování TDD. Kdo nevydrží, většinou ho pro sebe zatratí.
Ano ten graf je vycucaný z prstu a dokázat se nedá. Vznikl za pomoci zkušenosti. Pokud tě zajímá jaké zkušenosti, stačí kliknout na ten link autora od kterého pochází. Ten důvod, proč je vycucaný z prstu je jasný, dodnes ještě nemáme žádnou techniku měření kvality sw projektu, která by se dala opřít o jasný matematický model a zohlednila všechny aspekty.
Nemuzu to najit, ale nekde jsem v knize videl krasny graf. Byl to rovnostranny trojuhelnik a na kazde spicce sedelo jedno slovo ze svate trojky - rychlost, kvalita a cena. Uvnitr tohoto trojuhelniku lezi kazdy projekt. Dejte si to, prsknete tam tecku malou a sibujte s nim. Soustredte se napriklad na dva libovolne aspekty. Kvalita a rychlosti? Ejhle cena se nam vzdaluje a roste. Zkuste i jinak. Funguje to. :)
Uz to mam. :)
No, nevim. Ja myslel, ze Mythical Man-Month ukazal, ze i kdyz zvysujete cenu (pocet lidi delajicich na projektu), nemuzete dosahnout vyssi rychlosti pri stejne kvalite - kvuli komunikacnim nakladum uvnitr tymu.
Aha, to zni zajimave. Co to? Kde to? Kdo to? ;)
http://en.wikipedia.org/wiki/The_Mythical_Man-Month
A jak rikam, trochu to vyvraci ten trojuhelnik, protoze ten trojuhelnik je linearni, praxe ne.
Jinak já osobně bych řekl, že softwarový projekt, který se nevejde do jedné kanceláře, je fundamentálně špatnýLinus by s tebou asi nesouhlasil
Predevsim, Linuxove jadro jako takove neni omezeno penezi, takze tam diskuse management vs. vyvojari nehrozi.
Ať už jsou náklady na komunikaci jakékoliv, vždy existuje určitá hranice, za níž znamené přidání dalšího člena týmu takové dodatečné náklady , že celkový čistý nárůstek výkonosti je záporný.Něco jako elevator story?
Jestli ono to nebude tak, ze tomu grafu chybi 3. dimenze, ktera je pocet zdroju/lidi, kteri delaji na tom projektu. Takze, pokud je na tom dostatecny pocet lidi, muzete mit i pravdu. Ale realna tendence (v pripade uvedenem v blogpostu) bude dost mozna ten projekt poddimenzovat i co do nakladu, takze se vzdycky dostanete mimo tu spodni oblast.
Nejsem nejakej super programator, ale jednou jsem delal na web projektu, ktery mel pro zobrazovani pouzivat XML data zkonvertovany do HTML pomoci XSLT. Ja jsem to delal presne podle puvodniho navrhu - muj kod generoval cistej XML s vlastnima znackama a na to se pak pouzila XSLT a ta z toho vyplivla HTML - myslenka byla, ze grafik pak zmeni pouze XSLT a do PHP kodu vubec nebude hrabat. Kolegove to spis kombinovali, cast HTML slo rovnou z PHP. Nakonec moji cast museli prepsat, protoze to s XSLT bylo zatracene pomaly.
Dalsi takovou vec ve stylu "rychle rychle" jsem videl v kodu systemu, kterej firma pouzivala jako svuj ucetni system. Kdyz jste to videli v akci, tak to bylo super - byl to kompletni system pro support, timesheet, prijmy/vydaje, proste super. Kdyz jste se ale podivali trosku podrobnejc do kodu, tak to byla hruza. Chapal jsem to az kdyz mi vysvetlili, ze to vznikalo postupne pridavanim funkci z puvodniho XLS stylem "udelej nam neco, co nam bude automaticky pocitat tohle" , "ted tam dodelej, aby to delalo tohle". Takze tam byla napr. takova vec, ze pro ucetnictvi se ucetni polozky zapisovaly do tabulky jako "uc2005". Kdyz pak prisel novej rok, tak se museli udelat posledni upravy v roce 2005 a pak se musely v kodu zmenit nazvy tabulek na "uc2006". Proste silenost.
Pokud teda prijde sef, ze chce neco rychle nabusit bez premysleni, tak je nejlepsi poslat email (pripadne s kopii i na dalsi lidi), ze bud to udelas hned a rychle, ale v budoucnu bude muze trvat hodne tam neco pridelat, pripadne to muze byt uplne nemozne, a nebo se to naprogramuje poradne a bude to dobre spravovatelny, ale bude to drazsi. Nejlepsi je to potom predat zakaznikovi, at se rozhodne sam, jestli pocita s rozsirovanim a zaplati radsi o neco vic za kvalitni navrh ted a pozdeji za upravy pouze min, nebo jestli ted zaplati malo, bude to mit rychle, ale pri upravach bude platit treba i stejnou nebo vyssi cenu a bude to trvat dlouho.
Nejlepsi je to potom predat zakaznikovi, at se rozhodne sam
Tohle moc nefunguje – zákazník těm technickým detailům nerozumí a ani o takových věcech nechce rozhodovat*. Spíš by to mělo být tak, že jako firma (dodavatel) máš určitý standard kvality, pod který nejdeš.
*) a pokud bude muset, tak si vybere tu levnější variantu, protože si bude myslet, že se z něj akorát snažíš tahat prachy navíc, za nějakou údajnou kvalitu, kterou on ve skutečnosti nepotřebuje – „vždyť to přece bude fungovat i v té levnější variantě“
Nejlepsi je to potom predat zakaznikovi, at se rozhodne samTohle moc nefunguje – zákazník těm technickým detailům nerozumí a ani o takových věcech nechce rozhodovat*. Spíš by to mělo být tak, že jako firma (dodavatel) máš určitý standard kvality, pod který nejdeš.
*) a pokud bude muset, tak si vybere tu levnější variantu, protože si bude myslet, že se z něj akorát snažíš tahat prachy navíc, za nějakou údajnou kvalitu, kterou on ve skutečnosti nepotřebuje – „vždyť to přece bude fungovat i v té levnější variantě“
Nene, ja mel prave na mysli mu dat pouze na vyber, ale samozrejme tam nelicit objektovy navrhy a podobne, ale proste jenom rict neco jako, ze za pozadovanou cenu a kratky cas se to napsat da, ale pokud by se s tim v budoucnu melo dal pracovat (upravy, opravy), tak to pak bude drazsi a bude to trvat dele. Nebo se ted muze udelat kvalitni navrh s nejakymi predpoklady do budoucna a pak by dalsi upravy/opravy byly levnejsi a rychlejsi. A je na nem, jak se rozhodne. A kdyz si vybere tu levnejsi variantu, tak aspon bude vedet dopredu, co ho ceka:)
Kluci, je to projekt za pár šupů, tak se s tim moc nepárejte. … Zákazník na to vážně spěchá, takže není čas na nějaké přemýšlení, prostě to bušte.
Tyhle věty mají evokovat pocit, že „tenhle projekt je zrovna výjimka, ale jinak to děláme samozřejmě pořádně“. Jenže ve skutečnosti je to pravidlem – zákazník nikdy nechce zaplatit příliš mnoho a nikdy na to nemáme tolik času, kolik bychom si ideálně představovali. Takže nemá cenu se takovými větami nechat obalamutit* a neslevovat z kvality návrhu a kódu. Navíc ona ani neexistuje přímá úměrnost mezi „nějak to naprasím“ a „bude to rychle hotové“ – osobně si myslím, že ten zlomový bod nastává hodně brzo, resp. o těch výhodách nekvalitního kódu nemá cenu ani uvažovat.
*) já jsem se párkrát nechal a pak jsem zjistil, že to nebylo dobře
Mozne vysvetleni je v http://en.wikipedia.org/wiki/Market_for_Lemons
Jestli to take nebude tim, ze vyrobci tech "strasnych reseni" investuji penize do marketingu/sales misto do vyvoje. A diky asymetrickym informacim (viz vyse) se jim to vyplaci.
To může být tím, že ty máš jiná kritéria pro kvalitu než uživatel-zákazník. Ty dáváš asi přednost technické dokonalosti a kvalitě kódu, zatímco zákazníka spíš zajímá, co mu program přinese – jde tedy hlavně o to, jaký má ten program nápad – jak dobře je napsaný, je plus mínus jedno, pokud funguje.
A tohle jde podle mě ruku v ruce s kvalitou kódu. Zákazník a většinou ani management si neuvědomují že dosáhnout softwaru takového, který by zákazníkovi opravdu přinesl užitek a peníze se jen těžko dá na první pokus. Já říkám, že jedinou jistotu, kterou v projektu máme je, že budou změny v zadání. Ale na ty musíme být připraveni dostatečnou kvalitou kódu, tak aby nebyli drahé.
a ne jen drahé, ale spíš aby nebyli nemožné.
Tiskni Sdílej: