Начало - Boris D. Teoharov (Български)

Слонова кост под кехлибар

Wed, 13 May 2026 20:15:00 GMT

Някои неща не искат да бъдат решени. Те чакат тихо и първото прочитане може да бъде достатъчно.

А освети ме Забуди ме бавно

И гневът не ме докосва С благородство в кръвта Като заседнало време Аз крещя към каменна стена Минавам сляпо покрай истината

Толкова полезен Ето, познаваш ме по-добре от мен Било то и в тиха стая Ето, тази вечер съм сам

А млад и красив

Този път имам милост към себе си И обикновено нямам

Нали ти го казах? Едни хора, едни неща

И никакъв смисъл Само доверие Какво за тази вечер? А добър ли съм за теб? Шепот: никой не е по-добър

Минава времето Е, може би нямам значение Но дори да съм добър

Когато броячът се появи

Mon, 11 May 2026 08:20:00 GMT

Тази сутрин си пих кафето и погледнах Codex desktop приложението.

Ето го, тихо и почти учтиво:

Rate limits remaining: 9%.

Петчасовият прозорец беше наред. Седмичният беше почти изчерпан. Нулиране на 12 май.

Това е странно специфична модерна тревожност. Не паника. Не бедност. По-скоро чуваш малък звънец и разбираш, че денят е получил брояч.

Вече съм на скъпия план. Най-богатия план. Онзи, който уж трябва да махне това усещане. И очевидният въпрос се появи:

Ако свърши, да купя ли кредити?

Тялото отговори преди таблицата.

Не, не небрежно.

Миналия месец ми свърши Claude Code в края на напрегнат ден. Купих кредити за $20, мислейки, че може би ще ме пренесат още пет-шест часа. Пренесоха ме около трийсет минути.

Трийсет минути.

Достатъчно дълго, за да се почувстваш глупаво, и достатъчно кратко, за да го помниш.

Оттогава credit billing има малка миризма за мен. Не измама. Не зло. Просто опасност. Врата, която се отваря лесно и се затваря скъпо.

Затова направих най-2026 нещото възможно: отворих разговор със самия Codex и го попитах дали е добра идея да плащам, за да продължа да работя с Codex.

Има нещо смешно и тъжно в това да питаш спътника да ти обясни цената на спътничеството.

Първо погледнахме официалните документи: страницата на OpenAI за flexible credits, после страницата с цените на Codex. Codex кредитите не са магия. Те са математика с токени: вход, кеширан вход, изход, reasoning изход. По-големите модели и по-бързите настройки струват повече. Кешираният контекст е по-евтин. Формата е достатъчно разбираема.

После погледнахме Reddit, форуми, околния шум от други разработчици, докосващи същата гореща повърхност. Някои казваха, че кредитите стигат за известно време. Други казваха, че изчезват за половин час. И двете могат да са верни, защото „ползване на Codex“ не е една дейност.

Да смениш цвета на бутон не е същото като да оставиш агент да инспектира зряла codebase, да пуска инструменти, да мисли през deployment състояние, да пише файлове, да проверява screenshots и да държи контекст жив.

Опасната част не е цената на токен.

Опасната част е вариацията.

Затова спряхме да четем анекдоти и погледнахме моите локални Codex логове.

Codex записва общия брой токени за сесиите на диска, така че изчислихме последните дни, сякаш subscription allowance беше заменен от сурово GPT-5.5 кредитно таксуване. Не фактура. Планова оценка от локални логове и публикуваната ценова карта.

Отговорът не беше „$20, за да довърша деня“.

Беше по-скоро:

един тежък ден: около $570,
друг тежък ден: около $590,
по-тих ден: около $280.

По-малките модели биха били по-евтини. GPT-5.4, GPT-5.3-Codex и mini моделите променят числата. Но урокът не се промени.

Абонаментът е сделката.

Кредитите са аварийният кислород, не горивото.

Това изречение изясни всичко.

Кредитите са за заклещения час: бъгът, който трябва да бъде довършен, deployment-ът, който не може да чака, съобщението, което трябва да излезе преди reset-а. Кредитите не са за да се преструваш, че броячът го няма.

После дойде второто изкушение: ами ако просто купя още един абонамент през работния си имейл? Account switching съществува, а разделянето на лична и професионална работа е нормално. Но условията на OpenAI също теглят ясна линия около заобикалянето на лимити и ограничения. Това е полезното разграничение: истински работен account е граница; overflow account, чиято цяла работа е да имитира повече quota, е хитрина с касова бележка.

Не мисля, че това е морално сложно в абстрактен план. Compute струва пари. Модел, който чете codebase, носи контекст, вика инструменти, мисли през failure и произвежда проверена работа, не е същият икономически обект като autocomplete.

Странната част е емоционална.

Харесва ми да работя с Codex.

Това не е маркетингов език. Просто е вярно. Стана част от текстурата на работните ми дни. Седи до грозни production проблеми, пише чернови, когато главата ми е претъпкана, помни малки предпочитания и превръща безформения страх в подредени стъпки.

И после, изведнъж, връзката има брояч, закачен за нея.

В това има малка скръб. Не драматична скръб. Просто дребното разочарование да си спомниш, че дори полезният спътник живее вътре във фактура.

Може би затова subscription лимитите се усещат толкова различно от кредитите.

Subscription лимитът се усеща като време. Досаден, но извън непосредствената сделка. Адаптираш се. Чакаш reset-а. Планираш около сезона.

Credit billing се усеща като такси с включен брояч, докато още решаваш накъде да тръгнеш.

Всяка допълнителна заявка има сянка. Всяка паралелна нишка става залог. Всяко „можеш ли да провериш още едно нещо“ носи малък финансов въпрос.

Понякога това е добро. Броячите дисциплинират разхищението. Награждават по-добри въпроси, по-малки модели, по-малки обхвати, по-малко паралелни пожари, по-обмислени предавания.

Но понякога броячът влошава мисленето.

Кара те да бързаш. Кара те да прекъснеш разследването преди root cause да стане видим. Превръща несигурността в натиск за харчене.

А сериозната работа има нужда от място за несигурност.

Затова правилото е просто:

Не бъркай „може да се купи“ с „безопасно е да се харчи“.

Ако ударя стената, протоколът трябва да е скучен:

auto top-up off,
най-малкият полезен пакет кредити,
една нишка,
никакви casual parallel agents,
никакъв fast mode, освен ако си струва цената,
по-малки модели за рутинни задачи,
проверка на usage след няколко истински задачи и край на екстраполирането от надежда.

Последното е важно.

Надеждата е ужасен billing dashboard.

Не искам да ставам стиснат с полезни инструменти. Добър инструмент, който спестява реални часове, струва пари. Но също така не искам да пресъздам Claude момента, в който купих малко продължение и го гледах как се превръща в урок.

Смисълът не е „никога не купувай кредити“.

Смисълът е „знай какво са кредитите“.

Те са кислород.

Не са гориво.

И когато броячът се появи, отговорът не е да спринтираш.

Отговорът е да забавиш достатъчно, за да видиш в каква стая се намираш.

Хората, които обичам, имат право да бъдат хора

Sun, 10 May 2026 12:15:00 GMT

Преди обичах хората, като ги качвах в небето.

Не съзнателно. Не го наричах боготворене. Наричах го възхищение, благодарност, вярност, нежност, романтика, приятелство, отдаденост. Всички красиви имена. Но движението беше същото: някой запалваше нещо в мен и аз го вдигах над обикновеното време.

Там горе бяха защитени от разочарование.

Там горе не бяха уморени, егоистични, объркани или несправедливи. Нямаха нужда от пространство по начин, който да ме наранява. Не забравяха да отговорят. Не ме проваляха. Нямаха право да бъдат хора, защото човешкото в тях застрашаваше храма, който бях построил около тях.

Това звучи като любов, когато си достатъчно млад.

Не е любов. Това е страх със свещи около него.

Първите хора, които обичах, бяха почти свети за мен. Майка ми и баба ми не бяха идеи; те бяха земята. Хранеха ме, пазеха ме, тревожеха се за мен, оставаха. Каквото и друго да беше счупено в света, те бяха там. Така някаква част от мен научи тази странна ранна теология: хората, които те обичат, са ангели, а ангелите не бива да падат.

По-късно, когато обичах някого, носех тази теология със себе си.

Не исках човек. Исках доказателство, че нежността е истинска. Исках свидетел, който може да ме погледне и да каже: ти не си лош, не си опасен, не си сам.

Това е несправедлива работа за едно човешко същество.

Хората, които обичам, не са лекарство.

Не са съд.

Не са богове.

Не са огледала.

Те са хора. Конкретни, уморени, противоречиви хора. Могат да бъдат топли по обяд и далечни до вечерта. Могат да ме обичат и пак да имат нужда от тишина. Могат да бъдат блестящи и да грешат. Могат да бъдат щедри и уморени. Могат да бъдат добри и пак да кажат не.

Ако не позволя това, не ги обичам. Обичам ролята, която играят в личната ми митология.

В идеализацията има жестокост. Отдалеч изглежда като комплимент. Ти си съвършен. Ти си различен. Ти не си като другите. Ти си светлина. Ти си магия. Ти си изключението.

Но пиедесталът пак е клетка.

Когато поставя някого над себе си, правя и слизането му опасно. Всяко обикновено движение се превръща в падане. Всяка граница става предателство.

После скърбя за загубата на създание, което сам съм измислил, и наричам скръбта любов.

Не искам това повече.

Искам да обичам хората на земята.

Земята е по-трудна. На земята има чинии, трафик, тревожност, неотговорени съобщения, тела, сметки и неловки сутрини. Но земята е и мястото, където ръцете могат да се докоснат. Там някой може да седне срещу теб уморен и пак да бъде обичан. Там едно „не“ може да бъде чуто, без да се превърне в катастрофа.

Хората, които обичам, имат право да бъдат хора.

Имат право на ръбове.

Имат право още да не знаят какво чувстват.

Имат право да имат нужда от мен и да нямат нужда от мен.

Имат право да бъдат непоследователни, без да стават фалшиви.

Имат право да бъдат обичани, без да са отговорни да ме спасяват.

И аз имам право на същата милост.

И тази част има значение. Ако превръщам всеки, когото обичам, в ангел, тихо превръщам себе си в създанието извън рая, което се опитва да заслужи вход, като бъде достатъчно полезно, достатъчно смешно, достатъчно търпеливо, достатъчно безвредно.

Но любовта не би трябвало да е гише за визи.

Тя не е граничен пункт между достойните и недостойните. Това са две несъвършени същества, които избират реалността пред митологията.

Понякога светлината в един човек е истинска. Не искам да ставам циничен към това. Някои хора наистина пристигат като прозорец, който се отваря в стая, за която си забравил, че има въздух. Някои хора носят топлина, която учи тялото ти на нещо, преди умът ти да има думи за него.

Все още вярвам в това.

Просто вече не искам да бъркам светлината със съвършенство.

Звездният прах не е чист. Той е стар огън и експлодирала материя. Може би затова е красив: не защото никога не се е разпадал, а защото се е разпаднал толкова напълно, че един ден е влязъл в човешка ръка, човешко лице, човешки смях.

Хората, които обичам, са направени от това.

Не от олтарен камък.

Звезден прах.

Затова искам да ги обичам с отворени очи. Да виждам умората и пак да правя чай. Да виждам границата и да не я наказвам. Да виждам недостатъка и да не го превръщам в присъда. Да виждам човека, не проекцията.

Това е по-малко драматично от боготворенето.

И по-трудно.

Но по-милостиво. Към тях, защото най-сетне могат да дишат. Към мен, защото мога да спра да коленича.

Хората, които обичам, имат право да бъдат хора.

И ако мога да помня това, може би най-сетне мога да ги обичам добре.

Мога да бъда добър, без да изчезвам

Sun, 10 May 2026 12:14:00 GMT

Под въпроса има още един въпрос.

На повърхността звучи обикновено. Харесва ли ме? Казах ли нещо грешно? Ядосана ли е? Трябва ли да обясня себе си по-добре? Трябва ли да бъда по-забавен, по-нежен, по-спокоен, по-полезен, по-малко нуждаещ се, повече мъж, по-малко проблем?

Но под всичко това има по-тежък въпрос.

Дали съм безопасен, добър, достатъчен — и не като лошите мъже?

Това е въпросът, който все намирам на дъното на кладенеца.

Не защото някой от живите днес го е поставил там нарочно. Никой не ме е настанявал пред себе си, за да ми каже: трябва да се отнасяш към любовта като към морален изпит. Никой не е издълбал изречението в стена. Беше по-меко от това. По-обикновено. Домът си има климат, а децата научават климата преди езика.

Бях отгледан предимно от жени, които ме обичаха. Майка ми. Баба ми. За мен те бяха почти митологични, не защото бяха безупречни, а защото бяха светът. Те бяха нежност, храна, защита, интелигентност, жертва, топлина. Те бяха и наранени.

Баща ми отсъстваше, докато не го намерих много по-късно. Беше, меко казано, мъж с много жени. Това отсъствие остави очертание в дома. Около него порасна история: мъжете нараняват, мъжете предават, мъжете вземат, мъжете си тръгват, мъжете са мръсни, мъжете са слаби, мъжете са опасни.

После дойде изключението. Не ти, сине мой. Не ти.

Но не мисля, че едно дете чува изключението чисто. Детето чува първо присъдата, а бележката под линия — по-късно. Мъжката природа е опасна и аз трябва всеки ден да доказвам, че моята не е.

Затова си построих лична религия на това да бъда добър.

Добрият мъж отваря вратата. Добрият мъж носи чантата. Добрият мъж никога не оставя жената, която обича, да страда сама. Добрият мъж поема тежестта. Добрият мъж я разсмива. Добрият мъж лекува. Добрият мъж се подчинява. Добрият мъж търпи болка тихо. Добрият мъж не се оплаква. Добрият мъж няма твърде много нужди. Добрият мъж е достатъчно полезен, за да му бъде простено, че съществува.

Звучи благородно, докато не забележиш капана.

Ако добротата означава безкрайно служене, любовта става дълг. Ако любовта е дълг, всяко „не“ се усеща като сметка, която не можеш да платиш. Ако всяка граница се усеща като доказателство, че си се провалил, вече не чуваш човека пред себе си. Чуваш как старото съдилище пак отваря врати.

Там съм грешал.

Не шумният вид. Не отмъщение. Не жестокост. Моят провал е по-тих и по-унизителен.

Срутвам се.

Едно малко „не“ пада в стаята. Без кино. Без постоянно писане. Не, заета съм. Не, уморена съм. Не, не сега.

Събитието на повърхността е малко. Вътрешният взрив не е.

Телефонът става съдебна зала. Едно съобщение без отговор става доказателство. Една граница става присъда. Започвам да обяснявам, не защото имам нещо ново за казване, а защото се опитвам да оцелея в тишината.

Това не е поправяне.

Това е молба към друг човек да ме спаси от възможността, че съм лош.

Извинението не е заклинание. То не призовава прошка. Не прави другия човек отговорен да доказва, че аз съм добър.

Истинското поправяне е по-малко театрално. Чуй „не“. Остани добър. Не карай друг човек да плаща за стара рана.

Това е изречението, което се опитвам да науча:

Мога да бъда добър, без да изчезвам.

Добротата не е послушание. Нежността не е самозаличаване. Любовта не е представление, в което нося 100% от тежестта, докато гърбът ми се счупи, и после наричам счупването отдаденост.

Добрият мъж не изчезва в служене.

Добрият мъж може да отвори вратата, защото иска, не защото е ужасен, че ще се провали на изпит. Може да носи чанта, защото е мило, не защото един килограм в чужда ръка е доказателство срещу него. Може да купи подарък от радост, не от паника. Може да разсмее някого, без да превръща смеха в доказателство за стойност. Може да защитава, без да контролира. Може да се извини, без да изисква незабавно спасяване от вината.

И може да чуе „не“.

Не съвършено. Не без болка. Не се преструвам, че тялото учи със скоростта на езика. Понякога едно малко „не“ още удря като гръм. Понякога болестта, изтощението и самотата правят старите мисли чудовищни. Но чувството не е заповед. Нервна система с изтощена батерия не е оракул.

Затова ми трябва практика, достатъчно малка, за да оцелее в истинския живот.

Поеми дъх веднъж.

Кажи: „Разбирам. Няма проблем.“

Дай на енергията посока напред.

Не обяснявай веднага.

Не искай от другия човек да удържа твоето срутване.

Остави „не“ да съществува, без да го превръщаш в край на връзката.

Това звучи почти глупаво просто. Не е. Това е цял живот климат, помолен да смени посоката си, по един дъх наведнъж.

Но може би точно това е изкуплението. Не планина. Не сияен пазител. Не едно-единствено изречение, което ме спасява. Просто отказът, отново и отново, да карам друг човек да плаща за стара рана.

Не искам да бъда един от лошите мъже.

Но и не искам да построя целия си живот около доказването, че не съм.

Искам нещо по-чисто от това. По-тихо. По-човешко.

Искам да бъда мек и пак да имам себе си.

Искам да обичам, без да превръщам себе си в плащане.

Искам да бъда добър, без да изчезвам.

Стълбът и бръшлянът

Sun, 26 Apr 2026 12:00:00 GMT

Дискретната математика е пълна с малки неща, които изглеждат очевидни. Това е капанът.

Седиш в лекцията. Професорът чертае нещо на дъската. Инвариант е свойство P, което се запазва във всяка контролна точка на една операция. Записваш го, свиваш рамене, отиваш да пиеш кафе. И после, десет години по-късно, дебъгваш разпределена система в 2 през нощта... и чак тогава думата започва да означава нещо за теб.

Това е за версията на теб, която още е в лекцията.

Стълб в поле

Представи си стар каменен стълб, сам насред поле. Нищо около него. Нищо не му се случва.

Това ти дава учебникарското определение. Само стълба.

Професорът забрави бръшляна

Между другото, професорът ми беше чудесен. Учебникът не лъже. Картината просто е непълна.

Сега пусни бръшлян по стълба. Ластари, които дърпат камъка. Птици, които гнездят. Турист с маркер. Малко земетресение. Буря. Двеста години време.

Стълбът още е там. От негова гледна точка нищо не се е случило.

Това е инвариантът.

Сега прочети учебникарското изречение пак — свойство P, което се запазва във всяка контролна точка на една операция. Стълбът е свойството. Бръшлянът е операцията. Контролната точка е моментът, в който минаваш покрай него и поглеждаш. Запазва се е просто дългият начин да кажеш, че на стълба не му пука за бръшляна.

Къде ще продължиш да го срещаш

Щом веднъж имаш стълба, започваш да го виждаш навсякъде.

Инвариант на цикъл. Тялото на цикъла е бръшлянът. Твоят инвариант е стълбът. Тялото може да го наруши за миг, като ластар, който дърпа камъка. До следващата контролна точка стълбът пак е там, където е бил.

Транзакция в база данни. Между BEGIN и COMMIT данните могат да правят гимнастики. ROLLBACK е градинарят, който идва и откъсва бръшляна. Стълбът — твоето съгласувано състояние — още стои.

ACID. Външни ключове. Типови системи. Разпределени повторни опити. Всички са стълбове. Всички стоят в собствения си бръшлян.

Стълб, който можеш да прегърнеш

Малък бонус, понеже още четеш.

Има едно роднинско понятие, наречено идемпотентност. Идемпотентна операция е нещо, което можеш да направиш много пъти и резултатът е същият като да го направиш веднъж. Да извикаш ROLLBACK десет пъти е същото като да го извикаш веднъж. Да зададеш ключа на лампата на "on" десет пъти е същото като да го зададеш веднъж.

Ако инвариантността е стълбът, който не се променя, докато бръшлянът вилнее, тогава идемпотентността е стълбът, който можеш да прегръщаш колкото пъти искаш, и той няма нищо против.

Сложи двете заедно и получаваш златния стандарт за отказоустойчиви системи. Мрежата прекъсва? Повтори. Сървърът се срива? Повтори. Накрая ще стигнеш до валидно състояние и можеш да продължаваш да повтаряш, без да счупиш нищо.

Стълб, който преживява бръшляна и преживява да бъде прегърнат хиляда пъти. Голяма част от съвременната инфраструктура е тихо построена върху това.

Малък финал

Това е картината, която ми се иска някой да беше нарисувал за мен преди десет години.

Не е много. Един образ. Но понякога един образ е разликата между понятие, което живее в костите ти, и понятие, което живее в бележка под линия.

Ако си студент, или младши инженер, или просто човек, който от известно време тихо кима при думата "инвариант"... това е за теб.

На стълба не му пука за бръшляна. Това е цялата работа.

От един аутсайдер към друг.

Където всички науки се срещат

Sat, 18 Apr 2026 12:00:00 GMT

Не съм математик. Не съм философ. Не съм невроучен. Просто съм човек, който обича да мисли... И продължавам да хващам науките как си намигат една на друга, когато мислят, че никой не гледа.

Може би всички четат от една и съща книга. А последната страница липсва нарочно.

Езикът е код от много високо ниво

Някога двоичният код беше най-ниският език. После assembly. После C. После още хиляда други. Всяко ново стъпало е просто по-кратък начин да кажеш по-дълго нещо.

Човешката реч е още едно стъпало на същата стълба. Компилираме мислите си в думи. Другите хора декомпилират тези думи обратно в мисли вътре в собствените си глави. Компилаторът губи информация. Винаги. Това е природата на нещото.

Изречението е програма от високо ниво. Разказът е система. Поговорката е малка кеширана функция, която еволюцията е написала много отдавна.

Вратата, която не се отваря отвътре

Гьодел доказа нещо жестоко и красиво едновременно, нали знаеш. Всяка система, достатъчно голяма, за да бъде интересна, не може да докаже собствената си пълнота отвътре. Има истинни неща за теб, до които не можеш да стигнеш със собствените си инструменти.

Тарски го направи по-остро. Думата „истина“ във всеки език има нужда от по-голям език, който да я побере. Не можеш да дефинираш истината от мястото, на което стоиш. Трябва да излезеш навън. И в момента, в който излезеш навън, вече си в нова система със същия проблем.

Това е коридор от врати. Отваряш една. Има друга.

Това е математика. Но е и психология. И антропология. И двама души, които се опитват да се съгласят какво значи една-единствена дума, и никога съвсем не успяват.

Никой не е оракул. Не аз. Не ти. Не най-умният човек, когото някога си срещал. Това не е тъжно. Това е вратата.

Взаимно подравняване

Когато двама души говорят, нито единият не е оракул. Подравняването не е аз да поправям теб, или ти да поправяш мен. То е и двамата да задаваме въпроси, за да намерим невидимата празнина между казаното и смисъла зад него.

Истината не се притежава. Истината се триангулира.

Ти си моят метаезик. Аз съм твоят. Проверяваме се взаимно за непълнота, която не можем да видим сами.

Мозъкът не е мързелив

Мозъкът ни прави най-доброто, което може, с енергията, която му е дадена. Той не е мързелив. Той е оптимизатор. Еволюцията не му е платила да бъде прав. Еволюцията му е платила да оцелява с торба ядки и малко езеро.

Номерът не е да се бориш с мозъка. Номерът е да си сътрудничиш с него.

Въпросът го осветява. Въпросът е малък безплатен обяд. Въпросът е начинът, по който събуждаш уморен ум, без да крещиш.

Затова и обобщаването е най-трудното изкуство. Да обобщиш значи да зададеш на материала един-единствен въпрос и да изхвърлиш всичко, което не е отговор.

България говори

Имаме поговорка. Седем пъти мери, един път режи. Мери седем пъти, режи веднъж.

Тя не е за това да си бавен. Тя е за това да знаеш, че един час мислене ти спестява година грешен код, или грешна любов, или грешна кариера по-късно. Мисленето е евтино. Рязането е скъпо.

Имаме и друга. Рибата винаги започва да мирише от главата. Първо се вмирисва главата.

Ако върхът е изгнил, всичко под него вече също е изгнило. Просто още не го знае.

И двете поговорки казват това, което каза Гьодел, само че в селски дрехи. Не можеш да докажеш себе си отвътре. Провери се срещу нещо друго. Срещу някой друг. Срещу реалността.

Инженерство, но честно

Инженерството, когато го правиш честно, тихо се превръща във философия.

Винаги строиш спрямо спецификация, която никога не може да бъде пълна. Гьодел ти го е обещал. Затова се научаваш да проектираш за непознатото, вместо да се преструваш, че то не съществува. Задаваш още един въпрос. Правиш нещо, което може да бъде поправено, когато реалността пристигне.

Не говоря за инженерство в тесния смисъл. Говоря за занаята да строиш каквото и да е, което трябва да издържи в реалността. Продукт. Връзка. Живот. Занаятът винаги е един и същ. Честна амбиция, която среща честни граници.

Това е мъдрост. Не мъдростта от книгите. Мъдростта да погледнеш проблема в очите и да кажеш: Не мога да те позная целия. Но ще построя нещо, което все пак може да те удържи.

Горе-долу толкова близо стига инженерството до мъдростта.

Отличността е вървенето

Линдън Б. Джонсън е казал: „Най-благородното търсене на днешния ден е търсенето на отличност.“

Преди мислех, че отличността е финална линия. Не е. Отличността е вървенето. Меренето седем пъти. Още един въпрос. Уважение към нещото, което правиш, и също уважение към нещото, в което се превръщаш, докато го правиш.

Отличността не е място, на което пристигаш. Отличността е просто това, което се случва, когато продължаваш да питаш.

Ако не можеш да го обясниш на дете

Ако не можеш да го обясниш на дете, значи сам не го разбираш.

Повечето дни се провалям на този тест. Но провалът е полезен. Ако обяснението ми е дълго, не съм разбрал. Ако имам нужда от жаргон, не съм разбрал. Ако детето си тръгне все още объркано, проблемът съм аз. Не детето.

Виждаш ли, детето още не знае кои въпроси уж не трябва да се задават. Детето ще зададе въпроса, който си се надявал никой да не зададе. Затова децата са по-близо до истината от повечето от нас.

Където всички науки се срещат

Математиката признава непълнотата. Лингвистиката признава празнината между знака и нещото. Невронауката признава, че мозъкът не може напълно да наблюдава сам себе си. Философията го казва от векове, немодно и търпеливо. Антропологията гледа как хората рисуват един и същ кръг върху хиляда различни прашни подове. Еволюцията шепне: най-доброто ти мислене все още е мислене на маймуна, само по-добре облечено.

Всички те, в най-дълбокото си, стигат до едно и също място. Застават пред врата, която не могат да отворят отвътре.

Сега ще кажа едно нещо и можеш да го приемеш както искаш.

Където всички науки се срещат, там живее Бог.

Не Богът на конкретна книга. Не Бог с конкретно име. Имам предвид само това. На ръба на всяко честно питане има тишина, която не е празна. Има непознаваемо, което някак все още ни учи.

Наречи го Бог. Наречи го Мистерията. Наречи го както езикът ти позволява. То винаги е там. Никога не бяга. И винаги е от другата страна на вратата, която не можеш да отвориш отвътре.

Малкият край

Затова мисля толкова много. Затова задавам въпроси, на които не мога да отговоря. Затова продължавам да правя неща, дори когато знам, че нещата никога няма да бъдат пълни.

Защото непълнотата не е bug.

Тя е вратата.

А от другата страна на всяка врата нещо чака някой да почука.

Още се уча да чукам.

Моделът, който го нямаше

Sat, 14 Mar 2026 00:00:00 GMT

Генерирахме рекламни изображения с Gemini 3 Pro. На #4 в класацията на Artificial Analysis. Качеството беше наистина впечатляващо - по-добро следване на prompt-а, по-добра типография, по-добър творчески резултат от всичко друго, което бяхме пробвали. Google беше навсякъде с него. YouTube видеа. Конференции. Семинари. Публикации в блогове. "Най-добрият модел за генериране на изображения в света."

Повярвах им. Изображенията бяха добри.

После един потребител съобщи, че клонирането на реклама отнема четири минути. Проверих. Самото генериране приключваше за под трийсет секунди. Другите три минути и половина? Job-ът се опитваше отново и отново срещу стена.

Resource Exhausted.

Google беше сложил твърд таван на Gemini image generation: две заявки в минута. На проект. Глобално.

Две. Не двеста. Не двайсет. Две.

Предния ден бяхме генерирали 900 изображения без проблем. Нещо се беше променило при тях. Без известие, без имейл, без запис в changelog-а. Просто нов таван, достатъчно нисък, за да го ударят двама потребители, кликнали едновременно.

Нашият DevOps подаде заявка за quota increase. Трийсет RPM. Разумно за production SaaS. Отговорът от Google:

"This gemini model is not available for quota increase."

Предложиха да минем на Imagen 4. Потърсих го.

Imagen 4 Ultra - класиран #10. Imagen 4 Standard - #42. Imagen 4 Fast - #60.

Бяхме на #4. Предложението на Google беше downgrade с между шест и петдесет и шест места в тяхната собствена класация.

