Эта статья — краткий обзор моего опыта построения дизайн-направления в GlobalLogic. Она будет полезна менеджерам, которые хотели бы получить опыт работы над стратегическими задачами. Также статья может пригодиться тем, кто развивает или планирует развивать новую практику/услугу в своей организации. А менеджеры и владельцы компаний смогут посмотреть на дизайн с новой стороны и увидеть потенциал для роста бизнеса.

Основу экспертизы нашей команды составляет UX-дизайн (больше деталей об этом направлении здесь). Поэтому в этой статье под термином «дизайнер» я подразумеваю в первую очередь UX-дизайнера.

Если коротко, работу UX-дизайнеров иллюстрирует известная цитата Стива Джобса: «Дизайн — это не то, как предмет выглядит, а то, как он работает».

Часть нашей команды дизайнеров GlobalLogic

Дизайнеры как точка входа для нового проекта

Прежде чем предлагать клиенту состав команды, стек технологий и эскиз архитектуры, на этапе pre-sales важно:

• погрузиться в бизнес клиента, узнать больше о его домене;
• выйти с клиентом на один уровень понимания задачи (пусть не сразу, но итеративно);
• показать подход команды;
• дать понять, что компания фокусируется на решении бизнес-проблемы клиента.

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

Мир меняется, а точнее — оцифровывается. Позволю себе привести здесь комментарий Виктора Матусова (Engineering Director, GlobalLogic) к его статье:

К счастью, украинский IT в целом и отдельные компании в частности активно уходят в сторону более комплексных моделей, способных генерировать больше пользы клиентам. Ярким примером, к которому нужно стремиться, являются случаи так называемой Digital Transformation, когда заказчик приходит с запросом вида: «Я знаю свою отрасль, свой рынок, но ничего не понимаю в IT. А вот вы — эксперты. Трансформируйте, пожалуйста, мои продукты (или даже всю мою компанию) в Digital-плоскость. Любыми способами. Сами назовите сроки. Сами назовите цену».

И вот тут нам понадобятся не только хорошие PM, но и опытные дизайнеры. Дизайнеры, которые часто совмещают в себе в той или иной пропорции навыки бизнес-аналитика, системного аналитика, Product-менеджера. Эти ребята с развитой эмпатией, широким кругозором, множеством подходов к решению практически любых задач очень ценны, когда речь идет об инновациях и нестандартных решениях. И вроде бы нет ничего проще, чем набрать команду экспертов и почивать на лаврах. Но есть ряд трудностей, особенно когда речь идет о дизайнерах. Рассмотрим несколько типичных примеров.

Конкретная специфика, с которой пришлось столкнуться

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

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

Инфраструктура. Стандартный «софт» IТ-компании в первую очередь предназначен для разработчиков, а для задач дизайнеров (прототипирование, визуальный дизайн, motion design, 3D...) промышленного стандарта набора программного обеспечения не существует. Разные клиенты на разных проектах могут использовать разные инструменты для решения одних и тех же задач. Как минимум нужно управлять всем этим набором лицензий, софта, подписок, а еще — постоянно исследовать новые инструменты.

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

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

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

Развитие дизайн-направления в компании

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

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

Portfolio review.Еженедельно команда собирается, чтобы обсудить текущие проекты одного из дизайнеров. С одной стороны, эти встречи помогают делиться опытом, с другой — получать обратную связь от коллег.

Презентация дизайн-сервисов — простой и понятный набор слайдов. Таким образом аккаунт-менеджеры и менеджеры по продажам могут презентовать дизайн-сервис своим клиентам.

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

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

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

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

Увеличение видимости команды / PR. Беремся за любые задачи, в том числе внутренние. Опыт показывает, что главное — сделать две-три очень крутые работы, после чего репутация будет расти автоматически, как и очередь входящих запросов.

Наша команда дизайнеров помогала в подготовке презентаций для консультантов-спикеров GlobalLogic Kharkiv Java Conference 2018.

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

Обучение команды инженеров. Объясняем инженерам, кто такие дизайнеры и чем они занимаются. Например, мы провели Design Thinking Workshop, где на практических кейсах разбирали суть дизайн-мышления. Участники опробовали различные практики и подходы, чтобы далее применять их на реальных проектах. В команде с Аней Скоробогатовой (руководителем дизайн-офиса Globallogic Ukraine) и Алексеем Пономаренко (он уже делился своим опытом в статье про обучение дизайн-мышлению в Великобритании в статье на DOU) участники опробовали различные практики и подходы, чтобы далее применять их на реальных проектах. Получив позитивные отзывы после первого воркшопа, мы решили проводить их и в дальнейшем — в том числе и в других офисах компании.

Design Thinking Workshop в харьковском офисе GlobalLogic

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

Итог — опыт работы над стратегическими задачами

Каким образом можно обобщить опыт и подход, когда речь идет о развитии новых направлений? Мои выводы ниже.

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

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

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

Что помогает? Помимо очевидных вещей, вроде делегирования и работы с приоритезацией задач, важно регулярно получать подкрепление. Критично важны оба слова: «регулярно» и «подкрепление». Регулярные митинги с командой, руководством, трекинг задач, обратная связь от менеджмента/клиентов/коллег. Секрет в том, чтобы получать удовольствие и от процесса в том числе, а не только от достижения существенного результата.

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

Буду рад вашим вопросам и обратной связи в комментариях!

В рубрике DOU Labsмы приглашаем IT-компании делиться опытом собственных интересных разработок и внутренних технологических инициатив. Вопросы и заявки на участие присылайте на editors@dou.ua.

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

Идея

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

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

Мы долго ломали голову над тем, как поступить, и наконец перед нами появился ответ с огромным знаком восклицания: «Да мы же айтишники!». Вот так появилась идея о создании простого приложениядля сбора знакомых на футбольные турниры.

Наша команда состоит из 11 человек, среди которых есть дизайнер, Project Manager, 3 Android- и 4 iOS-разработчика, 2 бэкендщика. Кстати, наш дизайнер в этом году стала победителем Dev Challenge 2018 в категории mobile-design.

На фото наша команда или те, кто не побоялся публичности ;)

Реализация

Eventssion сначала был ориентирован на маленькие группы людей, у которых есть номера телефонов друг друга. Поэтому организатору оставалось только вписать название события, дату, время и пригласить участников, которые были зарегистрированы в приложении. Далее все получали уведомления и выбирали статус (идут или нет) + напоминание в день игры. Соответственно, каждый участник видит, что за событие его ожидает, а также где и когда оно состоится. Так мы свели действия организатора к минимуму. Он просто создавал мероприятие и после этого наблюдал за откликами. Исчезла необходимость в телефонных звонках и напоминаниях. Радость девочек-организаторов невозможно было передать словами.

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

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

С помощью общего чата участники легко находят единомышленников или обсуждают интересующие их темы — нетворкинг в режиме онлайн. И с помощью нового функционала «группы» организатор может все свои мероприятия объединить. Больше не нужно искать события в своем расписании. Теперь пользователь заходит в определенную группу, видит все её активности и выбирает, что его интересует.

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

С технической точки зрения это происходило следующим образом. Клиент Android и iOS общается с бэком через REST, сам бэкенд реализован на Spring. Поскольку API одно для всех платформ, это приводило к некоторым затруднениям. Например, с push-уведомлениями с более ранней версии Android. Было удобно отправлять только некоторые поля в пуше (название, события, время), а на Android уже перехватывать и отображать. На iOS оказалось, что когда пользователь закрывает приложение, оно никак не может обработать пуш. Его должен формировать бэкенд в виде, готовом для отображения системой (сразу в таймзоне и на языке устройства). Поэтому приходится слать разные пуши на разные устройства, что довольно накладно.

Версионирование API реализовали через HTTP-header. Есть глобальный перехватчик запросов, и при ответе сервера о необходимости обновиться, он обрабатывается соответствующим образом. А поскольку объектные модели часто меняются, мы ориентировались на использование MongoDB, но связей в БД также много. На данный момент мы остановились на MySQL.

Внешне мы изменили интерфейс и возможности расписания события.Теперь можно указать тайминг конференции (например, 9:00 — регистрация; 10:00 — первый спикер; 12:00 — кофе-брейк и т. д.). Так можно отказаться от бумажных флаеров, а участники конференции будут иметь быстрый доступ к плану мероприятия.

Также хотелось бы поделиться тем, как мы реализовали отображение списков и обработку действий (actions) на Android. Подход основан на «делегировании» отображения элементов списка специальным классам-делегатам. Действия тоже обрабатываются через ActionHandler, который через data binding вызывает Action. В итоге создание нового экрана со списком любой сложности сводится к формированию списка делегатов для элементов списка. Сюда же включен и список экшенов, которые срабатывают при нажатии на элементы в layout. Это решение оформлено в качестве библиотеки.

Отдельно хотим рассказать про систему напоминаний. Это особая история. У нас их два вида: хард (в виде звонка на телефон) и софт (на шторку). Харду мы уделили большой отрезок времени, поскольку это двоякая фича. С одной стороны, все лишние звуки на смартфоне отвлекают нас от работы, а с другой — именно они являются гарантией того, что участник будет помнить о событии.

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

Кроме того, в качестве кэширующей БД была выбрана Realm. Об этом мы ни разу не пожалели. Она действительно работает: быстрее SQLite, поддержка Rx и это удобно. Реактивные подписки на данные позволили добиться того, что на многих экранах обновляется информация синхронно с обновлением данных. Например, когда участник события дает ответ, организатор события realtime видит это на UI.

Результаты и планы

Хотим ли мы остановиться? Безусловно нет. Сервис находится в активной разработке. Идеи о том, как его улучшить, появляются ежедневно. Конечно, у нас нет Kotlin, но мы не спешим переходить. Сейчас все переходят на bottom navigation (VK, Instagram, LinkedIn), поэтому мы стараемся быть в тренде и тоже переделываем навигацию в приложении.

Сегодня наше приложение превратилось в событийно-ориентированную социальную сеть. На данном этапе мы тестируем новый функционал — «группы» с возможностью бронирования мест и внедряем поиск внутри приложения.

Мы сделали приложение на Android и iOS. Первое уже доступно в Play Marketв beta-версии, поэтому вы можете сделать тест и проверить свои организаторские данные. Держим пари, что у вас получится провести успешное событие любого масштаба. iOS-версия на последнем этапе разработки, поэтому ожидайте скорейшего ее появления. Поскольку мы серьезно взялись на это приложение, планируется публикация в App Store.

Новыми фичами и релизом на iOS, поделимся с вами уже в следующем материале. Будем рады видеть Вас на страничке в Facebook. Там мы ведём блог нашего приложения и всегда рады комментариям.

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

Кадровый голод

— Хороших программистов всегда будет не хватать...
— А ХИРЭ закрыли?
— А ХИРЭ, простите, выпускает хороших программистов? С каких пор?
— Так или иначе, но они оттуда появляются.

© Холивар на тему кадрового голода на конфе

Бизнес

— Девятеро не могут родить проект за один месяц?
— О-о-ок...
— Тогда пусть программируют по девять проектов одновременно!

Способы входа

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

1. Фигня! У новичка никогда не было богатства выбора, а сейчас — тем более. Глупо опираться на советы синьора, он не отвечает за набор обычно. Опирайтесь на менеджеров и рекрутеров!
2. Предыдущее правило — фигня. Менеджеры и рекрутеры видят ситуацию со своей стороны, и у них совсем другой опыт. Они не видят, как ломать систему, они видят, как систему строить. Опирайтесь исключительно на мои советы!
3. Предыдущее правило — тоже фигня! Я тоже ошибаюсь. Не верьте никому.
4. Что тоже является фигней и тупиком. Опирайтесь на интуицию.
5. Щаз, откуда интуиция без опыта. Интуиция — это нейронная сеть в мозгу, и ее тоже нужно обучать на выборке.

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

Зарплата=f(время)

Чтобы заработать в месяц 4000 гривен, нужно работать гораздо больше, чем для 2000 долларов. Почти все войтивайтишники знают это. Почти все синьоры — не знают.

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

IT-мотивы

Сейчас многие пришли в IT за деньгами. Их очень не любят предшественники, которые пришли спрятаться от мира.

Невыполнимые задачи

Однажды меня попросили расшифровать два десятка аббревиатур, а потом написать интерпретатор brainfuck прямо на собесе. Первое я смог с трудом, второе — откровенно не смог. Что люди пытались понять за эти три часа вечером в тот четверг, я так и не понял. © Anton Naumov
---
Если на собеседованиях ставить невыполнимые задания, то в этом много выгоды:

1. «Они все слабаки, а я классный специалист». Самоутверждаешься на этом.
2. Сбиваешь зарплатные ожидания. Благо и для себя, и для других фирм. Нефиг платить неудачникам.
3. Если работа связана с частыми фейлами и высокой дурной нагрузкой — смотришь, как человек ведет себя в таких условиях. (Вы реально в это верите? У вас такая работа? Точно-точно?)
4. Бывает очень специфическая работа. Например, в рил-тайме моделировать поведение плазмы. Или микрокод для глубокого космоса писать. И эта работа позволяет отсеять 99 из 100 синьоров, но таки выбрать сотого. Т.е. есть деньги и время на тщательный отбор, как в Гугле.

Дискриминация по возрасту

Есть ли дискриминация по возрасту в УкрIT? Да, есть. Я сталкивался с компаниями, которые неофициально говорили: «Старше 30 не берем».
---
Массовое ли это явление? Вот тут уже сложнее. Для поиска первой работы оптимальна ситуация «молодой парень без семьи после профильного высшего готовый работать бесплатно». Если кандидат не попал в формулу — для него всё становится сложнее, а там и так не сахар.

Стоит ли тут копать именно в эйджизм? Эммм... Я в отрасли 19 лет, мне 41, и программистов старше меня крайне мало. Когда мне было 31, программистов старше меня тоже было мало. И в 25 то же самое было. Причина банальна: когда я учился на программиста, компьютер был крайне редкой и дорогой штукой. Дома он был... ну как сейчас внедорожник — бывает, но штука редкая. И прежде чем пустить студента за руль, владелец крепко подумает.
---
Если уж хочется покопаться в причинах эйджизма, то я бы выделил:

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

Зодиак

«Кто вы по знаку зодиака?» © реальный первый вопрос на собеседовании айтишника. А я то думал, что уже всё видел :)

Похоже, у спрашивающего много кандидатов.

Sexual Harassment

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

То есть случаи точно есть, просто сейчас они под ковром. Нет, я не готов привести стопроцентные примеры.

Верность

Кому должен хранить верность программист в аутсорсинге/аутстаффинге: заказчику или местному начальнику?

Например, если местный начальник скажет: «Отсобеседуй сегодня кандидата (двух? трех?) на новый проект» или «Помоги с архитектурой на соседнем проекте». Это явно несколько часов на чужие проекты, и при этом в таймрепорт на заказчика нужно записать полный рабочий день.

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

Айтишники как вампиры

Айтишники как вампиры. Норовят укусить кого-то и сделать из него айтишника тоже.

* Это обобщение.
** Многие хотят просто укусить. Или ударить. Можно словом. Это подавленный гнев.
*** Желание сделать окружающих айтишниками — это защита собственного выбора.
**** Это Спасательство по Берну тоже.
***** Я сам укусил минимум восьмерых. Это хвастовство.

Технологии и процесс

Гугл

Гугл читает переписку вашего начальника и вашей жены.

Гугл знает о вашем окружении и их планах больше вас.

Если гугл показывает вам неожиданную контекстную рекламу — возможно, он просто упреждает события.

Идеальный мир глазами программиста

1. Уволить менеджеров, бизнес-аналитиков, HR. Оставить нормальных программистов, и, так и быть, QA.
2. Давайте нормальное ТЗ и хорошо подготовленный таск-лист.
3. Чтобы платили нормальную зарплату на нормальном проекте, а не вот этот вот всё.
4. Решения о пробелах, табах и прочих скобках должны приниматься в PvP.

> вы только что передали суть 99.9% статей с ebanoe.it © Михаил Быков

Ласковое IT

В каждом доме есть мусорное ведро. Для украинского IT в роли такого ведра выступает «ласковое IT». Бегло порылся, что же туда попадает:

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

Выводы:

• во многих ситуациях важно не только «как оно на самом деле», а и «как это выглядит для другой стороны»;
• хорошо бы уметь работать с ожиданиями кандидатов и сотрудников.

Техзадание

Вот вы говорите, вся проблема в том, что хреновое ТЗ. Или вообще нет ТЗ.

А у меня вот случай наоборот. Максимально детально описанное и согласованное со всеми ТЗ. Прописаны все интерфейсы, все окошечки, рюшечки и т. д.

И товарища клинануло. Потому что без (или с хреновым) ТЗ ты архитектор. Весь такой в белом. А с ТЗ тебя разжаловали в чернорабочие — меси бетон да тягай тачку — думать будут другие. © Artem Kravchenko

GDPR

GDPR.2018 == Проблема.2000

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

Skype

Еще никто не жаловался на плохую работу скайпа под MS DOS 3.0.

Прерывания

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

Я работаю, голова занята сложным кодом, прерывания обходятся дорого. Отвлекли на «ты вечером во сколько будешь?» — и потом опять разгоняйся. И разгон после 10 секунд прерывания занимает от получаса до двух часов. Отсюда — конфликты семейные, злость, разборки, и уже думаешь не о коде, а об отношениях.

* Вообще, объяснить это непрограммисту сложно. Даже гениальная статья «Не будите программиста»помогает на пару дней всего.

** «Безумно раздражать» начали гораздо раньше. Я это только осознал в тот момент. Раньше раздражение зашкаливало и выходило в зону нечувствительности.

Идеи для себя

Ла-а-а-адно, подойдем системно. Стал ставить себе на вайтборд пометки на каждом прерывании. Очень скоро понял, что больше всего прерываний приходит от FB и рекламных SMS. Но обида и раздражение — на жену. Это свойство такое у человека — обвинять только одушевленных. Итого:

• отключить нотификации и попапы;
• смарт-часы не покупать;
• телефон в режим «не беспокоить» с 22 до 19.

Идеи для менеджеров

Если есть ощущение, что прерывания мешают команде:

• Человек, которого часто прерывают, — ему нет смысла начинать работу. Отсюда прокрастинация. Борьба с прокрастинацией выматывает.
• Собрать все прерывания в кучу. То есть все вопросы и совещания унести на «сразу после утреннего синкапа».
• Горящие вопросы — в звонки. Вопросы, ждущие час-другой — в чаты (режим «не беспокоить»). Вопросы, ждущие день — в письма.
• Если прерывания идут изнутри команды, например есть болтливый сотрудник, то можно выдать каждому комплект шайбочек/фишечек/чего-угодно: «Прервали? Переложи в отдельную кучку. В конце недели посмотрим».

P. S.: Пока писал этот кусок — было два срочных телефонных звонка, письмо, два чата по работе, один не по работе, спам-чат и три прерывания от жены. Везде коротко, но... Хорошо, что код еще не начал писать :) Отключаю нотификации.

Крутой технолог

Менеджер не может быть самым крутым технологом в команде. Если так — это либо он (не)осознанно подбирает людей глупее себя, либо дает просадку в чем-то еще. Тут конечно, есть и особые случаи: «только что перешел из технологии в менеджмент», «накопил большой неустаревший опыт до этого», «супермен из Голливуда» и т. д.

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

Дроны

Дом высотка. Мусоропровод заварен.
Перед подъездом стоят открытые мусорные баки.
Выношу мусор. Сверху зверское жужжание.
Подлетает коптер, сбрасывает пакетик с мусором, улетает вверх.
Оглядываюсь, вокруг никого нет.
Это вообще законно?
© баш

Кстати, роботы отбирают работу.

Скоро будут дроны с функцией «летом днем залетать в открытые окна высоток и тырить деньги и гаджеты» и «зимой срывать шапки с прохожих (Янукович-режим)».

Функция цели

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

В общем-то, это описание с другой стороны: «дайте мне четкие критерии, по которым моя работа будет оцениваться и понятные инструкции, что делать».

«Тех, кто работает по инструкции, роботы заменят в первую очередь» © не моё

А вот умение составить инструкцию... Она всё более высокоуровневая. Не знаю, есть ли там предел. Мне пока не видно.

Сложные вычисления

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

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

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

Странное поведение, да и времени ушло дофига. Начинаю детективно-организационное расследование:

1. Оригинальное ТЗ «сделать как раньше, но на другом языке».
2. Перевод «в лоб» дал совпадение в 95% случаях.
3. Исследование показало, что в старом ЯП использована экзотическая реализация одного алгоритма, предложенная экзотическим вузом много лет назад. Алгоритм, наверное, правильный... Но ни до, ни после больше никто таким алгоритмом не пользовался. И в новом ЯП используется немного другой алгоритм.
4. Программист перечитал ТЗ и начал модифицировать модный алгоритм так, чтобы результат сходился. Алгоритм нагруженный, поэтому со вставками на C. Ну и оттуда уже и до падения не далеко.
5. Поменяли ТЗ до «оценить последствия от перехода на новый алгоритм и перейти на него, если всё ок», и задача решилась за пару дней.

Да, банальный вывод о контроле исполнителей был сделан слишком поздно.

Личность и общество

Личное пространство

У меня появился мой стол и только мой компьютер в 31. До этого всё время он был «конечно твой, но и немного чей-то еще». Моя комната появилась в 39.

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

Котенок

Каждый день в моей ленте новый пост о «возьмите котенка/щеночка».
---
Я могу взять котенка. Взял даже целую взрослую кошку. Очень ценю и пускаю в сейф. Наверное, я мог бы взять еще несколько. Может даже до двух десятков в квартиру, хотя это уже свинство по отношению к людям. После этого моя квартира переполнится. Если брать только из моей фб-ленты — это меньше месяца.
---
Я могу взять те деньги, которые отдаю волонтерам, и снять дом/квартиру где-то в пригороде и нанять человека, который будет за котопарком ухаживать. Наверное, за пару месяцев наполнится, а дальше будет переполнение. При этом котостадо будет людей видеть редко, зато часто будет строить котоиерархию. То есть много агрессивных особей и травм у животных и посетителей. Плюс эпидемии, с которыми бороться дорого.
---
Я могу организовать схему «отлов-стерилизация-возврат». Вот эта схема реально работает, видел в Эйлате, читал еще несколько. Тут бюджет — несколько тысяч долларов в месяц для Харькова. В одиночку я не потяну никак, нужно найти еще несколько айтишников. Решаемо, но насквозь противоречит закону «Про захист тварин від жорстокого поводження». Выпускать нельзя.
---
Пара «что делать?»

1. Нужны другие депутаты. Очень много слов не написал. Вот тот момент, когда орки из ДемСокирыи тролли из ПЦ МП выглядят лучше солидных дяденек с галстуками.
2. Деньги не берутся из воздуха. И я в своем семейном бюджете считаю, что «волонтеры важнее котиков». Для меня это понятно. В городском бюджете считают, что «ремонт туалетов в зоопарке важнее ремонта в поликлиниках». Им это понятно, а мне — нет. Мне понятно, что нужен другой горсовет.

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

Любовь к коду и людям

Программисты любят писать код, который описывает действия компьютера.

Программисты не любят писать и читать контракты/законы, которые описывают действия людей.

Впрочем, читать чужие программы тоже не любят.

Да и людей в общем-то тоже не любят.

* Людей любят рекрутеры и HR.

** В любом правиле есть исключения.

Поломки

Как только у меня дома что-то ломается — хочется починить самому. Оба моих деда были очень рукастыми, и я сам 20 лет назад многое умел. И инструментов у меня много. Унаследованная автоматическая реакция на поломку чего-то — достать инструмент и сделать. Это очень правильная реакция в ситуации дефицита — где ни мастеров, ни материалов нет.

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

Не работайте с мудаками?

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

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

Где упрощение?

«Мудак», скорее всего, не «мудак/немудак», а какая-то шкала, то есть можно сказать: «Вот этот человек больший мудак, чем вот этот». Еще одно упрощение: предполагается, что человек мудак всегда и во всех ситуациях, и не меняется. Еще одно — что я тоже одинаков и не меняюсь. Четвертое упрощение — «мудак» для одного, это совсем не обязательно «мудак» для другого. Вот мои соседи меня считают мудаком, так как я мешаю им петь караоке по ночам. А для моих родных я аж ни разу не мудак, а мудаки — мои соседи, что мешают спать.

Где теряются возможности?

1. Я знаю аутсорсинговую компанию, которая зарабатывает на работе со сложными клиентами. Все остальные отказываются работать с мудаками, а они на этом зарабатывают. Компания крупная, и на рынке давно.
2. «Мудак» — это не фильм ужасов, и даже не контринтуитивная квантовая физика. Под поступками «мудака» прячется какая-то логика, какие-то неочевидные убеждения и ценности. Поняв их, можно подстроиться, ну или как минимум точнее оценить риски. Научившись лучше понимать «мудаков», обычных людей станет понимать намного проще.
3. Люди меняются. Приняв один раз решение «не работать с этим мудаком», через год можно выяснить, что и мои навыки подросли, и человек пересмотрел свои убеждения.
4. Хорошо, когда в команде есть разные люди — при организационной гибкости можно найти подходящего человека для работы с нужным проблемным человеком.

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

Семейные ценности

