Всем привет!

Считается, что есть 2 мира разработки - enterprise со своими правилами, инструментами, платформами и все остальные, использующие в настоящее время в основном opensource. Я это знаю по Сбербанку, но судя по открытым источникам примерно тоже самое происходит в Яндексе, Google... Но эти два разных мира на самом деле пересекаются.

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

Google - Android, Chromium, k8s, Istio (service mesh), gRPC (RPC binary protocol), Go (lang), Angular (JS framework), Gerrit (code review), Knative (serverless platform), TensorFlow (ML), Apache Beam (data streaming platform)
LinkedIn - Kafka (streaming message broker)
Facebook - Cassandra (noSQL), React (JS framework), Thrift (RPC binary protocol)
Netflix - Eureka (discovery), Zuul (API Gateway), Ribbon (client side balancer), Feigh (http client), Hystrix (circuit breaker), Chaos Monkey (chaos engeneering)
Twitter - OAuth (auth protocol)
Amazon - S3 API (object storage API)
SoundCloud - Prometheus (metrics)
Yahoo - Zookeeper (distributed coordinator)
Yandex - Clickhouse (analytic DBMS), YDB (distributed SQL DBMS), Yandex Tank (load testing)
mail.ru - Tarantool (IMDG)

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

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

#it

Всем привет!

Интересная статья с опросом разработчиков https://habr.com/ru/articles/797045/

Что хотелось бы сказать по итогу прочтения.
Тему зарплат я обсуждать не готов, это слишком сложно)
То, что именно джуны склонны приукрашивать свое резюме - ожидаемо.
Процент девушек в ИТ - ну да, ну да, все грустно.
Тот, факт, что в ИТ проходят без профильного высшего образования (или образование было профильным, но преподавали не то) - тоже понятен. Зато с техническим, что тоже понятно.
Интересно то, что таких людей становится больше. Я честно говоря, думал наоборот. Вроде ИТ кафедр больше, чем лет 10-15-20 назад ...
Видимо работает тренд "Войти в ИТ".
Что еще интересно - в более 50% случаев люди, пришедшие после курсов, без опыта, сумели влиться в команду.
Ну и самое интересное - оценка полезности курсов.
Яндекс Практикум - ок.
Хекслет и Karpov.Courses - не слышал, надо бы глянуть.
По крайней мере теперь понятно, куда направлять тех, кто хочет войти в ИТ)

#learning #it

Всем привет!

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

Что в итоге? Мыши колются, но едят кактус)
А хочется найти решение, как бы это должно работать в "идеальном мире"... Например, вот так.

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

Заявки: в идеале должен быть портал, на котором можно заказать железо и там же указать используемые компоненты платформы и требования к ним: прогнозное число RPS и\или размер хранилища для планирования нагрузки, данные сертификатов для интеграции и прочую информацию, требуемую поставщиком. Возникает вопрос - как быть с тем, что железо нужно для разных стендов - например, сохранять заказ для первого стенда и потом клонировать его для других стендов. Данные заказа попадают в команду платформенной компоненты, а далее они уже сами решают как их обрабатывать - или подключают автоматизацию, или по старинке - руками. Итого получаем систему, которая хранит архитектуру модуля и информацию по полученной инфраструктуре. Причем актуальную информацию, т.к. от нее зависят доступы. Информацию лучше загружать в виде текстовых файлов, все же Infrastructure as Code рулит)

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

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

#it #infrastructure #arch #platform

Всем привет!

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

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

Влияет ли на этот образ массовый найм людей, пришедших за высокой зарплатой? Очевидно, да. Ремарка: я не говорю, что все «вошедшие в ИТ» пришли за длинным рублём. Но очевидно, что массовый найм приводит к росту доли таких людей.
О ком я говорю? Это люди, которые работают строго с 9 до 6. Даже если проект «горит». Не хотят выходить за пределы своих обязанностей, причём обязанностей, как они их поняли. Возможно, не любят или ненавидят свою работу.
К чему это приводит?

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

Что с этим делать?

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

Для остальных я вижу один вариант: отсев на собеседованиях и испытательном сроке по soft skills. То есть и эксперт на собеседовании, и ментор должны плотно работать с новичком. На собеседованиях с этим могут помочь HR-ы. Понятно, могут помочь, а могут и не помочь) Хотя кажется, должны.

P.S. Ещё есть надежда на ChatGPT)

#it #найм

Всем привет!

Учитывая бурный рост AI - в части возможностей и точности ответов - возникает вопрос: что будет с профессией программиста в частности и ИТ-шника в общем?
Пару мыслей по этому поводу.

1) ИТ-шники никуда не денутся - исследовательские задачи по созданию чего-то нового AI не отдашь по определению, аналитику\промты нужно писать, результат - контролировать, AI агенты - кому-то создавать, pipeline - настраивать. Число задач по автоматизации, их сложность растут и похоже будут расти дальше.

Что изменится?

2) Для начала - должна вырасти производительность. Пример: объяснить почему при наличии AI простая формочка делается несколько дней будет сложно. Хочешь - не хочешь, фичей придется выдавать больше. Можно привести аналогию со станками и конвейером - и то, и другое позволило в разы увеличить объем производства. А если брать более близкий нам пример - появление персонального компьютера, на который не надо записываться в очередь и скармливать ему перфокарты - также сильно увеличило производительность программиста. Получаем реально существующий NZT - ускоритель для мозга или bycicle of mind - за напоминание спасибо @AViIgnatov!

