Если вы подумываете о покупке своего первого 3D-принтера, но ничего о них не знаете и не понимаете, с чего начать выбор, эта статья для вас.

Привет, Хабр! Я Денис Воденеев, директор отделения автоматизированного тестирования в IBS. Увлекаюсь 3D-печатью уже 5 лет — первый принтер купил в 2019 году.

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

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

Александр Кучук, эксперт сообщества Spring АйО, подготовил авторскую статью, в которой шагом показывает, как структурировать интервью, какие вопросы задавать, как рассуждать и что оценит интервьюер.

Кстати, Александр ведет репозиторий с заметками: https://github.com/qcha/JBook

👋 Привет, Habr!

Вы когда-нибудь пытались найти качественный open-source клон Pinterest — с real-time функционалом, полноценной архитектурой, удобным UI и современной технологической основой? Я — да. И не нашёл. Поэтому решил создать свой.

Представляю вам Pinterest Clone — мой pet-проект, над которым я работал в одиночку 4 месяца, чтобы воссоздать не просто копию, а полнофункциональную платформу с реальным пользовательским опытом, максимально приближённым к оригиналу.

Сегодня разберёмся, как сделать видеозвонки — ту самую фичу, без которой сложно представить современное общение в 2025 году, на примере реализации мессенджера.

Для этого мы познакомимся с WebRTC — технологией, которая позволяет приложениям устанавливать прямое соединение друг с другом для обмена аудио, видео и другими данными. Это мощный, но местами капризный инструмент, который требует понимания архитектуры, сигналинга и сетевых нюансов вроде NAT и ICE.

PRD-шаблон от Product Lead в OpenAI с 9 ключевыми разделами и детальными рекомендациями, подкрепленный кейсом Shopify Auto Write, который можно адаптировать для большинства AI-проектов.

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

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

Продолжаем наращивать базу знаний по System Design! В этот раз освятим использование Pub/Sub, Event-Driven Architecture, Distributed Systems, Leader Election. Посмотрим на их концепции и области применения при проектирование высокодоступных отказоустойчивых систем.

Хочу начать с личной предыстории. Давным‑давно, как и многие из вас, я читал умные книжки: «Чистый код» и «Чистая архитектура» Роберта Мартина, «Совершенный код» Стива Макконнелла и другие.

Также не обошли меня и классические принципы проектирования — SOLID, KISS, DRY — и, думаю, каждый читатель добавит сюда свои.

Безусловно, это всё важные и фундаментальные вещи.

Но однажды на горизонте появилось DDD — предметно‑ориентированное проектирование в изложении Эрика Эванса. Именно его «синяя книга» стала культовой и задала язык для архитектурного мышления.

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

Читая Эванса, рассматривая его диаграммы классов и примеры кода, я всё думал: как он это делает?

Самым большим открытием для меня стало то, что книга DDD хоть и показывает стратегические и тактические приёмы — агрегаты, объекты‑значения, спецификации, фабрики и т. д. — но не учит проектировать саму предметную область.

Складывалось ощущение, что мы это уже откуда‑то должны были знать. А откуда — остаётся загадкой.

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

90% стартапов в Кремниевой долине работают с менторами. А те, кто добирается до раунда А — все до одного. Просто потому, что без ментора туда не доезжают.

Пример? Просто погугли, сколько было менторов (эдвайзеров) в таких небольших компаниях, как Airbnb, Dropbox и Stripe. Их, в общем, не глупые люди построили.

Родительский контроль — это функции технических устройств, позволяющие ограничить доступ ребенка в сеть, экранное время девайса, установить разрешение на использование приложений. Но что разрешать и что запрещать, на что опираться, принимая такие решения? Тема актуальна семьям, чья жизнь плотно связана с устройствами. Наши дети постоянно видят родителей с девайсами, и с раннего возраста хотят повторять за нами. Но далеко не каждое приложение на телефоне может заинтересовать ребенка. Сначала родители предлагают ему мультики, а потом сетуют, что он только видео и смотрит. Можно ли с помощью родительского контроля выстроить адекватные привычки у ребенка?

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

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

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

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

Реакция на стресс с эволюционной точки зрения — это полезный механизм для выживания, который активирует реакцию “бей или беги”.

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

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

А чтобы ничего нас не отвлекало, мы не думаем о еде, о размножении и других делах, которые мгновение назад казались самыми важными в жизни.

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

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

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

В итоге от хронического стресса люди быстрее стареют. Раньше умирают. Даже простое заживление бытовых или послеоперационных ран протекает дольше на фоне стресса.

Почему 90% стартапов терпят крах при масштабировании? Как построить стратегию роста, которой действительно можно доверять?

