REST po ludzku

Znalazłem ostatnio dwa ciekawe wpisy traktujące o architekturze REST. Pierwszy z nich jest autorstwa niezastąpionego Martina Fowlera, który ciekawie przedstawił drogę od prostych usług typu RPC aż po podstawy RESTful (ale nie samego REST-a). Zdecydowanie ułatwia przejście od jednej do drugiej koncepcji: http://martinfowler.com/articles/richardsonMaturityModel.html

Z kolei drugą perełką jest wpis Ryana Tomayko, programisty GitHuba i Heroku, który wytłumaczył idee RESTful (wirtualnej?) żonie. Niestety środowisko gender zaatakowało Ryana i autor usunął artykuł-wywiad, ale na szczęście (w tym wypadku) Internet zachował jego kopie. Znajdziecie takową m.in. na archive.org: http://web.archive.org/web/20130116005443/http://tomayko.com/writings/rest-to-my-wife

Miłej lektury!

Trochę o nowościach

Jestem wprost zafascynowany i rozpływam się jak masło w rondlu, kiedy otrzymuję zamówione newslettery. Jest spora szansa na to, że podobnie mają inni ludzie - zawodowcy, pasjonaci, hobbyści. Może są to nawet cholerne tysiące ludzi, a biorąc pod uwagę prasę drukowaną to i miliony istnień, które chcą dowiedzieć się co się w danym środowisku, produkcie czy dziedzinie nauki dzieje, a co jest planowane i wkrótce się wydarzy. Przyjęło się, że czytamy newsy, u Putina новости czy też известие, a po naszemu nowości a nawet niusy, choć właściwie neologizmy mnie drażnią. Toteż towarzyszy tym newsletterom pewien stopień podniecenia, doprowadzają mnie one niemal do rozkoszy, aby w końcu ten jeden szczególny - od Polish Python Coders Group - działał jak kubeł zimnej wody. Albo nie - jak przegnanie człowieka na golasa przez wartką, górską rzekę o piątej nad ranem.

Nowości, to są rzeczy i wydarzenia nowe, nadchodzące, naturalnie w opozycji do przeszłości, czasów zamierzchłych i zdarzeń minionych. I do prawdy nie mogę zrozumieć dlaczego z uporem maniaka PPCG rozsyła "nowości" z przeszłości. Tak! Są to zamierzchłości publikowane jako nowości, tytułowane przewrotnie "newsletterem" (list z nowościami, jakby nie patrzeć), z których dowiedzieć się możemy, że "za dwa dni było spotkanie koderów Pythona w Osrajdowie Małym" albo że "w minionym miesiącu będzie można wziąć udział w konkursie".

Kilkakrotnie pisałem na adres e-mail podany w newsletterze, ale po braku reakcji wnoszę, iż prawdopodobnie lądują one zawsze w przyszłości i nigdy nie zostaną odczytane, chyba że ktoś w przyszłości zorientuje się, że rozsyłali informacje z przeszłości, i wówczas może nastąpić jakieś załamanie czasoprzestrzeni, w końcu pewne fakty oraz moje listy dotrą do oświeconych osób, a pastletter stanie się prawdziwym newsletterem.

To niezła wizytówka środowiska programistów Python. Profesjonalizm pełną gębą. A szczególnie kole w oczy to marne forum postawione na PHP-ie, które rozsyła hasła plain textem w mailu potwierdzającym rejestrację. Razem z rozwalającą się stroną PySilesia dumnie realizują cele statutowe polegające na promowaniu Pythona. Chyba Monty Pythona. Latającego cyrku.

Międzynarodowy maraton programistyczny Deadline24

Deadline24 to międzynarodowy maraton programistyczny organizowany przez firmę Future Processing, który polega na rywalizacji trzyosobowych drużyn zmagających się z zadaniami algorytmicznymi. Już po raz siódmy pasjonaci informatyki będą mieć szansę wykazać się swoją wiedzą, kreatywnością oraz wytrwałością, pracując nad zadaniami konkursowymi przez 24 godziny. Rejestracja trzyosobowych drużyn potrwa do 26 lutego 2015 roku. Zapisy odbywają się za pośrednictwem formularza na stronie https://deadline24.pl/rejestracja/. Eliminacje rozpoczną się 1 marca 2015 roku punktualnie o 9.00. Przez 5 godzin zegarowych drużyny będą zmagać się z rozwiązywaniem zadań i generowaniem odpowiedzi, ocenianych przez serwer sprawdzający. Ten etap przebiega zdalnie.

