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

Изначально эта технология не имела отношения к мобильным устройствам и использовалась для рассылки уведомлений о судебных событиях подписчикам этих событий. Ещё с её помощью слали новости фондового рынка биржевым торговцам. Чуть позже, во время войны браузеров, Майкрософт и Нетскейп внедрили пуши в свои браузеры, но по ряду причин тогда взлетела технология RSS. Ещё чуть позже её внедрили Гугл и Эппл в свои мобильные операционки и вот тогда она уже заработала нормально.

Дальше немного технических деталей.

APNS

На устройствах Apple для работы с пушами используется сервис APNS. Через него пуши отправляются как на iOS, так и на OS X (через Центр уведомлений) и OS X Server (отправка почты, календаря и контактов на устройства пользователей сети).

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

GCM

А на Android-устройства пуши отправляются при помощи гуглового сервиса GCM. Кроме того, через GCM пуши могут отправляться в приложения и расширения для Chrome.

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

Пуши с точки зрения юзабилити

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

Форма уведомления. У сервисов пушей есть ограничения по размеру сообщения (2 килобайта для APNS и 4 килобайта для GCM) и по времени, которое пользователь готов потратить на его прочтение. Размещайте в тексте пуша значимое сообщение, например, как Яндекс Еде: «В честь вашего дня рождения, дарим промокод EDA24 на бесплатную доставку заказа от 800 руб.»

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

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

Звук уведомлений. Настройте свой, неповторимый. Чтобы пользователь знал, что новое сообщение пришло именно от вашего приложения. Такой звук есть, например, у приложения ВТБ, его пуш не перепутаешь ни с каким другим. Это тоже может стать преимуществом.

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

В целом, это всё, что пиэму нужно знать о пушах.

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

У вас четыре варианта подхода к найму исполнителей. 

1. Инхаус-команда.
2. Один или несколько фрилансеров. 
3. Аутстаф команда под полным вашим контролем. 
4. Подрядчик, которому вы поручаете работу под ключ. 

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

Инхаус команда

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

Вариант хорош, когда приложение планируется очень сложным и дорабатывать его предполагается длительный период (в нынешних условиях «длительно» — это 2-3 года). По деньгам вариант получается чуть ли не самым дешёвым, дешевле только фрилансеры. 

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

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

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

Один или несколько фрилансеров

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

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

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

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

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

Аутстаф команда под вашим контроем

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

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

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

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

Подрядчик для работы под ключ

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

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

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

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

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

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

Гит

На проекте я тимлид,
В мастер пушу свой коммит, 
У меня на это есть
Полный доступ в гит.

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

Код ревью

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

CI/CD

Эту загадочную аббревиатуру нужно внедрять в третью очередь, когда гит и код ревью уже заработали. Даёт великое множество профитов — возможность гибко управлять правами доступа, автоматизировать ручные действия и самое главное, возможность нормально масштабироваться. Без CI/CD в случае резкого всплеска нагрузки вам останется только развести руками.

Прозрачный процесс постановки задач

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

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

Руководитель изрыгнул в чат баг или очередную светлую идею — ответственный сотрудник заводит тикет в таск-трекере и скидывает в чат номер. Исключений нет.

Одна задача = одна ветка в гите.

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

Автотесты

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

Мониторинг ошибок

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

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

Вот, в целом, и все полезные практики, которые вам нужно завести в свежем стартапе чем раньше, тем лучше.

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

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

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

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

Классификация фреймворков

Бэкенд-фреймворки

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

Например, при помощи Django вы можете сделать админку с гридами, о которой я писал выше. Это фреймворк на питоне.

Ещё можно выделить:

• Symfony, Laravel — PHP;
• Express.js — JavaScript;
• Ruby on Rails — Ruby.

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

Фронтенд-фреймворки

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

• Angular;
• Vue.js;
• Svelte;
• React — формально это не фреймворк, а библиотека, но значение этого инструмента так велико, что его постоянно сравнивают с другими веб-фреймворками.

Фуллстек-фреймворки

Сюда относятся фреймворки, реализующие как клиентскую, так и серверную часть. Например, JS Meteor.

Возможности фреймворков

Важное для менеджера

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

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

В целом, это всё, что пиэму нужно знать о фреймворках.

1

1

1

Error happened.

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

Кроме того, в вашем продукте может потребоваться реализовать дорогостоящую функцию, которая уже сделана в стороннем сервисе на отличненько. Например, если вам нужны карты, целесообразно использовать API Open Street Map или Яндекс.Карт, это сильно дешевле, чем пилить собственные карты.

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

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

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

