Как стать автором

Всем привет!

Это моя первая статья на Хабре, решил поделиться с общественностью своей идеей и тем, чем последнее время я занимаюсь в свободное время.

Любая критика (а также предложения и/или пожелания) категорически приветствуются.
Приятного чтения!

Идея

Не так давно по состоянию здоровья вынужден был погрузиться в мир глюкозы и ее мониторинга. В продаже довольно много всяких‑разных глюкометров, которые с более‑менее приемлемой точностью помогают мониторить уровень глюкозы. Но, в наш век информационных технологий, электромобилей и умных домов подавляющее количество этих устройств — это просто «экранчики с кнопками», показания которых никуда нельзя передать, никак нельзя экспортировать (ну кроме банального переписывания в тетрадку с экрана). В общем, говоря «современным языком» умных домов — по большей части эти устройства «глупые». К слову, да — я в курсе про системы непрерывного мониторинга уровня глюкозы и про них здесь тоже будет сказано (спойлер — не все так радужно в тамошних королевствах).

В начале ноября после очередной шок-статьи, оказавшейся пустышкой, у меня появилась идея сервиса, который будет анализировать новости при помощи ИИ — рассказываю, что я делаю, и что из этого всего получается.

Это реальная история, не байт.

Красивая картинка про Нидерланды скрывает подводные камни: тяжелый рынок жилья, визовое рабство, зверские налоги и увольнение через месяц. Делюсь личным фэйл‑кейсом и рабочим планом, как пройти это спокойнее.

Набил шишки в релокации и теперь делюсь опытом.

Мне важно подсветить риски и поделиться стратегиями, которые помогут увеличить твои шансы на успех, в свое время не нашел подобных кейсов — теперь описал свой.

Здорова! Меня зовут Женя Урбановский, бывший iOS- и действующий Golang-разработчик.

Уезжал в Нидерланды по рабочей визе, с опытом зарубежных проектов, жил в странах СНГ, учился во Франции, обкатал Европу и сейчас живу в Польше.

Я не дам план переезда в страну Х, но передам опыт, который помог мне сохранять свои нервы и иметь большую уверенность в другой стране.

Многие хотят создать продукт и в целом все мы «знаем» что надо делать.

История о том, как я пытался запустить свой продукт — и почему многие зная идею продукта не доходят до запуска как и случилось у меня (IMHO).

Привет, Хабр!

Вы когда-нибудь мечтали о роботе, который не просто выполняет команды «едь прямо» или «поверни налево», а может обидеться на вас за глупый вопрос или радостно подмигнуть, увидев кота? Я тоже. И решил, что хватит мечтать — пора собирать.

Казалось бы что может быть проще и банальнее, чем обновить зависимости во фронтенд-проекте? Но зачастую даже опытные мидлы делают это не правильно и ставят себе палки в колеса. Давайте разберемся почему так происходит и как этого избежать.

Маркетологи говорят нам: купи увлажнитель, купи очиститель, купи ионизатор. Но никто не говорит про главное — углекислый газ.

Ты можешь сидеть в кристально чистой комнате с идеальной влажностью, но если CO2 там зашкаливает за 1500 ppm — твой мозг превращается в хлебушек. Ты устаешь, делаешь баги и хочешь спать.

Готовые мониторы стоят от 5 до 15 тысяч рублей. Внутри — датчик за тысячу и три светодиода.

Я решил, что переплачивать за пластиковый корпус не буду. Берем паяльник (или просто провода), ESP32 и делаем инструмент, который покажет правду.

Существует ряд ошибок, которые подрывают доверие к продукту. Одна из таких — потеря пользовательских данных. Мне пришлось столкнуться с этим лично, когда мой отзыв пропал при попытке публикации. В этой заметке — разбор UX-проблем и то, как мой фидбек привёл к конкретным изменениям в алгоритмах 2GIS.

Все началось с того, что я хотел включить свет в туалете, а он включился через три секунды.

У меня стоял шлюз Xiaomi, датчик движения Aqara и какая-то ноунейм релешка. Схема работала так: датчик видит меня -> сигнал летит в Китай на сервер Xiaomi -> там скрипт думает -> сигнал летит обратно ко мне в квартиру -> свет включается.

В тот момент я понял две вещи.

Первая: я не хочу, чтобы товарищ майор из Пекина знал, как часто я хожу в туалет.

Вторая: мой дом не должен превращаться в тыкву, когда провайдер проводит плановые работы.

Ниже рассказ о том, как я выкинул все проприетарные шлюзы, купил один свисток и поднял Home Assistant.

За 18 часов вместо 120 создал production-ready ETL-инструмент с 30-кратным ускорением. За 6 часов вместо 40 — фреймворк статистического анализа. Экономия времени: 85-88%. Улучшение качества: +48%.

Rust все популярней, а вместе c этим создается много библиотек для Python на Rust.
В данной статье узнаем, как создать простенькую библиотеку для Python на Rust на примере кодирования данных в Base 64.

Когда бизнес-логика обработчика запроса выходит за рамки одной транзакции, код быстро обрастает ручными откатами и сложной оркестрацией. Большие системы вроде Temporal решают эту проблему, но требуют собственной инфраструктуры и сложного деплоя — не всегда возможного, особенно в коробочных решениях. Floxy предлагает другой путь: лёгкий встраиваемый Saga-движок на Go, реализующий оркестрацию и компенсации без внешних сервисов, брокеров и YAML DSL для вашего приложения — только чистый Go и PostgreSQL.

В С++ 20 появились coroutines (далее буду называть их корутинами, по‑русски). Если кратко — они позволяют писать асинхронный код также как мы пишем синхронный. При этом асинхронный код это не обязательно должен работать с несколькими потоками. Асинхронным может быть код исполняемый в одном потоке.

