То, что РИТ++ — это фестиваль для тех, кто делает интернет, — не пустые слова. Мы, действительно, считаем, что полезно разбираться не только в тонкостях своего стека, но и быть в курсе общих тенденций отрасли и знать, кто живет по соседству.

А кто соседствует с бэкендерами и фронтендерами? Правильно, эксплуатация! И Root Conf — конференция о поддержке и эксплуатации IT-проектов, мониторинге, виртуализации, CD/CI, отказоустойчивости и всему такому прочему.



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

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

Наверное, абсолютно все читатели используют API, работая с фрэймворками, библиотеками, виджетами, как некий язык общения между сущностью и основным приложением. И вы наверняка замечали, что некоторыми API удобнее пользоваться, а в некоторых есть явные проблемы. Всеволод Шмыров (@vsesh) в своем докладе на Frontend Conf, расшифровку которого вы найдете под катом, постарался ответить на вопрос, какой API является хорошим.

Рассказ опирается на опыт разработки АPI Яндекс.Карт, и хотя это и JavaScript-библиотека, многие принципы и особенности его разработки применимы и к другим типам АPI, к примеру, к серверным API и Standalone библиотекам. Все то, о чем пойдет речь, относится именно к публичному АPI. Если к API вашей библиотеки обращаются только ваши коллеги, которым вы можете легко рассказать, что где-то что-то надо поменять, то вы, скорее всего, не столкнетесь с теми проблемами, с которыми сталкиваются разработчики публичного АPI.



Однако, в докладе не будет ответа на вопрос, нужен ли вам свой API. Надеемся, после прочтения вы взвесите все «за» и «против» и сами поймете, нужен ли он вам. Всеволод просто расскажет, с какими сложностями приходится сталкиваться разработчикам API, какие проблемы решать и что еще делать, а именно про эти четыре важных пункта:

• Проектирование интерфейса
  
• Обратная совместимость
  
• Исследование своего API
  
• Дополнительные действия
  

Java — очень распространённая платформа, на ней пишут очень разные вещи, начиная от Big Data, заканчивая микросервисами, монолитами, enterprise и прочим. И, как правило, всё это развёртывают на Linux серверах. При этом, соответственно, те люди, которые пишут на Java, зачастую делают это совсем на других операционных системах. Там они:

• пишут код;
  
• отлаживают, тестируют;
  
• после этого упаковывают в jar;
  
• отправляют на Linux, и оно работает.
  

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



С другой стороны, есть те, кто занимается администрированием серверов, на их сервера устанавливают JVM, отправляют jar и war-файлы, а с точки зрения мира Linux все это:

• чужеродное;
  
• проприетарное;
  
• собирается не из исходников;
  
• поставляется какими-то jar-архивами;
  
• «отъедает» всю память на сервере;
  
• вообще, ведёт себя не по-человечески.
  

Цель доклада Алексея Рагозина на Highload++, расшифровка которого идет далее, была в том, чтобы рассказать особенности Java для «линуксоидов» и, соответственно, Linux — Java-разработчикам.

Последнее время, на фестивале РИТ++ докладов по серверному программированию меньше, чем по клиентскому. Связано ли это с популярностью noBackend подходов, общим смещением фокуса в сторону фронтенда, или просто традициями конференции, сказать трудно.

Тем не менее, в программе Backend Conf целых 25 докладов, и мы решили составить полный гид по ним всем. Потому что это все равно два потока, и все равно придется выбирать, куда податься.



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

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

Название статьи не стоит понимать буквально: backend никуда не делся, просто фокус разработки — особенно на начальном этапе развития нового проекта — сильно смещается в сторону «клиентской части». Появляется большой соблазн взять что-то понятное для хранения данных и уже «обвязанное» REST API, максимально отказаться от PHP/Python/Ruby/Java/etc, писать 80% кода «на стороне клиента», минимально заботясь о возне «на стороне сервера».

Эта статья основана на докладе Николая Самохвалова, который, в свою очередь, обобщил опыт ряда проектов, написанных на React, React Native и Swift и переходящих на парадигму noBackend за счёт PostgreSQL+PostgREST.