Различия REST и SOAP

Чаще всего в современной разработке встречаются REST и SOAP API. Давайте разберём, в чём разница.

Типы запросов

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

1. GET
2. POST
3. PUT
4. PATCH
5. DELETE

GET – используется для получения со стороны севера определенного ресурса. Если вы производите этот запрос, сервер ищет информацию и отправляет ее вам назад. По сути, он производит операцию чтения на сервере. Дефолтный тип запросов.

POST – нужен для создания определенного ресурса на сервере. Сервер создает в базе данных новую сущность и оповещает вас, был ли процесс создания успешным. По сути, это операция создания.

PUT и PATCH – используются для обновления определенной информации на сервере. В таком случае сервер просто изменяет информацию существующих сущностей в базе данных и оповещает об успехе выполнения операции.

DELETE – как и следует из названия, удаляет указанную сущность из базы или сигнализирует об ошибке, если такой сущности в базе не было.

Postman

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

Есть публичное API для смешных переводов, например, эндопоинт для перевода на язык Мастера Йоды находится по адресу: https://api.funtranslations.com/translate/yoda.json

Эндпоинт принимает только один строковый параметр text. Отправим Постманом GET запрос на этот эндпоинт:

Как видите, API возвращает такой ответ:

{
    "success": {
        "total": 1
    },
    "contents": {
        "translated": "Force be with you yoda,Polovec helloy you",
        "text": "Hello Yoda, Polovec helloy you",
        "translation": "yoda"
    }
}

Как нетрудно понять, эндоинт возвратил код успеха, а в поле контента передал три значения:

• translated — переведённый текст.
• text — исходный текст.
• translation — тип переводчика.

По такому же принципу работают любые REST API, только в реальных запросах параметров больше и они сложнее.

Применение в реальной разработке

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

Может сложиться так, что проект будет совсем маленьким и проектирование API поручат вам. Для такого случая предлагаю вам пример API спроектированного мной для мобильного приложения для операций с топливом.

Разное

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

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

В целом, это всё, что пиэму нужно знать об API.

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

Для того, чтобы понять, зачем нужен Кубер, сначала нужно понять, зачем нужен Докер.

Docker

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

У вас может возникнуть вопрос, в чём разница докера и самой обычной виртуальной машины?

Контейнеры и виртуальные машины — это разные способы виртуализации. Только виртуалка реализует её на уровне железа, а Docker — на уровне операционной системы.

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

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

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

Если кратко перечислить преимущества контейнеризации, то это:

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

Все основные облачные провайдеры, такие как Amazon AWS, Google’s GCE, Microsoft’s Azure и даже Alibaba Cloud, предоставляют услуги по размещению контейнеров.

Докер работает на линухе. Чтобы использовать его на винде или макоси, нужно ставить виртуальную машину с линуксом. Теперь несколько слов о том, из каких компонентов состоит Докер:

• Docker host — это операционная система, на которую устанавливают Docker и на которой он работает.
• Docker daemon — служба, которая управляет Docker-объектами: сетями, хранилищами, образами и контейнерами.
• Docker client — консольный клиент, при помощи которого пользователи взаимодействуют с Docker daemon и отправляют ему команды, создают контейнеры и управляют ими.
• Docker image — это неизменяемый образ, из которого разворачивается контейнер.
• Docker container — развёрнутое и запущенное приложение.
• Docker Registry — репозиторий, в котором хранятся образы.
• Dockerfile — файл-инструкция для сборки образа.
• Docker Compose — инструмент для управления несколькими контейнерами. Он позволяет создавать контейнеры и задавать их конфигурацию.
• Docker Desktop — GUI-клиент, который распространяется по GPL. Бесплатная версия работает на Windows, macOS, а с недавних пор и на Linux. Это очень удобный клиент, который отображает все сущности Docker и позволяет запустить однонодовый Kubernetes для компьютера.

Основных сущностей для работы с докером три:

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

Ещё есть специальный репозиторий для хранения докер-образов.

Вы вполне можете использовать Докер без Кубера, но Кубер даст дополнительные возможности.

Kubernetes

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

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

Кластер

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

Узел

Узел — это отдельный компьютер (физический или виртуальный). Его задача состоит в запуске подов. Каждый узел в Kubernetes содержит несколько компонентов, таких как kubelet и прокси kube. Все они находятся под управлением ведущего узла. Узлы — это нечто наподобие рабочих пчел, которые занимаются выполнением всех основных задач. Устаревшее название узла — миньон.

