http://stronger.epsi.pl/

Agile database modelling

Sun, 10 Jan 2010 18:04:11 +0100

Things change. New laws are being passed, new business rules are kicking in, new requirements emerge and old ones get phased out. To keep the planets moving software must play catch up and good developer can be easily spotted: their code is ready for changes pretty much all the time and the change won't be a painful one.

NoSQL

The überpopular term NoSQL is not the thing I'm about to propose here. Despite its enthusiastic uptake the established position in the industry is yet to come. Secondly, because there are absolutely outstanding tools, books, common practices, and other knowledge sources on relational databases, SQL language, and Object-Relational Mapping. There are RDBMSes that range from zero to megabucks, there is workforce on the market that range from interns to six-digits-salary wizards. Everywhere you look the web is living and breathing in relational databases.

But I'm getting off the point. To outline this picture quickly, let's put two items into the equation:

design and implementation details do change
database schemas are strict and do not automatically adopt to changes by themselves

Granted the two forces opposing, cracks on the surface are inevitable. Sure, you can bend your neck and keep updating schema with every change. Or you could employ one of this big, complicated ORM engines and force it on all memebers of your team. Or, you can oppose all change and get replaced with someone competent. Finally, you can be smart and use in-schema serialised LOBs to provide required dynamic features. To illustrate what I mean, may I present real life example. I use PDO for database access, DAO for persistence handling, and JSON LOBs for dynamic containers. First, example without dynamic features:

CREATE TABLE orders (
        id              SERIAL PRIMARY KEY,
        ref_num         VARCHAR(60),
        created_on      TIMESTAMP NOT NULL DEFAULT current_timestamp,
        customer_id     INT
);

class Order {

        protected $columns = array('id', 'ref_num', 'created_on', 'customer_id');
        protected $data = array();
        protected $dao;

        public function __construct() {
                $this->dao = new PDODataAccessObject('orders', 'id', $this->columns);
        }

        public static function getById($id) {
                $o = new Order();
                $o->data = $o->dao->getByPrimaryKey($id);
                return $o;
        }

        public function __get($k) {
                return array_key_exists($k, $this->data) ? $this->data[$k] : null;
        }

        public function __set($k, $v) {
                $this->data[$k] = $v;
        }

        public function save() {
                $this->dao->save($this->data);
        }

}

This is minimal implementation of working persistent object. As you can possibly imagine class PDODataAccessObject is a relational storage, which was skipped as not being relevant for this example. You can retrieve Order from database by primary key simply typing $order = Order::getById(10). You can read echo $order->created_on and write $order->ref_num = 12345 object properties, that will be stored in database upon $order->save(). DAO will figure out whether to insert new row into db or update existing – but that's not relevant either. Let's enable class Order for dynamic schema.

CREATE TABLE orders (
        id              SERIAL PRIMARY KEY,
        ref_num         VARCHAR(60),
        created_on      TIMESTAMP NOT NULL DEFAULT current_timestamp,
        customer_id     INT,
        json         TEXT
);
Column "json" is a JSON container for dynamic properties.

class Order {

        protected $columns = array('id', 'ref_num', 'created_on', 'customer_id', 'json');
        protected $data = array();
        protected $json;
        protected $dao;

        public function __construct() {
                $this->dao = new PDODataAccessObject('orders', 'id', $this->columns);
        }

        public static function getById($id) {
                $o = new Order();
                $o->data = $o->dao->getByPrimaryKey($id);
                return $o;
        }

        public function __get($k) {
                if (in_array($k, $this->data)) {
                        return array_key_exists($k, $this->data) ? $this->data[$k] : null;
                }
                if (is_null($this->json)) {
                        $this->json = (array)json_decode($this->data['json'], true);
                }
                return array_key_exists($k, $this->json) ? $this->json[$k] : null;
        }

        public function __set($k, $v) {
                if (in_array($k, $this->data)) {
                        $this->data[$k] = $v;
                        return;
                }
                if (is_null($this->json)) {
                        $this->json = (array)json_decode($this->data['json'], true);
                }
                $this->json[$k] = $v;
        }