В конце, вы найдете список must-check-вопросов для работы с noBackend-подходом, а, если ваш Postgres-опыт позволяет, то сразу после прочтения вы можете приступить к разворачиванию безопасного, высокопроизводительного и годного для быстрого развития REST API.



О спикере: Николай Самохвалов больше десяти лет работает с PostgreSQL, является со-организатором российского сообщества RuPostgres.org и в данный момент помогает различным компаниям оптимизировать, масштабировать и автоматизировать процессы, связанные с эксплуатацией PostgreSQL. Далее — расшифровка доклада Николая на Backend Conf, рассчитанного и на бэкенд, и на фронтенд разработчиков.

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

Сегодня РИТ++ — масштабное российское IT-мероприятие. Но таким он был не всегда. Мы начинали с небольшой тусовки на несколько сотен человек, а к концепции фестиваля пришли только через восемь лет.

В этой статье я расскажу о том, каким был РИТ++ раньше и во что превратился сейчас: что сподвигло перебраться из бара на ивент-площадку, какие шишки были самыми болезненными, чем Москва хуже Петербурга, как мы чуть не разорились и почему сейчас легче пройти отбор в докладчики конференции, чем остаться ими до выступления.

Треть всех докладов на грядущем РИТ++ будет связана с клиентской разработкой, а это почти 40 штук. Естественно, они пойдут в два параллельных специализированных потоках, а наиболее применимые для широкой аудитории — в главном зале. И вот тут бы и пригодился маховик времени, но похоже, что вместо этого придется решать серьезную задачу максимизации полезности.

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

Большинство информации в приложениях передается посредством текста. Поэтому верстать его приходится много, а незнание всей механики рендеринга влечет за собой различные проблемы. Например, простая задача — добавить выделение текста в существующее приложение. Заменяем UILabel на UITextView, и вдруг едут все отступы, текст выглядит совершено по-другому или вообще не влезает на экран.



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

Статья будет состоять из двух частей, сначала мы поговорим про основные термины типографики, про шрифты и их метрики и про наиболее часто используемые символьные атрибуты. А во второй части мы подробно поговорим про TextKit и отличия рендеринга UITextView и UILabel.

О спикере: Ирина Дягилева ведущий iOS разработчик в компании RAMBLER&Co. За многолетний опыт iOS разработки успела поучаствовать в создании нескольких приложений для крупных газетных издательств, в которых нужно было осуществлять полный контроль над отрисовкой текста.

Главное в платежной системе — взять денежки, перевести записи из одной таблички в ту же самую табличку со знаком «минус». Звучит не очень сложно, пока не пришли юристы. Платежные системы во всем мире облагаются огромным количеством всевозможных отягощений и указаний. Поэтому в рамках разработки платежной системы приходится все время балансировать на грани между тяжелым enterprise и вполне нормальным масштабируемым web-приложением.

Под катом рассказ Филиппа Дельгядо (dph) на Highload++ про опыт, накопившийся за несколько лет работы над платежной системой для российского легального букмекерского бизнеса, про ошибки, но и про некоторые достижения, и про то, как грамотно смешать, но не взбалтывать, web с enterprise.

Если 3D-графика не ваша основная специализация, все равно, возможно, вам придется или, как в случае автора этого доклада Александра Амосова (@s9k), захочется с ней работать. Порог входа не так высок, можно взять технологию WebGL доступную в браузере, популярный фрэймворк Three.js и небольшой компанией единомышленников сделать своими руками интересный проект. Именно на примере такого проекта, начатого в рамках хакатона Avito, и разберем основные этапы, обратим внимание на проблемные места, и, наконец, замотивируемся на создание чего-то такого же прикольного, как эта карта офиса.



Проект, кстати, интересен и сам по себе. В современных больших опенспейсах ориентироваться в пространстве, находить нужных людей или переговорки зачастую очень сложно. Конечно, можно сделать схему в Excel, но не всегда это супер хорошее решение. У Александра Амосова появилась идея сделать это более удобно, которой он поделился на Frontend Conf, а ниже расшифровка его доклада.

