Зачем мы вкладываем столько времени и сил в стажеров

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

Но при этом на конференциях нам часто задают один и тот же вопрос: зачем вам это надо? Ответов может быть несколько, все они правильные:

• стажеры потенциально закрывают кадровые вопросы, которые по-прежнему на рынке стоят остро;

• стажеры куда более лояльны к компании — у нас, например, они работают не менее 2–3 лет;

• стажеры освобождают время мидлов и сеньоров для более сложных творческих задач;

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

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

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

Интересные кейсы использования Data Science

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

1. Сбербанк использует Data Science для анализа огромных объемов данных о клиентах.
   
   + Помогает предлагать более персонализированные продукты и услуги, а также эффективно бороться с мошенниками.

2. Благодаря анализу данных, Яндекс.Такси может прогнозировать спрос на такси в разных районах города и даже в разное время суток.
   
   + Помогает оптимизировать распределение машин и сокращать время ожидания для пассажиров.

3. Магнит — один из крупнейших ритейлеров в России — использует Data Science для управления запасами и прогнозирования спроса на товары.
   
   + Позволяет избегать дефицита и излишков на полках магазинов, а значит, экономить деньги и повышать удовлетворенность клиентов.

Больше подобных кейсов мы подробно разобрали на подкасте One Two Prod с Олегом Рудаковым, Data Science Head of Analytics крупной FMCG-компании. Ну а еще спросили у Олега о разнице работы в агентстве и продукте, о трендах в аналитике, кому вообще нужен Data Science и где больше платят.

One Two Prod — это совместный подкаст AGIMA и ONY, где мы говорим о развитии диджитал-продуктов. Первый выпуск уже доступен на YouTube и Яндекс Музыке, а второй выйдет на следующей неделе — не пропустите. В нем мы обсудим стратегии и метрики продуктов вместе с Павлом Аксеновым, ex CPO «Самолет Плюс».

Какие качественные и количественные исследования стоит проводить в рамках Discovery-процесса?

Качественные:

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

2. CJM

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

3. Юзабилити-тестирование

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

Количественные:

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

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

Подробнее о Discovery пишем тут.

Сравниваем Headless- и традиционный подход на примере Strapi CMS и WordPress

Headless CMS — это Low Code Solution для управления контентом.

При первом приближении Headless CMS очень похожа на стандартный подход с Django, Laravel или WordPress с прикрученным JSON API. Но дело в том, что у Headless-подхода есть несколько дополнительных преимуществ.

Выделим главные из них, сравнив Strapi CMS и WordPress:

• Полная и простая кастомизация дизайна
  
  Фронтенд в Strapi — это отдельное приложение. Он не имеет отношения к самой CMS, что дает большую гибкость для создания интерфейсов.

• Скорость отдачи контента
  
  Спорный момент, но Google заявляет, что сайты разработанные с использованием Headless CMS работают быстрее, чем, например, на WordPress.

• Безопасность
  
  У WordPress достаточно много уязвимостей, и поэтому даже простой бэкэнд на нем не совсем безопасен.

• Простота обслуживания и деплоя
  
  Со Strapi всё проще: собираем Docker-образ, пушим изменения кода в репозиторий, и, если настроен CI/CD, всё деплоится без проблем.

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

Если есть, что добавить к плюсам Strapi CMS на фоне WordPress — велкам в комментарии, обсудим. А подробнее о тонкостях работы с Headless CMS пишем в большой статье.

Преимущества Rive при разработке Flutter-приложений

При разработке Flutter-приложений используют много типов анимации, о чем мы ранее уже писали. Но Rive всё-таки превосходит большинство из них. Во-первых, у него удобный встроенный UI-интерфейс. Во-вторых, в Rive есть раздел Community, где авторы выкладывают бесплатные анимации.

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

State Machine включает несколько уровней:

• Graph — пространство, в котором мы добавляем состояния и соединяем переходы.

• State — анимации временной шкалы, которые могут воспроизводиться в нашей машине состояний.

• Transaction — переходы представляют собой логическую карту для State Machine.

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

• Layers — слой State Machine, который позволяет воспроизводить одну анимацию за раз.

Подробнее о том, как работает Rive и как интегрировать его в проект, в нашем блоге.

Как понять, что пора заканчивать процесс Discovery

В этом поможет закон убывающей полезности. Как он работает, объясним на примере.