        public function save() {
                $this->data['json'] = json_encode($this->json);
                $this->dao->save($this->data);
        }

}
Parts in bold were added to previous implementation.

Note the additional column json in table schema. This is where your dynamic properties go. Now, you are free to store any property you want without making any change to schema! Like, $order->if_not_delivered_please_call = "085123456"

No DBA would ever design something like this!

Yep, true. It is precisely because what most DBAs tend to care about is their golden temple of normalised tables, non-reduntant schemas, and optimal column sizes. It's the mental wank, the uplifting feeling of doing "Proper Engineering" that hardly ever contributes to anything but self esteem. Such DBAs would fear of a craftsman who treats their golden temple as a mean to an end and not an end itself, a developer who rather than sticking to "middleware" operates across and between layers where needed.

Dynamic schema extension as presented above has severe limitation of not being easy to report upon. You cannot retrieve records by columns stored in serialised LOB. It's just not suitable for that purpose. But serialised LOBs have this nice feature that once necessity arises, their content can be easily migrated to dedicated column. I.e. let's say that putting employee_id in Order object is becoming a common thing. Now, manager wants to know how do employees perform. Reporting on dynamic column is not possible, but at least, since information was stored in JSON, writing a five-liner that would extract property employee_id and store it into newly created column is a no-brainer. Now, DBA's been saved from heart attack.

However not an one-size-fits-all type of tool, dynamic schema can be a life saver in situations when it is unknown what sort of fields are worth storing into db. It's also perfect for rapid prototyping, where you don't really want to remodel your table columns endlessly and just get the shit running asap. Agile schema modelling can buy you significant amount of time before stabilising your code. Then, once you have pretty good idea on how is this all expected to work, you can start pulling dynamic properties into strict db columns.

Landscape od Canonical

Tue, 18 Aug 2009 17:22:51 +0200

Ten wpis NIE JEST o platformie Launchpad. Landscape != Launchpad.

Ponad rok temu pojawiło się ogłoszenie, że Canonical ma zamiar stworzyć oprogramowanie do grupowego zarządzania systemami. Sprawa przeszła jednak poniżej radarów prasy branżowej i blagsfery. Ponieważ ostatnio pojedynkowałem się bezcelowo na argumenty ze zwolennikiem Windows, przypomniałem sobie o Landscape. Rzeczony windziarz zarzucał, że w Linuksach brakuje odpowiednika windowsowej konsoli administracyjnej (MMC) do zarządzania większą liczbą maszyn. Moja odpowiedź poszła w trzech kierunkach:

MMC służy tylko rozwiązywamiu problemów stworzonych przez same Windowsy
odpowiednikiem MMC w Linuksach jest konsola tekstowa
jest Landscape

W tym ostatnim przypadku strzelałem w ciemno, bo o Landscape dawno nikt nie napisał. Po chwili, namysłu... krótkiej chwili, by nie angażować się zbytnio w ten proces, zapisałem się na jazdę próbną z tym narzędziem. I w zasadzie o całej sprawie zapomniałem na dwa tygodnie. Zaproszenie przyszło wczoraj, i ponieważ tak się akurat składa, że mam jeden hostowany RPS działający pod Ubuntu to z łatwością skonfigurowałem go do pracy z Landscape. Sprowadziło się to do zainstalowania jednego pakietu i tony zależności z bieżącego repo i odpowiedzi na kilka banalnych pytań.

I.

System składa się z dwóch części. Pierwsza to demon instalowany na własnej maszynie. Druga to webowy frontend dostępny pod landscape.canonical.com. Po kilku prostych i dobrze opisanych czynnościach konfiguracyjnych otrzymujemy dostęp do pełnej konsoli administracyjnej. Wygląda ona tak:

Zachęcony przejrzystym interfejsem postanowiłem zdziałać coś, co miałoby pozory rzeczywistej pracy. Postanowiłem więc udać się tam, gdzie wysyła mnie lista alertów, czyli do aktualizacji pakietów.

Instalacja jest banalna i sprowadza się do kliknięcia pakietów z listy i zatwierdzeniu zadania. Przypomina to nieco starego dobrego, najpierw kochanego, potem znienawidzonego dselecta.

Na screenshocie widać pasek postępu, ale nie jest on jednak ajaksowym gadżetem, który przyrasta w miarę postępu prac. Po odświeżeniu strony jego wartość podniosła się do 33%, co oznaczało, że paczki zostały pobrane i zaczyna się właściwa instalacja. Po niedługim czasie mogłem już oglądać raport poinstalacyjny.

II.

Pierwsze wrażenie z Landscape jest znakomite. Potrafię sobie wyobrazić, że w przypadku większej ilości serwerów potrafi ono ułatwić uzyskanie lepszego obrazu całościowego infrastruktury. Ponadto ciekawe jest odejście od klasycznej roli root-a jako administratora systemu. W Landscape można dodawać wielu administratorów bez konieczności dopisywania ich do sudoers. Ponadto, administratorzy mogą subskrybować powiadomienia e-mailem o konretnych zdarzeniach.

Przysłowiową wisienką na tak zwanym torcie (© Szyman) jest możliwość prezentacji wykorzystania zasobów systemu w postaci wykresów. Oprócz zajętości pamięci operacyjnej i masowych czy temperatury można dostarczyć własnych źródeł danych, które wygenerują wykres dowolnej funkcji, jaką tylko uda się nam wytrzasnąć. Źródła danych - to brzmi dumnie. W rzeczywistości są to zwykłe skrypty z podanym she-bangiem, czyli dowolnym interpreterem, który tylko jest dostępny na maszynie, więc jeśli tylko mamy ochotę na odrobinę dziwacznej perwersji możemy podać np. #!/usr/bin/php.

I c4n haz one?

Na lot testowy z Landscape można zapisać się na stronie produktu. Aplikacja jest prostsza niż niejeden panel systemów hostingowych i być może celuje nawet w ten sam segment rynku - kto wie? W końcu po co komu cPanel czy Plesk (jeden gorszy od drugiego) kiedy ma do dyspozycji tak przyjemną w użyciu konsolę webową.

Landscape z początku był aplikacją hostowaną u Canonical (model Application Service Provider), jednak producent ogłosił niedawno jej dostępność w instalacji on-site. Roczna licencja wyniesie $150.

Moar on Landscape blog

Tak zdechł XHTML i chuj mu na grób

Fri, 03 Jul 2009 23:19:33 +0200

(ten grób pochodzi z piosenki Arkadiusz by Homo Twist)

I badzo dobrze, bo miejsce pięknych standardów jest w muzeach utrzymywanych z pieniędzy podatników zarabiających dzięki standardom, które wprawdzie piękne nie są, ale są za to (by sparafrazować profesora Bartoszewskiego) sympatyczne.

Gęba pełna frazesów

Kiedy byłem pięknym młodzieńcem zwykłem głosić z przekonaniem, że każdy problem da się rozwiązać w standardowy sposób. Jeśli rozwiązanie nie posiada szablonu rozwiązania to należy go stworzyć i ustandaryzować, bo przecież na wszystko da się znaleźć wystarczająco obszerny algorytm czy format. Ponadto dobre rozwiązanie powinno cechować się uniwersalnością, zatem wszystkie pośledniejsze rozwiązania powinny zostać uogólnione za pomocą dodatkowej warstwy abstrakcji. I te pe, i te de, kosmiczna harmonia i zen.

Szybki reality check

