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

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

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

Привет, Хабр!

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

Для наглядности я приведу примеры кода разработанного сервиса на JEE7 под сервер приложений IBM WebSphere Liberty Server, а в качестве системы обмена сообщениями будет выступать IBM MQ.
Тем не менее, описанный метод подходит и для других аналогичных платформ, т.е. в качестве системы обмена сообщений может выступать любой поставщик JMS API, а в качестве сервера приложений любой JEE сервер (например, Apache Tomcat).

Дефицита технических материалов о Kotlin нет, узнать о корутинах или nullability можно много где. Но остаётся куда менее освещённой другая сторона: а как вообще выглядит процесс разработки языка? Как принимаются решения? Каковы задачи у «самого главного человека»? Остаётся ли у него в жизни время на что-либо ещё?

И сейчас, когда вот-вот выйдет Kotlin 1.3, мы расспросили «самого главного» Андрея Бреслава не про корутины, а про совсем другое: от того, чем он занимался до Kotlin, до того, чем полезна психотерапия.

(Иллюстрация)

Одна из задач, с которой сталкиваются 99,9% разработчиков, — это обращение к сторонним endpoint’ам. Это могут быть как внешние API, так и «свои» микросервисы. Сейчас все и вся бьют на микросервисы, да. Получить или отправить данные просто, но иногда изобретают велосипеды. Можете назвать 5 способов реализации запросов на Java (c использованием библиотек и без)? Нет — добро пожаловать под кат. Да? Заходите и сравните ;)

Привет, Хабр. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.

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

Чтобы непрерывно улучшать большие клиентские интерфейсы, нужна мощная система автотестов. Разработчик Яндекса Дмитрий Андриянов dima117 кое-что про это знает — пару месяцев назад он поделился своим опытом на Я.Субботнике в Нижнем Новгороде.


— Сегодня я расскажу, как мы в Директе пишем модульные тесты на веб-интерфейс. Мы в целом посмотрим, чем тесты на интерфейс отличаются от других тестов. Рассмотрим два подхода к написанию тестов: с помощью Selenium и с помощью Headless-браузеров. И в конце покажу инструмент, который мы написали в Директе для запуска тестов в Headless Chrome.

Представьте, что у вас есть всего один тест с использованием Selenium. Что может сделать его нестабильным? Как его ускорить? Теперь представьте, что тестов стало два. Теперь представьте сотню. Как заставить быстро отработать такую кучу тестов? Что произойдет, если количество тестов продолжит расти?

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

Прототипом этой статьи является доклад Саймона Стюарта на Heisenbug 2017 Moscow. Саймон — создатель WebDriver, технологии, которой сейчас почти 11 лет. Он стал руководителем проекта Selenium около 9 лет назад. В Google занимался масштабированием Selenium, от нескольких десятков тысяч до нескольких миллионов тестов каждый день, на их инфраструктуре. Затем перешел в Facebook. В данный момент занимается разработкой спецификации WebDriver для W3C, которая входит в группу тестирования и тулинга в W3C. Можно сказать, что на основе WebDriver и создается стандарт.

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

Сегодня мы поговорим о внедрении микросервисной архитектуры в Центре Финансовых Технологий (ЦФТ) — группе компаний, работающих в области информационных технологий для финансового сектора с 1991 года. То есть это организация, где качество продукта чрезвычайно важно, от него зависят реальные деньги.

В свою очередь, Владимир Плизга последние 6 лет погружен в разработку бэкенда интернет-банков и сопутствующих сервисов в ЦФТ, где активно топит за микросервисы и прочие модные штуки. Чтобы пообщаться с ним, я приехал прямо в офис ЦФТ, сделал сэлфи и обязательную фотку красного слона :-)

Обсуждаемые темы:

• Зачем нужны микросервисы;
• Как с ними жить (судьба REST и SOAP, statefull vs. stateless, переход от монолита к микросервисам, совместимость с legacy и многое другое);
• Микросервисные технологии (Spring Cloud Netflix, Zuul, ...), какие с ними проблемы, что нужно допиливать;
• Документация: на русском или английском? Написание и генерация документации (Swagger, SpringMVC, SpringFox). Архитектурные диаграммы — нужны ли, в чем рисовать, как хранить;
• Мониторинг, восстановление от сбоев;
• Ну и самое главное: стоит ли игра свеч?

(слева — Владимир, справа — olegchir)

Все мы встречались со сложными ошибками на продакшне, которые сложно поймать обычными средствами мониторинга. BPF — это технология ядра Linux, которая позволяет делать быструю и безопасную динамическую отладку прямо на запущенной работающей системе, без необходимости готовиться к этому заранее. JVM сама по себе имеет множество точек мониторинга для отслеживания сборки мусора, выделения объектов, вызовов JNI, даже вызовов методов — и всё это без необходимости в дополнительном инструментировании. Когда этих точек мониторинга недостаточно, ядро Linux и всевозможные бибилиотеки позволяют отслеживать системные вызовы, сетевые пакеты, события планировщика, время потраченное на доступ к диску, и даже запросы к базам данных.

