Пятница, конец спринта. Команда сдала всё в срок. Клиент доволен. Тишина в эфире. Я смотрю на экран и понимаю, работу затащили, как и всегда, но какой ценой?
Команда не выгорела, а я — да.
Выгорел, следя, чтоб не выгорела команда — иронично.
Статья про то, как создавать клеточные лабиринты с помощью алгоритма Hunt&Kill + реализация на языке python.
Сидячая работа — профессиональное проклятие разработчиков. Проводя по 10 часов за кодом, мы часто игнорируем «звоночки» от поясницы, пока они не превращаются в полноценные прострелы. После очередного визита к врачу я задался вопросом: а можно ли использовать современные LLM, чтобы упростить жизнь пациенту и наглядно отслеживать динамику лечения?
Так появился Spine Advisor — десктопное приложение на Python, которое использует мультимодальную модель Gemini 3 Flash для «чтения» МРТ и ведения цифрового дневника спины.
Термин vibecoding появился в 2025 года, когда Андрей Карпатый описал подход: разработчик формулирует задачу на естественном языке, ИИ генерирует код. За год практика ушла от «вайбь и забыл» к осознанному использованию. Cursor, Claude, Copilot стали стандартом, границы возможного сместились в сторону агентов, оркестрации и автоматизации маркетинга. Для кого это важно и что именно меняется в работе продактов и фаундеров — ниже.
Привет! Меня зовут Фаина, я системный аналитик с опытом более 5 лет. В последнее время все чаще стала задумываться как системному аналитику в текущих реалиях применять в работе ИИ. Так началось мое погружение в увлекательный мир LangChain, ИИ, RAG и векторные БД.
Для начального исследования я решила попробовать что-то достаточно простое и базовое. Так в мою голову пришла идея создать ТГ бота, который напоминает о запланированных делах
Ребята, кажется, мы уперлись в стену. Пока гиганты наращивают параметры и жгут тераватты, пытаясь выжать каплю разума из статистики, я решил пересмотреть сам фундамент. Проблема не в данных, проблема в «вязкости» стандартного Attention.
Как я устал дебажить MAX API, отреверсил их вебхуки и отучил Cursor галлюцинировать
Когда я писал своего первого более-менее серьезного бота под Max, случилась классика. Я и мой ИИ-ассистент (Cursor) пишем код, строго опираясь на официальную документацию Max API. Запускаю — падает. Сижу по 5-6 итераций, пытаюсь отдебажить базовый функционал, который под ту же Телегу пишется с закрытыми глазами.
В какой-то момент меня это достало. Я понял, что проблема не во мне и не в галлюцинациях нейронки. Я просто включил логирование всех входящих POST-запросов и стал дампить реальные вебхуки, которые прилетают от серверов Max. Открыв логи, я понял, почему мы так долго буксовали: то, что написано в документации, и то, что прилетает по факту — это две большие разницы. А слепая привычка писать архитектуру под Telegram Bot API делает только хуже.
Различия с официальной документацией Max API (Docs vs Реальность)
Мода на то «вкат» в IT появилась задолго до пандемии и массового распространения удаленного формата работы. Я помню пасты на двачах и мемы про «300кк/наносек синьора-помидора» в 2016-2017 годах - уже тогда многие стремились попасть в эту сферу из-за высоких зарплат и относительно низкого порога входа. После распространения удалёнки, хайп вокруг вката вырос многократно: появилось ещё больше желающих работать, лёжа на шезлонге где-нибудь на Бали с ноутбуком на коленках и с коктейлем в руках.
На фоне стремления огромного числа людей вытянуть свой счастливый билет в сказочный мир больших зарплат, удалённой работы, гибкого рабочего графика и достаточно низкой ответственности за результаты работы по сравнению с другими профессиями, начал набирать популярность феномен накрутки опыта, который подавался как эффективный способ вкатиться сразу на высокую зарплату на должность миддла и выше, минуя низкооплачиваемые (а иногда вообще не оплачиваемые) стажировки и джуновские позиции.
Логика простая: в IT-сфере профильный диплом не нужен, опыт из резюме почти никогда не просят подтвердить официальными документами. Зачем в таком случае тратить годы на учёбу в профильном ВУЗе и самообучение, начиная свой карьерный путь с позиции стажёра, если можно продумать легенду (или попросить кого-нибудь с реальным опытом выдумать её для вас), поставить в резюме 3+ года опыта, потратить на подготовку максимум год (а с ментором – раза в два меньше), походить по собесам, получить оффер и сразу начать «рубить бабло»? Так делали многие, и у многих получалось.
На дворе конец 2023. Я только что уволился из Яндекса и скучаю по ячану, чуть меньше скучаю по этушке, вообще не скучаю по таскам, дедлайнам, ревью. Чтобы заполнить возникший информационный вакуум, пробую переключиться на реддит, hacker news, пикабу, вышивание крестиком, сканворды, пилатес — не то. Тогда мне в голову приходит гениальная идея: а почему бы не сделать свою имиджборду с авторизацией по корпоративной почте крупных российских компаний? Ячан для всех!
Первая мысль — взять готовый движок и допилить под себя, в открытом доступе уже есть: lynx, vichan, wakaba, kareha, fchannel. Потыкался — ничего не понятно. Как ленивый человек решаю, что надо писать своё.
На тот момент я:
Не понимал разницу между HTTP и HTTPS
Не знал, что такое handler, router, middleware
Считал, что DNS — это какой-то раздел электронной музыки
Думал, что куки и кэш — это одно и то же
Не без труда отличал header от body
Не мог пропатчить kde2 под freebsd
Короче говоря, я был именно тем человеком, который должен был писать проект с нуля. Цель понятна, надо выбрать инструменты. Я неплохо знал питон и c++... поэтому языком разработки выбрал Голанг. Мой опыт с Голангом на тот момент ограничивался прослушанным фоном на х2 ШАДовским курсом. Прослушал я его в автопоездке Москва — Челябинск. Не написал на Го ни одной строчки кода, но суммарно прослушал — именно «прослушал», ибо рассмотреть мелкий шрифт на экране телефона, будучи за рулём, решительно невозможно — около 30 часов материала. Написать свой движок имиджборды - хороший повод попрактиковаться.
Алгоритм Крускала (также алгоритм Краскала) - алгоритм, который преобразовывает связный неориентированный граф в минимальное остовное дерево. На самом деле пока что непонятно, что делает он, поэтому разберём поподробнее.
Итак, у нас есть связный граф, который хранится в виде списков рёбер (позже это будет важно). Предположим, у нас есть задание: нам нужно связать все вершины так, чтобы общий их вес будет минимальным. Если говорить более по-умному, нам нужно получить из графа именно это самое минимальное остовное дерево.
В центре всего стоит UX (User Experience).
Все говорят про UX.
UX - это святое.
UX - это цель.
UX - это путь.
Да и, в конце-то концов, UX - это то, за что мы платим (или не совсем) деньги и прощаем недостатки.
Но, если копнуть глубже, возникает вопрос: «А из чего, собственно, состоит UX?»
Ответы обычно примитивны: из интерфейса, удобства, скорости, привычности. Но, чувствуете, чего‑то не хватает? Есть системы с красивым интерфейсом, которые бесят. Есть и такие, «некрасивые», к которым возвращаешься снова и снова.
Готовых модулей для связки 1С с маркетплейсами сделали уже много, и на лендингах они все выглядят примерно одинаково: заказы, остатки, цены – все в комплекте. Разница проявляется позже — на возвратах, пересорте, маркировке, нескольких складах и попытках переехать на другую конфигурацию 1С без полной пересборки процессов.
После того, как нам самим пришлось искать решение для интеграции, решил поделиться и с народом – описать пять наиболее сильных по функционалу решений, которые мы рассматривали в первую очередь: что реально закрывают, где начинаются тонкие места, какие сценарии стоит прогнать на тесте.
Как мне удалось создать свой полноценный продукт с функционалом и системой лицензирования с нуля без навыков программирования используя и IDE Cursor. Полный разбор в статье по шагам с инсайтами.
Разработка требований обычно начинается с терминологии. Перед стартом проекта команда аналитиков формирует словарь проекта — единое пространство определений и артефактов. Это не формальность, однозначно трактуемая терминология напрямую влияет на качество требований.
В этой статье разберём ключевое понятие — функция. Понимание сущности функции Информационной Системы во многом определяет успех дальнейшего формирования функциональных требований.
Переработал известную копилку от AlexGyver: напечатал новый корпус, сделал печатную плату вручную, устранил помехи LC-фильтром и наступил на грабли с энергопотреблением. Под катом — схема, осциллограммы и выводы.
Вчера вечером листал Telegram и наткнулся на пост в канале midov_channel (пост 775). У Ислама обсуждается пост в reddit в котором активно дискутируют, что 211 тысяч звёзд у репозитория — это «Fake stars, боты накручивают» .
Активно использую последнию неделю OpenClaw , имею своё мнение, и понимаю почему такой вопрос возникает: 211 тысяч звёзд — это много. Конечно, когда видишь такие цифры, первая мысль — «а точно ли это настоящие люди?»
У меня профессиональная деформация - доверяй, но проверяй. Всё таки 15 лет развивал департаменты Data и аналитики в L'Oreal. Это также трансформировалось в текущий мой бизнес AYGA Data & AI, где мы, с агентамиработаю в формате AI-first компании, привыкли к другому подходу — не спорить, а проверять. Есть гипотеза — есть данные. Данные либо подтверждают, либо опровергают.
Собственно, поэтому вчера дал своему агенту Gubin задачу: собрать все 211 тысяч профилей stargazers репозитория и провести forensic-анализ. Не выборку, не 1% — все до единого.
Через полтора часа Агент Губин прислал мне в телеграмм презентация из 14 слайдов. Дальше — разбор каждого из листа презентации.
Всем привет! В этой статье поделимся тем, как с помощью LLM анализировать поток из сотен договоров в ракурсе рисков и экономить на этом в год сотни часов работы юристов.
Воздействие генеративного ИИ на окружающую среду
Быстрое развитие и внедрение мощных генеративных моделей ИИ сопровождается последствиями для окружающей среды, в том числе увеличением спроса на электроэнергию и потребления воды.
Адам Зеве | MIT News
17 января 2025 г.
Функцию rand из стандартной библиотеки языка Си для генерации псевдослучайных чисел, наверное, не ругал только ленивый. В довольно известном докладе Rand considered harmful рассказывалось о проблемах с переносимостью, ограниченным диапазоном, многопоточностью, качеством и т.п. Иногда в учебниках упоминают о том, что алгоритм в rand может быть не очень качественным, иметь проблемы с младшими битами, периодом, прохождением статистических тестов. Но крайне редко можно увидеть разбор конкретных критериев, выявляющих дефекты генераторов. В этой статье я постараюсь наглядно показать не просто отдельные недостатки rand, lrand48 и random из glibc, но их полную непригодность для каких-либо вычислений в принципе. Также вы увидите превосходство поточных шифров над minstd, линейным конгруэнтным генератором из 1980-х, не только в качестве, но и в производительности.
Всем привет!
Я недавно закончил подготовку курса по управлению проектами на основе 8-го издания PMBoK и у меня появилось время поделиться здесь своими мыслями по поводу особенностей управления проектами с разных точек зрения и в разных отраслях.
Сегодняшний пост будет, в основном, посвящен обзору PMBoK 8, его ключевым особенностям и отличиям от предыдущих изданий. На всякий случай, если кто вдруг не в курсе, PMBoK, также известный как Project Management Body of Knowledge или Свод Знаний по Управлению Проектами – это основной руководящий документ сообщества PMI (Project Management Institute https://www.pmi.org/). С момента своего появления в 1996 году, PMBoK пережил несколько переизданий, часть из которых оставили большой след в области управления проектами и в профессиональной жизни многих руководителей проектов.
Особняком стоит 7-е издание, на данный момент – предпоследнее, которое тоже сильно повлияло на отрасль и участников, но этот след справедливее было бы назвать травмой. Несмотря на наличие большого количества передовых идей и внедрение новых подходов, 7-е издание оказалось воспринято сообществом неоднозначно и скорее даже с негативом. Уж слишком радикальными и, что самое главное, не всегда релевантными и практически применимыми оказались нововведения. Да и в целом, документ производит впечатление какого-то компромиссного недоразумения, в котором собрали новые концепции, скопипастили определения и целые разделы из предыдущих изданий, но местами просто не проверили соответствие одного другому.