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

На докладе мы рассмотрим немного истории и теории подхода GitOps.

Постараемся понять:
- Философию GitOps и ответить на вопрос "в чем смысл?".
- Что делать с секретами?
- DevOps vs GitOps?
- Главные вызовы GitOps.

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

Как обычно, методички есть всегда. Как полагается, написано внутри не всё. (Как всегда, никто даже тезисы не читает.) Поэтому я постараюсь вкратце рассказать про наиболее ходовые механизмы и концепции (mutex, semaphore, rwlock, atomic, spin-locking, exponential backoff, lock free, wait free...) и их внутреннее устройство, с одной стороны. Про реальные ходовые показатели всего этого добра на текущем (серверном) железе с другой стороны. Про стандартные "многопоточные" ошибки и нехитрые инструменты и методы их ликвидации с третьей. И, конечно, посмотрим пару занятных, но вполне себе практических примеров из разряда "где внезапно тормозит" или там "отчего внезапно не скейлится".

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

В докладе будет рассмотрен подход к разделению фронтенда на независимые модули — микрофронтенды, которые дают возможность командам изолированно работать над своими фичами.

Мы рассмотрим ситуации, в которых применение микрофронтендов может принести пользу, а также детально разберем один из способов реализации на примере того, как мы делаем это в Додо Пицце.

Сегодня мы имеем дело с большим количеством замечательных инноваций в технологиях баз данных. Например, введение новых моделей данных, таких как time series или graph, фокус которых направлен на решение проблем SQL при масштабировании приложений и превративших NoSQL в синоним масштабирования. Также на рынке появился новый дизайн баз данных Cloud-Native, использующий возможности Kubernetes и Serverless-концепции.

В своем докладе я рассмотрю все тенденции и объясню движущую силу этих изменений. Мы поговорим обо всех основных open source-базах данных и их универсальности, рассмотрим конкретные решения для разных ситуаций. Сравним коммерческие и open source-решения. Я дам информацию об изменениях в open source-лицензиях и о появляющемся классе частично открытых СУБД.

* Объясняю простыми словами, что значит фраза из новостей "стартап X привлек N миллионов долларов по оценке M".
* Рассказываю, зачем и почему инвестируют венчурные инвесторы.
* Выясняем, сколько может стоить стартап, у которого есть только презентация.

Все знают, что тестировать надо. Это полезно по многим причинам:
* тесты — это документация;
* тесты гарантируют работу кода;
* тесты позволяют нам безопасно рефакторить код.

И практически все могут написать тесты, но многие не пишут. Потому что это сложно или написанные тесты не помогают ни сегодня, ни потом, или дедлайны горят — не до тестов сейчас.

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

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

Реакту уже почти 9 лет. Мы все можем вспомнить мем, где каждый год на фронтенде случалась новая технология? На самом деле, технологии приходят и уходят, а идеи, заложенные в решениях, продолжают жить.

Этот доклад — рефлексия на тему реакта, его трейдофов и работы.

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

* Что нужно знать о китайских браузерах, DuckDuckGo — и другие интересные исключения, которые мы собрали в разных странах и проектах.
* Почему вам придется изобретать или “подгонять” под себя метрики, мониторинг, подходы к тестированию и так далее. Какие пути пробовали мы и на каких решениях остановились.
* Как обновления ОС и браузеров ломают ваш продукт — и какие еще внешние риски надо учитывать.
* Как рассчитывать и мониторить нагрузку, почему случаются несовпадения фактической и расчетной нагрузок — как использовать эти данные для контроля качества связи.

А также расскажу интересного о пользователях, интерфейсах и том, почему “обузданная” технология и объективные метрики еще не все, что вам нужно, и как субъективное отношение людей к видео будет влиять на вашу разработку и продукт.

Работа с данными выделилась в отдельную область разработки. Гига-, тера-, петабайты информации поражают воображение и озадачивают, когда дело доходит до тестирования. Hadoop, Spark, ETL — непонятные слова, к которым непонятно, как подступиться.

