Krzysztof Kędziorski - Notatnik “programisty”

W środę kurier przyniósł mi kolejnego 22 calowego Benq G2220HD. Zdecydowałem się na zakup tego samego modelu co poprzednio z 2 powodów. Po pierwsze jestem z niego bardzo zadowolony, a wiadomo że jak coś się dobrze sprawuje to nie ma potrzeby eksperymentować z innymi. Po drugie ze względów estetycznych - jednak lepiej wygadają 2 identyczne monitory niż każdy inny. Teraz mam do dyspozycji rozdzielczość 3840×1080px i myślę,  że już na tym pozostanę (w sensie nie kupie trzeciego jak planowałem na początku:P)

Od początku tygodnia mam przyjemność pracować z wtyczką GWTDesigner i muszę przyznać, że  sporo przyspiesza tworzenie aplikacji w GWT - wiadomo wszystkiego nie da się wyklikać ale do prostszych formatek dobrze mieć taką możliwość. Przy okazji ogarniania nowej wtyczki zacząłem też korzystać z biblioteki smartGWT (GWTDesigner ma również do niej wsparcie) - bardzo fajnie uzupełnia podstawowe widgety z GWT.

Wczorajszy dzień spędziłem w Warszawie na konferencji Javarsovia 2010. Tak jak w poprzednim roku do Wawy jechałem pociągiem co wymagało wczesnej pobudki i dało się we znaki na końcowych prelekcjach. W tym roku zebrałem nieco więcej kolegów niż w poprzednim. Ogólnie nasza grupa liczyła 5 osób + Majki odnaleziony w trakcje konferencji :) Ustawka miała miejsce na dworcu - ja, Robak i Łukasz jechaliśmy jednym pociągiem z Torunia , Bartek jechał z Poznania, a Michał jeszcze innym pociągiem z Siedlc. Wsiedliśmy w autobus i po około 25minutach byliśmy już na miejscu. Najpierw trzeba było wystać swoje w kolejce po materiały. Gdy już mieliśmy materiały poszliśmy do sali Double (świetny pomysł z tymi nazwami), gdzie zaczynało się właśnie powitanie uczestników, przypomnienie poprzednich edycji itp. Trzeba przyznać, że stawiła się masa koderów. Jestem pewny, że Javarsovia2010 przekroczy liczbę 500 uczestników. Sama organizacja konferencji tak jak w tamtym roku na najwyższym poziomie. Sale były na tyle spore, że bez większych problemów każdy miał miejsce. Firma cateringowa również spisała się świetnie - obiad był bardzo smaczny, od rana mieliśmy bułeczki, ciastka,soki no i oczywiście kawę :) Ok może teraz napisze coś o prezentacjach w których uczestniczyłem. O to moja ścieżka:

• Jak zapobiegać biodegradacji kodu. Jakub Nabrdalik
• Jak można zarobić na uczciwości, przejrzystości i szacunku dla klienta - kontrakty agile w praktyce. Wojciech Seliga
• Refaktoryzacja kodu testowego. Piotr Jagielski
• Software Craftsmanship - Język wzorców językiem profesjonalistów. Sławomir Sobótka
• “Clean Tests” by Unkle Paul, czyli jak pisać testy, żeby dobrze Ci służyły. Paweł Lipiński

Jak zapobiegać biodegradacji kodu. - bardzo fajna prezentacja. Tu po raz pierwszy padło, że piszemy kod minimum 10 razy rzadziej niż go czytamy. Jakub pokazywał co zrobić żeby jakość kodu nie spadała wraz z upływem czasu. Co wyniosłem z prezentacji ? To że jak czytamy kod w którym musimy dokonać jakiś modyfikacji, lub też z niego skorzystać tworząc nowy moduł / funkcjonalność powinniśmy spojrzeć na niego również pod kątem refaktoryzacji - czasem wystarczy Extract Method, by kod stał się już sporo czytelniejszy.

Jak można zarobić na uczciwości, przejrzystości i szacunku dla klienta - kontrakty agile w praktyce. - kolejna ciekawa prezentacja. Wojtek opowiadał w zasadzie o tym jak prowadzone są kontrakty w jego firmie. Kontrakty agile polegają na zaufaniu klienta do firmy która ma zakodować dany soft. Są bardzo elastyczne - klient w każdym momencie może zmienić zdanie co do funkcjonalności, w każdym momencie może zrezygnować z dalszej współpracy. Co zyskuje zespół ? Mniejszy stres, brak problemu niedoszacowania ilości osobo godzin potrzebnych na dostarczenie produktu. Kiedy agile nie przejdzie ? W inwestycjach unijnych gdzie potrzebne są przetargi i z góry ustalona funkcjonalność. Ciężko tez będzie z dużymi korporacjami ze względu na ich wewnętrzną biurokracje.