Когда мы проводим качественные исследования, берем 5–7 человек на один сегмент целевой аудитории. Социология и статистика показывают, что этого достаточно, чтобы выявить 80–90% проблем сегмента. Конечно, мы можем опросить и 30 человек, но выявим ли мы таким образом 100% проблем? Скорее всего, мы потратим намного больше ресурсов, а в итоге сможем лишь незначительно уточнить данные.

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

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

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

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

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

Подробнее о процессе Discovery — в большой статье.

Человек vs машина, или Почему А/Б-тесты не панацея

Недавно Spotify выкатили новую фичу на основе ML — Shortcuts. По сути, это шесть персонализированных плейлистов c музыкальными предпочтениями пользователей.

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

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

🎵 Послушать сейчас.
🎵 Быстрый доступ.
🎵 Горячие кнопки.
🎵 Доброе утро.

Результаты A/B-теста не показали значительной разницы между ними.

Один из участников команды настаивал на варианте «Доброе утро»: так пользователь косвенно будет понимать, что страница с кнопками — его пространство, а горячие клавиши — его персонализированные песни.

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

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

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

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

Мы создали свой инструмент для доставки сборок Android-приложений

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

Да, мы могли бы пользоваться Firebase App Distribution с помощью VPN, но это не очень удобно. VPN-сервисы ненадежны, потому что подвержены блокировкам. К тому же создание собственного решения позволяет добавлять новые функции и адаптировать инструмент под конкретные нужды команды.

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

Для его реализации выбрали фреймворк Ktor. Благодаря этому любой разработчик, знакомый с Kotlin, сможет быстро разобраться в кодовой базе, поддерживать инструмент и интегрировать его с различными проектами. А в качестве интерфейса решили выбрать Telegram. Наши рабочие чаты чаще всего находятся именно там. Кроме того, Telegram Bot API предоставляет много возможностей, хоть и имеет некоторые ограничения.

Делимся исходным кодом этого инструмента. А подробная инструкция по работе с ним — в отдельной статье.

Про роль HR бизнес-партнера в компании

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

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

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

Из вышеописанных функций вытекает третья — трансляция ценностей и преимуществ наружу. Тут HRBP плотно работает с PR-ом, обеспечивая DevRel (Developer Relations) процесс, донося потенциальным соискателям и коммьюнити преимущества работы в компании и укрепляя HR-бренд.

Больше об управлении IT-компанией рассказываем здесь.

Про процесс ДХП (документальный ход проекта)

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

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

Администратор проекта закреплен за несколькими проектными офисами и ведёт до 10 активных клиентов. По итогу этой работы проектной команде и руководству раз в месяц уходят письма с документальным статусом проекта, выглядят они вот так:

Таким образом мы:

• контролируем все документальные риски и узнаем о них заблаговременно;

• снижаем риски непреднамеренного нарушения условий договора;

• получаем дополнительный источник информации о потенциальном срыве сроков проекта;

• разгружаем руководителей проектов;

• передаем весь документальный процесс специалистам с опытом в этой сфере и с фокусом на эту составляющую;

• контролируем и уменьшаем объем работы без подписанных документов.

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

Почему размер телефона имеет значение

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

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

Более того, если пользователь находил заветную кнопку и перелистывал фото, ему приходилось скроллить вверх, чтобы увидеть ее целиком. Чувствуете, как больно? При этом на большом IPhone Pro Max всё было в полном порядке — красиво и удобно.

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

💬 Что, если пользователь предпочитает планшет?

💬 А если он использует только левую руку, потому что в правой держит кофе?

💬 А вдруг это приложение для готовки, и с ним удобнее работать голосом?

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

Больше постов о метриках и исследованиях — в нашем канале.

5 принципов именования и документирования аналитических событий

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

1. Единое место документации событий. Создайте единое место документации всех событий (будь то Notion, Confluence, Google-документ или система аналитики с встроенным трекинг-планом) и используйте только его как источник правды.

2. Единая нотация. Выберите одно соглашение о наименовании (нотацию) и придерживайтесь его. Вот наиболее используемые из них:

• all lowercase — page view;

• snake_case — page_view;

• camelCase — pageView;

• Proper Case — Page View;

• Sentence case — Page view.

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

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

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

Подробнее о каждом пункте мы рассказываем в отдельной статье.

Виды логирования в Swift

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

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

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

