Dve slike, Dve hiljade reči

Google Chrome, Preferences dijalog:

Zend Studio (Eclipse), Preferences dijalog:

WONTFIX

Joel Spolsky, u "Software Inventory" članku:

In many real-world companies, the desire never to miss any bug report leads to bug bankrupcy, where you wake up one day and discover that there are 3000 open bugs in the database, some of which are so old they may not apply any more, some of which can never be reproduced, and most of which are not even worth fixing because they’re so tiny.

Sa ovim smo se mi bili zakopali u activeCollab 2. Kada god bismo pogledali Tickets stranicu, uvek bi bila tona posla da se radi, od koga su polovinu činili nebitni bagovi i ideje za sitna unapređenja. Najveći problem je kada ovakve stvari unose takav šum da ne vidite stvarno važne stvari ili stvari koje imaju neku vrednost.

Rešenje koje smo počeli koristiti kako bismo izašli na kraj sa tim ludilom: novi, svež projekat za početak, a onda stvari koje predugo stoje u sistemu zatvorimo sa WONFIX labelom. Nije ni svaki bug report pažnje vredan… Oni koji jesu se uvek vrate:

Don’t worry, the severe bugs will come back.

Microsoft - umiruća platforma?

U zadnjih par dana smo radili na uprošćavanju izgleda email obaveštenja koja activeCollab šalje korisnicima. Kroz par kratkih dizajn iteracija smo došli do onoga što nam se sviđa i na meni je bilo da dogovoreni dizajn prekodiram. 

Meni se ovaj dizajn svideo jer jasno naglašava akciju, nije grafički težak i može brzo da se prolazi kroz niz obeveštanje i vide bitne informacije. Vrlo brzo sam iskodirao verziju koju Gmail i Sparrow korektno prikazuju, ali problemi su krenuli onog momenta kada sam upalio Outlook i pogledao kako se stvari u njemu vide.

Ukratko: "Mikrosofte, koji k???" Znao sam da Outlook ima slabu rendaljku koju deli sa ostalim alatima u Office paketu, ali nisam bio svestan da ću morati da se vraćam u 1998. Čak je i IE6 miljama ispred rendering endžina koji Outlook 2010 ima u sebi. Posle par sati frustracije i eksperimentisanja, došao sam do nečega što koliko toliko liči na originalni dizajn i stao kada je prosta funkcionalnost postignuta. Od mene toliko… Finese će dobiti fini klijenti, a Outlook dobija tek toliko upeglan dizajn da se ne raspada.

Umiruća Platforma

I tu dolazimo do jednog zanimljivog momenta, do koga je doveo proces kompletno poguban po sam Microsoft: Microsoft platforma prestaje biti bitna u očima mnogih developera! Kompanija ima mnogo korisnika, ali već godinama gubi grupu ljudi koju bih opisao kao vrh koplja - opinion-makere, programere i dizajnere koji prave zanimljive aplikacije i proizvode, tech novinare… Ti ljudi više ne koriste Microsoftove proizvode, na konferencije za štampu koje organizuje Microsoft dolaze sa Mac laptopima ili iPadima, testiraju za Windows na kraju, kada razmišljaju o nekoj inovaciji, retko kao polaznu tačku uzimaju Microsoft platformu itd. 

Nesumnjivo je da je Microsoft previše velik da bi propao i može sasvim lepo da živi u svom "malom mehuru" godinama, možda čak i decenijama, bez većih problema. Međutim, to je put umiruće platforme. Vrh koplja je okrenut na drugu stranu i samo je pitanje vremena kada će za sobom povući i dobar deo ostalih korisnika.

Nisi završio…

… dok to neko normalan ne proveri:

Rezultat cele ove igranke je stvarno upeglan sistem za filtriranje zadataka i izveštavanje koji ostatak softvera koristi na niz drugih mesta. Vredelo je :)

Korisnici i zahtevi za novim mogućnostima

Kada traže novu funkcionalnost, tipično za korisnike je da predlažu rešenje, bez da detaljno iznesu sam problem. Na primer, korisnik će pre tražiti:

Mi bismo želeli da activeCollab podržava Markdown

umesto:

Sistem za unos teksta je dosta kabast u trenutnoj verziji vašeg softvera. Mi bismo želeli da možemo brzo i jednostavno da pišemo, bez da klikćemo na opcije u toolbaru. Takođe, jako su nam bitne liste, tabele i brzo ubacivanje linkova i slika

