Большая часть денег венчурных инвесторов уходит на маркетинг и привлечение пользователей. По разным оценкам — не менее 70–80%. Эти средства в конечном итоге оседают в карманах Google и Facebook. Это и есть главные бенефициары гонки вооружений фондов и стартапов

Друзья, есть интересная вакансия на CTO/ИТ-архитектора в одну крупную компанию (сразу предупреждаю, что не имею к компании отношения).

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

Если кому-то интересно — в профиле канала есть контакт для связи.

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

Читатели, нужна ваша помощь. Прямо сейчас, безотлагательно, напишите мне, с какими шинами сообщений/интеграции работали, и как впечатления. Мнение будет записано и опубликовано в канал (с правками), если вы не будете против. Адрес, куда писать - в инфо канала. Спасибо!

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

1. Большинство использует интрузивные, но легковесные системы с поддержкой AMQP или JMS-совместимые (да, я понимаю, что JMS это не протокол). Интрузивные значит, что вся система знает, что это очередь и у нее конкретный протокол.

2. Шина у большинства инсталляций это на самом деле брокер очередей сообщений

3. Иногда на базе него делают request/reply

4. В отдельных редких случаях (один или два написали) очередь была спрятана за кодогенеренным адаптером, реализующим rpc/rmi

5. Оставшееся меньшинство используют более тяжёлые решения ESB или альтернативную Кафку

6. Все так или иначе довольны решением, его стабильностью и производительностью :)