Teraz pobawimy się w grę fabularną i ja będę twoim mistrzem gry. Możesz sobie stworzyć avatara, ale nie musisz, bo wynik rozgrywki mogę ci zdradzić już teraz – będąc wielbicielem XHTMLa wielkiego sukcesu nie odniesiesz. I nie myśl, że poniższa gra nie ma wiele wspólnego z developersko-biznesową rzeczywistością. Ma całkiem sporo – straciłem już dawno nadzieję, że życie zacznie mnie nagle rozpieszczać bardziej sensownymi wyborami.

Dołączasz do zespołu tworzącego aplikację WWW. Jest już napisane trochę kodu, który raczej słabo się waliduje. Poziom wiedzy pozostałych członków zespołu jest zróżnicowany: kilku gości świeżo po studiach, jeden nadęty mastahaka, dwójka całkiem sensownych develi. Co robisz?
Zaczynasz tworzyć brakującą funkcjonalność pozostawiając kod niezgodnym z żadnych ze standardów byle tylko działał w FF i IE
Przepisujesz aplikacją na zgodną z XHTML

42

Odpowiedzią na większość problemów, z którymi miałem szansę się zmierzyć była dziwna mieszanka solidnej inżynierii, doświadczenia, dystansu do technologii, szczęścia, paniki, braku czasu oraz jasna konieczność indywidualnego podejścia do zagadnienia. Wszelkie automaty, uniwersalne formaty i metasilniki okazywały się niewłaściwe, w najgorszym przypadku uniemożliwiały wykonanie zadania. Architektoniczni astronauci budują piękne cacka, których nikt nie potrafi poprawnie używać. Dokładnie takie samo zdanie mam o XHTMLu. Jest to przeteoretyzowany gniot, produkt myśli obsesyjnego purysty, który w zamierzeniu ma łączyć cechy XMLa i HTMLa. Byłoby fantastycznie gdyby łączył ich zalety, ale niestety łączy również ich wady. I jest to bardzo zła wiadomość, bo o ile zalety obu formatów czasami bywają przydatne, to ich połączone wady zawsze stanowią przeszkodę. Gdyby było inaczej to wszyscy z uśmiechem na twarzy używalibyśmy takich pereł architektury jak XHTML, SOAP czy CORBA, tym czasem wszystkie wymienione chętnie widziałbym w tym samym miejscu, w którym obecnie znajduje się Betamax.

PHP+SOAP+WSSE

Wed, 24 Jun 2009 13:26:54 +0200

Pick any two and your life will remain nice and easy. Pick all and you will want to hurt yourself with random object in reach. PHP native class for handling SOAP calls can't do WS-Security. Here's how one can work around this problem.

class WSSESoapClient extends SoapClient {                                                                                           
        protected $wsseUser;
        protected $wssePassword;

    public function setWSSECredentials($user, $password) {
        $this->wsseUser = $user;
        $this->wssePassword = $password;
    }

    public function __doRequest($request, $location, $action, $version) {
        if (!$this->wsseUser or !$this->wssePassword) {
            return parent::__doRequest($request, $location, $action, $version);
        }

        // get SOAP message into DOM
        $dom = new DOMDocument();
        $dom->loadXML($request);
        $xp = new DOMXPath($dom);
        $xp->registerNamespace('SOAP-ENV', 'http://schemas.xmlsoap.org/soap/envelope/');

        // search for SOAP header, create one if not found
        $header = $xp->query('/SOAP-ENV:Envelope/SOAP-ENV:Header')->item(0);
        if (!$header) {
            $header = $dom->createElementNS('http://schemas.xmlsoap.org/soap/envelope/', 'SOAP-ENV:Header');
            $envelope = $xp->query('/SOAP-ENV:Envelope')->item(0);
            $envelope->insertBefore($header, $xp->query('/SOAP-ENV:Envelope/SOAP-ENV:Body')->item(0));
        }

        // add WSSE header
        $usernameToken = $dom->createElementNS('http://schemas.xmlsoap.org/ws/2002/07/secext', 'wsse:UsernameToken');
        $username = $dom->createElementNS('http://schemas.xmlsoap.org/ws/2002/07/secext', 'wsse:Username', $this->wsseUser);
        $password = $dom->createElementNS('http://schemas.xmlsoap.org/ws/2002/07/secext', 'wsse:Password', $this->wssePassword);
        $usernameToken->appendChild($username);
        $usernameToken->appendChild($password);
        $header->appendChild($usernameToken);

        // perform SOAP call
        $request = $dom->saveXML();
        return parent::__doRequest($request, $location, $action, $version);
    }

} // class WSSESoapClient
Use method setWSSECredentials() to enclose WS-Security header in SOAP message.