Možda malo čudan primer, ali je prilično dobar kao prikaz jedne stvari: rešenje koje korisnici traže nije nužno ono što stvarno i žele. U ovom konkretnom slučaju, rešenje možda nije sam Markdown (iako tako verovatno deluje nekom ko ima dosta iskustva sa istim), već pomeriti granice koliko dobro može vizuelni editor da se upegla i integriše.

U suštini, ovo stvarno nije problem ukoliko ne slušate slepo korisnike. Zahteve i predloge ne treba uzimati zdravo za gotovo, već treba naći problem koji bi taj zahtev rešio. U velikom broju slučajeva, sam problem može biti rešen na mnogo elegantniji i jednostavniji način od zatraženog rešenja i stvarno bi bilo šteta to propustiti samo zato što od drveća nismo uspeli da vidimo šumu.

Kako stvari postaju stabilnije…

… commiti postaju sve manji i manji. Sada nije redak slučaj da commit bude svega dve izmene u jednom ili dva fajla. Ranije, kada je sistem pucao po šavovima, retki su bili commiti koji ne zahvataju bar 10, 15 fajlova, ponekad i mnogo više kod većih refaktorisanja.

Slična je stvar i kod verzija. Kada grana pređe u fazu održavanja (ne dodaju se nove mogućnost, samo se krpe postojeće), commiti postanu maleni i retki, dok sam rad na otvaranju grane obično znači masivne izmene i gomile promenjenih fajlova.

Zašto je ovo bitno? Verovatno i nije bitno, a ako i jeste onda samo kao "smradić" koji ukazuje na ozbiljniji problem: ako je grana već neko vreme u fazi održavanja i imamo dosta velikih commita, nešto krupnije nije u redu, verovatno "kontrola kvaliteta".

Working Effectively with Legacy Code

Evo jedan članak u duhu knjige koju upravo čitam: Working Effectively with Legacy Code. Misija je izmeniti klasu koja pravi izveštaje na osnovu praćenog vremena i troškova u activeCollab 3 tako da podržava više valuta.

Podrška za više valuta je dodata u međuvremenu i sistem za izveštavanje je nije svestan, tako da trenutno meša babe i žabe (troškove napravljene u Eurima tretira isto kao i troškove napravljene u dinarima i dolarima i samo ih sabira).

Problem je što trenutno ne postoje apsolutno nikakvi testovi za klasu za izveštavnje, pa:

1. Nisam siguran da li klasa radi kako treba bez ikakvih izmena. Malo sam se igrao i sve deluje OK, ali nisam baš 100% siguran da sam pokrio sve slučajeve.
2. Ukoliko krenem sada da prepravljam kod, nisam siguran da li će novi kod raditi kako treba bez mnogo ručnog njakanja izveštaja sa znanim podacima. Može to da radi neko drugi umesto mene (QA), ali bi se time krug između izmene i testiranja produžio na sate u najboljem slučaju (dane realno) što je previše sporo i troši vreme dve osobe umesto jedne.

Izveštavanje podržava prikaz individualnih zapisa ili sumiranih podataka, plus četiri načina grupisanja u oba slučaja, tako da baš treba vremena za ručnu pripremu podataka i testiranje. Iz tog razloga, prvi korak je napisati automatizovan test koji će nam potvrditi da kod radi ono za šta je originalno napisan da radi:

Pošto koristim activeCollab Timer da pratim vreme, znam koliko mi je vremena bilo potrebno da postavim testove: 1 sat i 15 minuta efektivno. Uzimajući da iz svog dana retko kada uspem da izvučem više od 3 sata efektivno programiranja, to stvarno deluje kao jako mnogo vremena za posao koji tehnički ni na koji način nije unapredio proizvod: ni jedna nova mogućnost nije dodata, ni jedna stranica nije ubrzana, ni jedna labela u sistemu nije prepravljena da bude jasnija…

Međutim, ono što je to uloženo vreme donelo je postavljanje sigurnosne mreže za sve današnje i buduće izmene koje će se desiti toj klasi. Pa krećemo…

Prvo što sam uradio je refaktorisao metod koji barata sumiranim izveštajima. U momentu kada je pisan, delovalo je da će prost switch raditi posao, ali je metod vremenom prerastao 300 redova koda. Kada sam ga rastavio i ponovo sastavio tako da koristi više pravilno imenovanih metoda, poterao sam ranije napisane testove da vidim da nisam nešto u međuvremenu pokvario. 10 sekundi kasnije testovi su mi rekli da klasa radi na identičan način kao i ranije, iako je sada osetno jednostavnija za čitanje i ispravke. Lepo!

