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

В нашей организации используется такой подход к разработке - на локальной машине (Windows 11) установлен PhpStorm и находится репозиторий с кодом. В PhpStorm настроена автоматическая выгрузка изменений на dev-стенд (внешний сервер), где и исполняется код. На dev-стенде: Ubuntu 20 и Docker (swarm mode).

Общий принцип настройки Xdebug таков:

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

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

Ещё одна статья на избитую тему? Да! Потому что за два часа поиска не нашёл ни одной, по которой можно было пройтись от и до и получить работающее окружение.

Шагов, на самом деле, немного, все очень простые, нужно лишь...

В статье рассказывается про процесс Code Review, подходы к реализации, как использовать в команде и на что обращать внимание во время Code Review.

Code Review - это процесс проверки и анализа кода задачи разработчиком перед ее релизом. CR (Code Review) выполняется не тем человеком, который делал задачу, а другими членами команды. Результатом CR является обратная связь по выполненной задаче: необходимость внести правки, либо готовность задачи к последующему тестированию и релизу.

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

Всё это я проговаривал на вебинаре в Хекслете тут https://www.youtube.com/watch?v=y_HkXvFovAc

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

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

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

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

Первоначальная идея. Сначала разъяснить все английские времена за один присест удавалось, надёргав различных идей из интернета: обрывки чьих-то схем, начинали склеиваться в свою схему и обрастать собственными легендами, а применение времён почти всегда было проще пояснить, используя хрестоматийную «систему английских времен с точки зрения употребления глагола “to vodka”». С каждой новой импровизированной лекцией, схема и нарратив продолжали меняться. «Ученики» попадались с различным базовым уровнем, что позволило понять, откуда нужно начинать плясать, чтобы урок был понятен всем, кто хоть раз слышал что-то про глаголы have и be. Когда счёт обученных уже пошёл на десятки, я решил оформить идею в более стройную лекцию. От первых попыток преподавания английских времён, до этого момента прошло пять лет. За это время было обучено ещё пару сотен человек. Обучено — по приколу. Денег за эти уроки я не брал.

Приветствую.

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

Дом-КУБОИД - 1х1,618 - 14400х9000х4200 - 1этаж

ТЭП (выборочные):
- габариты = 14400 х 9000 х 4200 (возможно 4400 будет оптимальней с учетом парапета);
- площадь застройки = 130м2 (+ пристройка 58м2; + отмостка 74м2);
- площадь полезная вутренняя = 98м2 или 103м2;
- высота потолков в чистоте = 3600мм;

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

Оба дома являются универсальными заготовками:

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

Оба дома максимально равнозначны.
Таким образом остаются в основном субъективные нюансы - кому что больше нравится.

Стоимость вышла ~ на 20% выше, энергоэффективность на 10-20% ниже, чем у дома серии КУБ - с другой стороны площадь крыши и террасы увеличились.

В следующей статье сравню эти 2 варианта дома.

З.Ы. :

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

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

Приветствую.

Задача - построить правильный дом "с нуля" и "под ключ" по цене квартиры.

В этой первой статье из цикла будет дана вся вводная информация о доме, который буду строить для своего постоянного проживания.
Старт март-апрель 2021 года.
Мск и ближнее МО.

В моем распоряжении на все про все (дом, участок итд итп) 10,00 млн. руб

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

З.Ы. :

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

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

Три мысли всё не давали мне жить спокойно:

1) есть ноутбук, но для работы нужен второй экран
2) давно мечтаю о пульте управления для Photoshop в дополнение к клавиатуре
3) на полках пылятся устаревшие гаджеты, которые продавать глупо, а выкидывать жалко

Вопросы код-ревью меня интересуют очень давно. Много раз возникали те или иные проблемы то с качеством кода, то с климатом в коллективе. И действительно, code review — это если не единственное, то одно из самых главных мест для возникновения конфликтов в коллективе разработчиков.

И вот недавно при подготовке к очередному выпуску подкаста "Цинковый прод" я узнаю, что Google опубликовал свод правил по проведению Code Review, битком набитый ценными мыслями. Весь материал довольно объемный и не влезет в одну статью, поэтому я постараюсь выделить наиболее интересные (мне) мысли.

Итак, поехали

• Полную беспроводную автоматизацию всего освещения.
• Установил кнопку «выключить всё».
• Сделал возможным полное удаленное обесточивание квартиры (включая и сам сервер управления вместе с контроллером) и обратное удаленное включение.
• Применил электронакладки (устройства поворота) для кранов на воду.

Вы вряд ли найдете в интернете что-то про разработку ботов, кроме документаций к библиотекам, историй "как я создал такого-то бота" и туториалов вроде "как создать бота, который будет говорить hello world". При этом многие неочевидные моменты просто нигде не описаны.

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

Подробный гайд о том, как работать с ботами — под катом.