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

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

На моем компьютере всё работало!» — фраза, после которой начинается многочасовой дебаггинг. Вы открываете requirements.txt, а там свалка: непонятные версии, транзитивные зависимости и библиотеки, которые вы вообще не ставили.

Pip — отличный установщик, но ужасный менеджер проектов. В 2025 году стыдно таскать за собой «портянку» из текстовых файлов. В этой статье я покажу, как Poetry превращает ад зависимостей в скучный и предсказуемый процесс. Разберем pyproject.toml, магию lock-файла и переедем с Pip за 5 минут без боли.

Внутри: туториал, гайд по миграции и честный разбор минусов (да, Poetry тоже не идеален).

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

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

«Я трёх жён бросил, девушку бросил, курить бросил, а работу бросить не могу», — это был 2016 год, передо мной в кафе сидел тимлид крупной компании и нервно ел эклер за эклером. Ему было очень плохо, и это было видно. Он выгорел, устал, буквально погас: у него было всё, чтобы сменить хоть компанию, хоть страну, но были бесконечные страхи. Это тормозило карьеру, мешало развитию, не давало возможности вырасти. Понадобилось ещё 5 лет, чтобы решиться и в корне изменить жизнь. За эти пять лет перевернулся мир и многие возможности обрезали обстоятельства, однако даже то, что получилось, сделало человека счастливее. Он остался в ИТ, но сменил стек, профиль, сферу и главное, отказался от управления людьми, которое ему и правда совсем не подходило. 

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

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

На сегодняшний день алгоритмические задачи встречаются не только в FAANG. Многие компании и на отечественном рынке всё чаще вводят дополнительный алгоритмический этап на собеседовании – и знание алгоритмов становится отличным «плюсиком» не только при трудоустройстве, но и в решении повседневных задач. Взглянем подробнее на эти паттерны.

Здравствуйте, товарищи! Сегодня у нас будет не техническая статья. Я расскажу об одном нестандартном кейсе из своей практики, суть которого отражена в заголовке.

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

Как обычно: все имена вымышлены, а совпадения случайны...

Почему бы не запустить своё ядро прямо на смартфоне? Без Android, без Linux — только Rust, загрузчик и паяльник. В этой статье расскажу о результатах своего эксперимента, как оживить голое ARM-железо, увидеть первые символы в UART и даже вывести что-нибудь на экран.

Первый Docker-образ для моего Go-приложения весил 1.92 GB. Для микросервиса на 100 строк — абсурдно. Решил разобраться, куда именно уходит место и как добиться максимально лёгкого образа.

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

Эта статья — впечатления о моём 600-дневном марафоне на этой платформе, динамике моих скилов и ответе на главный вопрос «надо ли решать там задачи?».

Все было спокойно, пока мы с другом не заключили спор — сможем ли мы решить 100 задач до конца 2023 года? А это было 50 задач всего за 1 месяц — декабрь.

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

Челлендж в 100 задач оказался достаточно легким — Новый год мы встречали уже с круглым числом выполненных задач в профиле. Так быстро мы решили не останавливаться — Покоренная вершина стимулировала покорить новую — 200 задач к началу лета (за 5 месяцев).

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

24 февраля 2024 в течении недели Leetocde предлагал неплохие и не очень сложные задачи на дейли челлендже, и у меня случайно получился стрик в районе 10 дней подряд.

Сбивать стрик было как‑то жалко — это же целых 10 дней. Так и началась долгая история в 600 дней...

Мне повезло в жизни, так как моя учительница русского языка и литературы в старших классах была педагогом с большой буквы. В выпускном классе мы особенно любили пятничные уроки литературы - читали стихотворение малоизвестного (нам) поэта или слушали песню какой-нибудь рок-группы и писали мини-сочинение об услышанном За спиной у нашей учительницы висел небольшой плакат с правилами и рекомендациями по написанию текстов. На эти правила она указывала, когда объясняла, как улучшить нашу малограмотную подростковую писанину.