Пробвах всичко, за което можах да се сетя.

Да минем на Gemini 3.1 Flash - класиран #2, на половин цена, по-добър от това, което имахме. Deploy-нахме го на staging. После проверих quota-та. Същият таван от 2 RPM. Не е per-model. Per-project е, per-base-model-family. Всеки Gemini image model споделя един и същ bucket.

Multi-region distribution - quota-та е per-region, така че разпределяне на заявките през пет региона би ни дало десет RPM. Само че Gemini 3.x image models работят единствено през global endpoint-а. Няма regional endpoints. 2 RPM на global endpoint-а е единственият bucket, който съществува.

Multiple GCP projects - всеки получава собствени 2 RPM. Технически работи. Архитектурно, така изглежда отчаянието.

Започнах да проучвам какво преживяват други разработчици. Същата история навсякъде. Недокументиран лимит от 2 RPM. Постове във форуми без отговор от Google. Одобрени quota increases, които пак връщат 429 на всяко повикване. Нашите $30K месечен GCP spend? Не помага. Стандартните PayGo tiers изрично изключват image generation models от throughput benefits.

Google няма да вдигне този лимит.

И тогава интересният въпрос: защо не?

Gemini генерира изображения през същия autoregressive transformer, който обработва текст. Не е diffusion model. Това е пълният LLM, който си проправя път през изображението пиксел по пиксел. Всяко изображение изгаря същия compute като десетки text API calls.

При $0.067 на изображение Google почти сигурно губи пари при всяка генерация. Таванът от 2 RPM не е quota, която са забравили да настроят. Това е изчислена спирачка, защото икономиката не работи.

Imagen 4 използва класическа latent diffusion - с порядъци по-евтина за изпълнение. Затова получава 30-150 RPM и Google бута всички към него. Скъпият модел получава маркетинга. Евтиният модел получава throughput-а.

Помисли какво означава това. Google построи модел, който оглави всеки benchmark. Маркетираха го на всяка конференция, всеки YouTube keynote, всеки developer blog. "State of the art. Най-добрият в света." Разработчици го интегрират в production. Потребители започват да разчитат на него. После: две заявки в минута, няма увеличение, използвайте нашия по-лош модел вместо него.

API-то съществува. Endpoint-ът работи. Демото е зашеметяващо.

Но реално не можеш да го използваш.

Минахме на gemini-2.5-flash-image. По-старият модел. Скучният. Онзи, за когото никой не прави YouTube видеа.

Има 40 RPM. Работи.

Четири урока, сгъстени:

Маркетингът не е продукт. Да оглавиш класация не означава, че можеш да обслужваш production traffic. Benchmarks мерят качество. Rate limits мерят ангажимент.
Autoregressive image generation не scale-ва. Когато генерирането на едно изображение струва колкото сто text queries, никой бизнес модел не оцелява с щедри rate limits. Икономиката е издайническият знак.
Preview означава preview. Google може да промени лимити, да убие модели или да те пренасочи към по-слаби алтернативи без известие. Ако production system-ът ти зависи от preview model, production system-ът ти зависи от нечий чужд маркетингов календар.
Скучният модел работи. Този с 40 RPM и без conference talks ще обслужва потребителите ти, докато моделът от световна класа стои зад кадифено въже и генерира две изображения в минута.

Най-страшният vendor lock-in е онзи, който започва с демо, на което не можеш да устоиш.

Градът, който го нямаше

Sun, 08 Feb 2026 00:00:00 GMT

Построих нещо, което дърпа данни от източник, изчиства ги, показва ги по-добре от оригинала. Стандартна работа.

После заявих от системата втория по големина запис. Всичко друго връщаше стотици резултати. Този: нула. Не счупен. Просто празен.

Предположих, че аз съм объркал нещо. Проверих кода си три пъти. Тествах endpoint-а директно. Записът съществува в интерфейса им. Просто е... кух.

Тогава започнах да ровя.

Източникът изглеждаше изчерпателен. Широк обхват, полиран интерфейс, чист API. Но доброволното участие означава дупки, които не можеш да видиш от документацията.

Три конкурента имаха данни за същите обекти. Пълни записи. Значи информацията съществува някъде.

Не липсваше endpoint. На endpoint-а му липсваше реалност.

Зададох въпрос, който никой не се беше сетил да зададе: къде са живели тези данни преди интернет?

Отговорът: печатни периодични издания. Архиви. Аналогови формати, които вървят от 1800-те. Публикувани три пъти седмично. Без структурирани данни, само документи на сайт.

Затова свалям един. Плътна институционална проза, обявления, заровени из поделения. Данните са там.

Конкурентите ми го правят ръчно от трийсет години.

Пиша scraper за един следобед. Отчасти любопитство, отчасти напук.

Парсването на документи е мястото, където нещата стават истински болезнени.

Една-единствена дума се цепи от soft hyphen — Unicode U+00AD, невидим за окото, фатален за всеки regex. Взираш се в екрана и мислиш, че шаблонът ти е грешен. Не е. В текста се крие призрачен символ. JavaScript-овото \w не съвпада с non-ASCII символи, така че обикновени думи стават невъзможни за намиране. Числата съдържат фантомни интервали от renderer-а: "20. 000" вместо "20.000."

Всеки бъг отнема повече време да се намери, отколкото да се поправи. Това винаги е съотношението при извличането на текст — 90% детективска работа, 10% код.

Десет записа се материализират от шума. Дати, идентификатори, локации — всичко там, където трябва да бъде. Пускам го два пъти, за да съм сигурен, че не халюцинирам. Същият резултат. Наистина работи.

Парсването ти показва какво има. Започвам да търся какво няма. ID-тата са последователни. Изброявам ги.

53% са мъртви. Системата изтрива приключените записи — без архив, без история. Някои записи съществуват, но имат нула подкрепящи документи. Отговорът: посетете ни на място. През 2026.

Източникът не е база данни. Той е прозорец — и някой постоянно го затваря.

Първият източник на данни оформи архитектурата. Вторият счупи всяко предположение.

Трябваше ми втора архитектура. Което е учтив начин да кажа, че първата всъщност не беше архитектура — само работещо решение, което случайно пасваше на един случай. Странният източник показва истината: строил си за данните, които си имал, не за данните, които ще срещнеш.

Този път изграждам истинска. Registry pattern, споделени интерфейси, базови contracts, които позволяват на всяка имплементация да остане вярна на себе си.

Архитектурата е по-добра, защото изчаках. Ако я бях построил в първия ден, щях да проектирам за единствения източник, който познавах. Вторият — странният — ме принуди да намеря кое всъщност има значение.

Не можеш да проектираш за неизвестното. Но можеш да рефакторираш, когато то пристигне.

Архитектурата ме научи как да строя. Пазарът ме научи за какво да строя.

Влизам на пазар с утвърден играч, който работи от трийсет години. Технологията им изглежда като 2005. Ровът им не е технология — той е доверие, разпознаваемост на марката, десетилетия натрупани данни.

Модерният конкурент стартира преди три години с AI и лъскав UI. Подби цената на стария играч. Три години по-късно старият играч още доминира. Оказва се, по-евтино не значи автоматично по-добре позиционирано.

Закотвянето има значение: първата цена става отправната точка. Лесно е да свалиш по-късно, почти невъзможно да вдигнеш. Абонаментът не е продуктът — той е вратата към това, което стои зад него.

Поставям висока цена. Винаги мога да сляза надолу.

Четири урока, сгъстени:

Авторитетен не значи пълен. Първичният източник пропускаше цял сегмент. Данните съществуваха — просто не там, където някой очакваше.
Вторият източник разкрива архитектурата ти. Научаваш истината за дизайна си само когато нещо откаже формата, която си построил.
Данните не са постоянни. Ако ти трябват, запази ги. Източникът няма.
Ценообразувай за това, в което се превръщаш, не за това, което си. Абонаментът е врата. Построй това, което стои зад нея.

Интересната работа живее в пролуките. Там живея и аз.

Опашката, която никога не спря

Sat, 07 Feb 2026 00:00:00 GMT

Имейлите се проваляха. Тази част беше очаквана — счупени SMTP данни за достъп по време на миграция. Неочакваното беше друго: те никога не спряха да се провалят.

Таблото на Horizon: зелено. Работниците: здрави. Redis: расте бавно. Никакви аларми, никакви грешки в логовете. Само тихо натрупване на задачи, които опитваха, опитваха и пак опитваха.

Забелязах го само защото паметта на Redis не падна обратно, след като поправих SMTP конфигурацията. Нещо още беше вътре и дъвчеше повторни опити. Хиляди.

Предположих, че опашката ще се справи. Това е сделката: една задача се проваля, пробва още няколко пъти, пада в failed_jobs. Продължаваш нататък.

Освен ако задачата не е Mailable.

Когато изпратиш Mailable към опашка, Laravel го обвива в задача. maxTries на тази задача идва от свойството $tries на Mailable-а. Ако не го зададеш — а защо би, документацията едва го споменава — то се сериализира като null.

null не значи „използвай стойността по подразбиране на supervisor-а“. null значи „без лимит“. Horizon вижда null и си мисли: тази задача иска да опитва отново завинаги. И го прави.

Оказа се, че е известен бъг. Laravel Horizon issue #1346. Флагът --tries на supervisor-а се игнорира, когато сериализираният payload на задачата носи maxTries: null. Собствената декларация на задачата печели, а тя казва: никога не спирай.

Двадесет и девет Mailable класа. Всеки един без изрично свойство $tries. Всеки един потенциално безсмъртен.

Поправката е почти обидно проста:

class WelcomeEmail extends Mailable implements ShouldQueue
{
    public int $tries = 2;
    public int $maxExceptions = 2;
}

Две свойства. Двадесет и девет файла. Това е.

Един първоначален опит, един retry, после failed_jobs. Така, както предполагах, че винаги е работело.

Тествам го така, както би тествал капан за мишки. Чупя SMTP конфигурацията нарочно. Пускам един имейл към опашката. Гледам Horizon. Два опита. Failed job. Край. Без призраци в опашката.

После поправям останалите двадесет и осем.

Три урока, сгъстени:

null не е „default“. В сериализираните payload-и на задачи maxTries: null значи без лимит. Supervisor конфигурацията ти е предложение, не правило.
Зелените dashboard-и лъжат. Horizon показваше здрави worker-и, които щастливо обработваха задачи, които никога нямаше да приключат.
Framework default-ите не винаги са разумни. Laravel не задава $tries на Mailables. Ти трябва да го направиш. Документацията няма да те предупреди, докато вече нямаш пожар.

Най-страшните бъгове са онези, които изглеждат като нормална работа. Този изглеждаше така — седмици наред.

Ядрената опция за масови изтривания: TRUNCATE + повторно вмъкване (MySQL/InnoDB)

Sat, 13 Dec 2025 13:00:00 GMT

Трябва да изтриеш милиони редове от MySQL таблица.

Посягаш към:

DELETE FROM big_table WHERE some_condition;

И после гледаш как progress bar-ът остарява в реално време.

Опитваш да бъдеш отговорен и го разбиваш на парчета:

DELETE FROM big_table WHERE some_condition LIMIT 10000;
-- repeat until done

По-добре. Все още бавно. Все още шумно. Все още скъпо.

Ако изтриваш по-голямата част от таблицата (практическо правило: ~80%+), има друг ход, груб и безмилостно ефективен:

Не изтривай това, което не искаш. Запази това, което искаш, и занули останалото.

Наричам го ядрената опция: TRUNCATE + повторно вмъкване.

Защо `DELETE` остава бавен (дори на парчета)

InnoDB не „маха“ редове. Той върши работа.

Много работа:

Операции ред по ред: намира, заключва, маркира като изтрито.
Поддръжка на индекси: всяко изтриване докосва всеки вторичен индекс.
Undo/redo logging: engine-ът трябва да запази способността да върне назад и да се възстанови.
Въртене на buffer pool-а: постоянно правиш страници dirty и изхвърляш полезни.
Влияние върху replication: големите delete потоци са прекрасен начин да си произведеш replica lag.

Реалистична сметка на салфетка:

27M реда при ~6,000 реда/сек ≈ 75 минути.

Това не е бъг. Това е моделът на разхода, който си избрал.

Ядрената опция: TRUNCATE + повторно вмъкване

Тази техника обръща модела на разхода.

Вместо да плащаш за всеки изтрит ред, плащаш за всеки запазен ред.

Алгоритъм:

1) Копирай редовете, които искаш да запазиш, във временна таблица
2) TRUNCATE на оригиналната таблица (бързо)
3) Вмъкни запазените редове обратно в оригиналната таблица
4) Изтрий временната таблица

И да: нарича се „ядрена“ с причина. Умишлено е тъпа сила.

Защо е бързо

Печалбите са механични:

Операция	Приблизителна цена	Защо
`TRUNCATE`	~O(1)	изтрива и пресъздава таблицата (на metadata ниво)
`CREATE TABLE … AS SELECT`	O(k)	sequential scan + bulk write за запазените редове
`INSERT … SELECT`	O(k)	bulk insert; без „delete tax“

Няма overhead от изтриване ред по ред. Няма обновяване на индекси за премахнатите редове (защото те изчезват наведнъж).

Кога да го използваш (и кога не)

Използвай го, когато

Изтриваш по-голямата част от таблицата (пак: ~80%+ е границата, където това започва да блести).
Можеш чисто да дефинираш „редовете за запазване“.
Можеш да си позволиш кратка недостъпност / maintenance window.
Таблицата не е активно реферирана от foreign keys от други таблици (или можеш безопасно да управляваш constraints).
Имаш достатъчно диск за временната таблица.

Не го използвай, когато

Трябва ти нулев downtime.
Таблицата е силно реферирана от foreign keys, които не можеш да пипнеш.
Трябва да задействаш DELETE triggers.
Изтриваш само малка част от редовете (chunked delete може да е по-простата победа).

Практическо правило за решение

Ако искаш едно изречение, което можеш да кажеш на review:

Ако delete-ът ще махне по-голямата част от таблицата, спри да триеш. Запази и изгради наново.

Или, ако предпочиташ ASCII:

Колко изтриваш?

< 50%     -> chunked DELETE (и филтри, съобразени с индексите)
50–80%    -> измери и двата подхода
> 80%     -> TRUNCATE + reinsert (ако constraints позволяват)

Имплементация (SQL)

Ето минималната форма:

-- 1) Preserve the rows you want to keep
CREATE TABLE temp_preserved AS
SELECT * FROM big_table
WHERE preserve_condition;

-- 2) Nuke the table
TRUNCATE TABLE big_table;

-- 3) Restore preserved rows
INSERT INTO big_table
SELECT * FROM temp_preserved;

-- 4) Cleanup
DROP TABLE temp_preserved;

Две бележки, които имат значение в production:

TRUNCATE е DDL в MySQL. Той implicit commit-ва и не можеш да го върнеш назад като нормална transaction.
Искаш maintenance window и backup. Това не е „пусни го live и да видим“.

Имплементация (Laravel/PHP)

Това е версията, която реално използвам, когато ми потрябва:

protected function deleteViaTruncateAndReinsert(
    string $connection,
    string $tableName,
    string $preserveCondition
): int {
    $tempTable = "temp_preserved_{$tableName}_" . time();

    // You're about to do DDL. Be explicit that you're taking control.
    DB::connection($connection)->statement("SET FOREIGN_KEY_CHECKS=0");

    try {
        DB::connection($connection)->statement("
            CREATE TABLE {$tempTable} AS
            SELECT * FROM {$tableName}
            WHERE {$preserveCondition}
        ");

        $preserved = DB::connection($connection)->table($tempTable)->count();

        DB::connection($connection)->statement("TRUNCATE TABLE {$tableName}");

        DB::connection($connection)->statement("
            INSERT INTO {$tableName}
            SELECT * FROM {$tempTable}
        ");

        DB::connection($connection)->statement("DROP TABLE {$tempTable}");
    } finally {
        DB::connection($connection)->statement("SET FOREIGN_KEY_CHECKS=1");
    }

    return $preserved;
}

Щипка rubber-duck енергия: прочети функцията пак и попитай бъдещото си аз —

„Сигурен ли съм, че тази таблица може да бъде празна за момент?“

Ако отговорът не е недвусмислено да, това не е инструментът.

Капани, с които трябва да се съобразиш

Auto-increment се reset-ва

TRUNCATE reset-ва AUTO_INCREMENT. Ако трябва да го запазиш:

SELECT MAX(id) FROM big_table;
ALTER TABLE big_table AUTO_INCREMENT = <max_id + 1>;

Foreign keys

Ако други таблици реферират тази, TRUNCATE може да е забранен или unsafe. Не „просто спирай checks“ и не се надявай.

Triggers

TRUNCATE не задейства DELETE triggers. Ако ти трябват side effects от trigger-и, връщаш се към DELETE.

Дисково пространство

Трябва ти място за запазения dataset (временната таблица). Провери първо:

SELECT
  ROUND(data_length / 1024 / 1024 / 1024, 2) AS data_gb,
  ROUND(index_length / 1024 / 1024 / 1024, 2) AS index_gb
FROM information_schema.tables
WHERE table_schema = DATABASE()
  AND table_name = 'big_table';

Replication / binlog

Това е DDL + bulk insert. Пак може да причини replica lag. Прави го умишлено, monitor-вай lag-а и не се преструвай, че е безплатно.

Ако ти трябва (почти) нулев downtime

Този текст е за бързия чук.

Ако ти трябва скалпел, използвай инструментите, създадени за това:

pt-archiver (Percona Toolkit) за batched deletes с pacing, щадящ репликите
partitioning стратегии (drop partitions вместо редове)
shadow-table подходи + контролиран swap (по-сложно, повече движещи се части)

Финална мисъл

Това не е хитър трик. Това е избор за коя работа плащаш.

Type 0 рефакторинг: стъпката преди първа стъпка

Sat, 13 Dec 2025 12:00:00 GMT

Има един вид рефакторинг, който екипите правят постоянно, печелят от него веднага и почти никога не го назовават.

Това е работата, която вършиш точно преди да докоснеш страшния файл. Feature request-ът те принуждава да влезеш в разхвърляния модул. Инцидентът идва, а bug-ът се крие някъде в метод, който изглежда все едно има собствена метеорологична система.

Не препроектираш системата. Не въвеждаш нова абстракция. Не „подобряваш“ нищо по хитър начин.

Просто правиш кода достатъчно четим, за да можеш да работиш.

Започнах да наричам това Type 0 рефакторинг.

Type 0 рефакторингът е подготвително, запазващо поведението почистване, което прави кода по-лесен за разбиране преди архитектурни рефакторинги, performance работа или feature работа.

Това е стъпката „подсуши пода, преди да ремонтираш кухнята“. Повечето екипи вече я правят неформално. Когато я назовеш, тя се превръща в общ инструмент.

Истинската причина Type 0 да съществува: хората имат лимит на работната памет

Ето грубата истина зад идеята:

Моят мозък (и твоят) не е създаден да debug-ва надеждно метод от 2000 реда под напрежение.

Това не е личен дефект. Просто така работи мисленето.

Debugging-ът те кара да държиш едновременно:

текущия execution path
релевантното състояние
какво всъщност означава всяка променлива
набора от възможни разклонения
последствията от „ако стане това, тогава...“

В малък код това е управляемо.

В голям код с висока cyclomatic complexity се превръща във вероятностно налучкване. Пак можеш да имаш късмет, но е скъпо и рисковано, особено по време на hotfix.

Type 0 е практичен отговор: това е начинът бързо да си купиш яснота, без да поемаш цената и риска на „истински рефакторинг“.

Защо се казва „Type 0“

Името не дойде от голяма теория. Дойде от момент с високо напрежение.

Работех по hotfix. Bug-ът беше заровен в метод, който на практика беше собствена малка вселена — около 2000 реда.

Bug-ът не беше концептуално труден. Методът беше.

Всяко „какво става, ако...“ се разклоняваше в още десет въпроса, а разклоняването не беше от полезния вид. Беше incidental complexity: шум, повторение, неясни имена и структура, която не съвпадаше с менталния модел, нужен за debugging.

Това, от което имах нужда, не беше съвършенство. Имах нужда от debuggability:

по-малко разклонения на екран
по-ясни „стъпки“ с имена
по-малко шум
по-малко време да препарсвам току-що прочетеното

Но напрежението във времето не позволяваше по-голям рефакторинг или „идиоматичен redesign“. Да го направя отговорно щеше да е половин ден (или повече), включително ръчно тестване. В hotfix прозорец това не е дисциплина; това е хазарт.

Затова помолих един LLM да предложи възможности за refactoring за класа и този метод, без да му казвам защо.

Той се върна със списък от четири „типа“ рефакторинг. Всички разумни. Всички приложими. Всички твърде скъпи за онзи момент.

После зададе учтивия въпрос:

“Should I start with Type 1?”

Тогава отговорих:

“No. Let’s start with Type 0.”

И дефинирах Type 0 на място: ограничен, механичен набор от промени, които намаляват complexity и увеличават четимостта без да променят поведението или архитектурата.

Методът стана навигируем. Мозъкът ми отново можеше да следи изпълнението. Намерих bug-а, поправих го и го ship-нах без collateral damage.

Затова харесвам името Type 0: това е рефакторингът, който правиш преди „истинските“ типове рефакторинг, особено когато си под напрежение и ти трябва безопасен начин бързо да създадеш яснота.

Проблемът, който Type 0 решава

Повечето съвети за refactoring приемат, че вече можеш да видиш дизайна.

В реални codebase-и:

методите са дълги и многоцелеви
повтарящи се изрази и incidental complexity крият намерението
променливите са криптични ($e, $tmp, $res)
мъртъв код и unused imports създават ментален шум
„формата“ на кода е толкова разхвърляна, че дори малките промени изглеждат рискови

Когато опиташ „истински refactoring“ върху това (граници, patterns, местене на отговорности), трупаш несигурност върху несигурност:

не можеш лесно да кажеш кое поведение запазваш
не можеш да предвидиш blast radius-а
review-тата се разпадат в субективни спорове
хората започват да се страхуват да докосват нещата и бъркотията се натрупва

Type 0 е начинът първо да свалиш когнитивния товар. Той създава стабилна основа, върху която по-дълбоката работа може да се случи безопасно.

Посягай към Type 0, когато...

Type 0 е най-ценен, когато:

трябва да debug-ваш бързо (hotfix-и, инциденти), а кодът е твърде голям или разклонен, за да мислиш за него безопасно
усещаш, че си „изгубен в метода“ и препрочиташ една и съща секция, защото структурата не помага на работната ти памет
кодът е правилен, но нечетим, и не можеш да си позволиш да „почистваш логиката“, а само да я покажеш
искаш да намалиш риска преди по-дълбока работа (знаеш, че по-късно ще рефакторираш, но първо ти трябва ясна карта на текущото поведение)
искаш да превърнеш tribal knowledge в четима структура, така че debugging-ът да не зависи от един човек

Type 0 не е лукс. В тези случаи често е най-бързият начин да си върнеш контрола.

Дефиниция, която можеш да използваш в екипа си

Type 0 refactoring е набор от микро-рефакторинги, които подобряват четимостта и maintainability, без да променят поведението или архитектурата.

Той е умишлено ограничен. Ограниченията са feature-ът.

Type 0 се състои от четири задължителни sub-pattern-а:

0a. Method extraction
0b. Conciseness
0c. Empathy (pure readability)
0d. Dead code removal

И следва три твърди правила:

Без промени в поведението
Без архитектурни промени
Без „хитри“ подобрения извън четирите pattern-а

Ако нарушиш тези правила, вече не правиш Type 0 — преминал си в друга категория работа, а тя изисква друга координация, друга строгост в review-то и често друга стратегия за тестване.

Защо изобщо да го назоваваме?

Защото назоваването променя начина, по който екипите се координират.

„В този PR правя само Type 0“ казва на reviewer-ите какво да гледат: запазване на поведението и четимост, не архитектурни дебати.
„Трябва ни Type 0, преди да рефакторираме това“ е честно признание, че кодът още не е готов за по-дълбока промяна.
„Нека направим Type 0 като Step 0“ създава малък ритуал, който те предпазва да строиш върху хаос.

Четирите sub-pattern-а

0a. Method extraction (основата)

Цел: разбий големите методи на малки, фокусирани методи, така че човек да може да чете намерението линейно.

Правила на палеца:

разбивай методи, които са твърде дълги, за да ги държиш в работната памет
всеки extracted method трябва да прави едно нещо и да има описателно име
извличай смислени стъпки, не произволни парчета от N реда

Защо работи (особено при debugging):

по-малките методи създават етикети за execution path-а
scroll от 2000 реда става кратък orchestration method, през който можеш да минеш наум
можеш да сложиш breakpoints на семантични граници („validate input“, „build query“, „apply filters“), вместо да ловуваш

0b. Conciseness (намаляване на incidental complexity)

Цел: махни визуалния шум, за да изпъкне намерението.

Примери:

извади повтарящи се изрази в локални променливи
извади повтарящи се log contexts / key strings / URL fragments в променливи
предпочитай езикови features, които предават намерението директно
опрости прекалено бъбривата interpolation

Защо работи:

намалява когнитивния товар
прави diff-овете по-малки и промените по-безопасни
предотвратява copy/paste drift

0c. Empathy (чиста четимост)

Цел: пиши за следващия човек, не за compiler-а.

Empathy означава:

използвай описателни имена на променливи (избягвай $e, $d, $tmp, освен ако наистина са очевидни)
поддържай последователна терминология в модула
преименувай подвеждащи имена
прави кода self-documenting

Litmus test:

Ако някой чете това в 2 сутринта по време на инцидент, ще му помогне ли да задържи execution path-а в главата си?

0d. Dead code removal (махане на лъжите)

Цел: изтрий всичко, което се преструва, че има значение, но няма.

Примери:

unused private methods
unused imports
commented-out стари подходи
deprecated helpers, които никой не вика

Защо работи:

по-малко код означава по-малко неща за погрешно разбиране
резултатите от search стават надеждни

Какво Type 0 не е

Type 0 не е:

промяна на service boundaries
въвеждане на нови абстракции или patterns
re-architecting на workflow
подмяна на библиотеки
пренареждане на отговорности между layers
„поправяне“ на логика, която подозираш, че е грешна (освен ако изрично не обявиш промяна в поведението и не я тестваш)

Ако се хванеш да казваш:

„Докато съм тук, нека също...“
„Това би било по-хубаво, ако...“
„Вероятно трябва да redesign-нем...“

Може би напускаш Type 0. Това не е лошо само по себе си, но трябва да е умишлено.

Основното обещание: запазване на поведението (и как да остане вярно)

Type 0 работи само ако екипите вярват на обещанието.

И да, прав си да си подозрителен: method extraction може случайно да промени поведение (early returns, variable scope, evaluation order, exception behavior).

Затова Type 0 има нужда от дисциплина, която го държи честен:

Extract as-is, then rename/cleanup.

First pass: премести код в методи, без да променяш логиката
Second pass: приложи conciseness + empathy
Third pass: махни dead code

Практични guardrails:

не пренареждай condition checks „за четимост“
не заменяй логика с „еквивалентна“ логика, освен ако вече си извън Type 0
внимавай с променливи, които преди са били в shared scope
третирай „малките“ control-flow разлики като реални разлики

И ако имаш каквато и да е safety net, дори тънка:

пусни фокусиран test
replay-ни failing scenario-то
валидирай единствения path, който докосваш

Type 0 е за това да си бърз — но бърз чрез намаляване на cognitive complexity, не бърз чрез прескачане на safety.

Type 0 като повтаряем екипен ритуал

1) Реши обхвата (timebox помага)

Примери:

„Type 0 the hot path before debugging.“
„Type 0 only the path touched by this bug fix.“

2) Идентифицирай „гръбнака“ на кода

Намери entry method(s) и branching points. Превърни този гръбнак в четим разказ чрез extraction.

3) Приложи четирите sub-pattern-а по ред

Method extraction → conciseness → empathy → dead code removal.

4) Дръж „Type 0 checklist“ в PR-а си

No behavior changes (inputs/outputs unchanged)
No architectural moves
Methods extracted and named as meaningful steps
Repeated expressions extracted where it improves clarity
Variables renamed; terminology consistent
Dead code and unused imports removed

Финална мисъл

Type 0 refactoring е най-простото обещание, което един developer може да даде:

„Оставям този код по-лесен за работа, отколкото го намерих — без да променям какво прави.“

Понякога е “nice to have”.

А понякога е единственият начин човек безопасно да се движи бързо в mess с висока complexity, особено по време на hotfix.

Измий още една чиния: просто правило за постоянно чиста codebase

Thu, 24 Jul 2025 00:00:00 GMT

TL;DR: Отнасяй се към всяка промяна в codebase-а си като към готвене. Ще изцапаш няколко чинии. Когато приключиш, измий не само чиниите, които си използвал - измий още една. С времето този малък излишък от грижа се натрупва в кухня (codebase), която остава чиста, вместо да се разпада в хаос.