На основе своего опыта разработки wordpress.com я расскажу об обеспечении качества в области больших данных. В рамках доклада вы узнаете, как традиционные подходы к тестированию и автоматизации тестирования соотносятся с Big Data-решениями, а также какие специфические проблемы требуется решать, когда дело доходит до QA.

– Как и когда возникает "окно возможностей"?
– Как это "окно" поймать?
– Как стать лучше конкурентов?
– Как захватить рынок раньше конкурентов?
– Основные составляющие успеха.
– На что смотрит инвестор, правило 6T.

При разработке крупных программных продуктов, даже применяя agile-подход, надо обеспечить соблюдение архитектурных принципов как в части конфигураций инфраструктуры, так и в части программного кода. Оптимальным способом решения данной задачи является подход governance as a code.

При данном подходе правила проверки каждого артефакта, будь то конфигурация k8s, список библиотек или даже описание сценария CI/CD, описаны специальным кодом проверки правил, имеют свой жизненный цикл, подвержены тестированию и ничем не отличаются от обычного программного продукта.

Мы расскажем, как и что можно проверять в процессе разработки программного обеспечения, как данный подход позволяет разрабатывать более безопасные и качественные приложения и почему было решено не использовать такие очевидные решения как SonarCube, а разработать собственное решение на базе Open Policy Agent без дополнительных пакетов над ним.

Вместе мы обсудим, когда же выбрать admission controller, когда использовать "чистый" Open Policy Agent, а когда всё же обойтись без какого-либо контроля.

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

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

С 2007 года проект активно развивается, за это время изменились архитектура и инфраструктура. О том, как мы в компании переходим с монолитной архитектуры на микросервисную, было сказано не раз. Например, про PaaS можно почитать https://habr.com/ru/company/avito/blog/454780/

Этот доклад сделан с упором на statefull-сервисы, PostgreSQL (база монолита, PostgreSQL с момента старта Avito решает серьезные и важные задачи; вокруг СУБД были построены основные компоненты архитектуры), эволюцию архитектуры и инфраструктуры:
- как вступление, сделаю обзор: эволюции архитектуры и инфраструктуры PostgreSQL в Avito; успешно решенных вызовов;
- раскрою историю решения вызова роста — миграция на микросервисную архитектуру;
- изменение инфраструктуры;
- интеграция и асинхронное взаимодействие;
- Dev и test среды;
- платформа: DBaaS (Database discovery, управление доступом, failover, backup, archive, вопросы разделения ресурсов и т.д.);
- эволюция команды.

В заключение поделюсь нашим wishlist/нерешенными вопросами.

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

В своем докладе я расскажу, какие бывают лидары, как они устроены и по каким параметрам их принято оценивать. Ещё я расскажу про то, как измерения лидаров используются в стеке беспилотных технологий Яндекса. Немного порассуждаю, нужен ли лидар беспилотным машинам или можно обойтись только камерами.

Основы кода классических баз (Oracle, PostgreSQL, MS SQL, ...) написаны в 80-х и унаследовали оттуда много ограничений. В 21 веке был кратковременный взрыв NoSQL-баз (MongoDB, Redis, Hadoop, ...), устранивших часть старых ограничений, но породивших множество новых. Сейчас, в 20-х годах в Production Ready-состояние входят первые базы, разработанные сразу под инфраструктуру 21 века — облака и контейнеры виртуализации, которые можно назвать "первыми бессерверными".

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

Про удаленку, часть первая. Психологические аспекты.

Удаленка ворвалась в нашу жизнь, однако мы системно подошли к проблеме: проштудировали все ресурсы на тему, после чего сформировали свои регламент и свод советов.

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