«Одинокий родитель может сам(а) вырастить ребенка, и все умеют отстаивать свои границы — и это хорошо». Это современный подход.
---
«Ценность имеет только полная семья. Женщина без мужа — неполноценна, мужчина без женщины — либо бабник, либо больной». Это подход предыдущего поколения, там вырастить детей могла только парная семья. И ради детей можно и нужно было терпеть всё что угодно от партнера: ругань, побои, оскорбления, насилие. Ничего личного, исключительно выживание детей. Кстати, «принц на белом коне» и инфантилизм — это отсюда.
---
«Важна большая семья из многих поколений. Да, тебе эта тетушка не нравится, но ты всё равно должен поддерживать с ней отношения — мало ли как жизнь повернется, и, возможно, твоя жизнь или жизнь твоих детей будет зависеть только от дальних родственников». Это подход поколения наших бабушек, и у них были на это основания.
------
Есть у меня гипотеза, что современный подход о ценности жизни и личности опирается на хорошую экономику и медицину и без них невозможен.

Обучение

Сообщество phpпрограммистов

xxx: Как поднять лвл программинга, например с джуниор на мидл и т. д.?

yyy: Нужно убить босса

Трехлетний ребенок

Трехлетний ребенок уже может писать код. Сил нажимать на кнопки хватит.

Что, не выйдет?! Ну да, мозг еще не созрел. Все навыки — в свое время. И у каждого ребенка оно своё для каждого навыка. Некоторые и к сорока не созревают.

Рецепта «как определить, что он(я) уже дорос до навыка Х» у меня нет. Это зона ближнего роста, и по-правильному нужно строить последовательно итерации из микронавыков.

Чай

• Дорогая, сделай, пожалуйста, чаю.
• Угу, ща, подожди.
• Мяяяяяяу! Мяяяяяяу! Мяяяяяяу!
• Так, прости, но сначала я покормлю кота, а потом сделаю чай тебе. Кот громче орет.
• Ах так?! Ну тогда чаааааааай! Чааааааай! Чаааааай!

Что подкрепляешь, то и имеешь. Это и про родственников, и про сотрудников.

Джун

Курировал джун-программиста. Он уперся в проблему, алгоритм написать не может, уже потратил больше 6 часов.
Там есть простое решение, которое он пока не нашел.

Но! В поисках решения он набирает опыт. Когда найдет — получит позитивные эмоции. Если я сейчас дам ему ответ — я отберу у него радость победы и веру в свои силы. Так что пусть пробует.

Мне имеет смысл вмешиваться в двух ситуациях:

1. Когда он скажет: «Всё, мне нужна подсказка».
2. Если я увижу, что он может перегореть на этом.

Ну и потом нужно будет объяснить бизнес-решение для реальных задач: «Если не справился за n-часов — иди к синьору за подсказкой. Не слишком рано и не слишком поздно».

Хайп

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

Мысль вслух, без практических выводов.

Развитие программистов

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

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

Плох тот программист, который не планирует свой стартап

«Хочу сделать свой стартап... Что может пойти не так? Нужно написать код, ну это понятно. Могут закончиться деньги, но с хорошим прототипом я их найду. Могут украсть идею конкуренты, но пока работаю сам — никто и не узнает. Могут быть сложности с юридическими вопросами — потом найму кого-то. Может не быть пользователей — потом найму SMM. А пока буду делать то, что знаю хорошо. Напишу код». Это подход на избегание неудач.

«Хочу сделать свой стартап. Критерий достижения — проект приносит больше денег, чем уносит. Нужны: код, анализ рынка, юридическое оформление. Код — три месяца на аутсорс или девять самостоятельно. Анализ рынка первичный — три дня гугления, вторичный — MVP/RAT тестирование прототипа. Продвижение и засталбливание ниши начинаю как можно раньше. Оформление — два дня на анализ возможных решений по критериям трудоемкость/цена/график». Это подход на достижение цели.

Программисты, склонные к избеганию неудач, часто делают монструозные велосипеды и вкладывают огромное время в обработку ситуаций, которые в реальном мире встречаются у 5% пользователей. Зато надежно.

Программисты, склонные к достижению целей, — часто пишут говнокод. Зато быстро.

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

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

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

* Это модель, которая делит людей по одному признаку на две категории. Большинство людей склонны колебаться туда-сюда в зависимости от внешних обстоятельств.

Делать или смириться?

Краткая фраза «Не можешь изменить ситуацию — измени отношение к ней». Или, в более полной форме, «Господи, дай мне спокойствие принять то, чего я не могу изменить, дай мне мужество изменить то, что я могу изменить. И дай мне мудрость отличить одно от другого» © К. Этингер

В общем и целом — всё правильно. И как всегда при сокращении — очень многое потеряно.

1. Человек в тяжелой для себя ситуации — теряет креатив. Тупо перестает видеть варианты, как изменить ситуацию. Видит только стены, а не проходы между ними. И за собой такое замечал, и на консультациях вижу. Отсюда — невозможность решить ситуацию. Хотя вполне возможно, что другой человек в этой же ситуации с этими же исходными её бы разрулил.
2. Человек в сложной ситуации легко влазит в Игру по Берну «Почему бы тебе не... — Да, но...». Сама теория здорово поменялась со времен Берна, а суть примерна та же — человек сидит в локальном оптимуме и рассказывает, как ему плохо.
3. Самое сложное — человек воспринимает окружающий тупик как объективный. И очень много сил тратит, чтобы это донести окружающим. А попытки его разубедить — воспринимает как атаку.
4. Есть действительно нерешаемые ситуации. Обычно связанные с близкой смертью. С остальными можно покреативить.

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

Проект? Сериал!

Мой нынешний проект — первый в моей жизни, который я измеряю сезонами, как в сериалах.

Первый сезон — программист и архитектор. В конце сезона после внезапного поворота сюжета стал CTO.

Второй сезон менеджерил. Большой найм команды. А вы когда-нибудь собеседовали человека, сидящего на унитазе? Релиз новой версии при переходе с PHP+jQuery на Ruby+React. В конце сезона после моей тяжелой болезни мой заместитель стал начальником, а я вернулся в кодинг. Этакий экшен-сезон.

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

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

Поэтому ищем работу, вместе или по отдельности:

• Я — Ruby on Rails и менеджмент. Фактически у меня уже есть оффер, но если что-то интересное, то почему бы и не поговорить? Ну и с 13 по 28 я в Канаде с тур визитом, так что поговорить лучше до. Если LinkedInнедостаточно, то можно еще почитать серьезно тути не серьезно — тут.
• Синьор-рубист. Из сотен программистов, с кем я работал, — он один из самых быстрых, с точными эстимейтами и красивыми решениями. Один из немногих, кто понимает в секьюрити и читает справочник по алгоритмам в свободное время. Категорически не менеджмент и не фронт. И вообще, без корпоративов. При этом написать в саппорт какого-то третьего сервиса — да запросто. Строго ремоут.
• Middle-to-Senior JS, три с хвостиком года опыта React. Я его учил с нуля до этого, толковый парень с большими перспективами. Очень желательно ремоут.
• Support. Фактически, она одна без перерывов, выходных и отпусков саппортила наш продукт несколько лет. Если бы не она, на ее место пришлось бы брать двоих. Хороший письменный английский. Очень ответственна и исполнительна. Строго ремоут.

Пишите в личку.

В рубрике DOU Проекторвсе желающие могут презентовать свой продукт (как стартап, так и ламповый pet-проект). Если вам есть о чем рассказать — приглашаем поучаствовать. Если нет — возможно, серия вдохновит на создание собственного made in Ukraine продукта. Вопросы и заявки на участие присылайте на editors@dou.ua.

Здравствуйте, читатели! Меня зовут Алексей, я — full-stack программист, на данным момент работаю в EPAM над React Native проектом. Недавно решил начать изучать Python в свободное от работы время, с целью дальнейшего развития в сторону Machine Learning. В итоге я создал небольшой репозиторий Playground and cheatsheet for learning Python, который, надеюсь, будет полезен не только для меня, но также и для тех, кто делает первые шаги в сторону Python.

Идея

Изучать Python 3 я начал с документациина официальном сайте. Мне понравились примеры кода, но, к сожалению, они были там не интерактивными. Хотелось попробовать выполнить код самостоятельно, с разными входными данными и посмотреть на выводимый результат. Также мне лично легче запоминаются конструкции языка, если я их набрал несколько раз вручную. Python-консоль для этого подходит отлично, но хотелось также иметь своего рода шпаргалку, к которой можно было бы вернуться при написании программ в дальнейшем, если, например, возникнет вопрос, как в Python написать цикл `for` и т. п.

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

Реализация

Реализация проекта до той стадии, которая есть сейчас, заняла две недели свободного от работы времени. Информация в основном была взята из официальной документациии w3schools.com.

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

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

Репозиторий также, по моему мнению, является «шпаргалкой» в том плане, что к нему можно вернуться и вспомнить основные конструкции языка, методы объектов и тому подобное. Благодаря тому, что код напичкан `assertion`-нами, пользователи могут проверить ожидаемый результат выполнения функций, не запуская их.

Как пользоваться данным репозиторием

Каждый Python-скрипт в репозитории имеет следующую структуру:

"""Lists  <--- Название раскрываемого топика

# @see: https://www.learnpython.org/en/Lists  <-- Ссылка для дальнейшего изучения

И здесь могут быть общие детали, относящиеся к топику (например что-то про Lists).
"""

def test_list_type():
    """Здесь идет название подраздела (например "Создание списков" или "Методы списков").
    
    И более детальное описание подраздела...
    """
 # Here is an example of how to build a list.  <-- Комментарии, объясняющие код
    squares = [1, 4, 9, 16, 25]
    
    # Lists can be indexed and sliced. 
    # Indexing returns the item.
    assert squares[0] == 1  # <-- Assertion, иллюстрирующий результат выполнения кода.
    # Slicing returns a new list.
    assert squares[-3:] == [9, 16, 25]  # <-- Assertion, иллюстрирующий результат выполнения кода.

Поэтому процесс пользования репозиторием может быть следующим:

• Найти интересующую тему, которую вы хотите изучить или вспомнить.
• Прочитать комментарии, при необходимости перейти по ссылке с более детальным объяснением топика.
• Ознакомиться с примерами кода и «ассершнами».
• Изменить или добавить код и посмотреть, как он будет работать.
• Запустить тестыи проверить стиль написания кода.

Основные разделы репозитория

1. Getting Started.
2. Operators.
3. Data Types.
4. Control Flow.
5. Functions.
6. Classes.
7. Modules.
8. Errors and Exceptions.
9. Files.
10. Additions.
11. Brief Tour of the Standard Libraries.

Выводы и планы

Надеюсь, этот проект будет полезен тем, кто собирается учить Python. Информация в репозитории на данный момент покрывает базовые нюансы Python. Я планирую по мере дальнейшего обучения дополнять репозиторий новыми примерами и разделами. Поскольку проект open-source-ный, то ваши пулл-реквесты с исправлениями и дополнениями приветствуются!

DOU Ревизорпобывал в Хмельницком офисе Stfalcon.com — компании, занимающейся комплексной разработкой веб-сервисов для технологических стартапов и больших бизнесов. Также она владеет экспертизой в транспортной отрасли, туризме и e-Commerce.

Компания была основана в 2009 году в Хмельницком. В 2017 году открыли офис в столице. На данный момент всего в Stfalcon работает 65 сотрудников: 45 — в хмельницком и 20 — в киевском офисе. Из всей команды 37 человек — технические специалисты (включая дизайн, тестирование, системное администрирование), из которых 26 — разработчики.

В округе и поблизости

Офис компании находится на пятом этаже здания по адресу ул. Заречанская, 3/2.

Рядом с офисом есть достаточный выбор заведений, где можно пообедать. Сотрудники частенько заглядывают в булочную «Витрибеньки від куми», которая находится на первом этаже того же здания. Пирог с курицей и кофе обойдется здесь в 35 грн. Полноценно пообедать можно в кафе «Таврии В», что в 20 минутах ходьбы от офиса, или пиццерии «Сан-Ремо», которая находится через дорогу от офиса (средний чек — от 60 до 100 грн). Также в 5-тиминутах ходьбы расположено «Бистро» с грузинской кухней, где можно перекусить лавашем с сулугуни за 25 грн или кебабом за 50 грн.

Чтобы не тратить время, сотрудники все чаще пользуются услугой службы доставки еды. Выбор пал на сервис Cook Drive. Офис-менеджер каждый день собирает заказы до 11:00 и делает общий заказ через сайт. В среднем обед обходится в 50-70 грн.Если брать полноценное первое-второе-компот — в 100 грн.

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

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

Рабочее пространство

Весь офис Stfalcon довольно компактный. Это помещение в 450 м² , которое можно обойти по кругу буквально за 2-3 минуты.Рабочая зона здесь выполнена в стиле одного большого open space пространства, в котором работают все 38 человек. Оно немного зонировано стеной, которая разделяет рабочие места команды разработки и маркетинг с operations team.

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

Сотрудники Stfalcon работают с 9:00 до 18:00 или с 10:00 до 19:00. Каждый может выбрать более удобный для него вариант. При необходимости есть возможность удаленной работы. Чтобы ею воспользоваться, за день до этого нужно согласовать все с PM-мом и/или тимлидом и предупредить всех членов команды. Обед здесь с 13:00 до 14:00 (по данным компании).

Количество квадратных метров на человека в рабочем помещении составляет 11 м² (по данным компании).

Отдых и вдохновение

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

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

DOU Ревизор спрашивает

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

Руслан, Front-end Developer, 3 года с компанией:

Офіс мене в принципі влаштовує. Немає такого, що мені ще тут треба було б. Офіс комфортний, великий, зручний. Подобається дизайн: білі столи, робочий простір класно організований. Лаунж-зона подобається — у теніс можна грати в обід. Розташування офісу мене влаштовує, бо мені звідси 5 хв пішки до дому. Тим, хто далі живе, може, й не дуже комфортно, бо саме на цю вулицю не дуже багато транспорту ходить. Але особисто мені все підходить. Тим паче у нас тут ця вулиця Зарічанська — як Силіконова долина. На ній багато IT-компаній зібралося.

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

Юрий, Back-end Developer, более 3 лет с компанией:

Подобається розташування офісу. Він компактний, все на своїх місцях. Є зона, де можна відпочити, в теніс пограти. Кухня є, велика, зручна.

Що покращити? Мабуть, хотілося б, щоб влітку у робочій зоні було трохи прохолодніше. Коли дуже жарко, кондиціонер не справляється.

Женя, Back-end Developer, 2 года с компанией:

Найбільше, що мені подобається, — я можу взяти ноут, прийти в будь-яку точку офісу і попрацювати. Можу сісти тут, там, взяти пуфік, вийти на кухню, в лаунж-зону. І за день так можу попрацювати на 5-6різних місцях. Це найбільш прикольне.

Друге — офіс дуже просторий. Можна повалятися в обід — поспати в лаунж-зоні, пограти в теніс, поговорити. Тут все зроблено по hi-tech, по-сучасному — це приємно. Дуже класно, що можна збиратися на якісь тусовки — посидіти на кухні, лаунж-зоні.

Я дуже хочу тут класної кави. Я великий кавоман, і мені треба виходити з офіс, і брати там каву, бо тут вона не дуже добра. Це для мене один з найбільших мінусів.

Було би ще кльово, якби були в офісі снеки, напої. Щось таке, що можна було б взяти, швидко перекусити і йти працювати.

Андрей, QA Engineer, 9 месяцев с компанией:

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

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

Александр, Mobile Team Lead, более 5 лет с компанией:

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

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

Ну что, мы поехали дальше... А если вы хотите, чтобы DOU Ревизор приехал к вам, пишите нам — revisor@dou.ua

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

Следите за нами на Facebook — www.facebook.com/dourevisor

Подписывайтесь на видеоканал DOU Ревизор на YouTube.

Фото: Леся Коверега.

[Об авторе: Сергей Кизян — Chief Technology Officer в Intetics с более чем 15-летнимопытом работы в IТ. Разрабатывал на C, C++, Java, C# и .NET, Code Project Legendary Author]

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

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

Кто должен возглавлять CoE?

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

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

Руководитель CoE должен сходиться во взглядах с топ-менеджментом компании. Менеджмент компании может непосредственно влиять на направление, в котором будет развиваться СoЕ. Задача руководителя центра в данном случае — синхронизировать с менеджментом стратегию развития центра и те инновации, которые предлагают его сотрудники.

Лидер СoЕ также должен обладать достаточно глубокими техническими знаниями, чтобы понимать все аспекты и быть в состоянии представить любые подробности работы СoЕ клиенту, менеджменту, новому заинтересованному коллеге и т. д. В то же время лидер должен обладать достаточной харизмой и авторитетом в компании, чтобы привлекать в СoЕ новых разработчиков (как внутренних, так и внешних).

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

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

Пример

В нашем случае лидерами СоЕ становились разные люди. Но показательным будет пример, когда один Senior-разработчик и его инжиниринг-директор услышали о технологии RPA и вместе решили создать СоЕ в этом направлении. Директор из своего бюджета финансировал проект, а разработчик больше года разбирался в области, до этого не известной ему. На данный момент этот разработчик возглавляет целый департамент, который занимается RPA направлением. Этот пример — хороший показатель совместной работы лидера СоЕ и менеджмента компании. И в этом случае нашелся лидер, который построил вокруг себя технологию и команду.

Как финансировать СoЕ?

А сейчас переходим к вопросу, который интересует владельцев компаний в первую очередь. Должен ли CoE иметь отдельный бюджет и должно ли участие в нем сотрудника оплачиваться дополнительно?

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

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

Компания со своей стороны будет обеспечивать нематериальные бонусы — профессиональное развитие участников СoЕ — как hard skills (сертификации, конференции, тренинги, книги), так и soft skills (тренинги по ораторскому искусству, продажи и т. д). Это очень часто будет способствовать и карьерному продвижению разработчиков.

Пример

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

Принципы работы CoE

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

• Попробуйте сделать так, чтобы все CоE в вашей компании работали по одному общему алгоритму, который описывает только базовые подходы и обобщает репортинг и статистику СоЕ.
• В дополнение к первому пункту. Не создавайте строгих правил и процессов. Будьте гибче и всегда помните, что работа в СоЕ — это часто исследовательская работа, которую не стоит загонять в четкие рамки. Дайте инженерам возможность творить.
• Позвольте разработчикам участвовать в построении этих процессов. Не навязывайте правил и не привлекайте сотрудников в СoЕ в приказном порядке.
• Во главе всех СоЕ должен стоять один человек. В Intetics это СТО компании. Мы предполагаем, что СоЕ могут быть абсолютно разными, но все равно в конце все они должны координироваться одним человеком/департаментом.
• Проводите регулярные митинги с командой СoЕ, чтобы понимать, на каком этапе находится каждый сотрудник, каковы дальнейшие планы, и иметь возможность оперативно реагировать на возникающие проблемы.

Как привлекать в СoЕ новых разработчиков?

Как привлекать новых участников? Как рекламировать СoЕ среди сотрудников? Нужно ли говорить о запуске центра вне компании?

Внутри Intetics мы делаем работу СoЕ максимально прозрачной. Регулярно рассылаются R&D newsletters, где мы говорим о достижениях СoЕ и его участников, о возникающих проблемах и о том, как эти проблемы решаются. О центрах мы говорим сотрудникам через каждый канал коммуникации в компании.

Отмечу самое главное: СoЕ должны быть интересны топ-менеджменту компании. Без этого достаточно сложно что-то предпринимать. И, несмотря на то, что на первых порах СoЕ — это своеобразное начинание внутри компании, он должен быть частью компании и частью бизнеса, а не просто развлечением для разработчиков.

Что нужно, чтобы превратить CоE в новое направление бизнеса?

Когда СoЕ станет новым направлением бизнеса? Как развить СoЕ до нового направления в компании? Нужно ли это делать на первых порах?

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

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

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

Пример

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

RPA CоE начинался, по сути, с работы двух энтузиастов. Поначалу ребята получали базовые знания в RPA самостоятельно и тренировались «на кошках»: роботизировали текущие фронт-офис задачи одного из проектов и внутренние бэк-офис процессы компании.

Все экспериментальные боты хорошо зарекомендовали себя внутри компании и реально сократили количество ручных операций. В тот момент и было принято решение создать отдел RPA.

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

Выгоды

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

Развитие СoЕ в любом случае — это выгодная инвестиция. Если что-то не получится с самого начала, вы получаете следующие выгоды:

• Высокую квалификацию ваших сотрудников и увеличение количества экспертов компании.
• Более высокое качество существующих проектов (если в текущем проекте работают со стеком технологий СoЕ).
• Помощь рекрутингу в проведении интервью по стеку СoЕ, повышение качества ваших интервью.
• Помощь вашей команде продаж, если прорабатывается потенциальный проект со стеком СoЕ.
• Улучшение имиджа компании благодаря регулярным отчетам CoE во внешних ресурсах.

Заключение

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

Всем привет, меня зовут Клименко Руслан. Сейчас я ведущий разработчик програмного обеспечения в одной из украинских аутсорсинговых компаний, part-time архитектор и создатель образовательного проекта Dobroe IT.

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

Главная цель статьи — познакомить в первую очередь Java-разработчиков с Kotlin, показать, каким образом этот язык может упростить работу инженера, победить рутину и сделать программирование под JVM весёлым опять. Ну, или около того.

Бытует мнение, что Kotlin — это нишевый язык, который заточен лишь на работу в экосистеме Android. Тем не менее мой опыт говорит мне о том, что это не совсем так.

На данный момент я реализовал около 10 enterprise-проектов с использованием этого языка, и во всех случаях он был незаменимым помощником. Оборачиваясь назад, хочу сказать, что сейчас у меня нет никаких стимулов возвращаться к использованию pure Java для enterprise-приложений. Более того, JetBrains (да-да, те самые ребята, которые создали лучшую IDE для Java-разработчиков, также являются создателями Kotlin) внедряют язык не только в мир JVM, но и в мир браузерных приложений (существует родной компилятор Kotlin в JavaScript), и даже в native код (проект Kotlin Native).

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

Как мы будем знакомиться с Kotlin?

В качестве метода исследования мы будем использовать декомпиляцию ПО, написанного на Kotlin, в код на Java. Такое преобразование возможно в силу того, что Kotlin, так же, как в свою очередь и Java, Scala, Groovy и многие другие языки, компилируются в bytecode виртуальной машины Java (JVM bytecode).

То есть все эти языки позволяют создавать программы, работающие на JVM, и, соответственно, в скомпилированном виде такие программы будут выглядеть приблизительно одинаково. Следовательно, декомпилируя bytecode программы, изначально написанной на Kotlin, мы увидим то, как бы мы должны были писать на Java, чтобы получить такой же результат.

Пошагово процесс декомпиляции выглядит следующим образом:

1. Пишем программку на Kotlin.
2. Компилируем её с помощью компилятора kotlinc.
3. Декомпилируем приложение в Java-код с помощью стандартного декомпилятора IntelliJ IDEA (конечно же, любой другой адекватный инструмент также подойдет).

Самая простая программа на Kotlin и ее декомпиляция

Традиционно первое приложение, которое мы напишем на новом языке, будет: «Привет, мир!». Открываем свою любимую IDE, создаем файл Test.kt и пишем следующий код:

fun main(args: Array<String>) {
    print("Hello world")
}

Что мы только что сделали? Мы создали метод main, который принимает массив строк (да-да, тот самый, родной). В глаза сразу бросаются некоторые отличия от Java. К примеру, при определении метода нужно теперь использовать ‘fun’, а вот ‘return type’ для ‘void’ методов указывать не обязательно. Параметры метода также объявляются чуть по-иному: вначале определяем имя, потом — тип.

По сути, этого кода вполне достаточно, и теперь мы можем смело воспользоваться компилятором kotlinc (скачать и установить его можно отсюда). В результате мы увидим файл с именем TestKt.class.

Далее, если вы используете IntelliJ IDEA — открываем окно Kotlin Bytecode и видим привычный для всех Java-разработчиков набор мнемоник.

Увеличить

До нашей заветной цели — декомпиляции программы — остался последний шаг. Нужно нажать на кнопочку «Decompile» в левом верхнем углу окна Kotlin Bytecode. Нажимаем и... Вуаля! В главном окне мы видим следующее:

Увеличить

Только что мы написали программу на Kotlin, скомпиллировали её, а после — превратили в программу на Java, используя декомпилятор.

Что мы видим в декомпилированном коде

Давайте разберем всё по порядку:

1. Исходный код программы на Kotlin содержал всего один метод — main, который был объявлен на уровне файла. Как мы знаем, в Java так делать нельзя. Все методы, включая метод main, должны быть объявлены в классе. Kotlin же упрощает жизнь программистов и позволяет писать методы в различных контекстах — на уровне файла, класса или другого метода. А вот для совместимости с виртуальной машиной Java Kotlin обязан добавлять методы, которые просто лежат в файле в класс. И поэтому в таком случае автоматически создается класс с именем файла + Kt (в нашем случаем мы видим класс TestKt).

Внутри класса мы видим вполне ожидаемый метод main с соответствующей сигнатурой. На что стоит обратить внимание: параметр метода помечен аннотацией @NotNull (зачем это нужно, можно узнать вот тут).

На самом деле в Kotlin довольно жесткая система типов. Существует две категории: те, которые могут принимать значение null (nullable типы), и те, которые не могут содержать null (not nullable).

По умолчанию все типы в Kotlin not nullable. Если вы всё же любите экстрим и хотите рискнуть, создать nullable тип — то вам прийдется явно об этом сказать компилятору с помощью символа ?. К примеру:

String — not nullable,
String? — nullable.

В методе main есть еще одна инструкция, которая связана с системой типов в Kotlin:

Intrinsics.checkParameterIsNotNull(args, "args");

Именно в этой строчке и происходит актуальная проверка параметра (args в нашей программе объявлен как not nullable). Если args всё же null, то checkParameterIsNotNull выкинет исключение.

Хорошая новость состоит в том, что внутри Kotlin-приложения все проверки типов происходят еще на этапе компиляции. Все not nullable переменные будут считаться безопасными, а при работе с nullable переменными компилятор будет просить указать явно, что делать в случае, если значение равно null.

Однако при разработке приложения, использующего другие JVM-языки, kotlinc сам по себе не может понять — может ли вернуть метод, написанный на другом языке null, или нет. И для решения этой проблемы можно использовать следующие правила:

• Если вы имеете возможность модифицировать код на другом языке — используйте аннотации @NotNull и @Nullable, которые подскажут компилятору Kotlin как воспринимать возвращаемый тип.
• Если у вас нет полномочий или возможности модифицировать код на другом языке — воспринимайте все типы как nullable по умолчанию и делайте все соответствующие проверки на начальном этапе выполнения приложения.

Второй подход хоть и является более энергозатратным, но все же более предпочтителен в силу того, что, вероятно, вам прийдется столкнуться не только с JVM-based языками, а и с другими сторонними системами (databases, message brokers, web services etc.), а они в свою очередь также могут возвращать null-значения.

3. Аннотация метадата. Зачем она нужна? Короткий ответ: для того, чтобы отобразить в рантайме, который будет использовать всю ту же старую добрую JVM, те нюансы, которые есть в Kotlin, но не существуют в Java (к примеру, разницу между mutable vs immutable коллекциями).

На примере ‘Hello world’ мы прикоснулись к Kotlin и даже посмотрели, что именно он делает за нас для того, чтобы мы могли быстро писать код. На самом деле пока что мы не видели ничего удивительного, а лишь познакомились с методом декомпиляции, который каждый может использовать самостоятельно для того, чтобы изучать JVM-языки.

Еще несколько примеров программ на Kotlin

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

‘Extension methods’ позволяют добавлять методы для типов вне их контекста. Ниже представлен пример метода, который может быть реализован на уровне файла. Этот метод расширяет класс String, добавляя метод encode (caesar encryption).

fun String.encode(shift: Int) =
        String(this.map { it + shift }.toCharArray())

Интересно, что методы, имеющие всего одну инструкцию, могут быть реализованы с помощью оператора присваивания (идея не новая, но человеку, работающему только с Java, это может показаться интересным). Возвращаемый тип в таком случае указывать явно также не нужно. Компилятор достаточно умный, чтобы понять, что к чему самостоятельно. После объявления метода encode мы готовы его вызывать:

fun main(args: Array<String>) {
    print("test".encode(3))
}

Как же работают Extension methods? Ведь мы с вами знаем, что наследовать финальные типы нельзя (а String, как известно, является final).

Давайте посмотрим на декомпилированное приложение:

Увеличить

Теперь всё становится на свои места. Конечно же, никакого наследования здесь нет. Метод encode не объявлен в классе String или его подтипе. Это обычный статический helper-метод, который лишь принимает строку в качестве параметра, а при вызове метода данная строка в него и передается.

Очень удобно, что в Kotlin мы можем делать подобные вещи всего в одну строчку.

Предлагаю рассмотреть ещё один, на этот раз последний, пример того, как Kotlin упрощает жизнь разработчикам.

Все мы не раз писали классы, которые содержат лишь состояние (JPA Entities, Domain models, DTOs и многие другие). И, конечно же, нам очень не хотелось писать к ним те самые канонические toString(), equals() и hashCode(), а также вечные getters-setters. Некоторые из нас даже пытались использовать Lombok, и это очень хорошо. Кто-то устал и отправился в мир абстрактных вычислений Scala, и это нормально (хотя могло быть и лучше). Но сейчас я хочу показать, что по этому поводу думает Kotlin. Предлагаю рассмотреть следующий пример:

data class Test(val a: String = "", val b: Int = 0)

Data classes. При добавлении всего одного ключевого слова ‘data’ перед объявлением класса на выхлопе мы получаем следующую программу:

public final class Test {
   @NotNull
   private final String a;
   private final int b;
   @NotNull
   public final String getA() {
      return this.a;
   }
   public final int getB() {
      return this.b;
   }
   public Test(@NotNull String a, int b) {
      Intrinsics.checkParameterIsNotNull(a, "a");
      super();
      this.a = a;
      this.b = b;
   }
   // $FF: synthetic method
   public Test(String var1, int var2, int var3, DefaultConstructorMarker var4) {
      if ((var3 & 1) != 0) {
         var1 = "";
      }
      if ((var3 & 2) != 0) {
         var2 = 0;
      }
      this(var1, var2);
   }
   public Test() {
      this((String)null, 0, 3, (DefaultConstructorMarker)null);
   }
   @NotNull
   public final String component1() {
      return this.a;
   }
   public final int component2() {
      return this.b;
   }
   @NotNull
   public final Test copy(@NotNull String a, int b) {
      Intrinsics.checkParameterIsNotNull(a, "a");
      return new Test(a, b);
   }
   // $FF: synthetic method
   // $FF: bridge method
   @NotNull
   public static Test copy$default(Test var0, String var1, int var2, int var3, Object var4) {
      if ((var3 & 1) != 0) {
         var1 = var0.a;
      }
      if ((var3 & 2) != 0) {
         var2 = var0.b;
      }
      return var0.copy(var1, var2);
   }
   public String toString() {
      return "Test(a=" + this.a + ", b=" + this.b + ")";
   }
   public int hashCode() {
      return (this.a != null ? this.a.hashCode() : 0) * 31 + this.b;
   }
   public boolean equals(Object var1) {
      if (this != var1) {
         if (var1 instanceof Test) {
            Test var2 = (Test)var1;
            if (Intrinsics.areEqual(this.a, var2.a) && this.b == var2.b) {
               return true;
            }
         }
         return false;
      } else {
         return true;
      }
   }
}

Круто, правда? :) Кроме озвученных getters-setters, toString(), equals(), hashCode(), мы также получаем перегруженный конструктор, метод copy, выполняющий поверхностную копию над объектом и методы componentX(), которые используются при деструктуризации.

