Posty oznaczone etykietą varia

Garry Newman powiedział żeby Unity się p..doliło

Garry Newman told Unity to "get fucked" and said the move has left him "furious."

Widać, że Big Tech zaczyna mocno deptać ludziom po odciskach. Tym razem inba jest o wprowadzenie haraczu od pojedynczej instalacji finalnego produktu. Instalacji, czyli reinstalacji też, a nie od sprzedanych kopii (co i tak byłoby odmienne od dotychczasowych opłat).

Rust dev claims Unity is "the worst company to be in charge of the Unity Engine"

So, Unity...


Źródło: https://www.gamedeveloper.com/business/rust-creator-tells-unity-to-get-fucked-as-developers-left-seething-by-new-fee

GitHub mandatory 2FA

GitHub is making 2FA mandatory for devs!

Microshit, Fuck You

GitHub is increasing the security of repositories by requiring all developers to enable two-factor authentication by the end of 2023.

Oh.

The company’s directive is simple:

if you contribute to code, you must enable 2FA.

Musk rozjebany

So, Microsoft...


I moved to GitLab: https://gitlab.com/marcinjn

Rysuj smoka

Legenda głosi, że to było moje pierwsze polecenie wydane komputerowi:

Rysuj smoka - Atari XE

Dziś, po ponad 30 latach, komputer w końcu zrealizował to polecenie.

Rysuj smoka - AI

Można umierać. Choć może nie do końca, bo sztuczna "inteligencja" daje także upust swojej sztucznej "kreatywności" ;)

Rysuj smoka - głupsze AI

Nie potrzebuję ery 5G

Era 5G niesie ze sobą zmiany, które nie są potrzebne ludzkości. Ostatnimi laty wypracowaliśmy nowe i skuteczne metody komunikacji - transfer informacji jest błyskawiczny. Nie potrzeba dalej przyspieszać, ponieważ to niczego nie daje poza rozrywką, konsumpcją lub przetwarzaniem wolumenów takich danych, których wolałbym do przetwarzania nie oddawać.

Nie będziemy uploadować gigabajtów jadąc na rowerze, lecąc w samolocie, drzemiąc nad stawem czy pływając po jeziorze. Pracę lub streaming, a tylko tam są potrzebne wysokie przepustowości, wykonujemy w biurze. A w biurze lub w domu mamy niezastąpiony kabel.

Koszty 5G są niewspółmierne do korzyści:

  • tracimy solidne, metalowe obudowy w telefonach
  • zwiększamy częstotliwości fal, tym samym zwiększamy zużycie energii które z drugiej chcemy ograniczać (kuriozum na oddzielny wpis, choć związanę ze szklanymi obudowami pod ładowanie indukcyjne)
  • wyższe koszty budowy i utrzymania infrastruktury
  • wyższe koszty usług i sprzętu
  • zbędne koszty utrzymania narzędzia jakim jest telefon (szkło się łatwiej rozwala - nie ma cudów)
  • i coś, nad czym niewielu się pochyla - cofamy się w kwestii ergonomii produktów.

Ten ostatni punkt ostatnimi czasy jest dla mnie szczególnie dotkliwy. Lubię i doceniam dobre rozwiązania ergonomiczne. Manualne przyciski i przełączniki w samochodzie, klawisze pianina, pulpity sterownicze, kontrolery do montażu wideo, klucz oraz zamek, czy wygodny starter aplikacji z Windows Mobile na Lumii (który musiałem zamienić na dwuwymiarową cygańsko-cyrkową macierz ikon).

Związek z 5G jest niby pozorny, ale w rzeczywistości już teraz wpinamy do sieci samochody. A wpinać będziemy ich więcej, będą wysyłać jeszcze więcej informacji, a na samochodach nie poprzestaniemy - słyszałem, że już teraz ludzkość wpina do sieci wibratory. To wszystko oczywiście wymaga większej przepustowości. A wskutek tego trendu, tej szalonej cyfryzacji stymulowanej histeryczną i absurdalną potrzebą bycia online, wygodne przełączniki zamieniane są na niewygodne dotykoślizgacze, obsługiwane przez przeładowane aplikacje niczemu nie służące poza bajerem. Te półprodukty są jak wystrzelone confetti - cieszą przez chwilę, a brak ergonomii ujawnia się w momencie, kiedy trzeba posprzątać syf (analogicznie: tylko włączyć lub wyłączyć radio - bo tyle z tego wszystkiego robimy).