Do finału zapraszane są najlepsze drużyny spośród tych, które wzięły udział w eliminacjach. Finał odbędzie się w dniach 7-8 kwietnia 2015 roku i potrwa nieprzerwanie przez 24 godziny. Wyróżnikiem maratonu Deadline24, poza nietypową formułą zadań konkursowych, których głównymi bohaterami są żukoskoczki, jest organizowanie go w miejscach wpisujących się w tradycję województwa śląskiego. Edycja 2012 i 2013 miała swój finał w Zabytkowej Kopalni Węgla Kamiennego Guido, 320 metrów pod ziemią, a w roku ubiegłym konkurs odbywał się w Zabytkowej Kopalni „Ludwik” w Zabrzu. Organizatorzy zapewniają, że tegoroczna edycja także zaskoczy uczestników wyjątkową oprawą oraz cennymi nagrodami!

Zeszłoroczna edycja maratonu zgromadziła uczestników z Polski, USA, Holandii, Niemiec, Wielkiej Brytanii, Estonii, Ukrainy, Rosji, Nigerii, Indii, Pakistanu, Tunezji oraz Indonezji. Zawodnicy reprezentowali między innymi Uniwersytet Warszawski, Uniwersytet Jagielloński, Carnegie Mellon University, czy National University of Lviv. Do rywalizacji stanęli również przedstawiciele takich firm jak Google, InsERT, czy Flytronic.

Organizatorem Deadline24 jest firma Future Processing, która działa na globalnym rynku oprogramowania od 2000 roku, tworząc systemy informatyczne dedykowane między innymi branży przemysłu, mediów elektronicznych, opieki medycznej, sektora finansowego oraz transportu. Firma jest Certyfikowanym Partnerem Microsoftu i posiada tytuły „Independent Software Vendor” oraz „Software Development” na poziomie Gold.

Aby być na bieżąco zapraszamy do śledzenia naszego fanpage na Facebooku https://www.facebook.com/Deadline24pl.

Źródło: inf. prasowa Future Processing

Angular w listopadowy wieczór

Nie mam słów i jestem zażenowany poziomem tzw. webdeveloperów portujących pluginy pod Angulara. Zdecydowana większość tego syfu to wrappery na ścierwo pisane pod jQuery. Tak, ścierwo, bo ta biblioteka sama w sobie jest jak lep na muchy, który przez swoją tandetną prostotę przyciąga tabuny amatorów przykładających swoje uszczerbione i ufajdane cegiełki do dziurawej budowli wznoszonej od lat przez nadęte i oderwane od rzeczywistości community open source. I mimo, że są perły pod jQuery, to tworząc soft pod Angulara używanie jQuery jest nadmiarem, naroślą, wrzodem na dupie i opuchlizną dręczącą i tak nie najlżejszy framework.

Jedyny sens jest portować tak, aby nie miały zależności od jQuery czy innych wynalazków tworzonych jako dodatek do HTML-a. Dlatego ciśną mi się na klawiaturę słowa: ludzie, przestańcie do cholery robić syf - albo robicie coś porządnie, albo nie róbcie tego wcale. Później mamy taki sektor IT, jaki sobie tworzymy. Poczytajta też Stack Overflow w tym temacie.

Czołem.

Kij w mrowisko: Django Sprint 2014, Kraków

15 i 16 lutego 2014 odbył się Django Sprint w Krakowie, na którym najlepsi programiści Python poprawiali błędy Django. A ja zapytuję - po co poprawiać coś, co jest w wielu miejscach źle zrealizowane "by design"?

Oczywiście przesadzam, ale nie mogę oprzeć się krytyce, skoro na prawdę istotne wady Django nie są korygowane a istotne feature requesty są odrzucane za "niezgodność z Django ethos". Kilka najbardziej irytujących błędów i braków na mojej liście:

Brak model.reload()

Odświeżenie properties obiektu jest czasem konieczne, bo DjangoORM nie ma sensownego persistence managera (błąd projektowy polega na własnej i przeciętnej implementacji ORM, zamiast zastosowania sprawdzonych wzorców lub gotowych rozwiązań).

Obecnie trzeba obchodzić przez sekwencję

obj = Model.objects.get(pk=obj.pk)

Skopany transaction management

Do v1.6 mamy do dyspozycji dekoratory commit_on_success oraz commit_manually, a także low-level API z funkcjami commit, rollback, savepoint. Problemy są następujące:

  • obsługa commit_manually sprowadza się do zabawy w dostawianie rollbacków i commitów w odpowiednich miejscach, np. przed/po response, w przeciwnym razie otrzymujemy TransactionManagementError z poziomu template/middleware.
  • przy commit_manually każdy wyjątek opakowywany jest w TransactionManagementError, więc trzeba używać debuggera lub usuwać wsparcie dla transakcji, aby dowiedzieć się o szczegółach błędu (sic!)
  • od wersji 1.6 mamy atomic, który zastępuje powyższe funkcje i upraszcza obsługę transakcji, ale od v1.8 nie będzie już żadnej możliwości niskopoziomowego kontrolowania transakcji (będzie prościej i jednoznacznie, ale ze związanymi rękoma)
  • wsparcie multidb jest skopane, więc szereg funkcji i metod ma dodatkowy parametr using, który domyślnie oznacza bazędefault. W przypadku dekoratorów i funkcji związanych z transakcjami ma to fatalny skutek w postaci zarządzania wyłącznie transakcjami dla bazy domyślnej, ale niekoniecznie używanej w danym widoku (!!!), chyba że jawnie użyje się N dekoratorów dla wszystkich używanych baz (to nie jest czytelne i takie oczywiste, szczególnie przy class-based views).

Formularze spaghetti

Związek formularzy z HTML (widgetami) to fatalny błąd projektowy. Formularze służą walidacji i czyszczeniu danych i czasem zawierają w sobie jakieś konkretne operacje (np. form.save). Niestety każdy field jest ściśle związany ze swoim widgetem HTML, co widać wyraźnie przy próbie odczytania błędów formularza, gdzie jako reprezentację ciągu otrzymujemy HTML! Implementując RESTful service albo jakąkolwiek inną usługę nie związaną z HTML borykamy się z bagażem zależności, które trzeba sprytnie omijać.

Widgety zaimplementowane są w stylu "spaghetti" - w kodzie pythona odnajdujemy rzeź generującą koślawe HTML-e (nienależyta separacja prezentacji od kontrolera). Aby dostosować prezentację trzeba uciekać się do pakietów rozszerzających możliwości parametryzowania prezentacji (Uniform, Crispy forms), ale one też ostatecznie nie są elastycznym i poprawnym rozwiązaniem. Problemy wynikają właściwie z nieco ułomnego systemu szablonów (zbyt wiele działań oddelegowanych jest do helperów).

Wadliwa jest obsługa pól, gdzie definicja Meta.fields jest "magicznie" uzupełniana o wszystkie pola dodane w klasie formularza. Dziedziczenie po takim formularzu uniemożliwia proste ograniczanie używanych pól i trzeba usuwać je w __init__ (!).

Wadliwa jest obsługa formularzy bez pól, w przypadku których Django zakłada zawsze brak błędów, mimo zdefiniowania metody clean ze ścisłymi regułami!

Ograniczony system szablonów

Django ethos nie pozwala na dostarczenie tak podstawowego template taga czy rozwiązania, jakim jest dostęp do danych przez klucz/indeks określony zmienną. Za każdym razem trzeba pisać swój template tag lookup czy get_key

Ze względu na strukturę ograniczone są możliwości łatwej wizualizacji bardziej skomplikowanych obiektów, jak np. formularzy.

Co robić, wuju?

Jak radzić sobie z Django w prawdziwych projektach podpowiada Christophe Pettus z PostgreSQL Experts, Inc w PDF Unbreaking Django.