Под

Под (pod) — это единица работы в Kubernetes. Каждый под содержит один или несколько контейнеров. Поды всегда работают совместно, то есть на одном компьютере. Все контейнеры внутри пода имеют одни и те же IP-адрес и пространство портов, они могут общаться между собой через локальный сервер или посредством межпроцессного взаимодействия. Кроме того, все контейнеры имеют доступ к общему локальному хранилищу данных узла, на котором находится под. Такое хранилище может быть подключено к каждому контейнеру.

Что же можно сделать при помощи Кубера?

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

Несколько слов о возможностях Кубера:

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

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

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

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

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

Безопасность и конфиденциальность. Kubernetes может сохранять и контролировать конфиденциальные данные (пароли, ключи SSH, OAuth-токены), распределять права доступа к системе. Обновление и развертывание приложений не затрагивает образы контейнеров и не раскрывает секретные сведения в конфигурации стека.

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

В целом, это всё, что пиэму нужно знать про Докер и Кубер.

2

1

1

1

Error happened.

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

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

Есть отличная книга 2004 года за авторством Сидни Финкельштейна: «Ошибки топ-менеджеров ведущих корпораций», она мастрид для любого айти-руководителя. В ней рассматриваются причины краха таких компаний как General Magic, Motorola, Webvan, Enron. У них не было недостатка капитала, были прекрасные руководители, закончившие заведения Лиги Плюща, были самые лучшие и звёздные сотрудники и тем не менее, они накрылись по разным причинам, которые тоже раскрываются в этой книге.

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

А потом все умерли.

Однако в 2004 году доверие к интернету начало возвращаться. Оказалось, что некоторые модели всё же работают, Google сделал «первое публичное предложение», никому не известный студент Марк Цукерберг основал Facebook и пошло-поехало.

Да и в России компьютеры стали становиться дешевле и доступнее, сотовые компании перестали брать за минутный разговор бюджет небольшой африканской страны, стремительно развивались носители информации. Я помню, как в 2004 году наша преподавательница информатики говорила на лекции, что дискета должна быть в кармане каждого современного человека, это так же нормально, как иметь ручку. В 2005 мы уже вовсю пользовались CD-R и CD-RW, а в 2006 у многих студентов были флешки. В этом году я уже устроился в первую в своей жизни айти-компанию и где-то через полгода купил первый ноутбук.

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

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

Давайте критически посмотрим на микрособытия, которые случились со мной вчера и разберём, каково влияние IT на них.