- Видео. Несмотря на то, что наилучшая коммуникация происходит при живом общении, видеосвязь идет следующей по результативности и, уж конечно, на порядки лучше голоса. Требуйте от коллег видеосвязь. Даже если нет веб-камеры на компьютере, то на телефоне же она есть, правда?
- Рабочая одежда и рабочее место. В офисе у нас аккуратные рабочие места, люди работают в повседневной одежде. Никто не сидит в пижаме или трусах. Ровно так же должно быть и на удаленке и видео (см. выше) это требование замечательно поддерживает.
- Приветствия. Приходя на работу, мы здороваемся со всеми. Значит, удаленно нужно поступить так же. Если людей много – делимся на чаты по отделам и здороваемся там (чтобы не заспамить эфир).
- Аналогично – отход на обед и окончание рабочего дня.

Люди на карантине делятся на две категории: 1) "Боже, как я продуктивен" и 2) "Посмотрите, я нарядил кота в костюм гуся".

Аналогичным образом разделились команды и компании (причём даже в IT, не говоря уже про смежные отрасли). Одни на каждом углу рассказывают, как с переходом на удалёнку у них упали затраты, выросла производительность и ценность для сотрудников. Другие по состоянию на 20 апреля всё ещё требовали от сотрудников ездить в офис, потому что попытка перехода на удалённую работу привела к коллапсу производительности.

Попытаемся просуммировать всю имеющуюся информацию и понять, в чём состоят ключевые вопросы и проблемы удалёнки:
- KPI и кривая эффективности;
- поддержка коммуникаций и взаимодействия сотрудников;
- "Office Not Required", "The Remote Handbook" и прочие мануалы — ценность, применимость, ошибки?
- документооборот (включая юридически значимый);
- документирование;
- защита данных и модели угроз;
- team building, поддержание командного духа;
- предупреждение выгорания;
- эволюция найма и пр.

Список участников:

- Артём Гавриченков, Qrator Labs. Технический директор, более десяти лет занимается сетями передачи данных, мониторингом и защитой информационных ресурсов. У компании три основных офиса, и до нынешнего кризиса Артём большую часть своих рабочих обязанностей выполнял в разъездах (в том числе из самолётов). Также у Qrator армада удалённых сотрудников в самых оригинальных уголках мира.

- Дмитрий Малыхин. Rossko.ru. Руководитель отдела поддержки и эксплуатации инфраструктуры. Эксплуататор из эксплуатации. Строит распределённую удалённую команду. За 20 лет в отрасли был на разных позициях и разных режимах: в офисе, удаленка, фултайм, фриланс, аутсорс....

- Дарья Мамлыгина, Додо Пицца. HR-менеджер. За 8+ лет в HR прошла путь от рекрутёра до руководителя отдела, а потом увлеклась направлением IT-рекрутмента, где продолжает развиваться по сей день. Дополнительно прокачивается в направлении DevHR и запускает проекты по адаптации и оценке. Никогда не работала на удалёнке до самоизоляции.

- Илья Росляков, Wargaming. Engineering Manager в Wargaming, Platform. Работал в РФ, Берлине, СФ теперь в Минске — помотало по миру. По функции — занимался инженерией, людьми, процессами, продактом, кроме проектного управления. Когда-то давно на протяжении 10 лет писал распределенные высоконагруженные системы.

- Алексей Семеняка, RIPE NCC. Работал в Мегафоне, Яндексе, Qrator, в данный момент занимает пост External Relations Officer в европейском региональном Интернет-регистраторе. Руководит в Восточной Европе и Центральной Азии взаимодействием RIPE NCC с участниками регистратора, сообществом, техническими органами, правоохранительными органами, академическими организациями и пр.

- Вячеслав Юданов, ЦИАН. Технический руководитель направления. Работал в компаниях с разным отношением к удаленке — от «только в офисе» до «приходите, когда хотите». Последние 4 года занимается управлением людьми. В Циан с середины прошлого года начали эксперименты с разными подходами к удаленной работе. Смогли бесшовно перейти на удаленку в марте.

