Internet Info, s.r.o. Lupa Root Měšec Podnikatel DigiZone Slunečnice Vitalianew Bomba Navrcholu Weblogy Jagg Woko Dobrý web Computer.cz SK: MojeLinky
Lupa.czBlogyRailsWorx Warťásek

nginx a Ruby On Rails

Erich Kaderka, 2. 03. 2010, 09:17 v kategorii Ruby on Rails, Technologie, štítky: , ,

V dnešním příspěvku jsem se rozhodl popsat konfiguraci nginx a Ruby On Rails. Nginx je http/reverzní proxy napsaný Igorem Sysoevem. Proč nginx?

  • Přehlednější konfigurační soubory
  • Nižší paměťová naročnost v porovnání s Apachem

Instalace nginx na debianu:
aptitude install nginx

Spuštění:
/etc/init.d/nginx start

V současné době existují 2 způsoby jak pomocí nginx "obsluhovat" railsovou aplikaci. První je pomocí mongrel_clusteru a druhý pomocí modulu Phusion Passenger.

Mongrel Cluster

Nejdříve je nutné nainstalovat gem mongrel_cluster:
gem install mongrel_cluster

Poté je potřeba vygenerovat konfigurační soubor příkazem (v rootu aplikace, soubor se vygeneruje do adresáře config):
mongrel_rails cluster::configure -e production -p 8000 -N 3 -a 127.0.0.1
-e znamená prostředí (obvykle production), -p je port na kterém se spustí první instance mongrelu, -N je počet mongrelů a -a znamená, že instance budou přístupné pouze z localhostu.

Cluster se spouští:
mongrel_rails cluster::start

Nyní je již zbývá pouze upravit konfigurační soubor nginx.conf (v debianu ho najdeme v /etc/nginx/). Zjednodušená ukázka:

user www-data;
worker_processes 1;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
# multi_accept on;
}

http {
include /etc/nginx/mime.types;

access_log /var/log/nginx/access.log;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;
tcp_nodelay on;

gzip on;
gzip_disable "MSIE [1-6]\.(?!.*SV1)";
#mongrel_cluster
upstream mongrels {
server 127.0.0.1:8000;
server 127.0.0.1:8001;
server 127.0.0.1:8002;
server 127.0.0.1:8003;
}
server {
listen 80;
#cesta k aplikaci
root /kde/je/rails_aplikace/root/public;
}
location / {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;

if (-f $request_filename/index.html) {
rewrite (.*) $1/index.html break;
}
if (-f $request_filename.html) {
rewrite (.*) $1.html break;
}
if (!-f $request_filename) {
proxy_pass http://mongrels;
break;
}

}
}
}

Po restartu nginx:
/etc/init.d/nginx restart
by měla aplikace již běžet. Stačí do prohlížeče zadat http://localhost. Případné chyby hledejte ve /var/log/nginx/error.log.

Phusion Passenger

je open-source modul do nginx (existuje i verze pro Apache, postup instalace a konfigurace bude velmi podobný, pokud by měl někdo zájem o konkrétní popis, tak ho mohu připojit později).

Instalace:

gem install passenger
passenger-install-nginx-module

Po spuštění druhého příkazu na vás vyskočí interaktivní mód, kde po odentrování proběhne kontrola závislostí. Pak nepotřebujete žadnou další konfiguraci nginx zadejte 1 a enter. Následuje stažení a kompilace nginx.

Jestliže jste nezadali cestu do jiného adresáře, tak se nyní nachází instalace nginx v /opt/nginx. /opt/nginx/conf/nginx.conf by měl vypadat asi takhle:


user www-data;
worker_processes 1;

error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
worker_connections 1024;
}

http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
passenger_root /usr/lib/ruby/gems/1.8/gems/passenger-2.2.10;
passenger_ruby /usr/bin/ruby1.8;

access_log /var/log/nginx/access.log;

sendfile on;
#tcp_nopush on;

#keepalive_timeout 0;
keepalive_timeout 65;
tcp_nodelay on;

gzip on;
server {
listen 80;
root /kde/je/rails_aplikace/root/public;
passenger_enabled on;
rails_env development;

}
}

Po lehké úpravě /etc/init.d/nginx, kde je potřeba nastavit cestu pro démona (DAEMON=/opt/nginx/sbin/nginx), stačí restartovat nginx a otevřít v prohlížeči localhost.

Závěr

K vyzkoušení kombinace nginx a passenger jsem se dostal teprve nedávno (díky Števo:)) její výhoda je především ve snadné instalaci. Na druhou stranu nginx s mongrel_clusterem je poměrně osvědčená stabilní kombinace.

Zdroje

http://nginx.org/
Phusion Passenger

Ruby Eigenclass (Singleton Class)

Štefan Ľupták, 12. 02. 2010, 09:00 v kategorii Programování, štítky:

Pri čítaní knihy Metaprogramming Ruby od Paolo Perrotta (pragprog.com) som narazil na zaujímavú informáciu, ktorá ma prekvapila a o ktorú by som sa tu rád podelil. Jedná sa o Eigenclass (niekedy nesprávne nazývaná aj Singleton Class). Poďme si teda postupne ozrejmiť o čo sa vlastne jedná.

Singleton metódy
Jedná sa o metódy, ktoré pridávame konkrétnej inštancii triedy a nie priamo triede. Napríklad:

str1 = "nejaky retazec"
str2 = "druhy retazec"

def str1.long_string?
  self.length > 10
end

str1.long_string? # => true
str2.long_string? # => NoMethodError
str1.singleton_methods # => ["long_string?"]

