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

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

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

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

Развитие происходит по спирали: когда-то люди не умели правильно индексировать, потом (в основном) научились, потом пришли noSQL и все снова забыли знание древних. Что вы будете делать, когда последние из старых DBA отплывут в Валинор?

Снова и снова и сталкиваюсь с полным набором антипаттернов индексирования. Я их перечислю, но! Для каждого антипаттерна есть исключение, когда именно это и стоит делать. Поэтому кликбейтно сформулированное правило верно в 95% случаях, но если вы хотите копнуть глубже, то прочитайте про исключения.

И в конце полезные скрипты для MSSQL, Postgres и MySQL.

Как Unicode уничтожает большинство ваших предположений о том, как на самом деле работают строки

Когда речь идет о написании чего-то простого, мы, программисты, обычно действуем интуитивно. В случае с простыми вещами мы полагаемся на четкий набор предположений вместо конкретных знаний о том, как эти вещи работают. Например, мы предполагаем, что если b = a + 1, то b больше a, или что если мы применим функцию malloc для какого-то буфера, то получим необходимое количество памяти для записи. Мы не заглядываем в документацию всякий раз, когда имеем дело с мелочами.

Мы делаем так, потому что тотальная проверка замедлит работу. Однако если бы мы все-таки провели проверку, мы бы обнаружили, что обычно ошибаемся в своих предположениях. Существует арифметическое переполнение, в результате которого a + 1 может быть значительно меньше, чем a. Иногда malloc дает нам null вместо буфера и мы оказываемся в пролете.

Нам обычно приходится обжечься на таких вещах, чтобы хотя бы немного изменить свои предположения. И даже тогда мы обычно исправляем их весьма условно.
Столкнувшись с досадной ошибкой переполнения, мы можем скорректировать свое предположение о целых числах в виде «a + 1 больше a, если отсутствует вероятность, при которой a представляет собой очень большое число». И мы действуем исходя из этого, вместо того, чтобы обдумать четкие правила, по которым работает переполнение.

Уточненные предположения – это опыт. Чаще всего они позволяют нам работать быстрее и правильнее. Однако мы можем вообще переместить некоторые вещи, например, правильную обработку malloc, из нашей внутренней категории «простые вещи» во внутреннюю категорию «сложные вещи». И тогда мы действительно можем пойти и уточнить, как они работают.

У нас в компании много иностранных проектов. Пройти интервью не всегда легко, даже если много и регулярно общаешься на английском. Поэтому наша команда преподавателей создала курс Project Interviews in English, который мы решили сделать доступным для всех желающих. Меня зовут Инна, я координировала создание курса и сегодня поделюсь  полезными советами из него.

Основано на реальных событиях.

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

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

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

 - Да, добрый день, друзья. – начинает Виктор. – Меня зовут Виктор, я принёс вас настоящий скрам. Предлагаю обсудить варианты сотрудничества.

Повисла неловкая пауза. С одной стороны, у меня в голове был целый ворох вопросов по методике и практике применения скрама, но они вряд ли подходили для собеседования. С другой стороны, я примерно представлял, кто такой скрам-мастер и чем он занимается, поэтому не знал, что спросить на тему «а чем вы у нас будете заниматься?». Но выручил Александр.

 - Итак, скрам... – Александр сложил ладони вместе, медленно опустил их на стол, выдержал паузу («завис»), будто обдумывая следующую фразу. – Иван заставил меня изучить, что это за методика, в рамках подготовки к этой встрече. Я сразу честно скажу – прочитал лишь половину книги. Поэтому, Виктор, если не затруднит, можете в двух словах рассказать, что именно хотите нам предложить? Чем будете заниматься, проще говоря?

Статья об одном неудачном решении, которое распространено при переходе на микросервисы. Несмотря на то, что Microsoft и другие компании в своих руководствах рассматривают возможность создавать Entity Services, есть все основания считать его антипаттерном. Далее мы поговорим о том, что такое Entity Service и какими свойствами он обладает для конечной системы в целом.

Зашла вчера в чат тестировщиков и вижу знакомый диалог:

— Мне в фирме 1 обещали фидбек через пару дней. В итоге неделя прошла, сам им пишу, а меня игнорят...

— Ага, я вот тоже собеседование в фирме 2 прошел, мне обещали ответ дать. А прислали просто отписку! «Вы нам не подходите», и всё.

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

Наши команды практикуют подход Trunk Based Development – новый код сразу добавляется в мастер-ветку, сторонние ветки живут максимум несколько дней. А чтобы коммиты не мешали друг другу, разработчики используют фича-флаги (Feature Flags) – переключатели в коде, которые запускают и останавливают работу его компонентов.

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

Если вы стремитесь сокращать Time-to-Market, это недопустимо долго. Чем раньше вы получите обратную связь от пользователей, тем скорее вы исправите ошибки, тем меньше времени вы тратите на неудачные идеи, тем больше ресурсов можете уделить идеям удачным.

Чтобы обновления быстрее доезжали до прода, одна итерация должна включать одну фичу. Именно поэтому нужно сокращать срок жизни веток.

Проблемы долгоживущих веток

Власти Сан-Франциско предупреждают, что переезд IT-работников может иметь «серьезные» экономические последствия для жизни города. По их словам, развитие удаленной работы во время пандемии вызвало резкий отток IT-сотрудников. В новом отчете они представили «убедительные доказательства эмиграции», в том числе снижение стоимости квартир на 25% за последний год — особенно в районах, где раньше жили сотрудники IT-гигантов.

Количество поисковых запросов о том, как выехать из города, у Сан-Франциско и Сан-Хосе на 120-150% превышает средний показатель по Штатам. Десятки тысяч людей уже уехали из города, ещё сотни тысяч — об этом задумались. Поскольку большинство крупных компаний объявили о перманентной удаленке, вероятность того, что все они вернутся, кажется очень призрачной. Эра Кремниевой долины как рая и итоговой цели многих айтишников — возможно, подходит к концу.

Более двух десятков лет назад мы разрабатывали устройство, передающее и принимающее данные, используя телевизионный сигнал. Это сейчас все избалованы гигагерцами и гигабайтами, а тогда, имея компьютер типа IBM/PC-AT, на таких скоростях можно было работать только с помощью встроенного контроллера прямого доступа к памяти (ПДП), реализованного в виде микросхем 8237А-5. Это устройство позволяло писать или читать данные, не привлекая центральный процессор.

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

И вот, при заключительном просмотре текста, я вдруг увидел глупую описку в программировании ПДП. Адрес в 16-разрядной 8237А-5 приходилось задавать по частям и при задании номера «станицы» (т.е. номера куска памяти в 128 Кбайт) вместо команды

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

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

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

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

Привет, Хабр! Представляю вашему вниманию перевод статьи "The agile swarm: How to design shareable work for software project teams" автора Stephen Frein.

^{Фото: Flickr}

Успешные аджайл-команды склонны ограничивать незавершённую работу (НЗП, незавершённое производство). Предпочитают ли они Скрам, Канбан-метод, или какую-либо другую аджайл-методологию, эти команды особенно выделяют над всем остальным быструю разработку полезной функциональности.

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

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

Язык программирования — это тоже продукт. Он помогает разработчикам выражать свои идеи так, чтобы их мог интерпретировать компьютер. Может показаться, что развивать язык — это брать последние достижения теории языков программирования, реализовывать их и из года в год выкатывать разработчикам. Это не так. Егор Толстой, Kotlin Product Manager, и Андрей Бреслав, руководитель проекта Kotlin, рассказали, зачем JetBrains бесплатный язык программирования, как он устроен и откуда приходят новые пользователи. Статья вдохновлена выпуском подкаста make sense о Kotlin.

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

Мы начали делать Kotlin десять лет назад, а первый релиз вышел зимой 2016 года. Изначально он задумывался как язык, который улучшит жизнь Java-программистов. Сейчас на Kotlin пишут даже приложения для браузеров и iOS. Современный Kotlin — универсальный язык программирования с большим количеством приятных для разработчиков фич, статически типизированный, заточенный под большие проекты и поддержку крупных кодовых баз.