Jakiś czas temu ekrany dotykowe wyparły z telefonów fizyczną klawiaturę. Ewangeliści tego trendu przekonywali mnie, że to działa tak samo dobrze (a szczegółnie w Kościele Jabłczanym, który znany był z "inteligentnej haptyki"). Prawda jest taka, że nadal pracujemy z komputerami używając fizycznych klawiszy, i to często nie jakichś byle-gumowych a mechanicznych, żeby feedback był odpowiedni. Nie zastąpiliśmy klawiszy fortepianów ekranami dotykowymi. Wprost przeciwnie - w klawiaturach sterujących staramy się naśladować feedback młoteczków. Do tej pory, a minęło dobrych dziesięć lat, żadna haptyka nie dogoniła fizycznych klawiszy.

Niczym nie różni się pogoń za większymi ekranami - dziś nie ma telefonów, ale są patelnie. Ludzie przykładają patelnie do uszu i rozmawiają za ich pośrednictwem. Poważnie! Nie można mieć tabletu do rysunku i telefonu do dzwonienia. Trend zmusza mnie do jednego urządzenia do wszystkiego. A jak coś jest do wszystkiego, to wiadomo że jest do dupy.

Co jednak istotne - ludzkość zdążyła zapomnieć o ergonomii i zdążyła przyzwyczaić się do rozwiązań słabych, złych, a nawet powiedziałbym że patologicznych. Tracimy komfort, wygodę, energię, pieniądze, nie otrzymując za to niczego sensownego. A kiedy zdigitalizujemy pieniądz i resztę dziedzin naszego życia, stracimy wolność, poufność i intymność.

A chciałem tylko w roku 2023 kupić mały telefon z metalową obudową, żeby nie rozbijać więcej szkła które do niczego nie jest mi potrzebne, i żeby mieścił się w kieszeni oraz dłoni. Nie potrzebuję w telefonie ładowania indukcyjnego, kosmicznych transferów, ani nie chcę robić z niego telewizora. Potrzebuję narzędzia ergonomicznego, trwałego i o sensownym koszcie utrzymania. Niestety ludzkość bez opamiętania zmierza w innym kierunku.

Prawa Murphy'ego jako narzędzie warsztatowe

Prawa Murphy'ego znane sią chyba każdemu, także osobom nietechnicznym, od dobrych dwóch dekad. W tym krótkim wpisie przytoczę kilka "praw", które zazwyczaj traktowane z przymrużeniem oka, są podstawą rzemiosła profesjonalisty, a szczególnie administratora lub wdrożeniowca.

Stosując metodykę DevOps, a nawet ograniczając się tylko do samego continuous delivery lub continuous deployment, istotnym czynnikiem jest zapewnienie jakości. Przeprowadzając wszelakie operacje w środowiskach produkcyjnych istnieją dwie naczelne zasady: możliwie najkrótszy downtime (lub zero downtime) oraz niedopuszczanie do wprowadzania wadliwych wersji.

Mówiąc ogólnie - naczelną zasadą jest nie szkodzić użytkownikowi eksploatowanego systemu. A jak powszechnie wiadomo człowiek jest z zasady istotą omylną, najsłabszym ogniwem każdego łańcucha, dlatego do zapewnienia jakości każdemu profesjonaliście potrzebne są odpowiednie procedury postępowania.

Ciekawą pomocą w ich opracowywaniu, prawdopodobnie stosowaną powszechnie nieświadomie, są moim zdaniem Prawa Murphy'ego. Każdy odpowiedzialny profesjonalista powinien być w jakiejś części sceptykiem i pesymistą, choć niekoniecznie musi to okazywać ;)

Jeżeli coś może się nie udać, to się nie uda.
Jeśli coś może pójść źle, to pójdzie.

Powinny być podstawowymi zasadami każdego inżyniera operującego w środowiskach produkcyjnych. Błąd operatora jest jedną z najczęstszych przyczyn awarii. Przykłady można mnożyć - od przypadkowych usunięć danych, długich dysfunkcji usług sieciowych (co jest krytyczne w modelu SaaS), aż po spektakularne wycieki danych (spowodowane np. pozostawieniem "otwartego na świat" narzędzia). Nie, chmury nie rozwiązują "magicznie" takich problemów ;)