Code above is a modification and extension of reply to Q#953639 on StackOverflow.com

video/theora - bo mamy XXI wiek

Thu, 18 Jun 2009 01:24:35 +0200

W ostatnich dniach przewaliła się przez Internety wiadomość sprzedana ustami Chrisa DiBony, jakoby format Theora był dla Google niewystarczający technologicznie, w związku z czym YouTube - owszem - rozważa użycie nowego tagu video z proponowanego standardu HTML 5, ale do serwowania plików w formacie H.264. Powodem takiego postawienia sprawy mabyć rzekoma dbałość o pasmo. Chris ostrożnie zasugerował, że pliki zakodowane Theorą i Vorbisem mają być większe przy zachowaniu tej samej jakości co H.264 i MP3/AAC. Na reakcję świadomej technologicznie części społeczności nie trzeba było długo czekać. Greg Maxwell i Maik Merten przedstawili nienaukowe, ale w miarę obiektywne porównania obu par formatów.

Dość przemiału newsowo-blogowego. Teraz ja się zapytuję: kto za to zapłaci gdy wejdzie w życie plan pobierania opłat licencyjnych za kodowanie i/lub dekodowanie H.264? Opcji jest kilka. Dostawca treści - co wydaje się być mało prawdopodobne, z uwagi na sporą siłę jaką dysponują więksi providerzy, czy raczej końcowy odbiorca, któremu kodeki zostaną dostarczone w cenie systemu operacyjnego lub sprzętu? A może pojawi się nowy model licencjonowania technologii i strony zaczną pobierać opłaty za każdorazowe odtworzenie multimediów? "Twój kredyt odtworzeń został wyczerpany - aby obejrzeć to video doładuj swoje konto YouTube." - jak ci się podoba?

Zwolennicy ponoszenia przez użytkownika opłat za korzystanie z technologii lubią odpowiadać pytaniem: kto zapłaci za jej rozwój? Ja na to zadaję kolejne: kto płaci za rozwój istniejących bezpłatnych technologii? Z całą pewnością Dirac, Theora, Vorbis, Speex i inne nie powstały z powietrza. Mniejsza już o jakiś tam kodek, weźmy grubszą sprawę: kto zapłacił za technologię znaną pod nazwą TCP/IP?
Pozostaje jeszcze argument technologiczny - dlaczego używać słabszego formatu, skoro istnieją lepsze? Otóż te lepsze wymagają całkiem sporej mocy obliczeniowej, co nie jest bez znaczenia w przypadku urządzeń przenośnych (arytmetyka zmiennoprzecinkowa!). Z pewnością lubisz mieć trochę prądu w swojej komórce i jeśli jesteś posiadaczem Nokii 3600 przeklinasz konieczność ładowania co drugi dzień. Dlaczego zatem nie pozostawić specyfikacji formatu video bez definicji, by umożliwić odtwarzanie intensywnych obliczeniowo multimediów tym, którzy mogą? Melduję posłusznie obywatelu kapralu, że udzielam odpowiedzi: z tego samego powodu, dla którego znacznik img ma ściśle sprecyzowaną listę formatów koniec odpowiedzi obywatelu kapralu.

Tak się akurat szczęśliwie składa, że Google oczekuje sugestii na temat rozwoju serwisu YouTube. Pomóżmy im zatem podjąć właściwą decyzję za pośrednictwem tej oto strony. Krótki formularz zawiera pole odpowiedzi otwartej po zaznaczeniu ostatniego checkboksa. Oto moja:

Teraz twój ruch.

Mała rzecz a cieszy

Sun, 14 Jun 2009 16:54:27 +0200

Kolejny dodatek do Folksr-a to filtr tagów. Działa ograniczająco (spójnik AND) – im więcej tagów zaznaczysz tym krótszą listę otrzymasz. Tak jak w Google.

Przy okazji zmiany przerobiłem również sposób sortowania. Teraz działa bez przeładowania strony, wykorzystując Ajax. Na marginesie, czy wspominałem już, że JavaScript to genialny język? ;-)

Folksr - pierwsze dwa tygodnie

Sat, 06 Jun 2009 21:00:44 +0200

Upływa właśnie drugi tydzień prywatnej bety Folksr-a. Pora na krótkie podsumowanie okresu najgwałtowniejszego (jak na razie) rozwoju.

Wasze propozycje, które ziściły się

Nowy tryb pracy widgetu: Ja, znajomi i wszyscy, którzy mają mnie w swoich znajomych. To ustawienie powoduje, że prezentujesz w widgecie również tych, którzy lubią twój blog i mają go w swojej liście znajomych, pomimo, że nie są na twojej liście.
Upload własnego avatara. Poprzednio Folksr pobierał mordkę użytkownika z serwisu Gravatar. Teraz możesz załadować własną grafikę.
Kto ma mnie w znajomych. Na stronie znajomych została dodana lista użytkowników i ich blogów, którzy linkują do ciebie. Dodatkowo, w liście twoich znajomych pojawia się informacja gdy twój znajomy również ma cię na swojej liście.
Powiadomienia pocztą o dodaniu do znajomych. Gdy ktoś doda twojego bloga do listy znajomych zostaniesz o tym fakcie powinformowany emailem.
XML-owa sitemapa. Dzięki niej Google i inni będą mogli skuteczniej dotrzeć do profili użytkowników i ich blogów. Trochę darmowego page ranku nie zaszkodzi ;-)
Statystyki wejść i wyjść na stronie wpisów. Bardzo często zgłaszana funkcja, która wyświetla liczbę przybyć i wybyć z/na inne blogi. Poniżej liczby odsłon pojawiają się mniejszym pismem dwie dodatkowe wartości: wyjścia→wejścia.
Sortowanie listy wpisów wg różnych kryteriów. Logiczną konsekwencją poprzedniej funkcji wydaje się być szeregowanie stron w oparciu o kolejność zaindeksowania, tytuł (alfabetycznie), ilość wyświetlen oraz wejść i wyjść z/na inne blogi.

To wszystko dzięki waszym zgłoszeniom.

Plany na nieodległą przyszłość

Przepisany ekran edytora skórki. Edytor skinu działa poprawnie, ale nie jest szczególnie piękny. Plan obejmuje przeorganizowanie podstrony oraz dodanie biblioteki przykładowych skórek. Podgląd aktualnie tworzonego widgetu będzie dodany w dalszej kolejności. Została zaproponowana nazwa "szablon" w miejsce słowa "skórka".

Wsparcie dla blogów na Blogspocie. Mam nadzieję, że wkrótce zmagania z denną dokumentacją od Google zaowocują pojawieniem się pluginu i detektora blogów opartych na silniku Blogger/Blogspot.

Migracja do innej domeny. Trochę wysiłku musi zostać włożone by przeindeksowanie wpisów pod inną domenę było możliwe.

Filtrowanie powtórzeń i przeładowań w logach. Obecnie każde kliknięcie jest odnotowane, choć nie zawsze powinno. W szczególności przeładowania strony nie powinny liczyć się podwójnie.

Garść liczb

Od początku prywatnej bety ilość wyświetleń widgetu wzrosła dwukrotnie, do poziomu ok. 2800 odsłon. W sumie tyle razy wasze blogi były oglądane. Dzienna wartość szczytowa to 3813 odsłon. Podobny wzrost dotyczy liczby kliknięć w widget (clickthrough). Obecnie jest ona na poziomie ok. 70 dziennie, co stanowi 2,5% wyświetleń - to lepiej niż w przypadku reklam Google!

