Logo

nástroje

Grafy, hypergrafy, diagramy - půjde vývoj tudy?

Vložil Pavel Klobasa, 9. Listopad 2008 - 21:00

Počítače vnesly do kreslení grafů pokrok – vytvořit graf v MS Excelu pomocí knihovny MS Graph je snadné a rychlé (na rozdíl od ručního kreslení grafu). Nicméně v povědomí lidí zůstávají jen běžné grafy, jako je čárový, sloupcový, koláčový…, které mají stejnou vypovídající hodnotu v papírové i počítačové podobě. Jako kdyby se vývoj zastavil a nic lepšího snad ani nešlo vymyslet.

Občas se mi podaří v nějaké aplikaci nalézt graf, který přináší něco nového – rád bych vám několik méně obvyklých grafů ukázal.

Google Analytics

Nedávno Google do svého nástroje přidal vizualizaci klíčových slov v grafu. V běžném zobrazení není graf ničím neobvyklým: kromě X a Y souřadnice je použita i barva a průměr kruhu.

Na co se zapomíná v UML

Vložil Pavel Klobasa, 4. Květen 2008 - 18:47

UML je užitečný nástroj pro vývoj SW. Jen je potřeba znát jeho omezení, je potřeba vědět, kdy a k čemu se hodí a jak ho používat. Bohužel většina materiálů o UML se zabývá syntaxí tohoto grafického jazyka, ale málokdy je ukázáno použití na reálné, například webové aplikaci. Sepsal jsem tedy pár praktických poznámek na téma UML.

Míra podrobnosti

Snad největším bariérou při kreslení UML je to, že s vyjímkou školních úloh (a úloh v knihách o UML) je problém složitý a obsáhlý (kdyby takový nebyl, tak nebudeme používat UML, že…). A o to jde: po počátečním nadšení nad „kreslítkem“ zanedlouho zjistíte, že nadpoloviční většina problématiky zůstává stále nepodchycená. S přibližujícím se termínem hotové analýzy pak začnete pronášet něco takového jako „ve Wordu už bych to měl dávno“. Přesně v ten okamžik víte, že jste nezvládli míru detailu.

Problém není v UML. Při psaní textové analýzy každý intuitivně tuší, že text je nepřesný a abstrahující, naopak UML má prostředky, kdy je možné zajít až do implementačních detailů, které jsou zpravidla v zadání nedůležité.

Proč používat wiki?

Vložil Pavel Klobasa, 2. Květen 2008 - 8:20

Jak již jsem psal v dřívějším článku, používáme ve firmě wiki k uchování technologických informací. Chtěl bych se ale nad tím, proč je wiki nástrojem, který může pomoci nejen v SW firmě. Za příklad si budu brát JSPWiki, kterou znám nejlépe.

Sventon - webový klient Subversion

Vložil Pavel Klobasa, 30. Duben 2008 - 22:54

Možná vám bude připadat divné, proč mít nainstalovaného na serveru webového klienta k Subversion. Vždyť existuje mnoho nástrojů k tomuto verzovacímu systému, nemluvě o integraci do IDE. Přinejmenším dva důvody by tu však byly, oba vycházejí z webové podstaty tohoto klienta:

  1. Můžete poslat odkaz mailem na konkrétní soubor zdrojového kódu či jeho verzi
  2. Nemusíte si nic instalovat, nemusíte checkoutovat…

Webový klient, který bych vám chtěl ukázat, je Sventon. Jde o klienta napsaného v Javě a vydaného pod licencí BSD.

Jak na zásuvný modul do JSPWiki

Vložil Pavel Klobasa, 26. Duben 2008 - 19:22

Technologické informace jsou v naší firmě důležité, takže ani my jsme neodolali pokušení používat Wiki. Existuje množství wiki engine v různých jazycích, naše volba byla javová – zvolili jsme JSPWiki.

Chtěl bych vám ukázat, jak je snadné v JSPWiki vytvořit zásuvný modul, neboli vlastní Wiki značku. Příkladem bude modul, který umožňuje vložit do stránek soubor ve formátu SVG. Nejprve krátce o tomto formátu.

SVG

SVG vektorový grafický formát, který je možné zobrazit ve webové stránce. Pokud je mi známo, je to jediný standartizovaný vektorový formát, který je možné na webu použít. Bohužel není příliš známý ani rozšířený, ale velmi často je v prohlížeči implicitně nainstalován nebo je možné prohlížeč rozšířit zásuvným modulem od Adobe.