Metódy tried
Triedy sú tiež vlastne len objekty a názvy tried sú konštanty. Z toho vyplýva, že volanie metódy na triede a na objekte je zhodné:

objekt.metoda # volanie metódy na objekte odkazovanom premennou
Trieda.metoda_triedy # volanie metódy na objekte odkazovanom konštantou

Keďže volanie metódy na objekte funguje tak, že sa postupne prehľadáva trieda objektu a potom smerom hore v hierarchii tried, vzniká nám otázka, na akej triede sa definujú singleton metódy. Ak by to v našom prípade bola trieda String, fungovala by metóda long_string? pre každý objekt triedy String. Tak ako to teda je?

Eigenclass
Ruby nám niekedy neodkryje celú pravdu. Namiesto triedy, ktorú nám vracia metóda .class, môže mať objekt svoju vlastnú skrytú triedu. Tá sa nazýva eigenclass objektu. Môžme sa k nej dostať pomocou špeciálnej syntaxe založenej na kľúčovom slove class:

retazec = String.new
eigenclass = class << retazec
  self
end
eigenclass.class # => Class
eigenclass.to_s # => "#<Class:String>"

Na základe týchto poznatkov sa dozvedáme, že singleton-metódy sa v skutočnosti definujú na eigenclass daného objektu. Tak isto metóda instance_eval() upravuje eigenclass daného objektu. Zaujímavé, však? Ak máte radi podobné zaujímavosti a chcete preniknúť do tajov metaprogramovania a pozrieť sa Ruby viac pod kapotu, rozhodne túto knižku odporúčam.

Kdo buduje obsah komunitních webů?

Jako jednu z hlavních otázek při tvorbě nové webové aplikace si musíme položit otázku "Kdo a jak jí bude používat". Nemáme-li o této otázce jasno během 3 vteřin, pak bychom měli tvorbu takové aplikace zvážit. Další velice důležitou otázkou je, kdo bude vytvářet obsah naší aplikace. Zcela upřímně, prázdné weby bez informací nebo nějakého dění, dnes již nikoho nezajímají a uživatelé na nich nemají tendenci zůstávat, ba se k nim každý den vracet. Proto musíme určit, kdo bude náš web takovými informace zásobovat. Existují 4 různé přístupy, na kterých se dá tvorba obsahu webové aplikace postavit

Costumer-service driven (obsah je tvořen službami zákazníkovi)

Určitě si každý z vás již kupoval nějaký lepší telefon, navigaci nebo herní konzoli. Občas se stane, že naše nové zařízení se nechová tak, jak bychom očekávali, nebo si s daným problémem nevíme rady. Ve většině případů mnozí z vás berou do ruky počítač a už vyhledávají v googlu, jestli někdo neřešil podobný nebo dokonce na chlup stejný problém. Většinou ano. Odpověď na tyto otázky většinou dostáváme na diskuzních fórech přímo u výrobce a nebo fanouškovských fórech daného produktu. Obsah těchto webů tedy vytváří samotní zákazníci a tedy i majitelé daných výrobků. Uživatelé se zde snaží najít pomoc a poskytnout radu jiným uživatelům.
Tento způsob tvorby obsahu je vhodný zejména pro weby, které se jsou buď přímo weby výrobců, nebo fanouškovských webů, zaměřující se na danou problematiku věci. Uživatelé sem chodí hledat odbornou pomoc a vytvářejí příspěvky, které se snaží vést k vyřešení dané problematiky nebo pokládají otázku, kterou na webu ještě není řešena, nebo její řešení nenalezli.

Publisher driven (obsah je tvořen autorem)

Obsah toho webu je krásnou ukázkou komunitní aplikace, kde obsah (tedy náměty k interakci uživatelů) vytváří autor. Obsah příspěvku je pak následně komentován komunitou a je nad ním vedena další aktivita. Tyto činnosti, například komentování daného blogu (co bych byl rád abyste dělali i u tohoto příspěvku :D) vytváří další obsah, který je pro uživatele těchto webů potřebný, ne však nutný, k jejich každodenní návratnosti. Pro většinu uživatelů má samotný obsah článku daleko větší význam, než komentáře pod ním, což je jeden z největších rozdílů oproti ostatním přístupům tvorby obsahu. Dalším příkladem těchto webů jsou například různé zpravodajské servery, kde poslední dobou bohužel kvalita komentářů k daným článkům upadá k bodu mrazu. Uživatel se denně vrací pro novinky z oblasti která jeho zajímá. Má chuť se vrátit a dozvědět se něco nového.

Member driven (obsah je tvořen uživatelem)

Nejvhodnější ukázkou typu toho komunitního webu jsou různá fóra a bulletin boardy, kde každý uživatel může začít svojí diskuzi na téma které se jemu líbí. Kdokoliv mu na tento příspěvek může reagovat. Ideálním příkladem tohoto webu je hofyland.cz, kde se každý může za registrovat a vytvořit vlákno o čem chce. Většinou se nejedná o přímé sdílení multimédií, ale o psaný text a názor jedince na danou společenskou situaci. Mezi oblíbená témata hovoru pak patří politika, film nebo hudba. Tento příspěvek však není tak ucelený, abychom ho mohli nazývat příspěvkem do blogu.

Contributor driven (obsah je tvořeno přispěvatelem)