Folksr indeksuje 1731 wpisów z 21 blogów (płodni jesteście!). Liczba zaindeksowanych tagów wynosi 8781, z czego 4004 jest unikalnych. Średnia ilość tagów na post to 5,09 (czyli moje wcześniejsze analizy były trafne).

Serwer Folksr-a działa pod Ubuntu 8.10 z Apache, PHP i bazą PostgreSQL. Najbardziej skomplikowane złożenie SQL obejmuje 5 tabel + 2 podzapytania z grupowaniem. Obciążenie maszyny oscyluje w granicach 0,15-0,25. Oznacza to, że mamy olbrzymi zapas mocy, którego nie zawahamy się użyć ;-)

Beta 2

Nadchodzące dni będą dla Folksr-a dalszym ciągiem prywatnej bety. Nadal znajdują się drobnostki, które wymagają naprawy – lepiej gdy zdarzają się kilku osobom niż miałyby dotyczyć setek użytkowników. Z pewnością gdzieś czai się także kilka nieprzetłumaczonych komunikatów (czego zwalczaniem zajmuje się breffa, kudosy i creditsy). Ponadto chciałbym pozyskać więcej testerów na platformach WordPress i Blogspot. Po zakończeniu prywatnych testów Folksr będzie miał już wystarczającą ilość zaindeksowanych wpisów, że podpowiedzi widgetu staną się dużo bardziej trafne.

Dzięki wszystkim dotychczasowym betatesterom, w szczególności tym raportującym błędy i dającym link do Folksr-a na swoich blogach. Możecie podsyłać propozycje ulepszeń, pamiętajcie tylko: Folksr powinien pozostać prosty w obsłudze (w następnych wpisach wyjaśnię dlaczego).

Folksr: algorytm szukania podobnych wpisów

Fri, 29 May 2009 10:59:41 +0200

Program prywatnej bety Folksr-a postępuje znakomicie i odzew społeczności jest ogromnie nagradzający. Szczególne podziękowania należą się roziemu i breffie (czy to się odmienia?) za cenne uwagi i raporty. Myślę, że będę Was musiał jakoś wynagrodzić, chłopaki ;-) Ale do rzeczy; oto algorytm używany przez Folksr-a do wyszukiwania podobnych wpisów.

Co się stanie jak dodam 1000 tagów?

No właśnie. Obliczanie podobieństwa wpisów na podstawie tylko i wyłącznie liczby tagów nie jest lepszym pomysłem. Technologia WWW już to przerabiała w postaci nagłówków meta z atrybutem keywords. Pole to szybko stało się na tyle bezużyteczne, że obecnie żadna wyszukiwarka nie bierze go pod uwagę. Folksr ogranicza liczbę indeksowanych tagów do dziesięciu. Jest to przyzwoita liczba, którą można wyrazić esencję treści i zachęca do rzetelnego tagowania swoich wpisów. Jest poza tym zgodna z ogólnymi wzorcami interfejsów użytkownika, gdzie 3-7 to zakres optymalny (jak myślicie, skąd 37signals wzięło swoją nazwę?).

Punkty za ilość

Każdy zbieżny tag jest punktowany i stanowi równą część wyniku. Załóżmy więc, że popełniłem wpis otagowany jako ubuntu 9.04 jaunty launch party dublin. Przyjmijmy też, że dwie inne osoby postanowiły podzielić się z blogsferą podobnymi wpisami. Pierwszy z nich zawiera tagi ubuntu 9.04 release party katowice, drugi jest oznaczony ubuntu 9.04 jaunty jackalope linux unix gnome recenzja. W obu przypadkach znalezione blogi mają po trzy tagi wspólne z wpisem na blogu gospodarza, ale ten drugi jest dużo szerszy. Jak ocenić który z nich jest trafniejszy?