Refaktoryzacja kodu testowego. - Testy powinny być użyteczne, aktualne i czytelne - wymagają, więc refaktoryzacji. Piotr zaprezentował kilka przykładów testów i “na żywo” je reaktoryzował. Z dość nieczytelnych stawały się przejrzyste. Zaprezentował również ciekawy sposób tworzenia obiektów za pomocą buildera. Bardzo ciekawa prezentacja.

Software Craftsmanship - Język wzorców językiem profesjonalistów. - prezentacja dotycząca wzorców projektowych. Sławek opowiedział czym jest profesja, pokazał przykłady łatwo rozszerzalnych klas prezentując kilka wzorców.

“Clean Tests” by Unkle Paul, czyli jak pisać testy, żeby dobrze Ci służyły. - ostatnia prezentacja na której byłem. Fajnie prowadzona :) Sporo wiedzy o testach. Co jest okej a co nie do końca - Paweł sporo korzystał z książki Clean Code gdzie również dało się znaleźć trochę informacji o wysokiej jakości testach.

Dlaczego nie byliśmy na ostatnim wykładzie ? Chcieliśmy zdążyć na wcześniejszy pociąg, niestety mimo zerwania się z wykładu pociąg nam uciekł :( Do następnego mieliśmy jakieś 2,5h więc poszliśmy na piwo (10zł za półlitrowego Żywca :O), potem na kebab (słaby był :(). Na sam koniec oczywiście pociąg był opóźniony +-25 minut. W pociągu przy piwku dyskutowaliśmy w zasadzie cały czas a to o tematach z konferencji a to innych programistycznych tematach. To tyle jeśli chodzi o moją relacje. Podsumowując Javarsovia2010 wyszła znakomicie - brawa dla organizatorów - na 100% spotykamy się w przyszłym roku.

Jakiś czas temu zobaczyłem wpis odnośnie praktyk organizowanych w Code-Hause i postanowiłem spróbować swoich sił. Namówiłem jeszcze kumpla żeby się również zgłosił. Kilka dni po wysłaniu CV otrzymałem test do rozwiązania. Test sprawdzał znajomość Javy dość szczegółowo plus ogólnie Hibernate, Spring i Web Services. Wypadłem chyba całkiem nieźle mimo nieznajomości Spring’a ani Web Services. Mój wynik to 27.5 / 32pkt. Kilka dni po teście zostałem zaproszony na rozmowę kwalifikacyjną, którą zespół z Code-House przeprowadził w bardzo fajny sposób. Luźna rozmowa, trochę pytań z CV, małe wprowadzenie do tego czym będziemy się zajmować i po 20 minutach było po. Podczas praktyk ja i mój kolega będziemy zajmować się projektem OSGi.

Co zadecydowało o tym, że postanowiłem wziąć udział w praktykach? Po pierwsze praktyki są zdalne. Nie trzeba tracić czasu na dojazdy itp. Wzięcie udziału w projekcie Open-Source. Zawsze chciałem - nigdy nie miałem pomysłu na projekt ani dość motywacji. Liczę że sporo się nauczę. Maven, Spring, OSGi i jeszcze kilka innych technologii muszę już teraz ogarniać :) i o to właśnie chodzi :) Kolejne na co liczę to udział w dobrze prowadzonym projekcie. Co przez to rozumiem? Testy, Continues Integration może jakieś wzorce projektowe - chętnie zdobędę trochę doświadczenia w tych rejonach.  Nie można oczywiście zapomnieć o odpowiednim wpisie w CV :) Wg. mnie warto :) Mam nadzieję, że uda mi się czasowo jakoś to wszystko pogodzić :)

Jakieś 2 tygodnie temu (wiem wiem ale nie miałem wcześniej czasu :( ) na seminarium mgr miałem okazję przeprowadzić prezentację na temat podstaw pozycjonowania stron internetowych.  Prezentacja miała na celu wprowadzenie do tematu, a nie dogłębne omówienie, tak więc proszę o wyrozumiałość :) Wydaje mi się, że każdy programista tworzący jakieś strony, serwisy www powinien zapoznać się choć pobieżnie z tematem. Strony tworzone z uwzględnieniem tych podstaw będą znacznie lepiej traktowane w google.pl i innych wyszukiwarkach.