Nakon refaktorisanja ide i onaj deo zbog čega je cela priča i počela: dodavanje mogućnosti izveštaja da sumiraju podatke kada je u sistemu definisano više valuta. Pre nego što se bacim na prepravljanje koda same klase, prvo treba da se napiše test koji proverava naša nova očekivanja. Naravno, pošto je ovo urađeno pre nego što smo stvarno i dirali kod, test neće proći:

Možda zvuči malo glupo pisati test pre koda, ali to je cela poenta iza Test-Drive Development pristupa. Pisanjem testa pre pisanja koda imamo priliku da lepo ispišemo očekivanja i uočimo neke rane problem u dizajnu.

Ovo je zanimljiv momenat. Ranije bih počeo ovde, međutim u ovom konkretnom slučaju iza sebe već ima dva sata efektivnog programiranja, a kao rezultat tu su sistem kojim mogu oceniti da li izmene koje budem napravio rade kako treba, plus je sam rad sa klasom jednostavniji jer sam neke komplikovane delove refaktorisao.

Idemo lagano - sada treba da izmeniti klasu da zadovoljili nova očekivanja. Uz izmenu klase i test se možda promeni na nekim mestima koja bih još dodatno da pokrijem, a koja sam prevideo kada sam ga pisao. Kada je sve gotovo, dobijemo lep rezultat:

activeCollab Timer kaže: 45 minuta za novu funkcionalnost, plus 2 sata ranije za pisanje testova i refaktorisanje.

Ovakav pristup programiranju je investicija u kvalitet softvera koji će biti poslat klijentima (najskuplji je bug koji korisnik nađe), kao i u budući razvoj. Modifikovanje bilo koje klase je osetno jednostavnije ukoliko već postoji test za nju, tako da će razvoj postajati lakši ako se sistematski prolazi kroz postojeći kod i pišu testovi za njega, iako sama aplikacija u međevremenu raste i postaje komplikovanija.

I za kraj, proces, ukratko:

1. Postavimo testove koji proveravaju da li postojeći kod radi na očekivani način;
2. U svakom kodu uvek ima nešto da se refaktoriše, tako da uzmemo lepo pa prepravimo par stvari, kako bi kod bio čitkiji, a buduće izmene lakše;
3. Prepravimo testove tako da proveravaju naša nova očekivanja i poteramo ga iako znamo da neće proći. Korisno je videti tačke u kodu na kojima nova očekivanja nisu ispunjena;
4. Prepravimo klasu tako da zadovoljava nova očekivanja;
5. Otvorimo jedno 'ladno jer smo sebi i kolegama upravo uštedeli sate posla u budućnosti, a korisnicima napravili kvalitetnije rešenje koje će manje pucati i za koje ćemo lakše i brže objavljivati unapređenja i ispravke.

Brz razvoj 101

Pogledajte log verzija 1password aplikacije za Mac: bar jedan release mesečno, uglavnom dva do tri, a nije Software as a Service! Svaka čast ekipi iz AgileBits, to se tako radi.

Osnovni princip se može sumirati u kratku "Bring value and bring it often" filozofiju koja je osnova svih agilnih metodologija razvoja. Najlepša stvar je što je takav razvoj ne samo dobar finansijski (gledano na duže staze), već i znatno zabavniji. Kada se pređe na brzu rotaciju verzija, razvoj postaje mnogo zanimljiviji pošto se stvari mnogo brže kreću i bivaju objavljene, a kupci zadovoljniji zato što ne moraju da čekaju mesecima na nove mogućnosti i ispravke.

Uvek sam "znao" (navodnici zato što ne treba mešati insinkt i znanje) da je baš takav pristup razvoju rešenje, ali nisam imao dve stvari:

• Precizno definisano zašto je to dobro, sa finansijske strane. Rešenje nudi tradicionalna proizvodnja, koja na inventar i Work in Progress gleda kao na zarobljeni kapital i teži da ga smanji. Ista stvar je i sa softverom, gde su stvari na kojima se radi u stvari inventar. Što je kraće vremena nova mogućnost u razvoju (vremenski razmak između donošenja odluke da se nešto napravi do momenta kada je to dostupno korisnicima), to bolje.
• Mogućnost da se nove verzije PHP aplikacije često objavljuju, a da to ne predstavlja problem korisnicima. Rešenje je auto-upgrade, a WordPress je celu ideju progurao u mase (sada svi očekuju to). Problem je što je to dosta spetljano kada je PHP u pitanju zbog ograničenja platforme, ali mislim da smo našli ključ i za to:

