Когда вы ленитесь выйти из-за компа и заказываете доставочку, зарабатывают трое. 

– Сервис доставки 

Например, Яндекс.еда сразу скушает свой процент. 

– Ресторан/магазин 

– Курьер 

Человек, который пилит к вам и в дождь, и в снег. 

А еще зарабатываю я.

Я закончил московский политех (ранее МГТУ “МАМИ”) по специальности "конструктор-технолог литейного производства" с красным дипломом. В 2010 году пошел работать в Роскосмос.

Я всегда любил Терминатора. В детстве мы надевали чёрные очки и с чувством говорили:

«Hasta la vista, baby» (с исп. — «До свидания, детка»)

Но в 2020 году любовь кончилась. Тогда на меня подал в суд Арнольд Шварценеггер.

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

Изменения затронули не только внешний вид - это фундаментальный сдвиг в самом подходе к серверной разработке на JavaScript. Современный Node.js опирается на веб-стандарты, снижает зависимость от внешних библиотек и предлагает более понятный и приятный опыт для разработчиков.

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

Ну хорошо, ну есть у нас ИИ. Уже как 3 года он есть. А толку? Как его правильно впихивать в техпроцесс?

- Меня не надо впихивать!

- ЧЕМ ТЫ ЭТО СКАЗАЛ?

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

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

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

Спустя 20 лет эта идея выросла в производство с оборотом 30 млн рублей в год.

ДИСКЛЕЙМЕР: Статья написана на основе интервью с Антоном Сагдаковым — основателем производства кастомных автозапчастей Alania Motor Sport.

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

День системного администратора — самое время разобраться кожаным с железными.

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

Пару недель назад меня попросили помочь на техническом собеседовании для Senior/Lead backend-разработчика и поделиться опытом. В процессе я формализовал несколько правил, которых придерживаюсь при проверке кандидатов. Чем я и хочу поделиться.

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

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

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

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

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

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

Главная мысль: переработки плодят ещё больше переработок и гробят бизнес.

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

26 июня мне в Телеграм написал потенциальный клиент.

— Добрый день! Хочу пообщаться с вами на тему возможного сотрудничества по поводу UI/UX. Если кратко, это редизайн для электронного прибора (радиолюбительский КВ/УКВ приемопередатчик). Проект открытый, текущий дизайн я делал сам, но хочу переделать. То, что сейчас сделано, можно посмотреть на канале проекта.

Первая мысль: «Не мой клиент». Во-первых, я UX-дизайнер и привык делать прототипы и документацию, а не рисовать редизайн. Во-вторых, если проект открытый, денег там, наверное, не заработаешь.

Вторая мысль: «Зато интересно! Интерфейс для физического устройства. Даже если не смогу взяться за работу — познакомлюсь с интересным человеком. Может, порекомендую кого».

В общем, я точно не предполагал, какой у истории будет конец.

Всем привет. Я сеньор и тимлид на .NET (C#). До недавнего времени работал в Росатоме, пока там внезапно не сократили целую дирекцию по цифровизации. Так что пришлось срочно выходить на рынок, причём, впервые в моей жизни (до этого работа находила меня сама). По результатам нескольких циклов собеседований получился неплохой дневник, который я здесь привожу.

Всем привет! Меня зовут Александр Григоренко, я фронтенд-разработчик, и сегодня хочу поговорить о вопросах этики в интерфейсах и ценностях в разработке на примере одного моего недавнего собеседования. Это история о том, почему я отказался внедрять тёмные паттерны и не получил оффер на фронтенд-лида.

Всем привет! И снова с вами Илья Криволапов – системный аналитик в SENSE, где мы вместе с командой трудимся над проектом одного из цветных банков РФ. Напоминаю, что в профессии я уже больше пяти лет и, несмотря на фамилию, прод все еще живой и здоровый (ну почти)!

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

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

Материал будет полезен всем, кто проектирует, масштабирует или просто поддерживает «здоровье» базы данных: DBA, архитекторам, DevOps-инженерам, аналитикам и разработчикам.

Финальный рывок – поехали!

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

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

Следя за развитием HTML и CSS, очень сложно запомнить всё. Я заметил это, ведя свой канал и общаясь с коллегами. Многие люди не знают про возможности HTML и CSS, которые были внедрены в браузеры 6 лет назад или раньше.

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

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

Когда-то всё было проще. В достопамятные двухтысячные годы джунов и в самом деле нанимали. Не спрашивали о «релевантном опыте», не требовали ссылки на боевые проекты и не строили сложных лабиринтов из HR-интервью, технических сессий, тестовых заданий и многоступенчатых собеседований. Но прошло 15–20 лет — и всё изменилось до неузнаваемости. Новички (стажёры и джуны) теперь бесправны и даже подозрительны.

КДПВ

Обычно сервер ассоциируется с чем-то дорогим и недоступным обычному человеку. Даже на вторичном рынке они пока еще стоят весьма существенно (если не рассматривать совсем уж допотопные экземпляры). Однако, есть и такие, которые можно приобрести весьма недорого.

Это так называемые блейд-серверы. Блейд-сервер (от англ. blade — лезвие) – концепция использования нескольких компактных серверов в одной общей корзине (шасси). Некоторые узлы сервера (такие как блоки питания, охлаждение, сетевые адаптеры, управление) вынесены за пределы сервера и сделаны общими для всех. Благодаря этому исключается излишнее дублирование и, соответственно, уменьшаются габариты и общее энергопотребление всей сборки. Увеличивается плотность вычислительной мощности на единицу объема серверной стойки. Из-за того, что единичный блейд-сервер бесполезен без корзины, а в корзине избыточен, они не пользуются спросом на вторичном рынке, а потому стоят весьма недорого. 

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

Привет! Я давно в IT, настолько что верстал еще под IE6. Начинал ещё со школы: сервера Diablo II, боты mIRC, карты Warcraft III на JASS, код, форумы, общение и дикий, нескончаемый интерес. Без какого-либо понимания, что я делаю и куда меня это приведёт.

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

Заваривайте чай, расскажу вам свою историю как я попал в IT и вот уже лет 13 тут, приятного прочтения