Если честно, то я ничего не понял из этой статьи. Причём совсем ничего не понял, хотя перечитал её дважды.
Проблем с заказами нет.
Что это значит? Мы можем продать весь произведённый объём продукции или это что-то другое?
Проблемы с заказами есть.
Что это значит? Производственные мощности больше, чем мы можем продать?
Сама теория ограничений хороша тем, что она рассматривает всю цепочку создания ценности - от поступления сырья до продажи готового товара клиенту. Ограничение может находится, где угодно, например в сырье, когда поставщики его медленно или с задержками привозят нам. Ограничение может быть в продажах, тогда есть смысл вложиться в рекламу. Ограничение может быть в производстве и т.д.
После прочтения заголовка и просмотра синего скриншота, вдруг подумалось, что Континент 4 - это отличное название для межконтинентальной ядерной ракеты. В этом случае гайд по развёртыванию Континент 4 заиграл новыми красками.
Сразу отмечу отсутствие двух фундаментальных элементов: Заявление о доступности (Accessibility Statement) Ссылки для пропуска навигации (Skip Links)
Сервис НЕ заявляет у себя доступности для людей с ограниченными возможностями. Вы проверили этот сервис и подтвердили, что доступность для людей с ограниченными возможностями найти не удалось.
Предлагаю ещё проверить сервис на наличие холестерина и вредных пептидов, так как про них сервис тоже ничего не заявляет.
В общем, смысл всего вашего тестирования бесполезен.
Если хотите, чтобы там появилась доступность для людей с ограниченными возможностями, то вам необходимо через ассоциацию таких людей отправить соответствующий запрос в Приорбанк, чтобы они рассмотрели возможность этот функционал добавить. Если прям совсем зудит в одном месте, то тогда есть смысл подниматься на уровень министерств и озвучивать эти тезисы там, чтобы не только в Приорбанке, но и у других банков такой функционал появился.
Уязвимость либо есть, либо её нет. Если она есть, то было бы неплохо её исправить. В чём проблема? Разработчики могут сами принять решения, исправлять что-то или нет.
Вижу, что не все поняли смысл моего комментария, поэтому распишу свою позицию подробнее.
Уязвимости в ПО - это плохо и их нужно исправлять. Создал своё ПО и отправил его в opensource, будь добр нести ответственность и исправлять в нём уязвимости. Если не хочешь исправлять уязвимости, то так и напиши. Индустрия тогда просто перейдёт на другое ПО, где есть кому исправлять уязвимости.
Размер ПО конечен (а не бесконечен), как и количество багов и уязвимостей в нём. Чем больше их исправлено, тем меньше их там остаётся.
Сейчас появилось много ПО, которое с помощью ИИ лучшим образом находит уязвимости, т.е. там, где раньше нужно было 10 человек, теперь с этим справляется 1 человек с помощью 10 сканеров уязвимостей. А это значит, что сейчас нахлынет волна репортов по уязвимостям. Это нормально. Чем больше уязвимостей будет по этим репортам исправлено, чем меньше этих репортов будет приходить в будущем.
Появление новых ИИ сканеров уязвимостей означает, что создателям ПО имеет смысл их запускать самостоятельно на периодической основе, а не ждать, пока это сделают сторонние исследователи ИБ. Например, можно включить дополнительную стадию в свой CI\CD процесс.
Если уязвимостей слишком много, то в первую очередь нужно исправлять самые критические, потом средние и в самом конце, если есть время и желание, то уязвимости с самым низким приоритетом.
Google и другие исследователи ИБ уже сделали многое, что нашли эти уязвимости и прислали вам для исправления. Никто из них вам больше ничего не должен, поэтому не нужно ждать, что кто-то будет вам присылать ещё и патчи для закрытия этих уязвимостей. Уязвимости должны исправлять мейнтейнеры проекта. Если из мейнтейнеров есть только сам автор этого ПО, то вопрос уже к нему, почему он не набрал к себе в команду других людей или почему не занимается расширением своего комьюнити.
Если какая-то компания или исследователь ИБ прислали вам тонну уязвимостей, то обсудите с ними, в каком порядке вы будете их исправлять и когда примерно, можно будет их обнародовать. С другой стороны тоже сидят люди, а не роботы и с понимаем отнесутся к вам, если будут знать, что уязвимости будут исправлены, а так как репортов было очень много, то на это потребуется больше времени, чем ранее ожидалось. В общем, будьте людьми и начните друг с другом общаться, а не видеть во всех, присылающих вам баги и уязвимости, врагов.
Уязвимость либо есть, либо её нет. Если она есть, то было бы неплохо её исправить. В чём проблема? Разработчики могут сами принять решения, исправлять что-то или нет.
Огонь! Всё, что вертелось у меня в голове, было наконец-то нормально сформировано в вашей статье. Теперь я знаю, как лучше отвечать на вопрос, когда именно будет выполнена задача, которую я ранее никогда не выполнял.
Добавил себе в закладки.
До этого момента я придерживался методологии "в сраку сроки", где задачи делятся на 2 типа:
Те, которые принесут реальную пользу бизнесу.
Те, которые по факту нафиг никому не нужны.
Задачи второго типа выкидывались и никогда не выполнялись, ну либо спускались на тормозах. Сэкономленное таким образом время тратилось на задачи первого типа.
Статья вроде и содержит какие-то факты, но выводы совсем безграмотные.
Amazon за последние десять лет превратил свои центры исполнения заказов в полностью интегрированные технопарки. В России же склад по-прежнему остаётся ручным процессом: тележки, сортировка, конвейеры и почти без автономных машин.
Amazon - флагман электронной коммерции в Америке. В США кроме Amazon имеются сотни других компаний со своими складами и даже им очень далеко до Amazon.
И фактически наша автоматизация пока находится на базовом уровне. Там где для мировых лидеров эта стадия осталась в прошлом десятилетии.
Смешно. Маркетплейсы у нас появились совсем недавно, так что им требуется некоторое время, чтобы создать свою первоклассную логистику и хранения. Через 3-5 лет склады Яндекс, WB и Ozona будут не хуже, чем у Amazon.
Азиатские гиганты электронной коммерции уже сейчас превосходят Amazon в роботизации, автоматизации и объёмах товаров.
Причина не в отсутствии компетенций — в экономике масштаба.
Вторая – нехватка мозгов, способных построить и обслуживать сложные системы.
Первое противоречит второму. Так всё же есть компетенции ли их нет?
С мозгами и компетенциями у нас никогда проблем не было. Сначала должна появится бизнес-потребность в этих решениях, а только потом мозги эти решения реализуют. Чтобы делать решения уровня Amazon нужно иметь товарообороты уровня Amazon. Как много компаний в РФ таким могут похвастаться? Ozon, WB, Yandex, Почта России и это всё. Не густо. Почта России - это гос, поэтому в расчёт не берём. Ozon, WB, Yandex как раз сейчас выходят на большие обороты и именно сейчас активно улучшают свои склады и логистику. Так что всё хорошо, вы зря паникуете.
Желанную привычку нужно встроить в определённое место иерархии твоих целей.
Это называется якорь, или триггер. Смысл в том, что какие-то события, явления, картинки или воспоминания сразу триггерят какие-то действия. Это как после выпитого кофе хочется покурить, или после негатива хочется его сразу же чем-то алкогольным погасить.
Якори\триггеры бывают позитивными, например, увидел на улице турник - пошёл подтянулся. Переел - сработал триггер на пешую прогулку для сжигания лишнего.
Ок, BotHub. Делегирую тебе задачу. Залезь в упомянутый в статье репозиторий и расскажи, какую реальную пользу могут примести лично мне представленные там материалы.
А как называется IPMI, который отвечает за управление вашим сервером - iBMC, ILO, iDRAC ?
Бесплатной в составе платного пакета Microsoft 365. :)
Если честно, то я ничего не понял из этой статьи. Причём совсем ничего не понял, хотя перечитал её дважды.
Что это значит? Мы можем продать весь произведённый объём продукции или это что-то другое?
Что это значит? Производственные мощности больше, чем мы можем продать?
Сама теория ограничений хороша тем, что она рассматривает всю цепочку создания ценности - от поступления сырья до продажи готового товара клиенту. Ограничение может находится, где угодно, например в сырье, когда поставщики его медленно или с задержками привозят нам. Ограничение может быть в продажах, тогда есть смысл вложиться в рекламу. Ограничение может быть в производстве и т.д.
После прочтения заголовка и просмотра синего скриншота, вдруг подумалось, что Континент 4 - это отличное название для межконтинентальной ядерной ракеты. В этом случае гайд по развёртыванию Континент 4 заиграл новыми красками.
Сервис НЕ заявляет у себя доступности для людей с ограниченными возможностями. Вы проверили этот сервис и подтвердили, что доступность для людей с ограниченными возможностями найти не удалось.
Предлагаю ещё проверить сервис на наличие холестерина и вредных пептидов, так как про них сервис тоже ничего не заявляет.
В общем, смысл всего вашего тестирования бесполезен.
Если хотите, чтобы там появилась доступность для людей с ограниченными возможностями, то вам необходимо через ассоциацию таких людей отправить соответствующий запрос в Приорбанк, чтобы они рассмотрели возможность этот функционал добавить. Если прям совсем зудит в одном месте, то тогда есть смысл подниматься на уровень министерств и озвучивать эти тезисы там, чтобы не только в Приорбанке, но и у других банков такой функционал появился.
Вижу, что не все поняли смысл моего комментария, поэтому распишу свою позицию подробнее.
Уязвимости в ПО - это плохо и их нужно исправлять. Создал своё ПО и отправил его в opensource, будь добр нести ответственность и исправлять в нём уязвимости. Если не хочешь исправлять уязвимости, то так и напиши. Индустрия тогда просто перейдёт на другое ПО, где есть кому исправлять уязвимости.
Размер ПО конечен (а не бесконечен), как и количество багов и уязвимостей в нём. Чем больше их исправлено, тем меньше их там остаётся.
Сейчас появилось много ПО, которое с помощью ИИ лучшим образом находит уязвимости, т.е. там, где раньше нужно было 10 человек, теперь с этим справляется 1 человек с помощью 10 сканеров уязвимостей. А это значит, что сейчас нахлынет волна репортов по уязвимостям. Это нормально. Чем больше уязвимостей будет по этим репортам исправлено, чем меньше этих репортов будет приходить в будущем.
Появление новых ИИ сканеров уязвимостей означает, что создателям ПО имеет смысл их запускать самостоятельно на периодической основе, а не ждать, пока это сделают сторонние исследователи ИБ. Например, можно включить дополнительную стадию в свой CI\CD процесс.
Если уязвимостей слишком много, то в первую очередь нужно исправлять самые критические, потом средние и в самом конце, если есть время и желание, то уязвимости с самым низким приоритетом.
Google и другие исследователи ИБ уже сделали многое, что нашли эти уязвимости и прислали вам для исправления. Никто из них вам больше ничего не должен, поэтому не нужно ждать, что кто-то будет вам присылать ещё и патчи для закрытия этих уязвимостей. Уязвимости должны исправлять мейнтейнеры проекта. Если из мейнтейнеров есть только сам автор этого ПО, то вопрос уже к нему, почему он не набрал к себе в команду других людей или почему не занимается расширением своего комьюнити.
Если какая-то компания или исследователь ИБ прислали вам тонну уязвимостей, то обсудите с ними, в каком порядке вы будете их исправлять и когда примерно, можно будет их обнародовать. С другой стороны тоже сидят люди, а не роботы и с понимаем отнесутся к вам, если будут знать, что уязвимости будут исправлены, а так как репортов было очень много, то на это потребуется больше времени, чем ранее ожидалось. В общем, будьте людьми и начните друг с другом общаться, а не видеть во всех, присылающих вам баги и уязвимости, врагов.
Уязвимость либо есть, либо её нет. Если она есть, то было бы неплохо её исправить. В чём проблема? Разработчики могут сами принять решения, исправлять что-то или нет.
Огонь! Всё, что вертелось у меня в голове, было наконец-то нормально сформировано в вашей статье. Теперь я знаю, как лучше отвечать на вопрос, когда именно будет выполнена задача, которую я ранее никогда не выполнял.
Добавил себе в закладки.
До этого момента я придерживался методологии "в сраку сроки", где задачи делятся на 2 типа:
Те, которые принесут реальную пользу бизнесу.
Те, которые по факту нафиг никому не нужны.
Задачи второго типа выкидывались и никогда не выполнялись, ну либо спускались на тормозах. Сэкономленное таким образом время тратилось на задачи первого типа.
Неожиданно годная статья про ИИ и его внедрение. Правда, слишком много картинок, но это, видимо, чтобы с СДВГ не заскучали, пока её читают.
Не ты выбираешь армию, а армия выбирает тебя. Сержант, занесите эти простые, но в тоже время мудрые слова в протокол. (С) ДМБ
Для хороших людей армия — родная мать, а для плохих — тёща. (С) ДМБ
Скорее показал, что нельзя вкладывать деньги в Европу, т.к. могут отжать компанию, прикрываясь вопросами национальной безопасности.
В остальном согласен с вашим комментарием, что строить любое производство в Европе - так себе идея.
eat - sleep - game - repeat
Осталось ещё британских учёных спросить.
Статья вроде и содержит какие-то факты, но выводы совсем безграмотные.
Amazon - флагман электронной коммерции в Америке. В США кроме Amazon имеются сотни других компаний со своими складами и даже им очень далеко до Amazon.
Смешно. Маркетплейсы у нас появились совсем недавно, так что им требуется некоторое время, чтобы создать свою первоклассную логистику и хранения. Через 3-5 лет склады Яндекс, WB и Ozona будут не хуже, чем у Amazon.
Азиатские гиганты электронной коммерции уже сейчас превосходят Amazon в роботизации, автоматизации и объёмах товаров.
Первое противоречит второму. Так всё же есть компетенции ли их нет?
С мозгами и компетенциями у нас никогда проблем не было. Сначала должна появится бизнес-потребность в этих решениях, а только потом мозги эти решения реализуют. Чтобы делать решения уровня Amazon нужно иметь товарообороты уровня Amazon. Как много компаний в РФ таким могут похвастаться? Ozon, WB, Yandex, Почта России и это всё. Не густо. Почта России - это гос, поэтому в расчёт не берём. Ozon, WB, Yandex как раз сейчас выходят на большие обороты и именно сейчас активно улучшают свои склады и логистику. Так что всё хорошо, вы зря паникуете.
Это называется якорь, или триггер. Смысл в том, что какие-то события, явления, картинки или воспоминания сразу триггерят какие-то действия. Это как после выпитого кофе хочется покурить, или после негатива хочется его сразу же чем-то алкогольным погасить.
Якори\триггеры бывают позитивными, например, увидел на улице турник - пошёл подтянулся. Переел - сработал триггер на пешую прогулку для сжигания лишнего.
Как минимум, я единственный, кто оставил коммент, под этой бесполезной статьёй.
Ок, BotHub. Делегирую тебе задачу. Залезь в упомянутый в статье репозиторий и расскажи, какую реальную пользу могут примести лично мне представленные там материалы.
Нужны скрипты на:
Утренний подъём без будильника.
Комфортное перемещение на работу и обратно.
Отправку детей в сад.
И готовку еды на утро и вечер.
/sarcasm
Ок, значит и это читать не буду.
Автономная доставка ребёнка в детский сад и обратно.