Вы, конечно, слышали, что есть R&D. Но чем конкретно они занимаются? Алгоритмы, данные, математика, аналитика или разработка? В зависимости от проекта у такой команды будут разные задачи, и мы расскажем, как устроен Research & Development в Delivery Club — пионере foodtech'а в России.

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

Обсудим следующие темы:
1. Какие процессы отличают R&D-команду в Delivery Club.
2. Эксперименты на бою — разберем на реальном запуске.
3. Измеримость — как мы выбираем метрики.
4. Автономность — наша адаптация Gist и Inner Source.

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

В своем докладе я продемонстрирую множество stub-серверов для различных технологий: REST API, GraphQL, SSE и WebSocket. Я расскажу, как быстро наполнить заглушки фейковыми данными, при этом не написав ни одной строчки кода на js или любом другом языке.

Сегодня фронтенд-разработчик занимается огромным списком задач: верстает, разрабатывает дизайн-системы, кодит на JS, спорит о типизации, выбирает лучший фреймворк. Но мы в Яндекс.Маркете пошли дальше и решили ещё писать серверный API для мобильного приложения силами команды разработки интерфейсов. Почему мы так поступили? Что из этого вышло? Стоит ли вам поступить так же? Ответы на эти и другие вопросы в моём докладе.

Только перейдя на удалёнку, начинаешь поистине ценить офисный кулер для воды.

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

Обсудим на круглом столе ключевые вопросы и проблемы полностью удалённых коммуникаций:
- принципы выбора средств коммуникации, есть ли “серебряная пуля” и в каких условиях?
- обучение сотрудников;
- дефрагментация информации;
- фиксация договорённостей;
- синхронная или асинхронная коммуникация: что предпочесть?
- мониторинг и KPI;
- защита данных и модели угроз;
- стабильность электронных коммуникаций и пр.

Список участников:

- Артём Гавриченков, Qrator Labs. Технический директор, более десяти лет занимается сетями передачи данных, мониторингом и защитой информационных ресурсов. У компании три основных офиса, и до нынешнего кризиса Артём большую часть своих рабочих обязанностей выполнял в разъездах (в том числе из самолётов). Также у Qrator армада удалённых сотрудников в самых оригинальных уголках мира.

- Артём Каличкин, ЦФТ. Последние 10 лет работает в ГК ЦФТ на технических руководящих позициях. С января 2018 года является техническим директором сервиса ДБО Faktura.ru. За 20 лет поработал разработчиком, аналитиком, менеджером проектов, продуктов и т.д. Всегда уделял особое внимание организационным проблемам взаимодействия команд, видимым по-своему с каждой из позиций. Опираясь на полученный опыт, уже 15 лет занимается организацией разработки, эксплуатации, сопровождения mission critical- и highload-продуктов разной степени сложности. Ведёт профильные спецкурсы в Новосибирском Государственном Университете.

- Дмитрий Меликов, Яндекс. Руководитель группы sro/sre, сейчас отвечает за организацию инцидент-менеджмента, стандартизацию подхода в работе с релизами и регламентными работами. В компании прошел путь от инженера-системного администратора в дата-центре до руководителя подразделения. За время работы решал задачи мониторинга, оперативного реагирования(24/7), координации и общего подхода к надежности сервисов. Большое внимание уделяет развитию коллектива.

- Максим Лапшин, Flussonic. Руководит своей компанией в 50 человек, которая разрабатывает и продает свой софт для доставки видео. Две трети компании находятся не в Москве, вне офиса, поэтому с самого начала вырабатывали гибридную конструкцию, когда часть людей в офисе, часть на удаленке. В итоге выросла система, когда даже в офисе сотрудники используют схемы общения, свойственные удаленке. Переход на карантин прошел практически безболезненно (не считая отыквевшегося интернета).

- Константин Попандопуло, Umbrella IT. Технический директор. Компания разрабатывает ИТ-решения под заказ, в данный момент команды работают удалённо.