Dziś całkiem inny wpis :) Nic coby się tyczyło programowania :) Opiszę jak w kliku krokach postawić sobie w domku serwer Apache z zainstalowanym PHP oraz MySql. Sprawa jest naprawdę banalna :) Do rzeczy - instalacja w 3 krokach :)

1. Najpierw instalujemy apache.

yum install httpd

2. Gdy już mamy zainstalowanego apache’a instalujemy php’a

yum install php

3. Jak pewnie łatwo się domyśleć teraz serwer MySql’a

yum install mysql-server mysql

No i tyle. Mamy postawiony serwerek. Wypada go oczywiście uruchomić.

service httpd start

service mysqld start

Teraz już możemy się cieszyć że w kilkanaście sekund postawiliśmy serwer www.

Pozostało wrzucenie strony startowej do

/var/www/html/

Jak już pisałem w poprzednim poście jestem w trakcie czytania książki Czysty Kod. Podręcznik dobrego programisty. Pomyślałem sobie, że w trakcie czytania będę starał się wypisywać zawarte tam rady. Efektem tychże notatek będzie właśnie ten wpis. Mam nadzieję, że komuś taki spis dobrych zasad w pigułce się przyda. A ja będę miał go w jednym miejscu :)

Zdecydowałem się na wypisywanie porad zgodnie z rozdziałami książki.

1. Znaczące nazwy:

• nazwy przedstawiające intencję
• unikanie dezinformacji
• wymawialne nazwy
• nazwy łatwe do wyszukania

2. Funkcje:

• możliwie jak najkrótsze (max 20 wierszy)
• najlepiej bez lub jedno argumentowe
• pojedyncza odpowiedzialność
• jeden poziom abstrakcji
• bloki try{} catch{} w osobnej funkcji

3. Komentarze:

• jak najmniej (samo komentujący się kod)
• dozwolone komentarze:
  • komentarz z rodzajem licencji
  • TODO
  • komentarze ostrzegające
• nie komentujmy na siłę
• nie zostawiajmy za komentowanych fragmentów kodu

4. Formatowanie:

• małe pliki (klasy) są lepsze niż duże
• u góry klas najogólniejsze metody poniżej coraz bardziej szczegółowe
• pionowe odstępy między segmentami kodu
• funkcja wywoływana zaraz pod funkcją wywołującą
• wiersze maksymalnie 120 znakowe
• spacje wokół operatorów
• wcięcia poziome oddzielające bloki kodu
• spójne formatowanie w całym zespole

5. Obiekty i struktury danych:

• NIE dodawać na ślepo setterów i getterów
• przestrzegajmy prawa Demeter
• unikanie “wraków pociągów”, czyli kodu postaci: a.getB().getC().getD().getZ().doSth();
• unikać hybryd (trochę obiekt, trochę struktura danych)

6. Obsługa błędów:

• wyjątki zamiast kodów powrotu
• NIE zwracamy null
• NIE przekazujemy null
• tworzenie komunikatów błędów z informacją o typie awarii i co miało się wykonać oraz przesłanie ich w wyjątku

7. Granice:

• separacja obcego kodu od naszego
• testy “uczące” obcego kodu
• wzorzec Adapter

8. Testy jednostkowe:

• kod testów jest tak samo ważny jak kod produkcyjny
• czytelność testów
• w testach nie jest tak istotna wydajność
• jedna asercja na test - niekoniecznie
• jedna koncepcja na test
• testy powinny spełniać zasady F.I.R.S.T.
  • Fast - szybkie
  • Independent - niezależne
  • Repeatable - powtarzalne
  • Self-Validating - samo kontrolujące się
  • Timely - o czasie

9. Klasy:

• organizacja klas (od góry):
  • publiczne stałe statyczne
  • prywatne zmienne statyczne
  • prywatne zmienne instancyjne
  • publiczne metody
  • prywatne metody
• klasy powinny być małe
• pojedyncza odpowiedzialność (SRP)
• niewiele zmiennych instancyjnych
• zachowanie dużej spójności