Одно из правил - буквально слово в слово - я недавно встретил в одном популярном эссе о написании кода без ошибок (я расскажу об этом правиле позже). Мне стало любопытно, насколько применимы остальные правила со школьного плаката (короткий ответ – да), и есть ли у этого обоснование. Я немного зарылся в литературу, и вот что понял.

Когда хорошая идея становится популярной - все начинают пересказывать её "как поняли". В итоге в информационном поле от изначальной идеи остаётся настолько мало, что её перестают воспринимать всерьёз. В этой статье я хочу рассказать о двух таких идеях: Scrum и ООП

Команда JavaScript for Devs подготовила перевод статьи, в которой разработчик с восьмилетним опытом работы с React делится неожиданным открытием: Solid.js оказался проще, логичнее и… приятнее в использовании. Меньше перерендеров, ближе к нативному вебу, честное поведение API и настоящие веб-компоненты — кажется, у React появился достойный конкурент.

Каждую секунду в дата-центры Cloudflare в 330 городах отправляется 84 миллиона HTTP-запросов. Из-за этого даже самые редкие из багов возникают достаточно часто. На самом деле, именно наши масштабы позволили нам недавно обнаружить в компиляторе Go на arm64 баг, вызывающий состояние гонки в генерируемом коде.

В этом посте мы расскажем о том, как впервые столкнулись с багом, исследовали его и докопались до его первопричины.

В последнее время поймал себя на том, что меня успокаивает процесс создания плат, от разводки, до пайки и я какое-то время вынашивал идею, что неплохо было бы сделать какую-то свою отладочную плату, например, с программированием по USB. Но зачем что-то придумывать без веской причины, тогда как можно взять готовый проект, например, Arduino UNO или Digispark и заодно подсмотреть, как там все устроено. Поэтому я ухватился за эту идею.

Эта статья — рассказ о том, как я собрал клоны Arduino UNO и Digispark, сделал три разные платы расширения своими руками и протестировал две из них, купленные в магазине.

Попробуем сделать Arduino UNO DIY — свой ответ Arduino UNO Q.

Мы с командой, как и многие, вели рабочие переписки в Telegram. Постоянно теряли задачи во флуде и мемах, забывали о договорённостях и тратили часы на поиски нужных сообщений.

Тогда мы решили взять лучшее от Telegram и сделали свой корпоративный мессенджер — который помогает фокусироваться на работе.

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

Давно я ничего не писал для джунов. А ведь HTML и CSS не стали проще для них. Всё так же есть сложности, и мне надо как-то помочь людям.

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

Давайте посмотрим, что я вам подготовил.

Данный курс является продолжением образовательной программы в области проектирования Информационных систем (далее ИС). В рамках этой части - «Архитектура ИТ решений», мы с Вами рассмотрим вопросы проектирования и организации, применительно к большим глобализационным системам.

Часто, когда отдельные ИТ-системы, по мере развития цифровизации начинают объединять в более крупные, всеобъемлющие решения, команды сталкиваются с проблемами восприятия:

Ещё в 2009 году Тим Бернерс-Ли написал веб-спецификацию под названием «Socially Aware Cloud Storage», ориентированную на защиту общественных интересов при реализации облачных хранилищ:

«Есть такая архитектура, в которой несколько сетевых или веб-протоколов собираются воедино для создания всемирной системы, где приложения (десктопные или веб) способны работать поверх уровня стандартного хранилища, предоставляющего возможность чтения/записи.

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

Несколько таких идей активно обсуждались в цифровой среде в конце 2000-х, вскоре после взрывного развития монолитных платформ эпохи Web 2.0 вроде Facebook*.

Ещё одну схожую по духу концепцию в то же время предлагали разработчики Opera, которые хотели «встроить в ваш браузер веб-сервер».

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

Чем больше строк кода за спиной, тем отчётливее чувствуется «песок в глазах» после вечернего ревью. Эта статья — попытка собрать в одном месте практические ходы — от выбора вариативных шрифтов до реактивного переключения тем по кривой солнечного спектра — которые позволят зрелым разработчикам продолжать писать осмысленный код, а не эпитафии своему зрению.