- Андрей Смирнов, X5. Руководитель управления разработки enterprise-систем в X5 Retail Group. Прошёл путь от frontend-разработчика до руководства ресурсными пулами разработки, последние несколько лет занимается организационными вопросами найма и развития людей. Также, будучи фронтендером, вёл подкаст Frontend Weekend и организовывал различные митапы. Последний год увлёкся исследованиями soft skills среди разработчиков, регулярно выступает с докладами на эту тематику.

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

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

Расскажу, как удалёнщик из Нижнего Новгорода стал ментором новичков в PHP/JS на курсах HTML Academy, а потом и в своей распределенной компании, и какие плюсы и минусы это принесло в мою жизнь.

Когда я перестал ездить в офис, у меня освободились 2 часа ежедневно. Я решил инвестировать их в студентов онлайн-курсов, изучающих программирование, и стал ментором. Меня затянуло — уже второй год я пишу код сам в основное время, а затем учу этому других.

Хочу рассказать:
* что нужно, чтобы стать ментором, и с чего начать, если вы тоже хотите делиться опытом с новичками;
* в чем заключается роль ментора, какие шишки я набил на этом пути;
* сколько денег это приносит и сколько сил и времени требует взамен;
* как я стал ментором в компании и сделал из QA программиста за полгода;
* какие бонусы это дало мне и моим студентам.

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

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

Рынок СУБД уникален по количеству «холиварных» тем. Открытые и коммерческие, in-memory, колоночные, NoSQL, SQL, NewSQL, облачные — огромное количество идей, подходов и продуктов, развивающихся на протяжении десятилетий.

Давайте посмотрим, в какой точке мы находимся. Что происходит? Кто побеждает? Что выбирать сейчас и к чему готовиться?

Посмотрим и на полутеоретические споры, проходящие в «недрах» конференций (таких, как VLDB — старейшей конференции по БД) и онлайн-тусовок (в том числе при участии таких больших имён, как Майкл Стоунбрейкер).

И на то, что происходит «на земле», где зачастую в одной компании используется уже более 5 разных СУБД, при этом уже накрыла волна моды (микросервисы, контейнеры, Kubernetes), но при этом многие базовые потребности крупных проектов закрыты так плохо, что каждый раз всё ещё приходится «пилить» решения вручную (шардить Postgres, делать вменяемый мониторинг, налаживать разворачивание качественных dev- и staging-сред).

И, конечно, облака. Какая их роль в картине мира баз данных и какие намечаются тенденции?

Автоматизированный сбор открытых данных с веб-ресурсов, он же парсинг, он же web scraping, он же краулинг... — как его ни назови, имеется в виду один и тот же процесс: бот представляется пользователем-человеком и берет/кладет что-то на веб-сайт, обычно с высокой частотой и с большого количества источников. Рано или поздно это затронет и ваш ресурс: как может выглядеть эта активность и как она влияет на важные метрики?

В своем докладе я хочу разложить по полкам популярные инструменты веб-скрэпинга, проследить их развитие до актуального состояния и объяснить подходы, которые применяются для обнаружения и предотвращения работы этих инструментов. Мы затронем следующие темы:
* Сбор данных с помощью Python: requests, Scrapy. Как стать скрэпером за 2 минуты?
* Эволюция headless browser automation в скрэпинге: PhantomJS, Selenium, Puppeteer, Playwright.
* Использование headful-браузеров, OCR и человеческого труда: есть ли граница между человеком и автоматом?
* Защитные меры: когда есть смысл их применять, как при этом не навредить целевой аудитории.

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

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

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

Долгое время мы разрабатывали web-приложения, которые используют 3rd-party-куки, и считали, что такие куки — неотъемлемая часть Интернета и что они будут работать всегда. Но времена меняются, и разработчики браузеров всё активнее начинают ограничивать или вовсе блокировать работу таких кук. Из-за этого страдает не только работа всяческих систем отслеживания пользователей, но и более полезные вещи. Например, различные виджеты и приложения, встраиваемые с других сайтов. Работа разных SDK авторизации, например, именных кнопок входа, как у Mail.ru, ВКонтакте и Facebook. Всё это находится под угрозой.

