//DEVGURU

Podczas pisania iBlipa natrafiłem na dość ciekawy problem: Gdy chciałem użyć funkcji eval() do parsowania obiektu JSON który otrzymałem z API otrzymywałem Parse Error. Wyjaśnienie tego problemu znalazłem, ale zajęło mi to dość dużo czasu, zatem warto się nim podzielić .

Jak pewnie gdzieś już pisałem od dawna korzystamy podczas developmentu z SVN oraz z Capistrano. Niedawno nasi zachodni sąsiedzi z firmy peritor stworzyli narzędzie webistrano, które po wprowadzeniu drobnych poprawek (prawa dostępu i style) wdrożyliśmy u siebie.

Dlaczego warto skorzystać z webistrano?

1. Prosta instalacja i względnie prosta konfiguracja.
2. Bezpieczeństwo (nie ma konieczności dawania dostępu do shella)
3. Prosta obsługa – deployment polega na kliknięciu w przycisk deploy.
4. Łatwe cofanie problematycznych deployów (deploy:rollback)
5. Przejrzysta historia deployów wraz z informacją kto go wykonał (wiadomo na kogo zwalić winę jak coś nie działa :P)
6. Obsługa Ruby on Rails (mongrel, passenger) jak i PHP
7. Automatyczne nadawanie praw odpowiednim katalogo.
8. Wiele innych możliwości (jeśli umiesz pisać skrypty do rake’a)

PS: Jak ktoś ma propozycję na polski odpowiednik słowa deploy/deployment to proszę o komentarz :-)

Jak to mówią – lepiej późno niż później…

Poniżej prezentacja jaką miałem przyjemność wygłosić podczas RuPy 2008:

Kolejna prezentacja z cyklu FridayTalks – tym razem na temat uniwersalnego API do tworzenia widgetów od Netvibes.

| View | Upload your own

Jaki wniosek nasuwa się po obejrzeniu prezentacji? Z pewnością entuzjazm jaki towarzyszył ukazaniu się pierwszej wersji API był uzasadniony. Zbudowanie środowiska uniwersalnego, które będzie obsługiwane przez różne urządzenia i platformy jest czymś bardzo cennym. Uwagi można jednak mieć już do samej zasady działania API.

Widgety napisane w Netvibes są zależne od działania serwerów Netvibes. Najpierw serwer parsuje kod i dopasowuje do wybranej platformy, a następnie wszystkie zapytania ajaxowe tworzone zgodnie ze specyfikacją przechodzą za każdym razem przez Netvibes. Wady takie rozwiązania mogą być wielorakie:

- gdy serwer Netvibes pada – co miało miejsce podczas ostatniej migracji na nową wersję – nasz widget też zamiera

- zapytania poprzez Ajax trwają dłużej, gdyż muszą być jeszcze obsłużone przez momentami bardzo obciążony serwer Netvibes

- przeglądarki internetowe blokują często zapytania do serwera Netvibes – gdyż naruszają one zabezpieczenia (odwołując się do domeny innej niż macierzysta)

Odrębne problemy sprawia to, iż API Netvibes ciągle nie zostało jeszcze ukończone. W dokumentacji czytamy o brakach w obsłudze preferencji, itp… Sprawia to problem gdy chcemy stworzyć ciut bardziej skomplikowany widget i musimy rezygnować z pewnych rozwiązań z powodu braków w API.

Kolejny zarzut jaki się pojawia to niedopasowanie widgetów do poszczególnych platform, np. Windows Vista nasz gadżet będzie miał nadal szerokość taką jak inne gadżety w Netvibes i na pasku gadżetów się nie zmieści. Za to w Dashboard w Mac OS X musimy najpierw ściągnąć widget pośredniczący, do którego dopiero wklejamy URL właściwego widgeta…

Najprościej byłoby nie korzystać z API Netvibes i zadowolić się np. Google Gadgets – gdyż jak pokazują statystyki popularnosć Netvibes jest znikoma. Co zrobić jeżeli jednak musimy korzystać z Netvibes?

Rozwiązaniem jest z pewnością zastosowanie <iframe> – możemy stworzyć prostą stronkę, którą będzie parsował serwer Netvibes – a w niej iframe z właściwym widgetem, do którego już Netvibes zaglądać nie będzie (możemy zatem użyć np. jQuery). Takie rozwiązanie pozwala nam też zrezygnować z Netvibesowych zapytań AJAX – możemy zatem stworzyć własny plik proxy w PHP przez którego będą przechodziły wszystkie zapytania. Pozwoli to nam “oszukać” przeglądarkę w kwestii zabezpieczeń XSS i przyspieszyć uzyskiwanie odpowiedzi.

Asocjacje typu has and belongs to many w Cake PHP potrafią czasem nieźle napsuć krwi. Dodawanie i usuwanie powiązań rekordów jest dość pracochłonne, a co gorsze może być źródłem błędów, jeśli robić to za każdym razem ręcznie. Dziś wpadłem na rozwiązanie, które znacząco ułatwia życie w takich sytuacjach. Chodzi o zamieszczony już jakiś czas temu w bakery behavior ExtendAssociations.

Dzięki zastosowaniu tego rozwiązania możliwe są konstrukcje:

$this->Post->habtmAdd('Tag', $postId, $tagId);
...
$this->Post->habtmDelete('Tag', $postId, $tagId);
...
$this->Post->habtmDeleteAll('Tag', $postId);


Więcej szczegółów w podlinkowanym wyżej artykule. Polecam również przeczytanie zamieszczonych tam komentarzy, które sugerują możliwości dodatkowego usprawnienia tego behaviora.

Całość oczywiście nie jest tak fajna i intuicyjna jak np. w Railsach, ale taka już specyfika samego PHP. Mimo to polecam :)