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

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

Эта статья рассчитана на тех, кто ещё не знаком с очередями и RabbitMQ. Тем, кто уже знает как работать с RabbitMQ и хочет только изучить возможности, которые предоставляет MonsterMQ, я рекомендую посетить страницу проекта на github.com, где в описании подробно описано как можно использовать MonsterMQ без описания основ работы с RabbitMQ. Далее в этой статье будут рассмотрены основы работы RabbitMQ вместе с MonsterMQ.

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

«Человек может стать человеком только путем воспитания. Он — то, что делает из него воспитание»
И. Кант

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

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



В статье, перевод которой мы сегодня публикуем, представлен обзор 7 опенсорсных инструментов для мониторинга безопасности облачных систем. Эти инструменты предназначены для защиты от хакеров и киберпреступников путём детектирования аномалий и небезопасных действий.

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

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

Процесс загрузки разделим на три этапа. Для каждого этапа сформулируем общие стратегии повышения производительности:

1. Начальная отрисовка: сколько времени требуется, чтобы пользователь увидел хоть что-то
   
   • Сократить запросы, блокирующие рендеринг
     
   • Избегать последовательных цепочек
     
   • Повторно использовать соединения с сервером
     
   • Сервис-воркеры для мгновенного рендеринга
2. Загрузка приложения: сколько времени требуется, чтобы пользователь смог использовать приложение
   
   • Разбить пакет приложения на части. Загружать только необходимые ресурсы. Максимизация попаданий в кэш
     
   • Проверить, что хэши частей пакета не меняются без необходимости
     
   • Запрашивать данные для страницы до загрузки всего приложения
     
   • Не блокировать рендеринг загрузкой второстепенных данных
     
   • Рассмотреть рендеринг на стороне сервера
3. Следующая страница: сколько времени требуется для перехода на следующую страницу
   
   • Запрашивать дополнительный код до того, как он понадобится
     
   • Кэшировать и повторно использовать данные на клиенте

Если ваша компания только внедряет DevOps или инструменты CI/CD, вам может быть полезно познакомиться с самыми распространенными ошибками, чтобы не повторить их и не наступать на чужие грабли. 

Команда Mail.ru Cloud Solutions перевела статью Avoid These Common Pitfalls When Transitioning to CI/CD by Jasmine Chokshi с дополнениями.

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

Процесс деплоя у нас следующий: когда накапливается достаточное количество задач, прошедших тестирование из них собирается Релиз-кандидат (RC) в каждом проекте, затронутом задачами, затем задачи тестируются в составе RC. После этого RC заливается на стейджинг сервер, где в близком к боевому окружении все еще раз тестируется и проводится полный регресс. И затем, после необходимых деплойных действий свежий релиз заливается в мастер.

До недавнего времени весь процесс сборки проводился кем-либо из разработчиков вручную. Что отнимало час, два и больше времени и было, мне кажется, не очень интересным занятием. Теперь же, когда уже почти все готово, релиз из 20 задач, затрагивающий 5 проектов, собирается меньше минуты. Остается, конечно еще разрешение конфликтов, запуск пропущенных тестов и прочее, но даже с учетом этого, времени разработчиков и тестировщиков, вынужденных ждать, пока кто-то и первых освободится и создаст RC, экономится немало.

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

Представим команду, где не проводится Code review. Разработчики пишут код, и без проверок вносят все изменения в основную ветку. Спустя время расширяется функционал или находятся баги, они возвращаются к исходному коду, а там все переменные названы одной буквой, нет следования архитектуре, да и качество не самое лучшее. Этот некачественный код будет копиться и однажды наступит момент, когда, при любом мало-мальском нововведении, проект начнёт разваливаться: в лучшем случае – увеличится время разработки, в худшем – поддержка проекта станет невозможной. И это при том, что когда-то давно задача была выполнена и все хорошо работало.

Как этого можно избежать?

Kyiv Go Meetup May 2018:



Ведущий: – Всем привет! Спасибо, что вы здесь собрались! Сегодня у нас два официальных спикера – Лёша и Ваня. Будет ещё два, если у нас хватит времени. Первый спикер – Алексей Грачёв, он расскажет нам о GopherJS.

Алексей Грачёв (далее – АГ): – Я – Go-девелопер, и я пишу веб-сервисы на Go. Порой приходится сталкиваться с фронтендом, иногда приходится залазить туда ручками. Хочу рассказать о своём опыте и исследованиях Go на фронтенде.

Легенда такая: сначала поговорим, почему мы хотим запускать Go на фронтенде, потом поговорим, как это можно сделать. Есть два пути – Web Assembly и GopherJS. Посмотрим, в каком состоянии эти решения и что можно делать.

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


Анатолий Островский megatolya объясняет, как его команда решила эту проблему, и делится практиками, специфичными для Маркета, но в целом актуальными для любого большого сервиса. Его доклад основан на собственном опыте развёртывания нового маркетплейса в довольно сжатые сроки. Толя несколько лет руководил командой разработки интерфейсов в Маркете, а сейчас перешёл в направление беспилотных автомобилей.