Итоги и советы

На самом деле Kotlin таит в себе ещё много секретиков, но нам пора закругляться. Я хочу спать, да и лонгриды никто не любит. Я надеюсь, что этой статьей я заинтересовал вас (особенно если вы java-разработчик). Ну а дальше...

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

0. Мой толкна JEE Conf. По сути, эта статья — краткий его пересказ.

1. Книжка «Kotlin in Action».

2. Задачки Kotlin Koans.

3. Документашка.

А еще мы в Dobroe IT планируем сделать курс по Kotlin этой осенью. Поэтому если вы молоды, горячи и очень хотите, то можно вступить в нашу группуи смиренно ждать анонса курса.

На этом сегодня всё. Спасибо за внимание. Будьте счастливы.

У випуску: відео Laracon 2018, автоматизація деплойменту, конференція Highload fwdays’18, реліз PHP 7.3.0.beta3, що краще .env чи config.php.

Основне

Що нового в РНР 7.3 за 30 секунд

Стан Developer Ecosystem в 2018

Caching strategies

Туторіал по SPA Vue + Symfony

Laracon 2018 videos

Remote Code Execution on packagist.org

How To Automatically Deploy Your PHP Apps

PHP Benchmarks: OPcache vs OPcache w/ Performance Tweaks

Strategies for dealing with poor code in limited time

What’s wrong with popular articles telling you that foo is faster than bar?

Відеозаписи з конференції CODEiD PHP, Odessa, 2018

Івенти

• 15 вересня відбудеться вже другий рік поспіль масштабна конференція для розробників Highload fwdays’18. Цього року плануємо зібрати понад 1000 учасників. Конференція проводиться пройде y 4 потоки доповідей та Speakers’ Corner. Попередня програма.

Серед спікерів: Philipp Krenn (Elastic), Alkin Tezuysal (Percona), Олександр Соловйов (Kasta), Дмитро Волошин (Preply.com), Михаїл Овчінніков (Badoo) та інші.

Для читачів дайджесту — промокод на знижку 10%: dou-digest-fwdays. Купити квитки.

• 13 вересня буду виступати в Харкові на PHP Evening. Івент орієнтованний на junior- та middle-розробників. Розповім про native PHP extensions. Приходьте, буде цікаво.
• 1 вересня Михайло Боднарчук провів відкриту лекцію для doge.codes про автоматизоване тестування за допомогою Codeception. Відеозапис доступнийна YouTube.
• doge.codes проводить курс по основам PHP. Під час курсу ви вивчите основи РНР та напишете свою версію Twitter на ООП.

Також відкритий набір на курс по React. Стань профессіоналом в Реакті всього за 6 тижнів за підговтовленою програмою і практичними завданнями. Для читачів дайджесту — промокод на знижку 10%: DOU_DIGEST. Детальна інформація.

Релізи

PHP 7.3.0.beta3 Released

PHP 7.1.21 Released

PHP 7.2.9 Released

Laravel 5.7

Google App Engine with PHP 7.2

AWS with PHP 7.2

Open source

PHP project scaffolding tool

Show syntax-highlighted code of 150+ languages in your terminal

Різне

Що краще .env чи config.php?

Is PHP good for freelancing ?

Do you think being a programmer has made you more pessimistic

З вами був Роман Севастьянов.

Підписуйтесь на мій Телеграм канал про PHP — я там публікую новини зі світу PHP, security баги в live режимі.

← Попередній випуск: PHP дайджест #15

В выпуске: Robustness of Go, Clean code using decorators, Go modules простыми словами, методы обработки ошибок, которые облегчают отладку.

Новости

Go 1.11 Released — последний мажорный релиз с поддержкой модулейи эксперементальной поддержкой WebAssembly. Release notes.

A Gentle Introduction to Go Modules — Go modules простыми словами.

Go 1.11’s Versioned Modules Documentation

HTTP/2 Adventure in the Go World — net/http теперь поддерживает http/2, ну почти.

Go Was The Fastest Growing Language Used in GitHub Pull Requests in Q2 2018.

Tutorials & Articles

Getting Started with Go Development on the Pixelbook

A Good Makefile for Go — пример Makefile, который включает „hot reloading”.

Deploy a Buffalo App to DigitalOcean with Docker

Clean Code using Decorators — как сделать код чище используя декораторы.

Refactoring Go Switch Statements

Goodbye Python, Hello Go — история одного разработчика о том, как он начал использовать Gо вместо Python.

Build a Multiplayer Game in Go with PubNub

Write Go, Run WASM — очень короткий туториал по WebAssembly.

Building a Serverless Function using the Serverless Framework and Go

Interacting with Ethereum Smart Contract Events in Go

Some Go Error Handling Practices — несколько методов обработки ошибок, которые облегчают отладку.

Using Go Modules with Vendor Support on Travis CI

Circuit Breaker and Retry — отказоустойчивость в микросервисной архитектуре.

How to Use the Official MongoDB Go Driver — включая использование модулей Go 1.11.

Cloudflare’s Journey Porting Its Software to ARM64 — интересный опыт от Сloudflare о том, как они портировали свой код на ARM64.

Accessing Data in Go — демонстрация подхода для доступа к данным при написании веб-приложений.

Building a Calculator with Go WebAssemply.

’How We Massively Reduced Our AWS Lambda Bill With Go’

Посмотреть

Brian Kernighan on Go, Programming Languages, and Computer Science

Linear Regression with Gradient Descent

Go: Building on the Shoulders of Giants and Stepping on a Few Toes — история Go и почему создатели языка приняли определенные дизайнерские решения.

Building a Network Command Line Interface Tool in Go

Building Go Applications for the Open Cloud

The Robustness of Go — доклад охватывает проектные решения Go, которые помогают в создании надежных программ, но также и недостатки Go в этой области, особенно в сравнении с Erlang.

Building a Resilient Stream Processor in Go

Dave Cheney — Don’t Just Check Errors, Handle Them Gracefully

Building a Production-Ready Go Service in 30 Minutes — live coding сессия из GopherCon UK, на которой разрабатывается production-ready сервис и деплоится при помощи Docker.

Инструменты и библиотеки

go-sqlite-lite — SQLite драйвер. Поддерживает SQLite’s online backup APIи BLOB incremental IO.

gosec — проверка безопасности кода. Выполняет ряд правил над абстрактным синтаксическим деревом Go кода, чтобы выявить потенциальные проблемы.

Beego — Framework для быстрой разработки RESTful APIs.

Heighliner — Continuous Delivery из GitHub в Kubernetes Cluster.

repo-security-scanner — CLI инструмент для поиска приватных ключей, паролей и т. д., которые были закомичены в Git.

Chart — генерация графиков на основе данных из STDIN. Умеет генерировать „pie charts”, „bar charts” и т. д. во временную HTML-страницу.

embiggen-disk — рекурсивный Live-Resize файловой системы в Linux от Google.

ZikiChombo — библиотека для обработки звука.

Bild — коллекция алгоритмов параллельной обработки изображений. Ресайзинг, повороты, изменение цвета и т. д.

Rclone — ’Rsync for Cloud Storage’ поддерживает ~20 платформ.

gomarkov — библиотека имплементирующая цепи Макова.

Goofys — POSIX-ish Amazon S3 File System. Позволяет примаунтить S3 бакет в виде файловой системы.

morse — библиотека кодов Морзе. Мало ли что может произойти...)

SSO Authentication Proxy от BuzzFeed — ребята из BuzzFeed выложили в open source свою реализацию SSO Authentication Proxy и описали, как она работает.

Vegeta — библиотека для тестирования HTTP-нагрузки с поддержкой HTTP/2.

GopherCon 2018 Performance Tuning Workshop — код, упражнения и расписание GopherCon Performance Tuning Workshop от Dave Cheney.

Fleep — библиотека для определения формата файла. Распознает около 100 форматов.

lazygit — консольный UI для Git-команд.

Zap — библиотека для логирования от Uber.

go-health — „Health Checking” библиотека для Go-Powered сервисов.

Noti — мониторит процесс и тригерит уведомление по завершению.

← Предыдущий выпуск: Go дайджест #4.

У рейтингу вишів DOU Чернівецький національний університет імені Юрія Федьковича отримав оцінку вищу за середню і зайняв 5 місце. Цього року виш уперше потрапив до рейтингу.

Чернівецький національний університет готує IT-спеціалістів на двох відділеннях: в Інституті фізико-технічних та комп’ютерних наук і факультеті математики та інформатики. Розглянемо особливості навчання на кожному з них.

Щоб ви могли на власні очі побачити, що і як відбувається в університеті, ми туди вирушили з фотографом і все зафіксували.

Інститут фізико-технічних та комп’ютерних наук

В інститутіготують фахівців із IT за трьома спеціальностями: інженерія програмного забезпечення, комп’ютерні науки та комп’ютерна інженерія. Навчальні програми та плани відрізняються для кожної з них, проте такі загальні дисципліни, як математика, фізика, теорія ймовірності, читаються для всіх.

Ютуб-канал кафедри програмного забезпечення

У 2017-мупроходила акредитація зі спеціальності «Інженерія програмного забезпечення», тож програми оновили. Як розповідає один із викладачів факультету, вносити корективи в навчальні курси намагаються і поза тим, відповідно до потреб часу.

Так, до прикладу, для першого курсу у першому семестрі читають основи програмування (C++), а другий семестр — вже основи ООП (об’єктно-орієнтованого програмування). Протягом останніх двох років ввели такі курси, як: технології програмування мовою Python, програмування мобільних додатків (Android) і т. д. Читають курси під web-програмування PHP, JavaScript, Angular. Вивчають такі мови програмування: С/C++, C#, Java, JavaScript, Python, PHP.

На кафедрі «Інженерія програмного забезпечення» хочуть спробувати новий курс по Arduino. «Подивимося, як сприймуть студенти, а тоді вже будемо остаточно вводити», — каже викладач кафедри Сергій Янушевський. На цій кафедрі також вивчають групову динаміку та комунікації, (технології Scrum, Agile), якість та тестування ПЗ, аналіз вимог до ПЗ, менеджмент проектів ПЗ, інструментальні засоби розробки ПЗ (Microsoft Visual Studio, Code::Blocks, CLion, Eclipse, IntelliJ IDEA, Rider, PhpStorm, PyCharm, AngularJS, FrontPage, Django, WebStorm, Unity), системи управління базами даних (MySQL, PostgreSQL, Oracle, SQLite, HyperSQL, Apache Derby, H2, MongoDB).

Також студенти вивчають бази даних, комп’ютерну графіку, програмування мультимедіа, штучний інтелект, конструювання ПЗ, архітектуру та проектування ПЗ, аналіз вимог до ПЗ, мережі, основи криптографії та захисту інформації, тобто ті дисципліни, які пов’язані з програмуванням та розвитком логіки. Також у переліку навчальних дисциплін — паралельні та розподілені обчислення, диференціальні рівняння, комп’ютерний дизайн, теорія алгоритмів, теорія робототехніки тощо.

Курси викладені на сайті університету у розділі електронне навчання, Moodle, де студенти можуть проглядати курси дистанційно в будь-який час, незалежно від відвідування університету.

Серед викладачів є і доктори та кандидати наук, і молоді фахівці, — багато з них також працюють в IT розробниками програмного забезпечення. Таким чином можуть не просто пояснювати теорію, а й розповідати, як застосовувати методи і шаблони ПЗ на практиці.

Кожна спеціальність передбачає проходження виробничої практики: студенти, відповідно до своєї спеціальності, чотири тижні мають пропрацювати на IT-фірмі. Здебільшого домовляються про неї самі. Якщо ж не можуть знайти, допомагають викладачі. Серед компаній, де практикуються студенти: SoftServe, Yukon, Desyde, Datawiz, AMC Bridge, OSF Global та ін. Також Інститут співпрацює з місцевим ІТ-кластером.

Матеріально-технічна база складається з п’яти комп’ютерних класів, шести комп’ютеризованих лабораторій, лабораторії IP-телефонії, лабораторії міжнародної академії CISCO з комп’ютерних мереж. За оцінкою самих викладачів, матеріально-технічна база не встигає за розвитком галузі, хоча основні потреби забезпечує.

«Серед девелоперів, якщо ти програміст, то повинен мати власний ноут, який буде налаштований під тебе і твої потреби. Тож я виступаю за те, щоб університет забезпечував доступний Wi-Fi та робоче місце, а не якийсь умовний комп’ютер. Хоча для першого курсу потужностей тієї техніки, яку ми маємо на сьогодні, цілком вистачає. А студенти вже других-третіх курсів віддають перевагу власним ноутбукам. На лекціях користуємося мультимедійними дошками та проекторами, відкриваємо доступ до курсів в Moodle, маємо власні сервери. Тож, думаю, якихось труднощів в цьому плані у студентів не повинно виникати», — розповідає Янушевський.

Викладач зауважує тенденцію: якщо ще років 10 тому на роботу в IT-фірми йшли лише випускники п’ятих курсів, то тепер студенти починають працювати вже з другого-третього курсу. Відтак по закінченні університету вони мають 2-3роки досвіду роботи в ІТ. Це буквально всі ІТ-фірми міста Чернівці. Основні з них: SoftServe, SharpMinds, AMC Bridge, OSF Global, Desyde, Yukon, MobiDev та ін.

Відгуки студентів

Після того як я закінчив коледж за спеціальністю «Розробка програмного забезпечення», зрозумів, що формальна освіта у царині комп’ютерних наук інертна до змін і перевантажена гуманітарними дисциплінами на кшталт соціології, філософії, БЖД. Тому довести до пуття освіту (після коледжу є можливість одразу вступати на третій курс бакалаврату) я вирішив на заочній формі навчання за напрямом «Програмна інженерія», а стаціонарно пішов студіювати свій незакритий гештальт — теоретичну фізику.

Зазвичай, у моєму випадку на заочку забивають і просто приходять вже на іспити, але я старався. Особливо мені полюбилися такі курси, як «Теорія автоматів», «Теорія керування», «Дослідження операцій» (саме тут я вперше познайомився з градієнтим спуском — важливим математичним трюком для навчання нейромережі), «Криптографія». Тобто теоретичну базу, на якій стоїть цифровий світ сьогодні, тут отримати можна легко і якісно. Але якщо говорити про якісь останні тенденції — вони надто мінливі для університетських програм.

Вас не навчать писати SPA на ReactJS або розгортати проекти на Spring, але доступно розкажуть різницю між UDP i TCP, які є метрики складності алгоритму і що таке нормалізація баз даних. Це те, чого не вистачає програмістам-самоучкам, і те, що вони змушені вивчати самостійно, щоб зрозуміти, що відбувається під капотом фреймворка.

Андрій, випускник

***

Я закінчив бакалаврат на спеціальності «Комп’ютерні системи і мережі», після чого вступив на магістратуру. Загалом, на мою думку, програма навчання мало чим відрізняється від інших універів. Частина програми є класичною, і вона навряд чи колись застаріє (математика, фізика, алгоритми, тощо), а частина, звісно, застрягла в середині 90-х (паскаль, браузерні аплети на джаві, верстка таблицями). Все це дуже сильно відрізняється від предмету до предмету і залежить від викладачів і того, наскільки їм не байдуже.

Моя спеціальність більше пов’язана з залізом і на виході з універу я мав би стати проектувальником усіляких мереж, мікросхем, тощо. Так склалося, що мені цікавіше програмувати, ніж сидіти з паяльником, тому у моєму випадку програма з життям пов’язана лише базовими предметами, які розширюють кругозір.

Загалом помічаю, що програма дуже академічна і розрахована на навчання не «у глибину», а «в ширину». Нас вчили всього: креслення, фізики, планування, культурології, менеджменту, алгоритмів, екології, програмування, політології, криптографії, безпеки життєдільності, схемотехніки, охорони праці. З одного боку, я розумію, що це університет, що він мав би давати універсальну освіту, що це все потрібно для розширення кругозору, але до вирішення практичних задач більшість випускників не готові. Хотілося б більшого заглиблення у деталі, виставлення акцентів на те, де вивчену теорію можна застосувати на практиці, в нелабораторних умовах.

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

Багато курсів заточені на вивчення софту, який здебільшого є пропрієтарним (продукти Autodesk та Adobe, Proteus Design, тощо). Виходить, що студенти повинні піратити софт, щоб мати можливість зробити лабораторні. Часом буває таке, що лабораторні роботи заточені під конкретну версію програми. Найбільше болю ти отримуєш тоді, коли приходиш на пари з макбуком чи ноутбуком на Linux — це я з власного досвіду кажу. Доводилось піднімати віртуалку з віндоусом.

Безсумнівно корисними є вища математика, дискретна математика, основи програмування, ООП, інші предмети пов’язані з програмуванням — їх було кілька протягом всього навчання. Інженерія програмного забезпечення — крутий предмет, на якому нам розповідали про процес розробки ПЗ: патерни проектування, всілякі аджейли, скрами. А ще системне програмне забезпечення — адміністрування серверів, компілятори, інші системні штуки. Це ті предмети, які були корисні для мене. Напевно, якщо б я захоплювався залізом, то їх було би більше.

Викладачі є різні. Є такі, яким байдуже, — вони приходять, читають лекції з листочків, йдуть додому, все. Є викладачі-практики, які мають досвід роботи в реальних проектах, які намагаються тримати навчальні програми актуальними, доносити студентам щось цікаве. Є викладачі-ветерани, які почивають на лаврах і дивляться на студентів з висоти своїх років. Є викладачі-друзі, які поважають студентів, а студенти поважають їх. Найбільше проблем і конфліктів виникало з викладачами непрофільних предметів: основи охорони праці, культурологія, екологія. Студенти часто ставляться зневажливо до цих предметів, а викладачі зі свого боку вважають свій предмет найважливішим. Хоча, мушу сказати, що після того, як послухаєш історії студентів інших факультетів, складається враження, що наші викладачі найбільш адекватні в усьому університеті.

Багато бюрократії. В університеті відчувається запашок нафталіну. Є викладачі, які можуть «дрючити» за оформлення лабораторної, при цьому навіть не подивитись на якість виконання самого завдання — це дико демотивує. Багато викладачів люблять патетизм, люблять коли їх просять, люблять відчувати себе важливими. Це я загалом про весь універ.

В універі багато різних студентських ініціатив, до яких можна приєднатися. Ми, наприклад, організували NodeSchool Chernivtsiразом з іншими небайдужими (не лише студентами), з якого потім виросла спільнота ChernivtsiJS. Приємно, що викладачі нашої кафедри такі ініціативи підтримують. Власне, сама щорічна конференція ChernivtsiJSпроходить за підтримки універу.

Була навіть мова про те, щоб ми вели для студентів факультативний курс із веб-розробки спільно зі спеціалістами місцевих компаній. З цим якось не склалось, але ми принаймні провели Kottans Chernivtsi Frontend Course 2017.

Загалом можливостей в універі більш ніж достатньо. Періодично сюди приходять представники місцевих компаній і розповідають про те, чим вони займаються, запрошують до себе. У нашому відділі інституту проводять так званий «Ярмарок вакансій» — це день, коли представники компаній приходять в універ, розкладають свої стенди, спілкуються зі студентами, ведуть невеликі корисні лекції, проводять розіграші, запрошують на співбесіди. Знаю, що не один студент так знайшов собі роботу.

Викладачі, як правило, ставляться до тих, хто працює за спеціальністю, лояльніше.

Мені здається, що я в універі отупів. Після школи я писав гарні есе, цікавився літературою, ще навіть вибирав між журналістикою і програмуванням. Закінчивши бакалаврат, розумію, що словниковий запас у мене скоротився і наповнився англіцизмами, я роблю все більше і більше помилок на письмі (я ж узагалі розучився від руки писати!), а літературу я зараз читаю здебільшого технічну. Не знаю, наскільки це пов’язано з універом. Можливо це наслідок такої собі профдеформації.