Решите ключевые проблемы вашего стартапа: отсутствие системного подхода к масштабированию, преждевременный рост без PMF и непонимание последовательности шагов выхода на рынок.

80% ресурсов должны быть направлены на работающие GTM-стратегии, только 10-20% — на эксперименты с новыми каналами.

Узнайте, как превратить product-market fit в устойчивую модель роста через 9 критических этапов масштабирования от Шона Эллиса (создатель термина "Growth Hacking") и Маджа Вое

Привет Хабр! Меня зовут Татьяна Ошуркова, я системный аналитик и разработчик. В прошлом году у меня вышла статья Не UML-диаграммы на PlantUML. Обзор с примерами, где я рассмотрела различные диаграммы не в нотации UML, которые можно построить с использованием возможностей PlantUML. В этой статье я хочу разобрать построение и других диаграмм, которые использует системный аналитик в своей работе.

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

Особое внимание уделяется методам повышения надёжности при временных сбоях, включая: повторные попытки выполнения операций с экспоненциальной задержкой (exponential backoff), использование шаблона circuit breaker, механизмы плавной деградации функциональности (graceful degradation), задание таймаутов, реализация идемпотентности, ограничение одновременных вызовов (bulkhead isolation), а также внедрение систем мониторинга и алертинга. Приводимые примеры охватывают типовые сценарии — обращение к внешним API, взаимодействие с базами данных и выполнение фоновых задач.

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

Всем привет! Меня зовут Мельников Виктор, я работаю Junior Data Scientist в хабе Розничного Бизнеса Департамента Продвинутой Аналитики в Альфа-Банке. В этой статье я расскажу про AUF – Open Source библиотеку Альфа-Банка. 

Её главная задача — автоматическое решение задач uplift-моделирования.

Позволяет ускорять разработку в десятки раз и убирает рутину, избавляя от привычного fit-predict. Приятным бонусом идёт полный отчёт по качеству модели, понятный как DS, так и бизнесу.

Дисклеймер: эта статья не про uplift-моделирование, а про библиотеку, которая решает задачу uplift-моделирования. Если хотите почитать про общую постановку задачи, посмотреть на математику, лежащую в основе uplift, в конце статьи оставил раздел с ссылками на полезные материалы.

Всем привет! Меня зовут Саттар Гюльмамедов и я работаю в команде ETL платформы DataOps в МТС. Марк Твен как-то написал «Слухи о моей смерти сильно преувеличены» — про Big Data сейчас можно сказать то же самое. Волна хайпа, которую многие пытались оседлать, прошла. Но, как и значительная часть инженерных достижений, работа с большими данными стала рутиной, помогающей развиваться другим направлениям в ИТ. 

В экосистеме МТС мы строим для Big Data отдельную платформу, где есть инструменты для хранения и оценки данных, анализа и построения отчетов. Но все начинается с их загрузки и обработки. Получение и преобразование данных — как раз задача библиотек и сервисов, которые делает моя команда. Многие знают мем о перекладывании JSON. А мы как раз делаем инструменты для тех случаев, когда такие задачи уже не столь тривиальны и нужно разобраться с разными типами данных, разными структурам, хранящимися к тому же в разных форматах, и все это нужно сделать в рамках одного процесса.

В этом материале я расскажу про наши решения и условия, лежащие в их основе. Одним наш опыт поможет спланировать эволюцию своих инструментов, другим снимет страх перед сложным стеком технологий Big Data, а третьи просто развлекутся. 

Дисклеймер:
чтобы не отклоняться от темы, я не буду подробно описывать концепции ETL и ELT (они хорошо разобраны тут, тут и тут). Наши инструменты следуют парадигме «E[TL]+», т. е. позволяют выполнять трансформации данных как в процессе переноса, так и в целевом хранилище.

Про нашу платформу в общих чертах писал мой коллега Дмитрий Бодин в своей публикации «Customer Happiness: как не только разработать, но и внедрить новый продукт внутри крупной компании». Я продолжу начатый им рассказ и добавлю подробностей о компоненте ETL, его составляющих и нашей команде.

Как известно, чтобы получить понятный и полный ответ, нужно как можно лучше сформулировать вопрос. Из научной фантастики мы знаем, что «ответ на главный вопрос жизни, вселенной и вообще» это «42». Так зачастую и в ритейле, подходя к вопросу внедрения или замены одной из вспомогательной для бизнеса систем, вопрос формулируется следующим образом – «что нам даст внедрение новой системы?». Если вас не устраивает ответ 42 или 37, а также не устроит что-то в стиле «10%», нужно вложить в постановку вопросов гораздо больше смыслов.