Pewnie słyszeliście, że Sun prowadził takie cudo jak SAI. Sun oferował członkom programu (studentom, wykładowcom) sporą zniżkę na egzaminy certyfikacyjne. I tak egzamin na SCJP zamiast kosztować 750zł, kosztował 40$ (120zł). Niestety Sun został przejęty przez Oracle’a, który jak widać nie do końca zgadza się z sposobem zniżek. W tak korzystnej cenie voucher na egzamin można było zamówić tylko do 31 marca 2010, ale tylko jeśli było się wcześniej zarejestrowanym w SAI. Teraz Oracle owszem daje zniżkę członkom swojej wersji SAI, ale zniżka nie jest już taka super. Dostajemy o 40% tańszy voucher, czyli zamiast płacić 750zł zapłacimy około 450zł. Widać sporą różnicę względem 120zł za czasów starego dobrego Sun’a :(

Całe szczęście w porę się ogarnąłem i 2 dni przed deathline’em zamówiłem sobie taniutki voucher’ek. Aby go otrzymać należało wpłacić kaskę (prawie 120zł) i wysłać mailem/faxem skan legitymacji studenckiej. No i tak uczyniłem. W odpowiedzi dostałem takiego o to maila:

Thank you for your Sun Academic Initiative exam voucher order.

We are currently experiencing extremely high order volume, which has affected our order processing time.  Orders are being processed in the order received and will be processed as quickly as possible.  Your order may require several weeks for fulfillment.

We will contact you if additional information is required.  Please avoid sending multiple emails as the additional email volume will cause further processing delays.

We appreciate your patience.

Best regards,

SAI Voucher Team

Nie dość że człowiek ledwo się załapał to jeszcze mnie tu dobijają “several weeks” :( No ale miejmy nadzieję, że pójdzie to w miarę sprawnie. Jak już będę pewny voucher’a to zabieram się za naukę do SCJP.

A tym czasem zmykam do lektury książki Czysty kod. Podręcznik dobrego programisty, którą udało mi się wyhaczyć w promocji Helion’a kilka dni przed świętami. Jak na razie przeczytałem coś około 50str i czyta się ją całkiem spoko. Może po przeczytaniu pokuszę się o małą recenzję.

EDIT:

Zapomniałem dodać, że mam jeszcze 2 vouchery na egzaminy Microsoftu z serii 70—. Jako, że uczęszczałem na koło naukowe .NET mogłem sobie wymienić zebrane w ten sposób punkty na książki lub vouchery. Mam w planach zdać jakiś .NET’owy egzamin jeszcze w tym roku. Może się uda, w końcu mam aż 2 podejścia :)

Pisałem niedawno małą aplikację webową na zlecenie. Aplikacja była oczywiście napisana w GWT :) Z rzeczy, których wcześniej nie pisałem aplikacja musiała korzystać z Hibernate i uploadwać pliki na serwer. No i z czym miałem najwięcej problemów ? Właśnie z uploadem :( Hibernate okazał się bardzo fajnym narzędziem (ale o tym pewnie osobny wpis kiedyś będzie). Ok więc najpierw jak zrealizować fileupload w GWT, a potem co ja spartoliłem :)

Ok wiec najpierw przyjrzyjmy się części po stronie klienta. GWT dostarcza nam komponent FileUpload, który zajmie się czarą robotą przy uploadzie. Co jest istotne ? Żeby dało się coś przesłać na serwer musimy umieścić to w formularzu, (klasa FormPanel). Musimy nadać formularzowi odpowiednią akcję tj. podać url-pattern do servletu, który zajmie się odebraniem pliku i zapisaniem go na serwerze. Oczywiście do przesyłania pliku użyjemy metody POST :)

final FileUpload plik = new FileUpload();

final FormPanel form = new FormPanel();
form.setAction("fileupload");
form.setEncoding(FormPanel.ENCODING_MULTIPART);
form.setMethod(FormPanel.METHOD_POST);

form.setWidget(plik);

//Gdy chcemy wysłać formularz z plikiem(np po kliknięciu na przycisk) wywołujemy:

form.submit();

Jaki był mój błąd skoro cały ten upload jest taki prosty ? Najpierw zrobiłem sobie GUI, nie było FormPanelu tylko w głównym panelu miałem dodany FileUpload. Podczas zmian zapomniałem usunąć this.add(plik), i w ten sposób FileUpload zamiast znajdować się w formularzu znajdował się w głównym panelu. Wyglądało tak jak trzeba - ale nie działało :) Kilka godzin myślałem co jest nie tak.