activeCollab Manager već od sledeće nedelje ulazi u (javno dostupnu) betu, zajedno sa activeCollab 3.0.2. Posle toga ide lagano peglanje kroz brzu rotaciju novih buildova, kako samog Managera tako i activeCollaba.

One speed, one gear: Go! :)

JavaScript FTW!

JavaScript je divan jezik na koji se uvek možeš osloniti:

>>> [] + {}
"[object Object]"
>>> {} + []
0
>>> [] + []
""
>>> {} + {}
NaN

via Goran Radulović.

Citat: Accountability

Jonathan Rasmusson, The Agile Samurai:

If you think you have an issue with accountability, there is an easy fix - get your team to demo their software.

Postoji pozitivan pritisak kada se od tebe očekuje da timu ili mušteriji predstaviš nešto na čemu si radio.

Fakulteti i programeri

Juče je bio prvi dan kako pozivamo ljude na ragovor za pozicije sistem administratora i C++ programera. Pored manje više klasičnih pitanja i priče o tome gde su do sada i šta radili, šta su im interesovanja itd, često se priča odmota i u nekim drugim smerovima, pa se može čuti koješta zanimljivo.

Tako smo, kroz priču o fakultetima (novosadskom Fakultetu tehničkih nauka i Prirodno-matematičkom fakultetu da budem određeniji) profesorskim garniturama na istim i sličnom, čuli zanimljivo mišljenje jednog od kandidata. On je pomenuo prilično zanimljiv problem, a to je da su fakulteti obrazovanje programera okrenuli skroz natraške.

Naime, njegovo mišljenje je da "klincima" treba dati neke higher level alate koje odmah mogu da koriste i od kojih odmah mogu da dobiju neki feedback. Dajte im SQL da vrše upite na neku sample bazu, Python da automatizuju neke svakodnevne računarske zadatke, bacite ih odmah na neko jednostavno GUI programiranje, naučite ih HTML-u i CSS-u... To je ono što ih verovatno zanima i to je ono što im može dati instant rezultate, čineći sve zanimljivim. Da se ne zaboravi i to da su oni studenti koje programiranje stvarno zanima verovatno već imali neko iskustvo sa tim stvarima, pa odmah mogu da krenu sa malo težim problemima ako predavači kod njih primete osnovu i dublje interesovanje.

Nakon što im je long hanging fruits postalo dostupno i kako polako stiču znanje da koriste te alate, onda se priča lagano širi na to šta stvarno stoji iza njih, i dalje produbljuje znanja. Matematika, fizika i sve ostalo dolazi tek na kraju, ako i tad.

Naši fakulteti naravno idu skroz obrnuto. Postoji niz slučajeva gde ljudi, koji su inače dobri programeri i praktičari, bivaju isfiltrirani akademskim predmetima, što zbog profesora koji "traže znanje", što zbog njihove lenjosti i manjka interesovanja za iste. Najbolji programeri koje znam imaju prilično fokusiranja interesovanja i ne vole da "gube vreme" na stvari koje ih ne zanimaju. Takav način funkcionisanja ih ne čini lošim programeri, ali ih često čini lošim studentima.

Iako se sa samim stavom ne slažem u potpunosti (dosta je sve uprošćeno i sve nosi svoj set prednosti i mana), ima tu nešto. U svakom slučaju, zanimljiva tema za razmišljanje.

Negacije (!PHP)

Stvarno me nervira kada moram da kucam:

if (!($user instanceof User))

Zašto jednostavno ne bih mogao da kucam:

if ($user not instanceof User)

Ili pak, ako već sanjarim:

unless $user instanceof User

Neki će reći da je u pitanju samo stvar šminke, neki da bi tako nešto samo zbunjivalo ljude (to je odgovor PHP internals ekipe na ovakve zahteve), a opet mi jako smeta taj jedan uzvičnik i dva para zagrada viška. Negacije me toliko nerviraju, da imam jednu malu igru gde uvek gledam kako da izbegnem negacije i uzvučnike kada god je to moguće, a to se ponekada završi sa previše ugneždenih IF-ova, što i nije baš najlepša stvar za videti.