Ano, zejména kvůli této kategorii všechny názvy píši raději v anglickém jazyce, jelikož slovo "contributor" do českého jazyka lehce přeložit nejde. Na tomto principu dnes funguji velké sociální sítě jako je YouTube nebo Flickr. Tedy taková služba, kde "contributor" vytváří multi-mediální obsah, a má k dané stránce určitý vztah. Fotka, kterou uživatel nahraje nemusí sloužit jen jako základní entina celého systému, ale velice často se vztahuje ještě k nějaké jiné činnosti na této službě. Například na Facebooku, můžete k jednotlivým událostem nahrávat vaše fotky a videa, nad kterými může být dále pak vyvíjena aktivita jiných uživatelů. Rozdíl mezi "contributorem" a "publisherem" je převážně v tom, že contributorem se může stát kdokoliv, bez jakéhokoliv předchozího schvalování. Prostě si jen vytvoří profil a může se zapojovat. "Publisher" však musí být na trošku jiné úrovni, v tom co dělá. Jistě namítnete, že blog si dnes může založit každý, ale například zprávy na idnes.cz každý psát nemůže (i když to tak poslední dobou vypadá). Uživatelé jsou nuceni se každý den vracet na základě aktivit jiných uživatelů nad jednotlivými entity systému. Například: Někdo mi okomentoval fotku, někdo se zúčastní události na kterou pořádám. Někdo mi odpověděl na můj příspěvek. Tedy možností interakce s ostatními je zde hodně.

Je tedy pouze a jen na vás, který přístup k tvorbě obsahu vašeho komunitního webu si vyberete, nebo využijete od každého trochu. Avšak vřele doporučuji si tento směr vybrat na samotném začátku a pak ho co nejméně měnit.

In-Page Editing

Štefan Ľupták, 18. 01. 2010, 09:54 v kategorii Optimalizace, Webdesign, štítky: , ,

Urob to priamo

Mnoho programov má jedno miesto pre vstup a druhé pre výstup, spracovávajúc ich ako osobitné procesy. Používateľský mentálny model v tom ale nevidí rozdiel. Jedno zo základných pravidiel hovorí: Dovoľte vstup všade tam, kde máte výstup. Vo všeobecnosti by sme mali vytvoriť rozhranie tak, aby reagovalo priamo na užívateľskú interakciu. My si popíšeme ten najpoužívanejší.

Editácia na stránke

Obsah na stránkach býval kedysi určený len pre zobrazovanie. Ak niečo potrebovalo zmenu, použil sa na to osobitný formulár s niekoľkými vstupnými poľami a tlačítkom na potvrdenie zmien. Umožnenie používateľovi editovať obsah stránky priamo, nasleduje princíp “Urob to priamo”.

Výhoda tohto prístupu je v sile kontextu. Často je pre používateľov potrebné, aby počas editácie videli zvyšok stránky. Napríklad je užitočné vidieť fotku, ak editujem jej názov, aby ju bolo možné výstižnejšie pomenovať.

Jedno-políčková priama editácia

Jedná sa o najjednoduchší typ editácie priamo na stránke, ale zároveň aj najpoužívanejší. Tento proces sa skladá z 4 krokov:

Stav ne-editácie: Prvok je zobrazovaný tak, aby bol čo najviac čitateľný. Je vhodné už v tomto stave zobrazovať editačný odkaz. Výhody tohto prístupu si popíšeme neskôr.

Pozvánka na editáciu: Pre používateľa musí byť už na prvý pohľad jasné, že daný prvok sa dá editovať priamo na stránke. To je možné dosiahnuť napr. podfarbením daného prvku pri pohybe kurzorom ponad prvok a prípadným zobrazením pomocného “ToolTip textu”.

Editácia: Akonáhle používateľ klikne na daný element, prepne sa do editačného módu. Zobrazenie tlačidiel “Uložiť” a “Storno”, dávajú používateľovi jasne vedieť, že sa momentálne nachádza v editačnom režime.

Dokončenie: Jednou z možností, ako dať jasne vedieť, že daná operácia prebehla úspešne, je použitie zvýrazňovacieho efektu na dočasné podfarbenie daného elementu inou farbou a napríklad zmena jeho textu na “Ukladá sa...”.

Objaviteľnosť

Nami popísaný postup má jednu drobnú chybu. Keďže všetky zmeny sa prejavia až po nájazde myšou, používateľ nevidí na prvý pohľad, že daný element je editovateľný. To je možné vyriešiť napríklad zobrazením odkazu “edit” hneď vedľa elementu. Každopádne to musí byť vyvážené, aby na stránke nebolo príliš veľa rušivých prvkov. Je nutné zvážiť, či je prednejšia čitateľnosť alebo editovateľnosť.

Prístupnosť

Ďalšíe znepokojenie, ktoré prichádza spolu s inline-editáciou je nedostatok prístupnosti. Prístupnosť ovplyvňuje širší rozsah používateľov, ako by ste si mohli myslieť. Prístupné technológie pomáhajú ľuďom s fyzickými postihnutiami, zdravotnými problémami, zrakovými ťažkostami a veľa iným.

Pomocné technológie vo všeobecnosti spracúvajú značkovací jazyk stránky, aby našli obsah, odkazy, alternatívne názvy pre obrázky a iné štruktúry na stránke. Ak inline editácia neobsahuje explicitne značku zabudovanú priamo do stránky, pomocné technológie nemôžu jednoducho objaviť možnosť editácie.

V určitom slova zmysle, spoliehanie sa na myš, aby objavila nové možnosti, zabráni niektorým užívateľom v priamej editácii. Ako sme spomínali vyššie, poskytnutím explicitného editačného linku pomôžeme objaviteľnosti a ako vedľajšie pozitívum bude táto schopnosť aj viac prístupná.