Maven - výhody a nevýhody prakticky

Vložil Pavel Klobasa, 13. Duben 2008 - 17:38

Apache Maven je jedněmi nadšeně přijímán a masivně propagován a jinými zatracován. Podle mého názoru je problém s Mavenem v jeho propagaci – nejčastěji je prezentován jako „deklarativní Ant“. Maven dělá něco podobného jako Ant, ale dělá to jinak a umí leccos nového. (Jakoby ona odlišnost od všeho, co v Javě známe, byla vyjádřena i velmi specifickým logem se sedícím programátorem…)

ColorZilla - kapátko pro Firefox

Vložil Pavel Klobasa, 26. Březen 2008 - 19:55

ColorZilla je nástroj pro práci s barvami ve webové stránce. Tento nástroj je koncipován jako „kapátko“ obvyklé v grafických programech. To znamená, na rozdíl od Web Developer Toolbaru, že při určení barvy nevychází ColorZilla z barvy v kaskádovém stylu, ale přímo z barvy, zobrazené na pozici kurzoru. Díky tomu ColorZilla dokáže snímat i barvy v obrázcích.

Ovládacím prvkem ColorZilly je ikona kapátka v levém spodním rohu prohlížeče. Pozadí ikony znázorňuje vybranou barvu.

Po clicku na ikonu se objeví menu ColorZilly. Užitečná je možnost přenést do schránky hexadecimální kód barvy, a to hned v několika formátech.

Web Developer Toolbar - nástroj vývojářův

Vložil Pavel Klobasa, 16. Březen 2008 - 23:21

Web Developer Toolbar je jeden z několika užitečných rozšíření Firefoxu, který ušetří spoustu práce vývojáři webových aplikací. Web Developer Toolbar se v prohlížeči objeví jako lišta, na následujích obrázcích je její široká (oříznutá) a úzká verze.

Začnu nástroji, které mají blíž ke grafice. Nejprve lupa, u které si můžete navolit míru zvětšení. Na ukázce je vidět, že si lupa nedokázala poradit s flashem. (To ale neplatí vždy.)

V dalším nástroji můžete snadno odměřit výšku či šírku a porovnat ji s jiným elementem ve stránce. Velikost a pozice v pixelech je vidět v liště mimo stránku.

SchemaSpy snadno a rychle

Vložil Pavel Klobasa, 24. Únor 2008 - 15:17

Dnes bych chtěl ukázat další užitečný vývojářský nástroj – SchemaSpy. Tento nástroj dokáže přes JDBC vyexportovat databázové schema do HTML podoby.

Nejprve nabízím krátkou ukázku, která ukazuje dvě na sebe navázané tabulky. (Pro případné kritiky: toto schema není úplné ani správné.)

Checkstyle snadno a rychle

Vložil Pavel Klobasa, 24. Únor 2008 - 14:21

Další z programátorských nástrojů, který bych chtěl stručně představit, je Checkstyle. Jde o nástroj pro kontrolu stylu či estetičnosti zdrojového kódu v Javě.

Na jádře jedné z našich starších aplikací pracovali v průběhu let čtyři lidé. Pohledem do kódu dokážu poznat, kdo kterou část kódu napsal. Liší se ve složitosti podmínek a cyklů, v používání mezer a závorek, v názvech proměnných… A není to dobře, protože vlastní styl zápisu kódu se kód sice stane čitelnější pro jeho tvůrce, ale o to hůře je čitelný pro ostatní programátory. V každém projektu by měly být stanoveny kódové konvence – sada pravidel pro správné psaní kódu.

Stanovení kódových konvencí není vůbec snadné, každý programátor považuje za správné (tj. čisté, estetické…) jiné konvence. Například počítadlo v cyklu by se mělo jmenovat i, j nebo k, tak, jak to kdysi zavedl Fortran? Mělo by se počítadlo jmenovat iPocitadlo podle maďarské notace? Není lepší proměnná s názvem pocitadlo, protože je to blízké přirozenému jazyku? Pokud vezmeme do úvahy angličtinu, tak se nabízí další dvě varianty: counter a iCounter. Nebo raději intCounter?

© 2005-2008 oXy Online s.r.o., všechna práva vyhrazena.