Под капотом компилятора корутины — это просто синтактический сахар (syntax sugar). Т.е. корутины не создадут дополнительных потоков. Компилятор заменит корутины вызовом нескольких функций и не более того. Но давайте посмотрим как корутины выглядят в коде.

В этой статье я буду делать простейший таймер на основе корутин. При этом напишу классы, для Awaitable и Promise, которые необходимы для работы корутин.

Laravel завоевал авторитет у бизнеса и программистов за эффективность решения задач. Автор не раз встречал суждение среди коллег, что опыт разработки на Symfony и Laravel равнозначны. Это миф. Ниже — 7 ловушек Laravel и практичных решений без отказа от фреймворка.

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

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

Я сделал её максимально практичной — так, чтобы у вас был реальный инструмент, с которым можно дойти до результата: построить модель, разобраться в экономике проекта и подготовиться к разговору с инвестором.

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

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

Поехали.

Я работаю старшим фронтенд-разработчиком в it-отделе одного из крупнейших федеральных застройщиков. Специфика разработки в такой непрофильной компании — сроки спускаемые сверху и вообще не имеющие корреляции с реальными ресурсами и возможностями команды. Именно поэтому мы работаем очень быстро, постоянно пытаясь получить (максимум результата)*3 за (минимум времени)/4.

В этих условиях мы делали большие интеграции с headless CMS Directus и непосредственно с бекендом, используя моковые данные на фронте.
Интеграции были большие и быстрые — и вот тут-то и стало видно, что большинство фронтенд-разработчиков не очень понимают, как подготовить интеграцию, чтобы потом было быстро и не больно заменять моки на реальные ответы. В этой статье пойдет речь о таких подходах на фронтенде,

Привет, Хабр! Недавно у меня появилась задача - собрать RAG-систему для интернет-энциклопедии. В поисках решения я вышел на новый подход к гибридному RAG - “DAT: Dynamic Alpha Tuning for Hybrid Retrieval in Retrieval-Augmented Generation” (Динамическая настройка Альфа-параметра для гибридного поиска в RAG). 

Поиск по Хабру и Рунету показал, про подход DAT на русском языке еще не рассказывали, поэтому спешу поделиться находкой с вами и обсудить преимущества и недостатки этого метода. Эта статья - упрощённый пересказ научной работы. Материал будет интересен как продвинутым, так и начинающим разработчикам RAG-систем.

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

А что на счет самих данных, если мы их рассматриваем как продукт? Как будем оценивать их ценность, как будем планировать их развитие?

В статье предлагаю экспериментальный набор UX‑метрик: они помогут увидеть, где ваш продукт реально теряет пользу для пользователя. Методика готова к тестированию — цифр пока нет, но каркас для расчётов уже работает.

За полгода активного использования Cursor IDE я была поражена тем, насколько этот инструмент изменил мой подход к работе. Разработка превратилась в удовольствие: поэтапное планирование, реализация, умные подсказки – агент выполняет задачи активно, быстро и, что самое главное, практически именно так, как я хочу.

Конечно, всегда есть к чему придраться, но существенных минусов становилось все меньше. Cursor-подобные IDE и LLM постоянно развиваются: с переходом на последние модели и увеличением контекстного окна, мощь инструмента достигла такого уровня, что повседневные задачи решаются за минуты, и я уже практически не задумываюсь о технической рутине.

Казалось бы, недостатков почти нет. Однако, всякий раз, приступая к новой задаче, я начинала новый чат. Мне не хотелось перечитывать свои диалоги недельной давности, искать там контекст. Но настоящая проблема возникает, когда задача переходит ко мне от другого разработчика. У меня нет доступа к его диалогу с чатом. Я не знаю, почему он принял те или иные решения, какие варианты он и AI отбросили. Мне приходится заново вводить Cursor в суть задачи, тратя время на объяснение того, что AI-агент моего коллеги уже знал.

Еще одной проблемой всегда остается отсутствие наглядного понимания хода проекта. Глядя на код, я вижу результат, но не процесс. Я не вижу, как менялась логика принятия решений и куда движется архитектура. Git Log дает мне сухие факты ("изменен файл X"), но не дает ментальной модели.

Получается парадокс: наши локальные AI-агенты умнеют с каждым днем, но как команда мы страдаем от "коллективной амнезии" и отсутствия единой картины мира. Именно это натолкнуло меня на идею Когнитивного слоя проекта (Project Cognition Layer). Если у нас уже есть инструмент, который идеально хранит историю всех изменений (Git), почему бы не "накинуть" на него когнитивный слой, понятный и человеку, и AI?

От красивых демок к законченным проектам: что я понял за полтора года работы с Claude Code

Я не программист. Я гуманитарий, который научился использовать ИИ для создания рабочих приложений. Но если эта статья поможет и вам господа разработчики, то моя гуманитарная тушонка будет вопить от счастья.

В общем с чем я столкнулся. С тем, что с виду все в ИИ кодинге красиво, но по факту большой проект, например свою LMS ты не соберешь, ИИ сдохнет.

Проблема была не в промптах и не в архитектуре. Просто процесс разработки с ИИ постоянно буксовал: Claude выдавал код с API прошлого года, поиск нужной функции занимал по 15 минут, после третьего рефакторинга я терял нить и бросал проект, начинал терять что было сделано, сколько не суй ему to-do листы.

Потом я нашёл свой стек из MCP-серверов, которые действительно повысили эффективность в разных случаях от 2 до 8 раз, позволили экономить до 80% токенов, не терять контекст и совершать на 8 из 10 ошибок меньше.