В этом хабрапосте мы сделали текстовую расшифровку доклада Sasha Goldshtein, посвященного тому, как инструменты BPF можно использовать для мониторинга JVM-приложений на GNU/Linux, и чеклисту проверки производительности с использованием классических инструментов, таких как fileslower, opensnoop, strace — но всё это с использованием неинвазивной, быстрой и безопасной технологии BPF.

После ката будет множество картинок со слайдами. Осторожно, трафик! Картинки ужаты насколько можно, но не более того. Все они действительно нужны.

Здравствуйте, меня зовут Владимир, я работаю главным ИТ-инженером в СберТехе, в команде Digital Business Platform. Как-то раз за обедом мы обсуждали плюсы-минусы Dagger 2 и то, что хотели бы поменять в своей реализации. Нас много, и кода мы, соответственно, тоже пишем много, так что на тот момент в нашем приложении уже было 100500 методов и полтонны dex-файлов. Пораскинув мозгами, пришли к выводу, что писать меньше у нас не получится, зато можно уменьшить количество генерируемого кода при компиляции. Так было принято решение искать альтернативу существующему мастодонту от компании Google.

Год 2017 стал годом больших изменений в зарождающейся экосистеме российской микроэлектроники. Эти изменения заметило даже ранее безразличное к российскому железу общество. Российский чип ELISE для умных камер от ЭЛВИС-НеоТек вышел на удобной плате для разработчиков. Эту плату показали по Первому каналу российского телевидения. C российским процессором Байкалом-Т теперь может поработать любой программист через доступ к серверам удаленной лаборатории, которую байкаловцы создали вместе с МГУ. Российские процессоры от НИИСИ стали использовать для телекоммуникационного оборудования.

Для перехода от единичных успехов к развитой экосистеме необходимо подкрутить образование. В сентябре в Томске прошло совещание, на котором преподаватели и инженеры из Москвы, Сибири, Поволжья, Калифорнии и других мест обменялись опытом в преподавании микроэлектроники. Одновременно там же прошел учебный семинар по SystemVerilog, VHDL, FPGA, CPU IP, на который пришли не только россияне, но и студенты из Китая и Вьетнама, среди которых быстро распостранилась информация, что рядом учат чему-то полезному для их карьеры. Под катом — отчет об этом и сопутствующих событиях. Действующие лица: томские и новосибирские университеты, московские МГУ, МФТИ и МИЭТ, новосибирские лицеи, российская компания МЦСТ, американские MIPS, AMD и National Instruments, британская Imagination и казахский Назарбаевский Университет.

Меня зовут Лена, я работаю тестировщиком в InfoWatch. Хочу поделиться впечатлениями от длительной летней командировки в Иннополисе. Знаю, что статей об этом необычном городе под Казанью уже немало, и надеюсь, что мой рассказ поможет вам увидеть его с новой стороны.


Шайба

Всем привет, хочу поделиться накопленными знаниями по GraphQL, которые сформировались на основе около сотни прочитанных статей/доков и месяца построения API используя GraphQL.

Ну что ж, начнем с того, что такое GraphQL?

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

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

Рассмотрим пример простого запроса пользователя.



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

Simon Wirtz в своем блоге публикует достаточно много интересных постов о Kotlin.
Представляю вашему вниманию перевод одного из них.

long long ago; /* in a galaxy far far away */

 //
    //                       _oo0oo_
    //                      o8888888o
    //                      88" . "88
    //                      (| -_- |)
    //                      0\  =  /0
    //                    ___/`---'\___
    //                  .' \\|     |// '.
    //                 / \\|||  :  |||// \
    //                / _||||| -:- |||||- \
    //               |   | \\\  -  /// |   |
    //               | \_|  ''\---/''  |_/ |
    //               \  .-\__  '-'  ___/-. /
    //             ___'. .'  /--.--\  `. .'___
    //          ."" '<  `.___\_<|>_/___.' >' "".
    //         | | :  `- \`.;`\ _ /`;.`/ - ` : | |
    //         \  \ `_.   \_ __\ /__ _/   .-` /  /
    //     =====`-.____`.___ \_____/___.-`___.-'=====
    //                       `=---='
    //
    //
    //     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    //
    //               佛祖保佑         永无BUG
    //

«Слава богу, багов нет»

Sql, RegExp, Gradle — что их объединяет? Всё это примеры использования проблемно-ориентированных языков или DSL (domain-specific language). Каждый такой язык решает свою узконаправленную задачу, например, запрос данных из БД, поиск совпадений в тексте или описание процесса сборки приложения. Язык Kotlin предоставляет большое количество возможностей для создания собственного проблемно-ориентированного языка. В ходе статьи мы разберемся, какие инструменты есть в арсенале программиста, и реализуем DSL для предложенной предметной области.

Весь синтаксис, представленный в статье, я объясню максимально просто, однако, материал рассчитан на практикующих инженеров, которые рассматривают Kotlin, как язык для построения проблемно-ориентированных языков. В конце статьи будут приведены недостатки, к которым нужно быть готовым. Используемый в статье код актуален для Kotlin версии 1.1.4-3 и доступен на GitHub.