Autor: Kuba Filipowski
Mamy kilka problemów zwiÄ…zanych z ruszeniem wersji private beta Traduko. Wszystko jest systematycznie naprawiane ale potrzebujemy jeszcze trochÄ™ czasu. Jak już pozbÄ™dziemy siÄ™ tych wstÄ™pnych błędów zrobiÄ™ screencast’y obrazujÄ…ce dane funkcjonalnoÅ›ci serwisu.
Nadal szukamy chętnych do beta testów.
Autor: Janu
Przy okazji tworzenia Traduko stwierdziliśmy, że fajnie by było, jakby linki umieszczone w tekstach, w tym permalinki do oryginałów, były pingowane. Z tego co się zorientowaliśmy w polskiej sieci trudno odnaleźć polskie produkty, które zaimplementowany miałyby pingback. Oczywiście, jest sporo blogów korzystających chociażby z Wordpressa, które właśnie dzięki niemu umożliwiają przesyłanie pingów - poprzez skrypt xmlrpc.php. Ja chciałbym poruszyć sedno sprawy - jak w prosty sposób zaimplementować Pingback w Ruby on Rails. Przede wszystkim przyda się lektura specyfikacji tegoż protokołu. Wyczytać w nim możemy, że komunikacja odbywa się na bazie protokołu XML-RPC, a serwer powinien posiadać metodę pingback.ping odpowiedzialną właśnie za pingi. To w niej należy umieścić wszelkie odpowiedzi na pingi, jak również operacje, które chcemy wykonać przy pingu (Wordpress z tego co zauważyłem dodaje komentarze pod odpowiednimi postami). Zajmę się zatem najpierw serwerem, później zaś przejdę do konstrukcji klienta.
Serwer
Zatem za co jest odpowiedzialny serwer? Przede wszystkim odbiera żądania do WebServices, odpowiada na nie i wykonuje odpowiednie operacje, które ma wykonywać ping, w moim przypadku byÅ‚o to tylko dodanie informacji do bazy, że taki ping zaistniaÅ‚. PierwszÄ… rzeczÄ…, którÄ… musimy zrobić jest wygenerowanie nowego WebService’u odpowiedzialnego wÅ‚aÅ›nie za pingowanie, choć możemy w nim również umieÅ›cić dowolne inne WS. Ja nazwaÅ‚em to “przewrotnie” xmlrpc, choć tak naprawdÄ™ do metod można mieć dostÄ™p również przez SOAP (generuje siÄ™ przy tym plik wsdl [tzn. istnieje on tylko wirtualnie] dotyczÄ…cy naszych serwisów). Zatem wywoÅ‚ujemy w naszym projekcie: ruby script/generate web_service Xmlrpc. Tworzy to nam kilka plików, m. in. xmlrpc_controller - odpowiedzialny za obsÅ‚ugÄ™ żądaÅ„, oraz xmlrpc_api (w katalogu apis) - zawierajÄ…cy API naszego WS. W ww. plikach utworzone sÄ… dwie klasy: XmlrpcController dziedziczÄ…cy po ApplicationController oraz XmlrpcApi dziedziczÄ…cy po ActionWebService::API::Base. By ping byÅ‚ dobrze dobrze nazwany (czyli wedle specyfikacji pingback.ping) musimy utworzyć jeszcze przynajmniej dwie klasy: Pingback dziedziczÄ…cÄ… po ActionWebService::Base oraz PingbackApi dziedziczÄ…cÄ… po ActionWebService::API::Base.
Naszemu kontrolerowi (XmlrpcController) aplikujemy trzy metody:
wsdl_service_name 'Xmlrpc'
web_service_dispatching_mode :layered
web_service :pingback, Pingback.new
Pierwsza nadaje nazwÄ™ naszym WS’om, druga przypisuje metodÄ™ dysponowania poszczególnymi WSami, ostatnia tworzy WS o nazwie pingback, za którÄ… odpowiedzialna jest obiekt klasy Pingback. WiÄ™cej słów siÄ™ należy metodzie web_service_dispatching_mode, bo to wÅ‚aÅ›nie ona decyduje o tym, że nasza metoda ostatecznie bÄ™dzie siÄ™ nazywaÅ‚a pingback.ping. Otóż przyjmuje ona trzy możliwe wartoÅ›ci (symbole):
- direct - klasą odpowiedzialną za żądanie jest dany kontroler, a nazwą jest po prostu nazwa metody, którą zaimplementujemy (i podamy w API)
- delegated - klasą odpowiedzialną za żądanie jest zdefiniowana klasa, nazwą jest po prostu nazwa metody zdefiniowanej, natomiast adres do serwisu jest postaci: /api/serwis (gdyby nasz skrypt używać metody delegated to adresem do serwisu byłoby: /api/pingback)
- layered - klasą odpowiedzialną za żądanie jest zdefiniowana klasa, nazwa jest postaci: nazwa_serwisu.metoda (w naszym przypadku
pingback.ping); adresem dostÄ™powym tak jak w przypadku direct’a jest po prostu /api (oczywiÅ›cie należy pamiÄ™tać, że leży ono w kontrolerze Xmlrpc, zatem peÅ‚ny adres to /xmlrpc/api)
Jak można Å‚atwo zauważyć ja użyÅ‚em ostatniej metody, dziÄ™ki której uzyskać wyspecyfikowanÄ… nazwÄ™ pingback.ping. Zajmijmy siÄ™ teraz API naszego WS. Jak można wyczytać w specyfikacji Pingback 1.0 do korzystania z niego wystarczy zaimplementować metodÄ™ pingback.ping. Metoda ta “zjada” sourceURI (strona z której puszczamy pinga) i targetURI (strona do której puszczamy pinga), a nastÄ™pnie wypluwa albo błąd, albo informacjÄ™ o sukcesie (z tego co wyczytaÅ‚em - dowolnÄ…). Definiujemy zatem w API PingbackApi metodÄ™ ping:
api_method :ping, :expects => [{'sourceURI' => :string}, {'targetURI' => :string}], :returns => [:string]
Jak łatwo się domyślić :ping to nazwa naszej metody (która zlayerowana będzie miała pożądaną postać), :expects powinien zwierać tablicę hashów z nazwami zmiennych i ich typami, a :returns wartość zwracaną przez metodę. Można przy tym używać struktur, a nie tylko typów prostych, jednak przy implementacji Pingbacku nie jest to nam potrzebne.
Nasza klasa XmlrpcApi powinna również wywoÅ‚ywać metodÄ™ inflect_names z zaaplikowanym false - można spróbować bez wywoÅ‚ywania, jednak może nie dziaÅ‚ać (inflection tworzy liczby mnogie w różnych miejscach, gdzie jest to logiczne wg twórców RoR ;)). Dalej wystarczy zaimplementować w klasie Pingback odpowiedniÄ… metodÄ™ (ping) i już wÅ‚aÅ›ciwie caÅ‚y WS bÄ™dzie gotowy. MetodÄ™ ping przedstawiÄ™ w nastÄ™pnej notce, tak samo zresztÄ… jak WebService’owy scaffolding i klienta XML-RPC.
Autor: Kuba Filipowski
W ramach spotkaÅ„ Google TechTalks - Jen Fitzpatrick opowiada o rozwoju interface’u produktów firmy. JednÄ… z ciekawszych anegdot z jej referatu jest historyjka o osóbie która byÅ‚a uczestnikiem testów użytecznoÅ›ci wyszukiwarki Google.
Posadzono tÄ… osobÄ™ przed ekranem mointora z zadaniem wyszukania danej informacji i obserwowano jak radzi sobie z wyszukiwaniem. No i ona czekaÅ‚a. Ludzie z Googla pomyÅ›leli, że pewnie zastanawia siÄ™ nad dobrÄ… frazÄ…, którÄ… mogÅ‚aby wpisać w okienko wyszukiwania. Ale to czekanie trwaÅ‚o już dÅ‚uższa chwile i ktoÅ› z Google spytaÅ‚ jÄ… czy wszystko ok? Na to osoba ta odpowiedziaÅ‚a: tak ale czekam, aż to siÄ™ zaÅ‚aduje do koÅ„ca… Po tym wydarzeniu Google postanowilo dodać copyright na dole strony gÅ‚ownej, żeby byÅ‚o jasne, że to wszystko.
Polecam oglądnięcie całości:
Autor: Kuba Filipowski
Tygodniowa sesja webdev dobiega końca. Serwis jest praktycznie cały zaprogramowany i czekamy aż domena wskoczy gdzie ma wskoczyć.