Existuje prirodzená dilema medzi priamou a nepriamou interakciou. Je možné ju vyriešiť, poskytnutím oboch prístupov v jednom rozhraní. Samozrejme odkaz na nepriamu editáciu bude odkazovať na osobitný formulár, s ktorým dokážu pomocné technológie spoľahlivo pracovať. Toto sa javí asi ako najvhodnejšia cesta pre väčšinu použití.

Doporučené postupy pre in-page editing

  • Používajte len pre jedno políčko.
  • Používate, ak chcete editovať jednu položku z mnoha, pomôže to udržať kontext
  • snažte sa, aby zobrazovanie aj editácia mali rovnakú veľkosť, zabráni to rušeniu a znervóznovaniu pri prechode medzi režimami.
  • Urobte prechod medzi oboma módmi čo najlplynulejší.
  • Používajte pozvania pri prechode myši, keď je čitateľnosť dôležitejšia ako editovateľnosť.
  • Vyhnite sa dvojkliku pre aktiváciu editácie.
  • Umiestnite “[edit]” link k položke, ktorá sa môže editovať, keď sú čitateľnost a editovateľnosť rovnako dôležité, alebo je množstvo editovateľných prvkov malé.
  • Použite overlay, ak editovaná položka potrebuje špeciálnu pozornosť. Tak isto to zabráni nechcenej zmene dôležitej hodnoty.
  • Nepoužívajte viacnásobný overlay.
  • Použite tlačítka na uloženie a zrušenie, ak je pre ne dostatok miesta.
  • Vždy keď je to možné, dovoľte overlayu, aby bol posúvateľný myšou tak, aby bol obsah pod ním viditeľný podľa potreby.

Recenze knihy Collective Intelligence

David Schovanec, 8. 01. 2010, 21:24 v kategorii Nezařazené,

Kniha - Collective Intelligence
Autor - Toby Segaran
Jazyk - angličtina
ISBN - 978-0-596-52932-1

Zajímalo vás někdy, jak vám některé online obchody dokáží doporučit produkty, které by vás mohly zaujmout, kterak na dnes velmi populárním facebooku funguje doporučování přátel a mnoho dalších funkcí moderních webů ? Tato kniha vám to může snadno objasnit, bohužel však není určena každému čtenáři. Pokud ale znáte základy algoritmů, nejsou vám cizí slova jako graf, matice, heuristika, či data mining a ovládáte základy programovacích jazyků, tak je určena právě vám. Znalost programovacćih jazyků, nejlépe pak skriptovacího jazyka Python pro vás ale bude nejcennější. Toby Segaran totiž odvedl vynikající práci při vysvětlování složitých algoritmů a matematických pojmů s jasnými příklady. Jeho kód je i přes komplexnost samotného tématu velmi přehledný a mohl by složit jako pseudo-kód samotných algoritmů. Pro lepší pochopení využívá data z reálného prostředí, tedy existujících webových stránek, obchodů a aplikací, jako je například Amazon, či Ebay. Před očima nám tak vznikají závislosti mezi produkty a návštěvníky. Jaké skupiny preferují jaký produkt, kde se jejich preference shodují, či co by si koupili dále.
Věřím, že vám všem může tato kniha posloužit jako inspirace pro nové možnosti vašich webových aplikací a samotným vývojářům pak jako velmi jednoduchá příručka, kterak jednotlivé algoritmy implementovat.

Folksonomie: všechno pro lid! (1. část)

Honza Makovička, 28. 12. 2009, 09:20 v kategorii Architektury, Sociální sítě, štítky: ,

Když uživatel nahrává na Flickr, Picasu nebo obdobnou službu svoje fotky na web, má možnost svoje fotky a alba organizovat pomocí tagů. Podobně je to i „psaného“ obsahu, jako např. u Technorati a konec konců i u tohoto lupího blogu. Teoreticky by tagování mělo zjednodušit jak organizaci fotek, tak i jejich vyhledávání. Ve skutečnosti ale tagování problémy teprve začínají. Základní problém který tagování obecně přináší je, že jednoznačný pohled na klíčová slova použité jako tagy není možný. Každý člověk uvažuje jinak, a tak pod stejným obrázkem či spotem na blogu budeme schopni najít řadu různých tagů různých uživatelů. Dosud používaným řešením je umožnit každému uživateli pracovat s jeho vlastní sadou tagů. To umožňuje vytvářet užitečnější indexovací systémy nad daty aplikací, nazývaný folksonomie (folksonomy). Folks + Taxonomy = Folksonomy.

Co to je folksonomie

Folksonomie (tento termín se poprvé objevil v roce 2004) je logickým opakem taxonomie, při které jsou data a informace organizovány systémem top-down, typicky pomocí hierarchické struktury složek či adresářů, do kterých jsou informace přiřazovány. Příkladem je organizace složek v každém dnes běžně používaném file-systému.

Zatímco taxonomická struktura je typicky vytvářena „na začátku“, folksonomie vzniká evolučně, postupně, a hodí se tak právě pro použití ve víceuživatelských prostředích, kde nároky jednotlivých uživatelů nelze předem přesně odhadnout. Folksonomická struktura vzniká postupně tak, jak se vytváří informační obsah webové aplikace. Tím, čím je složka u taxonomických struktur, tím je tag u struktur folksonomických.