Ok. Jak wygląda servlet odbierający nasz plik? Skoro przesyłamy plik o trzeba w nim zaimplementować swoją metodę doPost(). A servlet wygląda tak:

public class FileUploadServlet extends HttpServlet {
private static final long serialVersionUID = 3404817164861510193L;

@SuppressWarnings("unchecked")
protected void doPost(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {

if (ServletFileUpload.isMultipartContent(req)) {

FileItemFactory factory = new DiskFileItemFactory();

ServletFileUpload upload = new ServletFileUpload(factory);

try {
List<FileItem> items = upload.parseRequest(req);
for (FileItem item : items) {
if (item.isFormField()) continue;
String fileName = item.getName();
if (fileName != null) {
fileName = FilenameUtils. getName(fileName);
}

File uploadedFile = new File(getServletContext().getRealPath(getServletContext().getContextPath()), fileName);
if (uploadedFile.createNewFile()) {
item.write(uploadedFile);
resp.setStatus(HttpServletResponse.SC_CREATED);
resp.getWriter().print("The file was created successfully.");
resp.flushBuffer();
} else
throw new IOException("The file already exists in repository.");
}
} catch (Exception e) {
resp.sendError(HttpServletResponse.SC_INTERNAL_SERVER_ERROR,
"An error occurred while creating the file : " + e.getMessage());
e.printStackTrace();
}

} else {
resp.sendError(HttpServletResponse.SC_UNSUPPORTED_MEDIA_TYPE,
"Request contents type is not supported by the servlet.");
}
}

@Override
protected void doGet(HttpServletRequest req, HttpServletResponse resp)
throws ServletException, IOException {
super.doGet(req, resp);
}

}

W tym semestrze na uczelni mamy przedmiot Wstęp do kryptografii mający nam przedstawić podstawy szyfrowania danych i muszę przyznać ,że jest nawet ciekawie. Mamy w ciągu semestru zrobić klika małych “projektów”. Na pierwszy ogień poszły historyczne szyfry. I pierwszym zadaniem było złamanie szyfru Vigenere’a metodą kryptoanalizy. Samo szyfrowanie jest bardzo proste, każdej literze alfabetu przypisujemy liczbę odpowiednio a -> 0, b -> 1, …. , z -> 25 . Zapisujemy tekst który chcemy zaszyfrować w postaci cyfr. Potem to samo robimy z kluczem, który wykorzystamy do szyfrowania. Samo szyfrowanie polega na dodaniu do siebie wartości danej pozycji w tekście i danej pozycji w kluczu (modulo 25). Jako, że klucz jest krótszy od tekstu to gdy się “skończy” zapisujemy go od początku i tak do momentu pokrycia całej długości tekstu. Gdy już pododajemy do siebie odpowiednie pozycje to zamieniamy liczby na litery.

Jak łamiemy szyfr?

Na początek musimy odgadnąć długość klucza użytego do zaszyfrowania tekstu. Na zajęciach przedstawiono nam 2 metody: Metodę Kasiskiego oraz metodę Friedmana.

Metoda Kasiskiego polega na wyszukiwaniu powtarzających się ciągów w tekście (więcej niż 3 znakowych). Analizujemy odległości miedzy występowaniami tych samych ciągów. Kasiski zauważył, że jeśli zbitki tych samych znaków powtarzały się np co 35, 70, 95, 15 ,23 to najprawdopodobniejszą długością klucza będzie 5 większość liczb dzieli się przez 5 (23 przyjmujemy jako skrajną wartość , ja w swojej implementacji brałem pod uwagę 60% “najlepszych” wyników tylko). Ogólniej mówiąc zbitki liter powtarzają się w pewnych odstępach będących wielokrotnością długości klucza, analizując wystąpienia zbitek możemy wywnioskować długość klucza.

Metoda Friedmana polega natomiast na analizowaniu ilości koincydencji. Jak to wygląda w praktyce? Zapisujemy “pod sobą” 2 razy szyfrogram jeden normalnie a drugi przesuwamy o ileś znaków. Następnie sprawdzamy ile razy wystąpi koincydencja tj. ile razy na miejscu i pojawia się w obu tekstach taka sama litera. Liczba koincydencji będzie największa przy przesunięciach o wielokrotność długości klucza. Jeśli analizujemy szyfrogram ręcznie to długość klucza zobaczymy od razu rysując sobie wykres koincydencji. W programie trzeba jakoś rozkminić, które przesunięcie jest tym “pierwszym odpowiednim”. Ja zdecydowałem się wziąć pierwszy element który będzie większy niż średnia + odchylenie standardowe wszystkich koincydencji. Poniżej kod realizujący te metodę.

private static int znajdzDlugoscKluczaFriedman(String szyfrogram) {
int[] koincydencje = new int[szyfrogram.length()];
for(int i=1;i<szyfrogram.length();i++)
for (int j=0; j < szyfrogram.length(); j++)
if(szyfrogram.charAt(j) == szyfrogram.charAt((i+j)%szyfrogram.length()))
koincydencje[i]++;
int sred=0;
int odchyl=0;
for (int j=0; j < szyfrogram.length(); j++)
sred+=koincydencje[j];
sred/=szyfrogram.length();
for (int j=0; j < szyfrogram.length(); j++)
odchyl+=Math.abs(koincydencje[j]-sred);
odchyl/=szyfrogram.length();

for (int j=0; j < szyfrogram.length(); j++)
if(koincydencje[j] > sred + odchyl) return j;
return 0;
}

Gdy znamy już długość klucza możemy przystąpić do jego łamania. Jak to zrobić?
Analizujemy częstość występowania konkretnych liter w tekście i porównujemy je z częstością występowania znaków w j. polskim. Np litera ‘a’ występuje w j. polskim z częstotliwością około 10%, więc jeśli w szyfrogramie znajdzie się litera występująca z podobną częstością to z dużym prawdopodobieństwem jest to zaszyfrowane ‘a’.
Wówczas od wartości liczbowej tej litery odejmujemy wartość liczbową naszego ‘a’ i w ten sposób otrzymujemy wart. liczbową danej litery klucza.
Oczywiście to bardzo mocne uproszczenie. W praktyce zdarza się że literka ‘a’ występuje nieco rzadziej niż np. literka ‘e’ a wg tabeli częstości powinna występować najczęściej.
Ja do odgadnięcia danej litery klucza zastosowałem znów odchylenie standardowe. Sprawdzając po kolei każdą literę jako daną pozycje klucza wybierałem tę, dla której suma wartości bezwzględnych odchyleń standardowych, między częstością w tekście a częstością w j. polskim była najmniejsza.

public static String odgadnijKlucz(String szyfrogram, int[][] czestosci, int dlKlucza){
String tmp = "";
for(int i=0;i<dlKlucza;i++){
int indexZminOdchyleniami=0;
int minOdch = Integer.MAX_VALUE;
for(int j=0;j<26;j++){
int sumaOdchylen = 0;
for(int c='a';c<='z';c++){
sumaOdchylen += Math.abs(czestosci[i][(c-'a'+j)%26] - czestosciPL[c-'a']);
}
if(sumaOdchylen < minOdch){
indexZminOdchyleniami = j;
minOdch = sumaOdchylen;
}
}
tmp += (char)('a'+indexZminOdchyleniami);
}
return tmp;
}

No i to byłoby na tyle. Mnie zadanko zaciekawiło może i kogoś jeszcze zaciekawi :)