Opracowując procedury postępowania, czy to tworząc playbooki Ansible lub innego narzędzia orkiestracji, czy też wykonując operacje typowo manualne, powinno się mieć na uwadze że każdy krok może się nie powieść. Powinno się też przewidzieć w jakim stanie będzie system i jaki będzie sposób przywrócenia do stanu pierwotnego.

Jeśli wiesz, że coś może pójść źle i podejmiesz stosowne środki zapobiegawcze, to źle pójdzie coś innego

Zawsze trzeba mieć plan "B". Nawet zwykły backup. Często robiąc wdrożenia mocno modyfikujące dane, skracam RPO do absolutnego minimum tworząc kopie danych tuż po przejściu w tryb przerwy technicznej (aby wyeliminować napływ nowych danych). Czasem robię hotcopy zakładając, że częściowe odzyskanie danych będzie możliwe i nie będzie wiązać się z nadpisaniem nowszych informacji. Ostatecznie zawsze pod ręką powinien być backup całej maszyny lub okresowe dumpy danych.

Moje plany "B" zazwyczaj są wielowarstwowe, przez co na wiele niespodziewanych przypadków jestem odporny z zachowaniem RPO (Recovery Point Objective) oraz RTO (Recovery Time Objective) wynikającego z przyjętej polityki bezpieczeństwa.

Powinieneś być przerażony, gdy dziecko jest zbyt ciche.

Ta "prawda życiowa" ma swoją analogię w świecie IT. System wykazujący zbyt niskie obciążenie w stosunku do typowego dla danego dnia i pory dnia, powinien być poddany natychmiastowej inspekcji. Oznacza to, że konieczne są narzędzia monitorujące pracę systemu, ale nie tylko on-line ale również gromadzące dane historyczne. Nie ma lepszego sposobu jak ogląd krytycznych parametrów systemu w formie wykresów.

Tu warto zauważyć, że skuteczny monitoring wymaga personelu, który w niego patrzy i reaguje na jego zgłoszenia. Bez tego każdy system monitorowania jest niestety niemym głosem tonącego.

Nigdy nie mów „ups”, gdy pacjent jest przytomny

Profesjonalista nigdy nie poddaje się, gdy obsługuje awarię. Nie można wycofać się nawet wtedy, gdy za awarię w 100% odpowiedzialny jest ktoś inny. W opanowaniu sytuacji pomogą ci procedury i twoje plany "B".

Z tego wynika jeszcze coś, co nie jest oczywiste. Musi istnieć dokumentacja techniczna systemu, z której pomocą inżynier będzie mógł podejmować odpowiednie działania. Alternatywą jest posiadanie pełnej wiedzy o funkcjonowaniu całego systemu i sposobie jego obsługi, ale to podejście ma istotne wady, gdyż...

Wiedza i doświadczenie przychodzą z wiekiem. Najczęściej jest to wieko od trumny.

... każdy jest śmiertelny. Jeśli z nim zniknie wiedza, to biznes będzie miał niemały kłopot. Tworzenie dokumentacji technicznych oraz instrukcji obsługi systemu/podsystemów jest częścią pracy profesjonalisty. Zawsze trzeba na to mieć czas.

Ten, który się waha, ma prawdopodobnie rację

Trzeba być wyczulonym na takie sygnały. Wynikają one zazwyczaj z umiejętności przewidywania oraz z doświadczenia. Znowu zabezpieczeniem są procedury, plany "B".

Zawodowcy są przewidywalni – strzeż się amatorów

To się samo komentuje.

Jira nie nadaje sie do pracy

Tak twierdziłem wiele lat temu i tak twierdzę teraz. Jira to system, który jest nieopłacalny w utrzymaniu (nie tylko w zakupie), bardzo skomplikowany i trudny w użyciu. Niby są pluginy, niby są opcje do skonfigurowania, ale i tak istotne rzeczy są albo niemożliwe (tickety wiszące po 10 lat), albo trzeba dłubać w bazie danych.