3) Со многими вещами из первого пункта можно поспорить - точно ли нельзя человека заменить машиной? Но вот с чем спорить сложно - машина не может нести ответственность. А во многих отраслях - авиация, космос, транспорт в целом, мирный атом, медицина, финансы - отвечать за ошибку кто-то должен. Авторы LLM модели, очевидно, это делать не будут. Иначе условный Сэм Альтман будет не вылезать из судов. Менеджер, внедривший модель тоже - а как он сможет проконтролировать код, созданный моделью? Да, наверняка есть кейсы, когда можно доверить машине и генерацию, и оценку качества кода, а в случае ошибки - просто дообучить модель и перегенерировать код, а клиентам вернуть деньги. Но это, кажется, небольшая часть существующих ИТ систем. Итого - человек нужен, но ответственность его также возрастет. Похожая проблема, кстати, сейчас с автопилотом - там нет LLM (я надеюсь), но вопрос ответственности при аварии при включенном автопилоте пока не решен.

4) интересный вопрос насчет T-Shape vs узкий специалист. С одной стороны узкого специалиста сложнее заменить, особенно, если его фреймворк не очень распространен. С другой стороны рутина отдается на откуп LLM, поэтому от менеджеров будет ожидание горизонтального роста на смежные специализации. Что можно сказать точно - разработчик узкого профиля, умеющий в аналитику, тесты и не боящийся ПРОМа - точно незаменим)

5) Самый интересный момент - что будет с джунами? Т.к. теперь джун должен уметь не только писать промты, но и проверять качество кода. Это либо повышенные требования к ВУЗу\курсам, или растянутая по времени стажировка, во время которой джун должен "обогнать" LLM. Хорошая новость: если вы - джун время прокачаться до сеньора еще есть)

#it #llm

Всем привет!

Вот только написал, что исследовательские задачи — точно не место для AI, как на тебе https://t.me/andre_dataist/172 )))

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

P.S. Ещё интересны 4 и 5 уровень развития моделей из поста выше.

#llm #ai #it

skip level в ИТ

О чем речь? Не о том, как из джуна стать сеньором, не уверен, что это возможно) А об обращении к вышестоящему руководителю.
Причем кейсы могут быть разные, т.к. часто есть две иерархии - продуктовая\проектная и ИТ-ная. PO и ИТ лид. Прожект и тимлид.

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

1) системная проблема в проекте или команде. Тогда "жаловаться" можно и нужно, если проблема будет решена - плюсы в карму и не только в карму)

2) проблема личного развития. Тут есть важная развилка. Она решается следующим вопросом: что я сделал для своего развития?

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

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

#it_career

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

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

Закон Конвея, упомянутый ранее https://t.me/javaKotlinDevOps/301 - структура кода повторяет структуру организации - 1967 год. Практически 60 лет назад.

Спор о вреде go to (а это значит, что он уже активно использовался) начал Дейкстра в письме Go To Statement Considered Harmful практически тогда же - 1968 году. 58 лет назад. Дискуссии, к слову, тогда велись через письма в журналы. В рамках дискуссии о go to понятие спагетти-код стало общепринятым примерно в 1977 году. 49 лет назад.

В 1970 году сотрудник IBM Эдгар Кодд опубликовал статью «A Relational Model of Data for Large Shared Data Banks», которая стала фундаментом для всех реляционных баз данных. В 1979 году появилась первая коммерческая реляционная СУБД Oracle. 56 и 47 лет соответственно.

Мифический человеко-месяц был написан в 1975 году. Знаменитый закон Брукса: добавление разработчиков ближе к концу проекта лишь увеличивает его сроки. А на русский книга была переведена в 1979 году, соответственно, в СССР. Это 51 и 47 лет назад. Я ещё не родился)

Совершенный код (да, опять), первое издание - 1993 год. 33 года назад.

Java 1.0 (еще без collections, не говоря уже и стримах, generic, enum, JDBC и многого другого) появилась в 1996 - 30 лет в этом году.

В 1999 был сформирован DRY («Don't Repeat Yourself» — «Не повторяй себя») Эндрю Хантом и Дэвидом Томасом в книге The Pragmatic Programmer. 27 лет назад. Принцип KISS сильно моложе, но его снимем с дистанции - он появится в ВВС США.

Принципы SOLID были сформулированы на год позже Робертом Мартином в статье Design Principles and Design Patterns. 26 лет назад.

Тогда же вышла книжка Кента Бека про XP (экстремальное программирование, включая TDD). И в 2001 Agile Manifest, который с ним связан.

В 2001 году появилась IDEA и рефакторинг стал доступен всем. Ну почти всем , Community появилась на 8 лет позже и началось ее победное шествие. 25 лет назад.

И лишь Docker, Kafka, DevOps, Kotlin можно считать относительно новыми - 15-20 лет назад. K8s так вообще чуть больше 10 лет.

Т.е. отрасль все же достигла зрелости.

И тут пришёл AI и хочет ее отменить)
Но это уже другая история)

#it_history