Od dziś aby dodać komentarz do wpisu musicie wpisać tekst z obrazka. Wiem, że to okropnie denerwujące, ale dostaję tygodniowo około 20 maili z prośbą o sprawdzenie komentarza ze SPAMem. Wybrałem silnik reCAPTCHA bo jako bonusik pomagamy (a w zasadzie Wy pomagacie) w digitalizacji książek (szkoda ze głównie po angielsku :( ). Jak wiemy systemy OCR nie radzą sobie za dobrze i często trzeba je poprawiać. No i mądrzy ludzie wpadli na to aby zastosować Human Computing, czyli wykorzystać naszą “moc obliczeniową”.

Gdy chcemy dodać komentarz na blogu musimy przepisać poprawnie dwa* wyrazy. W ten sposób mamy zabezpieczenie przed automatycznym spamem. A przy okazji do bazy reCAPTCHA “tłumaczymy’ jeden z wyrazów. System podając nam 2 wyrazy do odczytu tak na prawdę zna “tekstowo” tylko jeden wyraz i ten MUSIMY wpisać poprawnie drugi wyraz, jest tym słowem na którym wywalił się OCR :)  System zapisuje sobie naszą propozycję i jeśli potwierdzi ją kilka osób to zapisuję ja jako znaną i kawałek jakiejś książki zostaje przetłumaczony na tekst, dzięki naszej pomocy.