Niespójny interfejs, denne rozwiązania UI (edit in place i zapis onblur), powolność działania (Java, żre zasoby), nieczytelne maile z notyfikacjami i podatność na uszkodzenia sprawiają, że pracuje się z Jirą źle. Ma kiepską nakładkę Agile. Może do Scruma jeszcze jakoś się nadaje, ale dla Kanbana to jest tylko słabiutka tablica. No dobra - jest jeszcze wykres CFD (wow!). Z Kanbanem ma to niewiele wspólnego.

Najgorsze jest to, że ciągle ktoś jest angażowany do naprawiania, konfigurowania, korygowania właściwie podstaw, i ciągle próbuje się coś zrobić, ustawić, opierając się na micie "wszystko w Jirze da się zrobić". No i dupa, szanowni czytelnicy, właśnie że się nie da. Jeśli kiedykolwiek ten mit od kogokolwiek usłyszycie, wspomnijcie moje słowa. Przed zakupem i wdrożeniem sprawdźcie dokładnie, czy spełni wasze oczekiwania (będą mówić, że spełni - ale to handlowcy).

Używałem przez dłuższy czas mojego własnego softu, który oczywiście ma większe braki i którego nie mam kiedy skończyć na jakimś sensownym etapie, ale pracowało mi się o wiele lepiej. Może dlatego, że soft jest tworzony pod konkretny workflow i z rozwiązaniami customowymi, których niekiedy próżno szukać nawet w takich kobyłach jak Jira.

srajFon - dlaczego jednak nie kupię

Bo to jeden z droższych acz małych komputerków (lub jak kto woli - przenośnych telefonów stacjonarnych), naszpikowany duperelami po to, żeby zżerać baterię i napędzać rynek power banków oraz obudów z bekonu. Komputerek z systemem, który zadręcza na "dzień dobry" koniecznością podłączenia się do WIFI lub GSM bez aktywnej karty SIM tylko po to, abyś nie mógł odczytać MAC-a potrzebnego do whitelisty WIFI. System, który po upgrade przyspiesza wysysanie baterii i jeszcze bardziej napędza rynek power banków (i obudów, kiedy już zaczynasz nim ciskać o ziemię lub ściany). System, który wiesza się akurat przy wyłączaniu automatycznie włączanych usług inwigilacyjnych srajGlaude. Oraz w końcu sklep z milionem aplikacji bez możliwości zakupu. Oraz w końcu "intuicyjny" UX, który nakazuje mi się domyślać, że karta kredytowa == jakakolwiek karta płatnicza. Skąd ta popularność - nie rozumiem. Podoba się kobietom.

Aktualizacja 19.03.2017 - a jednak kupiłem

Lumia 830 z Windows Phone w praktyce

Niemal rok temu dałem szansę Nokii z Windows Phone. Przekonały mnie dobre opinie o wytrzymałości baterii, stabilności i płynności działania. Jak słuchawka sprawuje się w praktyce?

Wymagania

Uznałem, że telefon powinien oferować:

  • prostotę użytkowania, szczególnie podczas rozmów, gdyż telefon służy do dzwonienia
  • dostęp do internetu, głównie e-mail oraz WWW, Skype
  • względnie długi czas działania na baterii
  • płynność i stabilność działania

Rozmowy

Jakość rozmów jest bardzo wysoka, szczególnie gdy aktywny jest HD Voice. Tylko znajomi początkowo mówili, że mnie nie poznali po głosie. Żadnego zrywania połączeń, żadnego zawieszania się oprogramowania przy odbieraniu lub podczas rozmów. Długie konwersacje na słuchawkach - czysta przyjemność.

Jedyny defekt to przerywanie dłuższych rozmów policzkiem. Ekran dotykowy jest czuły, włącza się czasem podczas rozmów i niestety policzek sobie coś tam klika. Być może źle trzymam słuchawkę. Ale ponieważ dłuższe rozmowy prowadzę głównie na słuchawkach, to ten problem nie jest bardzo uporczywy.

Sieć i internet

WIFI i internet GSM generalnie działają dobrze. WIFI mam praktycznie stale włączone, bo nie wysysa baterii. GSM włączam okazjonalnie. Niestety od początku użytkowania, mimo kolejnych aktualizacji zdarza się, że sieć w Windowsie "zacina się". Albo nie działa GSM, albo nie funkcjonuje WIFI. Włączanie i wyłączanie usług nie odnosi skutku, a w przypadku WIFI - nie da się go wyłączyć (ciągle oczekuje na wyłączenie). Wygląda to niestety na problem OS-a lub drivera. Pomaga dopiero restart telefonu. Duży minus.

