Мной давно не публиковались статьи и вот опять… Данная статья получилась не очень большой, но, надеюсь, полезной. Когда-то мы решили использовать для сбора метрик Prometheus, но… Спустя время, мы решили перейти на Elastic APM, т. к. весь стек для Elastic у нас уже был и мы решили поддерживать метрики в рамках этого стека.
Software Developer
20 вопросов, которые стоит задать IT-компании, прежде чем сменить работу
4 min
Если бы меня попросили дать один универсальный совет всем, кто ищет работу в IT, я бы сказал: не стесняйтесь задавать побольше вопросов. Мало приятного в том, чтобы через месяц осознать, что новая компания/должность — совсем не то, что вы искали. А если это вакансия с релокацией, цена ошибки возрастает в разы.
Узнав как можно больше о компании и должности, вы уменьшаете риск оказаться «в неправильном месте». Вместе с командой экспертов по поиску работы за рубежом из Relocate.me, мы собрали 20 вопросов, которые стоит задать, прежде чем пойти на работу в новую компанию.
Узнав как можно больше о компании и должности, вы уменьшаете риск оказаться «в неправильном месте». Вместе с командой экспертов по поиску работы за рубежом из Relocate.me, мы собрали 20 вопросов, которые стоит задать, прежде чем пойти на работу в новую компанию.
Как выжать максимум из Computer Science образования
10 min
Большинство современных программистов получили образование в вузах. Со временем это изменится, но сейчас дела обстоят так, что хорошие кадры в IT-компании все равно приходят из университетов. В этом посте Станислав Протасов, директор Acronis по связям с университетами, рассказывает о своем видении особенностей вузовской подготовки будущих программистов. Преподаватели, студенты и те, кто их нанимает, могут даже найти под катом пару полезных советов.
Переход от монолита к микросервисам: история и практика
17 min
В этой статье я расскажу о том, как проект, в котором я работаю, превращался из большого монолита в набор микросервисов.
Проект начал свою историю довольно давно, в начале 2000. Первые версии были написаны на Visual Basic 6. С течением времени стало понятно, что разработку на этом языке в будущем будет сложно поддерживать, так как IDE и сам язык развиваются слабо. В конце 2000-х было решено переходить на более перспективный C#. Новая версия писалась параллельно с доработкой старой, постепенно все больше кода было на .NET. Backend на C# изначально ориентировался на сервисную архитектуру, однако при разработке использовались общие библиотеки с логикой, да и запускались сервисы в едином процессе. Получилось приложение, которое мы называли «сервисный монолит».
Одним из немногих преимуществ такой связки являлась возможность сервисов вызывать друг друга через внешний API. Имелись явные предпосылки к переходу на более правильную сервисную, а в перспективе и микросервисную архитектуру.
Свою работу по декомпозиции мы начали примерно в 2015 году. Пока еще мы не достигли идеального состояния — остались части большого проекта, которые уже трудно назвать монолитами, но и на микросервисы они не похожи. Тем не менее, прогресс существенный.
О нем я и расскажу в статье.
Проект начал свою историю довольно давно, в начале 2000. Первые версии были написаны на Visual Basic 6. С течением времени стало понятно, что разработку на этом языке в будущем будет сложно поддерживать, так как IDE и сам язык развиваются слабо. В конце 2000-х было решено переходить на более перспективный C#. Новая версия писалась параллельно с доработкой старой, постепенно все больше кода было на .NET. Backend на C# изначально ориентировался на сервисную архитектуру, однако при разработке использовались общие библиотеки с логикой, да и запускались сервисы в едином процессе. Получилось приложение, которое мы называли «сервисный монолит».
Одним из немногих преимуществ такой связки являлась возможность сервисов вызывать друг друга через внешний API. Имелись явные предпосылки к переходу на более правильную сервисную, а в перспективе и микросервисную архитектуру.
Свою работу по декомпозиции мы начали примерно в 2015 году. Пока еще мы не достигли идеального состояния — остались части большого проекта, которые уже трудно назвать монолитами, но и на микросервисы они не похожи. Тем не менее, прогресс существенный.
О нем я и расскажу в статье.
Как работает конфигурация в .NET Core
9 min
Давайте отложим разговоры о DDD и рефлексии на время. Предлагаю поговорить о простом, об организации настроек приложения.
После того как мы с коллегами решили перейти на .NET Core, возник вопрос, как организовать файлы конфигурации, как выполнять трансформации и пр. в новой среде. Во многих примерах встречается следующий код, и многие его успешно используют.
public IConfiguration Configuration { get; set; }
public IHostingEnvironment Environment { get; set; }
public Startup(IConfiguration configuration, IHostingEnvironment environment)
{
Environment = environment;
Configuration = new ConfigurationBuilder()
.AddJsonFile("appsettings.json")
.AddJsonFile($"appsettings.{Environment.EnvironmentName}.json")
.Build();
}Но давайте разберемся, как работает конфигурация, и в каких случаях использовать данный подход, а в каких довериться разработчикам .NET Core. Прошу под кат.
Оптимизация сборки мусора в высоконагруженном .NET сервисе
16 min
Ежедневно в сервисе Pyrus работают десятки тысяч сотрудников из нескольких тысяч организаций по всему миру. Отзывчивость сервиса (скорость обработки запросов) мы считаем важным конкурентным преимуществом, так как она напрямую влияет на впечатление пользователей. Ключевой метрикой для нас является «процент медленных запросов». Изучая ее поведение, мы заметили, что раз в минуту на серверах приложений возникают паузы длиной около 1000 мс. В эти промежутки сервер не отвечает и возникает очередь из нескольких десятков запросов. О поиске причин и устранении узких мест, вызванных сборкой мусора в приложении, пойдет речь в этой статье.
Быстрорастворимое проектирование
25 min
Люди учатся архитектуре по старым книжкам, которые писались для Java. Книжки хорошие, но дают решение задач того времени инструментами того времени. Время поменялось, C# уже больше похож на лайтовую Scala, чем Java, а новых хороших книжек мало.
В этой статье мы рассмотрим критерии хорошего кода и плохого кода, как и чем измерять. Увидим обзор типовых задач и подходов, разберем плюсы и минусы. В конце будут рекомендации и best practices по проектированию web-приложений.
Эта статья является расшифровкой моего доклада с конференции DotNext 2018 Moscow. Кроме текста, под катом есть видеозапись и ссылка на слайды.
В этой статье мы рассмотрим критерии хорошего кода и плохого кода, как и чем измерять. Увидим обзор типовых задач и подходов, разберем плюсы и минусы. В конце будут рекомендации и best practices по проектированию web-приложений.
Эта статья является расшифровкой моего доклада с конференции DotNext 2018 Moscow. Кроме текста, под катом есть видеозапись и ссылка на слайды.
Мониторинг мёртв? — Да здравствует мониторинг
15 min
Наша компания с 2008 года занимается преимущественно управлением инфраструктурами и круглосуточной технической поддержкой веб-проектов: у нас более 400 клиентов, это порядка 15% электронной коммерции России. Соответственно, на поддержке очень разнообразная архитектура. Если что-то падает, мы обязаны в течение 15 минут это починить. Но чтобы понять, что авария произошла, нужно мониторить проект и реагировать на инциденты. А как это делать?
Я считаю, что в организации правильной системы мониторинга происходит беда. Если бы беды не было, то мой спич состоял из одного тезиса: «Установите, пожалуйста, Prometheus + Grafana и плагины 1, 2, 3». К сожалению, теперь так не работает. И главная проблема заключается в том, что все продолжают верить во что-то такое, что существовало в 2008 году, с точки зрения программных компонентов.
В отношении организации системы мониторинга я рискну сказать, что… проектов с грамотным мониторингом не существует. И ситуация настолько плохая, если что-то упадёт, есть риск, что это останется незамеченным — все ведь уверены, что «всё мониторится».
Возможно, всё мониторится. Но как?
Все мы сталкивались с историей наподобие следующей: работает некий девопс, некий админ, к ним приходит команда разработчиков и говорит — «мы зарелизились, теперь замониторь». Что замониторь? Как это работает?
Ок. Мониторим по старинке. А оно уже изменяется, и выясняется, что ты мониторил сервис А, который стал сервисом B, который взаимодействует с сервисом C. Но команда разработчиков тебе говорит: «Поставь софт, он же должен все замониторить!»
Так что изменилось? — Всё изменилось!
12 вопросов, которые стоит задать потенциальным работодателям
8 min
Translation
Я только что завершил шестинедельный процесс трудоустройства на должность middle-senior разработчика на рынке, где сейчас ведется активная охота за талантами (Амстердам). Иными словами, я побывал на куче собеседований. Чтобы аккуратно разведать, какие компании мне больше всего подходят, я старался задавать побольше вопросов. Тут нужно найти правильный баланс, исходя из своих потребностей и того, кто с вами общается.
Если вы джуниор в поисках работы, то вы, возможно, придете к выводу, что вас на самом-то деле мало интересует, что вам ответят на все приведенные ниже вопросы — вам бы хоть куда-нибудь устроиться. Но даже в этом случае, решите для себя, какие моменты для вас будут стоп-сигналами и спрашивайте с расчетом на то, чтобы всплыла нужная информация. Если есть что-то, что может вас заставить отказаться от вакансии, лучше узнать об этом до того, как примете предложение о работе.
Запланированные новые возможности C# 8.0
12 min
Translation
Все ранее представленные в минорных версиях C# средства, разработаны так, чтобы не сильно изменять язык. Они представляют собой скорее синтаксические улучшения и небольшие дополнения к новым возможностям C# 7.0.
Этот подход был преднамеренным, и он остается в силе.
Более серьезные изменения, которые требуют большей работы на всех этапах разработки (проектировании, внедрении и тестировании), по-прежнему будут выпускаться только с основными релизами языка. И хотя окончательная минорная версия C# 7 еще не выпущена, команда уже активно работает над следующей основной версией языка: C# 8.0.
В данной статье, я планирую представить подборку планируемых в настоящее время функций, которые, скорее всего, окажутся в финальном релизе. Все они находятся на ранней стадии разработки и могут быть изменены.
Антипаттерны тестирования ПО
31 min
Translation
Введение
Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.
В этой статье я хочу сделать шаг назад и перечислить высокоуровневые антипаттерны тестирования, общие для всех. Надеюсь, вы узнаете некоторые из них независимо от языка программирования.
Терминология
К сожалению, в тестировании пока не выработали общую терминологию. Если спросить сотню разработчиков, в чём разница между интеграционным, сквозным и компонентным тестом, то получите сто разных ответов. Для этой статьи ограничимся такой пирамидой тестов:
Если не видели пирамиду тестов, настоятельно рекомендую ознакомиться с ней. Вот некоторые хорошие статьи для начала:
- «Забытый слой пирамиды автоматических тестов» (Майк Кон, 2009)
- «Пирамида тестов» (Мартин Фаулер, 2012)
- «Блог отдела тестирования Google» (Google, 2015)
- «Пирамида тестов на практике» (Хэм Фокке, 2018)
Riot Games: анатомия технического долга
15 min
Translation
Привет, меня зовут Билл «LtRandolph» Кларк. Я работаю техническим руководителем команды создания чемпионов LoL. За последние несколько лет я успел поработать в разных отделах разработки League, но единственное, чем я был постоянно одержим — это технический долг. Мне нужно найти его, понять его и, при возможности, устранить его.
Когда разработчики обсуждают любую существующую технологию, например патч 8.4 League of Legends, то часто упоминают технический долг. Я называю техническим долгом код или данные, за которые придётся расплачиваться будущим разработчикам. Этой печальной стороне разработки ПО посвящено бесчисленное количество постов, статей и определений. В своём посте я хочу обсудить виды технического долга, с которыми мне пришлось встретиться при работе в Riot, и рассказать о модели, которую мы начали использовать в компании. Если бы меня попросили выделить самый важный урок, который можно извлечь из этой статьи, то я сказал бы, что это описанная ниже метрика «инфицирования».
Чтобы принимать правильные решения о том, какие проблемы необходимо устранить сейчас, а какие можно ставить на потом (или, будем реалистичными, совершенно забыть о них), нам нужен какой-то способ измерения каждого конкретного элемента технического кода. Я выбрал для оценки три основные оси измерения: влияние, затраты на устранение и инфицирование.
Когда разработчики обсуждают любую существующую технологию, например патч 8.4 League of Legends, то часто упоминают технический долг. Я называю техническим долгом код или данные, за которые придётся расплачиваться будущим разработчикам. Этой печальной стороне разработки ПО посвящено бесчисленное количество постов, статей и определений. В своём посте я хочу обсудить виды технического долга, с которыми мне пришлось встретиться при работе в Riot, и рассказать о модели, которую мы начали использовать в компании. Если бы меня попросили выделить самый важный урок, который можно извлечь из этой статьи, то я сказал бы, что это описанная ниже метрика «инфицирования».
Метрики
Чтобы принимать правильные решения о том, какие проблемы необходимо устранить сейчас, а какие можно ставить на потом (или, будем реалистичными, совершенно забыть о них), нам нужен какой-то способ измерения каждого конкретного элемента технического кода. Я выбрал для оценки три основные оси измерения: влияние, затраты на устранение и инфицирование.
Подборка ресурсов для соискателя на вакансию программист
2 min
Tutorial
Занимаясь с 2013 г. обучением Java и трудоустройством выпускников, я накопил достаточно большую коллекцию ссылок на темы составления резюме, онлайн тестов, подготовки к собеседованию и прохождения интервью, поиска работы и советов новичкам. Часть подходит всем кандидатам, часть (по подготовке) специфична для Java. Предлагаю Вашему вниманию эту подборку:
Как построить сообщество. Перевод книги «Социальная архитектура»: Предисловие. Мудрость толпы
10 min
Translation
В «Рассуждениях о первой декаде Тита Ливия» Никколо Макиавелли есть следующие строки: «Что же до рассудительности и постоянства, то уверяю вас, что народ постояннее и много рассудительнее всякого государя. Не без причин голос народа сравнивается с гласом Божьим: в своих предсказаниях общественное мнение достигает таких поразительных результатов, что кажется, будто народ ясно предвидит».
В своей книге «Мудрость толпы» Джеймс Шуровьески писал: «при правильных условиях группы могут быть очень умными, а зачастую могут быть намного умнее, чем даже самый умный человек внутри группы». Он заметил, что коллективный разум обычно показывает лучшие результаты, чем небольшая группа экспертов, даже если члены группы не владеют всеми фактами или ведут себя иррационально, поступая по-своему.
Другими словами, группа случайных людей в среднем будет умнее нескольких экспертов. Этот тезис противоречит здравому смыслу и выглядит насмешкой над накопленной веками мудростью. Эксперты в области человеческого интеллекта (социологи, антропологи, психологи) встретили идеи Шуровьески далеко не с распростертыми объятиями. Он пошел дальше: «добавив в группу специалистов, вы сделаете ее глупее, а добавив дилетантов, повысите опять ее интеллектуальный уровень. Как и любой рецепт, это работает только при определенных обстоятельствах».
Как правильно чистить лук, или Почему разработка ПО выходит из-под контроля
10 min
Translation
Вы придумали стартап и с самыми лучшими намерениями нанимаете разработчика для реализации своей идеи. Но идет неделя за неделей, а приложение по-прежнему нуждается в доработке. Как-то незаметно появляются новые функции, и масштаб задачи понемногу расширяется.
Складывается ощущение, что проект зажил собственной жизнью и пытается сожрать вас.
Как так случилось? Может, наняли плохого разработчика? Кто-то ошибся в планировании проекта? А вдруг сама идея проекта была ужасной?
Возможно. Но часто проект бывает с самого начала обречен на провал из-за недопонимания одного важного момента.
Мы предполагаем, что продукт определяется набором функций, записанных на листочке бумаги: иногда что-то добавляется, иногда убирается — но масштаб проекта всегда будто бы можно понять с одного взгляда.
Это предположение — неверно.
Проект — это не лист бумаги, не двумерный объект — у него есть глубина.
Каждую функцию на поверхности можно раскрыть — и так слой за слоем. Будь у меня склонность к громким заголовкам, я бы сказал, что всякое приложение — это лук, и нужно уметь правильно его чистить. Не очень понятно? Тогда давайте я поясню, что имеется в виду, и расскажу, почему не получается раскрывать слои приложения без слёз.
Переведено в Alconost
Одних тестов недостаточно, нужна хорошая архитектура
11 min
Мы все понимаем, что такое автоматические тесты. Мы разрабатываем софт, и хотим, чтобы он решал какие-то проблемы пользователей. Написав тест, мы убеждаемся, что конкретная проблема решается конкретным участком кода. Потом требования изменяются, мы меняем тесты и меняем код соответствующим новым требованиям образом. Но это не всегда спасает. Кроме высокого тестового покрытия наш код должен быть спроектирован таким образом, чтобы защищать разработчика от ошибок ещё при его написании.
В статье я постарался описать одну из проблем, которую может решить хорошая архитектура: связанные участки кода могут разъезжаться между собой, это может приводить к багам, и тесты тут не спасут. А грамотный дизайн может помочь.
В статье я постарался описать одну из проблем, которую может решить хорошая архитектура: связанные участки кода могут разъезжаться между собой, это может приводить к багам, и тесты тут не спасут. А грамотный дизайн может помочь.
Упрощаем лог действий пользователя
6 min
В предыдущих статьях мы сделали большое и доброе дело — научились автоматически собирать предысторию падения программы и отправлять её с крэш-репортом. Для WinForms, WPF, ASP, Javascript. Теперь научимся показывать все эти горы информации в удобоваримом виде.
Взламываем собеседования: по алгоритмам, по архитектуре, поведенческие и прочее
8 min
Translation
Я только что закончил семь собеседований в компаниях Кремниевой долины. В конечном итоге я принял предложение разработки программного обеспечения в Facebook.
Вот как я готовился к этим собеседованию и чему я научился на этом пути.
Мой многолетний путь в Кремниевую долину
Когда я изучал компьютерные науки в своем университете в Австралии, я всегда представлял свое будущее в качестве инженера-программиста в Кремниевой долине.
Мне понравилась идея быть в центре всех инноваций в технической индустрии, а также ее промахов. Эта цель мотивировала меня. Это помогло мне сосредоточиться.
Я оставил свое место в качестве ведущего инженера iOS в чудесной компании в Мельбурне и я вернулся обратно в мой родной город Перт, чтобы учиться. Тут я буду готовиться к переговорному процессу которое ждет меня в Кремниевой долине. Я знал, что это будет невероятно сложно и тяжело.
Если вы упомянули о техническом интервью в комнате с инженерами-программистами, многие будут выступать против обычных методов собеседования. Большая часть аргументов исходит из того, что решение алгоритмов на доске фактически не представляет повседневные задачи инженера-программиста.
Ради этой статьи я не буду вступать в эту дискуссию. Вместо этого я рассмотрю различные типы методов интервью с точки зрения кандидата. Я также сосредоточу внимание на том, что я узнал из этого процесса.
Собираем пользовательскую активность в JS и ASP
6 min
После написания функционала авторекордера действий пользователя, названного нами breadcrumbs, в WinForms и Wpf, пришло время добраться и до клиент-серверных технологий.
Начнем с простого — JavaScript. В отличии от десктопных приложений тут все довольно просто — подписываемся на события, записываем необходимые данные и, в общем-то, всё.
Начнем с простого — JavaScript. В отличии от десктопных приложений тут все довольно просто — подписываемся на события, записываем необходимые данные и, в общем-то, всё.
Открытый веб-интерфейс для .NET (OWIN)
6 min
Translation
Привет, Хабр! ASP.NET Core поддерживает открытый веб-интерфейс для .NET (OWIN), а OWIN позволяет отвязывать веб-приложения от веб-серверов. Он определяет стандартный способ использования связующего ПО при обработке запросов и соответствующих ответов. Приложения ASP.NET Core и связующее ПО совместимы с приложениями, серверами и связующим ПО на базе OWIN. Подробнее об этой паре читайте под катом.