Людей, которые не просто хотя бы раз писали UI-тесты, а делали бы это в коммерческих проектах, довольно мало, потому что эту часть разработки очень сложно продать заказчику и аргументировать менеджеру, зачем они нужны и почему занимают столько времени. Новосибирская компания Improve Digital решилась на этот шаг по ряду причин, в частности из-за того, что разрабатываемый проект долгосрочный и с большим потенциалом дальнейшего развития.

Далее расшифровка выступления Михаила Домрачева на AppsConf 2017, в ходе которого он рассказал, как на практике внедрить UI-тесты в iOS проектах, и поделился мыслями, когда это действительно необходимо, а когда — излишне.

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

Каждый бизнес, даже если это маленький семейный ресторанчик, с чего-то начинался. В IT, и особенно в web, скорость роста очень высока, поэтому истории становления успешных компаний из ничего могут занимать всего каких-то десять лет, но при этом, пройти много этапов, взлетов и падений. Так все происходило и для KODIX, которая стартовала, как маленькая web-студия, а пришла… читайте дальше в расшифровке выступления Кирилла Новикова на Whale Rider, к чему пришла компания, что нужно, чтобы повторить успех, и какие есть перспективы.



О спикере: Кирилл Новиков основатель и руководитель компании, которая с недавнего времени называется KODIX Automotive Digital и работает более, чем с 10 автомобильными брендами и более 300 их дилерами. По числу клиентов и согласно разным отраслевым рейтингам — это ведущая компания в сфере Web-разработки для автомобильного бизнеса.

Но так было не всегда.

8-9 октября в Москве пройдет AppsConf — конференция, посвященная проблемам в мобильной разработке и их решению. Это будет уже третья AppsConf, и теперь мы решили переработать формат и подойти к организации немного с другого угла.

Но сначала о важном:

• Мы ищем докладчиков, вот форма для подачи заявок.
  
• Доступны early bird билеты, цена начнет повышаться с первого июня и дальше по графику.
  
• Видео с предыдущих конференций AppsConf 2016 и 2017.
  

Итак, что изменилось…

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



Сегодня мы поговорим о том,

• Как делать тестирование сложными зависимостями?
  
• Как добиться большого тестового покрытия?
  
• Как тесты влияют на дизайн?
  
• Что делать, когда много логики в базе?
  
• Как соблюсти компромисс между дизайном и «не дизайном».
  

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


Вместе с Игорем Беспальчуком постараемся посмотреть на этот тренд с трех разных ракурсов, что очень полезно для понимания природы того, с чем мы имеем дело, и, как следствие, для того, чтобы сделать правильные выводы и принять правильное решение.

Микросервисы — одна из самых важных и значимых составляющих Web-scale архитектуры, имеющая наибольшие последствия для переделки устройства техник и паттернов в Enterprise. Трудно сейчас сказать, на каком участке сейчас находится сама технология — может быть, на самом верхнем пике, и нам предстоит еще десять раз разочароваться. Но, тем не менее, это не повод не изучать её прямо сейчас.

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

Обработкой естественного языка (NLP) называется активно развивающаяся научная дисциплина, занимающаяся поиском смысла и обучением на основании текстовых данных.

Как вам может помочь эта статья

За прошедший год команда Insight приняла участие в работе над несколькими сотнями проектов, объединив знания и опыт ведущих компаний в США. Результаты этой работы они обобщили в статье, перевод которой сейчас перед вами, и вывели подходы к решению наиболее распространенных прикладных задач машинного обучения.

Мы начнем с самого простого метода, который может сработать — и постепенно перейдем к более тонким подходам, таким как feature engineering, векторам слов и глубокому обучению.

После прочтения статьи, вы будете знать, как:

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

Пост написан в формате пошагового руководства; также его можно рассматривать в качестве обзора высокоэффективных стандартных подходов.

В основе этой статьи доклад Дениса Иванова (@DenisIvanov) на РИТ++ 2017, в котором он поделился опытом разработки и запуска в продакшен REST-сервиса на ASP.NET Core на Kubernetes. На текущий момент это сделать уже можно без особенных проблем и бояться использовать .NET Core, судя по опыту 2ГИС, не стоит.

Конфигурация: ASP.NetCore на Linux позволила не только использовать существующую on-premise платформу, но и принесла еще несколько дополнительных плюсов, в частности, в виде полноценных Docker и Kubernetes, которые сильно упрощают жизнь.