1. Проснулся от мелодии будильника на смартфоне. Смартфоны, созданные айтишниками, заменили множество устройств, в частности, будильники.
2. Проверил каналы и чаты в телеграме. Телега, созданная айтишниками, заменила другие новостные каналы, региональные, общероссийские и общемировые.
3. Через сайт клиники нашёл у своего врача окно на 11 утра в воскресенье и записался на приём. Сайт создали айтишники, CRM создали айтишники, интеграцию настроили айтишники. Ещё совсем недавно, нужно было звонить.
4. Для самоуспокоения нашёл на prodoctorov.ru отзывы об этом враче и посмотрел его фото, чтобы вспомнить, как он выглядит. prodoctorov.ru, конечно, создали айтишники, теперь любой человек может оставить отзыв о любом враче или клинике.
5. Через сайт агентства забучил на среду, 28 декабря, на 13:30 клинершу. Сайт, CRM, всё создано айтишниками.
6. На сайте службы доставки здоровой пищи заказал ежедневные рационы на пять дней, потому что эндокринолог сказал питаться нормально. Получил ответ на почту, что курьер привезёт первый рацион сегодня с 19 до 22 часов.
7. Просмотрел гуглокалендарь, созданный айтишниками, и обнаружил, что забыл вчера оплатить коммуналку. Ну ничего, вечером к этому вопросу вернусь. Завтра собеседование в 14 часов, надо подготовиться. Собеседование, конечно, онлайн, в компанию, у которой даже нет офиса в Калининграде.
8. Запустил на смартфоне музыку в Яндекс Музыке, созданной айтишниками, оделся, взял рюкзак и отправился на почту, чтобы забрать посылки, заказанные на Алиэкспрессе, созданном айтишниками.
9. Сел в маршрутку, добрался до остановки на Горького, заплатил карточкой через мобильный терминал. Чисто айтишная история. Потом заплатил в автобусе со стационарного валидатора, который тоже создан айтишниками.
10. На почте при помощи терминала электронной очереди (созданном айтишниками, конечно) встал в очередь. Каких-то восемь лет назад приходилось мучиться с живой очередью, гадать, в какое окно встать, помнить, кто передо мной, кто после меня, кто отошёл и всё такое. Пока сидел в очереди, читал на смартфоне соцсеть Твиттер, созданную айтишниками. Оператору показал штрихкод отправления на экране смартфона, он считал его сканером штрихкодов (создан айтишниками), нашёл отправление, отправил мне в приложение код авторизации, который отобразился в пуше. Я продиктовал ему код, он пошёл на склад и принёс посылку.
11. При помощи приложения Uber, созданного айтишниками, я заказал такси. Уже давно не надо звонить и диктовать адрес, достаточно ткнуть две точки на интерактивной карте. Не надо отсчитывать деньги и беспокоиться, будет ли у таксиста сдача. Таксист, находящийся поблизости, взял мой заказ, мне отобразился номер и марка его машины. Да, машина не создана айтишниками, в ней тот же самый арахичный двигатель внутреннего сгорания, но да, появилась электроника, созданная айтишниками.
12. По дороге водитель рассказал мне, что прочёл в телеграмме, созданном айтишниками, новость про то, что глава городской администрации заявила, что нанимать 10 000 дворников, чтобы убирать улицы во время двух недель снегопада нерентабельно. Да, государственным управлением пока занимаются не айтишники, поэтому нормального способа экстренно убирать внезапно выпавший зимой снег, пока нет.
13. Дошёл до ПВЗ маркетплейса Озон, созданного айтишниками, показал на смартфоне штрихкод оператору, оператор считал его сканером штрихкодов, принёс мне две посылки.
14. Я сел в автобус, снова заплатил карточкой и добрался до дома. Сидел рядом с девушкой, увлечённо записывающей видеосообщения с собой и накладывающей на них инстаграмные маски. Инстаграм, ессно, создан айтишниками.
15. Дома я посетил социальную сеть Линкадин, созданную айтишниками, написал в ней пост про микрофон, ответил на комментарии, пролайкал интересные посты.
16. Оплатил через Сбербанк Онлайн коммуналку. Отчётливо помню, как бабушка отправляла меня с квитанциями и деньгами на почту и в банк, я там стоял в очереди и платил в окошечко. Но сейчас у нас есть созданные айтишниками сервисы, в которых всё это делается в пару кликов. В процессе произошло затруднение — протух шаблон оплаты капремонта. Но не беда, я запустил приложение Сбера на смартфоне, сфоткал куаркод на квитанции и всё получилось.
17. Вечером мне позвонила мама через скайп, созданный айтишниками и мы поговорили про наши дела. Рассказала, что зашла на сайт какой-то социальной службы, созданный айтишниками и обнаружила, что её очередь на льготный санаторий продвигается, она уже шестьсот какая-то.
18. Заказал на Аптеке.ру, созданной айтишниками, рецептурные лекарства, которые трудно купить при обычном заходе в аптеку. Их должны доставить в удобную мне аптеку как раз к понедельнику, в который у меня уже будет рецепт от доктора.
19. Мне в скайп написал друг, попросил денег до четверга. Я запараноил и набрал его со смартфона (это уже не айтишники, это уже телеком, но это близко). Он ответил, что скайпом сто лет не пользуется и это мошенники. Даже мошенничество давно переехало в интернет.
20. При помощи приложения Яндекс еда, созданного айтишниками, заказал ужин, оплатив карточкой. Это уже вообще, если вдуматься, чудо техники. Интеграция заказчика, ресторана, курьера, онлайн-оплаты, всё бесшовно.
21. Через банковское приложение, созданное айтишниками, перевёл с накопительного счёта на карту сумму для оплаты еды. Каких-то пятнадцать лет назад для такой операции пришлось бы искать банкомат, а двадцать лет назад ехать в банк. Всё это сделано айтишниками.
22. Уже совсем поздно приехал курьер из доставки из пункта 6. Привёз еду на завтра. Показал на экране смартфона куаркод системы быстрых платежей, созданной банковскими айтишниками, я открыл на своём смартфоне банковское приложение, сосканировал куаркод, оно получило информацию о назначении и сумме платежа, подтвердил эсэмэской, оплата ушла.
23. Сходил в магаз за минералкой и кефиром. На обратном пути обнаружил, что у меня во дворе открылся ПВЗ маркетплейса Вайлдбериз, созданного айтишниками.
24. Чистил зубы обычной электрической зубной щёткой. Да, её создали не айтишники, но уже есть умные щётки, для которых айтишники сделали приложения, которые показывают, в каких зонах вы недочищаете зубы. У меня такой пока нет.
25. Перед сном послушал через приложение «Литрес аудиокниги», созданное айтишниками, интервью Черниговской Познеру. В этом интервью специалист по мозгу, Татьяна Черниговская, ругалась на созданные айтишниками сатанинские холодильники, умеющие заказывать еду через интернет и отнимающие у людей положительные эмоции.

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

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