Варто було би тісніше взаємодіяти з компаніями, які займаються професійною розробкою: робити спільні курси, оновлювати навчальні програми, робити гостьові лекції. Студенти отримували би чіткіший вектор для розвитку і самоосвіти, а компанії знаходили би потенційних співробітників.

Після переїзду в новий корпусситуація сильно покращилася — тепер у нас є просторі, світлі і найголовніше теплі аудиторії. Зараз бачу тенденцію, що в аудиторіях активно оновлюють меблі. На поверхах є стабільний Wi-Fi (можна навіть приходити на пари, як у коворкінг, і працювати).

З технічним забезпеченням усе гірше. Є кілька лабораторій з відносно новими комп’ютерами, але є комп’ютери та комплектуючі, яким по 20 років. У більшості студентів це не викликає проблем, адже всі ходять з власними ноутбуками.

Денис, студент

***

Навчальну програму складно оцінювати, бо вона постійно змінюється та еволюціонує. Коли я вступав, то готувався до певних курсів, про які дізнавався від старшокурсників. На практиці ж виявилося, що вже в моєму розкладі їх замінили на більш актуальні. Те ж стосується і нинішніх студентів. Спілкуючись з ними та викладачами, знаю, що програма постійно підлаштовується під сучасні тренди.

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

З професійної точки зору найбільше в роботі зараз, звісно, використовую знання та навички, набуті під час курсів, що стосувалися власне спеціальності. Глобально ж найкориснішим предметом, який стає в нагоді щодня й максимально широко, назву англійську мову: 3 семестри навчальної програми та 5 семестрів поглибленого факультативного вивчення за спеціальністю програмного забезпечення систем.

Моя кафедра програмного забезпечення комп’ютерних систем має гарні стосунки з низкою ІТ-компаній і організовує спільно з ними цікаві проекти, які допомагають отримувати знання «з поля бою». Свого часу це були ІТ-академії, конференції тощо, що створювали можливості для активної інтеграції до професійної спільноти. У нас регулярно відбувалися зустрічі з представниками ІТ-компаній, найкращі студенти могли брати участь у спільних з ними академіях. Зрештою, на свою нинішню роботу я потрапив після університетського стажування. Будь-яке розкриття своїх здібностей насамперед залежить від самої людини. Наш навчальний процес цього точно не обмежував і створював низку додаткових нагод.

Матеріально-технічна база в ІТ-сфері має оновлюватися постійно, щоб йти в ногу з часом. У часі мого навчання такий процес, хоч, на жаль, і не максимально регулярно, мав місце, в тому числі — завдяки меценатству колишніх випускників.

Навчальна програма цінна багатогранністю, водночас, гадаю, на останніх роках навчання варто було б мати декілька альтернативних напрямів із додатковими предметами більш вузької спеціалізації, відповідно до вподобань студентів, які вони сформували протягом перших курсів. А ще дуже хотілося б, щоб навчати могли і мали мотивацію люди, які безпосередньо й на високому рівні саме зараз працюють в ІТ-сфері, адже безцінним є практичний досвід. Утім, це питання вже потребує більш глобального обговорення крізь призму системи освіти загалом.

Євгеній, випускник

Факультет математики та інформатики

Факультетскладається з шести кафедр: кафедра алгебри та інформатики, кафедра диференціальних рівнянь, кафедра математичного аналізу, кафедра математичного моделювання, кафедра системного аналізу і страхової та фінансової математики, кафедра прикладної математики та інформаційних технологій.

Презентаційний ролик факультету

Тут готують фахівців за спеціальностями «Комп’ютерні науки», «Прикладна математика», «Системний аналіз», «Статистика», «Середня освіта (математика)», «Середня освіта (інформатика)».

Студенти вивчають такі предмети: методи штучного інтелекту, аналіз даних, математичний аналіз, методи обчислень, розробка веб-додатків, операційні системи, програмування й підтримка веб-застосувань тощо. Є й такі предмети, як охорона праці в IT-галузі — саме до таких дисциплін у студентів найбільше питань щодо доцільності.

На факультеті є шість комп’ютерних класів, три лабораторії. Студенти здебільшого позитивно оцінюють ресурси класів і лабораторій та добре відгукуються про бібліотеку.

Факультет співпрацює з IT-компаніями Чернівців: SoftServe, MobiDev, Yukon Sofware, AMC Brіdge та іншими. Тут студенти мають змогу проходити практику, а затим — і працевлаштовуватися. Практика є обов’язковою, і студент може сам вибрати, чим він хоче займатися, як каже один із викладачів університету. Він же називає одну з головних, на його думку, проблем: розумні, здібні студенти спрямовують свої зусилля на те, щоб працювати за кордоном.

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

Випускники працюють програмістами, аналітиками, можуть бути вчителями математики та інформатики.

Відгуки студентів

Навчальній програмі можна поставити 6 із 10 балів. З усіх прослуханих курсів використовую не більше 10. Програма відірвана від реальності. Найбільше вибивали з колії предмети, на яких було потрібно розробляти, наприклад навчальну програму, яка потім буде нікому не потрібною, — це були завдання, які не матимуть реалізації в майбутньому, просто папірчики. Із позитивного — математика розвиває логічне мислення!

Корисними є такі предмети: бази даних, алгоритми та структури даних, алгебра та геометрія, матстатистика, веб-розробка (HTML, JS, CSS, якісь фреймфорки), soft skills, C#, Java.

Деякі предмети мали різну назву, проте на них викладали майже ідентичний матеріал. Ох скільки було зайвих предметів: фізкультура, ОБЖ, екологія, методика викладання... Починаючи від створення папочок на комп’ютері, роботи в програмі Microsoft Word і закінчуючи 1С.

Викладачі до своєї професії ставляться з повагою, до нас — більшість добре, проте буває, що кидають фрази: «Ну та-а-ак, ви ж краще за нас заробляєте» або «Це ви зараз думаєте, що все можете, а коли вам буде 30+, ви будете нікому не потрібними».

Найкраще враження залишили викладачі з 1-2курсів з кафедри прикладної математики та декілька викладачів, які реально працюють за спеціальністю із кафедри математичного моделювання. Вони передавали свій досвід, давали літературу, додаткові курси. Особливо надихав наш декан! А ще класно, що хлопці з іншого факультету проводили Node school — дуже захоплююче.

Університет допомагає знайти класну роботу. Більшість студентів працюють після практики (з моєї групи 15/17 працюють за спеціальністю).

Я можу із упевненістю сказати, що мої знання виросли, порівняно із 1 курсом, проте багато знань я отримала самостійно, на курсах, спілкуючись із одногрупниками, більшість із яких зараз — професіонали. А загалом я рада, що цей період навчання був у моєму житті, я зустріла дуже крутих людей! Було весело.

студентка магістратури, анонімно

***

Програма навчання трішки застаріла, є корисні речі, але загалом побудована не в найкращому порядку подання матеріалу. Наприклад, перший семестр викладали С після С++ і на початок третього року — Delphi.

З приводу практичного досвіду викладачів, звичайно, він є не у всіх, але велика частина проводить викладання з урахуванням їх досвіду на реальних проектах, оскільки поєднують викладання з роботою в ІТ- компаніях. Якщо студенти показують зацікавленість до навчання, то відчувається підтримка і допомога з боку викладачів.

Сильно засмучує наявність зайвих предметів: таких як педагогіка, психологія викладання, основи профбезпеки і т. д. Їх наявність вимагає суттєвих часових затрат на речі, які не приносять користі на практиці і будуть забуті через декілька тижнів.

Матеріально технічна база на достатньому рівні: велика кількість комп’ютерних аудиторій, на території корпусу організовуються різні ІТ-івенти чи відкриті курси, але немає підтримки різних хмарних сервісів для ознайомлення з ними студентів, хоча це вже більш просунутий рівень.

студент магістратури, анонімно

***

Програмі можна поставити 6 за 10-бальноюшкалою. Мій напрям «Економічна кібернетика» охоплює лише мінімальну основу для IT. Реально отримали тільки базу, багато чого я вивчив самостійно. Найбільше запам’яталися предмети «Дискретна математика» та «Дослідження операцій», оскільки задачі покривали реальні кейси, тобто мали практичну користь. Загалом багато теорії, мало практики. Чуєш від викладачів: «Купіть мою книжку, бо так вам буде легше йти за програмою». Загалом програма досить неефективна, мало що пам’ятаю з неї. Потрібно більше практики і не нудної, а нормальної. Треба якісніше заохочувати студентів до конкурсів на міжнародні програми, ввести більше годин англійської.

Викладачі давали корисні поради. Та більшість просто хотіла, аби ми вивчили їх предмет, бо так розроблена програма. Хоча на старших курсах найбільш активним пропонували роботу та знайомства з корисними людьми.

Я почав працювати з другого курсу, оскільки перевівся з Криму і треба було, окрім навчання, думати про роботу. Тому на старших курсах мене цікавило лише, як набрати мінімальний прохідний бал або не завалити іспит/залік. На магістратуру вдалося потрапити лише на платне навчання, оскільки державні місця у 2017-мускоротили, тому я вирішив зосередитися на роботі у Львові. Менш ніж за рік мені вдалося вивчити польську та отримати стипендію по програмі Банаха для магістратури в Гданській політехніці. Проте польський університет відмовився прийняти мене на напрям «Інформатика», оскільки мій диплом не «інженерський». Запропонували піти на «Аналітику господарчу». Я відмовився від стипендії та бажання продовжувати навчання, оскільки, вважаю, самоосвіта дає більше можливостей і ти не зав’язаний на таких речах, як відвідування лекцій, іспити і т. д.

Загалом в університеті все залежить конкретно від студентів. Університет пропонує багато можливостей для студентів: обміни за кордоном, стажування, але не так багато студентів врешті досягають їх. Більшість просто зациклена на оцінках та виконанні навчального плану. Можливо, просто не всі розуміють що, приклавши трохи зусиль поза стандартними лекціями та семінарами, можна відкрити для себе нові можливості та потрібні знайомства.

Щодо матеріально-технічної бази нарікань не маю. Ніби є все: література та комп’ютери. Можливо, тільки ПЗ дещо застаріле. Досить хороша бібліотека, 8 із 10.

Станіслав, випускник

***

Програма навчання продумана добре. Поверхнево покриває великий обсяг спеціальностей, тож студент в результаті може обрати, що йому до вподоби. Фокус тут не на підготовці спеціаліста по конкретній технології, а на тому, щоб дати можливість зачепитися за необхідний напрям з хорошим куруванням викладача. Тому, можу сказати, при ініціативності студента чимало знань будуть корисними на посаді програмного інженера, але це вимагає самостійної роботи. В цьому випадку підхід досить європейський. Університет допомагає набути потрібного світогляду і здобути знайомства. Це основне, як на мене.

У мене була ситуація з початком кар’єри в IT з 2-гокурсу. Викладачі цьому посприяли, цим їм дуже завдячую. За всі спеціальності підписуватися не можу, але ЕММ в цьому плані чудове. Викладачі досить молоді й часто викладають по обміну за кордоном, що позитивно впливає на студентів.

Навчальна програма в класичному університеті, такому як ЧНУ, передбачає деяку універсальність знань (предмети типу соціології, філософії) з паралельним вивченням обраної спеціальності та подальшим фокусом на неї після 2 курсу. Підхід досить дієвий, адже, незалежно від майбутньої професії, студент отримує світогляд.

Що мені найбільше сподобалося в навчальному процесі — заохочення викладачами ЕММ до розвитку особистості та цілеспрямованості в обраному напрямі. Безумовна підтримка та наставництво. Відзначу — його потрібно заслужити своїм старанням. Саме ці речі найбільше підготували мене до кар’єри.

Юрій, випускник

Резюме

Фото: Володимир Довгань

Підписуйтеся на наш Telegram-канал для Чернівців, щоб дізнаватися про цікаві події, вакансії в місті.

Богдан Рубльов — український математик та професор факультету комп’ютерних наук і кібернетики КНУ імені Тараса Шевченка. Він також є організатором математичних олімпіадв Україні й головою журі Всеукраїнської математичної олімпіади. З 2009 року Рубльов возить математичну збірну Україну на різні міжнародні олімпіади.

Нещодавно українська команда стала четвертою на Міжнародній математичній олімпіаді, найстарішій з міжнародних наукових олімпіад серед школярів. Всі шестеро її учасників вибороли медалі — чотири золотих і дві срібні. Богдан Рубльов організовував поїздку. Досі найкращим результатом України на Міжнародній математичній олімпіаді було шосте місце, здобуте в 2014, 2007 і 1997 роках. В інтерв’ю для DOU Богдан Рубльов розповів, яка різниця у підготовці математиків в Україні та за кордоном, що далі робити тим, хто найкращий у цій науці та як це — любити математику.

Богдан Рубльов і учасники першої Всеукраїнсьої олімпіади з математики для учнів 5-7класів

— Нещодавно вперше в історії українська команда посіла четверте місце на Міжнародній математичній олімпіаді (ІМО), поступившись командам США, Росії та Китаю. Раніше українська команда ніколи не піднімалась так високо. За рахунок чого вдалося посісти таке місце цього разу?

Цього року в нас була доволі добротна команда. Троє математиків, а саме Нго Нгок Тхай Шон, Роман Сарапін та Ілля Коваль, вже брали участь у попередній міжнародній олімпіаді. Аліна Гарбузова була двічі переможницею Європейської жіночої олімпіади (EGMO). Арсеній Ніколаєв та Федір Юдін теж пройшли чималий шлях при підготовці. Дуже погано насправді виступили азійські команди, наприклад, Корея, Сінгапур, Тайвань. А ми чи не вперше виступили в свою силу, майже кожен показав усе, на що здатний. Це стало наслідком комфортних умов олімпіади, адже змагання проходили в Румунії. Там майже той самий час, повітря, вода, їжа — все було геть як удома.

У нас були й більш потужні команди свого часу, але олімпіади проводилися то в Таїланді, то в ПАР. Кожного разу хтось з учасників не дотягував до свого рівня. Тому ми посідали 6-ті,8-мі,11-тімісця. Багато разів ми були найкращі в Європі. Але четверте місце у світі — це шалений успіх.

— Яка була ваша перша думка, коли стало ясно, що Україна четверта?

Коли на олімпіаді проголосували, що золото дають з 31 балу, я навіть злякався, бо виходило, що в нас 4 золоті, а такого ще жодного разу не було. Але тут треба було дещо перечекати, адже свого часу в Таїланді судді так само виставили золото з 29 балів, і в нас був такий лише 1 учасник. Але згодом виявилося, що хтось помилився, бо насправді золото було з 26 балів, тому ми отримали 2 золота. Так і тут. Коли виставили на сайт командні результати, то через шалений трафік користувачів з усього світу все підвисло. За 10 хвилин сайт відновився. Я став дивитися на 9-10 місця,шукаючи Україну, — немає. Очі поповзли вгору — і це було щось. Приблизно 50 країн з усього світу, особливо з Європи, зрозуміли, що вітати треба саме нашу команду. Для України це нечуваний результат. Усіх 50 навіть не перелічиш, але там були і англійці, і пуерториканці, іспанці, малазійці та інші.

Результати збірної України на Всесвітній шкільній олімпіаді з математики: Роман Сарапін («золото»), Нго Нгок Тхай Шон («золото»), Аліна Гарбузова («срібло»), Ілля Коваль («золото»), Федір Юдін («золото»), Арсеній Ніколаєв («срібло»)

— Як у вас свого часу складалося з математичними олімпіадами?

У шкільні роки я був переможцем республіканських та всесоюзних олімпіад. У студентський час олімпіади були не так поширені й зовсім не мали престижності. До університету у мене було три математики: шкільна — дуже проста для опанування, конкурсна — необхідна для вступу та олімпіадна — перлина, адже все найцікавіше, нестандартне, красиве та неочікуване було саме в ній.

— Красиве та нестандартне — що ви маєте на увазі?

Інколи ти довгий час не можеш наблизитись до розв’язання задачі. Коли нарешті сам приходиш до розв’язку чи отримуєш підказку, виявляється — те, що ти не міг зробити, насправді розв’язується дуже просто та очевидно. Це наче ти штовхаєш двері з усіх сил і не можеш відчинити, а згодом розумієш, що їх слід було тягнути на себе.

Коли я став студентом, то зрозумів, що наукові дослідження набагато цікавіші, ніж розв’язування задач, які хтось уже розв’язав до тебе. Над науковими проблемами можна думати місяцями, по кроку наближаючись до шуканого чи бажаного результату. Для прикладної математики це взагалі природно: спочатку просто розв’язати, а далі шукати найбільш ефективних шляхів для покращення цього розв’язку. У чистій математиці буває, що при розв’язанні певної гіпотези чи проблеми ти навіть не уявляєш, куди рухатися. Перемоги в олімпіадах допомогли мені здобути віру в свої сили для подальших досліджень.

— Чим ви зараз займаєтесь?

До олімпіад учнів готують їхні вчителі, керівники гуртків та факультативів, тренери. Я лише допомагаю організувати цей процес. Десь п’ять років тому ми зробили важливі кроки в його упорядкуванні. З 2007 року я був керівником всеукраїнських олімпіад, також мав змогу возити команду України на міжнародні олімпіади. Але перші два роки це робив мій помічник Сергій Торба. На жаль, він поїхав працювати за кордон, тепер я супроводжую команду України як голова журі всеукраїнської олімпіади.

Я хвилювався, коли мене призначили головою журі саме всеукраїнської олімпіади, а керувати на міжнародній — стало вже наслідком першої події. Тоді також подумав, мовляв, нарешті можна буде зробити все так, як ми собі уявляємо. Думаю, подальші наші результати довели, що ми на правильному шляху.

— Чому ви захопились саме математикою?

Я полюбив її з перших днів навчання після початкової школи. Ганна Білоус, моя перша вчителька математики, викладала цей предмет дуже натхненно, незважаючи на те, що у нашому класі було 43 учні.

— Як саме вона це робила?

Цікаве викладання — це коли новий, навіть надскладний матеріал, розповідають наче це не складні теореми та твердження, а просто розповіді. Я навіть не відчував, що той матеріал може бути для когось незрозумілим. Мені все життя щастило на чудових викладачів: від школи до університету. Мені читали такі видатні викладачі, як Боярчук О. К., Протасов І. В., Пєтунін Ю. І. та багато інших. Десь з 5-гокласу Ганна Білоус почала вести щотижневий факультатив. Я чекав його весь тиждень, бо там були нові цікаві нестандартні задачі.

— Наприклад?

Приміром, побудувати трикутник по трьох висотах. Я цілий тиждень придумував, як це зробити. Згодом Ганна Дмитрівна показала мені більш просте роз’язання, але мій розв’язок не перервала жодного разу, хоча він був не дуже раціональний. Думаю, це були мої перші знайомства з олімпіадними задачами.

— На ваш погляд, у чому суть математичних олімпіад?

Філософія в тому, що утворюється дружня розумна спільнота однодумців — від шкільних учителів, батьків, викладачів навчальних закладів до школярів та студентів. Такі контакти залишаються на все життя. Тому я не в захваті, коли від деяких регіонів на всеукраїнську олімпіаду привозять менше дітей, ніж потрібно. Думаю, що діти, які одного разу потрапляють у таку спільноту — чесну, дружню, справедливу, — вже матимуть заряд натхнення на чимало років наперед.

— Любити математику — вроджене чи набуте?

Для мене це вроджені здібності та прищеплена вчителями любов. В Українському фізико-математичному ліцеї КНУ ім. Т. Шевченка в мене була вчителька з математики — Любов Ващенко. Викладала вона прекрасно. До прикладу, у нас в класі на той час було два учасники всесоюзних олімпіад з математики та три — з фізики. Крім них, ще двоє учасників республіканської олімпіади з математики та п’ять з фізики.

— А що робити тим, у кого це не вроджене?

У мене немає рецепта, що робити з математичною освітою тим, кому складно дається ця наука. Ось мені, наприклад, зовсім не даються мови — як рідна, так й іноземні. Я досить багато зусиль витрачаю на вивчення англійської, але зараз можу вільно лише читати математичні англійські тексти. До вільного спілкування в побуті ще дуже і дуже далеко. Якщо людині зовсім не до снаги розуміння математики, то не треба мучити ні себе, ні математику в собі, а отримувати насолоду від того, до чого є хист та здібності.

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

— То як викладати математику цікаво, на вашу думку?

Треба просто любити і її, і тих, кого навчаєш. Знати предмет та знайти спільну мову з учнями. Зараз чимало дітей проходять до вищих навчальних закладів з поганими знаннями й балами по ЗНО з математики, але витягує їх атестат та додаткові бали. Проте вони взагалі математику не знають на рівні абітурієнта математичного закладу вищої освіти.

Тоді буває важко знайти спільний знаменник щодо того, як правильно викладати. Уявіть: п’ять людей гарно підготовлені та десять погано. Треба обрати, як викладати в такій групі: чи так, щоб тим п’ятьом було цікаво, а десять залишилися загубленими в предметі, чи навпаки знизити рівень, щоб навчити чогось тих десятьох. Проте існує велика ймовірність, що ті п’ять з хорошими знаннями будуть спати на партах.

— Ви кажете: «Треба просто любити математику». Але що означає любити математику?

Пояснити, що це означає — думаю, майже неможливо. На колір і смак товариш не всяк. Кожен це розуміє по-своєму. Коли ми проводимо математичний занзібар у вихідний день, тобто діти витрачають півдня на математику, то на нього приходить більше 150 команд по 6 учасників. Ніхто їх цього не примушує. На останню київську міську олімпіаду з математики прийшло 1350 дітей, незважаючи на зиму, мороз та знову ж вихідний день. Достатньо подивитися на цих дітей і зрозуміти, що таке любити математику.

Кожен знаходить у ній свою красу, і в цьому її ще більша привабливість — різноманітність та багатогранність. Це може бути алгебра, геометрія, комбінаторика, складні довгі доведення та дослідження, коротенькі ідеї та приклади.

— Цього року вдруге в історії української команди золото виборов дев’ятикласник. Про що це говорить?

Саме завдяки такому ранньому відбору наші учні 9-гокласу можуть позмагатися з одинадцятикласниками. Першим був Антон Тригуб, наступного року — Шон. Кожен з них за три роки виборов повний комплект нагород — бронзу, срібло та золото. А от Федір Юдін одразу почав із золотої нагороди, як свого часу Юлій Санніков. Надалі у Юлія було три золоті нагороди — сподіваємося на це й у випадку Федора. Головне, що нас обмежує — нестача коштів, бо усі ці додаткові заходи проводяться не державним коштом, а за рахунок самих учасників та спонсорських благодійних внесків. Хочеться, щоб таких благодійників стало набагато більше.

— Яка сума потрібна для організації хорошої олімпіади?

На усі наші заходи за минулорічними цінами треба приблизно 3 млн грн, щоб провести їх належним чином. Щоб дітям ще й надати певні призи та інші відзнаки, тоді, напевно, до цієї суми доречно дописати нулик. З цієї суми держава забезпечує проведення державних заходів. Усі інші — додаткові олімпіади, турніри, збори — проводяться на самофінансуванні.

— Чим відрізняється підготовка математиків в Україні і за кордоном?

У кожній країні підготовка до олімпіад має свої особливості: фінансові, людські, організаційні. Наша вада в тому, що всі міжнародники виїжджають за кордон після 4 курсу університету чи раніше. Тому мають змогу передавати свій досвід за дуже обмежений час. Є країни, де цим професійно займаються спеціалісти, які накопичують неабиякий досвід у такій підготовці, а тому вона проходить більш організовано, на відміну від нашої країни. Це стосується провідних країн. Звичайно, є багато країн, де олімпіадами переймаються лише окремі фахівці без жодної державної підтримки. Зазвичай, це країни, що пасуть задніх. Навіть у Європі таких більшість.

— Часто результат залежить від психологічного стану учасника в конкретний момент. Математикам притаманне здебільшого раціональне мислення. Чому тоді вони часто хвилюються на олімпіадах, адже це впливає на їхній результат?

Наталка Хотяїнцева, золотий та срібний призер міжнародних олімпіад, двічі золотий переможець EGMO, зараз студентка МІТ, колись мені сказала: «Я на першому своєму EGMO так хвилювалася, що в перший день нічого не могла розв’язувати». Але наступного дня вона вже увійшла в ритм та стала переможницею в особистій та командній першості. Звідси природній висновок: хвилювання можна здолати не лише підготовкою в домашніх затишних умовах, а й на виїздах на різні престижні математичні заходи. Так ми вже багато років тренуємо найкращих на румунському турнірі, деякі з наших дівчат беруть участь в EGMO з дня започаткування конкурсу. Нам і далі треба шукати інші змагання, в яких можна тренувати наших учасників. Уже двічі поспіль наші юні математики беруть участь у Білоруський республіканській олімпіаді. А зараз, на початку вересня, команда України змагається на Середньоєвропейській олімпіаді. Думаю, ми рухаємося у правильному напрямку.

— Але чому люди з раціональним мислення хвилюються, як думаєте?

Олімпіади — це математичний спорт. Вони хвилюються передусім тому, що дуже потужно підготовлені, а миттєво розв’язати задачу не виходить. Тут і починається колотнеча, мовляв, як таке можливо, я ж готовий... Раціональне мислення не означає, що ці люди без емоцій та живуть наче роботи — вони людяні, добрі, працьовиті, співчутливі.

— Яка олімпіада для вас запам’ятається на все життя?