О сервисе

С 1 апреля 2017 года в продуктах 2ГИС появилась иконка, на которую можно нажать и начнет проигрываться видео. Рекламодатели, которые размещаются в справочнике, теперь могут купить новый способ размещения рекламы, а все продукты нашей компании (мобильные, онлайн, API), ходят на сервис, про который я буду сегодня рассказывать.

Топология этого сервиса примерно представлена на картинке ниже. Сервис помечен облачком в центре, он, по сути дела, является бэкендом для продуктов. Когда продукт приходит и говорит: «Дай мне для этого рекламодателя всю информацию о видеорекламе», сервис ему послушно ее отдает. Это информация такого плана: такая-то обложка лежит на таком-то CDN, такой-то видеофайл в таких-то разрешениях лежит там-то и там-то, само видео длится такое количество времени и прочее.


Осторожно: много информации и кода.

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

1. Нужен ли вообще тимлид?
2. Что есть тимлид, какие у него задачи?
3. Что сначала: команда или тимлид?
4. Необходимы ли тимлиду технический навыки?
5. Вырастить или нанять?
6. Как понять, можно ли и нужно ли выращивать из инженера тимлида?
7. Сколько времени нужно, чтобы вырастить тимлида?
8. Менеджерские роли тимлида, какая роль предпочтительней?
9. Насколько важны эмоциональный интеллект и социальные навыки?
10. Что делать если руководитель сам является техническим специалистом и падок на микроменеджмент?
11. Тимлид ушел на неопределенное время (отпуск, больничный, форс-мажор), что делать?
12. Что делать, если тимлид уходит насовсем?
13. Какое должно быть соотношение менеджмента и разработки в работе тимлида?
14. Есть ли путь назад (и вперед)?
15. Какие перспективы карьеры тимлида?
16. Что может помешать стать тимлидом?
17. В чем разница между тимлидом и техлидом?
18. Как выявить неэффективного тимлида на ранней стадии?
19. Как начинающему тимлиду справиться с потоком информации?
20. Нужен формальный или неформальный лидер?
21. Junior и Senior тимлид, в чем различия и как держать их в одной команде?

Такой поток запросов выдали участники TeamLead Conf на круглый стол. Если вы уже сталкивались с какими-то из них, то, вероятно, и остальные могут вас настигнуть, есть, о чем подумать.

Под катом — обзор лучших докладов TeamLead Conf с видеозаписями и презентациями.

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

• Некоторые делают это для самообучения: берут класс стандартной библиотеки, пишут его сами с нуля, сравнивают то, что получилось, с тем, что есть в стандартной библиотеке — в процессе узнают для себя что-то новое.
  
• Некоторые проекты имеют особое требования к коду. В embedded-разработке принято работать без RTTI и без exception, поэтому части стандартной библиотеки, которые используют RTTI и exception, необходимо переписать без них.
  
• Редко, но бывает, когда велосипед пишут, потому что могут написать лучше, чем в стандартной библиотеке. Как правило, такие нововведения рано или поздно попадают в стандартную библиотеку.
  
• Другим только кажется, что они могут написать лучше, и таких людей больше. Но в процессе они обучаются, выясняют для себя что-то новое и что-то интересное открывают.
  
• Могут быть другие причины.
  

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

• бездумно переносить устаревшие технологии 20-30-летней давности в современные проекты;
  
• пользоваться «вредными» бенчмарками и оптимизациями.
  

А также затронем «вредные» советы, обсудим новейшие практики программирования (C++ 11 и позднее), подумаем, что делать с «идеальным» велосипедом.

Описать понятие прокрастинации можно этим максимально простым изображением. У вас есть ряд определенных задач и есть выделенное время на их выполнение. Прокрастинаторы решают свалить все задачи в кучу и оставить на самый последний момент.

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



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

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

Под катом рассказ Петра Людвига на конференции Aletheia Business 2017 о том, как положить конец прокрастинации используя три простых инструмента. Как только вы внедрите их в свою жизнь, вы сразу заметите разницу. Вы будете более продуктивны, почувствуете себя счастливее и у вас появится больше энергии.