Co je pro folksonomickou strukturu je typické.

  • Jediný namespace tagů: žádná hierarchie nebo vztah rodič-potomek mezi tagy
  • Každá tag lze přiřadit do více skupin, které ale nesloží k organizaci, jak spíše ke snazší navigaci – typicky představují generalizaci informace.
  • Klíčová slova použitá při tagování nepředstavují pohled autora obsahu (fotky, článku, …), ale toho, kdo tento obsah užívá.
  • Stálá otevřenost folksonomické struktury.
  • Snadná použitelnost – uživatel se nemusí seznamovat se systémem organizace obsahu.
  • „Sociální aspekty“ – uživatel může snadno vyhledat jiné uživatele, kteří často používají (logicky) stejné tagy jako on sám, může s nimi začít komunikovat.

Prohlížení vs. vyhledávání

Pohled na oba typy organizace informací může různit podle toho, k jakému účelu je využívána. Prosté tagy jistě nebudou příliš dobré k procházení celého katalogu informací – dovedete si představit Firmy.cz organizované výhradně pomocí tagů připojených k firmám? Asi ano, ale je otázka, kolika uživatelům, kteří rádi pracují s katalogy, by tento přístup nevyhovoval. Naproti tomu při vyhledávání se ukazuje tagování jako snadněji použitelné. Prostě zadaný dotaz se provede nejen nad vlastní databází informací, ale i nad množinou klíčových slov použitých jako tagy.

Široká a úzká folksonomie

Běžně se rozlišují dva základní typy folksonomí, a to široká (broad) a úzká (narrow). Vlastnosti „široké folksonomie“.

  • Velké množství lidí taguje stejné objekty, přičemž každý uživatel může tagovat slovy ze svého vlastního slovníku.
  • Více lidí může označit objekt stejným tagem.
  • Long tail efekt v histogramu četnosti použití tagů pro konkrétní subjekt. Přibližně řečeno, 20% klíčových slov použitých jako tagy je použito v 50% přiřazování klíčových slov subjektu.
  • Příkladem je Delicious.

Oproti tomu „úzká folksonomie“.

  • Jeden nebo jen málo uživatelů vytváří tagy, které ostatní uživatelé používají k získávání informací. Tagy typicky vytváří autor obsahu.
  • Exkluzivní přiřazení tagu pro jeden logický objekt, např. „auto“ je vždy „auto“, ne jednou „auto“ a podruhé „vůz“.
  • Příkladem je Flickr.

Tag Clouds

Velmi populárními se staly tag clouds. Umožňují v koncentrované formě vyjádřit popularitu konkrétních tagů, resp. jim odpovídajících či jimi popsaných objektů. Typicky je tag cloud konstruován jako histogram počtu přiřazených tagů všem objektům (informačním zdrojů) v systému. Tím se řešíme jak „vytažení“ populárnějšího obsahu (používanější obsah bude mít statisticky i více přidělených tagů), tak i popularitu tagů používaných pro popis tohoto obsahu. Není to však jediný způsob. V „nečistých“ tag clouds se mohou projevit např. i často používaná slova z vlastního obsahu článků apod.

Nevýhody organizace informací folksonomickou strukturou

Nic není černobíle, kromě některých postarších televizí, takže i folksonomická organizace informací má své nevýhody.

  • Nekontrolovaná expanze počtu použitých tagů může vést k nejednoznačnostem, kdy jeden tag má více významů nebo naopak více tagů popisu jediný význam.
  • Absence hierarchické struktury.
  • Malá vypovídací schopnost plynoucí z nutnosti použít jako tag jen jedno slovo.

Je řešením těchto problémů něco jako „kontrolovaný slovník“ pro použití v tazích? Něco jako editoři Wikipedie? Mohou taxonomická a folksonomická struktura (efektivně, bez matení uživatele) existovat vedle sebe paralelně na jednom webu?

Výzvy

Asi nejtypičtějším a nejčastěji řešeným problémem v souvislosti s tagy je zřejmě již zmíněná schopnost různých uživatelů přiřadit jednomu objektu různé tagy, které jsou ale ve skutečnosti synonymy. To může ztížit schopnost vyhledávání (např. na dotaz „auto“ dostaneme objekt označený jako „vůz“ jen stěží), ale i prostého organizování informací. Chybí něco, co by řeklo, že tyto dvě slova jsou synonyma. Úkolem vyspělého systému na pozadí webové aplikace použité je synonyma identifikovat a pracovat s nimi jako s jedním slovem. Jak k řešení této záležitosti lze přistoupit, na to se podíváme ve druhé části.

Dalším důležitým úkolem, a to nejen pro weby pracující s obsahem, je dostat své „tagy“ do indexovaného obsahu vyhledávačů. Navigace pomocí rychlého zadávání klíčových slov do lišty vyhledávače v browseru se stává realitou pro stále více uživatelů. Pro náš projekt Netina zatím není řešení tohoto problému na čele seznamu priorit, ale v budoucnu se mu patrně také budeme muset věnovat.

Kde najdete více

Další zdroje informací o folksonomii (některé byly využity i při psaní tohoto spotu):

Web navigation testing methods

Andrej Tolstych, 18. 12. 2009, 11:43 v kategorii Webdesign, štítky: , ,

this article is based on the book “Designing Web Navigation”

An important thing in the web development is a design of web navigation. Especially when we are talking about a complex multifunctional web site, such as social network. You can try to design the web navigation "from the ground up", it is a difficult and interesting way. But it is better to use the world experience of web developers, remember received basic principles for the navigation, using the established web navigation testing methods and methods of estimation its effectiveness. Our team has the tendency to make decisions based only on the amount of subjective views of the team members. Of course, the opinion of each member must be taken into account. But it is necessary, together with it, to use more objective methods of estimation. I offer you a short description of the basic design principles and methods of testing web sites, related to web navigation.

