Clawdbot, dnes známý jako Moltbot, není jen další chatbot – je to osobní AI agent, který umí přímo vykonávat úkoly, místo aby jen radil. Stačí mu zadat cíl, a on sám zpracuje e-maily, plánuje schůzky, vyhledává informace nebo spouští skripty. Open-source a self-hosted přístup zajišťuje plnou kontrolu nad daty i nástroji, a dává tak uživatelům možnost mít vlastního digitálního asistenta, který skutečně pracuje za ně.
Mikroslužby slibují flexibilitu, nezávislé nasazování a snadné škálování týmů. Ve skutečnosti však každé síťové volání přidává latenci, zvyšuje režii a komplikuje dostupnost. Tento článek ukazuje, proč i jednoduché workflow může být v mikroslužbách pomalejší než v monolitu, doplněno o čísla, kód a praktické tipy pro rozhodování mezi architekturami.
Redis je běžně používán pro cache, fronty a realtime notifikace, ale přidává další infrastrukturu. Tento článek ukazuje, jak lze tyto funkce nahradit čistě PostgreSQL, s praktickými příklady kódu a zachováním rychlosti i transakční konzistence.
Dodám, že test byl proveden pro dlouho běžící aplikace, kde Java (a asi podobně i .NET) navzdory své pověsti je na tom výkonově dobře. Javisty asi moc nepřekvapí, že pro krátko běžící aplikace není JRuby výkonově vhodné. Překvapením může být spíše větší než očekávaná míra nevhodnosti JRuby pro krátko běžící aplikace, kde i –help může trvat třeba sekundu. Headius (jeden z vývojářů JRuby) psal něco jako že svého výkonu dosáhne JRuby asi po 5s běhu. Psal i nějaké možnosti, jak tu neuvěřitelnou startup prodlevu snížit, myslím, že šlo o JRuby JIT cache (na úrovni JRuby, ne JVM) a pevné nastavení 32b/64b architektury pro nativní části namísto autodetekce.
Nechá říkat, že je JRuby špatné. Pokud by se tu psalo, že JRuby je pomalé, asi bych se jej naopak zastal. Chci jen říct, že to není tak černobílé. A chci, aby se lidé nedivili, až to výkonné JRuby si na –help nějaké aplikace vezme sekundu.