DXF-вьюер в браузере — это не «показать картинку». Это разбор формата, который живёт в серой зоне между CAD и мусором из десятка версий стандарта.

Проблема простая: у DXF нет единого «правильного» рендера. Один файл может содержать:
- разные кодировки и версии;
- примитивы, которые каждый движок трактует по-своему;
- блоки, слои, атрибуты, XREF’ы и прочую радость, которую нельзя просто взять и отрисовать как SVG.

Если вьюер уходит на бэкенд, он обычно делает 3 вещи:
1) парсит DXF;
2) нормализует геометрию;
3) рендерит в растер или вектор.

Это дорого по CPU и плохо масштабируется. В браузере задача упирается в другое: как быстро распарсить файл, не положить main thread и не убить память на больших чертежах. И да, 2D-чертёж может оказаться тяжелее, чем кажется: десятки тысяч сущностей, миллионы точек, огромные polyline’ы.

Вывод: «просто показать DXF» — плохая формулировка. Правильная инженерная задача звучит так: какой подмножество DXF поддерживаем, где парсим, как кэшируем и что делаем при деградации. Именно там и заканчивается магия.

IT-рынок сейчас часто ломается не на коде, а на оценках.

Кейс простой: задача на генерацию PDF ушла в «1 день» у тимлида. На деле там были:
— backend-модуль с полями и записью в БД
— pixel-perfect верстка под кривой движок типа dompdf
— предпросмотр документов
— учет шрифтов, сетки, таблиц, отступов

Для фронта это не «быстро сверстать», а отдельный мини-проект. Реалистичная оценка — 7–10 дней, если без магии и с нормальной приемкой. 📌

Проблема рынка в том, что сроки часто считают сверху вниз без технического декомпоза. Потом включают переработки, давят на команду, а после релиза просто заменяют людей, как расходник. Это уже не про разработку, а про управленческий брак.

Нормальная практика:
1. дробить задачу на backend / frontend / QA / интеграции
2. фиксировать риск по PDF-движку и вёрстке
3. считать не “сделать”, а “сделать и принять”

Если оценка не бьется с реальностью — это не проблема исполнителя. Это сигнал, что проектом управляют в ручном режиме.

ЕЮ Иванов продолжает кошмарить АффПапу, конторку, которая накинула говна на вентилятор этим летом. Тогда в AffPapa не знали, с каким говном идут бодаться, поэтому заслуженно проиграли. 😏

На этот раз ЕЮ зарегал товарный знак AffPapa — совсем скоро имя компании будет официально принадлежать ему. Чтобы убедиться в трушности мува, переходим по ссыл-Очке и вводим серийный номер: 2026793242. Там видим, что заявка на регистрацию подана лично Евгением Юрьичем.

Всё это выглядит забавно, но давайте не забывать, в какой сфере мы работаем и что реально может произойти с жирным троллем за воровство нейминга. Впрочем, толстому не привыкать отхватывать пиздов за проделки в интернете, поэтому ждем очередную фотку разбитого ебала и длинный пост с извинениями. 😏😏😏

В арбитраже денег нет 💵

Китай не делает «один Falcon 9-клон». Он гонит сразу несколько платформ — и это инженерно логично.

Ставка не на один идеальный носитель, а на параллельный эксперимент:
- разные топлива: керосин / метан / гибридные схемы
- разные двигатели и компоновки
- разные профили возврата ступени: посадка на ноги, на платформу, частичная reuse-модель

Зачем так распыляться? Потому что многоразовость — это не «приземлили ракету и победили». Там сразу куча узких мест: тепловые нагрузки, ресурс ЖРД, точность ГНСС/ИНС на посадке, повторяемость старта, стоимость межполетного обслуживания.

Параллельные программы дают главное: данные. Не презентации, а телеметрию, отказные сценарии и статистику по реальному reuse.

Итог простой: пока SpaceX масштабировала одну архитектуру, Китай строит несколько конкурирующих траекторий развития 🚀 Это медленнее на уровне PR, но быстрее на уровне инженерного обучения.

Алиасинг памяти в C++ — это когда компилятор и разработчик видят в одном и том же адресе разные типы. И вот тут начинается веселье: стандарт разрешает агрессивные предположения, а значит UB ловится не на этапе запуска, а ещё на этапе оптимизаций.

Что важно:
- через `char`/`std::byte` можно смотреть на сырые байты;
- через `reinterpret_cast` — не значит, что доступ легален;
- strict aliasing даёт компилятору право выкидывать «невозможные» перезаписи.

Практический эффект: код, который «работал годами», ломается после обновления GCC/Clang или смены флагов оптимизации. Не баг компилятора. Это цена за более жёсткие предположения в IR и лучшее переиспользование значений.

Будущее у темы тоже не гладкое: комитет пытается уменьшить число ловушек, но полностью убрать UB нельзя без потери производительности и совместимости ⚙️

Если пишете системный код, проверяйте:
- границы lifetime;
- типы доступа к памяти;
- где у вас реально сырой байтовый слой, а где уже объектная модель.

Теневая система в SEO — это когда у сайта есть один robots.txt на бумаге и другой в логах.

Де-юре: «все важные страницы доступны, sitemap актуален, индексация под контролем».
Де-факто: Googlebot тратит crawl budget на мусор, параметрические URL, дубли, JS-обвязку и служебные страницы.

Как проверить, есть ли у вас тень:

1. Берём лог-файл за 7–14 дней.
2. Считаем, куда реально ходит бот: % хитов по типам URL.
3. Сравниваем с sitemap и приоритетами бизнеса.

Если 40–70% обхода уходит не на посадочные и товарные страницы — у вас не «сложный сайт», у вас расхождение между архитектурой на схеме и архитектурой в жизни.

Ещё один маркер: в Search Console страницы «вроде бы важные», но crawl rate на них ниже, чем на фильтры и дубли. Это не магия. Это сигнал, что поисковик видит сайт не так, как его описали разработчики и SEO.

Лечение не в лозунгах про «ускорить сайт». Лечение — в нормализации URL, жёстком контроле индексации, чистом internal linking и проверке по логам после каждого релиза. 🔧

ИИ в разработке — это не магия, а изменение unit economics.

Если смотреть как техдир, вопрос не «ускоряет ли AI кодинг», а что происходит с LTV команды:
— сколько часов реально экономится на типовых задачах;
— где уходит маржа на ревью, исправления и интеграцию;
— как меняется cost per feature.

На практике AI-assisted хорошо режет время на:
— boilerplate;
— черновой код;
— поиск по базе знаний;
— первичный рефакторинг.

Но есть жёсткий офсет:
— больше шума в коде;
— выше цена ревью;
— растёт риск скрытых багов, если нет тестов и жёстких контрактов.

То есть экономика меняется не линейно. Если в команде слабый QA и размытые требования, AI может не ускорить delivery, а просто перенести работу из разработки в багфикс. 📉

Правильная метрика тут не «сколько строк сгенерили», а:
— cycle time;
— defect rate;
— % задач, ушедших в rework;
— себестоимость релиза.

AI даёт профит только там, где процесс уже измеряется и контролируется. Иначе это не ускорение, а дорогой генератор технического долга.