More important qualities of successful navigation:

  • Balance. Balance between the number of visible menu items on page (breadth) and the number of hierarchical levels in a structure (depth).
  • Ease of learning. Increasing the time it takes to learn a navigation for a site will generally lower its success.
  • Consistency. In terms of navigation, this usually refers to the mechanisms and links that appear in a steady location on the page, behave predictably, have standardized labels, and look the same across the site.
  • Feedback. Feedback in navigation can be considered in two ways: with rollovers before selecting a navigation option, and by showing location after transitioning to a new page.
  • Efficiency. Good navigation minimizes the effort to get to content. For instance, dynamic menus that require hand-eye coordination just to reach the option will slow users down.
  • Clear labels. The optimal balance of a site’s structure is related to the clarity of labels.
  • Visual clarity. Visual design isn’t just about making things look nice: it creates a better sense of orientation and to the usability of navigation.
  • Appropriateness for type of site. The success of navigation is relative to the kind of site in appears on.
  • Aligning with users needs. First, You must define your target group. Second, identify information needs of the target group.

Evaluation methods:

Heuristic evaluation. A popular, low-budget analytical usability method, heuristic evaluation are qualitative and rely on subjective inferences made by the person doing the evaluation.

  1. Prepare
    • Agree on who will do the review.
    • Becomes familiar with key pages of the site.
    • Determine the principles for evaluation.
    • Agree on key content areas and features to review.
  2. Execute
    • Go through the site, focusing on the principle at a time.
    • For each heuristic, provide a severity rating from 0 to 4.
  3. Consolidate
    • Discuss your findings with other reviewers. Agree on the potential problem areas and on the interpretation of issues.
    • Summarize reviews.
    • Determine appropriate recommendations for addressing the identified issues.
    • Create a presentation for the project team and stakeholders.
    • Develop a plan for addressing the identified issues.

Checklist review. Evaluating navigation with checklist is similar to a heuristic evaluation. But instead of overarching principles, concrete test statements. Similar to a heuristic evaluation, it’s best to conduct the review with more than one person.

Navigation stress test. The stress test method is simple. Pick a page (pages) randomly from deep within the site. Print pages, assume the you are a first-time visitor to
the site and murk up the printed pages with the symbols for each test question:

  1. What is the page about? Mark title of the page.
  2. What site is this? Circle the site name.
  3. What are major sections of the site?
  4. What major section in this page in?
  5. What is one level up from here?
  6. How do I get to the home page?
  7. How do I get to the top of this section of the site?
  8. What does each group of links represent? Circle the major groups of links:
    • More details
    • Nearby pages
    • Pages on same site, but not as near
    • Off-site pages

For question, that can’t be answered, determine the cause.

Usability testing. With this method, participants use computers as they normally would to browse the web site. Software then tracks where they clicked and how they navigated. Usability test are often structured as laboratory-based trials. Can be costly and time-consuming.

Metric analysis. A good way to learn whether your web site is achieving its goals is to gather traffic data. But it’s difficult to show cause and effect with web metrics. Modern web measurement tools are captured many important business-specific metrics, such as:

  1. Conversion ratios
  2. Customer-acquisition costs
  3. Order size
  4. Overall sales

Your goal is to tie an improvement in the navigation to an improvement in business. Before a relaunch, get a baseline measure of a key statistics important to stakeholders. The steps break down this way:

  1. Prepare
  2. Agree on the metrics to measure success, such as conversion rate or revenue.
  3. Get a baseline reading on this criteria before making improvements to a site.
  4. Execute
  5. Conduct heuristic evaluations of the current site, as well as usability test, to arrive at a list of improvements.
  6. Implement design changes.
  7. Consolidate
    • After a period of use, compare the agree-up on metrics to the baselined values.
    • Calculate the increase or decrease in the figures. Note other possible factors that could potentially influence the findings (marketing campaigns, promotions, etc.) and include these in your conclusions.

Git - základy

Erich Kaderka, 10. 12. 2009, 18:53 v kategorii Technologie, štítky:

Git je distribuovaný systém správy verzí. Mezi jeho hlavní výhody patří snadné vytváření větví (branch) a jejich slučování (merge). Díky tomu, že má vývojář celý repozitář u sebe může commitovat, mergovat nebo vytvářet nové větve i když je offline. Git má oproti jiným SCM nástrojům výhodu i v tzv staging area neboli indexu. Po přidání souborů si může vývojář znovu projít nové nebo změněné soubory než provede commit.

Instalace

V Debianu Git nainstalujeme pomocí příkazu:
aptitude install git-core

Verze pro Windows je ke stažení na zde

Vytvoření repozitáře

Nejdříve si vytvoříme adresář, poté se do něj přesuneme a spustíme git init.

mkdir muj_projekt
cd muj_projekt
git init

Takový repozitář je pouze lokalní, pokud chceme vytvořit sdílený repozitář na serveru, použijeme příkaz:

git init --bare --shared=true

Pro starší verze Gitu (< 1.6.2) je potřeba postupovat následovně

mdir new_repo
cd new_repository
git init
touch .gitignore
git add .
git commit -m "prvni commit, gitignore"
cd ..
git clone --bare --shared new_repo/ new_repo.git

Každodenní používání

Většinou moje práce s Gitem vypadá následovně, přepnu se na větev master a stáhnu si nejnovější změny:

git checkout master
git pull

Vytvořím si novou větev:
git checkout -b "nova_featura"

Provedu změny v souborech a prohlédnu si změněné soubory:
git status