Z e-maliami nie ma problemu. Wbudowany klient obsługuje Gmail i inne konta IMAP. Synchronizacja kontaktów i kalendarza działa OOTB.

Przeglądanie WWW jest słabe. Dostępne są tylko przeglądarki z jedynie słusznym silnikiem - Trident. Internet Explorer jest kiepski, lubi się zacinać, jest niewygodny w obsłudze. Nie jest źle, ale jednak męczy. Opera na WP jest kiepska (wolna), a UC Browser wiesza się na potęgę. Alternatyw w praktyce brak.

Skype działa bez zarzutu.

Bateria

Przy moim stylu użytkowania wytrzymuje do około 3 dni. Gdy gadam więcej lub korzystam z internetu GSM - oczywiście znacznie krócej. Ekran telefonu jest duży, więc biorąc to pod uwagę jest na prawdę nieźle. Mam aktywną funkcję oszczędzania baterii przy poziomie <20%. Wydłuża to trochę czas oczekiwania, co bywa bardzo przydatne.

Płynność i stabilność

Oprogramowanie telefonu działa szybko. UI jest responsywne, nie ma przycięć. Telefonem operuje się komfortowo. Nawet jeśli część operacji jest przykryta pod animacjami (takie pojawiają się głosy), to wrażenie jest na prawdę bardzo dobre. A to chodzi, bo po prostu użytkownik nie irytuje się.

Przez cały okres użytkowania telefon chyba nigdy się nie zawiesił, albo wystąpiło to może raz. Zamulać mogą tylko otwarte (aktywne) aplikacje, ale kiedy idą w tło - oprogramowanie działa znowu normalnie. Aplikacje w tle są wstrzymywane.

Ergonomia i wygląd

Względnie duża cegła - niczym nie wyróżniający się klocek z aluminiowym i chyba solidnym wykończeniem. Parę razy zaliczył glebę (w etui) i nic się nie stało. Ekran duży, jasny, czytelny nawet w słońcu.

Interfejs Metro jest minimalistyczny, czytelny i intuicyjny. Kafelki są wygodne i nie potrzeba dziesięciu pulpitów. W ogóle nie czuję takiej potrzeby (latami na Androidzie miałem co najmniej dwa).

Klawiatura ekranowa jest wyśmienita, a szczególnie tryb swipe, Na prawdę swipe świetnie działa i pozwala szybko pisać bez większych pomyłek.

Pozostałe uwagi

App store jest względnie skromny. Jest sporo zamienników, ale wielu ważnych aplikacji nie ma. Korzystanie z aplikacji Googla jest przeciętne (nie ma oficjalnych portów, trzeba wybierać zamienniki). Jest też mniej specjalistycznego oprogramowania. Jeśli ktoś korzysta intensywnie z usług Google (szczególnie związanych z chmurą), to z Windows Phone będzie bardzo niezadowolony (ja nie korzystam).

Aparat fotograficzny dosyć dobry. Kamerką też da się coś zrobić. Nie jest to ekstraklasa, ale jakość wystarczająca do szybkiego uwiecznienia jakiejś chwili. Pokusiłem się nawet na zrobienie krótkiego filmu - tu jednak brakuje lepszego oprogramowania, które wyeliminuje automatykę.