PHP nikada nije bio lep jezik, pa zašto bi to sada, posle toliko godina i toliko koda koji se danas vrte na njemu, postajao? Sada je čak i teže da se takve izmene uvode u jezik jer svaka izmena potencijalno ruši kompatibilnost sa kodom pisanim za starije verzije (a svi znamo šta to može da znači na primeru petice kojoj su trebale godine da pusti korenje baš zbog problema sa kompatibilnošću sa starim kodom).

Imam čudnu naviku da stvari kao što su jezici (ne samo programski), stil i slično ponekad opisijem materijalnim objektima. Tako opisan, PHP je jedna jako ćoškasta stvar koja zvoni sve u 16 kada je zakotrljaš. Iritira to što skoro pa i čujem tu zvonjavu kada programiram, a to je nešto što se neće promeniti uskoro, što zbog PHP internals ekipe i njihove vizije gde jezik treba da ide, što zbog popularnosti platforme i miliona redova koda "u divljini" koji treba da nastave da rade u novim verzijama jezika...

Jebi ga, trava je zelenija sa druge strane.

Dilema

Jedna od stvari koja s vremena na vreme naleti je pitanje da li postoji ili zahtev da se napravi nešto što će uvoziti zadatke iz activeCollaba u Eclipse, kao Mylyn konektor ili kao potpuno nezavistan paket. Zahtev kao i svi drugi, manje popularan od nekih, ali opet dosta popularniji od nekih drugih, za neke timove nebitan, a za neke deal breaker. Definitivno tema za razmišljanje, ali tu ima jedan problem:

Lično mislim da je Eclipse kompletan promašaj, Frankenštajn napravljen od gomile otpada nabacanog na jedno mesto, tako napravljen da ne naljuti nikoga po pitanju mogućnosti, ali da te vremenom dovede do ludila i definitivno da nikada nikoga ne učini srećnim. Pogledajte samo ovaj Preferences dijalog:

Da te vidim da podesiš soft tabs iz prve, o ostatku da i ne govorim... Ne poželeti nikome!

I tu dolazimo do dileme iz naslova posta: da li svojim radom podržavati platformu na čiju pomisao vas obuzme neki čudan bes, kao da biste je obrisali iz postojanja da ikako to možete? Da li ličnim stavom i ličnim protivljenjem pucate sebi i svom proizvodu u nogu? Da li zbog ličnog stava uskratiti nešto korisno svojim korisnicima?

Po meni, projekti na kojima radimo neizbežno nose naš lični pečat, sa svim dobrim i lošim stvarima koje to nosi. To ne treba izbegavati, već prigrliti. Neka ono na čemu radimo bude oličenje našeg najboljeg Mi, pa makar to značilo izbacivanje stvari koje Mi smatramo lošim, bez obzira što ih neki ljudi traže. Naknadno izbacivanje mogućnosti je teško, tako da sve što dodamo treba da se računa i da dodaje vrednost proizvodu, jer smo Mi ti koji ćemo tu istu mogućnost morati godinama da podržavamo. Ako je Mi ne volimo i zakolutamo očima svaki put kada je neko spomene, onda je greška što smo je uopšte i dodali...

I tako A51 neće u skorijoj budućnosti raditi na Mylyn konektoru...

Traži se Mac OS X Developer

A51 is a software development company from Novi Sad. Our focus is development of tools that help organizations get projects done by employing more communication and less management.

Our flagship product, activeCollab, is used across the globe by thousands of organizations, including some of the largest technology and media companies and well known universities.

Mac OS X Developer

Job Description:

1. Develop native applications for Mac OS X

What we Offer:

1. Clean, quite, cozy environment where you can concentrate and get stuff done. We even offer home cooked lunch served in the office every day.
2. Opportunity to learn new and develop existing skills.
3. Best equipment money can buy. Tools should never limit your creativity.
4. Type of energy only small companies can offer.
5. Make the difference! activeCollab is one of the best known software products coming from Serbia.

Requirements:

1. Simply put, you need to be a good programmer and natural problem solver.
2. Experience with development of Cocoa applications.
3. Candidates who are not able to work in office in Novi Sad Monday to Friday should not apply.
4. Faculty degree is a plus, but not a requirement.

If you are interested and see a fit here, please fill out the form that is available on this page:

http://a51.wufoo.com/forms/prijava-mac-os-x/

Thank you for your time!

Koje crno samopouzdanje!?

Our entrepreneurial motivation is not confidence, it's an insatiable desire to improve. It's not about thinking your ideas are better than everyone else's, it's about never accepting any idea as being best.

Jason Cohen, Why I feel like a fraud

Dive into HTML5

Jako dobra, besplatna knjiga o HTML5: Dive into HTML5. Ne mora da se čita od reda, već možete da skočite na sekciju koja vas zanima (unapređene forme, canvas, video itd).

Improvement is fun!

It is clear to us that regardless of the number of changes we make, we see the need for more. Improvement is fun. One or two improvements uncover the need for other improvements.

John Smith, COO, Ross Controls

Reinvent vs Reuse

[There's] a famous fault in software engineers to instinctively favour reinvention over reuse, not just because they are unfamiliar with what came before, but because they misunderstand why it came before.

Ben Ward, Understand The Web

Ovaj citat mi je pao na pamet kada sam razmišljao o emailu. Email je servis Interneta koji je toliko dugo sa nama i koji ima toliko istorije da dosta ljudi koji programiraju aplikacije koje se oslanjanju na njega ne razumeju gomilu stvari vezanih za email i povezane standarda, kao ni razloge zašto su te stvari tu i zašto rade baš na način na koji rade.

Takve stvari ja u svojoj glavi imam markirane kao "legacy". Ukoliko je to nešto toliko pustlo korenje da je sada standard i da je gotovo nepromenljivo, prihvati i guraj bez obzira koliko shakovano sve izgledalo i koliko "bolje" može da se uradi.

Praćenje kretanja korisnika kroz stranice

Jutros nešto razmišljam o podršci i praćenju korisnika - ne bi li bilo lepo znati koje je stranice korisnik prethodno posetio (i kako je došao do njih) pre nego što vas je kontaktirao za pomoć? Iz toga bi se dosta dalo zaključiti: koliko posetioci stvarno obraćaju pažnju na dokumentaciju, da li prvo pretražuju ili odmah klikaju na Contact dugme itd.

I tako nažvrljam na papiru sledeće:

posete -< otvorene stranice

Svaka poseta može da ima niz otvorenih stranica. Dovoljno jednostavno samo po sebi, ali nedovoljno ukoliko se ne prati sa koje stranice je korisnik došao na koju stranicu. Davno smo prerasli browsere sa jednim prozorom i doba kada su se korisnici linearno kretali kroz sajt. Ponašanje današnjih korisnika više liči na drvo sa gomilom račvanja nego na flat listu stranica koje su posetili.

I tu je problem - kako pratiti koje stranice otvaraju koje stranice?

Prva stvar koja mi je pala na pamet je jednostavno kačenje ID-ja trenutno otvorene stranice na sve linkove na stranici (jedna linija JavaScripta bi sasvim lako nakačila ove vrednosti):

http://www.activecollab.com/contact?from=123

gde je from vrednost ID trenutno otvorene stranice u logu. Najveći problem kod ovog pristupa je što se "prljaju" URL-ovi sa podacima koji bi generalno trebalo da se prenose u pozadini.

Takođe ne znam kako botovi pretraživača tretiraju ovakve URL-ove. Da li smatraju stranicu drugačijom kada je GET parametar drugačiji? U kojoj situaciji ignorišu određene GET parametre? Kada liče na hash? Ima li neko više informacija o ovome?

Očigledno "prljanje" bi se dalo rešiti JavaScriptom tako što se presreće klik događaj svakog linka i pre same redirekcije kači ID trenutno otvorene stranice. Ovo ne bi radilo kada posetilac otvara linkovanu stranicu u novom tabu jer se tada preskače klik događaj. Otvaranje stranica u novom tabu je dosta čest slučaj, posebno kada se traže neke informacije bez da se jasno zna gde se iste nalaze (nakon pretrage foruma npr - posetilac će isklikati sve top teme u novim tabovima i tražiti odgovor na svoj upit u njima).

Druga opcija je da se oslonimo na browser da nam kaže odakle je korisnik došao. Ovo je nepraktično zato što nije potpuno rešenje (neki korisnici isključu prosleđivanje referrer informacija) i što bi onda na osnovu referer stranice morali da kopamo po logu i tražimo tačan ID prethodne stranice. Deluje kao nepotreban korak pošto taj info već ionako imamo na prethodnoj stranici.

Treća opcija koja mi je pala na pamet je da se jednostavno svim linkovima doda rel="nofollow", a struktura sajta ponudi kao sitemap. Ovo je naravno jako glupo pošto bi pretraživač video gomilu stranica na koje ni jedna druga stranica "zvanično" ne linkuje i verovatno bi im dobrano oborio vrednost.

I tako ne dođoh ni do kakvog zaključka... Cela ova priča je samo razmišljanje naglas. Zakucam tako ponekad sa problemom koji mi deluje interesantno iako i nemam stvarnu potrebu za rešavanjem istog. Zanimljivo je ipak, kao vežba za vijuge ako ništa više :)

