Эх, когда-то предлагал все секьюрные компании сделать страховыми, чтобы была ответственность с обеих сторон (размер страховки или даже вообще отказ определяет регламент секьюрной компании). А сейчас - выпустили "антивирус", взяли деньги за него, но ничего не гарантируют и никаких "убытков" за некачественное предоставление услуги не несут. А то по такой аналогии можно перебрасывать на любой вид деятельности - "вот вам самолет - он летает, но если упадет по тех причине - мы не виноваты". Что-то в IT мало ответственности.
"Интеграция функций искусственного интеллекта в сервисы" позволяет тех. директору, тимлиду и команде разработчиков поучиться интегрировать эти сервисы.
Банально - ни один «трюк» не сработает, если сам продукт не решает проблему пользователя, НО привлечение пользователей != удержание пользователей. Для "долгосрочного удержания пользователей" нужно решать долгосрочные проблемы пользователей.
различие между методом at и operator[] у std::vector
изменения порядка циклов с ijk на ikj
Все бы хорошо, да вот только когда речь идет о перфомансе - примеры есть? Где микросекунды? Верить на слово?
В статье опишу "набор новичка"
Есть упоминание об инструменте - нет примера использования. С одной стороны какие-то уж очень общие знания, с другой - переключение на "углубленные" нюансы С++.
Все что есть физически - можно отобрать рэкетом. А вот "рэкет" для телеги в виде макса не пошел - но не унывают - эксперименты во всех направлениях ставят каждый день.
Эволюцию, как и революцию не остановить. Многое в GPL мне не нравится - MIT лучше, но человеческая натура такова, что есть положительные и отрицательные стороны - GPL борется с отрицательными, MIT для альтруистов.
Простота всегда в почете только для того, чьи цели она преследует. Все различие будет в мотивации, если мотивация "повышение", то "простота" теряет свои плюсы. "Адекватность" в подавляющем большинстве компаний не является мотивацией.
В целом согласен - индустрия одурманенна дешевым успехом. Безответственность (слепое доверие машине) в сочетании с мощным инструментом.
С одной стороны: неконтролируемая генерация, как и неконтролируемое написание кода людьми (люди пишут не лучше) - это всегда плохо. Другое дело если говорить о скорости его генерации, которая превышает скорость качественного ревью. ИИ должен писать атомарные функции (ИИ — компилятор), человек — собирать из них систему. Должно действовать правило: «Ты не автор кода, но ты его ответственный».
С другой стороны: люди любят ленится - это заложено в "природой". Даже крутой стартап через две остановки от твоего дома, проиграет стартапу рядом с твоим домом. Не списывайте "природу" человека - он тоже не "белый и пушистый" в данной ситуации.
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 как неприменимый — что неправильно в последнем случае. Эту метрику сложнее внедрить в инженерный контур, но она критически важна.
Некоторые метрики скорее про технический долг, а не про качество продукта.
Эх, когда-то предлагал все секьюрные компании сделать страховыми, чтобы была ответственность с обеих сторон (размер страховки или даже вообще отказ определяет регламент секьюрной компании). А сейчас - выпустили "антивирус", взяли деньги за него, но ничего не гарантируют и никаких "убытков" за некачественное предоставление услуги не несут. А то по такой аналогии можно перебрасывать на любой вид деятельности - "вот вам самолет - он летает, но если упадет по тех причине - мы не виноваты". Что-то в IT мало ответственности.
Отличная тема для статьи кстати.
"Интеграция функций искусственного интеллекта в сервисы" позволяет тех. директору, тимлиду и команде разработчиков поучиться интегрировать эти сервисы.
Банально - ни один «трюк» не сработает, если сам продукт не решает проблему пользователя, НО привлечение пользователей != удержание пользователей. Для "долгосрочного удержания пользователей" нужно решать долгосрочные проблемы пользователей.
Все бы хорошо, да вот только когда речь идет о перфомансе - примеры есть? Где микросекунды? Верить на слово?
Есть упоминание об инструменте - нет примера использования. С одной стороны какие-то уж очень общие знания, с другой - переключение на "углубленные" нюансы С++.
Ну не только одним Atlassian живет рынок - когда то использовал https://trac.edgewall.org/ на питоне и очень быстро интегрируются многие вещи.
Давно уже не читал статьи в которых чувствуется "теплота" написавшего ее человека. Читается на одном дыхании. Спасибо.
Если основывать рабочие процессы на архитектуре, а не на конечном полезном результате, то они не смогут ни эффективно масштабироваться, ни обучаться, ни адаптироваться. см. От картинки к системе разработки проектов. Фундамент под ногами
Delicias habet omne suas et gaudia tempus.
Все что есть физически - можно отобрать рэкетом. А вот "рэкет" для телеги в виде макса не пошел - но не унывают - эксперименты во всех направлениях ставят каждый день.
Эволюцию, как и революцию не остановить. Многое в GPL мне не нравится - MIT лучше, но человеческая натура такова, что есть положительные и отрицательные стороны - GPL борется с отрицательными, MIT для альтруистов.
Простота всегда в почете только для того, чьи цели она преследует. Все различие будет в мотивации, если мотивация "повышение", то "простота" теряет свои плюсы. "Адекватность" в подавляющем большинстве компаний не является мотивацией.
В целом согласен - индустрия одурманенна дешевым успехом. Безответственность (слепое доверие машине) в сочетании с мощным инструментом.
С одной стороны: неконтролируемая генерация, как и неконтролируемое написание кода людьми (люди пишут не лучше) - это всегда плохо. Другое дело если говорить о скорости его генерации, которая превышает скорость качественного ревью. ИИ должен писать атомарные функции (ИИ — компилятор), человек — собирать из них систему. Должно действовать правило: «Ты не автор кода, но ты его ответственный».
С другой стороны: люди любят ленится - это заложено в "природой". Даже крутой стартап через две остановки от твоего дома, проиграет стартапу рядом с твоим домом. Не списывайте "природу" человека - он тоже не "белый и пушистый" в данной ситуации.
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 как неприменимый — что неправильно в последнем случае. Эту метрику сложнее внедрить в инженерный контур, но она критически важна.
Некоторые метрики скорее про технический долг, а не про качество продукта.