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

Build the API with FastAPI top of Django

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.

Django FastAPI Bridge automated documentation

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

Can you use Django with FastAPI?

Django-ORM can also be used with FastAPI but that is simply not recommended because it will be useless to use one of the oldest framework which does not use the modern features of Python, with one of the newest framework which uses the modern features like asyncio and others to provide high performance.

The brutal truth is that it is bulls*t. Let the numbers speak for themselves. The tested endpoint looks like:

# sync version

@api.get("/permissions", response_model=PermissionListResource)
def permissions_list():
    queryset = Permission.objects.all()
    items = [{"pk": obj.pk, "name": obj.name} for obj in queryset]
    return PermissionListResource(items=items)

# async version

@api.get("/async/permissions", response_model=PermissionListResource)
async def permissions_list():
    queryset = Permission.objects.all()
    items = [{"pk": obj.pk, "name": obj.name} async for obj in queryset]
    return PermissionListResource(items=items)
  1. Django + FastAPI in sync mode: 657.16 rq/sec
  2. Django + FastAPI in fully async mode: 1568.97 rq/sec

Both served through uvicorn. So... is this a high performance Django or not? :)

Note that there also is an ApI. ("artifical pseudo intelligence") which will give you nonsense in the form of supposed knowledge. Be careful and "don't trust the science" (a "science" is a new idol these days). Ok, enough...

What for is this hybrid?

  • To have one codebase for your core (models, logic)
  • To expose Django Admin panel top of it
  • To use Django ORM, auth, permissions system and other tools with FastAPI
  • To gain from brilliant performance and automatic documentation which comes from FastAPI
  • You don't have to rely on less known or unstable solutions
  • And, if programmed in async mode in mind, gain from asynchronous features like long polling.

How it works

Django has builtin support for protections against running sync code in async context, and async emulation built on threads. So you can mix sync and async code quite safely, but with a performance loss. To gain from fully async mode you must write handlers with async in mind, which will give you the best performance on the same ASGI server.

Despite the excellent support built into Django, you should pay attention to external applications or add-ons that may be developed for synchronous mode and may lack protection and cause problems. Test your app well.

What will not work

  • Django middlewares aren't compatible because of different request object
  • Wherever request is used in the code, it will not be compatible with the request object from FastAPI
  • Context processors based on request object are mostly unusable
  • Django's URL routing will not work with FastAPI routing
  • Sessions handling (not an issue when using external OAuth2 server)

What's different

  • authenticated user object must be injected as a dependency explicitely (user=Depends(get_current_user))
  • serialization and model updates will require additional helpers (a Pydantic models coupled with Django ORM models)
  • authentication process is delegated to a separate service (OAuth2 recommended), and can be based on Django OAuth2, and share the same database (it is easier to integrate both in such case)

Alternatives? No.

  • Django Rest Framework - slow, not fully async, old and not best design (which is mentioned in the docs)
  • Django Ninja - however inspired by FastAPI, it is slow and shares part of not best design from DRF

Should I use FastAPI with Django?

"It's a Frankenstein"

— random python-like developer

You can, you don't have to. Mid-sized and big-sized projects are "Frankensteins" nowdays. Monoliths or microservices - does not matter. For such projects, where you must maintain them, it is important to have consistent and simplest stack. It is easier to support Django and FastAPI instead of tens of differrent technologies, frameworks and tools, not mentioning difficulties with hiring developers who knows A, B, C, D, E, etc frameworks or libraries. It is even a matter of team management not technology itself.

"But you broke Django!"

— maybe python-like developer

There is no practical difference between not using features A, B, C because they are not needed, and not being able to use A, B or C for technical reasons. Also, I didn't broke Django in any way. It's just a mental thing. But for sure, you should be aware of the limitations.

Example architecture concept

Example architecture based on Django FastAPI Bridge

Summing up

Django FastAPI Bridge is NOT fully compilant with Django, because it is not using Django ASGI/WSGI http server. Features based on middleware or request/response objects simply won't work. But, with a proper separations of concerns, you are able to use your app logic codebase to run different services top of it, and you have all battle tested tools needed to get the things done. Note that in most cases when building a RESTful API (or even an entire API), you won't miss the built-in Django middleware.

The really missing parts the Django FastAPI Bridge will try to deliver. I am considering adding an adapter for the request object, but it can be tricky and faulty.

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.