Я десять лет тестирую и пишу код, а последние четыре года — тестирую доклады в программном комитете конференции Heisenbug. Сегодня расскажу о сквозных тестах, кросс-браузерности и ощущениях от использования Playwright версии 0.10.0.

Из конца в конец

Зачем нужны сквозные (end-to-end) тесты? Они управляют браузером и имитируют действия пользователя. Например, я описал пользовательские сценарии и хочу, чтобы они были проверены с каждой версией продукта. Проверять все сценарии для всех версий вручную — дороже и дольше, чем автоматикой.

Есть разные инструменты: Selenium, Puppeteer, Protractor, Cypress и другие. Две недели назад вышел новый инструмент — Playwright, над которым работал Андрей Лушников, разработчик Puppeteer. Эта библиотека полностью решает проблему написания кросс-браузерных тестов.

Веб-скрапинг — это метод сбора данных с веб-сайтов. Этот термин обычно используется в применении к автоматизированному сбору данных. Сегодня мы поговорим о том, как собирать данные с сайтов анонимно. Причина, по которой некто может захотеть анонимности в деле веб-скрапинга, заключается в том, что многие веб-серверы применяют определённые правила к подключениям с IP-адресов, с которых за некий отрезок времени выполнено какое-то количество запросов. Здесь мы будем пользоваться следующими инструментами:

• Puppeteer — для доступа к веб-страницам.
• Cheerio — для парсинга HTML-кода.
• Tor — для выполнения каждого запроса с различного IP-адреса.

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

Современные браузеры — это не только отличные приложения для просмотра веб-страниц.

Браузеры — это ещё и платформы, предлагающие веб-разработчикам массу удобных инструментов, помогающих создавать замечательные сайты. В распоряжении разработчика, помимо встроенных инструментов, есть огромное количество браузерных расширений. Автор статьи, перевод которой мы сегодня публикуем, отобрал самые лучшие, на его взгляд, расширения, которые призваны помочь программистам в решении самых разных встающих перед ними задач. Это, в основном, расширения для Google Chrome.

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

Но есть ситуации, когда без «крепкого словца» не обойтись. И чтобы не потерять свой имидж культурного человека, мы предлагаем вам целую коллекцию «mild curses» — легких ругательств и идиоматических выражений на английском языке, которые не считаются матами, но при этом помогут выразить всю палитру эмоций. Поехали!

Предлагаем вам познакомиться с переводом статьи Jamie Bullock, опубликованной на сайте medium.com. Автор рассказывает, какие веб-приложения он обычно использует в работе.

Однажды я разговорился с разработчиком из компании-клиента о программном обеспечении. Мне стоило бы понять то, что разговор пошёл куда-то не туда, когда собеседник сказал о том, как нам, разработчикам ПО, повезло: «Мы обманом заставляем организации платить нам за, как кажется, простую работу». Неважно — насколько некто продвинулся в деле написания кода, но я полагаю, что не стоит говорить обо всей индустрии разработки программного обеспечения как о чём-то вроде шайки мошенников.

Я не стал заострять на этом внимание, разговор добрался до Agile. Клиент, в целом, был открыт идее испытания новых методологий и улучшения своих рабочих процессов. Но — лишь до тех пор, пока я не упомянул о разработке через тестирование (TDD, Test-Driven Development). Единственным ответом на это была следующая фраза: «Значение TDD преувеличено».



Мне не только больно было это слышать, но это заставило меня понять то, что TDD — это ещё одна из тех Agile-методологий, которые могут выглядеть чем-то вроде «городских легенд». Это — то, что заставило меня написать данный материал, в котором мне хотелось бы обратиться к тем, кто сомневается в ценности TDD.

В коде самых разных проектов нередко приходится оперировать временем — например, чтобы завязать логику работы приложения на текущее время у пользователя. Старший разработчик интерфейсов Виктор Хомяков victor-homyakov описал типичные ошибки, которые встречались ему в проектах на языках Java, C# и JavaScript от разных авторов. Перед ними вставали одни и те же задачи: получить текущую дату и время, измерить интервалы или выполнить код асинхронно.



— До Яндекса я работал в других продуктовых компаниях. Это не как фрилансер — написал, сдал и забыл. Приходится очень долго работать с одной кодовой базой. И я, собственно, смотрел, читал, писал много кода на разных языках и увидел много чего интересного. В итоге у меня родилась тема этого рассказа.

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

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

Всвязи с этим, "Руководство компании Google по проведению ревью" выглядит очень ценным документом, перевод первой части которого и представлен далее. Переводы остальных частей выйдут позже отдельными постами. Стоит отметить, что это адаптированный перевод, не все переведено слово-в-слово, во имя более русских формулировок и предложений.

Терминология:

CL: "changelist" — список изменений кода, отправленный в систему контроля версий на ревью. Аналог Pull Request в GitHub или Merge Request в GitLab.

Привет, Хабр! Когда-то мы использовали метрику «Вроде бы стало лучше» для оценки качества наших релизов. Но потом мы решили довериться чему-то более надёжному. В этой статье я расскажу о том, как искал гайд по метрикам, не нашёл и создал свой.