yashke.com

Postanowiliśmy zmienić widget - poprzedni uzależniał prędkość ładowania strony od szybkości i dostępności naszego serwera. To nie było dobre i mogło Was zniechęcać do pokazywania ofert.

Nowy jest fajniejszy - nie ładuje danych od razu tam gdzie mają pojawić się oferty czyli nie “zatyka” Wam ładowania strony. Podzieliliśmy go na części. Pierwsza to div w którym pojawią się oferty.

<div id="ygigs-offers"><a href="http://yashke.com/praca/">zobacz oferty pracy</a></div>

Druga część to po prostu JavaScript zaciągający dane z JSONa a potem drugi który te dane parsuje - ten fragmencik kodu najlepiej wkleic zaraz przed </body>

<script type="text/javascript" src="http://widgets.yashke.com/ygigs/ygigs.js"></script>

Ograniczyliśmy też ilość wyświetlanych ofert do 10, od dziś wyświetlamy je też w losowej kolejności.

Mamy nadzieję, że to zachęci Was do wstawienia widgetu na Waszego bloga lub stronę.

Obiecałem tutoriala o instalowaniu plugina OpenID do Wordpressa, więc chcąc być słownym napisałem ten właśnie tekst. Początkowo miał on zawierać jakieś screenshoty, ale ostatecznie z uwagi na prostotę procesu uznałem, że wystarczy opis słowny.
(more…)

Niedawno zacząłem tworzyć stronę mojego duszpasterstwa. Stwierdziłem, że nie opłaca mi się programować czegoś zupełnie nowego, bo przecież ma być to strona w miarę prosta, a jedynymi ciekawostkami będzie galeria, księga gości i kalendarz wydarzeń - z tych właśnie powodów wybrałem mechanizm Wordpressa (alternatywą było użycie engine’u spiffy.content, bądź kanapy.org). Znalazłem odpowiednie narzędzie do tworzenia galerii, księgę gości chwilowo oparłem o zwykłe komentarze (co jest błędem, gdyż wygląda przez to bardzo “forumowo”). Nie mogłem jednak wygooglać żadnego pluginu, który tworzyłby kalendarz wydarzeń. Zapadła więc szybka decyzja - zrobię własny.
(more…)

W notce Pingback w kilku słowach (cz. 1) zacząłem opisywać tworzenie serwera Pingback w Ruby on Rails. W tej chciałbym dokończyć opis tworzenia serwera, natomiast w następnej (może następnych?) przedstawię, jak stworzyć klienta i się nim posługiwać. Kontynuując tekst sprzed dwóch tygodni zakładam, że czytelnik pamięta o czym pisałem, szczególnie jeżeli chodzi o sam protokół Pingback 1.0. Zatem, do dzieła!

Pozostało nam właściwie napisanie tylko metody ping, która będzie wywołana przy pingowaniu. Zgodnie ze specyfikacją pobiera ona dwa argumenty: sourceURI i targetURI, tj. permalink do tekstu, w którym odwołujemy się do drugiego tekstu, oraz permalink do tekstu do którego się odwołujemy. Nasza metoda ping będzie metodą klasy Pingback, o której wspominałem już wcześniej. Zatem w fazie początkowej nasza klasa będzie wyglądała tak:

class Pingback < ActionWebService::Base
  web_service_api PingbackApi

  def ping(source, target)
  end
end

Jak łatwo się domyślić web_service_api przypisuje naszemu serwisowi API zawarte akurat w klasie PingbackApi. Warto zauważyć, że metoda ping nie wygląda jakoś szczególnie - właściwie zasady jej definiowania są takie same, jak zwykłych metod w Ruby. Zatem ostatnio użyta R-wartość jest wynikiem działania metody, chyba że rzuci ona wyjątkiem. No właśnie - wyjątki typu XMLRPC::FaultException będą po prostu odpowiadały za zwrócenie poprzez XML-RPC informacji o błędzie. Jak można wyczytać w dokumentacji konstruktor tego wyjątku pobiera dwie wartości - numer błędu oraz komunikat przyjazny człowiekowi. Dzięki takiemu podejściu do XML-RPC praca znacznie się upraszcza - nie martwimy się o to, jak zakodować zwracane wartości, bo martwi się tym warstwa stojąca wyżej.

Teraz wystarczy do naszej metody dopisać odpowiednie operacje, które będą sprawdzały poprawność podanych danych i w odpowiednich miejscach rzucą wyjątkami bądź na końcu zwrócą jakąś wartość, najlepiej tekst, że wszystko się udało - najlepiej po angielsku. Listę błędów znaleźć można w specyfikacji protokołu Pingback 1.0, a można z niej również wywnioskować, co należy sprawdzić podczas pingowania. A sprawdzić należy - czy podane sourceURI rzeczywiście istnieje i zawiera adres do targetURI, czy targetURI istnieje itp. I to właściwie koniec pracy nad serwerem naszego serwisu - można łatwo sprawdzić, czy rzeczywiście serwer działa poprzez scaffolding - wystarczy wywołać w klasie XmlrpcController metodę web_service_Scaffold podając do zjedzenia nazwę akcji (w formie symbolu), która odpowiadać będzie za scaffolding. Przykład:

web_service_scaffold :invoke

Jeśli jesteś osobą, która wierzy, że wszyscy spiskują i nie należy wierzyć twórcom RoR, możesz również sprawdzić działanie serwisu pisząc odpowiednią aplikację - ja tak zrobiłem :).

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):

1. direct - klasą odpowiedzialną za żądanie jest dany kontroler, a nazwą jest po prostu nazwa metody, którą zaimplementujemy (i podamy w API)
2. 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)
3. 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.