Я хочу рассказать вам:
- что такое 3rd-party-куки и как они используются в современных интернет-сервисах;
- как работают различные провайдеры авторизации, такие как Mail.ru, ВКонтакте, Facebook и как они используют 3rd-party-куки;
- что означают и как отразятся на работе интернета новые изменения, касающиеся работы 3rd-party-кук;
- как реализовать внешнюю авторизацию на своём сервисе без использования 3rd-party-кук;
- какие планы у разработчиков браузеров по дальнейшему ограничению использования 3rd-party-кук в web-сервисах.

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

За годы работы над коммерческими и OSS-проектами я сформировал для себя список принципов, которыми должен соответствовать такой код, например: тестируемость, гибкость, расширяемость, узнаваемость и т.д. В докладе я рассмотрю этот «чек-лист» подробнее, а также приведу примеры из мира Руби и не только.

Год назад я рассказывал, от чего Интернет может сломаться. С тех пор тезисы из доклада подтвердились не раз и не два.

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

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

Рынок платформенных решений по управлению знаниями достигает 33 млрд. долларов. Спектр развития продуктов по управлению знаниями достаточно широк, но на данный момент инвестиции крупных игроков рынка сфокусированы в локальных направлениях.

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

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

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

Что такое servant leadership? Чем этот метод управления отличается от обычного? Почему это работает? Что делают (и не делают) руководители, выбравшие метод руководства servant leadership? И, в конце концов, как вообще слуга может быть лидером?

Я перешел на servant leadership 8 лет назад и ни разу не пожалел об этом. Мне удалось добиться повышения мотивации, производительности и самое главное — достижения бизнес-целей компаний, в которых я работал. Хочу поделиться с вами своим опытом, а также привести примеры из практик ведущих IT-компаний.

Из доклада вы узнаете, как устроена специальная СУБД для АСУ ТП / IIoT:
* Почему в АСУ ТП ACID транзакции являются страшным злом и как без них обойтись. Зачем нужно уметь выполнять код "ближе к данным".
* Как построить надежную синхронизацию данных на асинхронных сообщениях в режиме реального времени.
* Как построить схему управления параллельными вычислениями на основе избыточности и сегментирования данных.
* Что будет, если данных больше, чем может обработать вычислительный кластер в сети.
* Как прикрутить к этой конструкции безопасность.

Если у продукта, который вы делаете, глобальные планы, то рано или поздно вам придется столкнуться с локализацией. Перевести все версии клиентов на английский — полбеды, но когда добавляются новые языки и диалекты, возникают не всегда очевидные трудности. Кроме того, мало перевести проект: локализация затрагивает форматы дат и чисел, и нужно уметь тестировать все изменения в условиях существования нескольких версий проекта и переводов (!) параллельно.

В случае нашей компании речь идет о четырех разных продуктах, 52 языках (11 из них — диалекты), 17 падежах в венгерском языке, письме справа налево в арабском и иврите, числительных в русском и огромном количестве версий и клиентов.

В докладе я поделюсь полным описанием процесса перевода проекта и подходами к тестированию, заострю внимание на важных проблемах и способах их решения.

Мы рассмотрим, как поддерживать А/B-тестирование и проводить тестирование, имея множество версий. Поговорим, как обеспечить единство стиля переводов, а также как переводить новый функционал за 48 часов и не нагружать разработчиков рутиной.

1. Способы обеспечения правовой охраны и доказательств прав на интеллектуальную собственность.
2. Рекомендации по снижению рисков утери интеллектуальных прав при оформлении трудовых отношений с работодателем.
3. Внедрение ноу-хау в своей команде: практические рекомендации сохранения тайн.

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

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

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

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