Теперь несколько слов о высоких зарплатах. Почему продавец в пятёрочке трудится в поте лица и зарабатывает 25 тыс. руб., а разработчик кодит 4-5 часов в день и зарабатывает 250 тыс. руб. Главная разница в том, что продавец в пятёрочке ограничен физической средой. Есть предельное количество посетителей, которое он может обслужить за рабочий день. Я не смог нагуглить, сколько примерно, но это число конечно. Да, в смене группа из нескольких продавцов и её возможности тоже конечны. И автослесарь может починить за рабочий день ограниченное количество автомобилей. И курьер может доставить ограниченное количество посылок.

А группа из нескольких разработчиков (4-5 человек) или даже одарённый программист-одиночка, способны создать сервис, которым будут пользоваться миллионы людей каждый день. Если сервер, на котором крутится этот сервис, не справляется с нагрузкой, при помощи одного девопса и добавления железа в стойку, можно легко расширить возможности сервиса, практически неограниченно. Да, там дальше возникают разные проблемы масштабирования высоконагруженных систем, но разработчики вместе с девопсом могут их решить. Вот в этом и вся разница. Разработчикам много платят не из-за огромного объёма знаний (у неайтишных инженеров этих знаний не меньше), а из-за вот этой масштабируемости создаваемых ими решений.

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

1. Некоторые создатели онлайн-курсов хорошо так заработают.
2. На рынке будет огромное количество парикмахеров, пекарей и автослесарей, закончивших айтишные курсы.

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

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

Менеджмент

Менеджер продукта

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

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

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

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

Аккаунт-менеджер

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

Занимается тем, что уменьшает количество вашего общения с заказчиком, беря его на себя. Часто берёт на себя оформление различных юридических документов при поддержке юристов. Поддерживает с заказчиком хорошие отношения, часто допродаёт услуги (иногда не посоветовавшись с вами). Если аккаунт технически подкован, ему можно делегировать встречи по статусу проекта, но я бы рекомендовал делать это самостоятельно.

Эйчар

Эйчары бывают как в продуктовой, так и в заказной разработке.

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

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

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

Технический директор

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

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

Разработчики

Тимлид

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

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

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

Фронтенд-разработчик

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

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

Делает он всё это, как правило, на JavaScript. В чистом виде JS используется редко, чаще применяется один из JS-фреймворков, например React, Vue или Angular.

Бэкенд-разработчик

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

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

Хорошие бэкендеры владеют несколькими языками программирования: C++ или C#, PHP, Python и фреймворками, которые сильно облегчают им бэкенд-разработку. В случае, например с PHP, это Laravel или Symphony, для Python популярен Django.

Если нет девопса (о нём ниже), чаще всего вопросами гита и развёртывания тоже занимается один из бэкендеров.

Мобильный разработчик

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

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

Айосники обычно пишут либо на Swift (чаще), либо на Objective С (реже). Андроидщики — на Java или более новом Kotlin.Технически подкованные ведроводы, пищущие особо сложные приложения или игры, используют C/C++

У специалистов по кроссплатформе всё сложно.

Quality assurance

Мануальный тестировщик

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

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

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

Когда-то путь тестировщика считался самым простым способом входа в айти. В 2022 требования к ним сильно выросли, современный тестировщик должен уметь развернуть на своём компе ветку разработчика, постучаться в API при помощи Postman или Swagger, отлично уметь пользоваться консолью разработчика в браузере и не только в Хроме, а вообще во всех, уметь составить запрос к БД и многое, многое другое.

Самые системные и коммуникабельные тестировщики становятся лидами тестирования и начинают относиться уже больше к менеджменту.