Найяскравіша олімпіада була в Колумбії. Тиждень чи навіть трохи більше на самому березі Карибського моря в п’ятизірковому готелі в липні. Там взагалі організатори не переймалися дозвіллям, мовляв, ось вам море, отримуйте задоволення. Ми так і робили — кожну вільну хвилину від роботи ми насолоджувалися цим чарівним морем. А загалом рівень організації олімпіади залежить від коштів, які країна-організатор в них вкладає. Якщо це готелі в Бразилії, Таїланді, Нідерландах, то перебування там стає святом. Якщо це кампуси університетів ПАР, Гонконгу, то життя там, наче в гуртожитку.

Коли в нас є можливість приїхати трохи раніше для акліматизації дітей чи від’їхати хоч на півдня пізніше, то заступник лідера може організувати певне дозвілля, як це, наприклад, було в ПАР. Діти потрапили на сафарі, відвідали точку, де Індійський та Атлантичний океани зливаються, відвідали Маракану. У Ріо-де-Жанейро мандрували до статуї Христа. У Німеччині ми мали гарний, хоч і невеличкий, відпочинок на Північному морі.

— Як цей досвід організації олімпіад впливає власне на вас?

Організація олімпіад наразі забирає весь мій вільний час. Ні на що інше не лишається ні сил, ні можливості. Але сили не безмежні, треба шукати собі більше помічників. Але як можна їх знайти, якщо ця робота ніким та нічим не заохочується та не підтримується? Напевно, марно сподіватися на велику державну підтримку математичних заходів, бо країна здебільшого бідує в багатьох галузях. Дуже шкода, що в нас немає потужного приватного благодійника, який би вирішив усі наші доволі невеликі фінансові проблеми. Мрію, щоб кожен предмет, наприклад, фізику, хімію, біологію взяв під своє крило якийсь благодійник чи благодійні організації. Тоді розвиток та покращення результатів, принаймні на міжнародній арені, стануть колосальними.

Хочеться, щоб усі вчителі, не лише в математиці, які підготували призера міжнародної олімпіади, отримали б звання заслуженного вчителя. Хочеться, щоб країна знала своїх, щоб вони були постійно на виду, щоб з ними розмовляли, переймали досвід, організовували зустрічі. Тоді наші успіхи зростуть суттєво, а 4-темісце стане нормою. Можливо, і студенти тоді б залишалися в Україні. А поки такому життю немає через що заздрити.

— Багато переможців і учасників олімпіад їдуть навчатися за кордон?

Одразу їдуть закордон одиниці. Таке було десь двічі. Усі інші зазвичай їдуть після бакалаврату чи PhD. Наші реалії такі, що поки що тут математики себе прогодувати не можуть. Ті, хто обирають прикладні дослідження, роботу в ІТ — можуть цілком спокійно забезпечити гарне життя в Україні. Але більшість хочуть спробувати свої сили спочатку в науці. Сподіваюся, що скоро наші випускники почнуть повертатися. Мій учень, який зараз працює в Google в Лос-Анджелесі, казав, що протягом 3-4років після переїзду в США жив гірше, ніж в Україні. Сподіваюся, що скоро будуть і в Україні комфортні умови для життя наших найкращих випускників.

— Діти виграють міжнародні олімпіади, привозять медалі. Але що далі? Спробуйте навести оптимістичний та песимістичний сценарії.

Оптимістичний: вивчився на бакалавра в Україні, поїхав на 3-4роки в західний університет і став доктором, далі повернувся для подальших наукових досліджень в Україну, не втрачаючи зв’язків із заходом, постійно мандрує на наради та конференції по всьому світу.

Песимістичний: вивчився в Україні, поїхав на захід — там не склалося, влаштувався там прибиральником чи таксистом.

— Мій вчитель алгебри у школі постійно казав, що математики — ліниві...

Людство тому й винайшло усі свої прилади та знаряддя, які ми маємо сьогодні. Було ліньки це все робити руками чи іншими складними способами. Лінь — це стимул винайти щось, що полегшує життя. Хоча все повинно мати свої межі.

— Чим ви пишаєтесь?

Пишаюся чіткою структурою змагань, які ми проводимо по Україні. Це вимагає чимало зусиль. Так само приємно бачити книжки, які виходять кожного року. Пишаюся молоддю, яка долучається до наших заходів, а також учасниками. Вони ростуть чесними, неупередженими та патріотичними громадянами України. Нашим журі пишаюся, бо в ньому поєднується мудрість і досвід з юністю та розум молоді.

— А за чим шкодуєте?

Шкодую, що запізно долучився до олімпіад як організатор. А також за те, що свого часу нас на півтора роки прибрали з журі. Можливо, когось ненавмисно образив і своєчасно не вибачився. Усе бувало. За цим також шкодую. Можливо, когось цим відштовхнув від наших заходів. Дуже був би радий, якби усі повернулися до нашої команди. Але це життя і це складна задача, адже в кожного свій характер, емоції, амбіції.

— Над чим ви зараз працюєте?

Як завжди, працюю над підготовкою щорічних заходів, які, на щастя, відбуваються з року в рік. Дуже хочу, щоб EGMO в Україні пройшло якнайкраще. Разом з цим я готуюся піти з олімпіад. Вони займають увесь мій час, тому треба подумати, чому приділити увагу, коли цього часу стане вдосталь. Також готуюся до зустрічі з коханою людиною.

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

Дмитрий Абрамов, Delivery Director, Deputy Head of Kiev R&D Center в DataArt

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

Станет сложно, когда окажется, что Chief — это не просто «главный». Это босс, это лидер большой команды, это глава части компании, это ответственный за бесперебойную работу всех технических инструментов: от приложений пользователей до серверов в облаке и подписок на внешние SaaS и платёжные системы. Придётся работать с людьми, и когда от CTO-новичка начинает зависеть их найм, зарплаты и увольнение, не все справляются одинаково хорошо. Более того, придётся заниматься также бюджетами, контрактами, переговорами с бизнесом, защитой перед финансовым директором или владельцем компании своих идей и людей. Как ни крути, но C-levelобязывает быть не просто инженером, но и уметь управлять компанией в команде других топов. Не для всех начинающих очевидно, что топ-босс должен уметь делать очень многое, иначе ему не выжить.

Чтобы иметь возможность стать CTO, нужно в первую очередь понять, как работает бизнес. Откуда он берёт деньги, кто его клиенты, что компания для них делает, какими инструментами для этого пользуется и какие средства вкладывает в поддержку своей инфраструктуры? Понимание базовой экономики бизнеса, умение составлять и исполнять бюджет is a must. Дальше следует озаботиться умением общаться с внутренним заказчиком и совместно работать над созданием новых сервисов. Ну и, естественно, нужно быть сильным технически, чтобы уметь планировать и создавать то, что необходимо компании для жизни.

Для получения опыта, необходимого для CTO, я советовал бы поработать в нескольких проектах, которые привели к выходу продукта на рынок. Причём делать это в роли тимлида, архитектора или PM. Желательно иметь частое общение с бизнесом, для которого делается продукт, чтобы научиться понимать его ожидания и ограничения.

Павел Никиточкин, CTO & Management 3.0 Practitioner в JetThoughts

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

Вы не научитесь быть СТО в школе. Ресурсов, которые помогут именно научиться быть CTO не так много, как хотелось бы, но все же я постараюсь указать пути вашего развития и получения навыков для того, чтобы стать опытнее в этом деле:

• банальная, но все же самая эффективная стратегия — найти наставников, которые лучше вас, и учиться у них, опирайтесь на опыт успешных СЕО/СТО;
• если в вашем окружении таковых нет, напишите холодные письма или свяжитесь с опытными СТО или техлидами посредством Twitter (или других соцсетей) и попросите у них совет/наставничество за чашечкой кофе;
• познавательной будет книга Джоела Бисли «Современный СТО»;
• из подкастов рекомендую обратить внимание на: CTO Think, Modern CTO;
• посещайте встречи и собрания CTO в различных крупных городах. Это могут быть конференции и саммиты. Можно найти в Календаре;
• черпайте знания в профильных сообществах и каналах. Как пример — популярный @rands.

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

Программистам, которые начинали с увлечения технологиями, придется перестроиться и перейти на «скучную» для них сторону. Technical Frameworks заменяются на Management Frameworks. Programming Language превратятся в Official/Corporate Language! Clean Code на Team Culture!

Как развиваться дальше? Наставлять других — помогать начинающим и тем самым давать оценку своим методам и улучшать их. Конкуренты не дадут засохнуть, надо всегда повышать производительность. Для этого надо иметь среду, позволяющую проводить постоянные эксперименты и делать выводы.

Зеник Матчишин, СТО в Altran Ukraine (Lohika)

Перед тим як почати навчання, найкраще визначити, якого типу СТО ви хочете стати. Якщо дуже все спростити, є 3 види СТО:

1. Технічний-технічний. Виключно програмує, з бізнесом не пересікається.
2. Технічний-бізнес. Трошки програмує, трошки пересікається з бізнесом.
3. Бізнес-бізнес. Не програмує, але використовує багаж знань, щоб допомагати бізнесу.

Також є суттєва різниця між СТО в сервісних компаніях та СТО в продуктах. Якщо дуже коротко, то СТО в продуктах — це повна відповідальність за технічний розвиток саме цього продукту, в той час як СТО в сервісних компаніях — це розвиток нових компетенцій та підтримка існуючих на хорошому рівні, щоб могли допомогти продуктам.

З цією ввідною можна краще дати відповідь, як вчити. Якщо коротко, то на СТО не вчаться, СТО стають. Найефективнішим методом є проходження всіх кроків кар’єрного розвитку, щоб набратись досвіду та зрозуміти, як воно працює, і дійти до рівня архітекта. Після рівня архітекта можна спеціалізуватися:

• взяти і зробити один продукт з нуля та побути з ним хоча б 3-6місяців після продакшена — шлях продуктового СТО;
• паралельно брати участь в максимальній кількості проектів у ролі людини, яка «вирішує технічні проблеми» — шлях сервісного СТО.

Паралельно треба обов’язково бути в ситуаціях, коли ви працюєте з іншими СТО для вироблення поведінкових моделей та пасивного менторства. Проекти бувають дуже різні, тому стартовою точкою є відповідь на питання «Що я маю робити, щоб все працювало, і я був не потрібний». Ця відповідь буде містити набір технологій, підходів та практик, включаючи й підходи до людей. Як тільки ви це зробили раз і несли за це відповідальність, ви вже майже там. Пропорційно до розміру компанії росте потреба в people/soft skills. Чим більше людей, тим більше ви маєте бути доступні. Типово це має бути виправлено на рівні архітекта, але бажано не зупинятись.

Головні труднощі:

1. Треба розуміти, що ви будете в команді, і найчастіше це буде компроміс: «Так, AWS — це добре, але тут хочуть Azure, тому якщо ми хочемо рухатись далі, треба змінити підхід».
2. Комунікувати технічні рішення треба буде часто нетехнічним людям, тому без високих навиків комунікації будуть постійні конфлікти.
3. Треба також нести відповідальність за чужі рішення. В галузі є багато людей, які не затримуються на роботі і бавляться в resume driven розробку, і з їхніми аргументами та рішеннями треба теж вміти працювати. СТО — це в першу чергу відповідальність, і різні відмовки не є хорошим розвитком подій.
4. Кількість дрібних задач буде дуже великою, тому якщо є труднощі з багатозадачністю, краще навіть не починати.
5. Деколи технології не вистрілюють, і треба вміти переходити на інші речі. Програмне забезпечення — це таки не будинок, і деякі речі міняти можна, але треба вміти і знати як.
6. Треба дружити з грошима, так як на рівні СТО вже треба працювати з бюджетами та фінансовим плануванням.
7. По суті, тиск для розвитку вже не зупиниться, ви можете вибрати тільки напрямок (мені це більше плюс, проте комусь і мінус).

В залежності від вашого позиціонування та типу є 3 можливих шляхи розвитку:

1. Покривати собою повний поточний технічний стек.
2. Постійно стрибати зі стеку на стек.
3. Вийти на мета-рівень та працювати в режимі make things happen.

Найоптимальніше буде стати СТО продукту і повністю пройти там всі стежки, щоб все було відоме та зрозуміле, і після того зробити декілька технологічних стрибків. Тоді в голові буде загальне розуміння базових речей, і якщо ви не перестарались, ви і далі мотивовані та матимете життєві сили, що дозволяє виходити на мета-рівень, де вам, по суті, вже буде все одно, з якою технологією працювати. Ви зможете досягати поставлені технічні цілі будь-якими доступними методами.

Тарас Мурашко, CTO в EVO

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

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

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

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

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

Самое приятное в работе, — наверное, наблюдать, как проект развивается дальше, как команды делают лучшие продукты. Ну и как счастливы клиенты, которые пользуются теми продуктами, которые создает компания.

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

Дмитро Волошин, СТО в Preply

У нас немає профільної освіти на роль СТО, тому вчитися краще на практиці. Варто розуміти, що це частково управлінська посада, оскільки СТО взаємодіє з менеджментом компанії, але не плутати її з VP-Engineering — роль якоготполягає більше в роботі з людьми. Для себе я визначаю роль СТО в тому, щоб перетворювати людський потенціал команди розробників в якісний технічний продукт. Тобто відповідати за технічний стек, мати візію його розвитку і підтримувати процеси.

Відповідно найкраще до цієї ролі готують ролі нижчого рівня — Head of Engineering, Technical Lead, Solution Architect. Наприклад, у час моєї відсутності роль СТО в компанії виконує хтось з technical leads. На практиці варто брати великі проекти з впровадження нових процесів, технологій чи просто об’ємного функціоналу і доводити їх від початку до продакшену. В ідеалі варто також розвивати базові компетенції роботи з людьми, софт-скіли.

Основні труднощі полягають в тому, що роль у різних компаніях має різний зміст. Наприклад, СТО Амазону — це візіонер, який думає над новими технологіями і продуктами. В той час як від СТО маленького українського стартапу очікується писати код, СТО в банку більше буде відповідати за безпеку тощо. Тому варто розуміти, який кар’єрний план, в якій компанії будувати. Інша стандартна проблема — це баланс бажань бізнесу і можливостей технічної команди. Варто розуміти, що робота СТО — це спектр. Не можна бездумно робити все, що хоче бізнес, тому що в якийсь момент все розвалиться під тягарем технічного боргу. З іншого боку, якщо робити лише те, що хоче технічна команда, то «космічні кораблі будуть бороздити простори всесвіту» і бізнес перестане заробляти.

З теоретичних речей для подальшого розвитку варто читати технічну літературу, розуміти, куди рухається індустрія. СТО повинен мати досить великий авторитет в команді, адже команди розробки дуже раціональні. Хороший варіант розвитку — мати ментора СТО більшої компанії, відвідувати тематичні конференції. Також зауважу, що в Києві раз в півроку проводяться СТО мітапи, і для цього є закрита группа.

Дмитрий Лапшин, СТО в Sigma Software

Если честно, слабо себе представляю, как можно специально «учиться на CTO». И даже не уверен, что существуют какие-то специализированные курсы по этой теме. Скорее, стоит говорить о том, на чём фокусироваться в процессе обучения:

— Расти не только «вглубь», но и «вширь». Кажется, широкий технический кругозор и понимание того, как работает высокотехнологичный бизнес — это обязательная программа-минимум.
— Системный подход и целостное видение решения проблем.
— Эффективная коммуникация. Даже самый опытный программист в принципе может позволить себе быть букой-затворником. Но CTO общается и с проектными командами, и с руководством компании, и с клиентами. Важно подбирать нужные слова и проявлять находчивость, иногда даже немного быть дипломатом.

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

Затем, думаю, что крайне важно избежать соблазна поддаться хайпу и начать думать в ключе: «Ага, вот теперь-то я точно сделаю всё стильно-модно-молодёжно!». Потому что в реальности нередко технологии, активно нахваливаемые в блогах и на конференциях, на самом деле имеют ограниченную область применения и/или существенные подводные камни.

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

И, наконец, если вы выросли до CTO из «сурового технаря», вам поначалу может быть сложно смотреть на проблему с точки зрения бизнеса, а иногда и маркетинга/продаж. И здесь совершенно точно приходится делать над собой усилие и, как говорили во времена былые, «учиться, учиться и ещё раз учиться».

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

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

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

Как показывает опыт, нужно быть готовым даже к радикальной смене парадигм. Когда я сам был разработчиком, «рулили» ООП, скрупулезный контроль качества и подходы к разработке с тщательным планированием наперёд. Спустя 10-15лет «на коне» функционально-реактивный подход, Agile, Lean и Minimum Viable Products с качеством «бета-версии». А ещё через 10 лет, возможно, мы вообще будем писать очень мало классического кода, а вместо этого обучать нейросети. Так или иначе, почивать на лаврах совершенно точно не придётся, постоянное обучение и вовлеченность — неотъемлемая часть профессии.

Уже несколько лет я занимаюсь развитием Центра компетенций Java в EPAM. За это время он успел поменять head-базу, стал частью внутреннего обучения, сформировал Java-экспертизу для работы над сложными проектами.

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

Как все начиналось, или Поиск идеальной формулы

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

Когда 8 лет назад я пришел в компанию, подобных структур здесь еще не было. Java Competence Centre (Java CC) начал свою работу в 2012 году и изначально базировался в Минске. Основная группа экспертов находилась там же. В какой-то момент Head Центра компетенций решил заняться другими активностями, а я предложил свою кандидатуру на эту позицию. К тому моменту я накопил немало инженерного и организационного опыта на проектах, поэтому давно хотел сделать подобную структуру, где можно было бы применить знания и поделиться ими. Прошел интервью с CTO компании, который утвердил меня на эту позицию. Так Head Java CC переместился в Харьков.

Конечно же, еще на старте в 2014 году мы анализировали опыт подобных структур в других компаниях. Я изучал примеры крупных компаний, например, Oracle и IBM, где центры компетенций по некоторым темам работают как выделенные структуры. Они накапливают опыт в своих направлениях и консультируют по ним клиентов.

На различных конференциях общался с ребятами из украинских компаний, спрашивая, как у них устроены центры компетенций. Максимум, о чем мне рассказывали: определенный фокус на развитие education, внутренние университеты и тренинги, построение скилл-матриц.

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

В поисках своей идеальной формулы в построении Центра используем два момента.

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

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

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

У нас Java охватывает широкий пласт. В сферу входит (и может потенциально входить) много технологий, поэтому построить Центр компетенции, который закрывает все вопросы только лишь тренингами или другими вариантами обучения, практически невозможно. Что-то из результатов своих поисков я брал за основу — это модели профессиональных сервисов Lightbend, Red Hat и Apache Ignite, которые фокусируются на накоплении практического опыта и предоставлении конкретных платных сервисов. В итоге многое приходится строить конкретно под нас.

Структура и организация

В Java CC несколько достаточно больших направлений деятельности.

Первое — организация комьюнити, которой занимается целая структура. Это комьюнити-менеджеры от HR бизнес-партнеров и комьюнити-драйверы от Java.

Второе — архитектурная команда, которая занимается пресейлом, customer engagement и SWOT-кейсами, в которых необходима серьезная инженерная поддержка. Стабильного состава у этой команды нет, но есть некий core. Это 5-6 архитекторов,с которыми мы постоянно работаем и знаем, что их уровень достаточно высокий для решения сложных кейсов.

Дальше мы привлекаем к активностям разработчиков или архитекторов с продакшна. С их помощью команда довольно легко расширяется, когда приходит RFP, RFI или случается какой-то SWOT-кейс. Тогда архитектор из core-группы возглавляет активность технически, подбирает разработчиков и архитекторов под конкретный кейс и выступает супервизором. Как руководитель центра компетенции, я возглавляю архитектурную группу. Так что большинство «красных», сложных и важных кейсов в итоге проходят через меня и эту группу. В некоторых из таких кейсов я тоже участвую как ведущий архитектор.

Третье направление — образование. Эта группа занимается созданием тренинговых и менторинг-программ. В ней есть люди, которые отвечают за определенные тренинговые направления по Java. А сама группа наиболее распределена и наименее управляема со стороны Java CC. Объясняется это просто: все education-программы индивидуально разрабатываются под конкретную локацию и ее потребности. И чаще всего — ресурсами этой же локации. Мы же помогаем с формированием программ тренингов, но не управляем ими и не навязываем их локациям. Здесь они ориентируются на свои потребности.

Всего в Центре компетенции примерно 30 человек, которые плотно вовлечены в его работу, более 1500 инженеров, активно участвующих в технических комьюнити, и более 5000 человек в самой компетенции.

Пожарная команда

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

В фокусе нашего внимания самые приоритетные проекты, которые стартуют в EPAM Global. Например, те, которые «на карандаше» у нашего Head of Global Delivery и Country Head-a. Эксперты Центра компетенций привлекаются и в SWOT-кейсы — проекты, которые попадают в красную зону, то есть в них присутствует риск потери денег или клиента. Поэтому часто Центр компетенций напоминает пожарную команду.

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

Реальность и продакшн

Как по мне, самое сложное — правильно совместить работу в Центре компетенций и на реальных проектах. Я с трудом представляю, что в какой-либо компании вдруг возьмут и снимут всю рабочую нагрузку с инженеров, отдав им только «красные» кейсы. Как минимум сложно сформировать и контролировать нагрузку. Особенно, если у компании множество локаций.

Например, наша группа экспертов очень распределена. Для каждого из них есть индивидуальное требование: примерно 80% времени он должен заниматься реальными проектами. В этом плюс — мы не отрываемся от живых кейсов и не вязнем в теории. Однако здесь же и минус: когда человек 80% времени проводит на продакшн-проекте, сделать какую-то эффективную структуру Центра компетенции становится очень сложно.

Поэтому на текущий момент мы пробуем выстроить Java CC как некую виртуальную группу. Людей, работающих на продакшене и обладающих определенной экспертизой, знаниями, best practices, мы привлекаем для решения проблем в похожих ситуациях на других проектах.

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

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

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

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

У нас есть общий по компании Portal Contribute. Все, кто контрибьютит в Центре компетенций, получают определенный денежный бонус. Дальше есть программа для лучших контрибьюторов Центра от самого Центра. Мы мотивируем какими-то уникальными подарками, которые можно получить только от нас. Если человек с нами сотрудничает на регулярных началах, участвует в консультировании, SWOT-кейсах и серьезных engagement, пресейлах, помимо контрибьюта получает проектный бонус и потенциальный годовой бонус от Центра компетенции.

Результаты работы Java CC

Java CC берется за самые сложные задачи — и ему их доверяют все больше. Что уже само по себе большое достижение.

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

Компания большая, и не всегда легко выявить, кто конкретно готов быть экспертом. С развитием Java CC образовался определенный нетворк экспертов, которым действительно интересно заниматься Java-компетенцией.

К результатам Центра я отношу и акселераторы. Они в компании были и раньше, но ярко не выстреливали. За 2 года мы сделали 2 достаточно успешных акселератора в рамках Java CC: EPAM Delivery Platform и EPAM Microservices Accelerator. Каждый из них помогает привлечь клиентов нашими разработками, быстрее стартовать проекту, упростить разработку или решить другие конкретные задачи.

Оглядываясь в прошлое

Всех этих результатов не было бы без ошибок. В работе Центра компетенций их было не так много, но по прошествии времени легче заметить «точки роста».

Как я уже говорил выше, драма Центра компетенций в том, что приходится заниматься им между другими рабочими задачами. Первый же «красный» кейс, который попал в Java CC, — проект для крупной логистической компании. На пике в нем состояло больше 120 человек. Одновременно делать архитектуру на такую команду и эффективно работать в Центре компетенций — практически нереально.

Если отмотать время на пару лет назад, я бы более грамотно распределил время в плане совмещения продакшн-проектов и Java CC — больше бы отдавал последнему. И более активно привлекал бы к Центру талантливых специалистов компании.

Заглядывая в будущее

Среди прочего наша команда разрабатывает continuous learning. Здесь нам предстоит отвечать на массу вопросов. Как определить, чему нужно обучать специалистов? Что будет востребовано с точки зрения скиллов разработчиков у заказчика? Как заранее подготовить тренинговые программы? Как это совместить с реальным бизнесом на стороне клиента?

Для этого у Центра компетенций есть такой инструмент как скилл-матрица. Туда мы прописываем навыки, которыми, по нашему мнению, должен обладать разработчик согласно своему уровню. Она необязательна и не является мерилом профессионализма разработчика — носит, скорее, рекомендательный характер. Но человек, развиваясь от Junior до Chief, может ориентироваться, что ему в конкретный момент корректнее и эффективнее прокачивать.

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

Каждая из инициатив Java CC — довольно большая. За каждую из них отвечает конкретный человек. Моя задача — подготовить список таких инициатив.

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

Планы и рекомендации

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

1. Разработка рекомендаций и методологий. Хороший пример — микросервисный акселератор. Он появился так. В какой-то момент мы поняли, что в ближайшие 3-5лет тема микросервисов будет очень востребована. Разработали референсную архитектуру для крупных клиентов, изучили несколько разных фреймворков в этой области, прикинули, какие из них будут наиболее востребованы в крупных предприятиях, с которыми мы работаем. Спустя полгода-год после этого спрос на микросервисные проекты вырос до такой степени, что мы не успевали ответить множеству некрупных проектов. Зато в некоторых ситуациях могли привлекать очень крупные. Кроме презентаций мы приносили на переговоры демопроекты и показывали, как это на самом деле работает. Это был наш джокер.
2. Проактивное обучение технологиям, которые будут востребованы в обозримом будущем. У нас был интересный кейс, когда на базе R&D-лаборатории мы специально обучили группу студентов микросервисному стеку. Потом эта группа студентов попала на один из реальных проектов. И вышло так, что они изначально были подготовлены лучше и работали продуктивнее, чем зрелые специалисты, которые пришли неподготовленными по этому конкретному стеку.

