Co dělá dokument pro plán snižování ceny pro projekt vývoje softwaru? Jaký je rozdíl mezi dobrým a skvělým plánem? Pořád pořád mluvím o tom, jak věnuji 85 %+ svého času a energie plánovacím fázím. Co to vlastně obnáší? Je těžké to vysvětlit abstraktně; Potřebujete konkrétní příklad, abyste opravdu ilustrovali nuance. Tak jsem si řekl, že se podělím o dobrý příklad z dneška. To také odpovídá na nedávnou otázku, kterou dostávám ohledně svého přístupu. Lidé si myslí, že musíte udělat všechno v projektu najednou. A podle mého přístupu je to pravda, ale jen pro verzi 1! Pokud se rozhodnete přidat nové funkce nebo změnit, můžete to samozřejmě udělat, jakmile budete mít funkční verzi 1. A způsob, jak to udělat, je stejný jako při tvorbě v1, tedy tím, že nejdřív vytvoříte velmi detailní plán značení a pak z něj uděláte korálky. Dám vám příklad z Cass, mého programu Coding Agent Session Search, což je docela propracovaný program v Rustu, který automaticky detekuje, zpracovává, ukládá a indexuje všechny vaše předchozí záznamy relací téměř od každého kódovacího agenta. Nabízí pod 50 ms okamžité "vyhledávání při psaní" napříč všemi těmito logy a má mnoho dalších pěkných funkcí. Rozhodl jsem se, že bych chtěl do Cassu přidat funkci podobnou té, kterou už mám v MCP Agent Mail a v beads_viewer (bv): možnost exportovat vaše nastavení jako statický web, který lze obsluhovat pomocí GitHub Pages. Příklad BV můžete vidět právě pro tento projekt, což je konečný výsledek plánovacího procesu, který popíšu v tomto příspěvku: Tato funkce umožňuje velmi rychlé a snadné generování a nasazení exportovaného webu pomocí nástroje gh. Samotný web obvykle obsahuje sqlite soubor a spoustu typescriptů a wasm, které běží kompletně v prohlížeči, ale s velmi dobrým výkonem, pěknými funkcemi a stylem, což můžete pozorovat v uvedeném příkladu. Sdílení MCP Agent Mail zpráv nebo spousty korálků je jedna věc, ale sdílení spousty log relací kódovacích agentů je úplně něco jiného; tyto věci jsou často plné citlivých informací, API klíčů, nadávek/nadávek (alespoň ty moje!) a dalšího materiálu, který byste rozhodně nechtěli zveřejnit světu. Ale GitHub Pages, i když je pěkný, funguje jen pro veřejné repozitáře (mimochodem, mé nástroje také podporují Cloudflare Pages, ale GH Pages je pro tento případ lepší a jednodušší). Jak tedy tyto problémy řešit? Odpovědí je šifrování: uživatel nejprve vybere, které kódující agenty zahrne, které složky projektu, časové období atd. a vygeneruje se balíček (poznámka: tento balíček je v kanonickém formátu, do kterého Cass interně převádí všechny zprávy kódujících agentů z jejich původních nativních formátů) a poté uživatel zadá heslo pro šifrování tohoto balíčku. Myšlenka je tedy taková, že i když jsou repozitář a webová stránka veřejné, všichni kromě vás a dalších, kterým heslo řeknete, uvidí jen pole hesla a nebudou moci přečíst žádné zprávy. Jakmile zadáte heslo, odemkne se krásné, responzivní uživatelské rozhraní, které vám umožní snadno a rychle prohledávat zprávy téměř stejně rychle a efektivně jako Cass. A pokud opravdu nemáte co skrývat, můžete heslo vynechat a vše skutečně zveřejnit. ...