Всем привет! Меня зовут Алексей, я тимлид команды разработки в SENSE. Как нанимающий специалист, я все чаще сталкиваюсь с кандидатами, которые притворяются разработчиками. Например, приходит человек, у которого в резюме 4 года коммерческого опыта, уверенный стек, проекты интересные. Думаешь: ну вот, наконец, нормальный разговор по делу. Но вместо этого – щелчки клавиатуры за кадром, невнятные паузы, ответы как заученные. А дальше ступор на задачах, а у некоторых «особенно одаренных» в коде «as per OpenAI suggestion».

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

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

Я расскажу о системе, к которой шел почти 18 лет, потому что системы GTD для обычных людей у меня не работали. Я пробовал ежедневники, Google Keep, Evernote, Notion, физическую белую доску для маркеров, делал локальный сайт на HTML, писал себе в личные сообщения и в канал в соцсетях и мессенджерах, пока, наконец-то, не дошел до Obsidian.

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

В результате этого оценивания уже можно “поиграть” показателями: время, ресурсы, качество (содержание) и приступить к подбору наиболее подходящего их сочетания. Так же, выявленные объемы и зависимости функциональности позволят делить будущий продукт на модули, подсистемы, контуры и прочие части, обеспечивая поэтапное воплощение, распределение ресурсов и ответственности, снижая риски провала благодаря дроблению. Для решения подобных задач нам очень пригодится умение эффективно определять Границы проекта и управлять ими.

Мало что настолько меня угнетает, как невозможность что‑либо понять так, чтобы потом объяснить это самому себе:) И хоть я уже давно не девятиклассник, этот период запомнился мне внезапным переходом от заучивания материала «чтобы не схватить парашу» к некоторой степени осознания «а как оно там устроено и почему именно так». Сложнее всего было с математикой и я постоянно изобретал для себя «объяснялки». Этот навык, к счастью, прижился и стал привычкой.

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

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

При нагрузочном тестировании баз данных Tantor Postgres или других на базе PostgreSQL с использованием стандартного инструмента pgbench отсутствие фиксации деталей окружения (таких как конфигурация СУБД, характеристики сервера, версии ПО) часто приводит к нерепрезентативным результатам и необходимости повторных тестов. В статье рассматривается разработанный автором инструмент pg_perfbench, который призван решить эту проблему.

Что объединяет частицу в воде, биржевой курс и кота Барсика, бродящего по району в поисках ларька с рыбой?

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

Мы начнём с истории открытия броуновского движения — от наблюдений Роберта Броуна до формулы Альберта Эйнштейна, которая связала наблюдаемое явление с атомной гипотезой. Покажем, как идея случайного движения превратилась из гипотезы в надёжный инструмент научного анализа.

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

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

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

Меня зовут Роман Ремизов. Я — системный аналитик ГК Юзтех. В рамках цикла статей «Хроники архитектурного дизайна» я делюсь своей экспертизой о разных автоматизированных банковских системах (АБС) и о том, что нужно знать перед тем, как приступить к архитектурному дизайну.

Данная статья, как и другие статьи этого цикла (первая статья доступна по следующей ссылке: [ссылка на статью Хроники архитектурного дизайна (Часть 1)]; вторая статья доступна по следующе ссылке: [ссылка на статью Хроники архитектурного дизайна (Часть 2)]; третья статья доступна по следующе ссылке: [ссылка на статью Хроники архитектурного дизайна (Часть 3)]), написана с допустимым уровнем конкретики и соблюдением NDA. Напомню: все банки разные и на других проектах могут преобладать иные как архитектурные, так и программные решения.

В этой статье мы обсудим работу с транзакциями на примере использования PostgreSQL.

Формирование сильной команды — задача, с которой сталкивается любой руководитель разработки. Однако одного понимания хардов и уровней квалификации часто бывает недостаточно. Настоящая управленческая работа начинается там, где появляются характеры, амбиции, скрытые конфликты и разные стили взаимодействия с задачами и людьми.

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

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

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

Предыстория

У нас двухнедельные спринты, в рамках которых с определённой периодичностью проходят груминги, на которых мы не только приоритизируем задачи, но и разбираем аналитику. Происходит это так: на регулярных встречах собирается вся команда, аналитики презентуют нам новую фичу/задачу, а мы задаём вопросы. Если все вопросы решены, либо что‑то можно быстро уточнить/устранить, то команда двигает эту задачу в статус «Готово к разработке». И мы командой тестировщиков определили, что во время грумингов презентация аналитики происходит быстро, мы не успеваем параллельно читать и слушать пояснения, а также придумывать на ходу вопросы. Нужен был процесс по тестированию требований.

За несколько итераций проведённых 1-to-1 я выяснила, что нам было бы удобно построить это следующим образом: разделиться на подкоманды согласно функционалу, который мы реализуем, и до груминга читать аналитику, разбираться, оставлять комментарии с вопросами в спокойной обстановке без строго ограничения по времени.

Привет! Меня зовут Абакар, я работаю главным техническим лидером разработки в Альфа-Банке.

Сегодня мы поговорим на тему, связанную с корутинами, а именно погрузимся чуть глубже в недра компилятора Kotlin. На данную тему мы с Александром Гиревым готовили доклад на «Мобиус».

В рамках подготовки доклада нам пришлось заглянуть в святая святых для всех «андроидеров», а именно в исходники компилятора Kotlin. Ну что ж, поглядим, что мы там накопали. Поехали!

Итак, вы решили использовать Angie как замену Nginx. С чего начать процесс? Какие аспекты нужно учитывать при переходе? Разберёмся со всем по порядку.

Напомню, что Angie является форком Nginx. Это значительно упрощает процесс переезда с Nginx на Angie, так как Angie поддерживает все возможности и директивы конфигурации, что и Nginx. Обратный переход с Angie на Nginx может быть уже не таким простым, если мы начинаем использовать уникальные возможности Angie (например, возможности проксирования или балансировки).

Начнём с подготовки системы к миграции.

Решил поделится историей о том, как взял IT ипотеку на 30 лет со ставкой 5% и несмотря на регулярные платежи после задержки с отправкой подтверждения о работе в IT компании, получил уведомление о потере сниженной процентной ставки по кредиту. Как решить такую ситуацию, которая сейчас «молча» набирает обороты.

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

В статье выделено несколько категорий таких некомпетентных лидеров.

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

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

Всё, как обычно, на основе исследований и примеров.

Приятного чтения!

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

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

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

В чём подвох? Часто проблема кроется в том, когда и как именно мы снимаем метрики во время тестирования.

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

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