В этом году мы делаем фокус на PaaS-решения — предполагаем, что рано или поздно они будут востребованы заказчиками. В частности, решение на Docker, Kubernetes, Open Shift и других подобных технологиях. После изучения стараемся эту экспертизу постепенно внедрять в реальных локациях. Кто знает, возможно, в следующем «красном» проекте в Java CC потребуются именно эти скиллы. И мы будем готовы.

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

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

Привет, меня зовут Иван Некипелов, и я Python Tech Lead в компании по автоматизации кафе, ресторанов и магазинов Poster. Хочу рассказать, как и почему мы решили использовать Raspberry Pi на постоянной основе в коммерческих целях для нашего highload продукта. Наш опыт будет полезен всем тем, кто думает применить Raspberry в узком месте проекта и хочет понять, какие подводные камни могут встретиться на пути.

Что мы делаем

Poster — это SaaS-система автоматизации ресторанного и розничного бизнеса. То, что мы делаем, называют Point of Sale или «касса». Для того, чтобы после работы вы съели с друзьями по бургеру в гастро-пабе, шефу нужно проработать меню и создать технологические карты, кладовщику — узнать, какие продукты заканчиваются на складе, и вовремя купить их, официанту — провести заказ на кассе, а повару — приготовить блюдо. Все эти процессы работают быстро и слаженно благодаря системе автоматизации.

Наш продукт разделен на две части — терминал и админка. Терминал запускается на планшетах iPad и Android или Windows-устройствах в противовес дорогим стационарным системам автоматизации, которые используют громоздкие Windows-моноблоки. Сейчас системой учета Poster пользуются 6800 активных заведений в 65 странах мира.

Как подключить неподключаемое

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

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

1. Отказ от iPad :)

Самым простым решением было отказаться от iPad и использовать только Android- или Windows-устройства с возможностью проводного подключения, но это противоречило нашей главной ценности — удобству, надежности и современности решения, поэтому этот вариант отсеяли сразу.

2. Использование еще одного планшета или компьютера на Windows

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

В итоге решили остановиться на Raspberry Pi и расскажу почему.

Что такое «малина»

Raspberry Pi — это микрокомпьютер размером чуть больше кредитной карты. В нем есть разъемы USB и Ethernet. Работает на базе операционной системы Raspbian. Raspbian — это форк Debian для Raspberry Pi.

Изначально Raspberry был создан для образовательных целей и DIY проектов. Сразу после выпуска этого одноплатника появились тысячи гиков, которые стали собирать на его основе умные дома, автоматические страйкбольные винтовки для охраны дома и гроверы для марихуаны. Также «малину» стали закупать школы в странах третьего мира для обучения детей информатике. На 2017 год было продано более 12,5 миллионов экземпляров этого микрокомпьютера. Многие зарубежные компании начали использовать Raspberry в своих коммерческих проектах. Например, на нем сделаны медиаплеер Slice и GIF-камера OTTO. Но в основном эти проекты были стартапами и продавались с помощью краудфандинговых кампаний на Kickstarter.

OTTO камера на основе Raspberry Pi для съёмки GIF-изображений

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

Как создавали Poster Box

Программно-аппаратный комплекс на основе Raspberry мы назвали Poster Box. Он подключается к локальной сети заведения, а к нему подключаются фискальные или термальные принтеры.

Выбор сервера

Web-сервис решили поднять на Tornado, чтобы работать параллельно с несколькими фискальными регистраторами и принтерами с помощью одного Raspberry.

Драйверы

После выбора сервера встал вопрос поддержки ресторанного оборудования. Так как парк оборудования достаточно большой, необходимо было найти наиболее универсальное решении. Такой «серебряной пулей» для нас стал драйвер компании «АртСофт», который называется «Универсальный драйвер РРО». Он предоставляет возможность с помощью единого интерфейса взаимодействовать со всеми возможными фискальными регистраторами в Украине. Использование уже готовых компонентов помогло максимально быстро запустить продукт. Позже мы самостоятельно написали драйверы для некоторых других моделей, чтобы снизить себестоимость устройства.

Когда масштабировали Poster Box на другие страны, иногда приходилось самостоятельно писать драйверы для фискальных регистраторов. Например, на момент нашего старта в России у Атола, самого крупного производителя фискальных регистраторов, совсем не было библиотек и драйверов, приспособленных для работы на Raspberry, поэтому пришлось самостоятельно закрывать этот вопрос.

Интеграции

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

ТОП-3 проблем, которые пришлось решить

Проблемы с Poster Box начались после продажи десятого устройства. Я выделил три ключевые проблемы, с которыми столкнулись и которые пришлось оперативно решать:

1. «Постановка на поток»

Самой первой проблемой стала организация потокового производства устройств. По сути, нужно было собрать Raspberry в корпус, установить на него операционную систему, наш софт и проверить его работоспособность. Операция сборки и записи занимала около 40 минут и требовала внимания разработчика. Учитывая крайнюю неэффективность такой работы, мы решили автоматизировать процесс. Для этого написали тулзовину под названием pbox-farm — по сути, cli-утилиту,которая запускалась тоже на Raspberry.

После запуска она находила все USB massStorage устройства и записывала на них образ Raspbian, потом делала chroot в каждую записанную флешку и устанавливала софт. Это позволило значительно ускорить запись — до 40 минут на 4 устройства с минимальным участием разработчика.

2. Дистрибьюция и обновления

Следующей проблемой стала дистрибьюция новых сервисов на устройства и поддержание их в актуальном состоянии. Ни одно из готовых средств доставки кода на клиента не закрывало наши потребности, поэтому пришлось писать свой «велосипед». Для этого мы использовали пакетный менеджер opkg, который изначально разрабатывался для openWRT и был очень легковесным.

Затем мы разработали многоуровневую систему репозиториев для плавного деплоя и написали сервис, который просто один раз за определенный период дергал opkg и обновлял пакеты на Poster Box. Сейчас конфиг на каждом устройстве выглядит примерно так:

src/gz custom http://updateserver.com/ua/ua999
src/gz stable_ua http://updateserver.com/stable/ua
src/gz testing_ua http://updateserver.com/testing/ua
arch any 100
arch arm 200

Существует три канала обновлений: stable, testing, custom. Stable — стабильные версии для всех. Testing — канал, на который выливаются новые релизы примерно для 10% всех клиентов. Custom — специфические пакеты, которые привязаны к конкретному устройству.

3. Настройка удаленного доступа

Поскольку каждый Poster Box физически находится у клиента, прямого доступа к нему у нас не было. Когда к нам стали обращаться клиенты по поводу тех или иных проблем с нашим софтом на «малине», мы толком ничего не могли сделать. Стало ясно, что без удаленного доступа к каждому девайсу работать будет сложно и неэффективно.

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

Поэтому мы решили создать чат-бота на основе XMPP-протокола. На каждом Poster Box установлен сервис-бот, который при включении девайса подключается к XMPP-серверу и становится онлайн для всех его контактов. Если приходит сообщение-команда от контакта из белого списка, он выполняет определенный скрипт на устройстве. Такая схема оказалась очень удобной.

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

И еще одна

Есть еще одна проблема, о которой хочется сказать отдельно, — требовательность Raspberry к питанию. Питающее «малину» напряжение должно быть 5 вольт и минимум 2 ампера, но не больше 3. К тому же Raspberry очень боится перепадов напряжения, поскольку в нем нет конденсаторов для безопасного выключения с синхронизацией файловой системы. Поэтому на некоторых точках от перепадов напряжения повреждались загрузочные разделы флешек. Единственный вариант, не меняя платформу, убрать эту проблему — это припаивать к каждому Raspberry конденсаторный шилд, что сильно бы увеличило стоимость и привело к проблеме с дистрибьюцией.

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

Что в итоге

Poster Box — это полезное решение, которое мы смогли быстро запустить благодаря нестандартному, но удачному выбору Raspberry PI. Теперь владельцы заведений могут управлять своим бизнесом с помощью планшетов из любой точки мира в режиме реального времени и не тратить время и деньги на громоздкие стационарные решения.

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

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

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

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

Что же такое Flexbox

С уверенностью можно сказать, что Flexbox призван помочь нам с некоторыми особо неприятными моментами CSS (например, вертикальное выравнивание). И в решении данного вопроса ему нет равных. Но порой разобраться в принципах работы этой технологии бывает сложно. Особенно если у вас не хватает опыта или вы совсем новичок.

Главная задача Flexbox — сделать слои гибкими, а работу с ними максимально простой. Идея гибкой (flex) разметки — позволить контейнеру менять ширину/высоту (и порядок) своих элементов, чтобы наилучшим образом заполнить доступное пространство (в основном для размещения на всех типах и размерах экранов). Flexbox контейнер расширяет элементы, чтобы заполнить свободное пространство, или сжимает их, чтобы избежать переполнения.

Так как Flexbox — это полноценный модуль, а не отдельное свойство, он содержит целый набор свойств.

Некоторые элементы предназначены для работы с родительским контейнером «flex-контейнер». А другие касаются дочерних элементов (известных, как «flex-элементы»).

Если обычная система компоновки основана на блочных и строковых направлениях, то Flexbox основан на «flex-flow направлениях».

Чтобы начать работать с Flexbox, нам нужно сделать наш контейнер flex-контейнером. Делается это так:

<div class="flex-container"><div class="box box-1">Item 1</div><div class="box box-2">Item 2</div> <div class="box box-3">Item 3</div> <div class="box box-4">Item 4</div> </div>

.flex-container {
    display: flex;
}

Как можно заметить, элементы выстроились в ряд.

Flex-direction

У flex-контейнера есть две оси: главная ось и перпендикулярная ей.

По умолчанию все предметы располагаются вдоль главной оси: слева направо. Из-за этого блоки выровнялись в линию, когда мы применили свойство display:flex;

Свойство flex-directionпозволяет вращать главную ось.

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

Также существует еще несколько параметров для flex-direction: row-reverse и column-reverse.

.flex-container {
  display: flex;
  flex-direction: column-reverse;
}

.flex-container {
  display: flex;
  flex-direction: row-reverse;
}

Justify-сontent

Свойство justify-content:может принимать пять разных значений:

flex-start;
flex-end;
center;
space-between;
space-around.

Работу всех этих свойств можно посмотреть, вписав в пример ниже:

Если justify-contentработает с главной осью, то align-itemsработает с осью, перпендикулярной главной оси.

Свойство также может принимать пять разных значений:

flex-start;
flex-end;
center;
stretch;
baseline;

Как показано в примере, свойства justify-contentи align-itemsдовольно легко объединять:

Align-self

Align-selfпозволяет выравнивать элементы по отдельности.

.flex-container {
  display: flex;
  min-height:100px;
  flex-direction: row;
  justify-content: center;
  align-items: flex-start;
}

.box-1 {
  width:50px;  
}
.box-2 {
  width:70px;
}
.box-3 {
  align-self:center;
  width:90px;
}
.box-4 {
  align-self:flex-end;
}

Flex-grow

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

Если у всех элементов свойство flex-growустановлено в 1, то свободное пространство внутри контейнера будет равномерно распределено между всеми элементами. Если у одного из элементов значение установлено в 2, то элемент будет занимать в два раза больше пространства, чем остальные (по крайней мере попытается).

<div class="flex-container"><div class="box box-1">Item 1</div><div class="box box-2">Item 2</div> <div class="box box-3">Item 3</div> <div class="box box-4">Item 4</div> </div>



.box-1 {
  flex-grow: 1;
}
.box-2 {
  flex-grow: 2;
}
.box-3 {
  flex-grow: 3;
}
.box-4 {
  flex-grow: 4;
}

Указывать отрицательные числа нельзя.

Flex-shrink

Это свойство определяет возможность элемента уменьшаться в размере, при необходимости.

.item {
  flex-shrink: <number>; /* по умолчанию 1 */
}

Указывать отрицательные числа нельзя.

Flex

Это сокращение для flex-grow, flex-shrinkи flex-basis. Второй и третий параметры (flex-shrink и flex-basis) не обязательны. Значение по умолчанию установлено в 0 1 auto.

Рекомендуется использовать это сокращённое свойство, а не указывать значения индивидуально.

Поддержка браузерами

Chrome - 21+
Safari - 3.1+
Firefox - 22+
Opera - 12.1+
IE - 11
Edge
Android - 2.1+
iOS - 3.2+

Заключение

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

Эта технология больше подходит для компонентов приложения и небольших макетов, хотя и весьма сложных, тогда как спецификация CSS Grid Layoutпредназначена для более масштабных макетов.

Плюсы

1. Не нужны сетки различных HTML-фреймворков
2. Управление блоками абсолютно наглядно и гибко.
3. Полностью решена проблема вертикального позиционирования.
4. Полная поддержка всеми современными браузерами, кроме Internet Explorer.

Минусы

1. Невозможность использования под Internet Explorer 9.
2. Internet Explorer 10+ не понимают некоторые условия Flexbox.

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

С самого начала своего существования GPU был узкоспециализированным устройством, предназначенным только для преобразования и рендеринга переданных ему данных. При этом поток данных был только односторонним: от CPU к GPU. Однако с момента выхода Nvidia CUDA (Compute Unified Device Architecture) в 2007 году и OpenCL (Open Computing Language) в 2009, графические процессоры стали доступны для универсальных двунаправленных вычислений (так называемых вычислений общего назначения на графических процессорах или просто GPGPU).

С моей точки зрения, как .NET разработчика, получить доступ к огромной вычислительной мощности сотен ядер GPU было бы потрясающей возможностью, поэтому я попытался выяснить, каково нынешнее положение дел GPGPU на .NET Framework.

Что такое CUDA и OpenCL и в чем разница между ними

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

Между двумя этими технологиями есть существенные различия.

Во-первых, CUDA — это проприетарная система, разработанная и поддерживаемая только Nvidia, в то время как OpenCL — это скорее открытый стандарт, а не законченное решение или конкретная реализация. Поэтому CUDA доступен только на устройствах Nvidia, в то время как OpenCL может поддерживать любой производитель (кстати, чипы Nvidia также его поддерживают).

Во-вторых, CUDA — это технология, работающая только с графическим процессором (по крайней мере, в настоящее время), а интерфейс OpenCL может быть реализован различными устройствами (CPU, GPU, FPGA, ALU и т. д.).

Эти различия приводят к очевидным последствиям:

• Производительность CUDA немного выше, чем OpenCL на чипах Nvidia.
• Благодаря единому производителю (Nvidia), можно однозначно рассчитывать на соответствие документации и реализации CUDA, что не гарантируется для OpenCL.
• OpenCL — это единственный вариант, если вам нужно работать с чем-либо, кроме чипов Nvidia.

Как это работает

Последовательность обработки данных с CUDA

Давайте опишем процесс работы с GPGPU при помощи схемы, представленной на рисунке:

1. Формируем в ОЗУ данные, которые необходимо обработать.
2. Копируем эти данные в видеопамять.
3. Даём GPU задание обработать данные.
4. GPU выполняет задачу параллельно на каждом ядре.
5. Копируем результат обратно в ОЗУ.

Нужно отметить, что вычисления общего назначения на GPU имеют ряд ограничений:

• Они не могут выполнять любые операции ввода-вывода.
• Они не могут напрямую ссылаться на данные в памяти компьютера.

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

Мне кажется, это сильно препятствует распространению GPGPU.

GPGPU на платформе .NET

На платформе .NET пока что отсутствует встроенная поддержка GPGPU, поэтому нам придется полагаться на сторонние решения. При этом имеется не так уж много вариантов, из которых можно выбирать, поэтому давайте кратко рассмотрим доступные альтернативы среди активно разрабатываемых проектов. Характерно, что большинство из них основаны именно на Nvidia CUDA, а не OpenCL.

Alea GPUот QuantAlea

Alea GPU — это основанная на CUDA проприетарная библиотека с бесплатной и коммерческими версиями. Наличие даже бесплатной версии позволяет вам создавать коммерческое программное обеспечение, готовое к взаимодействию с GPU, для видеокарт потребительского уровня (серии Nvidia GeForce).

Документация очень хороша, приводятся примеры как на C#, так и на F#, а также предоставляются отличные сопровождающие графические схемы. Я бы сказал, что Alea GPU на данный момент является наиболее проработанным, задокументированным и простым в использовании решением.

Кроме того, библиотека кроссплатформенна и совместима с .NET Framework и Mono.

Hybridizerот Atimesh

Hybridizer — еще одна основанная на CUDA коммерческая библиотека, но её трудно сравнить с Alea GPU с точки зрения удобства использования. Во-первых, она бесплатная только для использования в образовательных целях (при этом все равно требует лицензию). Во-вторых, конфигурация крайне неудобна, поскольку требует создания проекта на C++, содержащего генерируемый библиотекой код, который при этом можно скомпилировать только в Visual Studio 2015.

ILGPUот Marcel Köster

ILGPU — это библиотека с открытым исходным кодом на основе CUDA, с хорошей документацией и примерами. Она не так абстрактна и проста в использовании, как Alea GPU, но тем не менее это впечатляющий и серьезный продукт, хотя он и разработан всего одним человеком. Библиотека совместима как с .NET Framework, так и с .NET Core.

Campyот Ken Domino

Campy — еще один интересный пример библиотеки с открытым исходным кодом, разработанной одним программистом. Пока что это ещё ранняя бета-версия, но она обещает максимально абстрактный API. Создана на .NET Core.

Я попробовал использовать в работе каждое из приведенных решений, но Hybridizer оказалось слишком неудобно конфигурировать, в то время как Campy просто не работал на моем оборудовании. Поэтому мы будет проводить оценивание с помощью библиотек Alea GPU и ILGPU.

Оценивание

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

Для сравнения создадим три реализации:

1. С использованием стандартной Task Parallel Library из .NET Framework.
2. С использованием Alea GPU.
3. С использованием ILGPU.

Поскольку обе библиотеки используют CUDA, нам понадобится устройство Nvidia. К счастью, у меня такое имеется.

В общих чертах, мой компьютер имеет следующие характеристики:

• CPU: Intel Core i5-4460 (4 cores no Hyper-Threading, 3.20 GHz base clock speed).
• GPU: Nvidia Geforce GTX 1050 Ti (768 CUDA Cores, 4 GB GDDR5 VRAM, 1290 MHz Clock base clock speed).
• RAM: 32 GB DDR3.
• Накопитель: Samsung SSD 850 EVO 250 GB (что не так уж важно).
• Операционная система: Windows 10 Pro.

Прежде чем продолжить, нам будет нужно установить CUDA Toolkit (нужно для ILGPU, но не для AleaGPU) с официального веб-сайта.

Обе эти библиотеки кроссплатформенны, но поскольку Alea GPU еще не адаптирована для .NET Core, мы создадим консольное приложение на базе Windows, используя последнюю версию .NET Framework, установленную на моем компьютере (а именно 4.7.1).

Нам понадобятся следующие Nuget-пакеты:

• Install-Package Alea — Version 3.0.4
• Install-Package FSharp.Core — Version 4.5.0
• Install-Package ILGPU — Version 0.3.0
• Install-Package SixLabors.ImageSharp — Version 1.0.0-beta0004

Alea GPU требует FSharp.Core, поскольку создана на его основе.

ImageSharp — это отличная кроссплатформенная библиотека обработки изображений, которая упростит нам процесс чтения и сохранения изображений.

Общий алгоритм

Наша программа будет довольно простой и состоит из следующих шагов:

1. Загрузка изображения с помощью класса ImageSharp Image.
2. Получение массива пикселей (представленного структурой Rgba32).
3. Преобразование массива пикселей (инвертирование цветов).
4. Перезагрузка их в объект Image.
5. Сохранение результата в соответствующем каталоге.

Image<Rgba32> image = Image.Load(imagePath);
Rgba32[] pixelArray = new Rgba32[image.Height * image.Width];
image.SavePixelData(pixelArray);

string imageTitle = Path.GetFileName(imagePath);

Rgba32[] transformedPixels = transform(pixelArray);

Image<Rgba32> res = Image.LoadPixelData(
   config: Configuration.Default,
   data: transformedPixels,
   width: image.Width,
   height: image.Height);

res.Save(Path.Combine(outDir, $"{imageTitle}.{tech}.bmp"));

transform — это функция следующей сигнатуры: Func<Rgba32[], Rgba32[]>.

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

Реализация TPL

Task Parallel Library является стандартным и удобным способом работы с многопоточным кодом в .NET Framework. Приведенный ниже код реализует простой фильтр изображений и вряд ли требует комментариев. Должен отметить, что я изменяю массив пикселей, переданный методу Apply, чтобы получить лучшую производительность, хотя обычно я не одобряю такие функции.

public static class TplImageFilter
{
   public static Rgba32[] Apply(Rgba32[] pixelArray, Func<Rgba32, Rgba32> filter)
   {
      Parallel.For(0, pixelArray.Length, i => pixelArray[i] = filter(pixelArray[i]));

      return pixelArray;
   }

   public static Rgba32 Invert(Rgba32 color)
   {
      return new Rgba32(
         r: (byte)~color.R,
         g: (byte)~color.G,
         b: (byte)~color.B,
         a: (byte)~color.A);
   }
}

Реализация Alea GPU

Принимая во внимание приведенную ниже реализацию фильтра в Alea GPU, следует признать, что в коде нет существенной разницы с предыдущим примером на TPL. Единственное заметное отличие — это метод Invert, где нам пришлось использовать конструктор без параметров для структуры Rgba32, таково текущее ограничение кода, выполняемого Alea GPU.

public class AleaGpuImageFilter
{
   public static Rgba32[] Apply(Rgba32[] pixelArray, Func<Rgba32, Rgba32> filter)
   {
      Gpu gpu = Gpu.Default;

      gpu.For(0, pixelArray.Length, i => pixelArray[i] = filter(pixelArray[i]));

      return pixelArray;
    }

   public static Rgba32 Invert(Rgba32 from)
   {
      /* Noticeable that Alea GPU only support parameterless constructors */
      var to = new Rgba32
      {
         A = (byte)~from.A,
         R = (byte)~from.R,
         G = (byte)~from.G,
         B = (byte)~from.B
       };

       return to;
    }
}

Реализация ILGPU

По сравнению с предыдущими примерами, ILGPU API намного менее абстрактен. Во-первых, мы должны непосредственно выбирать целевое вычислительное устройство. Во-вторых, нам нужно явно загружать функцию ядра (kernel, чистая статическая функция), которая будет выполнятся ядрами GPU для преобразования наших данных. Функция ядра очень ограничена: она не может манипулировать ссылочными типами и, естественно, не может выполнять операции ввода-вывода. В-третьих, нам нужно явно выделить память в GPU RAM и загрузить в нее наши данные до запуска процесса преобразований.

public class IlGpuFilter : IDisposable
{
   private readonly Accelerator gpu;
   private readonly Action<Index, ArrayView<Rgba32>> kernel;

   public IlGpuFilter()
   {
      this.gpu = Accelerator.Create(
         new Context(),
         Accelerator.Accelerators.First(a => a.AcceleratorType == AcceleratorType.Cuda));
      this.kernel =
         this.gpu.LoadAutoGroupedStreamKernel<Index, ArrayView<Rgba32>>(ApplyKernel);
   }

   private static void ApplyKernel(
      Index index, /* The global thread index (1D in this case) */
      ArrayView<Rgba32> pixelArray /* A view to a chunk of memory (1D in this case)*/)
   {
      pixelArray[index] = Invert(pixelArray[index]);
   }

   public Rgba32[] Apply(Rgba32[] pixelArray, Func<Rgba32, Rgba32> filter)
   {
      using (MemoryBuffer<Rgba32> buffer = this.gpu.Allocate<Rgba32>(pixelArray.Length))
      {
         buffer.CopyFrom(pixelArray, 0, Index.Zero, pixelArray.Length);

         this.kernel(buffer.Length, buffer.View);

         // Wait for the kernel to finish...
         this.gpu.Synchronize();

         return buffer.GetAsArray();
       }
   }

   public static Rgba32 Invert(Rgba32 color)
   {
      return new Rgba32(
         r: (byte)~color.R,
         g: (byte)~color.G,
         b: (byte)~color.B,
         a: (byte)~color.A);
   }

   public void Dispose()
   {
      this.gpu?.Dispose();
   }
}

Простой тест на производительность

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

var stopwatch = new Stopwatch();

foreach (string imagePath in imagePaths)
{
   /* Some Code */
   stopwatch.Start();
   Rgba32[] transformedPixels = transform(pixelArray);
   stopwatch.Stop();
   /* Some Code */
}

Console.WriteLine($"{tech}:\t\t{stopwatch.Elapsed}");

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

Для этого теста я использовал несколько фотографий в высоком разрешении, сделанных телескопом Hubble.

Пример преобразования

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

• TPL: 0.737472333 секунд;
• Alea GPU: 0.4567708 секунд;
• ILGPU: 0.410849867 секунд.

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

Что из этого следует и стоит ли игра свеч?

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

С другой стороны, это уже хорошо, поскольку мы осуществили преобразования изображений заметно быстрее, а наш CPU при этом оставался свободным для выполнения другой работы!

Заключение

Вычисления общего назначения на GPU с использованием высокоуровневых языков вроде C# — это очень здорово, и я настоятельно рекомендую поиграться с такими библиотеками, как Alea GPU или ILGPU. Я искренне верю, что завтра многие из нас будут программировать в неоднородных вычислительных средах, состоящих из различных типов процессоров, и мы должны научиться использовать их возможности.

