У нас в компании используется ИИ для категоризации лидов. Реальный процент ошибок на практике в бою: 5-10%. Есть необычная статистика: хуже всего он справляется в понедельник и лучше всего в четверг.
Такой процент ошибок уже позволяет его использовать в действующих бизнес процессах.
А в кейсе из статьи есть шикарный читкод: возможность проверки, корректировки и подтверждения заказа автором - это нивелирует ошибку
Любая ИТ система проектируется так, чтобы падение даже количество сервиса не останавливало бизнес. В данном случае ничто не мешает официанту в условии отсутствия телеграмма/васапа или ИИ, вбить провести заказ вручную через ркипер или 1с или что там под капотом.
Только подумал что идея с выдуманными терминами гениальна, но:
Расскажи пожалуйста про принцип транспортации в ооп
Принцип транспортации в объектно-ориентированном программировании (ООП) не является общепринятым термином. Возможно, вы имеете в виду принцип инкапсуляции, полиморфизма или наследования, которые являются основными принципами ООП.
Я думаю речь о том что линейно по строчке сверху вниз. Программист кожаный пишет код блоками, сначала формируя каркас например функции, а потом пишет её тело; параметры добавляет по ходу дела, а не в самом начале. Короче у бота в момент написания первого уже есть в мозгу весь код целиком до самого последнего символа, а у человека - нет
Крутая задумка. Как я понимаю это аналог directus / stapi. Но для меня ярким жирным стоп фактором является какой-то собственный язык разработки. Извините но нет. Зовите когда добавите поддержку js/python да хотя бы lua/lisp
"Let me take a loo" - нет k "Something's not right with the configuration" - "something isn't..." "Alright, let's roll | Ладно, поехали" тут не столько проблема перевода, сколько проблема IT лексики. У девопсов "roll out" означает "раскатить" обычно в продакшн. И фраза "Let's roll" может быть воспринята как однозначное "выкатывай в прод" а не многозначное "поехали" "Giving it a shot/try | Попробовать" - с ing окончанием это скорее "пробовать" а не "попробовать" но вообще кажется в английском так не говорят. И в примере без ing "Estimates | Сроки" - не правда. "Оценки". В ИТ это радикально разные термины и зачастую даже измеряются в различных единицах. "Deploying the code | Залить код" - опять с временем косяк: "Заливаю код". Но вообще код пушат, а деплоят сервисы, образы и т.п. "Working on the CI/CD pipeline | Работаем над CI/CD конвейером" - не говорят в данном контексте "конвейер" по русски. Либо пайплайн либо уже "Работаем над автоматизацией сборки и доставки". Короче тут как с пушем в продакшн, легче не переводить. "That’s outside the scope of .." это уже какой-то литературный британский (: может я чего не знаю, но в обиходе как за рубежом так и в СНГ "outside OF the scope" или "beyond the scope" но не "outside the scope". А чаще всего вообще просто "Off-scope" "Null | Нулевой/Пустой" и снова косяк понимания специфики/контекста. Null и "пустое" значение различны по смыслу. Но благо, это не обиходная фраза а термин. Тут никто не напутает. "Appliance | Устройство" и снова ошибка понимания специфики/контекста. Software appliance это довольно распространенный термин, которым называют большое количество именно программных продуктов, связанных часто с виртуализацией. Устройство это обычно "Device"
Но вообще ошибок именно смысловых там больше. Многие фразы взяты из обихода вне ИТ, в то время как в ИТ есть более распространённые аналоги.
Да блин. Где конкретика? Как вы используете мдх? Какой у вас гитфлоу, который учитывает и документацию и код? Как именно вы используете плейрайт для создания скриншотов? Куда эти скриншоты попадают? Прямо в документацию? Кто и как с этими скриншотами работает? Что именно вы покрываете документацией? Только компоненты? Что насчёт комплексных фичей, целых экранов, api? Какие ИИ инструменты вы используете для генерации документации? Как вы их используете?
ChatGPT напиши статью про фронтед документацию, состоящую исключительно из воды и эпитетов, не включая ни строчки смысловой нагрузки.
tl;dr я сначала кинул своего работодателя, воспользовавшись служебным положением, увёл заказчика. Затем я по очередно кинул и этого заказчика и ещё одного, прекратив работы не завершив ни этот ни другой параллельный проект. Затем ушёл в тимлиды, потому что эта работа благодарная оплачивает риски деньгами работодателя, а не моими.
У нас в компании используется ИИ для категоризации лидов. Реальный процент ошибок на практике в бою: 5-10%.
Есть необычная статистика: хуже всего он справляется в понедельник и лучше всего в четверг.
Такой процент ошибок уже позволяет его использовать в действующих бизнес процессах.
А в кейсе из статьи есть шикарный читкод: возможность проверки, корректировки и подтверждения заказа автором - это нивелирует ошибку
1с, например, в качестве бекофиса. А статья не про замену 1с или ркипер, а про добавление нового интерфейса взаимодействия на базе ИИ.
Любая ИТ система проектируется так, чтобы падение даже количество сервиса не останавливало бизнес. В данном случае ничто не мешает официанту в условии отсутствия телеграмма/васапа или ИИ, вбить провести заказ вручную через ркипер или 1с или что там под капотом.
По этому на моих интервью ключевым является раздел system design
Справедливости ради, стоит заметить, что ваши старшие коллеги awhoели не проводя кодревью его кода и допустив свинарник в репозитории
Только подумал что идея с выдуманными терминами гениальна, но:
Я думаю речь о том что линейно по строчке сверху вниз. Программист кожаный пишет код блоками, сначала формируя каркас например функции, а потом пишет её тело; параметры добавляет по ходу дела, а не в самом начале. Короче у бота в момент написания первого уже есть в мозгу весь код целиком до самого последнего символа, а у человека - нет
Уже несколько лет бесплатные нейронки на звонках взгляд направляют в монитор и скрывают подглядывание
Знал бы где упадёшь - соломки бы подстелил.
Профессионализм показывается не тем, что компания или человек не допускает ошибок, а тем, как на свои ошибки реагирует.
Крутая задумка. Как я понимаю это аналог directus / stapi. Но для меня ярким жирным стоп фактором является какой-то собственный язык разработки. Извините но нет. Зовите когда добавите поддержку js/python да хотя бы lua/lisp
"Let me take a loo" - нет k
"Something's not right with the configuration" - "something isn't..."
"Alright, let's roll | Ладно, поехали" тут не столько проблема перевода, сколько проблема IT лексики. У девопсов "roll out" означает "раскатить" обычно в продакшн. И фраза "Let's roll" может быть воспринята как однозначное "выкатывай в прод" а не многозначное "поехали"
"Giving it a shot/try | Попробовать" - с ing окончанием это скорее "пробовать" а не "попробовать" но вообще кажется в английском так не говорят. И в примере без ing
"Estimates | Сроки" - не правда. "Оценки". В ИТ это радикально разные термины и зачастую даже измеряются в различных единицах.
"Deploying the code | Залить код" - опять с временем косяк: "Заливаю код". Но вообще код пушат, а деплоят сервисы, образы и т.п.
"Working on the CI/CD pipeline | Работаем над CI/CD конвейером" - не говорят в данном контексте "конвейер" по русски. Либо пайплайн либо уже "Работаем над автоматизацией сборки и доставки". Короче тут как с пушем в продакшн, легче не переводить.
"That’s outside the scope of .." это уже какой-то литературный британский (: может я чего не знаю, но в обиходе как за рубежом так и в СНГ "outside OF the scope" или "beyond the scope" но не "outside the scope". А чаще всего вообще просто "Off-scope"
"Null | Нулевой/Пустой" и снова косяк понимания специфики/контекста. Null и "пустое" значение различны по смыслу. Но благо, это не обиходная фраза а термин. Тут никто не напутает.
"Appliance | Устройство" и снова ошибка понимания специфики/контекста. Software appliance это довольно распространенный термин, которым называют большое количество именно программных продуктов, связанных часто с виртуализацией. Устройство это обычно "Device"
Но вообще ошибок именно смысловых там больше. Многие фразы взяты из обихода вне ИТ, в то время как в ИТ есть более распространённые аналоги.
Если бы мне девопс написал "let's dive dear" - я бы напрягся 😅
Юля, ты же крутая! Вот нонейму из интернета было лень все косяки таблицы приводить, но для тебя времени не пожалею - сделаю полноценный ревью.
Судя по качеству - составлял школьник который DevOps по телеку видел. Ошибка на ошибке.
Больше всего доставило:
Let’s dive dear - Давайте посмотрим поподробнее.
Да и в я пиарюсь не подходит. Там пиарятся ИТ проекты, а не игры для школьников
Только для тех кто не умеет их готовить
В большинстве случаев это как раз и является первым шагом в микросервисы.
Но не каждый монолит так запустишь. А доевнючий легаси развившийся эволюционными скачками (а так скорее всего и было) тем более.
Во первых Не путайте SaaS и виртуальные сервера в облаке. Во вторых облако может быть своим (у гигантов вроде х5 наверняка такое).
Да блин. Где конкретика? Как вы используете мдх? Какой у вас гитфлоу, который учитывает и документацию и код? Как именно вы используете плейрайт для создания скриншотов? Куда эти скриншоты попадают? Прямо в документацию? Кто и как с этими скриншотами работает? Что именно вы покрываете документацией? Только компоненты? Что насчёт комплексных фичей, целых экранов, api? Какие ИИ инструменты вы используете для генерации документации? Как вы их используете?
ChatGPT напиши статью про фронтед документацию, состоящую исключительно из воды и эпитетов, не включая ни строчки смысловой нагрузки.
tl;dr я сначала кинул своего работодателя, воспользовавшись служебным положением, увёл заказчика. Затем я по очередно кинул и этого заказчика и ещё одного, прекратив работы не завершив ни этот ни другой параллельный проект. Затем ушёл в тимлиды, потому что эта работа
благодарнаяоплачивает риски деньгами работодателя, а не моими.Кажется ничего не пропустил