Художник
Досталась мне от бати книжка издания 1973 года, отпечатанная на ротапринте. Наткнулся в ней на вещи, которые бы мы сейчас назвали проблемой "выгорания". Термина в то время еще не было, но проблема была. Я выписал кое-какие вещи чисто для себя, но потом решил все же опубликовать, может кому пригодится...
В своё время я сам здорово намучился с английскими временами. Совершенно не получалось понять, как они формируются. Когда наконец удалось вызубрить все правила, самые простые существующие между временами закономерности всё равно оставались для меня неочевидными.
Как это часто бывает, по-настоящему понимаешь какую-то тему, только когда начинаешь рассказывать о ней другим («метод Фейнмана»). Несколько друзей, позавидовав моим «успехам», попросили помочь разобраться с английским. Тут и обнаружилось, что хотя я уже успешно использую английский в повседневной работе, обучать ему кого-то ещё — это совершенно отдельный навык.
Первоначальная идея. Сначала разъяснить все английские времена за один присест удавалось, надёргав различных идей из интернета: обрывки чьих-то схем, начинали склеиваться в свою схему и обрастать собственными легендами, а применение времён почти всегда было проще пояснить, используя хрестоматийную «систему английских времен с точки зрения употребления глагола “to vodka”». С каждой новой импровизированной лекцией, схема и нарратив продолжали меняться. «Ученики» попадались с различным базовым уровнем, что позволило понять, откуда нужно начинать плясать, чтобы урок был понятен всем, кто хоть раз слышал что-то про глаголы have и be. Когда счёт обученных уже пошёл на десятки, я решил оформить идею в более стройную лекцию. От первых попыток преподавания английских времён, до этого момента прошло пять лет. За это время было обучено ещё пару сотен человек. Обучено — по приколу. Денег за эти уроки я не брал.
В данной статье приведен опыт инженера-сетевика по развертыванию виртуальной лаборатории EVE-NG в домашних условиях, для целей подготовки к экспертным экзаменам Cisco.
Я постарался собрать все основные вехи настройки, разбросанные по статьям в интернете и попытался добавить в топологию, попутно изучая, ansible — систему управления конфигурациями. Черновик статьи появился случайно, поскольку мне стало жаль терять накопленный опыт и решил сохранять его в отдельный файл. Вот его я и представляю на ваш суд.
Ситуация с тем-самым-вирусом сильно бьёт по организаторам мероприятий. Людям, которые помогают сообществу разработчиков России, сейчас тяжело. Мы в AvitoTech хотим поддержать своих друзей из Онтико, и поэтому открываем доступ к видео с конференций, которые ещё не публиковались. Это доклады за 2019 год с Saint AppsConf, HighLoad++, DevOpsConf, FrontendConf, Product Fest и с последней TeamLead Conf.
Инженеры Авито, которые выступали или были участниками конференций, вспомнили самые интересные доклады. Под катом — ссылки на плейлисты со всеми-всеми видео и наша субъективная подборка.
UPD: добавили в статью плейлисты с UseData и GolangConf 2019.
Я хотел бы рассказать об опыте применения практик DDD к существующему Ruby on Rails проекту. Изначально, мы имели монолит, который писался 10 лет. Основная трудность проекта была в достаточно сложных процессах, и высокой связанности. Нам удалось не только декомпозировать приложение на отдельные сервисы, но и существенно повысить читаемость кода, сделать описываемые процессы прозрачными.
Решение задач в рамках системы стало предсказуемым, мы перестали работать с черным ящиком, и в конечном итоге система сама стала подсказывать нам решения.
Для облегчения как восприятия, так и написания, рассказ о применяемых подходах будет представлен в виде цикла статей. Данный подход не является "серебряной пулей", поэтому я бы хотел выделить прежде всего тот сегмент проектов, которым это решение сможет подойти. Далее, я более подробно расскажу о DDD методологии и микросервисной реализации данного паттерна, распишу возможные комбинации применяемых паттернов с учетом их имплементации, и в конечном итоге приведу пример конкретной реализации одного небольшого сервиса.
Порой диву даёшься, чего только люди не сделают «на блокчейне». С середины 2017 я занимаюсь аудитами безопасности смарт-контрактов и повидал всякого. В отдельную категорию я бы выделил «применения блокчейна», которые выглядят логичными и полезными, но в основе содержат проблему. И кочуют из стартапа в стартап вместе с ней. Здесь я рассмотрю ряд таких примеров, опишу проблемы и неработающие способы решения. После прочтения этого текста вы будете знать, с каких вопросов стоит начать, если вам как разработчику/клиенту/инвестору предложат такое «применение блокчейна».
Пусть мы заказали доставку товара и перевозчик обязуется по дороге соблюдать условия хранения, например, поддерживать низкую температуру. Предлагается следующее решение: устанавливаем в грузовик датчик, который регулярно публикует температуру в холодильнике в блокчейн. Таким образом, можно проследить историю температуры и убедиться, что условия хранения были соблюдены на всём пути.
