Всем привет!
Считается, что есть 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
Считается, что есть 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
Интересная статья с опросом разработчиков https://habr.com/ru/articles/797045/
Что хотелось бы сказать по итогу прочтения.
Тему зарплат я обсуждать не готов, это слишком сложно)
То, что именно джуны склонны приукрашивать свое резюме - ожидаемо.
Процент девушек в ИТ - ну да, ну да, все грустно.
Тот, факт, что в ИТ проходят без профильного высшего образования (или образование было профильным, но преподавали не то) - тоже понятен. Зато с техническим, что тоже понятно.
Интересно то, что таких людей становится больше. Я честно говоря, думал наоборот. Вроде ИТ кафедр больше, чем лет 10-15-20 назад ...
Видимо работает тренд "Войти в ИТ".
Что еще интересно - в более 50% случаев люди, пришедшие после курсов, без опыта, сумели влиться в команду.
Ну и самое интересное - оценка полезности курсов.
Яндекс Практикум - ок.
Хекслет и Karpov.Courses - не слышал, надо бы глянуть.
По крайней мере теперь понятно, куда направлять тех, кто хочет войти в ИТ)
#learning #it
Хабр
Опросил больше 1000 айтишников: вранье в резюме и котируемость курсов по «вкатыванию в IT»
Получилось отследить довольно интересные тренды: как размер стажа в индустрии коррелирует с отношением к выдумыванию опыта в резюме, как в IT-среде на самом деле относятся к выпускникам школ в стиле...
Всем привет!
Периодически на работе приходится сталкиваться с задачей подключения той или иной платформенной компоненты. Платформа у нас большая, компонент много.
С подключением обычно два вида сложностей:
1) изучить кукбук, подключить правильные зависимости и сделать правильные настройки) Зависимости - это очевидно для разработки, а вот настройки - далеко не всегда.
2) административка: завести заявку на подключение - в JIRA, Confluence или даже по почте. Вот это совсем не интуитивно, а ошибки, связанные с отсутствием заявки сложно отлаживать. Оправдывают такой процесс обычно так:
а) что новый потребитель - это дополнительная нагрузка, ее нужно запланировать.
б) требованиями безопасности.
в) просто считается, что это нормально
А хуже, если заявки придется делать на каждый используемый стенд.
Что в итоге? Мыши колются, но едят кактус)
А хочется найти решение, как бы это должно работать в "идеальном мире"... Например, вот так.
Настройки:
а) максимум настроек должны иметь приемлемые значения по умолчанию
б) там, где это невозможно - нужен генератор приложения из каркаса, который сгенерирует шаблон и файл fixme.md с инструкцией как заполнять. Там, где настройки лежат вне приложения - или положить в приложение, или тоже генератор.
Заявки: в идеале должен быть портал, на котором можно заказать железо и там же указать используемые компоненты платформы и требования к ним: прогнозное число RPS и\или размер хранилища для планирования нагрузки, данные сертификатов для интеграции и прочую информацию, требуемую поставщиком. Возникает вопрос - как быть с тем, что железо нужно для разных стендов - например, сохранять заказ для первого стенда и потом клонировать его для других стендов. Данные заказа попадают в команду платформенной компоненты, а далее они уже сами решают как их обрабатывать - или подключают автоматизацию, или по старинке - руками. Итого получаем систему, которая хранит архитектуру модуля и информацию по полученной инфраструктуре. Причем актуальную информацию, т.к. от нее зависят доступы. Информацию лучше загружать в виде текстовых файлов, все же Infrastructure as Code рулит)
Повторюсь - это концепт, при реализации возможны неочевидные на первый взгляд проблемы, т.к. подключаемые компоненты платформы имеют разную архитектуру и требования.
А основная цель предлагаемых изменений - автоматизировать ручной неочевидный труд, и т.об. снизить число ошибок и время на отладку.
#it #infrastructure #arch #platform
Периодически на работе приходится сталкиваться с задачей подключения той или иной платформенной компоненты. Платформа у нас большая, компонент много.
С подключением обычно два вида сложностей:
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 #найм
Я не открою Америку, если скажу, что ИТ-шников не хватает, а поток людей, «входящих в ИТ», растёт. Процесс начался не сегодня. Один из основных стимулов — уровень зарплаты. И у этого процесса есть следствия.
Какой традиционный портрет ИТ-шника? Человек, которому с детства нравятся компьютеры, возможность их настроить, что-то запрограммировать. Готовый сидеть до ночи, решая задачу. Перфекционист, готовый бесконечно улучшать код до идеала. Это не хорошо и не плохо, это типичный ИТ-шник.
Влияет ли на этот образ массовый найм людей, пришедших за высокой зарплатой? Очевидно, да. Ремарка: я не говорю, что все «вошедшие в ИТ» пришли за длинным рублём. Но очевидно, что массовый найм приводит к росту доли таких людей.
О ком я говорю? Это люди, которые работают строго с 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 - в части возможностей и точности ответов - возникает вопрос: что будет с профессией программиста в частности и ИТ-шника в общем?
Пару мыслей по этому поводу.
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
Вот только написал, что исследовательские задачи — точно не место для AI, как на тебе https://t.me/andre_dataist/172 )))
А если серьёзно: в исследованиях тоже есть рутина. И вместо того, чтобы писать скрипты каждый раз — логично поручить «грязную» работу агенту.
P.S. Ещё интересны 4 и 5 уровень развития моделей из поста выше.
#llm #ai #it
Telegram
🤖 Датаист
Deep Research от OpenAI: Прорыв в автоматизации глубоких исследований
Вчера OpenAI представила Deep Research – автономного ИИ-агента, способного самостоятельно проводить многоступенчатые исследования в интернете. Deep Research доступен в тарифе Pro с 100…
Вчера OpenAI представила Deep Research – автономного ИИ-агента, способного самостоятельно проводить многоступенчатые исследования в интернете. Deep Research доступен в тарифе Pro с 100…
skip level в ИТ
О чем речь? Не о том, как из джуна стать сеньором, не уверен, что это возможно) А об обращении к вышестоящему руководителю.
Причем кейсы могут быть разные, т.к. часто есть две иерархии - продуктовая\проектная и ИТ-ная. PO и ИТ лид. Прожект и тимлид.
Т.е. возникает проблема при общении с одним из руководителей и желание пойти к другому. Желание нормальное, но я здесь вижу три кейса.
1) системная проблема в проекте или команде. Тогда "жаловаться" можно и нужно, если проблема будет решена - плюсы в карму и не только в карму)
2) проблема личного развития. Тут есть важная развилка. Она решается следующим вопросом: что я сделал для своего развития?
а) если ответ: я хочу заниматься Х и получить за это У, но злой продакт меня не понимает, пойду к ИТ лиду, чтобы он заставил продакта меня развивать - то это напоминает поведение трехлетнего ребенка. Мама не дала конфетку, пойду к папе. Что делать с ребенком - ничего, ребенок же. Что делать с ИТ-шником - это очень серьезный звоночек на то, что нам с ним не по пути.
б) если же ответ: я сделал уже вот это, учусь, готов учиться еще больше, но все без толку ... - это уже тема для предметного разговора. И опять же плюс в карму.
#it_career
О чем речь? Не о том, как из джуна стать сеньором, не уверен, что это возможно) А об обращении к вышестоящему руководителю.
Причем кейсы могут быть разные, т.к. часто есть две иерархии - продуктовая\проектная и ИТ-ная. PO и ИТ лид. Прожект и тимлид.
Т.е. возникает проблема при общении с одним из руководителей и желание пойти к другому. Желание нормальное, но я здесь вижу три кейса.
1) системная проблема в проекте или команде. Тогда "жаловаться" можно и нужно, если проблема будет решена - плюсы в карму и не только в карму)
2) проблема личного развития. Тут есть важная развилка. Она решается следующим вопросом: что я сделал для своего развития?
а) если ответ: я хочу заниматься Х и получить за это У, но злой продакт меня не понимает, пойду к ИТ лиду, чтобы он заставил продакта меня развивать - то это напоминает поведение трехлетнего ребенка. Мама не дала конфетку, пойду к папе. Что делать с ребенком - ничего, ребенок же. Что делать с ИТ-шником - это очень серьезный звоночек на то, что нам с ним не по пути.
б) если же ответ: я сделал уже вот это, учусь, готов учиться еще больше, но все без толку ... - это уже тема для предметного разговора. И опять же плюс в карму.
#it_career