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

По каждому продукту из цепочки 1) сформулирован результат, который достигается продуктом (конкретика) 2) он (результат) измерен (измеримость) 3) измерена его цена (достижимость) 4) понятно, нужен ли он в действительности (актуальность) 5) известно время его достижения.

Эти пять вопросов называются оценкой по SMART: Specific - конкретика, Measurable  - измеримость, Achievable  - достижимость, Relevant  - актуальность, Time-bound - ограниченность по времени. Подробнее прочитаете здесь: https://ru.wikipedia.org/wiki/SMART

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

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

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

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

Смех-смехом, но это единственное, что отделяло нас от победы. И как быть, было непонятно.

Мои девопсы построили за пару дней небольшой machine learning на базе решения от ibm, который совмещал по смыслу картинку и текст, замыкая таким образом смысловой баннер в единую композицию.

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

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

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

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

В итоге через полгода после того, как всё было неготово, с ними приходилось расставать, - они до сих пор ходят по рынку и рассказывают, как всё круто сделали на моих проектах :) Статьи пишут на хабре и выступают на хайлоаде!

Если отвлечься от эмоций, то такие товарищи блокируют разработку на неопределённый срок. И это реальный риск потерять контроль над всем проектом. Будьте ОЧЕНЬ внимательны к админам/девопсам!

Резюмируя по админам/девопсам: это критически важные роли для проекта.

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

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

Обсудить здесь: https://t.me/ctorecordschat

Как админы/девопсы делают "ничего".

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

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

И тут они ОЖИВЛЯЮТСЯ. У них сверкают глаза, они играют мускулами, они в костюме супермена. Отдают звонкие команды всем. Кричат "не путайся под ногами" всем, кто путается. И ещё масса героизированного представления.

И они всех спасают! Они гордо удаляются, - настоящие герои. На этом их функция окончена. Бравурная музыка.

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

В работе с хорошими сисадминам/девопсами всё немного наоборот, - они скучные и просто что-то делают. Всё работает. Они пинают меня, требуют каких-то планов, что-то согласовывают... всё довольно скучно. Иногда они прибегают и говорят "то-то и то-то почти сломалось, но мы уже исправили...  чтобы больше не повторялось нужен аппрув на то-то и то-то".

Всё работает. Всегда. И проблем не бывает. Никогда.

Прекрасный UPDATE от Эрик Олдман https://fb.com/oldmann.lj

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

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

И результат - 10 лет без неплановых простоев на одной из крупнейших ИТ-инфраструктур РФ, РАО ЕЭС/ФСК ЕЭС. 9 часовых поясов на борту, 24х7х365, тяжёлая бизнесовая функциональность с ВОТ ТАКУЩИМ секвентальным SQL)

Немного о том, что где не получить хороших бекенд-разработчиков

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

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

Ещё я прошу своих собственных разработчиков посоветовать мне хороших новых бекендеров. Это уже шах и мат! Я должен быть просто завален мега-крутыми бекенд-разработчиками. (Спойлер: приводят за хвост "сбитых лётчиков").

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

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

Задачка-градусник для определения способности кандидата работать бекенд-разработчиком

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

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

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

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

В http://t.me/ctorecordschat идут жаркие дебаты о том, как решать задачку про друзей!

По следам сегодняшнего поста про то, где не найти разработчиков, задаёт вопрос Алексей С. (fb.com/asudachen)

У меня вот вопрос прямо противоположный - как найти перспективный проект, о котором можно рассказывать другим людям с интересом и гордостью, и команду с толковым лидом, говорящую на одном с тобой языке (и я не про исп/англ/рус). Чтобы можно было не париться "трудностями перевода" и душу в проект вкладывать, а не только часы. Ну и чтобы платили ещё адекватно, да.

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

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

Конечно! Всё именно так.

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

ТТТ, чтоб не сглазить!


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

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

В моих командах человек сегодня и человек завтра - это разные люди.

Детям: как войти в айти?

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

Я постарался составить рекомендации таким образом, чтобы ими могли воспользоваться родители не только из Мск и Спб, но и во всей нашей необъятной родины.

Сначала про доступные для покупки знания:

* Английский язык must have, что является просто гигиеническим минимумом. То, что дают в обычных средних школах не очень-то и хватает для решения простой задачи: как читать литературу не только нашей родины, но всего мира? Согласитесь, такой скилл резко расширяет горизонты.

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

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

* В спб и мск большие университеты запустили обширные курсы программирования для майнкрафт (я не шучу!), для простейших игр, для разработки сайтов и вот этого всего. Ключевая ценность именно этих курсов заключается в самих университетах и знаниях, которыми они обладают. Стратегия win-win: университеты заинтересованы в светлых головах детей, а вы заинтересованы в развитии своего ребёнка.

* В каждом городе миллионнике при местному институте/университете, как правило, есть курсы программирования для детей. Выбирайте по принципу "чем ближе к государственной математике, тем лучше". Лучше плохие коммерсанты из науки, чем хорошие коммерсанты без науки (в случае Мск это особенно критично). Не переплачивайте за эти курсы, - среди них всегда есть выбор.

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

Теперь про самообразование:

* Языки программирования: как показали последние данные статистики, Си,  Джава и Питон не устаревают.

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

Джава - это банковский сектор, работа с деньгами, многочисленная и сложная логика.