Тестировщик-автоматизатор

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

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

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

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

Пишут автотесты они на скриптовых языках, прежде всего на Python и JS. Используют массу инструментов, например, Selenium и Protractor.

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

Дизайнеры

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

Функция UX (User Experience) ближе к аналитикам. В рамках этих задач дизайнер определяет, как будет работать интерфейс, его логика. Как сделать, чтобы интерфейс был максимально простым, не вызывал у пользователя желание обратиться в саппорт.

Функция UI (User Interface) уже чуть более «творческая». В рамках этих задач дизайнер определяет, как будет выглядеть интерфейс, его внешний вид. Эти функции неотделимы.

Так как проработка дизайна в том виде, в котором он будет готов для вёрстки, требует много времени, дизайнер интерфейсов должен уметь рисовать «вайрфреймы». Это такие наброски интерфейса, которые можно набросать за несколько часов и по которым уже можно судить, насколько это будет удобно использовать.

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

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

Аналитики

Бизнес-аналитик

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

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

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

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

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

Системный аналитик

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

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

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

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

Сисадминская братия

Системный администратор

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

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

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

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

Девопс

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

Эти ребята могут разворачивать процесс непрерывной интеграции и развёртывания при помощи разных инструментов — Git, Docker, Kubernetes, уменьшая тем самым головную боль программистов. Автоматизируют процессы в Jira, уменьшая головную боль всех остальных участников процесса и повышая связность системы. Также настраивает мониторинг всех развёрнутых контуров, контролирует работоспособность.

В разработке высоконагруженных приложений, девопсы бесценны.

Администратор баз данных

Достаточно редкие звери в современной разработке, за 13 лет работы я встречал выделенного dba-шника всего один раз. Нужен там, где много баз данных, все они здоровенные и критически важные.

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

Чаще всего же на dba экономят и всё это делает девопс или сисадмин.

Прочие специалисты

Контент-менеджер

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

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

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

Маркетолог

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

Например, вас могут попросить реализовывать нетипичный интерактивный элемент на сайте, лендинг (обычно по готовому дизайну, с чёрным фоном, конечно же), современный маркетолог может запросить ещё и телеграм чат-бота.

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

Технический писатель

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

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

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

Чаще на техписе экономят и инструкции пишет либо кто-то из аналитиков, либо вы.

Специалист по информационной безопасности

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

ИБ — это уже чисто айтишники.

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

В общем, с этими ребятами надо дружить.

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

Для начала, поместите в functions.php следующий код:

/**
 * Extension for wp_nav_menu()
 * Remove element "a" from current menu item
 *
 * Optional $args contents additional arguments
 * string replace_a_by - Whether to wrap the link text node, and what to wrap it with. Default 'span'.
 * string xpath        - xPath expression.
 *
 * @param $args
 * @see wp_nav_menu()
 * @return mixed Menu output if $echo is false, false if there are no items or no menu was found.
 */
function wp_nav_menu_extended($args = array()) {
    $_echo = array_key_exists('echo', $args) ? $args['echo'] : true;
    $args['echo'] = false;

    $menu = wp_nav_menu($args);

    // Load menu as xml
    $menu = simplexml_load_string($menu);

    // Find current menu item with xpath selector
    if (array_key_exists('xpath', $args)) {
        $xpath = $args['xpath'];
    } else {
        $xpath = '//li[contains(@class, "current-menu-item") or contains(@class, "current_page_item")]';
    }

    $current = $menu->xpath($xpath);

    // If current item exists
    if (!empty($current)) {
        $text_node = (string) $current[0]->children();

        // Remove link
        unset($current[0]->a);

        // Create required element with text from link
        $element_name = $args['replace_a_by'] ? $args['replace_a_by'] : 'span';

        $dom = dom_import_simplexml($current[0]);
        $n = $dom->insertBefore(
            $dom->ownerDocument->createElement($element_name, $text_node),
            $dom->firstChild
        );

        $current[0] = simplexml_import_dom($n);
    }

    $xml_doc = new DOMDocument('1.0', 'utf-8');
    $menu_x = $xml_doc->importNode(dom_import_simplexml($menu), true);
    $xml_doc->appendChild($menu_x);

    $menu = $xml_doc->saveXML($xml_doc->documentElement);

    if ($_echo) {
        echo $menu;
    } else {
        return $menu;
    }
}

А затем разместите в header.php вот такой вызов:

<?php wp_nav_menu_extended( array( 'theme_location' => 'primary', 'menu_class' => 'nav-menu') ); ?>

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