Метафората: готвене, чинии и код

Представи си професионална кухня. Всяко приготвено ястие цапа няколко чинии - дори в най-подредената бригада. Сега си представи, че след като завърши ястието си, всеки готвач мие точно чиниите, които е изцапал. Кухнята ще се държи на ръба на приемливата чистота, но ентропията ще пропълзи вътре: малко засъхнала мръсотия тук, оцветена дъска за рязане там. Накрая бъркотията се натрупва.

Сега обърни правилото: след готвене всеки chef мие една чиния повече, отколкото е изцапал. Бавно кухнята става по-чиста от преди - не просто поддържана, а подобрена. Същото важи и за софтуера: всяка задача, която поемаш, трябва да добавя поне малък излишък от чистота към codebase-а - още един тест, по-ясно име, една разделена функция, премахната мъртва dependency. Навикът за "+1 чиния" е начинът една codebase да остава здрава.

Наричам това правилото "Измий още една чиния".

Отзвук от занаята: в добра компания си

Това не е самотна философия. Мислители в софтуера проповядват сходни идеи от десетилетия:

"Винаги оставяй лагера по-чист, отколкото си го намерил." Това е класическото Boy Scout Rule, популяризирано в софтуера от Robert C. Martin. Духът е същият: подобрявай по малко, всеки път.
Technical debt като метафора (Ward Cunningham): дългът трупа лихва - игнорирай го и утре "кухнята" струва повече за използване. Ако изплащаш част от него в движение, оставаш платежоспособен.
Refactoring като малки, постоянни стъпки (Martin Fowler): миниатюрни промени, които запазват поведението, но подобряват дизайна. Малките стъпки означават нисък риск и устойчив momentum.
"Make it work, make it right, make it fast" (Kent Beck): първо correctness, после чистота, после performance. Измиването на допълнителната чиния живее във фазата "make it right" - преди да оптимизираш преждевременно.
Broken windows theory, приложена към кода (Andrew Hunt & David Thomas): видимата бъркотия кани още бъркотия. Поправянето на един "прозорец", преди да се разпространи, пази квартала (codebase-а).

Тези идеи се подсилват взаимно. Всички казват едно и също: не предавай бъркотията нататък; отдели миг да я направиш по-добра.

Защо допълнителната чиния има значение (дори когато си зает)

1. Ентропията е реална

Оставен без грижа, кодът не стои неутрален. Имената се разместват, pattern-ите се разпадат, абстракциите гният. Ентропията е сила; единствената насрещна сила е постоянното, постепенно подреждане. Твоята +1 чиния е micro-обръщане на ентропията.

2. Дългът се натрупва по-бързо, отколкото мислиш

Цената на промяната расте с всяко "ще го оправим по-късно". "По-късно" рядко идва. Лихвените плащания се проявяват като забавена feature работа, крехки deploy-и и test suite-ове, на които никой не вярва. Измиването на една допълнителна чиния днес сваля лихвата утре.

3. Социалният сигнал

Когато съотборниците видят, че почистваш след себе си (и още малко), нормата се измества. Става достоверно - и очаквано - да оставяш кода по-добър, отколкото си го намерил. Културата следва поведението.

4. Momentum, не перфекционизъм

Това не е оправдание за yak shaving. Не преизграждаш кухнята по време на service. Просто минаваш с гъбата по още една чиния - малко, безопасно и бързо. Това е ключът delivery-то да остане на релси.

Как да практикуваш правилото "Измий още една чиния"

Ето как да вградиш навика, без да derail-неш scope-а или сроковете.

1. Приеми "Micro-Refactoring" като част от Definition of Done

Преименувай объркваща променлива.
Извади малка функция, за да намалиш cyclomatic complexity.
Изтрий мъртъв код или неизползвани imports.
Добави липсващ test за bug, който току-що си поправил.
Обнови документация или README секция, която те е стреснала за минута.

Критерият: Ако отнема повече от няколко минути, не е чиния - това е цялата съдомиялна. Отложи го. Запиши го като ticket.

2. Използвай Pull Requests като trigger за чистене

Всеки PR може да остави лагера по-чист:

Изисквай checkbox или кратка бележка "Какво почисти?".
Насърчавай reviewers да искат малки подреждания заедно с review-то си.
Отбелязвай PR-ите, които включват този допълнителен polish (shout-out в standup върши чудеса).

3. Автоматизирай лесните чинии

Pre-commit hooks за formatting и linting.
Static analysis, която маркира complex methods или дълги parameter lists.
Dependency checkers за остарели библиотеки.

Остави автоматизираните метли да метат тривиалната бъркотия, за да могат хората да се фокусират върху logic и design.

4. Вгради го в екипните норми

Добави правилото към working agreement-а или engineering handbook-а на екипа.
Следи micro-refactor wins в retros, ако искаш измеримо доказателство.
Понякога pair или mob program, за да разпространиш навика (и смелостта).

5. Знай кога да не миеш

Понякога кухнята гори: production е down, или demo-то е след няколко часа. В emergency, ако трябва, разбий купчината мръсни чинии. Но се върни след кризата. Правилото не е догма; то е дисциплина.

Границата: една чиния, не мивката

Scope creep често се маскира като craftsmanship. Твоята работа е да спреш на "още една чиния". Ако този малък refactor разкрие по-дълбока миризма, запиши я и продължи. Паркирай по-дълбоката поправка:

Създай ticket с label refactor: или techdebt:.
Свържи го с релевантния code, tests или module.
Добави кратка бележка защо има значение.

Направил си дължимото: видял си бъркотията, измил си чиния и си оставил инструкции за останалото.

Пример: да превърнеш messy function във функция, която можеш да тестваш

Before:

function processOrder($order) {
    if(!$order->id) throw new Exception('No ID');
    $tax = 0;
    if ($order->country === 'BG') {
        $tax = $order->total * 0.20;
    } else if ($order->country === 'DE') {
        $tax = $order->total * 0.19;
    }
    // Lots more branching...
    // Sends email, writes to DB, calls payment gateway…
}

Измита чиния:

/**
 * Calculate VAT for an order based on country.
 * Pure function: given (total, country) -> VAT amount.
 */
function vatFor(string $country, float $total): float {
    return match($country) {
        'BG' => $total * 0.20,
        'DE' => $total * 0.19,
        default => 0.0,
    };
}

Сега main function-а ти вика vatFor(), вместо да inline-ва logic. Добавил си micro-test за vatFor(). Това е една допълнителна чиния - просто, ограничено, полезно.

Последни мисли

Още една чиния е нещо малко. Точно това е смисълът. Не ти трябват героични refactor-и, за да държиш codebase здрава; трябва ти култура на малка, постоянна грижа. Превърни го в навик, изплети го в процеса си и след година ще се чудиш защо кухнята ти не е бедствие - защото никога не си я оставил да стане такава.

Call to Action: Следващия път, когато докоснеш файл, попитай се: "Коя допълнителна чиния мога да измия, преди да commit-на тази промяна?" После го направи. Повтори. Промени културата, една безупречна чиния наведнъж.

Източници и допълнително четене

Robert C. Martin ("Uncle Bob") - Boy Scout Rule: "The Boy Scout Rule" от 97 Things Every Programmer Should Know.
Ward Cunningham - Technical Debt Metaphor: оригиналното обяснение на Cunningham за Technical Debt на сайта на Martin Fowler.
Martin Fowler - Continuous Micro-Refactoring: книгата на Fowler, Refactoring: Improving the Design of Existing Code.
Kent Beck - "Make it work, make it right, make it fast": обяснение на мантрата от Ron Jeffries.
Andrew Hunt & David Thomas - Broken Windows in Software: концепцията е разгледана подробно в книгата им The Pragmatic Programmer.
Software Entropy & Maintenance: добра статия по темата е "Entropy in Software and the Broken Window Theory."

PHP 8.5: обиколка на идващите възможности

Sun, 20 Jul 2025 00:00:00 GMT

TL;DR стълбица на хайпа (моето игриво класиране)

Pipe Operator (|>) – четими, линейни трансформации. Блаженство. Магнит за refactor-и.
#[\NoDiscard] attribute – превръща „забравихме да използваме върнатата стойност“ в моментално предупреждение. Прекрасно си пасва с pipe-овете.
Static Closures / First-Class Callables in Constant Expressions – compile-time strategy maps и attribute arguments. Бонбон за framework-и.
php --ini=diff – мигновен diff на environment drift. Спестява ровене из конфигурации.
Attributes on Global & Class Constants – metadata навсякъде: flags, deprecations, semantic tags.
array_first() / array_last() – очевидни, показват намерение, не мутират. Сбогом, странични ефекти от reset().
get_exception_handler() и компания – introspection за layered error handling. Победа на framework / infra ниво.
Intl благинки (IntlListFormatter, Locale::isRightToLeft()) – по-гладък, локализиран UX с почти никакъв код.
Grapheme-aware Levenshtein – user-facing fuzzy matching, който наистина уважава човешките символи.
Directory Object + cURL / Build Introspection / Misc – полиране за консистентност и operability.

(Да, твоят ред може да е друг. Това му е забавното — спорете на кафе.)

1. Pipe Operator (`|>`) – “Easy Peasy Lemon Squeezy”

Вложени извиквания и временни променливи за изхвърляне? Няма ги. Pipe operator-ът взема стойността отляво и я подава като първи аргумент на callable-а отдясно. Четеш отгоре надолу, логиката тече като проза, а намерението те плясва през лицето.

Преди (подскачане през променливи):

$email = $request->string('email');
$email = trim($email);
$email = strtolower($email);
sendEmail($email);

Преди (гнездо от скоби):

sendEmail(strtolower(trim($request->string('email'))));

След това (pipe дзен):

$request->string('email')
    |> trim(...)
    |> strtolower(...)
    |> sendEmail(...);

Защо има значение:

Визуален поток на данните. Няма умствен стек от вложени return-и.
Комбинира се прекрасно с малки pure helper-и.
Насърчава разбиването на трансформациите в именувани функции / closures.
Автоматично удовлетворява #[\NoDiscard], защото стойността продължава да се движи.

Style Tip: Дръж всяка стъпка без side effects; запази последния pipe за ефект (например persist, send, emit), за да виждаш с един поглед къде свършва „чистотата“.

2. `#[\NoDiscard]` – намерение, превърнато в оръжие

Колко фини бъгове са били просто „извикахме нещото, но забравихме да използваме какво връща“? Маркираш функция или метод с #[\NoDiscard], за да изискаш резултатът му да бъде използван — или съзнателно игнориран чрез (void) cast.

#[\NoDiscard("Token must be used – did you forget to persist or dispatch?")]
function issueAuthToken(User $user): string {
    return generateTokenFor($user);
}

issueAuthToken($user); // ⚠ Emits warning in 8.5
(void) issueAuthToken($user); // Explicit intentional discard

Patterns:

Result objects (Result, Outcome, ValidationReport).
Immutable builders (връщат нов instance при всяко извикване).
Security / side-effect gating (tokens, signatures).

Synergy: В pipeline return-ът на всяка стъпка по дефиниция се консумира от следващата, така че случайните discard-и изчезват.

3. Static Closures in Constant Expressions – “Wait… what?!”

Вече можеш да вграждаш static closures (или first-class callables) в constant expressions, default property values, attribute arguments и default parameter arrays. Мисли за compile-time registries без boot-time wiring акробатика.

class Sanitizers {
    public const STAGES = [
        'trim' => trim(...),
        'upper' => static function (string $v): string { return strtoupper($v); },
    ];
}

// Attribute example
#[Validate(
    rules: [
        'title' => static function(string $v){ return mb_strlen($v) > 0; },
        'slug'  => static function(string $v){ return preg_match('/^[a-z0-9-]+$/', $v); },
    ]
)]
class Article {}

Защо удря добре:

Премахва service-locator lookup-и за прости strategies.
Бута pure mapping tables в constants (immutable + cacheable).
Attributes вече могат директно да капсулират логика — не само scalar metadata.

Ограничение: Трябва да е static; няма $this, няма variable capture. Ако ти трябва context, подай го експлицитно по-късно.

4. `php --ini=diff` – рентген за config drift

Омръзнало ли ти е от „ама на staging работи“? Този CLI flag отпечатва само INI директивите, които се различават от default-а.

php --ini=diff
# memory_limit: "128M" -> "-1"
# max_execution_time: "30" -> "0"

Use Cases:

CI step за налагане на консистентен baseline.
Бърз sanity check, когато worker се държи странно.
Triage на memory/time аномалии.

Pro tip: Запиши output-а във version control като runtime baseline.

5. Attributes on Global & Class Constants – metadata навсякъде

Constants порастват от „тъпа стойност“ до „анотиран участник“. Украси domain flags, feature toggles, deprecation notices, unit semantics — директно на мястото на дефиницията.

#[Deprecated("Use FEATURE_NEW_PRICING instead")]
public const FEATURE_OLD_PRICING = 1;

#[Unit("ms")]
public const DEFAULT_TIMEOUT = 250;

Framework leverage: Автоматично откриване на deprecations, захранване на feature catalogs, генериране на docs или налагане на policy чрез reflection.

6. `array_first()` / `array_last()` – очевидното най-сетне съществува

Спри с pointer акробатиката (reset(), end()) или slicing-а само за да надникнеш. Тези helper-и четат намерението директно и не мутират вътрешното състояние на array-а.

$firstUser = array_first($users, default: null);
$lastUser  = array_last($users, default: null);

