Когда клиент добавляет товар - мы сразу его резервируем. Товар остаётся заблокированным. Если клиент не оформляет заказ - товар возвращается на склад.
Это плохое решение. "Заабьюзить" сервис можно запросто. К примеру, я сделаю скрипт, который каждые 15 минут тупо добавляет товар обратно в корзину. У других практически нет шансов тогда купить товар. Если резервировать на этапе оформление заказа, то тут надо рассмотреть этот же вариант, к примеру, самое примитивное решение - при отказе или таймауте оплаты, позволять перейти к новому оформлению заказа не ранее, чем через 5 минут.
Сразу списать товар при отправке заказа, чтобы он не разблокировался
Это не понял, что значит. То есть, еще на заплатили, а товар уже списан? Тогда однозначно - нет.
Ввиду вышесказанного, я бы процесс сделал так: 1. Добавляются товары в корзину с обновлением доспупности для ранее добавленных и соответствующими предупреждениями. 2. Переход к оформлению заказа - тут происходит резервирование товаров на 15 мин (если доступны все еще, если нет, то предупреждать в соответствии). 3. Списание товаров только по факту оплаты, то есть по нажатию на кнопку "оплатить". Причем учесть процесс продолжения действия, если оплата и списание не выполняются атомарно и произошла ошибка. То есть чтобы не получилось так, что оплата произведена, а списание не произошло, и наоборот. Тут можно придумать много чего, к примеру, сохранять идентификатор сеанса оформления заказа и при повторной попытке проверять что было реально сделано. 4. Если опалата не была произведена по таймауту или заказ был отменен, добавить таймаут на новое оформление. Добавлять товары тем не менее можно.
Ну я пишу лет 8 в том числе и на питоне, и сходу тем не менее затруднился с ответом на {("a", [1, 2]): "value"} и print((x for x in range(3))). А за 55 == True is True надо сразу бить по рукам на месте. Наверное, я не знаю базу? Или просто в нормальных условиях такую дичь на код ревью не пропускают, и вообще такое в голову не приходит? Питон, скажем так, довольно специфичный язык, а автор, видимо, нанимался загадывать ребусы и выводить на чисту воду этих наглых "накрутчиков". Я вот смотрю больше на способность кандидата мыслить, коммуницировать, рассуждать и предлагать варианты, что куда важнее, чем знание 100+ подводных камней питона. И в качестве теста на написание кода идут самые обычные кейсы.
Парад продолжается. После фиаско с первой версией этого, хм, "компилятора", а так же после его разбора, автор еще 8 месяцев пушил добавление/удаление строки в readme с целью создать видимость работы. Почти незамеченной протухла и вторая версия, краткий разбор которой был тут. Но автор не стоит на месте, радуя нас своим прогрессом, его даже не смущают 13 минусов под предыдущей статьей. Взлетит ли третья версия? Сомнительно. Видно, что автор явно не дурак, но нарциссизм не лучший спутник на этом пути.
Пустой треп в большей части. Понятно, что это интервью, однако...
Сейчас самое волнительное — это рост автономности ИИ-систем. Всё чаще инструменты, тот же Deep Research, выдают ответ в том виде, в котором его можно сразу использовать.
Тут точно имелась в виду автономность?
здоровенный чатик
Звучит прикольно.
..., выходит вперед LongChain, известная библиотека, которая адаптируется к фреймворкам.
LangChain?
Вообще, сейчас происходит такой ползучий процесс переизобретения процесса разработки.
Ползучий процесс и переизобретение, да-да. Это называют "эволюцией" обычно.
какие джабы выполняют инженеры
Это что такое? Джабба Хатт?
Например, возьмем кейс с проблемными активами: вы звоните должнику, что-то не то сказали — вам сразу штраф 500 тысяч прилетает от ФССП
Конгениальный и актульный пример и практики использования ИИ - работа звонаря-выбивателя долгов. Ах, это же банк, тогда норм.
В последнее время, на мой взглад, складывается впечатние о какой-то эпидемии словесного поноса среди подобных спикеров. Может быть, я слишком придирчив.
Тогда я предложил коммерческому директору вместе использовать нейросеть для анализа ситуации.
Когда есть только молоток, вокруг все кажется гвоздями.
Это время, которое коммерческий директор потратил на то, чтобы обучить ИИ, дать ему полное представление о бизнесе.
"Обучение" тут - это двухдневная болтовня с чатом?
Сначала ИИ предложил уволить одного бухгалтера, но так как у компании несколько юрлиц и большой объем работы, эту рекомендацию отклонили. ... В переписке с ИИ появилась идея передать функции отдела кадров в бухгалтерию, нейросеть одобрила, и скоро в компании станет еще на одного сотрудника меньше.
Противоречие тут видится мне.
То, что часть сотрудников уволили, не значит, что у других стало в разы больше обязанностей и нагрузки, с которой они не справляются.
Из чего сие значит? Из ваших слов?
Еще одна рекомендация: убрать вакантные позиции с нулевым выхлопом. Это дало еще +200 тысяч в месяц или 2,4 млн в год.
Долго вкуривал этот тезис. Каким образом незанятые позиции сэкономили +200 тыс в месяц. Видимо, я понимаю термин "вакантная позиции" как-то иначе. Ответ ИИ - "Вакансия" (вакантная позиция) означает незанятое рабочее место в компании, на которое можно принять нового сотрудника.
Я даю свой ноутбук... Можно я завтра еще к тебе приду? Действительно, даже час глубокого погружения зачастую помогает найти рабочие варианты.
Ноутбук один на всю компанию? Глубокого погружения куда?
Мой прогноз такой: через год-полтора в динамичных небольших компаниях останутся сотрудники, которые используют нейронки.
Еще один "прогнозист". Занялись бы вы чем-то более полезным.
Чем отличается ИИ от сотрудника? ИИ не скажет вам «Я не знаю».
Вы правы. Почему-то большая часть статей о graphql обходят этот вопрос. Помимо оптимизации глубоко вложенных запросов, есть также проблема глубины как таковой, так как object типы могут ссылаться циклически друг на друга (если так задать схему), то тем самым можно запросто положить сервер. У себя решили это просто собрав все запрашиваемые клиентами пути путем логирования, а потом все, что не в списке, то отбрасываем. Complexity тут не особо помогает тоже, так как сложно понимать что и насколько оценивать. Глубоко вложенные структуры в рамках одного сервиса можно оптимизировать, отображая схему запроса на eager или lazy отношения в orm, ну или как кому удобнее. Проблема N+1 может быть решена с помощью data loader (в federation схеме к примеру), но опять же смотреть надо что и как запрашивается. Оффтоп, но механизм upload в некотором роде просто приставка сбоку, и не рекомендуется аполло. У себя сделали просто отдельный рест для загрузок файлов, а в сервис передаем айди загрузки.
Тоже отказались от него, спустя 3 года. Ад конфликтующих зависимостей, куча откровенного мусора в node modules (каким-то образом туда даже попадали фротнэндовые библиотеки) плюс баги в graphql federation. Обновление до следующей версии каждый раз эти танцы с бубном. Использование rxjs в каждом углу не впечатляло, когда можно было обойтись обычным декоратором. Доходило до абсурда - когда для добавление аутентификации по jwt устанавливался пасспорт, jwt библиотека и обертка пасспорт под nestjs с кучей бойлерплейт кода, на тот момент это была рекомендуемая ими конфигурация. А всего-то кода там на 5 строчек без этой требухи. Хотя надо признаться, что другого такого универсального фреймворка под ноду нет. В итоге взяли «низкоуровневые» библиотеки, добавили немного вокруг них обвязки для удобства, и с этим благополучно живем.
То есть на основе зыбкого и допускающего широкую вариативность вопроса
Вопрос в статье был ни разу не зыбкий, а вполне определенный.
А что потом? Потом вам уволят.
И "вам", видимо, тоже.
Ну что-ж, умный понял, дурак до сюда не дочитал.
А третьего не дано? Дурак не дочитал, ок, а что этот некто умный должен из этого опуса понять? Что едино правильный взгляд - это взгляд очередного "всепропадиста" и более ничего?
Вообще часто удивляет косность содержимого подобных инфоциганских статей. Смешалось все, страшный ИИ (исколючительно в воображении автора), финансовые дефолты и иные фантасмагории. Прогресс в них проявляется в виде некой катастрофы, которая ниспустится вдруг на повсеместно стагнирующий мир. То, что прогресс изменяет этот самый мир и вообще ценности в нем, так это во внимание не принимается.
И да, покрутил я и ChatGPT, да, ведет себя умно, но, так сказать, с опорой на некий контекст. Короче, заданный вопрос уже содержал в себе определенный контекст ответа + обьем "усвоенных" в процессе обучения знаний. Вне этого нередко получается чепуха. Что дальше будет, посмотрим. Как мне пока что кажется, вряд ли совпадет с прогнозами автора.
Один из диалогов. В целом не очень впечатлило, довольно часто начинает говорить о каких-то вещах, о которых и не спрашивали, хотя в целом суть понимает. Лично я устал бы от такого ассистента довольно быстро.
HR ежедневно разгребают десятки откликов. Им уже особо не нужно искать кого-то самостоятельно. Хорошие специалисты сами плывут в руки.
Не знаю как в Китае, работаю в израильском стартапе, как пример, искали последние полгода толкового фронтендера и девопс и еле нашли. Аналогично и у знакомых в других компаниях.
Люди увидели в IT золотую жилу. Причем не только в качестве работников, но и как идея для создания образовательного бизнеса. Если раньше для получения знаний тебе надо было поступать в университет, то сейчас такое огромное количество курсов, что в них можно просто утонуть. Более того, каждая вторая такая платформа берет рекламу у блогеров, которые не только раскручивают их площадку, но и продвигают идею уходить в IT.
И что, хороших специалистов от этого стало больше? Скорее тут больше нагрузка на HR в итоге с затянутыми сроками и риском потерять действительно ценный кадр, а для соискателя где-то зря потраченное время.
Можно увидеть мир. В течение нескольких лет мы слышим, как какой-то наш знакомый айтишник уехал зимовать на Бали. Или его пригласили работать в Кремниевую долину, обеспечивая перелет/проживание/визы. А когда начался 2022... Кто-то увидел в этом даже спасение своей жизни. Неплохая мотивация, да?
Ни у кого из знакомых особого рвения такого не видел. Допускаю, что такие есть в принципе, но вряд ли уж очень много. Чтобы такое предложили, нужно быть ну уж точно вряд ли вчерашним джуном.
Доступность. Это 5 лет назад надо было шарить в математике, чтобы считаться хорошим специалистом. Сейчас же есть столько направлений и способов обучения, что сфера стала так или иначе доступна большинству. Уже даже не нужно хорошо знать языки программировния. Где-то достаточно простых команд, а вообще хватит и гугла. Ведь чем больше рынок - тем больше знаний в открытом доступе. Для средней зарплаты пойдет, а там видно будет.
Извечный камень преткновения - нужна ли программисту математика. Только как это соотносится вообще с направлением IT в целом? Вообще в этом абзаце смешались кони и люди.
Пора уже признать, что через пару лет IT перестанет быть такой перспективной темой
Слышу это уже лет 5 последние как. Оставляя в стороне высосанные из пальца сроки, вряд ли вообще оно было когда особо "перспективной" темой. Перспективной для чего? Есть спрос и есть предложение, как и во всем другом. И среди действительных спецов своего дела конкуренции нет и никогда не было в любой области. А остальное в соответсвии времени.
Это потому что вы смешали теплое с мягким. Тема была о декомпозиции регулярных выражений, и в рамках их применения, да, регулярка тут лучше, чем какой-то странный код, который по факту занимается валидацией, а не сопоставлением, прикидываясь, что этим и занимается. Валидация же может быть любой сложности и далеко выходить за рамки поиска.
Даже если вы декомпозируете пример с датой из начала статьи, конструкция (0[1-9]|[12][0-9]|3[01]) - это плохой и невкусно пахнущий код. Выковыряйте чиселку года вульгарным \d{1,4}
Это как раз-таки вполне здравый подход в данном случае в рамках применения регулярок, а ваши дополнительные проверки в коде как раз и есть плохой и невкусно пахнущий код.
Регулярки на то и регулярки, чтобы ими оставаться. А вы превратили относительно просто читаемое выражение в вырвиглазный псевдоскрипт, который малопереносим, да и сложен в проверке в каком-нибудь regex101. Вы с тем же успехом поучите математиков формулы писать. Вполне достаточно давать понятные имена самое переменной, использовать именованные группы или разбивку по строкам.
Это плохое решение. "Заабьюзить" сервис можно запросто. К примеру, я сделаю скрипт, который каждые 15 минут тупо добавляет товар обратно в корзину. У других практически нет шансов тогда купить товар. Если резервировать на этапе оформление заказа, то тут надо рассмотреть этот же вариант, к примеру, самое примитивное решение - при отказе или таймауте оплаты, позволять перейти к новому оформлению заказа не ранее, чем через 5 минут.
Это не понял, что значит. То есть, еще на заплатили, а товар уже списан? Тогда однозначно - нет.
Ввиду вышесказанного, я бы процесс сделал так:
1. Добавляются товары в корзину с обновлением доспупности для ранее добавленных и соответствующими предупреждениями.
2. Переход к оформлению заказа - тут происходит резервирование товаров на 15 мин (если доступны все еще, если нет, то предупреждать в соответствии).
3. Списание товаров только по факту оплаты, то есть по нажатию на кнопку "оплатить". Причем учесть процесс продолжения действия, если оплата и списание не выполняются атомарно и произошла ошибка. То есть чтобы не получилось так, что оплата произведена, а списание не произошло, и наоборот. Тут можно придумать много чего, к примеру, сохранять идентификатор сеанса оформления заказа и при повторной попытке проверять что было реально сделано.
4. Если опалата не была произведена по таймауту или заказ был отменен, добавить таймаут на новое оформление. Добавлять товары тем не менее можно.
Ну я пишу лет 8 в том числе и на питоне, и сходу тем не менее затруднился с ответом на
{("a", [1, 2]): "value"}иprint((x for x in range(3))). А за55 == True is Trueнадо сразу бить по рукам на месте. Наверное, я не знаю базу? Или просто в нормальных условиях такую дичь на код ревью не пропускают, и вообще такое в голову не приходит? Питон, скажем так, довольно специфичный язык, а автор, видимо, нанимался загадывать ребусы и выводить на чисту воду этих наглых "накрутчиков". Я вот смотрю больше на способность кандидата мыслить, коммуницировать, рассуждать и предлагать варианты, что куда важнее, чем знание 100+ подводных камней питона. И в качестве теста на написание кода идут самые обычные кейсы.Парад продолжается. После фиаско с первой версией этого, хм, "компилятора", а так же после его разбора, автор еще 8 месяцев пушил добавление/удаление строки в readme с целью создать видимость работы. Почти незамеченной протухла и вторая версия, краткий разбор которой был тут. Но автор не стоит на месте, радуя нас своим прогрессом, его даже не смущают 13 минусов под предыдущей статьей. Взлетит ли третья версия? Сомнительно. Видно, что автор явно не дурак, но нарциссизм не лучший спутник на этом пути.
Пустой треп в большей части. Понятно, что это интервью, однако...
Тут точно имелась в виду автономность?
Звучит прикольно.
LangChain?
Ползучий процесс и переизобретение, да-да. Это называют "эволюцией" обычно.
Это что такое? Джабба Хатт?
Конгениальный и актульный пример и практики использования ИИ - работа звонаря-выбивателя долгов. Ах, это же банк, тогда норм.
В последнее время, на мой взглад, складывается впечатние о какой-то эпидемии словесного поноса среди подобных спикеров. Может быть, я слишком придирчив.
Точно, необходимость передачи закрытого ключа как-то упустил из виду.
Бессмысленно, см "шифр Вернама", если размер ключа равен размеру текста, но идея интересная.
Когда есть только молоток, вокруг все кажется гвоздями.
"Обучение" тут - это двухдневная болтовня с чатом?
Противоречие тут видится мне.
Из чего сие значит? Из ваших слов?
Долго вкуривал этот тезис. Каким образом незанятые позиции сэкономили +200 тыс в месяц. Видимо, я понимаю термин "вакантная позиции" как-то иначе.
Ответ ИИ - "Вакансия" (вакантная позиция) означает незанятое рабочее место в компании, на которое можно принять нового сотрудника.
Ноутбук один на всю компанию? Глубокого погружения куда?
Еще один "прогнозист". Занялись бы вы чем-то более полезным.
А вы точно уверены, что понимаете причины этого?
Вы правы. Почему-то большая часть статей о graphql обходят этот вопрос. Помимо оптимизации глубоко вложенных запросов, есть также проблема глубины как таковой, так как object типы могут ссылаться циклически друг на друга (если так задать схему), то тем самым можно запросто положить сервер. У себя решили это просто собрав все запрашиваемые клиентами пути путем логирования, а потом все, что не в списке, то отбрасываем. Complexity тут не особо помогает тоже, так как сложно понимать что и насколько оценивать. Глубоко вложенные структуры в рамках одного сервиса можно оптимизировать, отображая схему запроса на eager или lazy отношения в orm, ну или как кому удобнее. Проблема N+1 может быть решена с помощью data loader (в federation схеме к примеру), но опять же смотреть надо что и как запрашивается. Оффтоп, но механизм upload в некотором роде просто приставка сбоку, и не рекомендуется аполло. У себя сделали просто отдельный рест для загрузок файлов, а в сервис передаем айди загрузки.
Тоже отказались от него, спустя 3 года. Ад конфликтующих зависимостей, куча откровенного мусора в node modules (каким-то образом туда даже попадали фротнэндовые библиотеки) плюс баги в graphql federation. Обновление до следующей версии каждый раз эти танцы с бубном. Использование rxjs в каждом углу не впечатляло, когда можно было обойтись обычным декоратором. Доходило до абсурда - когда для добавление аутентификации по jwt устанавливался пасспорт, jwt библиотека и обертка пасспорт под nestjs с кучей бойлерплейт кода, на тот момент это была рекомендуемая ими конфигурация. А всего-то кода там на 5 строчек без этой требухи. Хотя надо признаться, что другого такого универсального фреймворка под ноду нет. В итоге взяли «низкоуровневые» библиотеки, добавили немного вокруг них обвязки для удобства, и с этим благополучно живем.
Вопрос в статье был ни разу не зыбкий, а вполне определенный.
И "вам", видимо, тоже.
А третьего не дано? Дурак не дочитал, ок, а что этот некто умный должен из этого опуса понять? Что едино правильный взгляд - это взгляд очередного "всепропадиста" и более ничего?
Вообще часто удивляет косность содержимого подобных инфоциганских статей. Смешалось все, страшный ИИ (исколючительно в воображении автора), финансовые дефолты и иные фантасмагории. Прогресс в них проявляется в виде некой катастрофы, которая ниспустится вдруг на повсеместно стагнирующий мир. То, что прогресс изменяет этот самый мир и вообще ценности в нем, так это во внимание не принимается.
И да, покрутил я и ChatGPT, да, ведет себя умно, но, так сказать, с опорой на некий контекст. Короче, заданный вопрос уже содержал в себе определенный контекст ответа + обьем "усвоенных" в процессе обучения знаний. Вне этого нередко получается чепуха. Что дальше будет, посмотрим. Как мне пока что кажется, вряд ли совпадет с прогнозами автора.
Hidden text
Один из диалогов. В целом не очень впечатлило, довольно часто начинает говорить о каких-то вещах, о которых и не спрашивали, хотя в целом суть понимает. Лично я устал бы от такого ассистента довольно быстро.
Не знаю как в Китае, работаю в израильском стартапе, как пример, искали последние полгода толкового фронтендера и девопс и еле нашли. Аналогично и у знакомых в других компаниях.
И что, хороших специалистов от этого стало больше? Скорее тут больше нагрузка на HR в итоге с затянутыми сроками и риском потерять действительно ценный кадр, а для соискателя где-то зря потраченное время.
Ни у кого из знакомых особого рвения такого не видел. Допускаю, что такие есть в принципе, но вряд ли уж очень много. Чтобы такое предложили, нужно быть ну уж точно вряд ли вчерашним джуном.
Извечный камень преткновения - нужна ли программисту математика. Только как это соотносится вообще с направлением IT в целом? Вообще в этом абзаце смешались кони и люди.
Слышу это уже лет 5 последние как. Оставляя в стороне высосанные из пальца сроки, вряд ли вообще оно было когда особо "перспективной" темой. Перспективной для чего? Есть спрос и есть предложение, как и во всем другом. И среди действительных спецов своего дела конкуренции нет и никогда не было в любой области. А остальное в соответсвии времени.
Это потому что вы смешали теплое с мягким. Тема была о декомпозиции регулярных выражений, и в рамках их применения, да, регулярка тут лучше, чем какой-то странный код, который по факту занимается валидацией, а не сопоставлением, прикидываясь, что этим и занимается. Валидация же может быть любой сложности и далеко выходить за рамки поиска.
Это как раз-таки вполне здравый подход в данном случае в рамках применения регулярок, а ваши дополнительные проверки в коде как раз и есть плохой и невкусно пахнущий код.
Регулярки на то и регулярки, чтобы ими оставаться. А вы превратили относительно просто читаемое выражение в вырвиглазный псевдоскрипт, который малопереносим, да и сложен в проверке в каком-нибудь regex101. Вы с тем же успехом поучите математиков формулы писать. Вполне достаточно давать понятные имена самое переменной, использовать именованные группы или разбивку по строкам.
Автор понадергал из всех мест стереотипов, придумал свой мирок вокруг них и сам в него уверовал.