<h1 class="vcard author">
<?php if ( is_front_page() && !is_paged())
echo bloginfo('name');
else echo "";
?>
</h1>

<h1 class="vcard author">
<a href="<?php echo get_option('home'); ?>/" title="На главную страницу">

<?php if ( is_front_page() && !is_paged())
echo "";
 else 
 echo bloginfo('name');
?>

</a>
</h1>

Об опциях к приложениям

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

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

Сейчас ситуация средняя. В Макоси, например, сделали иерархию, оставив на самом верху системных настроек минимум разделов. В приложениях Майкрософт Офиса тоже отказались от полотен настроек, сделав всё компактно. В приложениях, которыми я пользуюсь активно — Mail, Ulysses, Agenda, Evernote, Todoist, тоже среднее количество настроек. Думаю, такая детализация опций сохранится и в ближайшем будущем.

О скрытых убийцах

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

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

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

Напишу точные названия нужных анализов:

• Гликированный гемоглобин HbA1С (HbA1С, Glycated Hemoglobin, GHB)
• Глюкоза (Glucose)
• Инсулин (Insulin)
• Холестерин общий (Холестерин) (Cholesterol Total)
• Холестерин ЛПНП (Холестерин липопротеинов низкой плотности, ЛПНП, β-холестерин) (Low-Density Lipoprotein Cholesterol, LDL Cholesterol)*
• Холестерин ЛПВП (Холестерин липопротеинов высокой плотности, ЛПВП, α-холестерин) (High-Density Lipoprotein Cholesterol, HDL Cholesterol)

Об общественном устройстве будущего

Я тут недавно публиковал нейросетевое видео об эволюции человека, которое предсказывает постепенное превращение людей в разумные гофрированные трубки. Но до этого ещё далеко.

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

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

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

Сейчас никаких «общечеловеческих» ценностей в мире нет и их никогда не было. Гугл говорит, что сейчас в семи странах практикуется каннибализм и это укладывается в рамки их морали. Но эти ценности появятся по мере формирования этого самого глобализированного общества.

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

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

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

Но до гофрированных трубок пока далеко.

О том, как важно иногда сдаваться

Решил посмотреть сериал «Выбывшая» про Элизабет Холмс и её детище. В очередной раз убеждаюсь, что излишняя целеустремлённость и упёртость может навредить. Я как-то писал о том, что иногда вовремя сдаться и попросить о помощи — лучшая стратегия.

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

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

Очень важно вовремя остановиться.

Об аббревиатурах

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

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

Или Систех. Приложение для мобильной торговли называется «Мобильная торговля». Приложение для отслеживания торгпредов — «Локатор». Приложение для репликации данных — «Репликация». Приложение для OLAP-кубов — «Аналитика OLAP»

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

О хобби и KPI

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

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

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

Не вешайте на хобби KPI и будет вам счастье.

О важности своевременного отключения рефлексии

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

Тёрк идёт к главному хирургу Вэнгу и спрашивает, как так получилось. А тот отвечает — ты зачастую слишком много думаешь.

Ну да. Тёрк такой: «А какой доступ лучше сделать, а что будет, если не удержим давление, а что будет, если он начнёт кровить…» А Тодд в то же время: «Тум-тум-тум, красивый скальпель, тум-тум-тум, пора порезать». И добивается успеха.

В условиях неопределённости и суженного до десяти минут горизонта планирования, в менеджменте тоже часто первыми оказываются не Тёрки, а Тодды.

О документах с полосочками

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

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

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

Полосочки в документообороте должны умереть.

О подписках на селебрити

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

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

О чипировании в гуглодоках

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

Вводите @ а после него название чипа и гуглотаблицы подскажут подходящие варианты. Добавление чипа человека не открывает ему доступ к документу.

Ещё через меню «Вставка» такое можно сделать.

Об упущенных возможностях и разновидностях пальто

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

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

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

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

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

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

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

Пальто, кстати, я у него купил.

Об обуздании зума

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

Опции → Звук → Автоматически включать звук компьютера при входе в конференцию.

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

Снова о приоритизации

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

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

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

О цифровых активах

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

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

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

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

О первом диске

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

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

Об обновлении на Вентуру

Для маководов. Три дня как обновился на Вентуру (13.0) Где-то полчаса качался дистрибутив, ещё полчаса система обновлялась. После обновления показала небольшую презенташку.

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