Windows to Microsoft - uczucie niesmaku i podejrzeń co do jakości softu jest stale obecne. Rekompensuje to trochę logo Nokii i brak sytuacji denerwujących, które serwował mi dotychczas Android. Na plus warto odnotować koniec zabaw z Cyanogemod`ami - nie ma oczywiście takiej opcji, ale w praktyce nie ma takiej potrzeby. To oszczędza dużo czasu. Warto wspomnieć bardzo dobrze przygotowywane aktualizacje oprogramowania.

Kolejny minus za brak funkcji "Godziny ciszy". Przed WP 8.1 można było zainstalować dodatkową aplikację, ale w nowszych wersjach jest ona wbudowana w system. Niestety jest dostępna tylko tam, gdzie Cortana (czyli w PL - nie!). I tak oto ani nie ma możliwości skorzystania z wbudowanej funkcji, ani nie można zainstalować aplikacji zewnętrznej.

Cena w stosunku do możliwości i jakości - bardzo dobra.

Ocena ogólna

Czwórka, może czwórka z plusem. Kupiłbym ponownie? - raczej tak, choć zaczekam na nowe Nokie z innym OS-em lub wypróbuję iPhone ze względu na bogatszy AppStore. Zdecydowanie jest to produkt dla węższej grupy świadomych użytkowników, którzy potrzebują telefonu przede wszystkim do dzwonienia i zajęciu się w życiu czymś ciekawszym niż wgrywanie ROM-ów.

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.

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.

Jak postawić sklep

A dyć prosto:

  • wybudować,
  • wynająć stragan albo blaszak,
  • zaopatrzyć się w sznur, dyktę i kilka pustaków; z dykty zrobić blat oparty na pustakach, na sznurze rozwiesić majtki.

Na czym postawić sklep?

  • na ulicy,
  • na chodniku,
  • na głowie.

Sklepu internetowego nie da się postawić. Postawić można natomiast mi piwo.

System e-commerce wdraża się w cały biznes, łącznie ze szkoleniem pracowników. System musi być dostosowany do celów biznesowych pod względem funkcjonalnym a także wydajnościowym. Powinien współpracować z innymi systemami przedsiębiorstwa, powinien być user-friendly, powinien być dobrze napisany, aby go utrzymać. Oczywiście można to wszystko olać i postawić sklep (patrz początek).

Architektura takiego systemu powinna być zorientowana na usługi, tj. zbudowana z autonomicznych ale kooperujących podsystemów, zapewniać dużą niezawodność i możliwość pracy nawet bez dostępu do Internetu.

Dla klientów sklep internetowy to łatwość wyszukiwania, szybkość działania, bogaty asortyment i konkurencyjne ceny, ale też szybkość realizacji zamówień. Tego nie osiągniesz jedną bazą i interpreterem php kulejącym na wirtualce.

Postaw mi piwo, postawię ci sklep. A jeśli traktujesz biznes poważnie, to kup odpowiedni software i jego wdrożenie. Niestety nie będzie to soft za 50, ani za 500, ani nawet 5000 zł.

Allegro Web API - czy jest wadliwe?

Allegro WebAPI jest bodaj najbardziej rozbudowanym i najlepiej udokumentowanym API spośród polskich serwisów aukcyjnych. Allegro jest wiodącym serwisem aukcyjnym w Polsce, z największą liczbą sprzedających, kupujących oraz aplikacji ułatwiających integrację z serwisem.

Podczas implementowania klienta Allegro natrafiłem na kilka mniej lub bardziej istotnych problemów. Poniżej przedstawię kluczowe dolegliwości Allegro API i serwisu testowego, które moim zdaniem powinny zostać wyeliminowane w nowszych wersjach.

Allegro WebAPI

  1. niespójność argumentów

    raz podaje się country-code, country-id, czasem zamiast myślnika używany jest podkreślnik, a w nowszych metodach zamiast webapi-key i country-code uzywany jest session-handle.

  2. niespójność odpowiedzi

    niektóre metody zwracają listy, a niektóre słowniki - czasem odwoływać można się przez klucz, a czasem trzeba przez index (najlepiej zamapować indeksy na klucze, co zrobiłem w moim kliencie Allegro)

  3. nazwy kluczy

    • prefiksowanie wszystkich kluczy nie ma sensu

      wydłuża kod, jest bardziej błędogenne (prawdopodobieństwo literówek jest większe)

    • myślniki użyte w kluczach to fatalny pomysł

      zwykle do właściwości obiektów SOAP`a można dostać się przez... właściwości obiektu; w przypadku Allegro odwoływać można się tylko przez klucz (nie można używać myślnika w nazwach properties)

  4. wersjonowanie

    API Allegro jest wersjonowane, ale w danym czasie mamy dostęp tylko do najnowszej wersji. Aplikacje klienckie przestają działać prawidłowo, jeśli w API zostanie zerwana kompatybilność wstecz. A to zdarza się dość często. Niestety o takiej krytycznej zmianie świadczy często skala lamentów na forum Allegro WebAPI. Trzeba (niestety) śledzić komunikaty.

    Takie podejście uniemożliwia napisanie działającej aplikacji klienckiej. Co najwyżej można ustrzec się przed padem za pomocą odmowy wykonania operacji i komunikatu w stylu "API Allegro zostało zaktualizowane. Skontaktuj się ze sprzedawcą".

    Brak dostępu do różnych wersji API uważam to za największą wadę Allegro.

    Kluczowe zmiany, zrywające BC, powinny być wprowadzane tylko w wersjach, których pierwszy (najważniejszy) numer ulega zmianie. Pozostałe numery wersji powinny odpowiadać odpowiednio za minor features oraz bugfixes. Kilka głównych gałęzi API powinno być stale dostępnych.

    Nowe wersje również powinny być udostępniane programistom, aby mogli przygotować klienty pod nowe API. Jednocześnie byliby betatesterami.

  5. skomplikowane struktury dancych

    Niektóre metody API przyjmują zadziwiające struktury danych, aby zrealizować jakieś zadanie. Niech za przykład posłuży metoda doNewAuctionExt i sposób przekazania danych za pomocą fields.