Я надеюсь, что встроенная поддержка GPGPU для .NET появится в недалеком будущем. Было бы здорово, если бы Microsoft сделала TPL, совместимым со стандартом OpenCL. Было бы также круто, если бы Microsoft приобрела Alea GPU, как она ранее сделала с Xamarin. Учитывая доступность Nvidia Tesla GPU в Azure это звучит вполне разумно.

Весь исходный код доступен на моем GitHub.

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

У випуску: огляд алгоритму Timsort, підходи до тестування Postgres запитів в Python, заміна термінів у мові.

Новини

Microsoft announce Python integration into Power BI

Breakthrough: Python reaches Tiobe index Top 3

master/slave — нашумівший PR. Цікаво почитати думки core девів у коментах.

Python developers locking conversations and deleting comments after people mass downvoted PRs to „remove master/slave terminology from the language”

І ще обговорення на DOUна цю ж тему.

Релізи

Django 2.1 — release notes нової версії популярного веб-фреймворка.

PyBind11 v2.2.4.

Цікаві бібліотеки

Interactive-coding-challenges — 120+ підтримуваних, інтерактивних задачок з фокусом на алгоритми та структури даних, що трапляються в інтерв’ю.

Pyodide — Python scientific stack, compiled to WebAssembly.

Social Mapper — розпізнавання облич в соціальних мережах.

Python-nubia — фреймворк для побудови shell аплікацій, що використовується в деяких командах Facebook.

Soundcloud-dl — дозволяє завантажувати музику з SoundCloud.

Salmon — Pure Python mail server.

Статті та рeсурси

PEP Explorer Python 3.8 — список PEP, запропонованих на додавання до версії 3.8.

This is the fastest sorting algorithm ever — огляд алгоритму сортування Timsort, який є дефолтним алгоритмом для сортування в Python, OpenJDK та реалізований в Android JDK 1.5.

Pirates of the Caribbean Online Rewritten — сервер гри від Disney на Python.

Google Spreadsheets and Python — використання Google Docs як бекенду для вашого проекту.

Deploying a Flask application on AWS with Gitlab CI/CD | Part 1

Compared breakdown by region on Google Trends for Python, Java, JavaScript, C#

What are Hashable Objects — high level пояснення принципу роботи hashable.

Demystifying Python OOP (Part 1) — Magic methods or Special methods — огляд існуючих магічних методів у Python.

Better PostgreSQL testing with Python: announcing pytest-pgsql and pgmock

Ten Things Python Programmers Should Know

Speed up your Python using Rust — розширення Python за допомогою Rust для покращення перформансу.

Learning Python for Social Scientists

Stabbing yourself with a fork() in a multiprocessing.Pool full of sharks — підводні камені роботи з fork у Python multiprocessing.

Відео

A Beginner’s Guide to WebSockets (2018)

Python Django Tutorial: Full-Featured Web App Part 1 — Getting Started

Python with VSCode Tutorial : Getting Started

Django 2.1 // Build a portfolio website with python | Youtube Playlist

← Попередній випуск: Python дайджест #16

Привіт, мене звуть Олександр Іванов. Моя попередня історіяна ДОУ — про те, як працювати програмістом в Іспанії. Чотири місяці тому я переїхав із тамтешнього тепла у холодніший норвезький клімат. Це сталося абсолютно спонтанно. Хоч і подумував змінювати роботу, не мав конкретних намірів щодо Норвегії. Але коли представники рекрутингової агенції на LinkedIn запропонували цікавий проект, згадав, що давно хотів подивитися, як живуть норвежці і самому замешкати в цій країні.

Примітка: на момент публікації 1 євро рівне 9,6 крон (NOK).

Переїзд

Після того як зголосився, було кілька співбесід: технічних і з менеджером (усі онлайн). Перший раз зі мною сконтактували в грудні, всі інші співбесіди були після Різдва. На очне інтерв’ю поїхав у Осло в лютому 2018-го,компанія оплатила переліт і готель. Наступного ж дня прислали пропозицію.

Сама Норвегія не входить у ЄС, працювати у країні без додаткових клопотів можуть тільки громадяни ЄС (і то їм треба реєструватися в поліції, оформити резиденцію). Проте мої зусилля для переїзду теж були мінімальними. Компанія, в якій збирався працювати, має контракт із компанією, яка допомагає іноземцям із переїздами. Зі мною зв’язався їхній представник, попросив прислати список документів (резюме, відсканований паспорт, диплом про вищу освіту, фотографії). Далі мені нічого не належало робити — компанія сама подала мої документи для оформлення резиденції. Лише коли я вже приїхав у Осло в травні, мене зустрів той же представник компанії, разом пішли в поліцію, щоб зареєструватися.

Документи на резиденцію розглядалися впродовж трьох тижнів, я ж у цей час ще відпрацьовував обумовлений місяць на роботі в Іспанії. Потім ще взяв місяць канікул для себе. З компанією домовився, що розпочну 8 травня, за два місяці після того, як прийняв пропозицію. У Норвегії термін відпрацювання — три місяці, тому проблем із тим, щоб приступити до роботи в зручний для мене час, не було.

Дозвіл на проживання і роботу мені видали на три роки. Із цим дозволом можу працювати лише програмістом. Скажімо, якщо захочу продавати у магазині, доведеться ще раз подаватися вже на іншу резиденцію. Коли минає три роки, отримуєш постійний дозвіл на проживання — тоді можеш працювати у будь-якій сфері без додаткових дозволів.

Житло

Компанія зняла житло на перший місяць, у той час шукав собі постійне помешкання. Норвегія — це країна з маленькими брендами, тут все представлене в одному наборі. Є один сайт із пошуку житла на зразок нашого ОLX — Finn, що в перекладі означає «Шукай» (ним володіє компанія, у якій працюю). На сайті можна знайти все, у тому числі оголошення про роботу, купівлю, оренду житла. Шукати мені допомагав представник агенції переїздів. Разом і ходили оглядати квартири. Подивилися десь зо 5, п’яту я винайняв.

На сайті можна знайти житло, яке здає як власник, так і ріелтори. Окремі агенції нерухомості відають квартирами у цілих конкретних під’їздах. Вони також надають і сервіси: мають своїх слюсарів, сантехніків, електриків. Якщо в квартирі щось зламалося, не мушу платити за це, що досить вигідно. Знайомі розповідали, що за 10 хвилин роботи (майстер підключав пральну машинку), заплатили 1000 крон (€104). У мене ж ці послуги вже включені в оренду.

Житло вибирав з огляду на розташування: хотілося жити ближче до центру. На велосипеді до роботи їхати хвилин 10, пішки йти півгодини. Мій будинок складається з 5 поверхів — і це максимум для столиці, великих багатоповерхівок в Осло нема.

Квартира площею 42 м², нове житло, щойно відремонтоване. Коли дивилися цю квартиру, господар ще білив стіни. Чудова звукоізоляція, хороше опалення, що важливо для холодних зим. В’їхав у порожню квартиру, була зроблена лише кухня та ванна і були електроприлади (холодильник, духовка, пральна машинка, плитка). Меблі довелося купували з нуля — але фірма теж дала на ці витрати 17 тисяч крон (€1700).

У місяць плачу за оренду 12 000 крон (€1200). Для Осло це досить середня ціна. Якщо від центру їхати 40 хвилин на транспорті, можна платити 10 000 крон (€1000). Якщо жити в самому центрі або у престижних районах, то ціна сягатиме мінімум 15 тисяч крон (€1500) і вище. Ціни на житло високі, але пропорційні до зарплат, тому все доступно.

Коли підписуєш договір, маєш внести депозит — на випадок, якщо щось із майна зламається. Але теж усе зроблено круто: йдеш у банк, він відкриває депозит спеціально під квартири (кожен банк має таку опцію). Загалом цей депозит складає три місячні квартплати. Якщо додати до цього ще суму оренди за перший місяць, то спочатку виходить болюча сума.

Район, у якому мешкаю, називається Grunerløkka. У 80-хроках тут були фабрики, заводи, індустріальна зона. Останні років десять, як мені розповідали, район почали активно забудовувати барами, кафешками. Тут живуть хіпстери, це молодіжний район. Але не шумно, як і загалом в Осло — після 21:00 місто затихає.

У Норвегії чудово оцифровані різні сервіси, у тому числі оплата комунальних послуг. Отримуєш social security number, до якого можна все підв’язати: всі твої податки, банківські рахунки, листи від податкової та інших державних служб. Щомісяця на електронку приходить квитанція, яку можна оплатити через веб-сайт банку або мобільний додаток. Рахунки досить невеликі. За воду тут узагалі не платять, раз у півроку платиш 500 крон (€50) за підтримку системи водопостачання. Середній рахунок — влітку 150-200крон (€15-20), узимку може бути 500-700 (€50-70) (що теж досить нормально, бо в Іспанії улітку платив 50-60євро — не порівняти). 98% електрики в країні — відновлювальні, є вітряки і гідроелектростанції, тому послуги дешеві.

Іпотеки тут доступні всім. Якщо маєш хорошу роботу, то цілком посильний перший внесок за іпотеку — 15%, якщо тобі більше, як 34 роки, і 10% — якщо менше. Тобто держава заохочує молодь купувати власне житло. Ставки на іпотеку низькі: всього 2%. Виплати за іпотекою у більшості випадків не є більшими, ніж виплати за оренду, а то й бувають меншими. Якщо жити й працювати разом із дівчиною/дружиною, досить вигідно сплачувати іпотеку.

Ціни відрізняються залежно від району: у районі, де я живу, помешкання на 60 м²можна купити від 3 мільйонів крон (€306 тис.) і вище. Бувають ціни 6-7мільйонів крон (€612-714 тис.), якщо помешкання в нових районах у новобудовах. Якщо близько біля фіорду, ціна може складати 13 мільйонів крон (€1,3 млн). Багато людей (особливо сім’ї з дітьми) купують будинки за межами Осло (15-20хвилин потягом від столиці) — виходить недорого, близько 7 мільйонів крон (€714 тис.).

Робота

Мій робочий день складає 7,5 годин + півгодини на обід. У Іспанії було 8 + година на обід, тобто вже на цьому щотижня економиться 5 годин.

Щодо культури роботи: у Норвегії нема ієрархії, всі звертаються один до одного на ім’я і немає такого, щоб бос тобі наказав, а ти маєш це робити. До тебе є кредит довіри, вкрай рідко відбувається таке, що хтось приходить і наказує, стоїть над головою. Великий рівень автономії як на рівні команди, так і компанії загалом. При цьому усі чітко знають, хто за що відповідає і що кому належить виконати. У тій же Іспанії багато чого відкладалося, тут же все чітко і по поличках.

Мене наймали спочатку на фронтенд, але нещодавно перевели в команду Big Data. Компанія велика, по всьому світу є 8 тисяч працівників і 200 мільйонів клієнтів. Відповідно, багато даних. Наша команда займається побудовою інфраструктури, процесів обробки та аналізу даних. Мені захотілося робити щось нове, бо на фронтенді стало нудно.

Кожних два тижні ти обговорюєш все, що захочеш, зі своїм менеджером. Я поцікавився, чи можу перейти — відповіли схвально, хоч я нічого не розумів у обробці даних. У компанії погодилися навчити, оскільки люблять довгострокові інвестиції. Тим паче, коли ти вже всередині, знаєш, що і як працює, навчання не складає великих проблем. До мене приставили програміста, який працює в команді вже чотири роки, і щодня по 4-5годин виконуємо разом якісь задачі. Культура вчити одне одного теж розвинена — це мені дуже подобається.

Також цікаво, що в нашій команді немає ні QA, ні DevOps — весь цикл розробки програмного забезпечення слідує принципу «You build it, you run it».

Загальні враження про країну

Самі норвежці скаржаться на те, що в них багато бюрократії, хоча для мене не надто очевидно, де саме вони її бачать. Коли я подався на SSN, мені сказали, що це займе 4 тижні. Я приніс свій робочий контракт, інші документи. Це трохи довго, бо без цього номера не можеш відкрити рахунок у банку. Тож майже півтора місяця я жив і розраховувався євро, що неймовірно било по кишені. Але рівно через місяць у моїй поштовій скриньці був цей номер. Тут узагалі багато зав’язано на традиційній пошті: листи від банку (картка теж прийшла поштою), від лікаря. Це може здаватися старомодним, але дуже зручно, не виникає жодних проблем.

Усе дуже оцифровано: подаєш декларацію про податки в цифровій формі. Усе, що можна уявити, є в цифровій формі. Багато говорять про Естонію як зразок е-урядування — не бачу, щоб Норвегія тут у чомусь відставала.

Також вразило, наскільки Норвегія децентралізована. Коли я познайомився з норвежцем з маленького міста Molde (північ країни), що мені могло прийти в голову? Незрозумілі будинки, не дуже якісні дороги, два магазини на все місто?

Але ця маленька країна з населенням у 5 мільйонів людей розбиває цей стереотип повністю. У місті з населенням 25 тисяч людей оперує обширна мережа автобусів, аеропорт, який здійснює кілька десятків рейсів на день, 4 автомобільні салони, 4 торгові центри та футбольний стадіон.

Ще 50 років тому Норвегія була однією з найбідніших країн у Європі. Але буває таке, що одного ранку прокидаєшся і виграєш джекпот. Для Норвегії таким джекпотом стало те, що біля берегів знайшли родовище нафти. Відтоді почався стрімкий розвиток, рівень життя дуже підвищився. Нині це одна з найдорожчих країн у Європі. Відповідно, з найбільшими зарплатами.

Уряд зробив ставку на видобуток нафти, розвиток нафтогазової промисловості і в меншій мірі акцентував на розвитку інших галузей. Це особливо контрастує з сусідньою Швецією, де є такі всесвітньо відомі бренди, як ІKEA, Spotify, Electrolux, Volvo, H&M. Тобто тамтешня економіка набагато різноманітніша. Але вже років п’ять як уряд Норвегії почав утілювати різноманітні програми для стартапів, підтримувати галузь IT, зелену енергетику, електрокари, відновлювальну енергетику. В Осло я побачив більше Тesla, ніж за все своє життя.

Щоб завезти з Європи у Норвегію машину на дизелі або на пальному, маєш заплатити ще стільки ж, як коштує машина. Натомість власників Tesla звільняють від податків, їм не потрібно платити за парковку; по місту є станції для зарядки.

IT-ринок

Осло — єдине велике місто Норвегії, 600-700тисяч жителів. Тут є багато IT-компаній, як великих фірм, так і стартапів. Є багато компаній нафти і газу, які наймають програмістів за неймовірні гроші. Але коли в 2014-муціни на нафту впали, багато людей втратили роботу. Хоча це теж не катастрофа: втративши роботу, впродовж наступних 104 тижнів (52, якщо зарплата була меншою за певну суму) можна отримувати 63% від попередньої зарплати. Загалом має статися щось надзвичайне, аби тебе звільнили: норвезькі працівники добре захищені законом.

Є тусовки, кілька коворкінг-спейсів, де можна найняти кімнату для свого стартапу, сидіти і кодити. Є професійні мітапи (для дизайнерів, фронтенд тощо), але не дуже великі — приходить 30-50 людей,всі знайомі між собою. Загалом таке враження, що в Осло всі одне одного знають. Правило про 5 потисків руки тут скорочується до 2-3.

Зарплати

Якщо в Україні величезний розрив між зарплатами вчителів, лікарів і програмістів, то тут такого нема. Програміст — доволі середньо оплачувана професія у Норвегії. Читав, що найбільше отримують ті, хто працюють у сфері нафти і газу, що досить логічно. Потім ідуть пілоти літаків, затим — індустріальні інженери, ті, хто проектують міста, мости, дороги. Архітектори, лікарі отримують більше, ніж програмісти. Що більше отримуєш грошей, то більше платиш податків.

Середня зарплата програміста — 650 тисяч крон (€66 тис.). Випускник університету на першій своїй роботі може отримувати 450 тисяч крон (€46 тис.). У сфері нафти і газу ця сума може сягати мільйона крон (€102 тис.). Якщо ти фрілансер, то можна спокійно заробляти 1,5-2мільйони крон (€153-204 тис.). Зарплати величезні.

Усі думають, що в Скандинавії великі податки, насправді це не так. У тій же Німеччині вони вищі. Я зараз плачу їх 28%. Бачу, на що вони йдуть: на прекрасні школи, дитсадки, майже безплатну медицину. Коли йдеш до лікаря, платиш за візит, але щойно твої витрати на медицину перевищують 2000 крон (€204) у рік, всі решта візитів безплатні. Так само безплатні операції, пологи. Крім стоматолога: він платний. Хоча моїм робочим контрактом передбачена приватна медична страховка і великі знижки на послуги дантиста. Не стикався з цим, але, ціни, вочевидь, високі, бо самі норвежці їздять лікувати зуби до Польщі.

Є повернення податків: якщо переплатив, держава віддасть зайве. Є невеликий бонус для іноземців: оподатковуваний дохід у рік на 40 тисяч менший.

Щомісяця, крім червня і половини грудня, платиш трохи більше податків, зате в червні приходить зарплата брутто, а в грудні — на 50% більша. Начебто на відпустку і до Різдва на подарунки. Держава, як нянька, для тебе заощаджує.
Податки вираховуються автоматично, щомісяця приходить ПДФ-файл, де написано, за що скільки ти заплатив.

Інформація про те, хто скільки заплатив податків, є публічною. Наприклад, можна в реєстрі дізнатися, скільки заплатив прем’єр-міністр. Але на практиці вважається дивним переглядати цю інформацію. До того ж, якщо ти подивився декларацію свого друга, йому прийде сповіщення про те, хто саме досліджував його декларацію. Люди цього переважно цього не роблять, хіба що журналісти дивляться податки політиків і бізнесменів, щоб писати статті. Рівень довіри у суспільстві є неймовірним. Скажімо, я не зачиняю квартиру на ключ, коли йду з дому. Упевнений, що практично нічого не станеться.

Транспорт

В Осло дуже зручна транспортна система. Мені навіть незрозуміло, навіщо люди користуються тут машинами. Є автобуси, трамваї, метро. Осло розташоване у кінці фіорду. Біля міста є ще кілька островів, де теж мешкають люди. Між островами ходять човни, які теж належать до системи громадського транспорту, всім заправляє одна компанія. Один квиток на будь-який вид транспорту коштує 35 крон (€3,5), що дуже дорого, але у порівнянні з зарплатами це нормально. Одноразовий квиток видається на півтори години на одну поїздку, тобто можна комбінувати різні види транспорту. Місячний проїзний коштує 700 крон (€71) — це безліміт на всі види транспорту.

Транспорт теж поділений на зони, є 5 зон. У залежності від них ціни на квитки коливаються. Аеропорти, наприклад, розташовані у зоні, де разовий квиток коштує 100 крон (€10). Транспорт абсолютно чистий і комфортний — це, видно, залежить і від рівня життя. Узагалі не помітно бідних людей, за винятком привокзального району, де мешкає велика кількість біженців та іммігрантів із Близького Сходу.

Багато людей їздять на велосипедах, я собі теж придбав. Є система прокату велосипедів. По всьому місту встановлені станції, на кожній — від 20 до 40 велосипедів. Купуєш абонемент на сезон (триває з травня до кінця листопада, поки вулиці не вкриються памороззю) за 400 крон (€41), що неймовірно дешево. Є мобільний додаток для цього: підходиш на станцію, тиснеш кнопку «Розблокувати велосипед» і маєш 45 хвилин, щоб доїхати до наступної станції і повернути велосипед. А вже там можна взяти ще раз — і так знову. В Осло багато велосипедних доріжок, це дуже зручно. Я практично не користуюся іншим транспортом, лише на далекі відстані. На роботі, з роботи, з друзями зустрітися, в магазин поїхати — всюди виручає велосипед.

Норвегія цікава країна з точки зору географії: вкрита горами, фіордами, лісами. Залізничні дороги тут прокладати дуже важко, тож їх проклали, де змогли. Багато тунелів, є навіть завдовжки 25 кілометрів. Між норвезькими провінціями ходять автобуси, їх мережа теж розвинена: можна знайти автобус у будь-яку точку Норвегії (з кількома пересадками).

Але найбільше пересуваються літаками. Перельоти всередині країни є неймовірно дешевими: з Осло на північ і назад можна долетіти за 600 крон (€61). Якщо тобі менше ніж 26 років, отримуєш знижки 30-40%.Люди, які працюють в Осло, але живуть на півночі або в центрі країни, користуються такою фішкою, як річний абонемент на літак. Якщо купуєш його, тоді один політ коштує 100 крон (€10). Є багато людей, які щодня туди й назад літають в Осло.

Таксі тут ніхто не користується, воно неймовірно дороге. Не знаю ціни за кілометр, але доїхати з центру в аеропорт коштуватиме 1000 крон (€102), з одного району в інший — 500 крон (€51). Мало хто ним користується, бо є нічні автобуси; трамваї ходять до 1-2години ночі.

Витрати

Норвегія — неймовірно дорога країна для туристів. Якщо отримувати навіть середню норвезьку зарплату, то життя є доволі комфортним.

Ціни на їжу в середньому в півтора-два рази вищі, ніж загалом по ЄС. Тому на кордоні зі Швецією шведи побудували величезний торговий центр (з Осло до кордону їхати 45 хвилин). Тож багато норвежців, які живуть неподалік, їздять туди купувати продукти, бо виходить хороша економія на сім’ю.

Я на їжу не витрачаю дуже багато, бо в нас є сніданки та обіди в офісі. Купую здебільшого фрукти-овочі, інші продукти для вечері. У середньому на їжу йде 1500-2000крон (€150-200) у місяць. У кафе харчуватися дорого (вдвічі дорожче, ніж в Іспанії), люди переважно роблять це хіба у п’ятницю та на вихідних.

Деякі люди скаржаться на малий вибір продуктів. Насправді це вірно лише для магазинів із низькими цінами. Нещодавно я відкрив для себе одну мережу супермаркетів із доволі обширним асортиментом та цінами, вищими лише на 5-10%.У Норвегії є мобільний додаток, куди кожного понеділка завантажується каталог знижок з усіх мереж супермаркетів на поточний тиждень. Тобто можна спокійно комбінувати та бути задоволеним. На додачу, є також декілька турецьких та арабських магазинів із тамтешніми продуктами та набагато дешевшими і смачнішими овочами та фруктами.

На алкоголь ціни теж високі. Якщо в Іспанії бокал пива в кафе можна було купити за 2-3 євро,то тут від 80 крон (€8). У супермаркетах алкоголь можна купити до 4-5%міцності. На все міцніше уряд зробив монополію, є мережа державних магазинів Vinmonopolet. Цікавий графік, за яким продають алкоголь: пиво у супермаркеті можна купувати тільки до 20-їпо буднях і до 18-їв суботу. У неділю нічого купити не можна, зачинені всі магазини, супермаркети. У державних магазинах з алкоголем є великий вибір: вина, коньяки і т. д. зі всього світу. Ціни теж демократичні. Податки на алкоголь все одно високі, бо держава хоче, щоб ти менше пив. Читав дослідження: у Норвегії люди п’ють менше алкоголю, живуть довше і є здоровішими.

Люди

До переїзду багато читав про норвежців, в основному траплялися відгуки, що норвежці дуже закриті, холодні. На перший погляд це може видатися правдою: вони більш сором’язливі, особливо з незнайомцями і іноземцями. Просто потрібен час, щоб норвежець став твоїм другом, відкрився тобі. Та, зрештою, якщо ти знайшов собі друга серед норвежців, то це на все життя. Не так, як в Америці: всі до тебе усміхаються, ввічливі, привітні, small talks, але все одно відчувається певна штучність. Характер норвежця можна порівняти з термосом: холодний зовні, але теплий всередині.

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

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

Самі норвежці — неймовірно спортивна нація. Таке враження, що всі бігають, катаються на велосипедах, взимку катаються на лижах. Усі здорові, підтягнуті. Люблять відпочивати на природі: йти в гори, плавати на яхтах, каяках, їздити на велосипедах, відпочивати на озерах. Ніхто не сидить удома, особливо влітку. Оскільки у Норвегії є закон, який дозволяє розбивати намет будь-де, за виключенням міст та приватних ділянок, то умови для подорожей є фантастичними. Природа неймовірно різноманітна — 44 національних парки та й загалом більшість території є незаселеною і недоторканою людьми.

Осло розташоване між фіордом і лісом, горами. 20 хвилин потягом від міста — і ти вже біля озер, лісу. Зимою прокладають лижні треки. 20 хвилин на трамваї — і вже катаєшся на лижах.

Помітив за собою, що у Норвегії став спортивнішим. Приєднався до студентського клубу, де займаються лижним спортом. Круто, коли ведеш активний спосіб життя, коли в русі.

Їжа

Тут наявні в’єтнамські, китайські, іспанські національні кухні. Тутешня кухня дуже невибаглива: рибні страви, картопля, сендвічі. Вирощувати щось важко, оскільки гірська місцевість і на додачу суворі зими. У Норвегії багато риби, лосось дешевший за воду. Норвежці ставляться до їжі як до необхідності, а не як в Іспанії — як до релігії. Тут їдять, щоб жити, і особливо цим не заморочуються.

Погода

Це літо було неймовірно крутим: із травня по кінець серпня температура трималася на рівні 27-30 градусів,не було дощів. Місцеві кажуть, що це найтепліше літо за останні 50-70 років.Загалом температура влітку — 22-25 градусів,іноді з дощами. Також дуже довгі дні, о 4-йранку вже світло, як удень. Що північніше, то більше сонця. У північній Норвегії з травня по серпень сонце взагалі не заходить, тривають полярні дні. Взимку, навпаки, два місяці темряви. В Осло сонце встає о 9-йранку, заходить о 4-й,тобто дуже короткий день.