Со второго раза система переустановилась, флешка увиделась.

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

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

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

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

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

UPD: Я неправ, ящики отваливаются, звук глючит. Всё стабильно.

О важности протестов

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

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

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

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

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

Пришлось этот конструктор с позором выпилить и о подсказках забыть. Я не берусь подсчитать, сколько денег мы в эту функциональность закопали. И всё оттого, что ни у кого не хватило духу сказать гендиру: «Нет, мы не будем делать эту херню».

О самой дорогостоящей ошибке

В посте «Самая дорогостоящая ошибка, допущенная на работе», реддитор ZestyPing написал:

Я встретил Carl Page и Larry Page в 1998 году на вечеринке, которую организовал мой друг в Стэнфорде. 

Carl вручил мне визитку от eGroups и сказал «мы принимаем на работу». Потом Larry вручил свою от Google — дешевый кусочек картона, текст на котором очевидно был распечатан на струйном принтере — со словами «мы принимаем на работу».

Я сказал, «Не-а. Разве кому-то нужен еще один поисковик?» и ушел получать высшее образование.

Визитка все еще у меня.

О важности работы и участия заказчика

Работа заказчика для реализации проекта не менее важна, чем работа исполнителя.

Год 2008, лето, код 4012. Я только-только закончил университет и хочу немного передохнуть от айтишечки. Покупаю давно желанный фотоаппарат и начинаю учиться снимать. На дне города случайно знакомлюсь с директором калининградского агентства развлечений и он приглашает меня поработать на него фотографом. Почему бы не совместить увлечение с заработком?

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

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

1. Референсы внешнего вида.
2. Контент.
3. Чтобы он оплатил хостинг и домен, админпанель хостинга надо регать на него.

Хорошо, говорит он. На этом вопрос сайта встаёт на паузу. И далее, где-то два раза в месяц у нас повторялся разговор:
— Как у нас дела с сайтом?
— Ну, мне нужны референсы, контент и домен с хостингом.
— А, хорошо.

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

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

О теории и практике

Я хотел бы набросить на вечный вентилятор спора, что важнее, теория или практика. Как правило, в описаниях курсов сейчас пишут: «Только практические рекомендации, никакой воды» и считается, что это хорошо. Только практика, только реальные кейсы, только хардкор. 

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

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

Так и лощёному скраммастеру с макбуком не будет лишним освоить тяжеловесные методологии прошлого и основы объектно-ориентированного программирования. Эти знания могут совершенно неожиданно оказаться полезными в условиях современной гибкой разработки. 

О карьерных манипуляциях

А ещё вот как бывает. Вам накидывают обязанностей или повышают по грейду и повышают зарплату. Это называется карьерный рост.

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

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

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

Плюс минус

Вычитал в Википедии про показатель «плюс-минус» в профессиональном хоккее. Его придумали в пятидесятые годы прошлого века, но считать для всех игроков НХЛ начали в 1967 году.

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

В скраме не принято смотреть личные метрики, только командные, но мне кажется, что аналог метода «плюс-минус» позволил бы намного объективнее взглянуть на вклад каждого члена команды.

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

Когда я в «Системных технологиях» руководил группой «Чикаго», считал для каждого пиэма разницу между согласованными с заказчиком (плановыми) и фактическими трудозатратами, эта простенькая метрика чётко показывала, кто приносит компании прибыль. Диаграмма на приложенной картинке, фамилии закрасил.

Об источнике задачи в джире

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

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

О мотивации

— А давайте введём систему мотивации!
— Отличная идея! Давайте введём систему KPI, при полном выполнении которой сотрудники будут получать 100 % переменной части, которую сейчас и так получают. А у кого будет меньше, будем снимать часть переменной части.
— Стой, у меня идея получше.

О важности грамотного завершения испытательного срока

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

Прочитал историю программиста Иннокентия, который устроился в одну модную и современную айти-компанию, но не поладил с менеджером. Токсичным оказался программист, если вкратце. Менеджер вёл с ним долгие беседы, пытался исправить ситуацию, но взрослых людей трудно перевоспитывать. Решил увольнять. Пиши, говорит, заявление. В 99 % случаев на этом всё успешно заканчивается, но не в нашем случае. Фигушки, ответил Иннокентий, платите мне два оклада, тогда уйду. А платить не хотелось.

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

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

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

В общем, завершение испытательного срока — это важно.

О незапланированных фичах

В появлении таких «незапланированных фич» прелесть геймдева.