Dump — еще одна функция для распечатки сообщений в консоль. При работе с объектами и массивами объектов Dump показывает себя лучше, чем Print и DebugPrint. Мы получаем более наглядный результат, можем повлиять на то, в каком виде представлена информация, избавиться от лишнего «шума» в консоли.

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

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

Подробнее о каждом инструменте — в нашем блоге.

Как оценить, нравится ли сотрудникам работать в компании

Чтобы понимать, какое настроение царит у нас в коллективе, мы раз в полгода проводим два опроса среди всех сотрудников: ESI и eNPS.

1. Индекс удовлетворенности ESI (Employee Satisfaction Index).

Опрос состоит из серии однотипных вопросов, где нужно оценить разные аспекты работы от 0 до 5 (например: уровень ЗП, интересность задач, соцпакет и т. д.).

По итогу формируется сводный показатель в виде среднего арифметического.

2. Индекс лояльности eNPS (Employee Net Promoter Score).

Тут задаем всего один вопрос — вероятность, что ты будешь рекомендовать AGIMA как место работы.

По итогу мы выявляем количество сторонников, нейтралов и критиков.

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

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

Больше материалов об управлении IT-компанией — в блоге нашего исполнительного директора Сергея Кожемякина. Чтобы почитать, включите VPN.

Главный принцип работы с правками от заказчика

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

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

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

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

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

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

Как поведение пользователей может подсказать, какие фичи нужны

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

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

Это навело команду Airbnb на хорошую мысль:

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

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

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

9 типов программистов в 2024

Часть 2

(Часть 1 тут)

Интроверт

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

Codefluencer

Его естественная среда обитания — не VsCode и не GitHub, а социальные сети, чаще всего Twitter. Только что узнав, как вывести "Hello World" в HTML, он постоянно публикует мемы и новости IT. Скорее всего, его зарплата выше твоей просто потому, что он умеет продавать себя.

Программист с ИИ

Искусственный интеллект изменил подходы к работе в нашей сфере. Никто не знает это лучше, чем программист с ИИ. Он пользуется новейшие инструменты — GitHub Copilot, ChatGPT, Gemini и т. д. — и выполняет работу в пять раз быстрее. Но не качественнее.

Мегаразработчик

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

Древний кодер

Последний из своего рода. Этот тип программиста старше интернета, у него длинные седые волосы и белая борода, как у Гэндальфа Серого. Он пишет код только на C или Assembly, его любимая среда разработки — VIM, а глубина его знаний превосходит человеческие.

>>Лайк Cаше и его посту, если узнали коллегу :)

9 типов программистов в 2024

Часть 1

Full-stack разработчик

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

ТехноБро

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

Технохейтер

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

DevOps

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

Продолжение в следующем посте.

3 нескучных приложения для бега

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

Relive

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

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

«Бег» от VK

Сервис «Бег» от VK синхронизируется с данными о тренировках с мобильных гаджетов и публикует их в приложении «ВКонтакте».

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

Zombies, Run!

Это игра для Android и iOS, где вы должны буквально убегать от зомби, чтобы выжить в мире постапокалипсиса.

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

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

P. S. А полезные для бега гаджеты мы рассматриваем в отдельной статье — сохраняйте :)

SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения

SQL (Structured Query Language) — это язык запросов, которые мы используем для работы с реляционными базами данных. У таких БД жесткая структура в виде таблиц. Вся информация там хранится в столбцах и строках. Структурированность — одно из главных преимуществ SQL баз данных.

NoSQL — нереляционные БД, у них нет жесткой структуры. Скажем, у нас есть класс — пользователи. У каждого из них есть ID, имя, фамилия и проч. Эти данные помещаются в отдельный файл (а не в таблицу), и взаимодействие происходит только с этим файлом. Вы уже не можете забрать какое-то одно поле и работаете только с этим классом.

Чтобы выбрать между SQL и NoSQL, нужно исходить из задач бизнеса.

• Если вы делаете маленькое приложение на узкую аудиторию или MVP, можно смело выбирать NoSQL. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL.

• Если вы делаете средний по объему проект, лучше SQL. Хотя, если очень хочется, можно и NoSQL. Но тут есть особенности: выбирайте NoSQL, только если у вас есть налаженные ивенты, налаженная имплементация баз данных и опыт работы с NoSQL.

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

Больше подробностей — в нашем блоге.