Případně se podívám co jsme v konkrétním souboru změnil:
git diff soubor

Přidám buď jeden soubor:
git add file

Nebo adresář:
git add adresar/

Nebo všechny soubory
git add .

Pokud jsem nějaký soubor smazal, tak ho odstraním:

git rm soubor

Nyní se nacházím v tz stage area (index), kdy mohu ještě před commitem soubor vrátit do původního stavu pomocí:

git reset soubor

Poté soubory commitnu:
git commit -m "hlaska proc jsem provedl zmeny"

Vyplatí se psát commit hlášky podrobně, protože za pár dní ani samotný autor nemusí vědět, proč daný commit dělal, když napíše oprava bugu :).

Nyní jsou moje změny ve větvi commitnuté a je potřeba je zanést do master větve a pushnout na server. Nejdříve se přepnu na master, stáhnu si aktualní kód, poté se přepnu do větve ve které jsme provedl svoje změny, provedu rebase master větve (sloučím master a svoji větev) a udělám merge své větve do master. Poté pošlu změny příkazem git push na server:


git checkout master
git pull
git checkout nova_featura
git rebase master
git checkout master
git merge nova_featura
git push

Prohlédnu si výpis všech větví a případně pokud je moje práce na feature ukončena, tak ji smažu


git branch
git branch -D nova_featura

Závěr

I když to tak na první pohled nemusí vypadat práce s Gitem je velmi jednoduchá a přímočará. Při přechodu ze Subversion na Git se vyskytlo pár problémů (instalace na serveru, pochopení základního workflow, instalace na Windows), ale po jejich překonání si i ostatní členové týmu na Git zvyknuli a jsou jím více či méně nadšeni :).

Zdroje

Sign-up framework

Denisa Lorencová, 9. 12. 2009, 03:21 v kategorii Webdesign, štítky: , ,

Na téma „jak přivést uživatele na své stránky“ už bylo napsáno článků dost a dost, představme si tedy, že jsme již v situaci, kdy o nás uživatelé vědí a nějakým způsobem se proklikali až k naší službě. V tuto chvíli přichází možná ten nejkritičtější moment, který velmi výrazně ovlivní , zdali budeme mít možnost získat nového uživatele, nebo o jednoho možná nenávratně přijdeme - první dojem - moment, kdy se návštěvník rozhoduje, jestli je pro něj naše služba atraktivní. Moment, který si zaslouží naší pozornost, protože lidé, které ztratíme v této fázi, se na naše stránky s největší pravděpodobností už nikdy nevrátí. Jak tedy zařídit, abychom z této situace dokázali vytěžit co nejvíce?

1. Vžijte se do toho co si myslí

V ideálním světě, by každý návštěvník, který by zavadil o naše stránky, byl už prakticky předem rozhodnut, že službu chce využívat, okamžitě se nadšeně zaregistroval a pochopitelně nezapomněl sdělit všem svým známým, na jak úchvatnou stránku právě narazil. Bohužel pro nás, v takovém světě nežijeme a tak jsou naši návštěvníci povětšinou nerozhodní lidé, kterým hlavou probíhá asi tak toto: „Co to je? Co to dělá? Potřebuji to? Je to lepší než to, co používám? Používá to někdo koho znám?...“ Je už na nás, jestli se nám povede vhodnou cestou na tyto otázky odpovědět

2. Pro koho navrhujeme?

Každý jsme jedinečný, proto i naše potřeby a očekávání jsou jedinečné. Tomuto se design musí přizpůsobit - tzn. nabízet něco pro každého, nebo alespoň pokrýt co nejvíce možných přístupů. Zde je několik těch základních, na které bychom měli být připraveni:

  • Ready to go – Uživatelé, kteří jsou už rozhodnuti se do služby zaregistrovat. Vědí, co služba obnáší a jediné co potřebují, je prostor k registraci. Klíčem k uspokojení těchto lidí, je dostat z cesty vše, co by mohlo dotyčného zbytečně rozptýlit.
  • Zainteresovaní ale nerozhodnutí – Tito lidé mají o službu zájem, ale nejsou si jisti, zdali je to pro ně to pravé. Pravděpodobně mají plno otázek a na nás je, abychom jim poskytli názorné, jednoduché ale úderné a dostatečné odpovědi.
  • Pozorovatelé – Lidé, kteří shánějí informace o podobných službách v dané oblasti aby se mohli později rozhodnout, kterou službu si vyberou. Ideální pro tuto skupinu je dostatečné shrnutí a vysvětlení jak služba funguje.
  • Skeptici – V podstatě lidé, kteří si chtějí jen ověřit, že vaše služba nestojí za nic a že jsou vlastně naprosto spokojeni se svou stávající. Odpovědí jsou reference. Dostatečné množství nadšených ohlasů lze jen těžko ignorovat, podělte se o ně :)

Vytváření ideálního Sign-up frameworku

Označení Sign-up framework zahrnuje všechny informace a zdroje, které poskytujeme lidem, kteří se zajímají o naší aplikaci. Měl by obsahovat jeden nebo více následujících prvků:

  • Slogan – stručná informace vystihující podstatu vaší služby
  • Ilustrace znázorňující jak služba funguje
  • Popis služby
  • Průvodce službou a jejími featurami
  • Video nebo screencast služby
  • Reference stávajících uživatelů (pozitivní)

Co by měl dobrý Sign-up framework umožňovat

  • Názorně předvést k čemu služba slouží
  • Napovědět zdali je služba pro zájemce vhodná
  • Zodpovědět základní dotazy, které by zájemce mohl mít
  • Potvrdit nebo vyvrátit případné předsudky o službě
  • Případně u některých tipů služeb možnost vyhledat přátele, kteří službu již využívají