Traduko to nasz pomysł i odpowiedź na problem jakim jest bycie poza językowym mainstreamem. Polski to język wyjątkowo niszowy dlatego posługiwanie się nim poza obrębem naszego kraju jest mało praktyczne. Ten problem ma też drugą stronę - inne niszowe jak i również mainstreamowe języki nie zawsze są dla nas zrozumiałe. Na pewno nie dla wszystkich z nas.
Traduko to serwis społeczności tłumaczy. Cel jest prosty - zgromadzić jak najwięcej przekładów tekstów z blogów i serwisów informacyjnych nie-polsko-języcznych, kóre publikują materiały w oparciu o wolne licencje. Chodzi o to, żeby pomagać sobie wzajemnie w zdobywaniu nowej wiedzy i poszerzać horyzonty.
Nawet jeśli sporo ludzi radzi sobie z angielskim to już taki hiszpański może być problemem - dlaczego nie podzielić się więc tą cenną wiedzą zawartą na tysiącach niezrozumiałych dla innych blogów?
Język to ogromna bariera komunikacyjna. Prowadzenie bloga całkowicie w obcym języku jest trudnym wyczynem - sami się o tym przekonaliśmy. Jednak czasem trzeba podzielić się daną informacją lub historią z całym światem. Trzeba stworzyć inną wersję językową notki - a to rodzi problemy. Uruchamiając Traduko chcemy je zredukować - Traduko będzie oferowało opcję łatwej podmiany wersji językowych wpisów. Może, w jakimś małym stopniu, przyczynimy się do globalnego wypromowania kilku naszych zdolnych rodaków? Byłoby cool.
Wkrótce zaczynamy beta testy. Będziemy Was informować jak sprawy się mają. Jeśli macie ochotę trochę nam pomóc i podjąć się testowania serwisu - zgłaszajcie się w komentarzach do tego wpisu. Piszcie też co myślicie o tym pomyśle.