Šta smo naučili iz bete

Pre nešto manje od dve nedelje objavili smo activeCollab 2. U pitanju je verzija na kojoj se dosta drugo radilo, sa nizom značajnih unapređenja.

Pored niza sitnih i krupnih unapređenja, ima i stvari (mogućnost sistema da prima emailove npr) koje iz korena menjaju kako ljudi koriste sistem. Takva verzija ne može da prođe bez bete. Manje, bug fix verzije sa sitnijim unapređenjima mogu da idu (samo paziš šta radiš i kontrolišeš se da se ne zaneseš previše sa dodavanjem novih stvari), ali nešto sa dosta izmena ne ide.

Prošle godine, u slično vreme je išla activeCollab 1.1 beta i to je bio prvi put da smo imali testiranje tog tipa i te veličine. Beta je bila javna tako da su svi koji su imali licence mogli da skinu novu verziju i testiraju je. To se pokazalo kao dobar pristup tako da smo na isti način išli i sa betom za verziju 2. Ono što je bila greška je to što smo za 1.1 bete dodavali nove mogućnosti.

Kada se tokom bete dodaju nove mogućnosti, svi testovi padaju u vodu - na ovaj način u sistemu se uvek nalaze stvari koje su nove i nestabilne. Naučeni greškom, activeCollab 2 beta je lansirana tek kada smo imali sve mogućnosti koje smo želeli da predstavimo. Svrha bete nije da timu da još vremena da nabaca još koju novu mogućnost, već da mu omogući da ispegla ono što ima i postara se da je sistem stabilan.

Pristup da se mogućnosti kompletiraju pre bete, pa zatim peglaju bez dodavanja novih, ima još jednu dobru stranu: tačno se zna kada je verzija gotova - kada se stabilizuje. Ukoliko se nove mogućnosti dodaju tokom bete, konačni set mogućnosti je uvek otvoren pa se jako lako zaneti, dodati previše novih stvari i celo "testiranje" produžiti za još koji mesec. Na kraju stvarno završite sa više mogućnosti, ali su one nestabilne i prava su noćna mora za podržavanje.

Zato sa betama treba pažljivo:

1. Napravite sve mogućnosti koje želite da finalna verzija ima i onda ih peglajte, bez dodavanja novih mogućnosti.
2. Pažljivo odabrate datum kada želite da vidite finalnu verziju, ali ga nipošto nemojte objaviti. Ako to uradite, velika je verovatnoća da ćete požuriti sa betom usled pritiska od strane korisnika, a samim tim i izbaciti manje stabilan proizvod. Ovo se uvek vrati kao bumerang u vidu značajno više posla oko podrške.
3. Što se podrške tiče, tretirajte betu kao i bilo koju drugu stabilnu verziju. Izvlačenje na fazon: "Beta je, i treba da ima greške. Strpi se do sledeće verzije" će za rezultat imati da će se ljudi opeći i neće želeti sledeći put da pomognu.
4. Opustite se i uživajte u procesu. Pritisak uvek za rezultat ima greške i uglavnom je kontra-produktivan. Umesto da šizite i gurate oštre rokove, opustite se i polako sa korisnicima privedite betu kraju. Na kraju ćete izbaciti stabilan proizvod bez da osedite u procesu.

U poređenju sa prethodnom beta koja je bila dosta napeta, verzija 2 se desila polako i na kraju smo stvarno zavriši sa znatno boljim proizvodom za koji nije trebalo toliko podrške kada je početna navala prošla. Sada se već radi na narednoj verziji pa se opet nadamo skoroj beti.

PS: Tekst sa istom temom i savetima, ali malo drugačijim sadržajem je prekjuče objavljen na A51 blogu.