Punkty za jakość

Do głosu dochodzi zatem zasada, że nie liczy się ilość lecz jakość. Ponieważ szerzej otagowane wpisy mogą być mniej trafne Folksr pomniejsza wagę wpisów o dużej liczbie tagów. Zapobiec ma to dodawaniu etykiet, które są słabo bądź wcale nie powiązane z tagami na blogu gospodarza. W drugim przypadku przytoczonym powyżej można się zgodzić, że tagi linux unix gnome są nieco nadmiarowe, a nawet błędne (unix???)

Jakość × ilość

Folksr bierze pod uwagę zarówno jakość jak i ilość. Każdy tag ma przyznaną pewną liczbę punktów, ale im więcej tagów tym punktów mniej. Ponieważ liczba tagów ograniczona jest do 10, to dwie skrajne możliwości są następujące:

1 tag za 10 punktów
10 tagów po jeden punkt każdy

Wielkości pośrednie łatwo sobie wyobrazić: 2 tagi po 9 punktów każdy, 3 tagi po 8 punktów każdy, itd. Gdy wartość pojedyńczego tagu jest wyznaczona Folksr przystępuje do zliczania pasujących tagów. Wartość każdej etykiety zostanie pomnożona przez liczbę tagów zgodnych z tagami na blogu gospodarza, wg wzoru:

wynik = (11 - liczba tagów) × liczba podobnych tagów

Wracając do wcześniejszych przykładów, wyliczmy punktację dla każdego z nich:

ubuntu 9.04 release party katowice
(11 - 5) × 3 = 18
ubuntu 9.04 jaunty jackalope linux unix gnome recenzja
(11 - 8) × 3 = 9

Zgodnie z przeczuciem, wpis nr 2 został oceniony niżej, natomiast nagrodzona została celność tagów we wpisie nr 1.

Punktacja na max

Skoro wiemy już, że Folksr nagradza za ilość przekładającą się na jakość, to ile punktów można osiągnąć maksymalnie? Szybki rachunek w arkuszu kalkulacyjnym pokazuje, że najwyższa liczba punktów możliwych do osiągnięcia to 30:

Liczba trafień	1	2	3	4	5	6	7	8	9	10
Wartość taga	10	9	8	7	6	5	4	3	2	1
Wynik	10	18	24	28	30	30	28	24	18	10

Wartość 30-tu punktów można osiągnąć publikując 5 lub 6 tagów pod warunkiem, że wszystkie z nich są zbieżne z tagami na blogu gospodarza. Całkiem przyzwoite wyniki uzyskuje się również dla 4 lub 7-miu tagów, co może być dość dobrą strategią biorąc pod uwagę trudność utrafienia wszystkich pięciu lub sześciu tagów (twórcy totolotka też potrafią liczyć ;-)

Kalkulator punktacji

Poniżej zamieszczam szybki kalkulator punktacji napisany w JavaScripcie. Oczywiście nie ma sensu brać go na poważnie – w końcu nie o to chodzi w blogowaniu; niech posłuży tylko jako ilustracja zastosowanego w Folkserze algorytmu i miernik jego jakości.

Liczba tagów: × Liczba trafionych: = 21

Folksr: empowered by OSNews.pl

Tue, 26 May 2009 03:28:50 +0200

Dzięki uprzejmości Borysa z OSNews.pl Folksr zaczął indeksować treść tego serwisu (Creative Commons Attribution 2.5pl).

Zasoby te z każdym dniem będą rosły, a ponieważ artykuły na OSNews są znakomicie otagowane ich trafność w podpowiedziach będzie wysoka. Oczywiście jeśli nie chcesz newsów z serwisu w swoim widgecie, po prostu nie dodawaj go do znajomych!

Folksr - już wkrótce

Wed, 13 May 2009 13:04:56 +0200

Folksr nadchodzi, jest tuż za rogiem. Spodziewaj się zaproszenia – tak tak, Ty!