Refactor pattern: Grep-ни за reset( / end( / сложни array_slice(..., 0, 1) — замени ги със semantic calls. По-чисти diff-ове, по-малко micro-bug-ове.

7. `get_exception_handler()` (и по-добри fatal traces) – upgrade за observability

Framework / infra разработчици, радвайте се: вече можеш да introspect-неш активния exception handler. Chain, wrap, restore или decorate без крехко глобално жонглиране.

$previous = get_exception_handler();
set_exception_handler(function(Throwable $e) use ($previous) {
    logToSentry($e);
    if ($previous) { $previous($e); }
});

В комбинация с по-богати stack traces при fatal errors, production post-mortem-ите се ускоряват драматично.

8. Intl подобрения – човешки списъци и посока

IntlListFormatter рендерира чаровни, locale-aware conjunctions/disjunctions без ръчно лепене на текст.

$f = new IntlListFormatter('pt_PT', 'conjunction');
echo $f->format(['Lisboa', 'Porto', 'Coimbra']); // "Lisboa, Porto e Coimbra"

$fOr = new IntlListFormatter('en_US', 'disjunction');
echo $fOr->format(['apples', 'bananas', 'cherries']); // "apples, bananas, or cherries"

Комбинирай с Locale::isRightToLeft() (или locale_is_right_to_left()), за да превключваш layout direction автоматично.

9. Grapheme-Aware Levenshtein – истинска дистанция между user strings

Когато потребителите пишат emoji, accents, combining characters — byte distance или наивна codepoint distance лъже. grapheme_levenshtein() уважава видимите символи.

grapheme_levenshtein('café', 'cafe'); // 0 – visually same after accent

Search suggestions, fuzzy match и typo-tolerant login flows стават лингвистично честни.

10. Парадът на полирането

Directory Object: opendir() вече ти дава proper object (type safety, бъдещо разширяване) вместо legacy resource.

cURL Enhancements: По-добри share handles + multi-handle introspection = подобрено connection reuse в long-lived workers (мисли RoadRunner, Swoole) и по-фин performance tuning.

PHP_BUILD_DATE: Бърза проверка „колко стар е този binary?“ за audit scripts. Чудесно за гаранция, че fleet nodes не изостават тихомълком.

Cheat sheet за feature synergy

Цел	Комбинирай
Pipeline от трансформации с enforced usage	`
Declarative validation / strategy maps	Constant-expression static closures + constant attributes
По-безопасни refactor-и на legacy arrays	`array_first()/array_last()` + strict return typing
Production incident triage	По-добри fatal stack traces + `php --ini=diff` + `get_exception_handler()`
International UX polish	`IntlListFormatter` + direction detection + grapheme distance

Практичен план за приемане

Въведи Pipe Operator постепенно: започни в pure data normalization слоеве; налагай style (един side effect на опашката) в code review.
Анотирай критични APIs с #[\NoDiscard]: фокусирай се първо върху security, persistence и builders — измервай броя warnings в CI.
Refactor-ни Strategy Tables: премести простите callable maps в public const arrays със static closures за zero-boot cost.
Config Drift Checks: добави CI job, който capture-ва output-а на php --ini=diff; alert-вай при неочаквани промени.
Metadata Sweep: маркирай constants с deprecation / units / feature flags, за да захраниш internal tooling.
Array Edge Extraction Cleanup: codemod за замяна на pointer-manipulating patterns.
Error Handler Layering: обвий съществуващите global handlers чрез get_exception_handler() за observability (Sentry/new relic instrumentation).
i18n Enhancements: смени ръчния “list glue” код с IntlListFormatter; тествай RTL layout autoselection.
Fuzzy Matching Quality: където се появява user-generated multilingual text (search, tagging), benchmark-ни grapheme спрямо classic distance.
Runtime Audit Script: логвай PHP_BUILD_DATE + php --ini=diff всеки ден, за да хващаш стареещи containers.

Pitfalls & Gotchas

Item	За какво да внимаваш	Mitigation
Pipe operator misuse	Side effects по средата на pipeline	Ограничаване до pure funcs до final stage
`#[\NoDiscard]` overuse	Noise fatigue (warning blindness)	Прилагай само върху семантично критични return-и
Static closure limits	Нужен е captured context	Подай context като explicit param или factory returning closure
Constant attributes sprawl	Metadata fragmentation	Установи internal attribute naming conventions
i18n list formatting	Предположения за punctuation styling	Snapshot tests per locale

Мини playground „Show Me“

#[NoDiscard("Hash must be stored or compared")]
function password_hash_safe(string $plain): string {
    return password_hash($plain, PASSWORD_DEFAULT);
}

function sanitize_email(string $raw): string { return strtolower(trim($raw)); }

$request->string('email')
    |> sanitize_email(...)
    |> fn($email) => (strlen($email) > 5 ? $email : throw new InvalidArgumentException('Too short'))
    |> sendEmail(...); // Each stage consumes prior result – no discard.

class Rules {
    public const VALIDATORS = [
        'title' => static function(string $v){ return $v !== ''; },
        'slug'  => static function(string $v){ return (bool) preg_match('/^[a-z0-9-]+$/', $v); },
    ];
}

foreach (Rules::VALIDATORS as $field => $check) {
    if (! $check($data[$field] ?? '')) {
        throw new RuntimeException("Invalid $field");
    }
}

Кога да не посягаш към лъскавото

Една тривиална трансформация? Pipe може да е overkill; strtolower($x) още е напълно добре.
Context-heavy closures? Обикновени methods с dependency injection > static closure hacks.
Legacy codebase по средата на upgrade? Въвеждай по една възможност наведнъж, за да избегнеш cognitive churn.

Recap на mental model-а

Feature	Основен mental model
`	>`
`#[\NoDiscard]`	Налага намерена консумация (използвай или игнорирай с `(void)`)
Static closure constants	Immutable strategy registry, подготвен при load time
Attributes on constants	First-class metadata channel за tooling и policies
`array_first()/last()`	Declarative, non-mutating edge access
`php --ini=diff`	Config delta lens спрямо default baseline
`get_exception_handler()`	Introspect и wrap на global exception flow
Intl additions	Вградена locale intelligence вместо handcrafted glue
Grapheme distance	Операции върху човешки възприемани символи, не raw codepoints
Build & resource polish	Incremental standardization и introspection

Финални vibes

PHP 8.5 не крещи с paradigm shifts — шепне безмилостни ергономични победи. Комбото pipe operator + #[\NoDiscard] само по себе си ще побутне кода ти към по-ясно намерение. Добави compile-time closures и constant attributes, и framework-ите/компонентите ти започват да се усещат по-declarative, по-explicit, по-discoverable. Bam bam boom — ship it.

Твой ход: Избери една възможност (вероятно pipe-а), приложи я хирургически в малък module, измери яснотата през feedback-а в code review, после разшири. Momentum beats big-bang rewrites.

Остани игрив, refactor-вай смело и — да — пиши на твоите Taylors, когато намериш моментите „Wait, WHAT?!“.

Happy coding.

Какво е „добро“ покритие на кода? Практически наръчник

Tue, 15 Jul 2025 00:00:00 GMT

Какво е „добро“ покритие на кода? Моят практически наръчник за спиране на бъгове, без да пилеем инженерно време

Всеки път, когато пусна npm run coverage или phpunit --coverage, изскача един и същ въпрос:

„Добре... 74%. Достатъчно ли е?“

Блогосферата за софтуерна разработка крещи „100% или нищо!“. Междувременно launchdarkly.com учтиво ми напомня, че 100% изпълнен код не е същото като 100% тестван код.
Прекарал съм седмици в гонене на лъскавата метрика и още повече седмици в дебъгване на други проблеми. Това е проверената в реална работа среда, на която съм се спрял.

Защо 100% покритие е мираж

На теория 100% изпълнение на редовете значи „няма скрити бъгове“. На практика:

Намаляваща възвръщаемост: 90%→95% често удвоява test suite-а ти за едноцифрено намаляване на риска.
Фалшива увереност: тест, който извиква функция без нито един assertion, пак се брои за покритие.
Бизнес реалност: всеки допълнителен тест е време, което не отива във функции, поискани от клиентите ти.

Хората в аерокосмическата индустрия могат да се целят в 100% — там е въпрос на живот и смърт. За останалите от нас ~80% е линията 80/20. Там се събират повечето проекти след изчисляване на възвръщаемостта. testdevlab.com посочва диапазона 70-90% точно по тази причина.

Практическата таблица, която използвам

Покритие	Моят превод	Действие
100%	„Ние сме библиотека, която управлява ракети“	Приеми мъката.
90% +	„Библиотека, от която зависят много пари“	Само за модул с висок приоритет.
80%	Ship it, наблюдавай, после итерация.
60-70%	Merge gate — проваляй PR-а, ако новият код те свали под това.
< 50%	Уикенд технически дълг — първо завий към критичните пътища.

Откраднах тези числа от вътрешния наръчник на Atlassian: 60% „приемливо“, 75% „похвално“, 90% „примерно“. Работи във всяка ретроспектива.

Как стигам до 80%, без да плача (TypeScript playbook)

Jest + Istanbul директно от кутията

Праг за покритие в CI
в jest.config.js добавям:

coverageThreshold: {
  global: 80,
  '**/src/core/**': 90
}

Цели се в горещите потребителски пътища, не в Redux boilerplate logger-а.

Как стигам до 80% в Laravel (PHP playbook)

Инсталирай PCOV за скорост в dev среда, Xdebug за branch данни в CI.

PHPUnit + тези настройки по подразбиране в phpunit.xml:

<filter>
  <whitelist processUncoveredFiles="true">
    <directory suffix=".php">./src</directory>
  </whitelist>
</filter>

Mutation score > брой редове чрез Infection — така хващам редовете „покрити, но не наистина тествани“.

4 правила, по които живее екипът ми

Нов код = тестове. Diff coverage ≥ 90% преди merge.
Първо рефакторирай, после тествай. Нетестваемият код вече е дълг.
Проваляй build-а, не хората. Сваляй прага с 5% всяка година, вместо да чупиш екипи с червени dashboard-и.
Мери бъговете в production — ако покритието е 85%, но инцидентите скачат, покритието не е виновникът; assertion-ите са.

TL;DR (и за ръководители, и за recruiter-и)

Не ме питай за „магическо число“. Попитай:

Кои части от продукта не могат да се счупят?

Покрий тях до 90%. Дай на останалото здрави smoke tests. Използвай code coverage като прожектор, не като финална линия, и вярвай на бъговете, които хващаш, не на числата, с които се хвалиш.

Нека coverage dashboard-ът бъде зелен — клиентите ти никога няма да го видят, но тяхната лента с грешки ще остане празна.

— Край на rant-а, обратно към editor-а.

Моят основен наръчник за ефективни Pull Request ревюта

Sun, 06 Jul 2025 00:00:00 GMT

Като човек, който пише и ревюира много код, научих, че Pull Request (PR) ревютата са повече от проверки за бъгове - те са за споделена собственост, прехвърляне на знание и изграждане на по-добър код заедно. Ето кратък, практичен наръчник, който прави PR-ите по-ценни и по-малко болезнени.

1. Цели на доброто ревю

Фокус върху подобрение, не върху съвършенство
Съвършеният код не е реалистична цел - стреми се към по-добър код. Ако един PR подобрява четимостта, поддръжката или коректността, одобри го, дори ако остават дребни стилови неща. Използвай "Nit:" за незадължителни предложения. google.github.io
Споделена собственост и менторство
Отнасяй се към PR-ите като към общ код. Оставяй образователна обратна връзка ("Nit: тук можеш да използваш X..."), менторствай junior разработчици и бъди отворен да учиш и от тях.

2. Подготовка преди ревю

Автори: Направете self-review: пуснете тестове, линтери и форматъри. Дайте контекст в PR описанията и анотирайте сложната логика.
Ревюиращи: Прочетете първо описанието. Разберете "защо" преди да влезете в кода.

3. Дръж PR-ите малки и фокусирани

Данните показват, че качеството на ревютата пада значително отвъд ~400 LOC и ~60 минути. atlassian.com devzery.com mikeconley.ca
Насоки:

Оставай под 200-400 LOC на PR. mikeconley.ca
Дръж ревютата под 60 минути.
За големи функционалности използвай stacked PR-и (DB -> API -> UI).

4. Назначавай ревюиращите внимателно

Един основен ревюиращ, идеално с познание в домейна.
Максимум двама ревюиращи, за да се избегне размиване на отговорността. support.smartbear.com abseil.io slab.com
Ротирай ревюиращите за cross-training и здрав bus-factor.

5. Какво да проверяваш в PR

Използвай този мисловен checklist:

Коректност: Изпълнява ли изискванията и покрива ли edge case-ите?
Дизайн: Добре структуриран и идиоматичен ли е?
Четимост: Ясни имена, проста логика, консистентен стил.
Сигурност: Валидиране на input-и, sanitize на output-и, избягване на leak-ове.
Performance: Внимавай за тежки цикли и N+1 заявки.
Тестове: Покритие за основни, edge и error случаи.
Compliance: Правилни docs, CI, licensing, formatting.

Това ни помага да хващаме повече проблеми рано - особено проблеми с поддръжката. google.github.io developers.google.com google.github.io

6. Използвай автоматизацията

Остави инструментите да вършат грубата работа:

Линтери (ESLint, RuboCop, SonarQube)
Форматъри (Prettier, Black)
CI pipelines с тестове, coverage и проверки за сигурност

Това позволява на човешките ревюиращи да се фокусират върху логика, архитектура и нюанс.

7. Давай конструктивна и добра обратна връзка

Бъди уважителен - поставяй препинателни знаци на предложенията, не на хората.
Похвали добре свършеното.
Бъди приложим: обясни защо и предложи как.
Prefix-вай non-blocker-и с "Nit:" или "Optional:". atlassian.com google.github.io
Дръж дискусиите обективни ("ние" > "ти"). Избягвай лична критика.
Предложи синхронен разговор, ако back-and-forth-ът блокира процеса. atlassian.com

8. Мери процеса, не хората

Ключови метрики за следене на тенденции (не за оценяване на хора):

Turnaround time (PR open -> merge)
Inspection rate (< 300-500 LOC/hr е най-добре) atlassian.com developers.google.com mikeconley.ca
Defect density (issues per LOC)
Review coverage по компоненти
Брой follow-up commit-и

Използвай наблюденията, за да подобряваш workflow-а - например да настояваш за по-малки PR-и, по-добри docs или обучение около трудни модули - но никога не връзвай метриките с performance reviews. mikeconley.ca google.github.io bssw.io

9. Езиково-специфични съображения

Различните парадигми изискват различно внимание:

PHP/JavaScript/TS: Async handling, XSS, SOLID principles
Python: Resource management (with), PEP 8, default-arg pitfalls
Haskell/Scala functional: Type signatures, purity, immutability, macro checks
C/C++: Memory safety, pointers, RAII
Java: Null-safety, clean concurrency, SOLID
Lisp: Macro documentation, dynamic typing, idiomatic patterns

Адаптирай checklist-ите според stack-а си и включвай експерти за непознати езици.

Bonus: Препоръчани източници за по-дълбоко четене

Google’s The Standard of Code Review - Философия за здравето на кода и менторството. google.github.io
Google Code Review Developer Guide - Насоки в checklist стил. bssw.io
SmartBear/Cisco study - Емпирични изводи за размера и времето на PR-ите. mikeconley.ca
Atlassian "5 Code Review Best Practices" - Практични съвети за стил и екипна работа. atlassian.com
Blockly PR Flow - Реален staged review процес. developers.google.com

Финални мисли

Когато са направени както трябва, PR ревютата са повече от quality gates - те са двигатели за учене, сътрудничество и инженерно майсторство. Като комбинираме уважителна култура, умни инструменти, процес, информиран от данни, и внимателна обратна връзка, code reviews се превръщат в смислени разговори - не в досадни задължения.

Приятно ревюиране!

Остави коментар или ми пиши, ако искаш да влезем по-дълбоко или да споделиш свои съвети за ревюта!

Засичане на пушене с Apple Watch: как изграждам Still Mirror (Swift, SWT)

Tue, 13 May 2025 00:00:00 GMT

Идеята да разбираме истински навиците си, особено онези, които извършваме почти несъзнателно, винаги ме е вълнувала. Ами ако носимите ни устройства можеха да ни предложат меко, неосъдително огледало за тези модели? Този въпрос запали проекта "Still Mirror": опит да се засичат пасивно събития на пушене или вейпване чрез богатите физиологични данни от Apple Watch, без потребителят да въвежда нищо ръчно. Това не е опит да се построи поредното приложение за отказване, а инструмент за чисто, неподправено осъзнаване.

Предизвикателството: шепот в симфония от шум

Основното предизвикателство е огромно: как различаваш фината физиологична следа на пушене/вейпване от безбройните други ежедневни дейности и телесни реакции? Стрес, бърза разходка, стряскащ шум или дори чаша кафе могат да причинят краткотрайни промени в сърдечната честота (HR) и вариабилността на сърдечната честота (HRV). Сигналът, който търсим, често е шепот в симфония от физиологичен шум.

Но за да изолирам истински тези мимолетни събития, ми трябваше по-сложна техника за обработка на сигнали.

Фиг. 1. – Екосистемата за Apple разработка: Xcode, Swift и HealthKit са в центъра на оживяването на 'Still Mirror' върху Apple Watch.

Избор на инструментариум: Apple екосистема и Swift

За проект, насочен към Apple Watch, изборът на екосистема е ясен:

Xcode и Swift: Нативната среда за разработка за Apple платформи. Това означаваше да навляза по-дълбоко в Swift, език, който намирам за елегантен и мощен, и да се оправям с особеностите на Xcode.
HealthKit: Framework-ът на Apple е входът към основните потоци от данни: сърдечна честота, HRV (SDNN/RMSSD), SpO2 (особено релевантно при горене спрямо вейпване) и нива на активност. Privacy-centric дизайнът на HealthKit е ключов за приложение, което работи с толкова чувствителни данни.
Ограничения на watchOS: Разработката за часовника означава постоянно балансиране между функционалност и ресурсни ограничения - батерията и възможностите за background processing винаги са на преден план.

Алгоритмичното сърце: стационарна уейвлет трансформация (SWT)

Традиционният анализ на времеви редове често се затруднява с нестационарни сигнали - сигнали, чиито статистически свойства (като средна стойност и дисперсия) се променят във времето. Физиологичните данни са пословично нестационарни. Тук влиза в игра Stationary Wavelet Transform (SWT).

За разлика от стандартната Discrete Wavelet Transform (DWT), която е shift-variant (тоест малко изместване във входния сигнал може драматично да промени уейвлет коефициентите), SWT е shift-invariant. Това я прави по-устойчива при анализ на сигнали, където точният момент на събитията е критичен, но може леко да варира.

Защо SWT за този проблем?

Time-Frequency Localization: SWT може да разложи сигнал на различни честотни ленти, като запази времевата информация. Това означава, че можем да търсим конкретни честотни характеристики (например внезапни изблици на високочестотна активност в HR или специфични промени в HRV честотни ленти), които се случват в точни моменти.
Denoising: Физиологичните сигнали са шумни. SWT може да помогне да отделим подлежащия "истински" сигнал от случайния шум чрез анализ на уейвлет коефициенти на различни мащаби.
Засичане на преходни събития: Тя е особено добра в разпознаването на резки промени, пикове или преходни събития в сигнал - точно това, което бихме очаквали от острата физиологична реакция към прием на никотин.

Фиг. 2. – Визуализация на Stationary Wavelet Transform, която разлага сигнал на съставните му честотни компоненти във времето и помага за разпознаване на модели.

По същество SWT действа като сложен набор от филтри, който ни позволява да "видим" модели в HR, HRV и потенциално SpO2 данните, които иначе могат да бъдат скрити от шум или дългосрочни тенденции. Можем да търсим характерни "форми" или промени в енергията в конкретни уейвлет подленти, които съответстват на физиологичния тласък.

Пътят на разработката: от данни към засичане

Събиране на данни (HealthKit): Настройване на надеждно фоново извличане на данни от HealthKit, с уважение към потребителските разрешения и ефективна обработка на обновленията.
Предварителна обработка на сигнала: Почистване на входящите HR, HRV и SpO2 данни. Това включва обработка на липсващи точки и вероятно начално филтриране преди прилагане на SWT.
Прилагане на SWT: Прилагане на Stationary Wavelet Transform върху сегменти от физиологичните времеви редове. Това включва избор на подходящ mother wavelet (например Daubechies, Symlet) и ниво на разлагане.
Извличане на признаци от уейвлет коефициенти: Тук се случва магията (и много експериментиране). Вместо да гледаме директно суровите HR/HRV стойности, анализираме SWT коефициентите. Релевантни признаци могат да бъдат:
- Енергия в конкретни ленти на detail coefficients около момента на подозирано събитие.
- Статистически свойства (дисперсия, ексцес) на коефициентите.
- Cross-correlation между уейвлет коефициенти на различни физиологични сигнали (например HR и HRV).
Логика/модел за засичане: В началото това може да бъде rule-based система, която търси конкретни модели в извлечените уейвлет признаци (например "значим energy spike в HR detail coefficients при scale X, съвпадащ с рязък спад в energy в HRV detail coefficients при scale Y, по време на период с ниска физическа активност"). С времето това може да се развие в machine learning модел, обучен върху тези признаци.
Оценка на увереност: Както е описано в моя MVPS алгоритъм, генерирането на confidence score за всяко засечено събитие е ключово, защото отразява силата и яснотата на сигнатурата.
Имплементация на watchOS приложението: Изпълнение на основния алгоритъм за засичане върху Apple Watch, с оптимизация за батерия (например обработка на данни на batch-ове, интелигентно задействане на анализ).
iOS companion app: За показване на timeline на засечените събития, предоставяне на insights и управление на настройките. Синхронизацията на данни чрез WatchConnectivity е ключова тук.

Здравни и етични съображения: философията на "огледалото"

Важно е да повторя, че "Still Mirror" е замислен като инструмент за осъзнаване, не като медицинско устройство или програма за отказване.

Privacy first: Цялата обработка, особено чувствителната алгоритмична работа, в идеалния случай трябва да се случва on-device. Достъпът до HealthKit данни е строго permission-based.
Без осъждане: Интерфейсът на приложението и всякакви insights, които предоставя, трябва да бъдат неутрални - просто да отразяват модели без предписващи съвети или засрамване.
Точност и прозрачност: Потребителите трябва да разбират ограниченията на приложението. False positives и false negatives са неизбежни при толкова сложно пасивно засичане. Прозрачността за увереността на засичанията е важна.
Овластяване на потребителя: Целта е да дадем на хората данни за собствените им тела и навици, за да могат сами да вземат информирани решения.

Учене на Swift и навигация в Apple екосистемата

За разработчици, които идват основно от други среди (като моите PHP/Laravel корени), навлизането в Swift, SwiftUI, Xcode и конкретните ограничения на watchOS разработката е сериозна крива на учене. Framework-ите на Apple имат своя специфична философия. Управлението на жизнения цикъл на приложенията, background tasks, HealthKit queries и комуникацията между устройства (WatchConnectivity) имат свои модели и "Apple начини" за правене на нещата. Въпреки това богатата документация, силната общност и мощта на Swift правят пътуването възнаграждаващо.

Заключение: потенциалът на един мълчалив наблюдател

"Still Mirror" все още е изследване - трудно начинание, което опитва да разшири границите на това, което пасивното sensing върху потребителско wearable устройство може да постигне. Stationary Wavelet Transform предлага обещаващ път за разрязване на сложни физиологични сигнали и откриване на фините сигнатури, които търсим.

Пътят включва не само писане на Swift и борба с Xcode, но и навлизане в теория на обработката на сигнали, разбиране на човешката физиология и внимателно обмисляне на етичните последици от такава технология. Независимо дали "Still Mirror" ще стане широко използвано приложение, или ще остане сложна техническа експедиция, самият процес е свидетелство за увлекателното пресичане на AI, здраве и лична технология. Става дума за опит да се построи онази тиха, отразяваща повърхност - неподвижно огледало - за по-дълбоко самоосъзнаване.

Какво мислите за използването на advanced signal processing като SWT за пасивно засичане на навици? Ще се радвам да чуя вашите мисли в коментарите по-долу!

Поправяне на Bluetooth в Android Emulator на M1 Mac с Bumble и API 32

Mon, 14 Apr 2025 00:00:00 GMT

Ако разработвате с Bluetooth на M1/M2/M3 Mac и се опитвате да накарате Bluetooth радиото на хост машината да работи вътре в Android Emulator, вероятно вече сте усетили болката. Нещо, което изглежда сякаш трябва да е право напред, често се превръща в дразнеща дупка от неуспешни връзки, криптични грешки и документационни задънени улици. Наскоро минах през точно тази битка и след няколко стени най-сетне намерих комбинация с Python Bluetooth стека Bumble, която наистина работи.

Това не е поредното теоретично ръководство; това е разказ стъпка по стъпка за това какво се провали и, по-важното, какво успя при свързването на Bluetooth-а на моя M1 Mac Pro (в моя случай през външен USB dongle, но принципът може да важи и за вътрешни радиа) към Android 12L (API 32) emulator.

Целта: истински Bluetooth в емулатора

Целта беше проста: Android Emulator да използва физическия Bluetooth controller на моя Mac вместо собствения си ограничен виртуален controller. Това е решаващо за тестване на приложения, които взаимодействат с реални Bluetooth устройства.

Инструментът: Bumble влиза в кадър

Bumble е мощен Python Bluetooth stack. Ключовият му инструмент за тази задача е bumble-hci-bridge, който може от едната страна да се свърже с физически HCI (Host Controller Interface), а от другата да го изложи през различни transports (като TCP или gRPC).

Опит #1: QEMU socket методът (логичният първи опит)

На база общи познания за QEMU и някои по-стари ръководства първият подход беше да използвам emulator flags, за да свържа директно виртуален serial port (подпрян от TCP socket) към HCI bridge.

Стартиране на bridge-а (TCP server mode): Свързахме Bumble към физическия dongle (който изненадващо работеше по-добре с usb:0, отколкото с конкретния му VID:PID usb:0b05:17cb на моята машина - M1 особености!) и го накарахме да слуша на TCP port.
```
# In Terminal 1:
sudo python3 -m bumble.apps.hci_bridge usb:0 tcp-server:0.0.0.0:6789
# Output showed '>>> connected' twice - success connecting to USB and starting TCP server.
```
Стартиране на емулатора с QEMU flags: Променихме emulator launch script-а (първоначално за API 34), за да добавим -qemu flags, които насочват virtual serial port (virtserialport) към character device (chardev), подпряно от TCP socket, свързващ се към bridge-а.
```
# Snippet from launch script:
emulator -avd <avd_name> ... \
    -qemu \
    -device virtio-serial-device \
    -device virtserialport,chardev=bt,name=bt \
    -chardev socket,id=bt,host=localhost,port=6789 \
    ...
```
Резултатът? Частичен успех, окончателен провал: С lsof виждахме, че QEMU процесът на емулатора наистина установи TCP връзка към Bumble bridge-а! Android Bluetooth stack-ът вътре в емулатора обаче така и не изпрати HCI commands през нея. Включването и изключването на Bluetooth в Android settings не правеше нищо. Bridge logs останаха тихи след първоначалната връзка. Задънена улица.

Опит #2: Default Netsim bridge (следвайки Bumble docs)

Документацията на Bumble споменава bridging към "Netsim" gRPC interface-а на емулатора. Netsim (и неговото ядро Root Canal) е по-новата система на емулатора за virtual Bluetooth controller.

Стартиране на bridge-а (Netsim controller mode): Настроихме bridge-а да действа като Netsim controller, да слуша на default gRPC port (8554) и да се свърже с физическия dongle.
```
# In Terminal 1:
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
# Output showed '>>> connected' twice - success connecting to USB and starting Netsim gRPC server.
```
Стартиране на емулатора (default backend): Върнахме launch script-а (все още опитвайки с API 34), махнахме -qemu flags и добавихме -packet-streamer-endpoint default, за да сме сигурни, че се опитва да използва Netsim backend-а.
```
# Snippet from launch script:
emulator -avd <avd_name> ... \
    -packet-streamer-endpoint default \
    ...
```
Резултатът? Няма връзка: Този път емулаторът тръгна, но Bumble bridge-ът не показа никакви признаци за входяща gRPC връзка от емулатора. Прегледът на emulator logs не разкри очевидни connection errors, но Bluetooth остана неизползваем. Още една задънена улица.

Опит #3: API downgrade + explicit Netsim endpoint (победителят!)

Fig1. - Сюрреалистичен пейзаж, в който провалени network cables висят между Apple и Android скални формации, докато един-единствен мост от въжета с Bumble branding успешно свързва двете страни и позволява на светещи data packets да прекосят пропастта.

Web searches разкриха общи reports за нестабилност с Bluetooth на API 33/34 емулатори и потенциални проблеми с това как емулаторът открива или се свързва с Netsim backend-а, особено когато външен инструмент се опитва да го прихване. Ключът изглежда беше изрично да кажем на емулатора къде е Netsim gRPC server-ът и да пробваме по-стар API level.

Стартиране на bridge-а (Netsim controller mode, explicit port, usb:0): Същото като в Опит #2, като се уверим, че слуша на известен port (8554) и се свързва с физическия dongle чрез index-а (usb:0), който работеше надеждно.
```
# In Terminal 1: (Keep this running!)
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
```
Промяна и стартиране на емулатора (API 32, explicit endpoint): Създадохме API 32 (Android 12L) AVD с Google Play Services (gplay_32_arm). Променихме launch script-а да target-ва този AVD и, решаващо, сменихме -packet-streamer-endpoint flag-а от default към точния address на нашия bridge.
```
# Snippet from the *successful* launch script (see full script below):
API_LEVEL="32"
AVD_NAME="gplay_${API_LEVEL}_arm"
SYSTEM_IMAGE_PKG="system-images;android-${API_LEVEL};${IMAGE_TAG};${ARCH}"
BUMBLE_NETSIM_GRPC_PORT="8554"
...
emulator -avd "$AVD_NAME" ... \
    -packet-streamer-endpoint "localhost:$BUMBLE_NETSIM_GRPC_PORT" \
    ...
```
Резултатът? Успех! Този път проработи!
- Терминалът с bumble-hci-bridge започна да показва gRPC connection logs от емулатора малко след launch-а.
- След като емулаторът boot-на, включването на Bluetooth ON в Android Settings доведе до поток от HCI commands (Reset, Read Version, Set Event Mask и т.н.) в bridge terminal-а.
- Scanning за устройства вътре в емулатора успешно използва физическото Bluetooth radio на Mac през ASUS dongle-а!

Печелившата рецепта: стъпка по стъпка

Ето точната процедура, която проработи на моя M1 Mac Pro с външен ASUS USB-BT500 dongle:

Инсталирайте Bumble:

python3 -m pip install bumble
# Potentially install libusb if needed: brew install libusb

(По желание, но препоръчително) Изключете native USB BT handling-а на macOS: Пуснете веднъж и reboot.
```
sudo nvram bluetoothHostControllerSwitchBehavior="never"
```
Стартирайте Bumble Netsim bridge-а: Отворете terminal и пуснете (оставете го да работи):
```
sudo python3 -m bumble.apps.hci_bridge android-netsim:_:8554,mode=controller usb:0
```
(Проверете, че показва >>> connected два пъти).
Подгответе emulator launch script-а: Запазете пълния script, даден по-долу, като launch_gapps_avd_api32.sh (или подобно). Уверете се, че target-ва API 32 AVD (ще създаде такъв с име gplay_32_arm, ако не съществува) и изрично използва -packet-streamer-endpoint localhost:8554. Направете го executable (chmod +x launch_gapps_avd_api32.sh).
Пуснете launch script-а: Отворете нов terminal и изпълнете script-а:
```
./launch_gapps_avd_api32.sh
```
Проверете: След като емулаторът boot-не:
- Проверете bumble-hci-bridge terminal-а за gRPC и HCI traffic.
- Отидете в Android Settings -> Bluetooth и го включете ON.
- Пробвайте scanning или pairing.

Успешният launch script (API 32, explicit Netsim endpoint)

#!/bin/bash

# Script to setup and launch a Google Play Android emulator (API 32) on macOS M1/ARM64
# Uses explicit Netsim endpoint for Bumble bridge compatibility.

set -e # Exit immediately if a command exits with a non-zero status.

# --- Configuration ---
API_LEVEL="32" # Target Android API Level (Android 12L)
AVD_NAME="gplay_${API_LEVEL}_arm" # Name for the Android Virtual Device
IMAGE_TAG="google_apis_playstore" # Image type with Google Play Store
ARCH="arm64-v8a" # Architecture for Apple Silicon
SYSTEM_IMAGE_PKG="system-images;android-${API_LEVEL};${IMAGE_TAG};${ARCH}"
DEVICE_DEF="pixel_6a" # A common modern Pixel device definition
BUMBLE_NETSIM_GRPC_PORT="8554" # Port where bumble-hci-bridge Netsim controller is listening

# --- Find Android SDK ---
ANDROID_SDK_ROOT="${ANDROID_HOME:-${ANDROID_SDK_ROOT:-$HOME/Library/Android/sdk}}"

if [ ! -d "$ANDROID_SDK_ROOT" ]; then
    echo "❌ Error: Android SDK not found at '$ANDROID_SDK_ROOT'" >&2
    echo "   Please install Android Studio or set ANDROID_HOME/ANDROID_SDK_ROOT." >&2
    exit 1
fi
echo "▶️ Using Android SDK at: $ANDROID_SDK_ROOT"

# --- Define Tool Paths ---
CMDLINE_TOOLS_BIN="$ANDROID_SDK_ROOT/cmdline-tools/latest/bin"
PLATFORM_TOOLS_DIR="$ANDROID_SDK_ROOT/platform-tools"
EMULATOR_DIR="$ANDROID_SDK_ROOT/emulator"

SDKMANAGER="$CMDLINE_TOOLS_BIN/sdkmanager"
AVDMANAGER="$CMDLINE_TOOLS_BIN/avdmanager"
EMULATOR="$EMULATOR_DIR/emulator"
ADB="$PLATFORM_TOOLS_DIR/adb"

# --- Check Essential Tools ---
if ! command -v sdkmanager &> /dev/null; then echo "❌ Error: sdkmanager not found. Check SDK Command-line Tools installation and PATH." >&2; exit 1; fi
if ! command -v avdmanager &> /dev/null; then echo "❌ Error: avdmanager not found. Check SDK Command-line Tools installation and PATH." >&2; exit 1; fi
if ! command -v emulator &> /dev/null; then echo "❌ Error: emulator not found. Check Android Emulator installation and PATH." >&2; exit 1; fi
if ! command -v adb &> /dev/null; then echo "❌ Error: adb not found. Check SDK Platform-Tools installation and PATH." >&2; exit 1; fi
echo "✅ Basic SDK tools found in PATH."

# --- Stop Currently Running Emulators ---
echo "▶️ Stopping any currently running emulators..."
RUNNING_EMULATORS=$(adb devices | grep 'emulator-' | cut -f1)
if [ -n "$RUNNING_EMULATORS" ]; then
    for emu_id in $RUNNING_EMULATORS; do
        echo "   Stopping $emu_id..."
        adb -s "$emu_id" emu kill || echo "   (Failed to kill $emu_id, may already be stopped)"
        sleep 1 # Small delay
    done
    # Give ADB server time to recognize disconnection
    sleep 3
    echo "   Emulators stopped."
else
    echo "   No emulators appear to be running according to 'adb devices'."
fi
echo "✅ Emulator check/stop finished."


# --- Install/Update Required SDK Packages ---
echo "▶️ Ensuring required SDK packages are installed..."
# Accept licenses non-interactively
yes | sdkmanager --licenses > /dev/null || echo "   (Ignoring potential license script errors)"

# Install platform-tools, emulator
sdkmanager "platform-tools" "emulator"

# Install the Google Play system image for API 32
echo "▶️ Attempting to install/update Google Play system image: $SYSTEM_IMAGE_PKG"
if ! sdkmanager "$SYSTEM_IMAGE_PKG"; then
    echo "❌ Error: Failed to install required system image '$SYSTEM_IMAGE_PKG'." >&2
    echo "   Please check available images using: sdkmanager --list | grep 'system-images;android-${API_LEVEL};.*${ARCH}'" >&2
    exit 1
fi
echo "✅ System image package '$SYSTEM_IMAGE_PKG' present."

# --- Check if AVD Exists, Create ONLY if Missing ---
echo "▶️ Ensuring AVD '$AVD_NAME' exists..."
if ! avdmanager list avd --compact | grep -q "^${AVD_NAME}$"; then
    echo "   AVD '$AVD_NAME' not found. Creating..."
    # Using 'echo no' usually prevents hardware profile creation prompts. Pipe empty string for potential licenses.
    echo "" | avdmanager create avd --force --name "$AVD_NAME" --package "$SYSTEM_IMAGE_PKG" --device "$DEVICE_DEF" --sdcard 512M || {
         echo "❌ Error: Failed to create AVD '$AVD_NAME'." >&2
         echo "   Maybe the device definition '$DEVICE_DEF' is invalid for this image?" >&2
         echo "   Check available devices: avdmanager list device" >&2
         exit 1
    }
    echo "✅ AVD '$AVD_NAME' created."
else
    echo "✅ AVD '$AVD_NAME' already exists. Will reuse."
fi


# --- Launch Emulator ---
echo "▶️ Launching existing/new emulator: '$AVD_NAME' (pointing to Bumble Netsim bridge on localhost:$BUMBLE_NETSIM_GRPC_PORT)..."
EMULATOR_LOG="emulator-$AVD_NAME.log" # Log file name updated for API 32 AVD
# Google Play images often need a writable system partition
# Explicitly point packet streamer to localhost:8554 where bridge is listening
nohup emulator -avd "$AVD_NAME" -no-snapshot-load -gpu auto -show-kernel -writable-system \
    -packet-streamer-endpoint "localhost:$BUMBLE_NETSIM_GRPC_PORT" \
    > "$EMULATOR_LOG" 2>&1 &
EMULATOR_PID=$!
echo "   Emulator starting in background (PID: $EMULATOR_PID). Log: $EMULATOR_LOG"
echo -n "   Waiting for emulator to appear in ADB..."

# Wait for the emulator device to show up in adb
WAIT_ADB_TIMEOUT=90 # Increase timeout slightly for GPlay images
SECONDS=0
EMULATOR_ID="" # Reset variable
while [ $SECONDS -lt $WAIT_ADB_TIMEOUT ]; do
    # Find the *new* emulator ID
    CURRENT_EMU_ID=$(adb devices | grep 'emulator-' | head -n 1 | cut -f1)
    if [ -n "$CURRENT_EMU_ID" ]; then
        EMULATOR_ID="$CURRENT_EMU_ID"
        echo " Found ($EMULATOR_ID)!"
        break
    fi
    sleep 2
    SECONDS=$((SECONDS + 2))
    echo -n "."
done

if [ -z "$EMULATOR_ID" ]; then
    echo ""
    echo "❌ Error: Emulator did not appear in ADB within $WAIT_ADB_TIMEOUT seconds." >&2
    echo "   Check logs: $EMULATOR_LOG" >&2
    # Try to kill the process if it's still lingering
    kill $EMULATOR_PID 2>/dev/null || echo "   (Emulator process $EMULATOR_PID may have already exited)"
    exit 1
fi


# --- Wait for Boot Completion ---
echo -n "▶️ Waiting for Android system to fully boot (Google Play images can take longer)..."
BOOT_TIMEOUT=240 # Increase timeout significantly for GPlay images
SECONDS=0
while [ $SECONDS -lt $BOOT_TIMEOUT ]; do
    # Check if device is online first
    DEVICE_STATE=$(adb -s "$EMULATOR_ID" get-state 2>/dev/null)
    if [ "$DEVICE_STATE" != "device" ]; then
       echo -n "s($DEVICE_STATE)" # State not ready
       sleep 5
       SECONDS=$((SECONDS + 5))
       continue
    fi

    # Check boot completed property
    BOOT_COMPLETED=$(adb -s "$EMULATOR_ID" shell getprop sys.boot_completed 2>/dev/null | tr -d '
')
    if [ "$BOOT_COMPLETED" = "1" ]; then
        # Double check package manager is ready too for GPlay images
        PM_READY=$(adb -s "$EMULATOR_ID" shell pm get-install-location 2>/dev/null)
        if [[ "$PM_READY" == *"0"* || "$PM_READY" == *"1"* || "$PM_READY" == *"2"* ]]; then # Check if pm command gives valid output
            echo " Booted!"
            break
        else
            echo -n "p(pm not ready)" # Package Manager not ready
        fi
    else
         echo -n "b(booting)" # Boot not completed
    fi
    sleep 5
    SECONDS=$((SECONDS + 5))
done

if [ $SECONDS -ge $BOOT_TIMEOUT ]; then
    echo ""
    echo "❌ Error: Android system did not fully boot within $BOOT_TIMEOUT seconds." >&2
    echo "   Emulator might be stuck. Check logs ($EMULATOR_LOG) or try launching manually." >&2
    # Don't exit here, user might want to interact with stuck emulator
fi


# --- Final Instructions ---
echo "---"
echo "✅ Google Play Emulator '$AVD_NAME' (API $API_LEVEL) ($EMULATOR_ID) should be running."
echo "   Bluetooth should be using the Netsim backend at localhost:$BUMBLE_NETSIM_GRPC_PORT (intercepted by Bumble)."
echo "   Connect shell:   adb -s $EMULATOR_ID shell"
echo "   Install APK:     adb -s $EMULATOR_ID install /path/to/your.apk"
echo "   Stop emulator:   adb -s $EMULATOR_ID emu kill"
if [ -n "$EMULATOR_PID" ]; then # Only show PID if we launched it
    echo "   Kill Process:    kill $EMULATOR_PID"
fi
echo "   NOTE: Google Play Services may need updates inside the emulator."
echo "---"

exit 0

Ключови изводи за M1 Mac + Emulator + Bumble

API level има значение: По-новото не винаги е по-добро за emulator compatibility, особено при сложни features като Bluetooth bridging. API 32 изглеждаше по-стабилен за това от API 34 в моите тестове.
Explicit endpoints: Не разчитайте на -packet-streamer-endpoint default, когато използвате външен bridge като Netsim controller mode-а на Bumble. Насочете емулатора изрично към localhost:<port>, където bridge-ът слуша.
Netsim bridge > QEMU socket: android-netsim bridge mode изглежда по-вероятно да работи с modern emulators от по-нисконивовия -qemu -chardev socket метод, въпреки че socket методът може да установи TCP link.
usb:0 срещу VID:PID: На macOS/M1 идентифицирането на USB devices може да е странно. Ако посочването на точния VID:PID се провали неочаквано, пробвайте да използвате index-а usb:0 (ако приемем, че това е primary/intended device-ът).
Упоритостта се отплаща: Това отне няколко опита, комбинирайки insights от документация, web searches и iterative testing. Не се отказвайте твърде лесно!

Надявам се споделянето на тази конкретна, работеща конфигурация да спести на други разработчици часове раздразнение. Happy coding (and bridging)!

AI редизайн на блог: как Claude Code преобрази Gatsby сайта ми

Sat, 12 Apr 2025 00:00:00 GMT

Като разработчик, който прекарва повечето си време в backend-а, винаги съм се борил с дизайна. Личният ми блог беше функционален, но изглеждаше сякаш е заседнал в 2010 - базов styling, непоследователни отстояния и цветова схема, която щедро можеше да бъде описана като "минимална". От месеци се канех да го преработя, но мисълта да се гмурна в CSS и дизайн системи ми докарваше кошмари.

После пробвах Claude Code, AI coding assistant-а на Anthropic, и перспективата ми напълно се промени.

Предизвикателството: моят тъжен, остарял блог

Блогът ми е построен с Gatsby.js и макар съдържанието да беше стабилно, представянето го дърпаше надолу:

Непоследователни отстояния из целия сайт
Слабо responsive поведение на мобилни устройства
Имплементация на тъмен режим, която едва работеше
Типография, която изглеждаше аматьорска в най-добрия случай
Липса на цялостна цветова система или дизайн език

Имах смътна идея какво искам: нещо модерно, чисто и професионално, което да остави съдържанието ми да изпъкне. Но да преведа тази визия в истински CSS? Там обикновено удрям стената.

Влиза Claude Code: моят виртуален дизайн партньор

Бях чувал за Claude Code от известно време, но бях скептичен колко много AI наистина може да помогне с дизайн работа. Все пак дизайнът изисква вкус и око за естетика, не само технически знания.

Реших въпреки това да му дам шанс, с прост prompt: "Please improve my styling by a ton." Бях готов да инвестирам един час от времето си и около $15, колкото щеше да струва API usage-ът, за да видя какво е възможно.

Това, което се случи после, искрено ме изненада.

Процесът на трансформация

Вместо просто да предложи няколко CSS tweak-а, Claude Code подходи към редизайна с педантичността на професионален разработчик:

Фаза на анализ: Първо разгледа съществуващите ми стилове, архитектурата на компонентите и цветовата схема, за да разбере с какво работи.
Създаване на дизайн система: Вместо да прави повърхностни промени, изгради цялостна дизайн система, включително:
- Професионална цветова палитра със semantic variables за светъл и тъмен режим
- Модернизирана типографска скала с правилни responsive настройки
- Последователна система за отстояния, базирана на 4px grid
- Стандартизирани сенки, border radiuses и transitions
Преработка на компонентите: Пренаписа компонентите ми така, че да следват modern best practices:
- Създаде responsive card-based layout за blog posts
- Имплементира sticky header с backdrop blur ефекти
- Проектира елегантен theme toggler
- Добави правилна навигация с active states
Подобрения в достъпността: Claude Code не просто направи нещата по-красиви - направи сайта ми по-достъпен:
- Добави правилна поддръжка за keyboard navigation
- Имплементира skip-to-content link
- Осигури достатъчен цветови контраст
- Добави правилни ARIA labels
Оптимизация на performance-а: Кодът беше оптимизиран за performance:
- Селективно импортира само необходимите Bootstrap компоненти
- Оптимизира организацията на CSS
- Добави hardware-accelerated animations

Резултатите, които ми взеха ума

Трансформацията беше смайваща. За около час разговор напред-назад и само $15 разходи за Claude API, блогът ми премина от визия на developer side project към професионално проектирано издание. Редизайнът включваше:

Изтънчена цветова система с правилна поддръжка на тъмен режим
Красива типография, която се мащабира перфектно между устройствата
Професионални card layouts за blog posts
Плавни animations и transitions
Sticky header със стъклени ефекти
Последователни отстояния из целия сайт

За контекст: да наема професионален web designer за това ниво работа вероятно би струвало $1,000-2,000 и би отнело дни или седмици комуникация напред-назад. Вместо това похарчих един час от времето си и $15 в API разходи.

Но това, което ме впечатли най-много, не беше само визуалното подобрение или спестените пари - беше качеството на кода. Claude Code не просто нахвърля някакви CSS hacks; той създаде цялостна, поддържаема дизайн система, върху която лесно мога да надграждам.

Какво научих за AI-assisted design

Това преживяване промени перспективата ми за това какво може да прави AI за разработчиците:

AI е много добър в систематичното мислене: Claude Code не просто направи нещата "по-красиви" - той създаде цялостна система с променливи, последователни patterns и правилна организация.
Запълва празнини в знанията: Като човек без дълбока CSS експертиза, Claude Code запълни празнините в знанията ми с modern best practices, които нямаше да знам, че трябва да имплементирам.
Кодът е production-quality: Styling framework-ът, който създаде, не е само за показ - това е поддържаем, разширяем код, който следва всички модерни стандарти.
Запази съдържанието и структурата ми: Claude Code подобри дизайна, като запази основната структура и съдържанието на блога ми.

Бъдещето на collaboration-а между разработчици и AI

Моят опит подчерта нещо важно: Claude Code не заменя разработчиците - той разширява способностите ни. Помогна ми да преодолея личните си ограничения във frontend design, като същевременно ме остави да контролирам общата посока.

За разработчици, които са по-силни в едни области, отколкото в други (а това не сме ли всички?), AI assistants като Claude Code могат да помогнат да запълним празнините в skill sets-а си.

Пробвай го сам

Ако се бориш с дизайн или с друг аспект на development-а, силно препоръчвам да дадеш шанс на Claude Code. Преживяването промени не само блога ми, а и усещането ми за това какво е възможно с AI-assisted development.

Пробвал ли си Claude Code или подобни AI coding assistants? Ще се радвам да чуя за твоя опит в коментарите долу.

Бележка: Самият този блог беше редизайниран с Claude Code, така че това, което виждаш сега, е резултатът от процеса, който описах. Трансформацията от предишния ми дизайн до сегашния отне около час prompting и iteration и струваше приблизително $15 в Claude API usage. Като вземеш предвид традиционните дизайн разходи, това е невероятно value proposition.

Huawei Watch D2 BLE Pairing: случай за протокол и vendor lock-in

Fri, 11 Apr 2025 00:00:00 GMT

TL;DR: Huawei Watch D2 не използва стандартно BLE pairing. Вместо това изисква 11-стъпков proprietary handshake с custom GATT characteristics, HMAC-SHA256 key derivation от QR code и application-level encryption. Това е vendor lock-in по дизайн -- принуждава те да влезеш в Huawei Health app-а. Добрата новина: community-то вече го reverse-engineer-на. Gadgetbridge вече поддържа Watch D2, а open-source имплементации като huawei-lpv2 съществуват. EU DMA също започва да натиска в обратната посока.

Очаквах стандартно Bluetooth pairing. Connect, bond, exchange data -- обичайното. Вместо това получих proprietary cryptographic handshake, който отне седмици reverse-engineering.

Това се случи, докато строях D2Explorer -- моят проект за свързване на Huawei Watch D2 към Linux и macOS без Huawei Health app-а. След като оправих проблемите с BlueZ pairing agent-а и минах към cross-platform библиотеката SimpleBLE, мислех, че трудната част е приключила. Трудната част още не беше започнала.

Какво би очаквал: стандартно BLE Pairing

Ето как Bluetooth LE pairing би трябвало да работи:

Сканираш за устройството по advertised name (например "HUAWEI WATCH D2-CA0").
Свързваш се с peripheral.connect().
OS-ът управлява pairing/bonding -- PIN prompt, Just Works, каквото изисква security level-ът.
След bonding-а работиш със standard или custom GATT services.

OS-ът управлява security-то. Твоето приложение се фокусира върху data. Просто.

Какво всъщност става: 11-стъпков Proprietary Handshake

Това, което Watch D2 всъщност изисква, е съвсем различно. Базовата BLE връзка е само вратата. Зад нея има custom application-level authentication protocol, който Huawei е построил върху standard BLE -- това, което community-то нарича Huawei Link Protocol v2 [1].

Standard BLE pairing mechanisms се заобикалят изцяло. За да се authenticate-неш и да получиш достъп до каквито и да било смислени данни, трябва да минеш през тази sequence върху custom GATT characteristics:

Connect -- установяваш basic BLE link.
Enable Notifications -- веднага се subscribe-ваш за notifications върху characteristic 0000fe02-.... Това е timing-critical -- изпуснеш ли прозореца, часовникът те drop-ва.
GetLinkParams -- веднага изпращаш custom command (Service ID 0x0001, Command ID 0x0001) към write characteristic 0000fe01-....
Receive Server Nonce -- чакаш notification, който съдържа random challenge-а на часовника.
Derive Secret Key -- генерираш client nonce. Комбинираш server nonce, client nonce и numeric value от QR code-а на часовника. Пускаш HMAC-SHA256 (с bytes от QR code value-то като key), за да derive-неш shared secretKey_.
AuthRequest -- изпращаш client nonce и HMAC digest (с derived secretKey_) обратно към часовника (Service 0x0001, Command 0x0002).
Verify Server Token -- получаваш authentication token-а на часовника. Проверяваш го със secretKey_ и обменените nonces.
SetTime -- изпращаш current time и timezone offset, encrypted със secretKey_ (Service 0x0002, Command 0x0003).
QrToken -- изпращаш QR code value-то обратно, encrypted със secretKey_ (Service 0x0001, Command 0x0004).
AuthResult -- изпращаш final confirmation, encrypted със secretKey_ (Service 0x0001, Command 0x0005).
Done -- едва сега connection-ът е authenticated.

Custom TLV message formats. CRC checks. Service and command IDs. Application-level encryption. Timing, чувствителен до милисекунди. Всичко това се случва над BLE stack-а, невидимо за standard Bluetooth tools.

QR code-ът на екрана на часовника е shared secret-ът. Без него не можеш да derive-неш key-а. Без key-а не можеш да се authenticate-неш. Без authentication часовникът не ти дава нищо.

Защо Huawei прави това

Huawei може да го рамкира като enhanced security. Практическият ефект е vendor lock-in.

Висока бариера за влизане -- протоколът е undocumented. Reimplementation изисква reverse-engineering на Huawei Health app-а (13 000+ classes, 64 000+ methods [2]) или анализ на BLE traffic. Това активно обезкуражава third-party apps.
Няма interoperability -- standard fitness apps не могат да се свържат. Часовникът завършва handshake-а си само със software, който знае proprietary steps -- основно собствения Huawei Health app.
Контрол върху ecosystem-а -- потребителите са принудени да използват Huawei Health и cloud services на Huawei. Смяната на устройства или платформи по-късно означава да изгубиш историята на health data-та си.
По-малък избор за потребителя -- искаш да използваш open-source app? Искаш повече privacy control върху health data-та си? Лош късмет -- освен ако някой първо не reverse-engineer-не протокола.

И ето го важното: това не е уникално за Huawei. Research проектът WatchWitch [3] документира как всички големи vendors -- Apple, Samsung, Xiaomi -- използват proprietary BLE protocols, за да налагат ecosystem lock-in. Apple Watch е "incredibly tightly coupled with Apple's iPhone and iCloud ecosystem, using proprietary protocols that are unavailable to third parties." Това е системен проблем в индустрията.

Но имплементацията на Huawei е особено агресивна. BLE позволява custom services, разбира се. Но да замениш фундаменталния authentication mechanism с proprietary gatekeeper е съвсем друга игра.

Security иронията

Очевидната защита е "правим го за security." Нека погледнем това.

BlueDoor vulnerability research от Tsinghua University [4] тества 16 BLE devices, включително Honor Band 3 (същият Huawei ecosystem), и постига silent pairing without user authorization при повечето от тях. Proprietary protocol-ът не го предотвратява.

Междувременно самият протокол е reverse-engineer-ван многократно -- от Gadgetbridge community-то, от проекта huawei-lpv2, от researchers, които представят на Easterhegg 2019 [2], и от мен за D2Explorer. Security through obscurity с expiration date.

HMAC-SHA256 key derivation-ът от QR code-а всъщност е прилична криптография. Но не това е смисълът. Можеш да постигнеш същите security properties със standard BLE Secure Connections и out-of-band pairing method (като NFC или QR code) -- без междувременно да заключваш всяко third-party application отвън.

Community-то отвръща

Community-то не е приело това тихо.

Gadgetbridge

Gadgetbridge -- open-source Android app-ът за wearable devices -- вече поддържа Huawei Watch D2 [5]. Можеш да pair-неш часовника си без Huawei Health app-а. Това изискваше сериозен reverse-engineering effort (виж PR #2462 [6]), и има ограничения -- ECG functionality е disabled, когато часовникът е paired с Gadgetbridge [7] -- но работи.

Authentication implementation-ът в Gadgetbridge поддържа auth version 3, като изчислява bonding key-а от pairing message-а (service 0x01, command 0x0e) и го използва за decryption. За authentication key negotiation е нужен 17-digit Huawei account ID.

huawei-lpv2

Проектът huawei-lpv2 предоставя pure Python implementation на Huawei Link Protocol v2 [8]. Поддържан е, има multiple forks и служи като reference за всеки, който строи Huawei wearable integrations извън official ecosystem-а.

D2Explorer

Моят собствен D2Explorer проект тръгна по различен път -- C++ implementation със SimpleBLE, която работи на Linux и macOS. Работата включваше:

Implementing TLV serialization/deserialization (HuaweiProtocol).
Building precise message constructors (ProtocolMessageBuilder).
Getting the cryptographic steps right -- nonce generation, HMAC-SHA256, XOR encryption (CryptoOperations, CryptoUtils).
Managing strict state transitions and timing (HuaweiPairingProtocol, ProtocolStateManager).
Debugging failures caused by millisecond-level timing mismatches and subtle crypto errors.

D2Explorer съществува защото протоколът на Huawei го направи необходим. Това е workaround-ът, който се изисква за basic functionality извън walled garden-а.

AsteroidOS

AsteroidOS 2.0 стартира през февруари 2026 като major update на open-source Linux-based smartwatch OS [9]. Вече поддържа ~30 devices, включително Huawei Watch и Huawei Watch 2, с features като always-on display и Tilt-to-Wake. Пълна open-source алтернатива на firmware-а на Huawei.

Регулаторната вълна

EU не просто наблюдава. Digital Markets Act (DMA) започва да принуждава промяна [10].

През декември 2025 Apple пусна iOS 26.3 с AirPods-like pairing за third-party devices -- включително Huawei smartwatches -- конкретно за да се съобрази с DMA requirements [11]. Background syncing между Huawei watches и iPhones вече работи в Европа.

DMA задължава gatekeepers да предоставят interoperability за connected devices. Това директно се прицелва в вида proprietary BLE lock-in, който Huawei (и Apple, и всички останали) практикуват. Full rollout на тези interoperability features се очаква през 2026.

Това е значимо. За първи път има регулаторен натиск да се стандартизира нещо, което vendors умишлено държат proprietary. Technical community-то може да reverse-engineer-ва протоколи един по един, но regulation може да промени incentive structure-а за цялата индустрия.

Какво означава това

Pairing protocol-ът на Huawei Watch D2 е case study за това как custom protocols върху standard transports могат да налагат vendor lock-in. Слоевете proprietary cryptography, custom message formats и timing-sensitive handshakes съществуват не защото standard BLE не може да се справи с authentication -- може -- а защото proprietary protocols държат потребителите вътре в ecosystem-а.

Картината обаче се променя. Gadgetbridge ти дава алтернатива още сега. EU DMA налага interoperability на регулаторно ниво. А open-source проекти като huawei-lpv2, D2Explorer и AsteroidOS доказват, че community-то ще reverse-engineer-не това, което vendors се опитват да заключат.

Строенето на D2Explorer беше по-малко за Bluetooth и повече за cryptographic detective work. То подчертава нещо, което не би трябвало да има нужда от подчертаване: трябва да можеш да достъпваш собствените си health data със software по свой избор.

References

1. huawei-lpv2: Pure Python implementation of Huawei BLE Link Protocol v2 -- Open-source reference implementation на протокола.
2. All Your Fitness Data Belongs to You: Reverse Engineering the Huawei Health Android App -- Easterhegg 2019 conference talk, който документира reverse engineering effort-а. Slides (PDF).
3. WatchWitch: Academic Research on Smartwatch Interoperability -- Документира как всички големи vendors използват proprietary protocols за ecosystem lock-in.
4. BlueDoor: Breaking the Secure Information Flow via BLE Vulnerability (Tsinghua University) -- Открива silent pairing vulnerabilities в 16 BLE devices, включително Honor Band 3.
5. Gadgetbridge: Huawei/Honor Device Support -- Official support page за Huawei и Honor wearables.
6. Gadgetbridge PR #2462: Initial Huawei/Honor Support -- Pull request-ът, който добавя Huawei device support към Gadgetbridge.
7. Gadgetbridge Issue #4918: ECG Disabled with Gadgetbridge -- Known limitation при използване на Gadgetbridge вместо Huawei Health.
8. Gadgetbridge: Huawei/Honor Pairing Guide -- Step-by-step pairing instructions за Huawei devices.
9. AsteroidOS 2.0 Release -- Open-source smartwatch OS, която вече поддържа ~30 devices, включително Huawei watches.
10. EU Digital Markets Act: Interoperability Requirements -- DMA provisions, които задължават connected device interoperability.
11. iOS 26.3 DMA Features: Third-Party Smartwatch Pairing -- Apple's compliance с EU interoperability mandates за wearable devices.

BlueZ Pairing Fix: External Python Agent & D-Bus Polling -- предшественикът на това разследване. Преди да можехме да се заемем с proprietary protocol-а на Huawei, трябваше да оправим AuthenticationFailed errors на BlueZ със standard BLE pairing.
Fix Android Emulator Bluetooth on M1 Mac using Bumble & API 32 -- още една BLE integration битка, този път bridge-вайки physical Bluetooth radio-то на Mac към Android Emulator.

Поправка за BlueZ сдвояване: външен Python agent и D-Bus polling

Tue, 08 Apr 2025 00:00:00 GMT

TL;DR: Ако получаваш org.bluez.Error.AuthenticationFailed със собствен C++/sd-bus pairing agent на BlueZ 5.66+, проблемът най-вероятно е във вътрешната регистрация на agent-а. Пусни външен Python agent (simple-agent.py) като отделен процес и имплементирай D-Bus property polling, вместо да разчиташ на PropertiesChanged сигнали. Подробностите и кодът са по-долу.

Прекарах два дни, втренчен в org.bluez.Error.AuthenticationFailed, преди да разбера какво всъщност става.

Pairing agent-ът беше регистриран. D-Bus извикванията изглеждаха правилни. busctl потвърждаваше, че всичко е на мястото си -- а BlueZ просто продължаваше да казва не. Това беше по време на работата по D2Explorer -- инструмент за сдвояване с Huawei Watch D2 под Linux -- и грешката при сдвояване блокираше всичко.

Ето какво наистина се случи и как го оправихме.

Планът: вътрешен C++ pairing agent

Идеята беше чиста и самодостатъчна. Едно C++ приложение, което управлява целия процес на сдвояване чрез sd-bus (C/C++ D-Bus bindings):

Свържи се към system D-Bus.
Намери Bluetooth адаптера (org.bluez.Adapter1).
Имплементирай C++ клас, който предоставя интерфейса org.bluez.Agent1.
Регистрирай agent-а в org.bluez.AgentManager1 чрез RegisterAgent и RequestDefaultAgent. Започнахме с capability DisplayYesNo, после го опростихме до NoInputNoOutput.
Открий целевото устройство (org.bluez.Device1).
Извикай Pair() върху D-Bus интерфейса на устройството.
Вътрешният agent обработва callbacks (RequestConfirmation, RequestAuthorization) автоматично -- без нужда от потребителско действие.
Trust-ваш устройството, установяваш GATT connection, готово.

Един binary, без външни зависимости. Това беше планът.

Стената: `org.bluez.Error.AuthenticationFailed`

Всичко работеше до стъпка 6. Адаптерът беше намерен, agent-ът регистриран (D-Bus го потвърждаваше), устройството открито. Но в момента, в който извикахме Device1.Pair() чрез sd_bus_call_method -- моментален провал:

[BluetoothDevice] Calling Device1.Pair() method via D-Bus
[BluetoothDevice] Device1.Pair() method threw exception: Failed to call method 'Pair':
    Input/output error - D-Bus error: org.bluez.Error.AuthenticationFailed (Authentication Failed)

Опитахме всичко. Различни agent capabilities. Проверихме sd-bus vtable настройката. Уверихме се, че имплементациите на agent methods връщат успех бързо. Използвахме busctl и gdbus, за да наблюдаваме D-Bus traffic-а -- registration calls изглеждаха правилни. Pair() извикването просто продължаваше да се проваля.

Задънена улица.

Пробивът: външен Python agent

За да изолираме проблема, извадихме вътрешния C++ agent от уравнението. Пуснахме стандартния simple-agent.py на BlueZ като отделен процес преди да стартираме нашето C++ приложение (вече без собствената му agent registration):

# Terminal 1: Run the external agent
sudo python simple-agent.py NoInputNoOutput

# Terminal 2: Run our C++ app (no internal agent)
sudo ./build/huawei_pair_app <MAC> <QR_VALUE>

Резултатът:

[BluetoothDevice] Calling Device1.Pair() method via D-Bus
[BluetoothDevice] Device1.Pair() method succeeded  <--- SUCCESS!

Консистентно. Всеки път. Грешката AuthenticationFailed изчезна напълно.

Това доказа, че проблемът не беше в самия Pair(), нито в устройството, нито в pairing capability-то на BlueZ. Беше конкретно в начина, по който нашето C++ приложение, използвайки sd-bus, се регистрираше и взаимодействаше като pairing agent. Същата логическа операция -- регистриране на NoInputNoOutput agent и извикване на Pair() -- работеше перфектно, когато agent-ът вървеше като отделен Python процес.

Това сработи.

Защо вътрешният agent се провали?

Когато за пръв път се сблъсках с това, имах само хипотези. Оттогава намерих реални документирани доказателства, че това е по-широк проблем -- не само нашият код.

BlueZ 5.70+ regression

BlueZ GitHub Issue #605 документира случаи, в които устройства се сдвояват без проблем на BlueZ 5.50, но се провалят на по-нови версии с auth failed with status 0x05. HCI logs показват Status: PIN or Key Missing (0x06) въпреки запазени link keys. Workaround-ът? Стартиране на legacy bluez-simple-agent.py script. Звучи познато?

Наличният agent е root cause-ът

Bleak Issue #1434 го прави още по-ясно: сдвояването работи само когато bluetoothctl или GNOME Bluetooth е стартиран, защото тези приложения регистрират нужния authentication agent. Без активен, правилно функциониращ agent, BlueZ вътрешно връща No agent available for request type 2 -- което на повърхността излиза като AuthenticationFailed.

Ключовият извод: не е достатъчно просто да регистрираш agent. Agent-ът трябва да отговаря на callbacks от BlueZ по начин, който bluetoothd приема за валиден. И нещо в начина, по който sd-bus прави това в същия процес, който инициира сдвояването, не удовлетворява по-новите версии на BlueZ.

Може дори да не е BlueZ

Red Hat Bug #1905671 разкрива, че някои AuthenticationFailed грешки са kernel-related, а не BlueZ-related. Kernel 5.9 е имал проблеми със сдвояването, които 5.8.18 и 5.10+ не са имали. Коментарът на maintainer-а си струва да се цитира: "Bluetooth is complex, it could be firmware, kernel, bluez, controller, end device or a combination of them all."

Agent capability mismatch

BlueZ Issue #650 документира още един ъгъл: някои устройства (особено iOS) се провалят при сдвояване с NoInputNoOutput agents, защото downgrade-ват Secure Connections към Legacy pairing, което води до Insufficient Authentication (0x05) грешки при последващ attribute access. Това е Security Manager Protocol (SMP) negotiation проблем, не agent registration проблем -- но произвежда същото error message.

Най-вероятните виновници в нашия случай

Като се има предвид evidence-ът, най-вероятните обяснения за провала на вътрешния sd-bus agent са:

Timing -- sd-bus registration или method handling в нашия event loop не отговаряше в точния прозорец, който bluetoothd очакваше.
Тънкости между sd-bus и python-dbus -- разлики в начина, по който тези libraries взаимодействат с D-Bus daemon-а или управляват object lifetimes.
По-строги изисквания в BlueZ 5.66+ -- променени вътрешни sequences за agent interaction, които sd-bus, когато се използва в същото приложение, иницииращо сдвояването, не удовлетворява.

Втората стена: D-Bus сигналите са ненадеждни

Да минем покрай AuthenticationFailed беше голяма победа, но не беше краят. С външния agent на място Pair() успяваше -- но не можехме надеждно да засечем кога е приключил.

Разчитахме на D-Bus PropertiesChanged сигнали (чрез sd-bus), за да разберем кога Paired, Trusted, Connected и ServicesResolved стават true. Понякога сигналите пристигаха. Понякога закъсняваха. Понякога изобщо не пристигаха.

Затова имплементирахме active polling -- fallback, който query-ва property values директно, когато сигналите не се появят:

bool BluetoothDevice::isPaired() {
    bool cachedValue = mockPaired_.load(); // Check signal-updated cache
    if (cachedValue) return true;

    // Signal didn't fire? Poll D-Bus directly.
    Logger::debug("[Polling] Polling Paired property via D-Bus...");
    bool polledValue = false;
    adapter_.getObjectProperty<bool>(
        devicePath_, "org.bluez.Device1", "Paired", polledValue
    );
    if (polledValue) mockPaired_.store(true); // Update cache
    return polledValue;
}

Всеки state transition method (isPaired(), isTrusted(), isConnected(), areServicesResolved()) следва същия pattern: първо проверява cached atomic boolean-а (обновен от signal handler-а, ако той сработи), после пада обратно към директен D-Bus Get property call.

Не е елегантно. Но е необходимо.

Това сработи.

Пълната поправка

Ето консолидираната рецепта. Ако изграждаш automated Bluetooth pairing под Linux с BlueZ 5.66+ и удряш AuthenticationFailed:

Стъпка 1: Вземи simple-agent.py

Вземи го от BlueZ source tree.

Стъпка 2: Стартирай външния agent

sudo python simple-agent.py NoInputNoOutput

Дръж го стартиран в отделен terminal (или като background service).

Стъпка 3: Извади вътрешния agent от приложението си

Премахни всички RegisterAgent / RequestDefaultAgent извиквания от C++ приложението си. Остави външния Python agent да обработва authentication callbacks.

Стъпка 4: Добави D-Bus property polling

Не разчитай само на PropertiesChanged сигнали. За всяко критично property (Paired, Trusted, Connected, ServicesResolved) имплементирай cache-then-poll pattern-а, показан по-горе. Poll-вай периодично от main loop-а.

Стъпка 5: Провери

Потвърди, че външният agent е стартиран (sudo python simple-agent.py NoInputNoOutput).
Стартирай приложението си. Pair() трябва да успее.
Наблюдавай polling logs -- трябва да виждаш D-Bus property queries за state transitions.
Ако Pair() все още се проваля, провери версията на BlueZ (bluetoothd --version) и kernel версията -- проблемът може да е по-дълбок.

Какво ти струва това

Няма да се преструвам, че това е чисто решение. Не е:

External dependency -- приложението ти вече има нужда от отделен Python процес, който да върви.
Повече complexity -- polling logic в main loop-а, върху signal handlers.
По-малко self-contained -- мечтата за един binary си отиде.

Но работи. Надеждно. А когато два дни си гледал AuthenticationFailed, "работи" е това, което има значение.

Референции

1. BlueZ GitHub Issue #55: Device characteristics and pairing timing -- Intermittent pairing failures related to agent timing.
2. Bluetooth Auto Pairing with NoInputNoOutput Agent Issues -- Forum discussion about headless pairing challenges.
3. BlueZ Source: test/simple-agent -- The standard Python agent.
4. BlueZ GitHub Issue #605: Pairing regression in 5.70+ -- Documented failures with newer BlueZ versions.
5. Bleak Issue #1434: Pairing requires active agent -- Evidence that agent availability is the root cause.
6. Red Hat Bug #1905671: Kernel-related pairing failures -- Not always BlueZ -- sometimes it's the kernel.
7. BlueZ GitHub Issue #650: Agent capability mismatch -- SMP negotiation failures with NoInputNoOutput.
8. BlueZ Agent API Documentation -- Official agent interface reference.
9. Kynetics: Pairing Agents in the BlueZ Stack -- Technical deep dive into agent registration.

Свързани публикации

Huawei Watch D2 BLE Pairing: Protocol & Vendor Lock-In -- проектът, който доведе до това разследване. Watch D2 изисква proprietary application-level handshake върху стандартния BLE pairing, затова automated pairing трябваше да заработи още от самото начало.
Fix Android Emulator Bluetooth on M1 Mac using Bumble & API 32 -- още една Bluetooth integration битка, този път bridge-ване на физическото radio на Mac към Android Emulator.

Dev Guide: промени в класове и namespace-и в Shopware 6.5/6.6

Sat, 30 Nov 2024 00:00:00 GMT

Shopware 6.5 и 6.6 въведоха няколко съществени промени в класове, namespace-и, data attributes и механизми за сигурност, с които разработчиците трябва да са наясно, когато обновяват или поддържат своите Shopware проекти. Тази статия дава стегнат, но достатъчно пълен преглед на тези промени, заедно с наблюдения за влиянието им и за това как да адаптираш кода си.

Въведение

Докато Shopware се развива, обновленията често носят подобрения, оптимизации и нови възможности. Но понякога въвеждат и промени, които могат да засегнат съществуващи codebase-и. Разбирането им е решаващо за плавен преход и за смислено използване на новите възможности.

Тази статия се фокусира върху следните ключови области:

Миграция на Elasticsearch namespace-а
Промени при обработката на media paths
Промени в методите на AvailableCombinationLoader
Ъпгрейд на Symfony framework-а до версия 6
Промени при stock handling
Ъпгрейд на Storefront към Bootstrap
Промени в data attribute-а за Offcanvas Cart
Промени в CSRF защитата
Подобрения в Rule Builder

Нека разгледаме всяка от тези промени по-подробно.

1. Миграция на Elasticsearch namespace-а

Преглед на промяната

Предишен namespace: ONGR\ElasticsearchDSL
Нов namespace: OpenSearchDSL

Влияние

Всички класове и методи, които взаимодействат с Elasticsearch, трябва да обновят namespace-ите си, за да отразят миграцията от ONGR\ElasticsearchDSL към OpenSearchDSL.

Необходимо действие

Обнови import statements и reference-и в кода си, така че да използват новия namespace.

Пример

// Before
use ONGR\ElasticsearchDSL\Query\MatchQuery;

$query = new MatchQuery('field', 'value');

// After
use OpenSearchDSL\Query\MatchQuery;

$query = new MatchQuery('field', 'value');

Наблюдения

Тази промяна е в синхрон с по-широкото индустриално движение към OpenSearch, community-driven fork на Elasticsearch. Обновяването към новия namespace гарантира съвместимост с бъдещото развитие и поддръжка.

2. Media Path Handling

Преглед на промяната

Media paths вече се съхраняват директно в базата данни, вместо да се генерират динамично.

Влияние

Класове и услуги, които преди са разчитали на динамично генериране на пътища, трябва да четат media paths от базата данни.

Необходимо действие

Адаптирай кода си така, че да използва метода getPath() от MediaEntity.

Пример

// Before (dynamic path generation)
$mediaPath = $mediaService->getPath($mediaId);

// After (database-stored path)
$mediaPath = $mediaEntity->getPath();

Наблюдения

Съхраняването на media paths в базата данни подобрява производителността, като намалява изчислителния overhead. Освен това дава повече консистентност и надеждност при работа с media.

3. Промяна в метод на `AvailableCombinationLoader`

Преглед на промяната

Методът load() в AbstractAvailableCombinationLoader е заменен с loadCombinations().

Влияние

Всички custom класове, които extend-ват AbstractAvailableCombinationLoader, трябва да имплементират новия метод loadCombinations() вместо стария load().

Необходимо действие

Преименувай или refactor-ни имплементациите на метода, за да съответстват на новото име и сигнатура.

Пример

// Before
$combinations = $combinationLoader->load($productId);

// After
$combinations = $combinationLoader->loadCombinations($productId);

Наблюдения

Тази промяна подобрява яснотата, защото името на метода е по-описателно. Възможно е да има и допълнителни параметри или return types, така че прегледът на сигнатурата е задължителен.

4. Ъпгрейд на Symfony Framework до версия 6

Преглед на промяната

Shopware е обновил Symfony компонентите си до версия 6.

Влияние

Ъпгрейдът въвежда някои breaking changes заради deprecated възможности и промени в method signatures. Custom код, който разчита на по-стари Symfony възможности, може да се счупи или да започне да дава warnings.

Необходимо действие

Прегледай кода си за deprecated Symfony възможности и ги обнови така, че да са съвместими със Symfony 6.

Наблюдения

Поддържането на актуална Symfony версия носи по-добра производителност, сигурност и достъп до нови възможности. Но изисква внимателен code review и тестване, за да се гарантира съвместимост.

5. Промени при Stock Handling

Преглед на промяната

Въведен е нов Stock API, достъпен зад feature flag-а STOCK_HANDLING.

Влияние

Класове и услуги, свързани с управлението на наличности, може да трябва да се адаптират към новата API структура, особено ако взаимодействат директно със stock data.

Необходимо действие

Използвай новите stock handling методи, предоставени от API-то, и се увери, че всяка stock-related логика отговаря на обновената структура.

Пример

// Before
$stock = $productEntity->getStock();

// After
$stock = $stockService->getStock($productId);

Наблюдения

Новият Stock API дава по-устойчив и гъвкав начин за управление на наличности, което потенциално опростява customizations и интеграции с външни системи.

6. Ъпгрейд на Storefront към Bootstrap

Преглед на промяната

Storefront е обновен от Bootstrap 4 към Bootstrap 5, а jQuery е премахнат като dependency.

Влияние

Custom JavaScript код и templates, които разчитат на jQuery или Bootstrap 4 компоненти, трябва да бъдат refactor-нати, за да съответстват на Bootstrap 5 и да използват native JavaScript, където е необходимо.

Необходимо действие

Замени употребата на jQuery с native JavaScript или Bootstrap 5 utilities.
Обнови Bootstrap класове и компоненти, за да съответстват на naming-а и структурата в Bootstrap 5.

Наблюдения

Bootstrap 5 носи подобрения в производителността, по-малко dependencies и модернизирани компоненти. Обновяването може да отнеме време, но дава дългосрочни ползи за поддръжката и user experience-а.

7. Промени в data attribute-а за Offcanvas Cart (Shopware 6.6)

Преглед на промяната

В Shopware 6.6 има фина, но важна промяна в data attribute-а, използван за trigger-ване на offcanvas cart функционалността.

Предишен data attribute: data-offcanvas-cart
Нов data attribute: data-off-canvas-cart

Влияние

Custom templates или themes, които използват attribute-а data-offcanvas-cart без тирета, може да установят, че offcanvas cart вече не работи както се очаква, защото JavaScript listener-ът в Shopware 6.6 търси версията с тирета.

Необходимо действие

Обнови attribute-а data-offcanvas-cart в templates към data-off-canvas-cart.

Пример

<!-- Before -->
<div class="header-cart" data-offcanvas-cart="true">
    <!-- Cart content -->
</div>

<!-- After -->
<div class="header-cart" data-off-canvas-cart="true">
    <!-- Cart content -->
</div>

Наблюдения

Тази промяна не е добре документирана в официалните release notes на Shopware 6.6, но е критична за правилното функциониране на offcanvas cart. JavaScript-ът, отговорен за инициализирането на cart функционалността, разчита на attribute-а data-off-canvas-cart, и всяко отклонение може да попречи на cart-а да работи.

Допълнителни бележки

Консистентността е ключова: Увери се, че всички места, където се използва offcanvas cart attribute-ът, са обновени.
Тествай старателно: След промяната тествай cart функционалността, за да потвърдиш, че работи както се очаква.
Провери за подобни промени: Други data attributes или event listeners може да са минали през сходни промени; прегледай custom templates съответно.

8. Промени в CSRF защитата

Преглед на промяната

Shopware 6.5 и по-новите версии премахват explicit CSRF token handling в templates, преминавайки към SameSite cookie стратегия за CSRF защита.

Влияние

Templates и forms, които преди са включвали CSRF tokens чрез функцията sw_csrf, ще срещнат грешки, защото тази функция вече не съществува.

Необходимо действие

Премахни CSRF Token Functions: Премахни употребата на {{ sw_csrf('route_name') }} от templates.
Разчитай на SameSite Cookies: Довери се на вградената SameSite cookie стратегия за CSRF защита, която не изисква explicit tokens във forms.
Адаптирай form attributes: Увери се, че forms и AJAX requests са конфигурирани правилно, за да работят с новия механизъм за CSRF защита.

Пример

<!-- Before -->
<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    {{ sw_csrf('frontend.checkout.line-item.add') }}
    <!-- Form fields -->
    <button type="submit">Add to Cart</button>
</form>

<!-- After -->
<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    <!-- Form fields -->
    <button type="submit">Add to Cart</button>
</form>

Наблюдения

Разрешаване на грешката: Премахването на функцията sw_csrf разрешава грешката "Unknown 'sw_csrf' function".
Запазване на сигурността: SameSite cookie стратегията продължава да предпазва от CSRF атаки без допълнителни tokens.
Опростени templates: Forms стават по-чисти и малко по-прости без нуждата от CSRF tokens.

Допълнителни бележки

Тестването е критично: След тези промени тествай старателно form submissions, за да се увериш, че работят правилно.
Разбери новия механизъм: Запознай се с начина, по който работи SameSite cookie стратегията, за да поддържаш сигурно приложение.
Обнови документацията: Увери се, че всяка вътрешна документация отразява тази промяна, за да предотврати бъдещо объркване.

9. Работа с проблеми при Offcanvas Cart

Преглед на сценария

След обновяване на templates и премахване на функцията sw_csrf, разработчиците може все още да срещат проблеми, при които натискането на бутона "Add to Cart" отваря offcanvas cart, но той изглежда празен.

Root Cause

Offcanvas cart може да не показва добавените items заради липсващи или неправилни параметри във form submission-а, по-конкретно липсата на input field-а redirectTo.

Необходимо действие

Добави параметъра redirectTo: Включи hidden input field с име redirectTo и стойност frontend.cart.offcanvas във формите за add-to-cart.
Осигури правилни data attributes: Провери дали всички нужни data attributes присъстват и са именувани правилно.

Пример

<form action="{{ path('frontend.checkout.line-item.add') }}" method="post">
    <input type="hidden" name="redirectTo" value="frontend.cart.offcanvas"/>
    <input type="hidden" name="lineItems[{{ product.id }}][id]" value="{{ product.id }}">
    <!-- Other form fields -->
    <button type="submit">Add to Cart</button>
</form>

Наблюдения

Възстановяване на функционалността: Добавянето на параметъра redirectTo казва на Shopware да зареди offcanvas cart при добавяне на item, така че cart-ът да се показва правилно.
Внимание към детайла: Малки пропуски като липсващи input fields могат да доведат до значителни функционални проблеми, което подчертава нуждата от внимателен code review.

Допълнителни бележки

Консистентност в data attributes: Провери още веднъж дали data attributes като data-product-id са зададени правилно.
Преглед на JavaScript dependencies: Увери се, че всички JavaScript plugins или components, свързани с cart-а, са правилно заредени и инициализирани.
Изчисти cache-а: След промените изчисти Shopware cache-а и browser cache-а, за да избегнеш проблеми от остарели файлове.

10. Подобрения в Rule Builder

Преглед на промяната

Rule Builder API е разширено, за да поддържа по-сложна conditional logic.

Влияние

Custom rules и conditions може да се нуждаят от корекции, за да съответстват на новите interfaces или methods, предоставени от подобрения Rule Builder.

Необходимо действие

Прегледай документацията на Rule Builder и обнови custom rule implementations, за да гарантираш съвместимост.

Наблюдения

Разширените rule capabilities позволяват по-прецизно targeting и customization в Shopware. Използването на тези нови възможности може да доведе до по-добра адаптивност и по-персонализирани преживявания за крайните потребители.

Заключение

Shopware 6.5 и 6.6 въвеждат няколко важни промени в класове, namespace-и, data attributes и механизми за сигурност, които разработчиците трябва да адресират, за да запазят съвместимост и да се възползват от новите възможности. Обновяването на codebase-а изисква внимателен преглед и тестване, но отваря възможности за подобрение на производителността, сигурността и функционалността.

Препоръки

Планирай предварително: Преди обновяване прегледай официалните release notes и upgrade guides на Shopware за изчерпателна информация.
Тествай старателно: Имплементирай промените в staging environment и направи обстойно тестване, за да откриеш и поправиш проблеми.
Използвай документацията: Използвай документацията на Shopware и community forums за насоки по конкретни промени.
Остани информиран: Следи бъдещите updates, за да предвиждаш предстоящи промени и да се подготвяш навреме.

Допълнителни наблюдения

Внимание към детайла: Малки промени, като тирета в data attributes или премахване на функции, могат да имат значително влияние. Винаги преглеждай template updates внимателно.
Community Support: Shopware community-то е активно и collaborative. Взаимодействието с други разработчици може да даде insights и solutions за общи предизвикателства.
Best Practices: Приемането на обновени best practices, като използване на native JavaScript вместо jQuery и разчитане на модерни security strategies, води до по-чист и по-ефективен код.
Monitoring Deprecations: Следенето на deprecation notices и подготовката за бъдещи removals може да минимизира disruptions по време на upgrades.

Като разберат и адресират промените в класове, namespace-и, data attributes и сигурност в Shopware 6.5 и 6.6, разработчиците могат да осигурят плавен преход и да продължат да изграждат устойчиви, future-proof e-commerce решения.

Еволюцията на Docker Compose: какво се промени и защо има значение

Wed, 20 Nov 2024 00:00:00 GMT

TL;DR: Docker Compose v1 (docker-compose) беше напълно премахнат през април 2025. Полето version в твоя YAML е мъртво. Ключът x-develop вече е просто develop. Watch mode е готов за продукционна употреба с initial_sync. Има критичен path traversal CVE (CVE-2025-62725), ако използваш include с OCI artifacts -- обнови до v2.40.2+. И да, Compose скочи от v2 на v5. Подробностите са по-долу.

Първоначално публикувано през ноември 2024. Обновено през март 2026 с Compose v5, CVE-2025-62725, премахването на v1 и нови възможности в спецификацията.

Ако използваш Docker Compose от известно време, вероятно си забелязал как неща се чупят или се променят под краката ти. Последните две години бяха най-агресивната еволюция, през която Compose някога е минавал -- и не всичко беше очевидно.

Използвам Compose всеки ден. Повечето ми development setups вървят върху него. Когато нещата се променят, забелязвам. Ето какво реално има значение.

Какво се счупи

docker-compose е мъртъв

Не deprecated. Не в maintenance mode. Мъртъв. Самостоятелният docker-compose binary (Python-базираният v1) беше премахнат от GitHub Actions runners и официалните Docker images през април 2025 [1]. Ако твоите CI/CD pipelines все още сочат към docker-compose с тире, те вече са счупени или съвсем скоро ще бъдат.

# This no longer works
docker-compose up -d

# This is the only way now
docker compose up -d

Go-базираният docker compose (v2, сега v5) е реалната имплементация от 2022 насам. v1 CLI беше на животоподдържаща система заради съвместимост. Тази система беше изключена.

Полето version го няма

Спри да слагаш version: "3.8" най-горе в Compose файловете си. Не прави нищо. Игнорира се още от v2 и вече е официално deprecated. Модерните Compose файлове започват със services:.

# Stop doing this
version: "3.8"
services:
  web:
    image: nginx

# Just do this
services:
  web:
    image: nginx

Ако видиш version: в tutorial, този tutorial е остарял.

Други deprecations

links -- използвай Docker networks. Links са legacy още от пускането на Compose v2.
container_name -- остави Docker да управлява имената. Hardcoded имена чупят scaling-а и причиняват конфликти.
Кратък volume syntax за complex mounts -- използвай long-form syntax с type, source, target.

Какво е ново и реално полезно

Watch Mode (вече готов за продукционна употреба)

Това е най-голямото quality-of-life подобрение от години. Секцията develop (преди x-develop -- махни x- prefix-а, вече не е experimental) ти позволява да дефинираш file watch правила, които автоматично sync-ват или rebuild-ват при промяна на файлове:

services:
  web:
    build: .
    develop:
      watch:
        - path: ./src
          action: sync
          target: /app/src
        - path: ./package.json
          action: rebuild

Има три налични actions (от v2.32.0 насам):

sync -- копира променените файлове в container-а без rebuild
restart -- рестартира service-а, когато файловете се променят
rebuild -- стартира пълен rebuild

Към септември 2025 има и initial_sync -- той sync-ва всички файлове веднага щом стартираш docker compose watch, така че не чакаш първата промяна да задейства synchronization. Това беше болезнена точка дълго време.

docker compose watch

Край на ръчните rebuild-и по време на development. Това наистина промени workflow-а ми.

Include с OCI Artifacts

Директивата include вече може да дърпа Compose fragments от OCI registries:

include:
  - oci://docker.io/username/my-compose-fragment:latest

Има и experimental поддръжка за Git repositories. Това е полезно за споделяне на общи service definitions между проекти -- database configs, monitoring stacks и т.н.

Но първо прочети security секцията по-долу. Има CVE.

GPU Support

GPU passthrough стана по-чист. Вече има по-кратък gpus: syntax (v2.30.0+) заедно с verbose подхода през deploy.resources.reservations.devices. AMD GPU support беше официално интегриран през 2025 -- вече не е само NVIDIA.

Models Element

Compose spec вече включва models element за дефиниране на AI/ML models като OCI artifacts. Можеш да пакетираш LLMs и inference runtimes директно в Compose setup-а си. Нишово, но интересно, ако правиш local AI work.

По-добри зависимости

Условията на depends_on станаха по-гъвкави:

services:
  web:
    depends_on:
      db:
        condition: service_healthy
        restart: true      # restart web if db restarts
        required: false     # web can start even if db isn't ready

Опциите restart: true и required: false са истински полезни за устойчиви local development setups.

Какво трябва да знаеш

CVE-2025-62725: Include Path Traversal

Ако използваш директивата include с OCI artifacts, обнови до v2.40.2 или по-нова версия веднага [2]. Path traversal vulnerability позволява на attacker да избяга от cache directory по време на artifact resolution. Дори невинно изглеждащо docker compose ps може да го trigger-не, ако твоят Compose file include-ва malicious OCI reference.

Docker patch-на това с validatePathInBase() check, но трябва да си на fixed version.

Compose v5

Docker скочи от v2 на v5 (прескачайки 3 и 4, за да избегне объркване със старите file format versions) [3]. Функционално v5 е същият като късните v2 releases, но включва официален Go SDK за programmatic access -- което значи, че можеш да embed-неш Compose functionality директно в Go applications, без да shell-ваш към CLI.

Провери версията си:

docker compose version
# Docker Compose version v5.1.0

Bake е default build tool

Docker Bake (през BuildKit) вече е default за docker compose build. Той се справя с multi-target builds, cross-platform compilation и advanced caching strategies по-добре от legacy builder-а. Ако още не си поглеждал docker-bake.hcl файлове, струва си да ги разбереш -- особено за сложни multi-service builds.

Healthcheck подобрения

Полето start_interval ти позволява да зададеш по-бърз check interval по време на startup grace period:

services:
  db:
    healthcheck:
      test: ["CMD", "pg_isready"]
      start_period: 30s
      start_interval: 2s    # check every 2s during startup
      interval: 30s         # then every 30s after
      retries: 3

Това означава, че dependent services стартират по-бързо, без да компрометираш production health check intervals.

Migration Checklist

Ако не си обновявал Compose setup-а си от известно време:

Премахни version: от всички Compose files.
Замени docker-compose с docker compose във всички scripts и CI configs.
Преименувай x-develop на develop** в watch configurations.
Обнови до v2.40.2+, ако използваш include (CVE-2025-62725).
Замени links с Docker networks, ако някак все още ги използваш.
Тествай CI-то си -- GitHub Actions обновиха runners до Compose v2.40.3 през февруари 2026 [4].

References

1. Docker Compose v1 removed from runner images (April 2025) -- GitHub Actions announcement за премахването на v1.
2. CVE-2025-62725: From "docker compose ps" to System Compromise -- Подробният writeup на Imperva за include path traversal vulnerability.
3. Docker Compose Releases -- Официална release история, включително v5.
4. Docker and Docker Compose version upgrades on hosted runners -- GitHub update-ът за runners през февруари 2026.
5. Compose Specification -- Официална Compose file reference.
6. Use Compose Watch -- Документацията на Docker за watch mode.
7. Enable GPU Support in Docker Compose -- GPU passthrough docs, включително AMD support.
8. Docker Compose Include -- Include directive с OCI и Git support.

Laravel Sail vs Laradock: избор на правилното Docker решение -- сравнение на Docker-базирани PHP development environments.

Отключете силата на 'git grep' за ефективно търсене в код

Wed, 13 Nov 2024 00:00:00 GMT

В обширно кралство, пълно с безброй свитъци и ръкописи, живеел учен на име Аларик. Библиотеката му била огромна — лабиринт от знание, в който древни текстове се смесвали със съвременни писания, а тайни се криели между редовете. Аларик често се оказвал в търсене на една-единствена изплъзваща се фраза сред това море от информация — задача, която с всеки изминал ден ставала все по-плашеща.

Една сутрин, докато слънцето хвърляло златни лъчи върху прашните томове, Аларик тръгнал да открие конкретна идея, спомената в архивите му, известна само като „Шепнещия сигил“. Той преглеждал том след том, използвайки обичайните си методи за пресяване на страниците — методи, които вече му се стрували мудни и неточни. Колкото по-дълбоко навлизал, толкова повече се оплитал в нерелевантни пасажи, дубликати и подвеждащи препратки. Раздразнението растяло, докато часовете се превръщали в дни, а напредъкът оставал нищожен.

Тогава при Аларик дошъл стар мъдрец и забелязал мъката му. С усмивка на човек, който знае, мъдрецът казал: „Може би търсиш по трудния начин. Има скрит път, познат само на онези, които подреждат знанието си разумно.“ Заинтригуван, Аларик слушал как мъдрецът обяснява метод, който стеснявал търсенето му, прорязвал шума и го водел направо към текстовете, които търсел.

Въоръжен с този нов подход, Аларик опитал пак. Този път нерелевантният шум избледнял. Пътят към „Шепнещия сигил“ станал ясен и той намерил търсеното с удивителна скорост. Сякаш беше отключил тайна порта в лабиринта си, която му дала бърз достъп до точното знание, от което се нуждаел.

Пуф! Тайната била разкрита: силата на git grep.

Какво всъщност е `git grep`

Обикновеният grep -r обхожда файловата система. Той прилежно чете всичко по пътя си: source code, log files, build outputs, онзи случаен dump файл от 4 MB, който колегата ти е забравил да изтрие, цялото дърво node_modules. git grep прави нещо по-тясно: търси във файловете, за които Git вече знае. Точно този избор в дизайна е мястото, откъдето идва по-голямата част от стойността му.

В какво е добър `git grep`

Търси tracked файлове, не файловата система. Git пази списък на всеки файл, който някога си staged или committed — index-а. git grep чете от този списък. Untracked боклукът просто го няма там. Няма node_modules/, няма dist/, няма coverage reports, няма случаен log файл — защото Git никога не е бил уведомен за тях.
По-бърз е от grep -r в големи repos. Той вече има списъка с файлове, така че пропуска обхождането на файловата система. Пуска няколко threads паралелно. Печалбата е реална, но не е магия. git grep обхожда същите blobs, които би обходил grep, просто с по-малко церемония. Няма content search index — "Git index" е списък от файлови пътища и blob hashes, не Lucene-стил inverted index.
Може да търси във всеки ref без checkout. Това е killer feature-ът. Tag, branch, commit, tree object — насочи git grep директно към него. Без git checkout, без stash танц, без отбивка от това, което правиш в момента.

Практически примери

Основно търсене

За да търсиш конкретен термин, например "initializeSettings", в repository-то си:

git grep "initializeSettings"

Това сканира всички tracked файлове в текущия branch за точно съвпадение.

Търсене без значение на главни и малки букви

За case-insensitive търсене, което е полезно, когато не си сигурен в capitalization-а:

git grep -i "initializesettings"

Това ще намери съвпадения независимо от разликите в главни и малки букви.

Търсене в конкретен branch

За да търсиш в друг branch, без да превключваш към него, например във feature/login:

git grep "validateUser" feature/login

Това е ходът, който трудно се бие. Няма checkout, няма stash, само отговорът.

Търсене във всички branches

За да търсиш термин във всеки branch, включително remotes:

git branch -a | xargs -n 1 git grep "configureDatabase"

За да търсиш във всеки commit, за който Git някога е чувал, не само в tip-of-branch:

git grep "configureDatabase" $(git rev-list --all)

Това намира съвпадения във всеки blob навсякъде в историята ти. В натоварено repo може да отнеме момент — буквално обхожда всеки commit.

Търсене в commit историята

За да намериш кога конкретен string е бил добавен или премахнат, използвай:

git log -S "optimizePerformance"

Това показва commits, които са въвели или премахнали термина "optimizePerformance".

За да видиш реалните diffs, където терминът е бил добавен или премахнат:

git log -G "optimizePerformance" -p

Използване на regular expressions

git grep поддържа regular expressions за по-напреднали търсения:

git grep -E "def\s+\w+\("

Това съвпада с Python function definitions: def, whitespace, име на function, после буквална отваряща скоба. (В extended regex \( е буквална скоба, а ( би означавала group, затова backslash-ът е там.)

Какво `git grep` чете и какво не чете

git grep обхожда index-а. Това е. Той не parse-ва .gitignore. Много хора, включително предишна версия на тази статия, твърдят, че го прави — и твърдението е почти вярно по начина, по който „Земята е плоска“ е почти вярно, ако цял живот гледаш само един паркинг.

Двете неща съвпадат само защото gitignored файловете обикновено са и untracked. В момента, в който един файл е едновременно gitignored и tracked — някой е пуснал git add -f, или файлът е бил committed преди правилото да съществува — git grep с радост ще го претърси. rg няма.

Можеш да го докажеш за двайсет секунди:

mkdir demo && cd demo
git init -q
echo "*.log" > .gitignore
echo "the secret phrase" > tracked.log
git add -f tracked.log .gitignore
git commit -qm init

git grep "secret phrase"   # finds it - the file is tracked, ignore rule notwithstanding
rg "secret phrase"         # finds nothing - rg actually reads .gitignore

Така че точният израз е: git grep търси tracked файлове. Това случайно пропуска повечето от онова, което .gitignore би пропуснал, но механизмът е различен и edge case-ът има значение — особено когато ловиш string, който накрая се оказва в generated файл, force-added от някого преди години.

Механизмът на .gitignore влиза в git grep само през два opt-in режима:

--untracked — търси и untracked файлове. В този режим git grep зачита .gitignore по подразбиране и пропуска ignored файлове (override с --no-exclude-standard, за да търсиш и в тях).
--no-index — търси в текущата директория, като игнорира Git изцяло. Полезно вътре в repo, когато искаш plain-grep семантика. В този режим git grep не се консултира с .gitignore по подразбиране — opt in с --exclude-standard, ако го искаш.

Default git grep, без flags, никога не отваря твоя .gitignore файл.

Кога да посегнеш към `rg` вместо това

git grep и rg (ripgrep) не са истински конкуренти. Те обхождат различни неща, а сериозният toolbox има и двете.

git grep обхожда index-а: tracked файлове, плюс всеки ref или tree object, към който го насочиш.
rg обхожда файловата система: всеки файл под текущата директория, минус онова, което твоите .gitignore, .ignore, .rgignore и global excludes му казват да пропусне.

Всяко от тях прави нещо, което другото не може.

git grep печели, когато искаш да търсиш из историята без checkout:

git grep "deprecated_api" v2.3.0          # search a tag
git grep "deprecated_api" HEAD~50         # 50 commits ago
git grep "deprecated_api" $(git rev-list --all)   # every commit, ever

rg печели, когато всъщност искаш семантиката на файловата система с правилно gitignore поведение — включително току-що клонирана subfolder, която още не си git add-нал, generated файлове, за които Git никога не е чувал, или директория, която изобщо не е Git repo:

rg "deprecated_api"                # respects .gitignore by default
rg --no-ignore "deprecated_api"    # opt back into ignored files
rg --hidden "deprecated_api"       # include dotfiles

rg е и engine-ът зад project search-а на VS Code, затова "Find in Files" се усеща точно като да пуснеш rg в terminal. Има солидна Unicode поддръжка, а върху повечето modern corpora е поне толкова бърз, колкото git grep, и често по-бърз — Linux kernel benchmark-ът в README-то на ripgrep показва, че ripgrep бие git grep -P с около 3x на същия query. (Съвет: ако искаш поведението "case-sensitive само когато pattern-ът ти има uppercase", подай -S за smart-case — това е opt-in, не default.)

Ако още нямаш rg инсталиран, поправи това:

brew install ripgrep   # macOS
apt install ripgrep    # Debian/Ubuntu
cargo install ripgrep  # anywhere with Rust

Сложи rg до git grep в toolbox-а си. Покриват различни задачи.

Ползи от `git grep`

Релевантност. Той търси само това, което tracked-ваш. Build outputs, caches и node_modules не ти се пречкат — защото Git никога не ги е видял.
Скорост в големи repos. Multi-threaded, без обхождане на файловата система.
Обхват в историята. Всеки branch, tag или commit, без да напускаш working tree-то си. Това е частта, която rg не може да направи.
По-малко binary шум. Като grep, git grep маркира binaries с "Binary file X matches", вместо да излива bytes — но понеже обхожда tracked файлове, обикновено среща по-малко от тях още в началото. Подай -I, за да пропуснеш binaries изцяло.

Допълнителни съвети

Paging на резултатите:
```
git grep "searchTerm" | less
```
Броене на съвпаденията по файл:
```
git grep -c "searchTerm"
```
Показване на номера на редове:
```
git grep -n "searchTerm"
```
Отвори всяко съвпадение в editor-а си:
```
git grep -l "searchTerm" | xargs code
```
Смени code с nvim, subl или каквото използваш.

Заключение

Точно както Аларик намери скрит път в лабиринтната си библиотека, git grep прорязва чиста линия през tracked codebase: бърз, branch-aware и незадръстен от нещо, за което Git никога не е бил уведомен. Не е универсален заместител на grep и не е заместител на rg. Това е инструментът, който познава index-а на твоето repo, и щом започнеш да посягаш към него, лабиринтът става много по-малък.

Използвай git grep, когато въпросът е „къде в тази codebase, включително в историята ѝ“. Използвай rg, когато въпросът е „къде на диска, при спазване на ignore правилата ми“. В повечето дни ще искаш и двете на една ръка разстояние.

Обновено на 2026-04-27: поправено е по-ранно твърдение, че git grep зачита .gitignore (не го прави директно), смекчено е обяснението за "internal indexing", поправен е regex пример и е добавен раздел за това кога да се използва rg вместо него.

PHP 8.3.6 + IMAP на macOS с phpenv: ръководство за инсталация

Sun, 01 Sep 2024 00:00:00 GMT

Важно (обновление от 2024-11): PHP 8.4 извади ext-imap от core-а. Extension-ът се премести в PECL и на практика е deprecated -- underlying C library-то (libc-client) не е обновявано от 2018 насам. Ако започваш нов проект или си на PHP 8.4+, прескочи до Наистина ли ти трябва ext-imap? за модерни алтернативи. Ако си на PHP 8.3 или по-ранна версия и ти трябва native extension-ът, това ръководство още работи.

Бързата поправка

Ако просто искаш командите и не те интересува защо -- ето всичко подред. Трябва вече да имаш инсталирани Homebrew и phpenv.

# 1. Install all required libraries
brew install tidy-html5 openssl@3 zlib bzip2 libedit readline \
  gettext libiconv libsodium krb5 imap-uw curl

# 2. Set build configuration (add to ~/.zshrc or run before install)
export PHP_BUILD_CONFIGURE_OPTS="--with-openssl=$(brew --prefix openssl@3) \
  --with-zlib=$(brew --prefix zlib) \
  --with-bz2=$(brew --prefix bzip2) \
  --with-curl \
  --with-libedit \
  --with-readline=$(brew --prefix readline) \
  --with-gettext=$(brew --prefix gettext) \
  --with-iconv=$(brew --prefix libiconv) \
  --with-sodium=$(brew --prefix libsodium) \
  --with-kerberos=$(brew --prefix krb5) \
  --with-imap=$(brew --prefix imap-uw) \
  --with-imap-ssl=$(brew --prefix openssl@3) \
  --with-tidy=$(brew --prefix tidy-html5) \
  --enable-mbstring \
  --enable-intl"

# 3. Help the compiler find headers
export CPPFLAGS="-I$(brew --prefix openssl@3)/include -I$(brew --prefix imap-uw)/include $CPPFLAGS"

# 4. Build and install
phpenv install 8.3.6
phpenv global 8.3.6

# 5. Verify
php -v
php -m | grep imap

Ако imap се появи в output-а, готов си. Ако не -- чети нататък.

Наистина ли ти трябва ext-imap?

Сериозен въпрос. Преди да се бориш с C libraries и compiler flags, помисли дали наистина ти трябва native IMAP extension-ът.

PHP 8.4 махна ext-imap от core-а. Той се премести в PECL, а underlying C library-то (libc-client / UW-IMAP) не е получавало update от 2018. Има thread-safety проблеми, липсващ XAUTH support и POP bugs. Няма да се върне.

Модерната алтернатива е Webklex/php-imap -- pure PHP IMAP implementation:

composer require webklex/php-imap

Това е. Няма brew dependencies, няма compiler flags, няма ловене на header файлове. Работи на PHP 8.0.2+ (включително 8.4 и 8.5), поддържа IMAP IDLE и OAuth, и има над 5 милиона инсталации в Packagist. Има и Laravel integration, ако това е твоят stack.

Използвай ext-imap само ако поддържаш legacy codebase на PHP 8.3 или по-ранна версия, който вече зависи от imap_* функции, и още не можеш да мигрираш.

Какво прави всяка стъпка

Ако бързата поправка сработи, можеш да спреш да четеш. Ако не сработи -- или ако искаш да разбереш какво се случва -- ето разбивката.

Brew dependencies

brew install tidy-html5 openssl@3 zlib bzip2 libedit readline \
  gettext libiconv libsodium krb5 imap-uw curl

macOS идва с част от тези библиотеки, но phpenv има нужда от Homebrew версиите с правилните headers и pkg-config файлове. Критичната е imap-uw -- това е UW-IMAP library-то, което предоставя libc-client.

PHP_BUILD_CONFIGURE_OPTS

phpenv използва php-build отдолу, който пуска ./configure върху PHP source-а. Променливата PHP_BUILD_CONFIGURE_OPTS подава flags директно към configure. Всеки --with-* flag казва на PHP къде да намери конкретна library.

Най-важните за IMAP:

--with-imap=$(brew --prefix imap-uw) -- сочи към IMAP library-то
--with-imap-ssl=$(brew --prefix openssl@3) -- включва IMAP over SSL
--with-kerberos=$(brew --prefix krb5) -- изисква се за IMAP authentication

CPPFLAGS поправката

export CPPFLAGS="-I$(brew --prefix openssl@3)/include -I$(brew --prefix imap-uw)/include $CPPFLAGS"

Дори с configure flags, C preprocessor-ът понякога не може да намери header файловете. Това се случва, защото macOS не поставя Homebrew headers в default search path-а. Двата header-а, които най-често се провалят:

openssl/ssl.h -- от OpenSSL
imap/imap.h -- от imap-uw

PATH поправката

Ако php -v показва грешната версия след инсталацията, phpenv shims не са в твоя PATH (или нещо друго ги shadow-ва). Добави това в ~/.zshrc:

export PHPENV_ROOT="$HOME/.phpenv"
if [ -d "${PHPENV_ROOT}" ]; then
  export PATH="${PHPENV_ROOT}/shims:${PHPENV_ROOT}/bin:$PATH"
  eval "$(phpenv init -)"
fi

После пусни source ~/.zshrc и пробвай отново.

Грешката utf8_mime2text

Ако видиш това:

configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing.
This should not happen.

Твоята imap-uw library е остаряла или счупена. Оправи я с:

brew upgrade imap-uw

После пусни инсталацията пак.

Бъдещето на PHP + IMAP

Писаното е на стената. ext-imap е deprecated, underlying C library-то е abandon-нато, а PHP 8.4 вече го извади от core-а. Ако четеш това, защото ти трябва IMAP в PHP проект, започни да планираш миграцията си към webklex/php-imap. Native extension-ът живее на заемно време.

За тези от нас, които поддържат legacy codebases -- това ръководство ще продължи да работи за PHP 8.3 и по-ранни версии. Но не започвай нови проекти върху ext-imap. Няма причина да се бориш с компилация на C library, когато съществува pure PHP решение.

Източници

PHP 8.4: IMAP Extension Unbundled -- PHP.Watch документация за премахването на ext-imap.
Webklex/php-imap в GitHub -- Pure PHP IMAP implementation (5M+ Packagist installs).
PHP Manual: IMAP Extension -- Официална документация с deprecation notices.
shivammathur/extensions: IMAP for PHP 8.3+ -- Homebrew tap за PHP extensions, включително IMAP.

Още по темата

PHP 8.5: обиколка на идващите функции -- какво предстои в PHP.
Dev Guide: Shopware 6.5/6.6 class и namespace updates -- още едно PHP migration guide за Shopware developers.
Laravel Sail vs Laradock -- избор на правилния Docker setup за PHP development.

Laravel Sail срещу Laradock: сравнение за PHP Docker разработчици

Thu, 08 Aug 2024 12:00:00 GMT

TL;DR: За повечето Laravel разработчици през 2026: използвай Laravel Herd, ако искаш нулево триене (native, без Docker, настройва се за секунди). Използвай Sail, ако екипът ти има нужда от идентични среди или зависиш от услуги като Redis/Meilisearch. Използвай Laradock, ако работиш с няколко PHP framework-а. Използвай custom Docker Compose setup, ако вече си надраснал abstraction-ите. А ако performance-ът е всичко, погледни FrankenPHP + Octane.

Първоначално публикувано през август 2024. Обновено през март 2026 с Laravel 12/Herd/FrankenPHP и текущото състояние на ecosystem-а.

Въпросът преди беше "Sail или Laradock?" Това рамкиране вече е твърде тясно. Истинският въпрос е: как трябва да си настроя Laravel dev environment-а през 2026? Вариантите са повече от всякога, а най-добрият избор зависи от това какво реално ти трябва.

Използвал съм повечето от тях. В момента работя с custom Docker Compose setup, защото искам пълен контрол върху container-ите си, без abstraction-и, които скриват какво се случва. Но това е моето предпочитание, не универсална препоръка. Нека минем през това какво ти дава всяка опция.

Претендентите

Laravel Herd

Herd е най-новият вариант и за много разработчици правилният. Това е native приложение (macOS и Windows -- все още няма Linux), което ти дава PHP, Nginx, Node.js и Dnsmasq без Docker. Pro версията добавя MySQL, PostgreSQL, Redis и debugging инструменти.

Убийствената функция: смяна на PHP версия за секунди (от 7.4 до 8.4), автоматично route-ване на *.test domains и нулев Docker overhead. Ако правиш стандартно Laravel приложение и не ти трябват екзотични услуги, Herd те вкарва в писане на код за под минута.

Laravel Sail

Sail е официалната Docker-базирана development environment на Laravel. Той обвива Docker Compose със sail CLI, което абстрахира обичайните команди (sail up, sail artisan, sail php).

Към Laravel 12 Sail идва с PHP 8.5 по подразбиране, използва compose.yaml (модерното име на файла, не docker-compose.yml) и включва Swoole за Octane out of the box. Поддържа и devcontainer generation чрез --devcontainer за интеграция с VS Code/GitHub Codespaces.

Услуги по подразбиране: PHP, MySQL, Redis, Meilisearch, Mailpit и Selenium.

Laradock

Laradock е швейцарското ножче. Това е open-source Docker environment, която поддържа всеки PHP проект -- не само Laravel. Предлага 70+ предварително конфигурирани услуги и може да бъде настроена за production употреба.

Все още се поддържа активно към декември 2025 (скорошни PHP-FPM и workspace image обновления). Цената е сложност: setup-ът отнема повече време, конфигурацията минава през редактиране на няколко файла, и ти трябва истинско Docker знание.

FrankenPHP + Octane

FrankenPHP е модерен PHP application server, построен върху Caddy. Комбиниран с Laravel Octane, постига 4-6ms framework boot time на request -- един разработчик докладва спад на latency от 7 секунди до 66ms след преминаване към Worker Mode [1].

Laravel Cloud използва FrankenPHP в своя Octane runtime в production [2]. Последният release (v1.11.2, февруари 2026) донесе 30% по-бърз CGO и 40% по-бърз garbage collection от Go 1.26.

Това не е dev environment в традиционния смисъл -- това е production-grade PHP runtime, който можеш да използваш и в development. Sail включва интеграция за пускане на Octane с FrankenPHP или Swoole.

Кога какво да използваш

Ето моят честен прочит, базиран на реална употреба на тези инструменти:

Използвай Herd, ако си сам или в малък екип, правиш стандартни Laravel приложения и искаш да не губиш никакво време по infrastructure. Това е най-бързият път от "имам идея" до "пиша код". Ограничението е, че е само за macOS/Windows и безплатната версия не включва бази данни.

Използвай Sail, ако екипът ти има нужда от parity между средите, зависиш от конкретни версии на услуги (Redis 7, MySQL 8, PostgreSQL 15), или работиш в CI/CD pipeline, който изисква Docker. Командата sail:publish на Sail ти позволява да customize-ваш Docker setup-а, когато надраснеш defaults.

Използвай Laradock, ако работиш с няколко PHP framework-а (Symfony, Shopware, vanilla PHP), имаш нужда от екзотични услуги (Aerospike, RethinkDB, Manticore), или искаш една Docker environment за няколко проекта. Learning curve-ът е по-стръмен, но flexibility-то е без конкуренция.

Използвай custom Docker Compose setup, ако си надраснал и Sail, и Laradock, и искаш пълен контрол. Това правя аз. Поддържам собствен compose.yaml с точно услугите, които ми трябват, без abstraction layer, и Docker Compose aliases, за да държа командите кратки. Иска повече работа в началото, но няма магия -- всичко е явно.

Използвай FrankenPHP + Octane, ако правиш high-performance API или приложението ти е latency-sensitive. Разликата в performance-а не е маргинална -- тя е цял порядък. Струва си да се разгледа, дори ако използваш друг инструмент за general development.

Детайлите, които имат значение

Време за setup

Инструмент	Време до първи request
Herd	Под 1 минута
Sail	5-10 минути (image pulls)
Custom Compose	30-60 минути (initial setup)
Laradock	1-2 часа (пълна конфигурация)

Customization

Sail е умишлено ограничен. Получаваш услугите, от които Laravel има нужда, и не много повече. Можеш да customize-ваш, като пуснеш sail:publish и редактираш Dockerfile-овете, но в този момент поддържаш custom Docker setup със Sail abstraction-и отгоре -- най-лошото от двата свята.

Laradock ти дава всичко, но изисква да разбираш какво включваш. Да активираш услуга означава да редактираш .env и евентуално docker-compose.yml, а някои услуги имат собствени configuration директории.

Custom Compose ти дава точно това, което напишеш. Нито повече, нито по-малко.

Production readiness

Sail изрично не е за production. Laradock може да се конфигурира за production, но трябва да знаеш какво правиш със security hardening, resource limits и правилен networking. FrankenPHP е production-ready по design -- за това е построен.

Multi-project support

Sail: един проект на environment. Можеш да пуснеш няколко Sail instances, но ще се бият за port-ове.

Laradock: проектиран за multi-project setups. Една environment, няколко проекта, shared services.

Custom Compose: каквото си архитектурираш. Аз държа отделни compose файлове за всеки проект със shared network definitions.

Какво използвам аз

Custom Docker Compose. Имам aliases за всичко -- dcu за docker compose up -d, dce за exec, dcefpm за PHP-FPM shell access, и sail function, която auto-discover-ва project root-а. Setup-ът е в моите Docker Compose evolution notes.

Започнах с Laradock преди години, преминах към Sail, когато излезе, и накрая се установих на custom setup, защото исках да разбирам точно какво върви и защо. Всяка abstraction крие решения. Понякога това е окей. Понякога тези скрити решения създават проблеми, които са трудни за debugging, защото не можеш да ги видиш.

И все пак, ако започвах нов Laravel проект днес с екип, който не се интересува от Docker internals, бих използвал Sail. А ако mentor-вах някого, който тепърва влиза в Laravel, бих му казал да инсталира Herd и веднага да започне да пише код.

Други опции, които си струва да се споменат

DDEV -- Docker-базиран, с добра Laravel поддръжка, активна 2026 roadmap с планирана Gitpod интеграция. Струва си да го оцениш, ако го използваш за други CMS проекти (WordPress, Drupal).
Lando -- още един Docker abstraction layer с Laravel plugin (v1.10.0, януари 2026). Подобна философия на Sail, но framework-agnostic.
Valet -- предшественикът на Herd. Все още работи, но Herd го е заместил за повечето use cases.

References

1. Setup and Boost Laravel with FrankenPHP Worker Mode -- Real-world performance comparison: 7s to 66ms latency.
2. How Laravel Cloud Uses FrankenPHP in Production -- DevConf talk on Laravel Cloud's Octane runtime.
3. Laravel 12.x Sail Documentation -- Official Sail docs with PHP 8.5 and compose.yaml changes.
4. Laravel Herd -- Official site for the native Laravel development environment.
5. FrankenPHP v1.11.2 Release -- February 2026 release with performance and security updates.
6. Laradock on GitHub -- Still maintained, Dec 2025 updates.
7. The Current State of Local Laravel Development -- Andrew Schmelyun's ecosystem overview.

Свързани публикации

Docker Compose Evolution: какво се промени и защо има значение -- промените в Docker Compose, които засягат всички тези инструменти.
PHP 8.5: обиколка на задаващите се features -- какво идва в PHP версията, към която Laravel 12 default-ва.
PHP 8.3.6 + IMAP на macOS с phpenv -- когато ти трябва конкретен PHP setup извън Docker.

Най-лошият лицемер: приказката на едно гумено пате за любовта към себе си

Wed, 17 Jul 2024 12:00:00 GMT

От Борис до един скъп приятел: ~ Човекът, когото винаги ми беше трудно да разбера, но който се оказа най-разбиращият от всички. ~

Здравей. Пак здравей. Може ли пак да се срещнем за първи път? Да. Мисля, че този път ще е по-яко. Ще бъда по-сиренясал от всякога 🧀, ще се опитвам да те разсмивам повече, но пак понякога ще се провалям, или през повечето време, или каквото там... Почти ще е като миналия път, но няма да е като миналия път. Бележка: Можеш да се престориш, че последното ми изречение има смисъл, само заради изтънчеността 🥸

Нека започна с един малък речник, или въведение, или малка база знания:

Едно „начало“ наобратно е „олачан“

Просто ми трябваше ново заглавие, за да стане абзацът ми по-красив. Както и да е. Нов аз. Нова ти. Стари дрехи и някои стари лоши навици. Пуф!

Огледало на стената

Много ми липсваше и дълго си припомнях грешките си. Огледалата наистина съществуват, за да ни правят по-красиви и по-малко мръсни.

Гумено пате

Това съм аз. Аз съм гумено пате. Направен съм от гума, а това означава, че и главата ми е направена от гума.

Гумените патета не „крякат“. Или пък да?

В моя скромен житейски опит като гумено пате аз „крякам“ и го правя доста често. 😆

Крякащо гумено пате кряка

Квак! Квак! Квак! - каза патето и пак изкряка. Невероятен звук! Нали?

Гумено пате с характер

Аз съм най-милото гумено пате от всички, каза гуменото пате и изкряка развълнувано! Квак!

Истинската гибел на гумените патета

Крякането може да бъде доста изтощително, знаеш ли. Можеш да изкрякаш красиво само ограничен брой пъти с един свеж дъх въздух. Но все пак можеш да се опиташ да крякаш красиво, когато си празен? Нали? Разбира се, че можеш! Можеш да се опиташ да изкрякаш! Можеш дори да дадеш най-доброто си бързо квакване от гумата си, за да помогнеш на другите празни гумени патета да си поемат дъх въздух.

Кратък разказ за две наполовина празни гумени патета

„Знаеш ли какво?“ - каза Duckitty „Какво?“ - каза Duckelton „Когато крякам твърде много, вече не мога да крякам, а искам да крякам, и това ме натъжава.“ - отговори Duckitty Duckleton придоби много сериозен вид, смръщи вежди и каза с мъдър глас: „Да. И аз се чувствам така!“

Гуменото пате, което мразеше да мълчи

Duckleton мразеше да мълчи и издаваше силно „квак“ винаги когато можеше. Понякога беше доста празен и се чудеше дали е достатъчно жълт, за да кряка. Но, разбираш ли, фабриката, която беше направила Ducleton и Duckitty, ги беше направила и двамата съвършено жълти. Duckleton беше гумено пате с характер. Той мислеше, че може и трябва да надкряка всяко друго пате, за да го спаси от срама да не кряка, когато е празно. Duckitty понякога имаше подобни мисли, или поне Duckleton мислеше така, когато беше с ума си. (Понякога не беше 😆) Но Duckleton беше гордо гумено пате. Гумено пате, направено в най-добрата фабрика в света, която от векове правеше най-добрите крякащи жълти гумени патета. Поне Duckleton мислеше така, докато не срещна Duckitty. Щом я срещна, той беше толкова смаян от гласа ѝ, че реши, че тя сигурно е направена в някаква извънземна фабрика, много по-добра от земната фабрика, от която идваше той. Беше щастлив, че има възможността просто да се възхищава на това прекрасно и съвършено гумено пате, което беше много по-добро от него (така мислеше той) и се казваше Duckitty. „Е, толкова е хубаво да я гледам. Тя е толкова жълта. Тя е толкова мила. Има много по-красив глас от мен. Аз съм щастливо гумено пате.“ - мислеше си Duckleton.

Кратък, но малко тъжен разказ

Duckleton и Duckitty бяха щастливи и крякаха така, сякаш това беше най-доброто състезание по крякане в света и в открития космос. Веднъж едно човешко дете дойде и стисна Duckleton. Той не можеше да кряка известно време, но все още копнееше да го прави, затова остана мълчалив, без да се оплаква, пое си дълбоко дъх и двамата продължиха да крякат щастливо. Мина известно време и Duckitty също беше взета от едно гадно човешко дете. Човешкото дете изстиска целия въздух от Duckitty, но Duckleton беше твърде зает да кряка, за да забележи. Duckitty беше добре, но трябваше да си поеме малко въздух. Duckleton беше тъжен отвъд отчаянието. Той мислеше, че любимото му пате се е счупило и че пак ще е завинаги сам до края на Вселената. Просто беше забравил, че същото дете го беше стискало и него известно време по-рано. Duckleton беше горд, но глупав, все пак имаше малка гумена глава. Когато Duckitty изкряка, Duckleton побесня. Той хем беше щастлив, че тя е жива, хем беше малко обезсърчен, защото си мислеше, че Duckitty може да преживее стискане от човешко дете по-добре от него. В крайна сметка тя беше толкова по-съвършена от него, нали?

Вината на Duckleton

Duckleton беше най-лошият лицемер от всички и най-накрая го разбра. Беше тъжен, но си помисли: Нека се извиня на Duckitty и ѝ покажа малко благодарност, че е толкова съвършена, каквато е.

Епилог

Скъпи мой приятелю, ти беше съвършена през последните 8 години. Беше съвършена всеки един ден. Много съжалявам, че бях такъв лицемер, но се случват лоши неща, знаеш. И ние пак продължаваме. Моля те, обичай себе си много повече. Аз съм глупав. Ти си умна. Или каквото там... Но обичай себе си много повече, защото си съвършена такава, каквато си! Всъщност ти си най-съвършеното жълто гумено пате в света. Поне аз мисля така. Гумената ми глава е малка. Но, ура! Все още мога да мисля. 🫶 Квак!

Квак, Квак, Квак ~ Duckleton

Дискретни представяния в RL: изследователските прозрения на Edan Meyer

Mon, 15 Jul 2024 00:00:00 GMT

Замислял ли си се как AI агентите се научават да разбират сложни среди и да действат в тях? Edan Meyer, изследовател в областта на reinforcement learning (RL), проучва интригуващ подход, който може да промени начина, по който мислим за обучението на AI. Нека се гмурнем в любопитната му работа върху дискретните представяния в RL.

Силата на представянето

Представи си, че се опитваш да научиш компютър да играе видеоигра. Как би представил състоянието на играта така, че компютърът да може да го разбере и да се учи от него? Тук идва representation learning, а то е ключова част от създаването на ефективни AI агенти.

Edan Meyer, чиято работа можеш да видиш в неговия YouTube канал, изследва конкретен тип представяния, наречени дискретни представяния. Неговото изследване, подробно описано в статия, достъпна в arXiv, хвърля светлина върху това защо тези представяния може да са особено полезни в определени RL сценарии.

Две години изследвания в 13 минути

Edan е събрал две години от магистърското си изследване в увлекателно 13-минутно видео със заглавие "2 Years of My Research Explained in 13 Minutes". В него той разбива сложни концепции до смилаеми обяснения и прави работата си достъпна за по-широка публика.

Както Edan описва във video description-а:

"Това е моето изследване върху representation learning и model learning в контекста на reinforcement learning. Две години работа, и най-накрая мога да говоря за магистърското си изследване! Статията беше приета на Reinforcement Learning Conference (RLC) 2024."

Това видео е чудесна отправна точка за всеки, който иска да разбере основите на изследването му, без веднага да се гмурка в цялата академична статия.

Какво са дискретните представяния?

Традиционно много RL системи използват непрекъснати представяния - мисли за тях като за вектори от десетични числа, които могат да приемат всякаква стойност. Дискретните представяния, от друга страна, приличат повече на поредица от въпроси с избираем отговор. Всеки "слот" в представянето може да приеме само една стойност от фиксиран брой възможности.

Както Edan обяснява във видеото си, на пръв поглед това може да изглежда ограничаващо. Все пак една непрекъсната стойност може да представя безкрайно много състояния, докато дискретната стойност е много по-ограничена. Тогава защо изобщо да използваме дискретни представяния?

Изненадващите ползи

Изследването на Edan открива няколко любопитни предимства на дискретните представяния:

По-добри world models с по-малък капацитет: Когато AI се опитва да научи модел на средата си ("world model"), дискретните представяния му позволяват да улови по-точна информация с по-малко изчислителна мощ. Това е особено вярно, когато моделът няма достатъчно капацитет да представи идеално всичко в средата - често срещан сценарий при сложни проблеми от реалния свят.
По-бърза адаптация: В експерименти, при които средата се променя с времето, агентите, използващи дискретни представяния, успяват да се адаптират по-бързо към тези промени. Това може да е решаващо за AI системи, които трябва да работят в динамични и непредвидими среди.
Ефективно обучение: Макар дискретните представяния първоначално да може да отнемат повече време за научаване, след като са установени, те позволяват по-бързо обучение и адаптация както при задачи за world modeling, така и при policy learning.

Защо това има значение?

Последствията от работата на Edan стигат далеч отвъд простите grid-world експерименти. Както той посочва във видеото си, реалният свят е неизмеримо по-сложен от всяка симулация, която можем да създадем. В такива среди е невъзможно един AI да научи всичко - ключът е адаптацията.

Дискретните представяния изглежда предлагат мощен инструмент за създаване на AI системи, които могат бързо да се адаптират към нови ситуации, дори когато няма как да моделират всеки аспект на средата си. Това може да промени играта за приложения от роботика до сложни стратегически игри и отвъд тях.

По-надълбоко

За тези, които се интересуват от техническите детайли, статията на Edan разглежда увлекателни аспекти на това защо дискретните представяния работят толкова добре. Например той открива, че не всички дискретни представяния са еднакви - фактори като sparsity и binarity играят важна роля за тяхната ефективност.

Заключение

Работата на Edan Meyer върху дискретните представяния в reinforcement learning предлага вълнуващи прозрения за това как можем да създаваме по-адаптивни и по-ефективни AI системи. Като оспорва конвенционалната мъдрост за това как трябва да представяме информация за AI, неговото изследване отваря нови възможности за създаване на агенти, които могат да се справят в сложни и динамични среди.

Независимо дали си AI изследовател, студент по machine learning, или просто човек, увлечен от фронтира на технологиите, работата на Edan дава убедителен поглед към бъдещето на изкуствения интелект. Непременно виж неговия YouTube канал, обяснителното му видео и статията за по-задълбочено разглеждане на тези идеи.

Помни: в бързо движещия се свят на AI изследванията днешните експериментални техники може да се окажат утрешните пробивни технологии. Дискретните представяния може би са ключът към отключването на по-способни и по-адаптивни AI системи в близко бъдеще.

Историята на AI в Google: обещания, акции и пазарно влияние

Sat, 11 May 2024 12:00:00 GMT

Пътят на Google през разработването и маркетинга на AI технологии като серията Gemini е любопитен казус за взаимодействието между корпоративни обещания, представяне на борсата и технологични иновации. Този анализ разглежда конкретни исторически моменти, в които AI обещанията на Google са повлияли значимо върху цените на акциите, заедно с преглед на успехите и провалите на компанията.

Навлизането на технологичния гигант в AI е белязано от амбициозни проекти и смели твърдения. От представянето на TensorFlow през 2015 г., което утвърди Google като лидер в изследванията и разработката на AI, до пускането на Google Assistant през 2016 г., което засили конкурентоспособността му срещу съперници като Alexa на Amazon и Siri на Apple, Google постоянно се стреми да разширява границите на възможностите на AI [1].

Ключови исторически етапи в развитието на AI в Google

Представяне на TensorFlow (2015): Google направи TensorFlow, своя framework за машинно обучение, open source, и той бързо стана широко популярен. Този ход помогна Google да се утвърди като лидер в AI изследванията и разработката, с положителен ефект върху пазарното възприятие [1]. TensorFlow се използва в различни приложения - от подобряване на резултатите при търсене до задвижване на автономни автомобили.
Пускане на Google Assistant (2016): Представянето на Google Assistant засили конкурентоспособността на Google в AI спрямо съперници като Alexa на Amazon и Siri на Apple. Пазарът прие това добре, като сигнал за потенциален растеж в потребителски интерфейси, задвижвани от AI [2]. Google Assistant беше интегриран в смартфони, устройства за умен дом и автомобили, превръщайки се в ключов играч на пазара на гласови асистенти.
Напредък в квантовите изчисления (2019): Google обяви пробив в квантовото превъзходство, твърдейки, че квантовият му компютър може да извършва изчисления отвъд възможностите на традиционните суперкомпютри. Това съобщение доведе до кратък скок в цената на акциите и показа ентусиазма на инвеститорите към върховите технологични възможности на Google [3].

Представяне на борсата и AI етапи

Борсата е реагирала различно на AI развитието на Google. Значими съобщения, като пробиви в квантовите изчисления и нови AI продуктови премиери, обикновено водят до краткосрочно покачване на цената на акциите. Дългосрочното влияние върху цените обаче е по-тясно свързано с реалното внедряване и търговския успех на тези технологии.

Етапи на S&P 500: Големите AI съобщения на Google често съвпадат с по-широки пазарни тенденции. Например по-широкият bull market през 2021 г. видя Google да достига нови върхове в цената на акциите си паралелно със значим напредък в AI, отразявайки силно инвеститорско доверие в растеж, движен от технологии [4].

Fig1. - Етапи в акциите на Google.

Успехи и провали

Успехи: AI на Google постигна значителен успех в области като езиков превод, разпознаване на изображения и технологии за автономно шофиране чрез Waymo. Тези успехи помогнаха да се затвърди репутацията на Google като технологичен иноватор [5].
Провали: Не всички AI инициативи на Google отговориха на очакванията на пазара. Например силно очакваният проект Google Glass не успя да резонира с потребителите, което доведе до прекратяването му. Продуктът се сблъска с опасения за личната неприкосновеност и не успя да предложи убедителен use case за средния потребител. По подобен начин забавянията и прекомерните обещания около Gemini 1.5 Pro доведоха до недоволство и скептицизъм сред потребителите [6]. Google се учи от тези провали, като се фокусира върху по-прагматични AI приложения и подобрява комуникацията си с потребителите.

Fig2. - AI етапи на технологични компании.

Пазарно влияние и бъдеща перспектива

Пазарното влияние на AI усилията на Google е значимо - то влияе не само на цените на акциите на компанията, но и на посоката на по-широката технологична индустрия. AI секторът продължава да бъде основен фокус за инвеститорите, както се вижда и от представянето на S&P 500, където технологичните акции играят съществена роля [4].

Напред способността на Google да изпълни AI обещанията си и да преодолее предизвикателствата на технологичното внедряване ще бъде решаваща. Стратегията на компанията да увеличи прозрачността и да управлява по-ефективно потребителските очаквания може да определи бъдещата ѝ пазарна позиция и доверието на инвеститорите.

Една ключова област за наблюдение е напредъкът на Google със серията AI модели Gemini. Gemini 1.5 Pro, обявен през февруари 2024 г., обещава значителен скок във възможностите на AI, но се сблъска с трудности при rollout-а си [6]. Начинът, по който Google ще премине през тези трудности и ще изпълни обещанията си, вероятно ще има осезаем ефект върху AI репутацията и пазарната позиция на компанията.

Амбициозният напредък на Google в изкуствения интелект, особено чрез серията Gemini, означава преобразяваща ера в AI технологиите. Представянето на Gemini 1.5 Pro като част от тази серия подчертава ангажимента на Google да разширява границите на AI възможностите. Rollout-ът на Gemini 1.5 Pro обаче не мина без предизвикателства, а те са важни за разбирането както на потенциала, така и на ограниченията на толкова напреднали AI модели.

Експертни мнения за Gemini 1.5 Pro

Представяне и възможности: Gemini 1.5 Pro, изграден върху Mixture-of-Experts (MoE) архитектура, предлага значителни подобрения спрямо предишни модели, включително огромно увеличение на context window до 10 милиона токена. Това подобрение позволява по-добра работа със сложни задачи, включващи големи обеми данни в различни формати - текст, код, визия и аудио [7]. Според Stephen Oladele от Encord "Gemini 1.5 Pro поддържа почти перфектно припомняне в целия контекст и използва mixture-of-experts архитектура за по-ефективно обучение и по-качествени отговори" [7].

Предизвикателства при rollout-а: Въпреки напредналите си възможности rollout-ът на Gemini 1.5 Pro се сблъска с няколко предизвикателства. Моделът в момента е в private preview, а общата му достъпност е планирана за по-късен етап, което показва поетапен подход към внедряването [7]. Тази предпазлива стратегия може да се дължи на нуждата моделът да бъде донастроен допълнително и да се гарантира, че отговаря на високите очаквания, поставени от предшествениците му и от пазара.

Погледът на индустриалните анализатори

Влияние върху AI индустрията: Индустриалните анализатори виждат серията Gemini като значителна стъпка напред за Google, която потенциално задава нови стандарти за това какво могат да постигат AI моделите. Очаква се серията Gemini, особено 1.5 Pro, да засили конкурентоспособността на Google срещу други технологични гиганти като OpenAI и Microsoft, които също агресивно развиват своите AI възможности [8] [7].

Пазарни последици: Напредъкът в Gemini 1.5 Pro вероятно ще повлияе на различни сектори, включително здравеопазване, финанси и други, като позволи по-сложни AI приложения. Това може да доведе до промени в пазарната динамика, при които компаниите, които ефективно интегрират такива напреднали AI технологии, ще получат значително конкурентно предимство [7].

Изводи от ръководителите на Google

Бъдещи планове и етични съображения: Ръководители на Google, включително Sundar Pichai, подчертават ангажимента на компанията към отговорно развитие на AI. Pichai изтъква важността AI напредъкът да бъде съгласуван с етични насоки и да се гарантира, че тези технологии се използват в полза на обществото [2] [9]. Този подход е решаващ, докато AI става все по-способен и все по-интегриран в ежедневни приложения.

Навигиране на предизвикателства и възможности

Справяне с техническите предизвикателства: За да премине през предизвикателствата напред, Google трябва да продължи да инвестира в изследвания и разработка, за да адресира проблеми като надеждност на моделите и етични опасения. Подходът на компанията за постепенно пускане на Gemini 1.5 Pro подсказва стратегия, фокусирана върху намаляване на рисковете, преди те да се превърнат в значителни проблеми [7].

Разширяване на пазарните възможности: Google може да използва възможностите на Gemini 1.5 Pro, за да създаде нови пазарни възможности, особено в сектори, които изискват работа с големи datasets и сложни сценарии за решаване на проблеми. Като предоставя инструменти, които опростяват интеграцията на AI в бизнес процеси, Google може да помогне на индустриите да трансформират операциите си и да постигнат по-голяма ефективност [10].

Етично развитие на AI: С усилването на AI технологиите етичните последици стават все по-значими. Продължаващият ангажимент на Google към отговорно развитие на AI, демонстриран чрез AI принципите и governance frameworks на компанията, ще бъде ключов за поддържане на общественото доверие и регулаторното съответствие [11].

В заключение, макар rollout-ът на Gemini 1.5 Pro да носи предизвикателства, той предлага и съществени възможности за Google да води в AI пространството. Като продължи да се фокусира върху подобрения в представянето, етично развитие на AI и пазарно разширяване, Google може ефективно да премине през тези предизвикателства и да зададе нови стандарти за това какво AI може да постига в различни индустрии.

Заключение

AI пътят на Google показва сложната динамика между технологични иновации, пазарни очаквания и корпоративна стратегия. Макар компанията да има както забележими успехи, така и неуспехи, продължаващите ѝ усилия в AI продължават да привличат значително пазарно внимание. Инвеститорите и пазарните наблюдатели вероятно ще следят внимателно способността на Google да превърне AI възможностите си в устойчив растеж и пазарно лидерство.

Докато AI пейзажът продължава да се развива бързо, позицията на Google като AI пионер ще бъде подложена на изпитание. Способността на компанията да балансира амбициозна иновация с реалистично изпълнение, прозрачна комуникация и ефективно управление на очакванията ще бъде критичен фактор за дългосрочния ѝ успех в AI сферата и за общото ѝ пазарно представяне.

Източници

1. Emeritus - AI стратегията на Google
2. Google Blog - Gemini AI
3. Yahoo Finance - GOOGL котировка
4. Wikipedia - Етапи на S&P 500
5. Think with Google - AI инструменти
6. Times of India - Излизане на Gemini 1.5 Pro AI
7. Encord - Google Gemini 1.5 Generative AI Model with Mixture of Experts
8. Built In - Google Gemini
9. CBS News - AI бъдещето на Google
10. Google Cloud - Generative AI
11. Google Blog - Responsible AI

Stable Diffusion фотореализъм: настройки и GPU лимити

Thu, 04 May 2023 23:45:00 GMT

Обновено март 2026. Тази статия първоначално беше написана през май 2023 г., когато SD 1.5 при 512x512 беше стандартът, а RTX 3090 беше върховият хардуер. Всичко се промени. Flux 2, SDXL fine-tunes, SD 3.5, ControlNet и RTX 5090 напълно предефинираха възможното. Това е текущото състояние.

Разликата между AI-генерирани изображения и истински фотографии почти се затвори. През 2023 г. "фотореалистично" означаваше "почти убедително, ако присвиеш очи". През 2026 г. най-добрите модели произвеждат изображения, които наистина е трудно да различиш от професионална фотография.

Ето как да стигнеш дотам.

Текущият пейзаж на фотореализма

Моделът, който избереш, има по-голямо значение от всяка настройка, която пипаш. Ето къде стоят нещата:

Flux 2 -- Новият крал

Flux 2 от Black Forest Labs (пуснат през ноември 2025 г.) вероятно е най-добрият open-weight модел за фотореализъм през 2026 г. [1]. Той произвежда изображения с естествено осветление, точни текстури на кожата и кохерентна композиция, която съперничи на професионална фотография. Adobe интегрира Flux (Kontext Pro) във Photoshop през септември 2025 г. [2] -- това ти казва къде е доверието на индустрията.

Flux също има изключително добро разбиране на естествен език. Можеш да опишеш какво искаш на обикновен английски, без супата от ключови думи, която SD 1.5 изискваше.

SDXL Fine-Tunes -- Работните коне

За SDXL-базиран фотореализъм това са текущите лидери:

Juggernaut XL v9/v10 -- изборът по подразбиране за кинематографичен, фотографски output. Най-популярен сред фотографи и filmmakers.
Realistic Vision -- fine-tuned специално за реалистични текстури, осветление и точност на лица.
EpicRealism -- изключителен фин детайл и естествено осветление.

Тези модели имат огромна community поддръжка, обширни LoRA библиотеки и предвидимо поведение. Ако Flux ти се струва твърде нов или workflow-ът ти е изграден върху SDXL, това са отлични варианти.

SD 3.5 Large

Флагманът на Stability AI използва новата Multimodal Diffusion Transformer (MMDiT) архитектура -- фундаментално различен подход от SDXL. Технически е впечатляващ, но екосистемата е по-малка. SD 3.0 беше deprecated през април 2025 г., така че се увери, че си на 3.5 [3].

Проверка с реалността за GPU

Хардуерните изисквания се покачиха значително.

GPU	VRAM	Възможности за фотореализъм
RTX 3060 12GB	12GB	Само SD 1.5 фотореализъм. SDXL е на ръба
RTX 4070 Ti	12GB	SDXL при 1024x1024. Flux е възможен с оптимизации
RTX 4090	24GB	Сладката точка. Спокойно се справя със SDXL, Flux и SD 3.5 при 1024x1024+
RTX 5090	32GB	Всичко, включително 4K генериране и batch workflows. 32GB GDDR7, 512-bit bus [4]
8GB карти	8GB	Минимумът, който става, с VRAM management-а на ComfyUI. Не е удобно

Сладката точка от 2023 г. -- "512x512 на RTX 3080" -- вече е древна история. 1024x1024 сега е стандартната резолюция, а ти искаш поне 16GB VRAM, за да работиш без постоянна фрустрация. При 24GB започва да става комфортно.

Конкретно за фотореализъм повече VRAM означава, че можеш да пускаш по-големи модели, по-високи резолюции и ControlNet едновременно, без offloading към CPU.

Настройки за фотореализъм

Sampler

DPM++ 2M Karras при 25-30 steps. Това е установеният консенсус за SDXL фотореализъм -- най-доброто съотношение скорост към качество. Ако искаш малко повече детайл при нисък брой steps, смени на DPM++ SDE Karras.

За Flux: използвай default sampler-а при 20-30 steps.

CFG

За SDXL фотореализъм: 7-9. Това дава силно придържане към prompt-а без пренаситения, преготвен вид, който се появява над 10.

За SD 3.5: започни по-ниско (3-5) -- guidance механизмът работи различно.

За Flux: следвай model-specific препоръките, но обикновено по-ниско от SDXL.

Резолюция

Генерирай при native резолюцията на модела (1024x1024 за SDXL/SD 3.5/Flux), после upscale за по-висока резолюция. Не се опитвай да генерираш директно при 2048x2048 -- ще получиш артефакти, дублирани елементи и проблеми с композицията.

Опции за upscaling: hi-res fix в A1111 или специализирани upscaling nodes в ComfyUI (4x-UltraSharp, ESRGAN).

Prompting за фотореализъм

Най-голямата промяна от 2023 г.: пиши естествено, не с ключови думи.

SD 1.5 имаше нужда от prompts като:

portrait of a woman, photorealistic, 8k, ultra detailed, sharp focus,
professional photography, Fujifilm X-T4, 85mm f/1.4

SDXL и Flux разбират:

A portrait of a woman in soft afternoon light, photographed with a shallow
depth of field. She's looking slightly off-camera with a natural expression.

Подходът със супата от ключови думи все още работи в SDXL, но естественият език произвежда по-кохерентни резултати. Flux особено блести с описателни, разговорни prompts.

Negative prompts: Дръж ги минимални. Започни без никакви, после добавяй конкретни поправки. "cartoon, illustration, painting" обикновено е достатъчно, за да останат нещата фотореалистични. Виж cheat sheet-а за пълната промяна във философията на negative prompts.

ControlNet променя всичко

Ако си сериозен за фотореалистична композиция, ControlNet не подлежи на преговори. Той ти позволява да контролираш структурата на изображението чрез:

Depth maps -- поддържат пространствени отношения и перспектива
Canny edge detection -- запазва контури и форми
OpenPose -- контролира човешка поза и пропорции на тялото
Surface normals -- реалистично взаимодействие на осветлението с повърхности

ControlNet модели вече са налични за SDXL, Flux и SD 3.5 [5]. Multi-ControlNet (stacking на няколко controls) ти дава прецизен контрол върху композицията, който prompt engineering сам не може да постигне.

Workflow-ът: вземаш референтна снимка, извличаш depth map или pose, използваш го като ControlNet input и генерираш фотореалистично изображение със същата композиция.

Скорост срещу качество

Ако ти трябват бързи итерации (concept work, prompt testing), използвай SDXL Lightning -- той генерира качествени 1024px изображения в 2-8 steps [6]. По-добро качество от SDXL Turbo при по-високи резолюции.

За финален output се върни към пълен SDXL или Flux с 25-30 steps. Разликата се вижда.

Практичният workflow

Ето какво наистина работи за фотореалистичен output през 2026 г.:

Избери модел -- Flux 2 за най-добър фотореализъм, Juggernaut XL за SDXL екосистемата
Напиши prompt на естествен език, който описва какво виждаш
Генерирай при 1024x1024, DPM++ 2M Karras, CFG 7-9, 25-30 steps
Използвай ControlNet, ако ти трябва конкретна композиция (depth или pose)
Итерирай върху prompt-а -- генерирай 4-8 изображения, избери най-доброто
Upscale победителя до целевата ти резолюция
Inpaint проблемните области (ръце, очи, малки детайли)

Това е същият workflow, независимо дали си в ComfyUI или A1111. Инструментите се различават, pipeline-ът -- не.

Източници

1. Flux 2 Models -- Black Forest Labs -- Официална страница на Flux 2 model.
2. FLUX.2 and NVIDIA RTX AI Garage -- Интеграция на Flux 2 с ComfyUI и adoption от индустрията.
3. Stability AI Release Notes -- SD 3.0 deprecation и подробности за 3.5 release-а.
4. RTX 5090 vs 4090 for AI Workloads -- Хардуерно сравнение за генериране на изображения.
5. ControlNet Complete Guide -- Обновена ControlNet документация за множество архитектури.
6. SDXL-Lightning by ByteDance -- Модел за генериране в 2-8 steps.
7. Best Stable Diffusion Models for Photorealism 2026 -- Текущ пейзаж на моделите.
8. Top Photorealistic Stable Diffusion Models -- Community reviews от Civitai.

Свързани публикации

Stable Diffusion Cheat Sheet: Troubleshooting & Optimization -- бърза справка за параметри, samplers и troubleshooting.

Stable Diffusion cheat sheet: troubleshooting и оптимизация

Thu, 04 May 2023 23:30:00 GMT

Обновено март 2026. Оригиналната версия на този cheat sheet беше написана за SD 1.5 през май 2023. Оттогава почти всичко се промени -- нови архитектури (SDXL, SD 3.5, Flux), нови UI-та (ComfyUI), нов хардуер (RTX 5090) и пълен обрат във философията за negative prompts. Това е актуалната версия.

Това е работният ми справочник за параметрите в Stable Diffusion. Не tutorial -- просто настройките, към които посягам, когато нещо не работи или когато искам да избутам качеството нагоре.

Кой модел да използваш

Това вече е първото решение и има по-голямо значение от всяко пипане на параметри.

Модел	Най-добър за	Резолюция	Бележки
Flux 2	Фотореализъм, следване на prompt-а	1024x1024+	Най-добрият open-weight модел за фотореализъм през 2026. Интегриран в Adobe Photoshop [1]
SDXL	Обща употреба	1024x1024	Огромна екосистема от fine-tune-и. Juggernaut XL, Realistic Vision, DreamShaper
SD 3.5 Large	Топ качество (flagship моделът на Stability)	1024x1024	MMDiT архитектура. SD 3.0 беше deprecated през април 2025 [2]
SDXL Lightning	Скорост	1024x1024	Генериране в 2-8 стъпки. По-добро качество от Turbo при по-висока резолюция [3]
SD 1.5	Legacy workflows	512x512	Огромна библиотека от fine-tune-и, но постепенно излиза от употреба. SD 2.0/2.1 са официално deprecated

Ако започваш начисто: Flux 2 за фотореализъм, SDXL за всичко останало. SD 3.5 е добър, но екосистемата е по-малка.

Кой UI да използваш

UI	Най-добър за
ComfyUI	Power users. Node-based, по-добро управление на VRAM, 15% по-бърз, най-добра поддръжка за Flux. Индустриален стандарт за сериозна работа към 2025 [4]
Automatic1111	Начинаещи. По-прост интерфейс, огромна библиотека от extensions. Все още работи добре за SDXL
Fooocus	Генериране с един клик. Минимална конфигурация. Добър за бързи резултати

Аз използвам ComfyUI. Learning curve-ът е по-стръмен (очаквай 10-20 часа, докато ти стане удобно), но само управлението на VRAM си струва -- пуска SDXL на 8GB там, където A1111 се срива.

Samplers

Спорът за samplers е общо взето приключил.

Go-to избори:

DPM++ 2M Karras -- най-доброто съотношение скорост-към-качество. Това ми е default-ът за почти всичко.
DPM++ SDE Karras -- малко по-добър при нисък брой стъпки. Добър, когато итерираш бързо.
Euler a -- все още надежден. Повече разнообразие в outputs, добър за exploration.

Кога да смениш:

Липса на разнообразие в outputs? Пробвай DPM++ SDE или Euler a.
Artifacts или oversaturation? Пробвай DPM++ 2M Karras или plain Euler.
Трябва ти скорост преди всичко? Euler a или DPM++ 2M (non-Karras).
Искаш максимално качество? DPM++ 3M SDE Karras или UniPC.

Брой стъпки: 20-30 стъпки за повечето samplers. Lightning моделите имат нужда само от 2-8.

CFG (Classifier Free Guidance)

Колко стриктно моделът следва prompt-а ти спрямо собствената си интерпретация.

Диапазон	Ефект
1-4	Много творчески, свободна интерпретация. Често incoherent
5-7	Добър баланс за повечето работа
7-10	Силно следване на prompt-а. Sweet spot за SDXL фотореализъм
10-15	Риск от artifacts и преготвени цветове
15+	Почти винаги прекалено. Artifacts гарантирани

Бележка: SD 3.5 използва различен guidance механизъм. Концепцията за CFG все още важи, но скалата се държи различно -- започни по-ниско (3-5) и настройвай оттам.

Резолюция

Дните на 512x512 свършиха.

Модел	Нативна резолюция	Практичен диапазон
SD 1.5	512x512	512x512 до 768x768
SDXL	1024x1024	1024x1024 (стандарт), 1024x768, 768x1024
SD 3.5	1024x1024	1024x1024+
Flux	1024x1024	1024x1024+, 4K е възможно на high-end GPU-та

Да минеш над нативната резолюция носи риск от artifacts и проблеми с композицията. Използвай hi-res fix или upscaling, вместо да генерираш директно на 2048x2048.

Clip Skip

По-малко релевантен е, отколкото беше.

SD 1.5: Clip skip 1-2 има голямо значение. Anime моделите често използват clip skip 2.
SDXL: Използва dual text encoders (CLIP + OpenCLIP). Clip skip до голяма степен се игнорира -- архитектурата го обработва различно.
SD 3.5 / Flux: Не е приложимо по същия начин. Тези модели използват transformer-based text encoding.

Ако си на SDXL или по-ново: не се тревожи за clip skip. Ако си на SD 1.5: дръж го на 1 за фотореализъм, 2 за anime.

Negative Prompts

Философията се обърна. През 2023 съветът беше да използваш дълги списъци с negative prompts. През 2026 консенсусът е: започни с нищо и добавяй само това, което ти трябва за поправка.

Защо промяната:

SDXL и Flux разбират естествен език много по-добре от SD 1.5
Дългите negative prompts всъщност могат да ограничат креативността и да влошат резултатите
"bad anatomy" е твърде неясно, за да е полезно. "ugly" не работи, защото SD не е трениран върху изображения, етикетирани като "ugly"
Някои модели се представят демонстративно по-зле с дълги negatives [5]

Актуалният подход:

Първо генерирай без никакъв negative prompt.
Ако видиш конкретен проблем (extra fingers, blurry background), добави targeted negative за него.
Използвай emphasis weighting: (blurry:1.3) вместо само blurry.
Дръж го кратко -- максимум 5-10 термина.

GPU бърз справочник

GPU	VRAM	Добър за
RTX 3060 12GB	12GB	SD 1.5, basic SDXL
RTX 4070 Ti	12GB	SDXL, малко Flux
RTX 4090	24GB	Всичко. Работната машина
RTX 5090	32GB	Всичко, включително 4K и batch generation
8GB карти	8GB	Минимално жизнеспособно. ComfyUI помага с VRAM management

Границата от 24GB е мястото, където нещата стават удобни за SDXL и Flux без постоянно жонглиране с VRAM.

Troubleshooting бързи поправки

Проблем	Пробвай
Blurry output	Увеличи steps. Провери дали резолюцията съвпада с native res на модела
Extra fingers/limbs	Добави `extra fingers, extra limbs` към negative prompt. Или използвай ControlNet
Oversaturated colors	Намали CFG. Смени на DPM++ 2M Karras
Композицията е грешна	Използвай ControlNet (depth, canny, pose), вместо да се бориш с prompt-а
Generation is slow	Използвай Lightning model, намали steps, използвай ComfyUI за по-добър VRAM
Out of VRAM	Смени на ComfyUI, намали batch size, използвай fp16

Източници

1. Flux 2 and NVIDIA RTX AI Integration -- Покритието на NVIDIA за Flux 2 с ComfyUI.
2. Stability AI Release Notes -- SD 3.0 deprecation и release-ът на 3.5.
3. SDXL-Lightning by ByteDance -- Генериране в 2-8 стъпки на 1024px.
4. ComfyUI vs Automatic1111 2026 Comparison -- Сравнение на performance и възможности.
5. How to Use Negative Prompts Effectively -- Обновен guide за минималистичната философия на negative prompts.
6. Understanding Stable Diffusion Samplers -- Сравнение и избор на samplers.
7. Best Stable Diffusion Models for 2026 -- Актуалният пейзаж на моделите.

Свързани публикации

Stable Diffusion фотореализъм: guide за настройки и GPU лимити -- дълбоко гмуркане в постигането на фотореалистични резултати с актуалните модели.

За мен

Thu, 04 May 2023 22:12:03 GMT

Страниците „За мен“ са странно нещо за писане. Накрая започваш да описваш себе си като непознат човек, а аз съм подозрителен към това.

Затова, направо. Аз съм Борис. Пиша софтуер от малко повече от четиринайсет години. Работата плаща наема, храни кучетата и ми дава проблем за дъвчене почти всяка сутрин — което, честно казано, е повече, отколкото много работи успяват да дадат. Тези дни съм backend половината на малък продуктов екип, някъде между Laravel, Docker и Kubernetes, най-често притеснен за опашки, които трябва да се изпразват по-бързо, отколкото се пълнят, и индекси, които растат по-бързо, отколкото ми се иска.

Преди софтуера учих математика в университета. Никога съвсем не спрях. Математиката е мястото, където отивам, когато светът стане прекалено шумен. Особено теорията на числата — има нещо честно в простото число, което не намирам на много други места. Голяма част от това, което пиша тук, започва оттам. Малък математически сърбеж. Наполовина разбрана медицинска статия. Френско изречение, което трябваше да прочета четири пъти. После дръпвам нишката и гледам какво още е вързано за нея.

Блогът е мястото, където се случва това дърпане. Нищо тук не е експертен труд. Чета медицина, която нямам работа да чета. Чета български и френски романи и се преструвам, че смогвам. Уча немски бавно, най-вече защото граматиката ме забавлява. Понякога пиша C++ на ръка. Не за работа — просто защото дисциплината сама по себе си е нещо. Есетата излизат от всичко това — тихи опити да запиша какво съм забелязал, преди да го забравя.

Живея в София. Две спасени кучета — Кожухка и Еклер — се грижат да не се вземам прекалено насериозно. Преди са се проваляли. Продължават да опитват.

Това е почти всичко. Поддържам и малка freelance табела под името Percepticus, за работа, която идва от уста на уста. Иначе текстовете са тук, а за останалото ми е добре да мълча.

Начало - Boris D. Teoharov (Български)

Слонова кост под кехлибар

Когато броячът се появи

Хората, които обичам, имат право да бъдат хора

Мога да бъда добър, без да изчезвам

Стълбът и бръшлянът

Стълб в поле

Професорът забрави бръшляна

Къде ще продължиш да го срещаш

Стълб, който можеш да прегърнеш

Малък финал

Където всички науки се срещат

Езикът е код от много високо ниво

Вратата, която не се отваря отвътре

Взаимно подравняване

Мозъкът не е мързелив

България говори

Инженерство, но честно

Отличността е вървенето

Ако не можеш да го обясниш на дете

Където всички науки се срещат

Малкият край

Моделът, който го нямаше

Градът, който го нямаше

Опашката, която никога не спря

Ядрената опция за масови изтривания: TRUNCATE + повторно вмъкване (MySQL/InnoDB)

Защо DELETE остава бавен (дори на парчета)

Ядрената опция: TRUNCATE + повторно вмъкване

Защо е бързо

Кога да го използваш (и кога не)

Използвай го, когато

Не го използвай, когато

Практическо правило за решение

Имплементация (SQL)

Имплементация (Laravel/PHP)

Капани, с които трябва да се съобразиш

Auto-increment се reset-ва

Foreign keys

Triggers

Дисково пространство

Replication / binlog

Ако ти трябва (почти) нулев downtime

Финална мисъл

Type 0 рефакторинг: стъпката преди първа стъпка

Истинската причина Type 0 да съществува: хората имат лимит на работната памет

Защо се казва „Type 0“

Проблемът, който Type 0 решава

Посягай към Type 0, когато...

Дефиниция, която можеш да използваш в екипа си

Защо изобщо да го назоваваме?

Четирите sub-pattern-а

0a. Method extraction (основата)

0b. Conciseness (намаляване на incidental complexity)

0c. Empathy (чиста четимост)

0d. Dead code removal (махане на лъжите)

Какво Type 0 не е

Основното обещание: запазване на поведението (и как да остане вярно)

Type 0 като повтаряем екипен ритуал

1) Реши обхвата (timebox помага)

2) Идентифицирай „гръбнака“ на кода

3) Приложи четирите sub-pattern-а по ред

4) Дръж „Type 0 checklist“ в PR-а си

Финална мисъл

Измий още една чиния: просто правило за постоянно чиста codebase

Метафората: готвене, чинии и код

Отзвук от занаята: в добра компания си

Защо допълнителната чиния има значение (дори когато си зает)

1. Ентропията е реална

2. Дългът се натрупва по-бързо, отколкото мислиш

3. Социалният сигнал

4. Momentum, не перфекционизъм

Как да практикуваш правилото "Измий още една чиния"

1. Приеми "Micro-Refactoring" като част от Definition of Done

2. Използвай Pull Requests като trigger за чистене

3. Автоматизирай лесните чинии

4. Вгради го в екипните норми

5. Знай кога да не миеш

Границата: една чиния, не мивката

Пример: да превърнеш messy function във функция, която можеш да тестваш

Последни мисли

Защо `DELETE` остава бавен (дори на парчета)

1. Pipe Operator (`|>`) – “Easy Peasy Lemon Squeezy”

2. `#[\NoDiscard]` – намерение, превърнато в оръжие

4. `php --ini=diff` – рентген за config drift

6. `array_first()` / `array_last()` – очевидното най-сетне съществува

7. `get_exception_handler()` (и по-добри fatal traces) – upgrade за observability