I heard about Tailwind and looking at its documentation I thought there was something wrong with it. At the time I was surprised by the many fragmented classes that had to be set. Now that I look at it more closely, HTML semantics are basically not used, contextual styling is almost non-existent, and instead there are hundreds of CSS classes that have to be repeated with almost every tag. This results in a terribly large HTML source (“HTML bloating”), slows down development (you have to remember and constantly rewrite hundreds of classes), makes documents unreadable. And by having to repeat classes for elements of a certain type Tailwind violates DRY .

Mój blog zdążył zniknąć z sieci, po tym jak OVH wskutek ich błędu usunęło mój serwer fizyczny. Powodem usunięcia serwera był brak powiadomienia o wyłączeniu usługi, które zawsze przychodzi, i od którego jest 7 dni na uregulowanie płatności i przywrócenie maszyny. Reklamacja została oczywiście odrzucona, a kopii danych nie było.

Ludzie dzielą się na tych, którzy robią backupy i na tych, którzy dopiero zaczną je robić

Robienie backupów nie jest procesem trywialnym. Jest kosztowny, wymaga infrastruktury, zaplanowania, i opracowania procedur odzyskiwania danych.

Jakie są podstawowe różnica między klasycznym CMS a headless CMS?

W świecie PHP brak istotnych zmian. Hipotetyczne dokumenty księgowe wystawiane 30 lutego wpisują się (niestety) w smutny kanon.

Jest to ciekawy i dość poważny błąd standardowej biblioteki funkcji języka, ponieważ może pozostać niezauważony. Nieistniejąca (nieprawidłowa) data jest bowiem wewnętrznie korygowana bez przerwania przetwarzania błędem lub wyjątkiem. Język zgłasza błąd dopiero wtedy, gdy spróbujemy ustawić dzień powyżej 31.

Równie problematyczny jest brak wyjątków, czyli do tej pory w PHP został zachowany status quo, tj. niespójny error handling (parse error, recoverable error, fatal error, exceptions):

Even though these two tools seem to be mutually exclusive, they are not. There is possibility to omit Django’s http server and relay all HTTP traffic to FastAPI’s ASGI application. These are the goals of the new package Django FastAPI Bridge

Wait, isn’t Django too old for FastAPI?

If you type “Django and fastapi” into Google you will get results that are simply misinformation. Speaking gently - they’re outdated or written by persons without an experience (a real plague these days):

In case of mess in your editor window, just add this line to your .vimrc:

let g:ale_virtualtext_cursor = 'disabled'

a mess in vim A mess in VIM (look at these red inline error messages)

The root cause of the issue

Some creative guys thought that mixing warning messages with code makes some sense and increases readability, and someone smart enough implemented it (to the misfortune of mankind).

A source of the mess in vim

ReactJS to moje odkrycie 2019/2020. Po gruntownej analizie plusów dodatnich i ujemnych Angular i ReactJS wybrałem ten ostatni. AngularJS 1.x znałem dosyć długo i doskonale zdawałem sobie sprawę z jego minusów, a te są najważniejsze. Przecież to od nich zależy szybkość developmentu i długofalowe utrzymanie projektu. AngularJS poległ pozostawiając nieczytelny i opuchnięty kod, a two-way bindingiem i watcherami doprowadzał do wysokich temperatur podczas debugowania.

Klasyczny development aplikacji webowych oparty jest o renderowanie części klienckiej przez serwer, a właściwie jego fragmentów. MVC (lub jego jakaś inkarnacja) w części serwerowej tworzą totalnie nieczytelny i niespójny generator klienta, z którym obcuje użytkownik i zespół załamanych developerów. Zarządzanie klienckimi assetami przez serwer (taki jak Django ), mimo dobrej implementacji, też nie należy do najprzyjemniejszych. Łatwo o chaos, szczególnie gdy czas developmentu jest krytyczny. Niech serwer robi to, do czego służy najlepiej - niech świadczy usługi za pomocą ustalonego interfejsu. REST , czy też HTTP +JSON , to droga która powinna być standardem.

Wersja 6

Wersja 6.0 ElasticSearch jest dla mnie szczególna - twórcy wprowadzają zmiany ułatwiające zarządzanie, ale też rezygnują z dawnych błędów, które krytykowałem na łamach tego bloga.

Każdemu polecam migrację do wersji 6.x. Służę pomocą w migracji z wersji 2.x oraz 5.x.

Aktualizacje ElasticSearch - jak wykonać?

Nie można zaprzeczyć, że ElasticSearch jest rozwijany dynamicznie. Tak szybki rozwój produktu nie zawsze jest oczekiwany, bo albo wdrożenie zostaje (z przyczyn obiektywnych) oparte o zamrożoną (i nie wspieraną) wersję, albo konieczne staje się przeprowadzanie migracji do nowszych wersji. Takie operacje trzeba zaplanować, zabudżetować, a na dodatek nie obejdzie się bez downtime i sukcesem jest, gdy przerwa techniczna jest relatywnie krótka.

Oryginalny tekst datowany jest na 4.11.2015, a uzupełniony w lipcu 2016

ElasticSearch jest takim samym systemem wyszukiwania, jak każdy inny powstały w przeciągu ostatnich kilkudziesięciu lat. Indeks ma sztywną strukturę i nic tego nie zmieni. Jedyna różnica polega na tym, że tenże indeks jest modyfikowany w locie / w tle, co niesie za sobą sporo, czasem przykrych konsekwencji, choć na początku może wydawać się to świetnym pomysłem.

Nie-typy, czyli “mappingi”

ElasticSearch posiada tzw. “mappingi” . Niektórzy mogą uważać, że są to typy indeksowanych dokumentów. Słowo “typ” z resztą pada w dokumentacji. Ale to nie są typy. Są to elementy grupujące kolumny indeksu w pewne logiczne klasy , które mogą posłużyć jako dodatkowy filtr lub zbiór definicji o analizerach i tokenizerach, oraz mogą mieć znaczenie wydajnościowe (operujemy na jakimś podzbiorze). Można je porównać do widoków znanych z [RDBMS].