Jednoduchost se cení

Občas ty nejjednodušší techniky jsou zároveň i těmi nejefektivnějšími. Dobrý design by měl zvládnout odpovědět na 6 základních otázek:

  1. Pro koho je určen?
  2. Co to je? Co to umí?
  3. Jak ho můžu používat? (existuje např. mobilní verze?)
  4. Kdy ho můžu používat? (Je přístupný odkudkoliv z prohlížeče?)
  5. Proč ho používat? Jaké výhody to přináší?
  6. Jak to funguje? Jak to můžu vyzkoušet?

Příklady:

http://www.facebook.com
Facebook

Typický design sign-up frameworku pro lidi, kteří již službu znají, slogan, ilustrační obrázek víceméně "na ozdobu", minimalistický design s velkým 'call-to-action' registračním formulářem. Další věc co stojí za povšimnutí je možnost vyhledání lidí v síti i bez toho, aby byl uživatel registrovaný. Zobrazí se ovšem jen limitované množství výsledků, tedy nikdy (resp. do registrace) si nemůžete být 100% jisti, že tam "Pepa někde opravdu není".


http://www.twitter.com
Twitter

Další ukázka designu pro lidi, kteří vědí o co se jedná.


http://simplegeo.com
Simple Geo

Ukázka více úrovní informací, některým postačí titulka, jiné potěší možnost dozdědět se další informace ve fromě screencastu (průvodce featurami).


http://basecamphq.com
Basecamp
Basecamp
Basecamp

Podle mého názoru jeden z nejlepších Sign-up frameworků obsahující prakticky vše, co by tam člověk mohl chtít hledat.  Slogan, stručný popis služby s náhledem 'jak služba vypadá' a jasné call-to-action sign-up tlačítko. Pro nepřesvědčené jsou tu reference v mnoha formách (textové, video, tweetfeed) a ukázka známých firem, které službu využívají. Nechybí ani 'průvodce featurami' pro ukázku služby.

Stránka opravdu obsahuje valnou většinu doporučených technik, už je na zvážení každého z vás co je ještě únosná míra a co už je přehršel informací, který působí spíše kontraproduktivně, jednoduše proto, že se s tím nikomu nechce číst.

A závěrem, jedním z nejsilnějších, přesto v čechách překvapivě málo využívaných 'taháků' jsou pozitivní reference uživatelů. Nejen že pro potenciálního klienta budou mít pravděpodobně mnohem větší váhu než jakékoliv ódy na produkt vytvořené copywrighterem, ale i samotnému referentovi tím dáte najevo, že o jeho názor jevíte zájem, což nepochybně ocení. A co více, člověk jako tvor exhibicionistický se rád hrdě pochlubí svým úryvkem zvěčněným na vašich stránkách, což pro vás může znamenat přísun dalších zákazníků. Win -win :)

Zdroje: Designing for the social web (Joshua Porter)

Go - nový programovací jazyk od Googlu

Erich Kaderka, 12. 11. 2009, 08:40 v kategorii Programování, štítky: ,

Původně jsem chtěl napsat příspěvek o 2 přednáškách na téma Google Wave z Google Developer Day, ale když jsem se dnes ráno dozvěděl, že Google vydal nový open-source programovací jazyk, tak jsem se rozhodl, že ho vyzkouším a napíši o něm.

Instalace (Debian Squeeze/amd64)

Nejdříve je potřeba přidat do .bashrc proměnné $GOROOT, $GOOS, $GOARCH a $GOBIN

#GO
export GOROOT=$HOME/go
export GOOS="linux"
export GOARCH="amd64"
export GOBIN=$HOME/bin
export PATH=$HOME/bin:$PATH

Následně jsem si nainstaloval verzovací systém Mercurial pomocí příkazu
sudo aptitude install mercurial

a naklonoval zdrojové kódy Go.
hg clone -r release https://go.googlecode.com/hg/ $GOROOT

Jestliže máte nainstalovány všechny potřebné balíčky (bison, gcc, libc6-dev, ed), tak stačí již jen zkompilovat pomocí

cd $GOROOT/src
./all.bash

Pokud vše proběhlo bez problémů, tak by se vám měl objevit na posledním řádku výstup: 0 known bugs; 0 unexpected bugs

Hello World

První program je jen základní helloworld.go.

package main
import fmt "fmt" // Package implementing formatted I/O.
func main() {
fmt.Printf("Čauda, Go\n");
}

Ten jsem zkompiloval, nalinkoval a spustil.

6g helloworld.go
6l helloworld.6
./6.out

Proč Google vydal nový programovací jazyk?

Podle oficiální dokumentace v něm jsou naprogramovány některé interní servery (otázka je jaké a k čemu slouží) Googlu, i když je zatím brán pouze jako experiment.

Go se snaží zkombinovat rychlost vývoje dynamických programovacích jazyků jako je například Python s výkonem a bezpečností statických typovaných jazyků jako je C nebo C++ (zkompilovaný kód je zatím údajně o 10-20% pomalejší než C).

Mně osobně syntaxe Go nezaujala a vzhledem k tomu, že zatím není k dispozici žádný rozsáhlejší tutoriál, který by prakticky ukázal výhody Go, tak mě narozdíl od jiných technologii Googlu, nijak nenadchnul.

Zdroje:
http://golang.org/
www.techcrunch.com/2009/11/10/google-go-language/
http://lwn.net/Articles/361390/