Кроме того на Objective C и Java пишутся мобильные приложения, что сейчас очень востребовано. Ребёнок, скажем лет 16, вполне может найти себе подработку на эту тему в режиме удалённой работы.

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

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

* Базы данных: MySQL и Mongo. Это та самая основа, на которых пишуются большинство попыток стартапов. Студентами. Как раз из-за лёгкости обучения. Что называется, сел и поехал.

* Бонус-трек: HTML и Node.Js, которые обязательно требуется учить сразу оба два. Увы, даже многие профессионалы ещё не смогли принять факт: время простых html-страничек закончилось и началось время разработки приложения под браузеры.

Монс в чатике тарантула сформулировал правильное обоснование про механизм очередей

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

если вы готовы потерять, то:
никакой репликации, ставите несколько нод, выдача id'шников внешняя (или uuid). кидаете задачи round-robin'ом, потребляете из всех
если какая нода сдохнет - задачи, лежащие в ней либо птеряются, либо выполнятся позже

если готовы задвоить, но не потерять:
ставите N(>1) очередей под одни и те-же таски.
всё, как с обычными БД. выбираете мастера, работаете только с ним, если отваливается, переключаетесь и т.п.

если нужна strong-consistency: вам точно нужны очереди? ))

чаще всего применяется первый подход
для второго хорошо подходят идемпотентные операции (тогда можно не париться из-за двойной обработки)

Т.о. queue, как базовый элемент конструктора, может использоваться, но для распределённых/отказоустойчивых архитектур требуются дополнительные на[д]стройки. Как впрочем и с любым инструментом

(с) fb.com/mons.anderson

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


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

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

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

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

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

Чтобы избежать таких блокировок придумали асинхронное взаимодействие. Браузер посылает запрос на воркер бекенда, который регистрирует в очереди задачу и тут же возвращает браузеру идентификатор этой задачи, освобождая таким образом блокировку. Сам браузер периодически дёргает воркер бекенда и спрашивает, - а не решилась ли задача с таким вот идентификатором? Не решилась? Тогда я через 15 секунд ещё раз попробую. О! Решилась! Дайте результат! Пользователь, смотри, - Твой платёж прошёл!!!

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

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

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

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

https://www.youtube.com/watch?v=FZEmZiMsm-0

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

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

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

2. Это позволяет делать сложную многоступенчатую асинхронную обработку различных бизнес-задач. Уже приводился пример с отправкой почты, но он достаточно примитивен. Более подробно см. Сети Петри (1)

3. Реализация такого функционала очень удобна для организации  сколько-нибудь сложных бизнес-процессов.

4. Критически важным являеется транзакционность систем передачи сообщений: сообщение не может быть потеряно, а при поддержке всеми сторонами протокола двухфазной фиксации(2) - задублировано. Кроме того, это позволяет производить обработку бизнес-задач длительное время - часами, сутками и т.д.

5. Более подробно можно посмотреть книжку Enterprise Integration Patterns (3) Книжка большая и несколько водянистая (так было принято писать в нулевые, что уж тут поделаешь)

6. Примеры реализации: Apache Camel, Spring Integrsation, Spring JMS, MDB из JEE. Различные реализации BPMN - jBPM, Activiti, Camunda... (интересно, что эти реализации используют СУБД, а не системы передачи сообщений). Отчасти DBMS_SCHEDULER из Oracle, pgpro_scheduler и много чего еще. Есть что-то для C#, но тут я точно не могу сказать.

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


[1] https://ru.wikipedia.org/wiki/Сети_Петри
[2] https://en.wikipedia.org/wiki/Two-phase_commit_protocol
[3] http://www.enterpriseintegrationpatterns.com/

(c) fb.com/vpupken

А можешь сходу дать тестовое задание для проверки на вшивость пыхера с graphql?

fb.com/dolphin278 отвечает: я не очень знаю, как на пыхе gql-бэкенды пилят, но по сути:

1. Я бы предложил нарисовать схему, в которой нужна пагинация, и посмотрел бы, как он ее реализовал, знает ли про механизм connection'ов, предложенный в relay.js, и какие у него сильные и слабые стороны.

2. Я бы спросил, как он собирается защищать публичны /graphql эндпойнт в проде, чтобы снаружи ему не напихали чего-то огромного толстого и нецензурно называющегося в него в виде произвольных, избыточно сложных запросов (например, большие числа в механизм пагинации из пункта 1)

3. Я бы дал какое-нибудь приложение несложное, и предложил спроектировать для нее graphql-схему, и посмотреть, где он заложится на возможное расширение ее в будущем.

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

Про адекватность руководителя

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

Некоторые становятся африканскими диктаторами. Кто-то мнит себя императором.

Но как ни крути, - даже руководители согласуют свою деятельность с реальностью. Чтобы не наткнуться на маяк.

Или не согласуют. Их обычно называют сбитыми лётчиками.

https://www.youtube.com/watch?v=ql0ce2NY8GU

Приходилось ли работать с руководителем диктатором?
anonymous poll

Да уж... был опыт. – 43
👍👍👍👍👍👍👍 49%

Нет, бог миловал... – 27
👍👍👍👍 31%

Я - император, а вы просто не умеете работать! – 17
👍👍👍 20%

👥 87 people voted so far.