В целом согласен - индустрия одурманенна дешевым успехом. Безответственность (слепое доверие машине) в сочетании с мощным инструментом.
С одной стороны: неконтролируемая генерация, как и неконтролируемое написание кода людьми (люди пишут не лучше) - это всегда плохо. Другое дело если говорить о скорости его генерации, которая превышает скорость качественного ревью. ИИ должен писать атомарные функции (ИИ — компилятор), человек — собирать из них систему. Должно действовать правило: «Ты не автор кода, но ты его ответственный».
С другой стороны: люди любят ленится - это заложено в "природой". Даже крутой стартап через две остановки от твоего дома, проиграет стартапу рядом с твоим домом. Не списывайте "природу" человека - он тоже не "белый и пушистый" в данной ситуации.
SSD без raid1 на "продакшн" - путь к простоям и, возможно, к потери данных. Есть небольшое смешивание факторов риска - хранение в плохих условиях (износ + тепло + время + коррозия платы + повреждения контактов или контроллера) vs физика памяти. По физике еще добавлю в TLC/QLC плотность ячеек такова, что заряд одной ячейки может влиять на соседнюю (cell-to-cell interference). Это важный фактор деградации данных, отличный от простого «утекания». Было бы круто иметь формулу расчета риска по годам (месяцам) выхода из строя исходя из условий работы и физики ssd.
Дела нас характеризуют больше чем умение об этом говорить. Для статьи о построении карьеры в ИБ, в тексте очень мало технического контекста. Без конкретики путь «от рядового специалиста до BISO» выглядит слишком гладким и «волшебным».
Если убрать из текста слово «девушка» и поменять концовку заголовка, статья станет отличным гайдом для любого интроверта или специалиста, который чувствует себя недостаточно уверенно в корпоративной среде. Пол здесь вторичен.
«Мужчины склонны к риску, женщины — к анализу последствий»
В ИБ и риск-менеджменте нужны обе компетенции в одном специалисте. Это тот стереотип, с которым статья пытается бороться, зачем подчеркивать это деление?
В примере с виноградом бизнес-логика складского учета почему-то переложена на очередь FIFO - неудачный пример. Какой именно виноград взять со стеллажа (понедельника или вторника) решает же не очередь сообщений.
В примере с банком - если у нас 10 млн пользователей, нам не нужно выстраивать операции Васи в очередь перед операциями Пети. Т.е. строгий глобальный FIFO редко нужен. Нужна консистентность в рамках одной сущности (аккаунта пользователя), т.е. "простой" будет только по user_id. Уточню - Kafka гарантирует порядок только при условии, что потребитель не читает сообщения параллельно из одной партиции (число консюмеров <= числа партиций).
А в целом, спасибо, идея масштабируемости - это правильный способ выявить требования и аргумент, который можно приводить заказчикам.
Общее правило такое: юнит-тесты должны проверять «что» делает код, а не «как» он это делает.
Может я что-то путаю, но юнит-тесты это про «как» и про миллисекунды, а acceptance тесты это про «что».
Игнорирование производительности - запуск сервисных тестов с реальными базами и брокерами занимает секунды и минуты. В примере с Order и Shipping общительный тест выглядит идеально. Но стоит добавить в Shipping зависимость от внешнего сервиса (БД, API), как «общительный» юнит-тест превращается в интеграционный (или требует моков, что Вы сами и ругаете далее по статье). Примеры подгонялись под желаемый вывод.
Вы пытаетесь продать одну крайность (общительные тесты) за счет очернения другой (одиночные тесты), используя для этого манипулятивные примеры и подмену понятий (назвав смену API «рефакторингом»).
В дополнение к мотивации QA-инженера - заказчик и инвестор тоже своего рода QA-инженер. Я реально удивился результату, когда инвестор в одном из стартапов сам же устроился QA-инженером - очень классный опыт и по скорости разработки и по фидбэку в обе стороны. Берите лайфхак.
Статьи, видео про индивидуализацию ИИ я вижу тут и там, однако есть проблема - отсутствие проверки фактов и сложности настройки. «железобетонное встречное предложение», сгенерированное ИИ за 4 часа, потребует не меньше времени на вычитку, чем классическая работа младшего юриста, просто фокус сместится с поиска на проверку - ссылка на несуществующий прецедент может стоить миллионы.
В контексте скажу, рядом с продвижением идеи индивидуализации ИИ, я всегда почему-то вижу продвижение конкретного сервиса в конце - маркетинг для глупых - таких на хабре нет.
"современный менеджер файлов, и куда ему стоит двигаться"
Если брать мотивацию пользователя far2l, то скорее всего это будет звучать так:
первоначальное изучение (осмотр "потрохов") и настройка "непродакшн" проектов, где setup еще не предусмотрен;
поправить что-то вручную там где "скрипты" или заточенная под это UI не справляется, сюда в том числе входит поправка систем сборки и исходников;
быстрый ручной поиск-просмотр по проекту в том числе на удаленной машине, чтобы не утруждать себя синтаксисом команд find, grep, less, vim и прочих - так сказать решение нештатных ситуаций, когда точно не известна где проблема;
естественно любое копирование, работа с "громадными" файлами, смена атрибутов и т.п в том числе по сети;
интерактивная работа с архивами;
Где вряд ли будет использоваться (естественно есть гики):
просмотр, создание и редактирование медиа-контента, презентаций (я исключу быстрый просмотр из этого списка);
пользователи начального уровня скажем так - те которые в основном используют мышь;
разработка ПО с графикой и развитой визуальной составляющей.
Т.о. куда стоит двигаться глобально:
Максимум Portable - минимальный набор зависимостей. Минимальный размер и максимальная скорость работы - вообще идеально один файл как в go. Скачал через wget на удаленную машину (или запустил "с флешки") - работаешь.
Плагины отдельно от far2l. Во-первых установка только нужных, может быть какой нибудь менеджер плагинов сделать. Во-вторых иногда плагин больше и сложнее по коду может быть чем сам far2l - поддержка "в куче" сложна. В идеале вообще выделить Far2l SDK отдельно.
Максимальное использование утилит из "никсов" или "макоси", а не свои "протезы" - авторы утилит часто лучше решают задачи - например копирование по rsync и т.п. far2l будет выступать "графической" оболочкой над ними.
В целом статья рассматривает качество не как на «поимку багов», а как на систему управления процессами - что гуд, но есть терминологическая путаница с Cycle Time и Lead Time. Lead Time — это время от возникновения потребности (заказ клиентом) до удовлетворения потребности (delivery). Это «время клиента». Cycle Time — это время, когда задача находится в работе команды (от момента, когда команда взяла задачу в работу, до момента готовности). Это «время команды».
Финальная оценка качества глазами заказчика и финальная оценка качества глазами пользователя — разные. Ваше замечание, что можно советовать «отбрасывать» NPS как неприменимый — что неправильно в последнем случае. Эту метрику сложнее внедрить в инженерный контур, но она критически важна.
Некоторые метрики скорее про технический долг, а не про качество продукта.
В целом мотивация автора понятна - он хочет гордиться своей страной, которая смогла... А вот какая мотивация у разработчиков этого самого ИИ я не вижу этого в статье.
"Другой вопрос, не стоит требовать от нее сопоставимого с нейросетями за миллиарды долларов уровня" - Почему? Может как раз стоит сразу ставить уровень выше, чем у аналогов. Может хватит искать причины почему нельзя ($, просто численность населения, количество потребителей и т.п.) и начать двигаться вперед?
Чай, который умеет думать. Этот чай, оказывается, обладает сознанием! Он понимает, когда его пьют, и запоминает вкус!. Неправильная технология заваривания. В целом по аналогии ко всей статье: Чай можно пить, но рецепт лучше читать в оригинале.
Часто для разработчика "признание" - это мотивация открыть код, т.е. какими мы ни были белыми и пушистыми, все же "корысть" присутствует.
В статье есть некоторые недочеты:
Open source не всегда означает что код доступен для изменения и распространения.
открытый исходный код != открытые стандарты. Даже в полностью закрытом мире стандарты могут существовать и публиковаться. Например без открытого кода не исчезнет и документация к протоколам.
"Любой бэкдор или баг может быть обнаружен сообществом" - давайте вспомним Heartbleed, Log4j, в противовес замечу аудит в закрытом коде тоже проводится и Bug Bounty программы есть - что эффективнее - не скажу, да и исследований таких не знаю. Утверждать, что в закрытом мире проверки «невозможны», некорректно. Но соглашусь - пользователь вынужден верить вендору - это верно.
без open source будущие инженеры вынуждены полагаться на сухую документацию. Тоже возражение - программисты учились и в 70-80-е годы, когда код часто был закрыт или написан на перфокартах/ассемблере, и это порождало сильных инженеров, понимающих «низкий уровень».
"MVP становится роскошью" - не все однозначно. Для того чтобы «подсадить» экосистему и на свои платные решения корпорации предоставляют базовые инструменты (IDE, компиляторы, базы данных начального уровня) бесплатно или предустановленными - MVP может быть не роскошью, а вот продакшн решения да.
LLM и обучение нейросетей - несмотря на доступность контента, на сейчас нанимаются специалисты для файнтюнинга моделей.
В целом статья написана как «продающий текст» для идеи open source, что неизбежно ведет к предвзятости и сгущению красок. В целом мир немного разнообразнее и несовершеннее, что-то должно быть закрытым - например, разработка оружия.
Должна быть равносильная ответственность работника перед компанией и компании перед работником. Вы нанимаете работника для решение Ваших задач лучше Вас, в Вашей компании с Вашими работниками и достижение долгосрочноного роста продукта. Почему тогда Вашу "первую" задачу "Интеграция с API регионального перевозчика" не дать в качестве проверки (под NDA конечно)? Причем здесь "обход дерева" и "адаптированный алгоритм Bellman-Ford". Если ему пофиг на компанию (он пришел только за $) - завтра уйдет, если пофиг на коллектив - коммуникацию как тестировать? Да и умение смотреть на продукт глазами - как это проверить без конкретной задачи специфичной для компании?
Т.е. изначально автор статьи не подготовился сам к найму - об этом решил умолчать.
Все развивается очень быстро, но за развитием LLM, даже сейчас, по прежнему стоит человек (т.е. до AGI еще далеко). В любом случае, на сейчас у ИИ отсутствует мотивация и плохо с фидбэком, но когда эти фитчи протезируют извне (либо кодом, либо навыками и опытом) - заменять программистов он уже умеет, а девелоперов еще нет.
Если первую и последнюю приходится поддерживать, то что касается развития - тут приходится бороться с энергетическими затратами мозга. Статья скорее про осознание дефицита развития и признания в социуме. Так сказать переход от состояния дефицита к направленной активности. Автор вроде говорит простые вещи, но они касаются больше выживания и гомеостаза (и это конечно база и тут легко найти мотивацию), а вот как найти мотивацию для развития в статье проскакивают пункты:
Признать состояние без осуждения
Мини-аудит потребностей
Запланировать "награду за процесс"
Создать мгновенную обратную связь
Упростить цель до "минимально жизнеспособного действия" (Пример: не "выучить архитектуру", а "прочитать 1 статью 15 минут")
Добавлю к статье небольшой лайф-хак - я купил себе песочные часы (несколько от 5 до 30 мин) и использую их как якорь, когда нужно тренировать внимание.
А с чего бы это Revolut вдруг "занялся" - Telegram? Может потому, что у Revolut недостаточно все хорошо с безопасностью или им коммерчески выгоден запрет телеги? Вопросов как всегда больше, чем ответов. Как всегда запретами оправдывают свою несостоятельность в области безопасности или коммерческую выгоду.
Джунов берут и будут брать молодых, красивых коммуникабельных и перспективных. Это основные требования - всем правят либо инстинкты "нанимающих", либо лень. Остальное - не столь важно. Всем остальным повышать уровень до мидла и выше.
В целом согласен - индустрия одурманенна дешевым успехом. Безответственность (слепое доверие машине) в сочетании с мощным инструментом.
С одной стороны: неконтролируемая генерация, как и неконтролируемое написание кода людьми (люди пишут не лучше) - это всегда плохо. Другое дело если говорить о скорости его генерации, которая превышает скорость качественного ревью. ИИ должен писать атомарные функции (ИИ — компилятор), человек — собирать из них систему. Должно действовать правило: «Ты не автор кода, но ты его ответственный».
С другой стороны: люди любят ленится - это заложено в "природой". Даже крутой стартап через две остановки от твоего дома, проиграет стартапу рядом с твоим домом. Не списывайте "природу" человека - он тоже не "белый и пушистый" в данной ситуации.
SSD без raid1 на "продакшн" - путь к простоям и, возможно, к потери данных. Есть небольшое смешивание факторов риска - хранение в плохих условиях (износ + тепло + время + коррозия платы + повреждения контактов или контроллера) vs физика памяти. По физике еще добавлю в TLC/QLC плотность ячеек такова, что заряд одной ячейки может влиять на соседнюю (cell-to-cell interference). Это важный фактор деградации данных, отличный от простого «утекания». Было бы круто иметь формулу расчета риска по годам (месяцам) выхода из строя исходя из условий работы и физики ssd.
Дела нас характеризуют больше чем умение об этом говорить. Для статьи о построении карьеры в ИБ, в тексте очень мало технического контекста. Без конкретики путь «от рядового специалиста до BISO» выглядит слишком гладким и «волшебным».
Если убрать из текста слово «девушка» и поменять концовку заголовка, статья станет отличным гайдом для любого интроверта или специалиста, который чувствует себя недостаточно уверенно в корпоративной среде. Пол здесь вторичен.
В ИБ и риск-менеджменте нужны обе компетенции в одном специалисте. Это тот стереотип, с которым статья пытается бороться, зачем подчеркивать это деление?
В примере с виноградом бизнес-логика складского учета почему-то переложена на очередь FIFO - неудачный пример. Какой именно виноград взять со стеллажа (понедельника или вторника) решает же не очередь сообщений.
В примере с банком - если у нас 10 млн пользователей, нам не нужно выстраивать операции Васи в очередь перед операциями Пети. Т.е. строгий глобальный FIFO редко нужен. Нужна консистентность в рамках одной сущности (аккаунта пользователя), т.е. "простой" будет только по user_id. Уточню - Kafka гарантирует порядок только при условии, что потребитель не читает сообщения параллельно из одной партиции (число консюмеров <= числа партиций).
А в целом, спасибо, идея масштабируемости - это правильный способ выявить требования и аргумент, который можно приводить заказчикам.
Может я что-то путаю, но юнит-тесты это про «как» и про миллисекунды, а acceptance тесты это про «что».
Игнорирование производительности - запуск сервисных тестов с реальными базами и брокерами занимает секунды и минуты. В примере с Order и Shipping общительный тест выглядит идеально. Но стоит добавить в Shipping зависимость от внешнего сервиса (БД, API), как «общительный» юнит-тест превращается в интеграционный (или требует моков, что Вы сами и ругаете далее по статье). Примеры подгонялись под желаемый вывод.
Вы пытаетесь продать одну крайность (общительные тесты) за счет очернения другой (одиночные тесты), используя для этого манипулятивные примеры и подмену понятий (назвав смену API «рефакторингом»).
В дополнение к мотивации QA-инженера - заказчик и инвестор тоже своего рода QA-инженер. Я реально удивился результату, когда инвестор в одном из стартапов сам же устроился QA-инженером - очень классный опыт и по скорости разработки и по фидбэку в обе стороны. Берите лайфхак.
Статьи, видео про индивидуализацию ИИ я вижу тут и там, однако есть проблема - отсутствие проверки фактов и сложности настройки. «железобетонное встречное предложение», сгенерированное ИИ за 4 часа, потребует не меньше времени на вычитку, чем классическая работа младшего юриста, просто фокус сместится с поиска на проверку - ссылка на несуществующий прецедент может стоить миллионы.
В контексте скажу, рядом с продвижением идеи индивидуализации ИИ, я всегда почему-то вижу продвижение конкретного сервиса в конце - маркетинг для глупых - таких на хабре нет.
Если брать мотивацию пользователя far2l, то скорее всего это будет звучать так:
первоначальное изучение (осмотр "потрохов") и настройка "непродакшн" проектов, где setup еще не предусмотрен;
поправить что-то вручную там где "скрипты" или заточенная под это UI не справляется, сюда в том числе входит поправка систем сборки и исходников;
быстрый ручной поиск-просмотр по проекту в том числе на удаленной машине, чтобы не утруждать себя синтаксисом команд find, grep, less, vim и прочих - так сказать решение нештатных ситуаций, когда точно не известна где проблема;
естественно любое копирование, работа с "громадными" файлами, смена атрибутов и т.п в том числе по сети;
интерактивная работа с архивами;
Где вряд ли будет использоваться (естественно есть гики):
просмотр, создание и редактирование медиа-контента, презентаций (я исключу быстрый просмотр из этого списка);
пользователи начального уровня скажем так - те которые в основном используют мышь;
разработка ПО с графикой и развитой визуальной составляющей.
Т.о. куда стоит двигаться глобально:
Максимум Portable - минимальный набор зависимостей. Минимальный размер и максимальная скорость работы - вообще идеально один файл как в go. Скачал через wget на удаленную машину (или запустил "с флешки") - работаешь.
Плагины отдельно от far2l. Во-первых установка только нужных, может быть какой нибудь менеджер плагинов сделать. Во-вторых иногда плагин больше и сложнее по коду может быть чем сам far2l - поддержка "в куче" сложна. В идеале вообще выделить Far2l SDK отдельно.
Максимальное использование утилит из "никсов" или "макоси", а не свои "протезы" - авторы утилит часто лучше решают задачи - например копирование по rsync и т.п. far2l будет выступать "графической" оболочкой над ними.
В целом статья рассматривает качество не как на «поимку багов», а как на систему управления процессами - что гуд, но есть терминологическая путаница с Cycle Time и Lead Time. Lead Time — это время от возникновения потребности (заказ клиентом) до удовлетворения потребности (delivery). Это «время клиента». Cycle Time — это время, когда задача находится в работе команды (от момента, когда команда взяла задачу в работу, до момента готовности). Это «время команды».
Финальная оценка качества глазами заказчика и финальная оценка качества глазами пользователя — разные. Ваше замечание, что можно советовать «отбрасывать» NPS как неприменимый — что неправильно в последнем случае. Эту метрику сложнее внедрить в инженерный контур, но она критически важна.
Некоторые метрики скорее про технический долг, а не про качество продукта.
В погоне за эффективностью мы рискуем потерять фундамент под ногами
В целом мотивация автора понятна - он хочет гордиться своей страной, которая смогла... А вот какая мотивация у разработчиков этого самого ИИ я не вижу этого в статье.
"Другой вопрос, не стоит требовать от нее сопоставимого с нейросетями за миллиарды долларов уровня" - Почему? Может как раз стоит сразу ставить уровень выше, чем у аналогов. Может хватит искать причины почему нельзя ($, просто численность населения, количество потребителей и т.п.) и начать двигаться вперед?
Чай, который умеет думать. Этот чай, оказывается, обладает сознанием! Он понимает, когда его пьют, и запоминает вкус!. Неправильная технология заваривания. В целом по аналогии ко всей статье: Чай можно пить, но рецепт лучше читать в оригинале.
Часто для разработчика "признание" - это мотивация открыть код, т.е. какими мы ни были белыми и пушистыми, все же "корысть" присутствует.
В статье есть некоторые недочеты:
Open source не всегда означает что код доступен для изменения и распространения.
открытый исходный код != открытые стандарты. Даже в полностью закрытом мире стандарты могут существовать и публиковаться. Например без открытого кода не исчезнет и документация к протоколам.
"Любой бэкдор или баг может быть обнаружен сообществом" - давайте вспомним Heartbleed, Log4j, в противовес замечу аудит в закрытом коде тоже проводится и Bug Bounty программы есть - что эффективнее - не скажу, да и исследований таких не знаю. Утверждать, что в закрытом мире проверки «невозможны», некорректно. Но соглашусь - пользователь вынужден верить вендору - это верно.
без open source будущие инженеры вынуждены полагаться на сухую документацию. Тоже возражение - программисты учились и в 70-80-е годы, когда код часто был закрыт или написан на перфокартах/ассемблере, и это порождало сильных инженеров, понимающих «низкий уровень».
"MVP становится роскошью" - не все однозначно. Для того чтобы «подсадить» экосистему и на свои платные решения корпорации предоставляют базовые инструменты (IDE, компиляторы, базы данных начального уровня) бесплатно или предустановленными - MVP может быть не роскошью, а вот продакшн решения да.
LLM и обучение нейросетей - несмотря на доступность контента, на сейчас нанимаются специалисты для файнтюнинга моделей.
В целом статья написана как «продающий текст» для идеи open source, что неизбежно ведет к предвзятости и сгущению красок. В целом мир немного разнообразнее и несовершеннее, что-то должно быть закрытым - например, разработка оружия.
C++ настолько сложный, что даже LLM "стреляет себе в ногу".
По идее нужен Кен Томпсон и аналог Go, который заменил C++.
Должна быть равносильная ответственность работника перед компанией и компании перед работником. Вы нанимаете работника для решение Ваших задач лучше Вас, в Вашей компании с Вашими работниками и достижение долгосрочноного роста продукта. Почему тогда Вашу "первую" задачу "Интеграция с API регионального перевозчика" не дать в качестве проверки (под NDA конечно)? Причем здесь "обход дерева" и "адаптированный алгоритм Bellman-Ford". Если ему пофиг на компанию (он пришел только за $) - завтра уйдет, если пофиг на коллектив - коммуникацию как тестировать? Да и умение смотреть на продукт глазами - как это проверить без конкретной задачи специфичной для компании?
Т.е. изначально автор статьи не подготовился сам к найму - об этом решил умолчать.
Все развивается очень быстро, но за развитием LLM, даже сейчас, по прежнему стоит человек (т.е. до AGI еще далеко). В любом случае, на сейчас у ИИ отсутствует мотивация и плохо с фидбэком, но когда эти фитчи протезируют извне (либо кодом, либо навыками и опытом) - заменять программистов он уже умеет, а девелоперов еще нет.
Наши потребности довольно просты:
Выживания (биологические потребности)
Развития (социальные, когнитивные потребности)
Гомеостаза (поддержания баланса)
Если первую и последнюю приходится поддерживать, то что касается развития - тут приходится бороться с энергетическими затратами мозга. Статья скорее про осознание дефицита развития и признания в социуме. Так сказать переход от состояния дефицита к направленной активности. Автор вроде говорит простые вещи, но они касаются больше выживания и гомеостаза (и это конечно база и тут легко найти мотивацию), а вот как найти мотивацию для развития в статье проскакивают пункты:
Признать состояние без осуждения
Мини-аудит потребностей
Запланировать "награду за процесс"
Создать мгновенную обратную связь
Упростить цель до "минимально жизнеспособного действия" (Пример: не "выучить архитектуру", а "прочитать 1 статью 15 минут")
Добавлю к статье небольшой лайф-хак - я купил себе песочные часы (несколько от 5 до 30 мин) и использую их как якорь, когда нужно тренировать внимание.
А с чего бы это Revolut вдруг "занялся" - Telegram? Может потому, что у Revolut недостаточно все хорошо с безопасностью или им коммерчески выгоден запрет телеги? Вопросов как всегда больше, чем ответов. Как всегда запретами оправдывают свою несостоятельность в области безопасности или коммерческую выгоду.
Джунов берут и будут брать молодых, красивых коммуникабельных и перспективных. Это основные требования - всем правят либо инстинкты "нанимающих", либо лень. Остальное - не столь важно. Всем остальным повышать уровень до мидла и выше.