Środowisko testowe (testwebapi.pl)

  1. Niedostępne opcje

    Niektóre funkcjonalności nie są dostępne w środowisku testowym, np. Płacę z Allegro (PzA). Rozumiem, że PzA jest oddzielnym podsystemem i nie ma trybu testowego.

  2. Puste wyniki

    Niektóre funkcje API w trybie testowym nie zwracają danych. Nie da się w pełni przetestować aplikacji klienckiej.

  3. Błędy interfejsu

    Formularze, które po zwalidowaniu gubią dane doprowadzają do powstawania nerwowych drgawek. Stąd wnioskuję, że oprogramowanie testowe jest zupełnie inne niż wersja produkcyjna (tam nie występują podobne błędy).

  4. Urywający się PHP

    Często po edycji aukcji lub wystawiania na nowo nie ma przycisku "List an item". Nie ma też stopki. Skrypt PHP urywa się gdzieś w połowie. Wystawienie nowej aukcji rozwiązuje problem, ale wydłuża czas testowania.

Podsumowanie

Czy kiedyś powyższe problemy będą rozwiązane? Liczę na to. A póki co koszty implementacji i utrzymania oprogramowania opartego na API Allegro idą górę.

Mimo wyżej wymienionych wad Allegro WebAPI jest dość porządne, szczególnie ze względu na:

  • ilość dostępnych funkcji,
  • dość dobrą i pełną dokumentację,
  • stały support ze strony Allegro na forum,
  • komunikaty o zmianach zrywających kompatybilność (lepsze to niż nic, choć nie rozwiązuje problemu wersjonowania).

API jednego z serwisów aukcyjnych na Węgrzech wypada przy Allegro bardzo słabo.

PyCon 2010, 8-10 października

Prelekcje:

  • Aplikacje internetowe w czasie rzeczywistym w Pythonie
  • Optymalizacja i profiling metodami chałupniczymi
  • 3 kilo przyjemności
  • Python w laboratorium fizycznym
  • SymPy, czyli matematyka w Pythonie
  • Kup Pan cegłę, czyli wstęp do algorytmów rekomendacyjnych
  • Realizacja zadań administracyjnych za pomocą języka Python
  • Programowanie GPU z wykorzystaniem PyCUDA i PyOpenCL
  • PyPy czyli jak uczynić Pythona szybszym

Więcej informacji na http://pl.pycon.org/2010/agenda

Do zobaczenia na PyCon 2010!

Źródło: http://pl.pycon.org/2010/

Zmiana silnika bloga

Nadszedł ten czas. Rezygnuję z Bloggera na rzecz własnej strony domowej, dla realizacji której Blogger nie wystarcza.

Postanowiłem użyć aplikacji django-simpler-blog i rozszerzyć ją o brakujące funkcjonalności. Dzięki temu zabiegowi projekt mojej strony domowej jest łatwiejszy do realizacji, a swoją drogą mam wpływ na każdy detal. Ponad to pisanie w edytorze WYSIWYG lub bezopośrednio HTML nie jest sympatyczne. Wolę zdecydowanie Markdown.

Do realizacji tego bloga użyłem również:

  • django.contrib.comments
  • django-tagging