Один мой воображаемый друг из твиттера (https://twitter.com/ruhkr54/) написал прекрасное, так что я решил запостить это сюда. История про типичную IT-задачу в банке.

Вводные: что от чего надо унаследовать, квадрат от прямоугольника, или наоборот? Задача не простая, решать собрался всяк светоч банковского IT..

—

“Итак. После воркшопа с бизнес-клиентами было решено, что лучший способ наследования - это от прямоугольника к квадрату. Приглашенная команда консультантов предложила схему наследований, фабрик линий, точек и углов с веб мордой. Ст. архитектор на собрании с тремя другими архитекторами утвердил  данную схему с незначительными изменениями. DBA развел координаты  стартовой точки и угол - в одну таблицу, длину и ширину - в другую и  написал функцию в бд для получения трех остальных точек. Три функции и sql view.
Поскольку команда была перегружена, работу с измерениями передали в другой отдел. Там все-равно был очень талантливый мальчик, который как раз машин лёрнинг изучает - ему полезно.
После консультации с юристами и экспертами по безопасности поняли, что базЫ данных (вторая команда решила работать в своей БД, не вашей) нужно переделать. К каждому полю добавили историю изменений, ники тех, кто с ними работал, флаг на согласие клиента для обработки.
В отделе после пары рефайнментов с энтузиазмом принялись пилить свою часть. Спринг бут + дата, Entity объекты для хранения того, что достаешь из БД, DTO для того, что отсылаешь, по три конвертера и контроллера для каждой сущности.
Измерения от второй команды импортируют из внутреннего хранилища. Требуется 15 разных разрешений что бы начать работать с тестовым сервером, запустить локально невозможно (на самом деле возможно, но нужно попросить коллегу прислать один файл).
Это все - вводная, которую тебе удалось восстановить ковыряя архивы конфлюенса. Пробивая имена причастных ты вдобавок узнал что у DBA никогда не было технического образования - он окончил художественное, и уже пару лет как ушел из банка в оперу.
Теперь задание - клиентка - бабушка-математик заметила, что при масштабировании у квадрата едут стороны и он почему-то становится больше похожим на прямоугольник. Задачу поручают тебе. Дополнительные факторы для проверки стрессоустойчивости: только ты приступаешь к работе как твоя рабочая станция выключается. Это "долгожданный" переход на Виндоус 10. После часа установки ты становишься счастливым обладателем новой оси.
Но вот ведь незадача! Ответственные за обновления забыли, что в банке есть кто-то кроме работников фронт офиса и техподдержки. Все приложения кроме браузера, офиса и (по недосмотру) гита заблокированы. У тебя есть лишь Notepad для выполнения задания. Время уходит, завтра - релиз.
Забыли про вторую команду? Она про вас тоже!!! Талантливый мальчик с ML ушел на повышение, новый коллега переделал тип измерения в строки и поменял эндпоинты и уронил БД. Ваш скрам мастер весь день пытался им дозвониться, но не смог, потому что у них отмечают день независимости.”

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

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

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

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

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

Возможно, что и методики управления при этом не сильно видоизменятся

Когда я шел в CTO, я себе наивно представлял картину, будто это — Самый Главный Архитектор компании, который принимает решения, как будут устроены системы и приложения, выбирает Cамые Новые И Лучшие Технологии, показывает, как писать Самый Правильный Код, при этом все молчат, согласно кивают, записывают. Во многих стартапах до сих пор CTО это самый лучший программист.

По факту вышло немного не так. Вернее, много не так. Задачи CTO это в первую очередь:
* Технический pre-sale ключевых проектов;
* Встречи с проектными менеджерами;
* Координация работы департаментов;
* Найм, онбординг людей, дообучение
* Формирование рабочей атмосферы в коллективе, мотивация людей
* Оценка продуктивности людей и решение об уровне их зарплат;
* Выбор и внедрение вспомогательных систем для разработки и администрирования: эксплуатация техники, выбор и закупки лицензий и оборудования
* Обеспечение темпа и качества разработки
* Опредение регламентов работы, настройка и оптимизация процессов ИТ производства
* Внешнее производство: поиск вендоров, переговоры, контрактование, распределение и контроль внешних ресурсов
* Руководство эксплуатацией сервисов и приложений: общие решения по инфраструктуре серверов и сервисов, сетей, БД, размещений, сборки, развертывания и поставки
* Общие решения и принципы по документирования и регламентированию разработки
* решение разнообразных КРЯ КРЯ доверившихся тебе людей

И уже ПОТОМ (если останется время - НЕТ)
* Экспертные предложения по архитектуре или конкретным техническим решениям;
* Управление техническими рисками на проектах

И если еще после этого останется время, то (хахаха):
* Написание кода, обзоры кода, рефакторинг

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

Самые лучшие микросервисы это JavaEE

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

Очень важное определение на самом деле

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

Пользуясь материалами блога “Стратоплан”, я составил некоторый скромный индекс того, что принято называть soft skills, и что будет актуально вне зависимости от технологий, специализации и такого прочего. Как я уже сказал, это индекс, т.е. — сгруппированные по блокам и темам ключевые слова и понятия, по которым в интернете можно найти материал: книги, статьи, выступления, и немедленно приступить к ознакомплению. Ключевые слова дают достаточно крепкое и разностороннее понимание темы, как ее видят в индустрии.

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

Наверняка буду пополнять, а вот сильно редактировать — нет.

Ссылка на индекс: https://docs.google.com/document/d/10JkELEYxLtQuU1JwHf9CXKvlV3csSX6QAoF5lXXBbWk/edit?usp=sharing

Наблюдение из жизни: Рано или поздно всякая ИТ-компания пишет свою систему управления задачами/хелпдеск, и рано или поздно от неё отказывается

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

“Срок разработки любого продукта можно уменьшить в 6 раз. Решение простое – приходишь к разработчику, говоришь: нужно сократить сроки во столько-то раз. Уходишь, он начинает думать, как жить с этим, и оказывается, что это действительно возможно”

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

Программисту на заметку: как быть, если вы не согласны с решением, которое предлагает руководитель, менеджмент, архитектор, лид? Существует действенный метод, который в долгой перспективе, вероятно, единственно правильный. Называется DAC: disagree and commit. Другими словами, следует быть максимально красноречивым в фазе, когда идёт обсуждение, но когда решение было принято, надо перестать спорить и приложить максимум усилий к реализации именно этого варианта как своего собственного, даже если ты на 200% с ним не согласен https://en.m.wikipedia.org/wiki/Disagree_and_commit

“Способность постоянно обучаться” синоним “все время быть неправым и не психовать”. Действительно, редкий навык