Зима для мешканців південних країн може видатися холодною, темною і довгою, але мені, сподіваюсь, буде комфортно. Температура взимку — мінус 10-15,для українця не дуже страшно.

Цікаві спостереження та факти

У Норвегії та Швеції курці — вимираючий вид. Натомість вони вживають snus — маленькі подушечки із тютюном, які закладаються за губу. У Норвегії відсоток людей, що користуються ними — 12%, натомість курців — 11%. Цікаво, що snus є нелегальним у ЄС, за винятком Швеції, яка його виробляє. Норвегія, як я вже згадував, у ЄС не входить. Ціни на snus у цих країнах приблизно однакові — приблизно 100 крон (€10) за упаковку.

Ніде в Європі я не зустрічав більшого соціального контрасту, ніж в Осло. Місто неформально поділене на західну та східну частини. Західна частина — охайні приватні будиночки, дорогі машини, люди у метро читають бізнес-журнали та одягнені у костюми вартістю десятки тисяч крон. Схід — переважно люди з низьким достатком, вихідці із неєвропейських країн, діти у школах — переважно діти іммігрантів. Це створює деякі проблеми, але інтеграція біженців та іммігрантів з бідних країн є доволі успішною, особливо якщо порівнювати із Швецією чи Данією.

Минулого року вартість активів норвезького «нафтового» фонду перевищила 1 трлн доларів. Керівництво держави інвестує прибутки від продажів нафти у цінні папери по всьому світу, і, як наслідок, 1,4% акцій, випущених по всьому світу, належать фонду. Цікаво, що уряд витрачає лише 4% прибутків на річний бюджет держави. Якщо розділити сумарну вартість інвестицій, то кожен житель Норвегії отримав би близько 200 тисяч доларів.

Підсумки

За час, що я в Норвегії, тут подобається все. Хтось нарікає на їжу, на одноманітні полиці в супермаркетах, але це не так суттєво. Головне те, що в тебе є можливість утілювати все, що хочеш. Можеш приєднатися до спортивного гуртка, співати в хорі, ходити в театральний гурток — все, що завгодно. Осло — багатонаціональне місто, тож якщо хтось скаржиться, що важко подружитися з норвежцями, то є люди з інших країн.

Норвегія цікавила мене через природу, бо такої більше немає ніде в світі. Усі ці гори, фіорди, водоспади, особливо на західному узбережжі. Хотілося бути ближчим до цього всього і вивчити ще одну мову. До того ж, скандинавські країни займають перші місця у щорічних рейтингах щастя, тож цікаво глибше дізнатися, у чому секрет.

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

Сказать, что украинские IT-компании рутинно проводят полноценные Discovery на новых проектах — преувеличить, если не соврать. Наш рынок завоевывает все больше доверия у иностранных заказчиков. Если ваша компания хочет и может взять фазу Discovery на себя, это преимущество выделит вас среди конкурентов.

Жизненный путь проекта начинается с фазы Discovery и переходит в фазу Delivery.

В рамках Discovery мы:

• исследуем предметную область;
• исследуем бизнес-процессы заказчика;
• узнаем ожидания заказчика от нового продукта;
• выявляем узкие места;
• формулируем решения его проблем на высоком уровне;
• расставляем приоритеты и формируем backlog;
• составляем roadmap проекта.

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

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

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

Нет единой схемы, как провести дискавери, но есть эффективные сценарии. Например, Double Diamond дизайн-процесс:

О том, как можно применить его на практике и пойдет речь.

Что произошло в реальности?

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

• Frontstage:общедоступный сайт для внешних пользователей.
• Backstage: тяжеловесное desktop-приложение + система хранения и обработки документов сотрудниками компании Х. На backstage действует множество ролей, его задача — обработать заявки пользователей, пришедших с frontstage... или как-то еще (интрига).

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

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

Шаг 1. Discovery Initiation

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

Это самый легкий этап, но лучше им не пренебрегать.

Выгоды для команды:

• Вместо надвигающейся горы задач команда получает примерный план, что делать и чего не делать.
• С другой стороны, план дисциплинирует и задает планку качества: «Мы сделаем это и это, сделаем так и так. Мы будем ориентироваться на артефакты до самого релиза проекта».

Выгоды для отношений с заказчиком:

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

Что произошло в реальности?

Решили делать короткие спринты по 4-5дней с ежедневными статус-митингами. Что касается инструментов:

• задачи хранили в Trello;
• пользовались interview cards;
• записывали интервью и сессии обучения дефолтным для мака QuickTime Player;
• для диаграмм и ментальных карт подошло бесплатное Гугл-приложение draw.io;
• прототипы — в Sketch (планировали еще Axure и inVision).

Шаг 2. Изучаем материалы удаленно

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

После этого ваши первые помощники — служба поддержки пользователей сайта. Эти люди сходу назовут вам основные проблемы пользователей: новых и опытных.

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

Что касается backstage, то самый очевидный способ ознакомиться с ним — узнать, как его осваивают новички компании. Если ими занимается «специально обученный человек» — отлично, вы его очередные падаваны. Часто в компаниях есть и обучающие материалы: инструкции, база знаний и видеоуроки.

Выгоды для команды:

• Первые впечатления и незамыленный глаз выявят то, что позднее может потеряться.
• Команда может составить первое впечатление о продукте в роли пользователей. Такие вот неофициальные юзер-тесты. Пока команда не вовлеклась в разработку, такие тесты можно считать объективными.

Выгоды для отношений с заказчиком:

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

Что произошло в реальности?

Frontstage

Поддержка сайта предоставила .csv файл с ~13 000 обращений за последние 3 года. Первая пара тысяч записей показала: типичных проблем — не больше пяти. Например, кроме банального восстановления пароля, в случае коллективной заявки пользователи не могли добавить своих коллег. Эта функциональность на сайте есть, но, очевидно, разобраться с ней нелегко.

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

Backstage

Новичку нужно в среднем 6 месяцев (!), чтобы разобраться с backstage-системой. Клиент предоставил нам их стандартное обучающее видео. Роликов было немного, и учитывая общий срок адаптации, погоды они не делают.

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

Шаг 3. Проведение удаленных интервью

Понимающий клиент с удовольствием предложит вам список кандидатур для интервью. Если нет, попросите его сами.

Даже самое отдаленное представление о функциях перечисленных людей позволит составить «interview cards». Это общие вопросы об их работе, которые так или иначе придется задать. Всегда оставляйте место на карточке для уточнений или информации, которую нельзя было предусмотреть.

Выгоды для команды:

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

Выгоды для отношений с заказчиком:

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

Что произошло в реальности?

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

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

• с директорами по развитию, которые рассказали, что делает организация, откуда приходят потоки заявок и что их ожидает на backstage;
• с архитектором существующей backstage-системы, которая писала и кастомизировала ее в течение последних 15 лет;
• с членами разных backstage-команд, подробно описавших цикл, который проходит типичная заявка;
• со службой поддержки.

На этом этапе было решено разделить наше исследование на два этапа: сначала Discovery frontstage-сайта, а затем — backstage-системы.

Шаг 4. Результаты и артефакты discovery frontstage

Повторюсь: интервью с конечными пользователями очень полезно. И полноценного Discovery без них не получится.

Допустим, вы провели интервью и начали ориентироваться в сфере бизнеса заказчика. Как структурировать полученную информацию?

1. Определите стейхолдеров продукта.
2. Выделите главные проблемы пользователей (pain points). Может быть полезно их классифицировать по происхождению.
3. Назначьте приоритет каждой проблеме.
4. Вспомним схему Double Diamond. Каждая проблема является запросом на улучшение (opportunity). Если начать вопрос с «How might we..?», то укажем и на проблему, и откроем возможность пофантазировать над ее решением. Например, «How might we help clients get real time feedback from the system?». Записываете их.
5. Проводите сессию мозгового штурма по списку «How might we...» вопросов. На этом этапе подключаем архитекторов и сочувствующих (QA/QC).
6. Создаете lo-fi прототипы, если это нужно.
7. Создаете Product Vision или Service Blueprint (или что вашей душе угодно), что позволит подробно и полно описать, как работает нынешний продукт и как будет работать будущий.
8. Составляем roadmap.

Выгоды для команды:

• Верное представление о системе и ее проблемах — проверенное народное средство, чтобы не сделать, что не надо.
• Команда логично, шаг за шагом двигается в направлении создания требований.

Выгоды для отношений с заказчиком:

• Споры о приоритетности задач будут решены уже на этом этапе.
• Заказчик обретает первое видение будущего продукта, когда еще не написана ни одна строчка кода и не нарисована ни одна страница.

Что произошло в реальности?

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

Почти все обнаруженные проблемы относились к:

• процессам (например, многие организации, обращающиеся в Х с заявками, требуют особого, нестандартного подхода; служба поддержки разрывается между разными инструментами, внедренными в течение многих лет; сложно быстро обнаружить срочную заявку);
• удобству интерфейса;
• коммуникации;
• техническим ограничениям системы;
• человеческому фактору (раскрывается #интрига: юзеры пользуются не только сайтом, но еще и присылают свои заявки с вложениями просто по email или даже по наземной почте. Сколько усилий требует обработка таких заявок для компании Х?).

Мы внесли все проблемы в Decision Matrix. Она строится на двух осях: Urgent — Not Urgent и Important — Not Important. Само собой, критическое значение имеет квадрант Urgent — Important.

Как мы описали инсайты с помощью вопроса «How might we...»: «Как помочь клиентам присылать заявки только через сайт?», «Как помочь клиентам настроить совместную работу над заявкой?»и так далее.

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

С этим мы прибыли в офис заказчика за подтверждением того, что Discovery идет в правильном направлении. На этом мы приостанавливаем его. Теперь пора взяться за backstage и создать артефакты, которые соединят обе системы.

Шаг 5. Проведение интервью на выезде

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

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

Можете вновь воспользоваться interview cards, делайте записи, получите разрешение делать аудио- и видеозапись, если такая возможность в компании предусмотрена (часто — запрещена).

Выгоды для команды:

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

Выгоды для отношений с заказчиком:

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

Что произошло в реальности?

Настало время нам перенестись в офис компании Х.

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

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

Шаг 6. Результаты и артефакты дискавери backstage

К этому моменту в ключевой команде с нашей стороны остался один дизайнер, но добавился еще один бизнес-аналитик. Теперь можно было создать один из самых важных артефактов Discovery — Service Blueprint.

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

Стейкхолдеры: все виды внешних юзеров — индивидуальных и организаций; все backstage-команды.

Мы пошли по проторенному пути и разделили обнаруженные проблемы по происхождению. В этот раз не сводили проблемы в Decision Matrix. Все они все равно попали бы в квадрант Urgent — Important.

Как мы описали инсайты с помощью вопроса «How might we...»: «Как помочь юзерам быстрее находить информацию в системе?», «Как помочь юзерам быстро и гладко переключаться между контекстами?», «Как уменьшить количество ручного переноса информации в систему?»и так далее.

Сессия мозгового штурма + ментальные карты с участием архитекторов и тестировщиков.

В это время стало ясно, что цель — объединить frontstage и backstage в одну платформу с одной точкой входа. Ментальные карты показывали, что сделать хочется много (очень много). Решили пойти по пути создания Minimum Viable Product и последующего его расширения.

Общий backlog для наглядности разбили на задачи, глобальные для платформы и специфичные для frontstage и backstage. Так в MVP попали почти все задачи для frontstage и половина глобальных.

Составили диаграмму Гантта для первых месяцев фазы Delivery. Она и стала основной roadmap’а проекта.

Вывод

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

А с точки зрения дизайна, проведение фазы Discovery — подтверждение, что основная работа дизайнера над проектом происходит еще до прототипа или первой нарисованной формы.

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

Ольга Филиппова, VP of engineering в OptioPay

Написала книги: «Learning Vue.js 2», «Vue.js 2 and Bootstrap 4 Web Development»и «Software Development From A to Z»

Работать в IT я начала еще 12 лет назад в университете Португалии: принимала участие в коммерческих проектах, с третьего курса вела практические занятия по Operating System Concepts. По окончании учебы стала работать в португальском стартапе на позиции Software Developer, с каждым днем все более вертикализируясь во Front-end разработку.

В 2014 году я переехала в Берлин, и здесь сперва работала в одной компании на позиции Lead Front-end Developer, а потом — в OptioPay как VP engineering. А еще я соучредитель и CTO украинской студии онлайн-образования EdEra.

Несколько лет назад мне написали из издательства Packt Publishing и спросили, не заинтересована ли я в написании книги о Vue.js. Этот фреймворк на тот момент как раз начал подниматься на пьедестал Front-end разработки, и Packt хотел быть одним из первых издателей книги о нем.

Почему я? Думаю, ребята из Packt хорошо прошерстили LinkedIn, а Vue в моем профиле был указан в списке фреймворков, которыми я пользовалась. Согласилась ли я сразу? Конечно, нет! Сомнений было миллион: и в глубине моих знаний самого фреймворка, и в моей способности написания технической литературы. Но я решила попробовать и абсолютно об этом не жалею.

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

Каждую главу перед отправлением издательству я давала на проверку мужу. Он перечитывал, давал фидбэк, вносил правки (у меня очень страдают артикли). Очень нервничала, когда отдала ему первую главу. Боялась, что скажет, что техническая литература не для меня, что английский хромает, что терминология непонятная и т. п. А он прочитал и абсолютно искренне заявил, что теперь ему хочется выучить Vue.js. А он Back-end разработчик! Этот отзыв дал мне сил и энергии продолжать писать с еще большим энтузиазмом.

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

Кстати, изначально книга называлась «Learning Vue.js». Писала я о первой версии фреймворка. Под конец написания книги вышла вторая версия, и издательство очень хотело быть в тренде — их можно понять, не успела выйти версия, а они уже издали о ней книгу. Это была бы первая книга о Vue.js 2! Это был отличный маркетинговый ход. Вот только мне пришлось полностью все переписывать — не только текст, но и код! Тогда я проклинала все на свете и жалела, что ввязалась в авантюру.

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

Согласно контракту, автор получает небольшую часть от прибыли — 16%. И кстати, Packt еще считается достаточно великодушным в этом плане :) На самом деле на технической литературе разбогатеть очень сложно. Мне повезло, моя книга была первым справочником о Vue.js 2 на рынке, поэтому каждый квартал я что-то получаю: можно хорошо выпить пивка за здоровье разработчиков и писателей. Но это не огромные деньги, на них не проживешь :)

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

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

Но и тут мы не остановились. Скоро выходит «Software Development From A to Z» — книга, которую мы написали вместе с мужем для издательства Apress. Эта работа — коллаб EdEra с Apress: многие ребята из команды EdEra принимали активное участие в разработке иллюстраций, дизайна, записи интервью, технической рецензии, а также по этой книге мы будем делать наш первый англоязычный онлайн-курс.

В новой книге мы рассказываем и показываем процесс разработки программного обеспечения от идеи до «выхода в люди». Книга даст возможность читателю окунуться в мир разработки и попасть в его закулисье. Читатель побывает в роли проектного и продуктового менеджера, Front-end и Back-end разработчика, тестировщика, девопса, дизайнера. Книга насыщена примерами из реальной жизни, интервью, разговорами, секретами и испробованными методами. Как по мне, книга просто бомба — а курс будет еще круче :)

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

Алексей Васильев, Software Engineer в Railsware

Написал книги «Работа с PostgreSQL. Настройка и масштабирование»и «Cooking Infrastructure by Chef»

Я работаю в IT 12 лет, сейчас занимаю позицию Software Engineer в компании Railsware.

В 2007 году я начал работать над новым проектом, онлайн-игрой, и главный инженер принял решение использовать базу данных PostgreSQL. На тот момент я был знаком только со стеком LAMP (Linux, Apache, MySQL и PHP) в веб-разработке.

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

Написание этой книги — непрекращающийся процесс. Я стараюсь обновлять текст каждые два года — после выхода новых версий PostgreSQL. Такая доработка занимает около 6-10 месяцев.Поэтому я и не берусь за книги по JS-фреймворкам: пока напишешь, тема успеет устареть.

Четкого графика написания у меня нет. Если чувствую вдохновение, стараюсь не упускать этот момент. Иногда вечером сажусь и до трех часов ночи пишу новый раздел. Если порыва нет, я не борюсь с собой: не вижу смысла себя мучить. Главное — не забросить книгу совсем и не опускать руки раньше времени.

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

Сейчас выпустил уже 5-еиздание. Книга сделана Open Source: если требуется, можно предлагать правки. Читатели мне очень помогают с редактурой и вычиткой, за что им огромное спасибо.

В 2014 году родилась еще одна книга — о системе управления конфигурациями Chef. По этой технологии документация была, но она не позволяла до конца понять, как правильно использовать продукт.

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

Написание книг дало мне понимание: что-либо стоящее требует времени и терпения. Прямо как ребенок. Книги не приносят мне деньги, да и не для этого они создавались. Для получения денег у меня есть работа :) Так что выгода — исключительно моральная, плюсик в карму. Еще иногда приглашают на конференции рассказать про PostgreSQL, хотя я себя профессионалом по этой технологии не считаю.

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

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

Сейчас пока на новую книгу планов нет. Хотя иногда проскакивает мысль написать о чем-то не техническом.

Сергей Моренец, основатель курсов IT Discovery

Написал книги «Разработка Java приложений», «Идеальный код»и «Основные ошибки в Java программировании»

Я основатель курсов IT Discovery и работаю тренером/преподавателем в этой компании. В IT я с 2000 года, это было время, когда профессия программиста мало котировалась и не очень хорошо оплачивалась. Многие даже уходили в другие сферы экономики. Я люблю свою профессию, поэтому остался и до сих пор получаю удовольствие от своей работы.

С 2012 года я часто выступал на конференциях, где рассказывал про разные интересные темы из мира Back-end разработки. Параллельно преподавал на Java курсах. И постепенно я пришел к мысли, что не могу рассказать студентам все, что хочу, — просто не хватает времени. Кроме того, студенты, которые пропускали лекции, оставались без материала.

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

Идею мне подсказали сами студенты, которые жаловались, что программирование им в принципе понятно, но они не понимают, как писать приложения с нуля. И в самом деле, такой книги, которая охватывает все аспекты, я и сам не встречал, даже в англоязычной литературе. Самое главное в книге было описать не только теорию, но и разработку приложения с нуля, чтобы читатели могли брать мой пример и адаптировать для своих задач. Я придерживался идеи в каждой главе рассматривать какую-то технологию или ее аспект. Когда набралось 100 практических глав, приложение оказалось законченным, как и книга.

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

Написание книги — творческий процесс, поэтому его нельзя ужать во временные рамки и, например, уделять 2-3часа каждый день. Иногда был такой моральный подъем, что я писал книгу несколько дней подряд. Иногда был перерыв в 2-3 месяца.

Первая часть книги «Разработка Java приложений» была самой сложной, поскольку это был первый опыт, и я не всегда понимал, куда двигаться дальше. Поэтому написание первой части заняло почти 3 года. Вторую часть я писал более уверенно, она близится к завершению, и на нее я уже потратил примерно год.

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

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

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

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

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

В ближайшей перспективе я начну писать третью часть трилогии «Разработка Java приложений». Осталось много интересных тем, которые я еще не успел раскрыть в первых двух частях, — микросервисы, распределенные вычисления, NoSQL базы данных и многое другое.

Андрій Будай, Software Developer в Amazon

Написав книгу «Дизайн-патерни — просто, як двері»

Я працюю в ІТ більше 10 років. Останні 9 місяців — в Amazon у Ванкувері. До того кілька років працював у IAEA та Bwin у Відні, ще раніше — у SoftServe у Львові.

Книгу я написав на 4-йрік кар’єри. Вона розрахована на тих, хто тільки починає займатися програмуванням професійно або ж вивчає програмування в університеті.

Як не важко здогадатися із заголовка, книга розповідає про шаблони проектування. Форма розповіді є простою і прирівнюється до простоти дверей, а не космічної станції, наприклад. Завдяки своїй нестандартній подачі матеріалу, книга допомагає легко опанувати основи дизайн патернів, а також швидко повторити їх перед інтерв’ю.

Книгу я написав із добрими намірами. Їх у мене було декілька. Я хотів упевнитися, що сам розумію усі класичні дизайн-патерни. Ресурсів для цього є досить багато, але я вирішив реалізувати ці патерни самостійно та придумати власні приклади.

Таким чином, починаючи з січня 2010 року, я писав пости у блозі, які викликали зацікавлення в читачів. Щоб цей внесок в програмування був більш чітким, в мене виникло бажання випустити невеличку безкоштовну книжку, яка стала б колекцією цих постів. Усю інформацію я намагався викласти доступною і простою українською мовою.

Над книгою працював приблизно півроку по 4-6годин на день. Ще десь 40-80годин пішло на остаточне редагування в наступні півроку. Верстанням займався самотужки. Потрібна була допомога із коригуванням: на початку було досить багато «охочих», але з них тільки одна-дві людини дійсно допомогли.

Книга доступна онлайн за вільною ліцензією Creative Commons Attribution-NonCommercial 3.0 Unported License, без ISBN.

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

У перший рік після написання отримав дуже багато листів подяки. Я й досі їх отримую, проте вже набагато рідше.

Щодо наступних книг — наразі таких планів не маю.

Евгений Завальнюк, Senior IT Engineer

Написал книги «За кулисами Youtube. Практический взгляд», «Собирайтесь дети в кучу — я вам Google отчебучу!», «Компьютерный инцидент — от теории к практике» , «Пароль защитит себя сам», «Визуальный web-дизайн для чайника»и «My Excel: tips & tricks»

Временно я не работаю, а до этого занимал пост Senior Engineer в НБУ. В общей сложности занимаюсь IT более 20-тилет. Главным образом работал в банковской сфере.

Много лет я был партнером YouTube. Имею канал «Nyukers WebTV — только позитивное видео». Лет семь назад я пересматривал видеокурсы по этой тематике других авторов и в какой-то момент обнаружил, что у меня самого есть, что поведать людям. Так появилась идея написать первую книгу — «За кулисами Youtube. Практический взгляд».

На без малого сорока страницах я описал свой многолетний опыт сотрудничества с YouTube, а также секреты этой соцсети, советы мастеров, интерактив и 3D, видеомонтаж онлайн.

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

У меня есть опыт офлайн-печати в популярных журналах «Мир ПК», «Мир ПК Украина», «Сети и телекоммуникации», «Вестник НБУ». Все это требует процесса согласования определений, проверки сигнального экземпляра, поиск места в следующем номере. Поэтому решил издавать книгу онлайн. Тем более как для печатного издания там не так много страниц. К тому же онлайн-книга намного доступнее, да и природу надо беречь :)

Верстал книгу в MS Word, там же выбирал макет. Мультимедийные объекты и защиту документа встраивал в Adobe Acrobat Х. К сожалению, не все удалось сделать так, как задумывал. К примеру, многие ссылки пришлось дублировать открытым текстом. Это было связано либо с форматом PDF, либо с экспортом документа на площадку сервиса Calameo.

Через некоторое время я плотно изучал инструменты Google, и вследствие этого родилась идея второй книги — «Собирайтесь дети в кучу — я вам Google отчебучу!». Я люблю путешествовать и перед каждым туром сижу в Google Earth и Google Maps. Проверено: чем лучше подготовиться к туру географически, тем больше получается увидеть на месте. Поэтому я захотел поделиться своим опытом работы в таких сервисах в деталях. В книге раскрыл секреты нестандартного использования картографии от Google: от теории просмотра фотографий Земли до практики их активного применения.

Следующими стали две книги по профилю информационной безопасности:

• «Компьютерный инцидент — от теории к практике» — о варианте набора инструментальных средств исследователя, применении такого набора, визуальном корреляторе данных;
• «Пароль защитит себя сам» — о графических и символьных паролях для пользователя, которые легко запомнить и невозможно узнать, а также о жестикуляции и стереопаролях.

Затем на волне моего знакомства с web-дизайном родилась книга «Визуальный web-дизайн для чайника». Это лучшие примеры из моей практики: подробный обзор web-инструментов для создания сайта, его настройки и безопасности.

Совсем недавно, занимаясь с онлайн-курсом из серии «Mastering Excel», я вдруг обнаружил, что у меня накопился интересный опыт и в этой сфере. Из постов в блоге я буквально за пару часов сформировал книгу «My Excel: tips & tricks».

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

Сейчас у меня накопился немалый материал про Powershell — скорее всего, оформлю его в новую книгу. Пока что материал постоянно дополняется.

Василий Некрасов, математик-финансист, аналитик данных

Написал «Knowledge rather than Hope: A Book for Retail Investors and Mathematical Finance Students» — книгу по финансовой математике

Сейчас я работаю как контрактор, специализируюсь на аналитике данных и риск-менеджменте. До этого работал в немецких компаниях, в том числе IDS/Allianz, и французской Total Energie. Я не айтишник, а математик-финансист и аналитик данных, свободно владеющий всеми необходимыми для этого IT-навыками.

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

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

Писать было тяжело, но не напряжно — так как писал в охотку. Весь процесс занял примерно полгода. Издавал сам через службу самопубликации CreateSpace, дочку Amazon. Для этого пришлось немного освоить верстку.

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

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

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

Дмитрий Сигов, Project manager в ZEO Alliance

Написал «Парламент. Игра на максимальных ставках» — художественную книгу в жанре сатиры и гротеска

Сейчас я работаю в ZEO Alliance, до этого работал в разных IT-компаниях в Украине, Эстонии и Черногории.

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

Вдохновением послужили книги Ильфа и Петрова, а также «Приключения бравого солдата Швейка» Гашека. Я люблю юмор, гротеск и сатиру, отсюда и жанр книги.

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

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

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

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

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