С этим согласен. Но и проблему распределения ресурсов капитализм не решает. По сути, это вспомогательный инструмент для решения этой и других проблем, со своими условиями эффективности.
А что, с капитализмом (современным) это делается не так? Одним разрешают умереть, других спасают господдержкой. Одним сразу дают госконтракт на Луну, вторых заставляют глотать пыль по судам.
В советском научно-фантастическом фильме "Гостья из будущего" 1984 года сюжет первой серии строится вокруг того, что главный герой в будущем носит в эко-сумке тару от напитка. Причём, что характерно, тару вымытую от остатков продукта. И в конце концов он просто заходит в магазин и там ему заменяют пустую тару на наполненную! Причём всё готово к повторному использованию - даже крышечку там придумали делать пригодной для повторного использования (на основе алюминия) - да и открывается она удобно - простым тычком большого пальца!
Выглядит удобно, хотя, конечно, до такой фантастически высокоразвитой цивилизации нам идти и идти. А так было бы удобно! Хочешь получить заказ в коробке? Просто принеси в ПВЗ пригодную для сдачи коробку и полиэтилен от предыдущего заказа и/или внеси залог.
Честно говоря, очень тяжело читать. Конечно, стиль, когда обсуждаемый вопрос разжёвывается по 100500 раз в каждый раз немного отличающемся виде - немного другая крайность. Но и когда начинают "с места в карьер", забыв даже расшифровать акронимы в месте первого их применения - это перебор в уровне конспективности.
Я далёк от обсуждаемой предметной области. Пришлось даже гуглить, что такое ТИМ. Кстати, те кто этот термин придумывал - видимо в той же традиционной отечественной манере решили "догнать и сразу перегнать" глупых и приземлённых "буржуев", и из моделирования информации касающейся конкретно строительства (BIM - Building Information Modelling) сделали абстрактную технологию информационного моделирования (ТИМ). По самому названию складывается ощущение, что те, кто этим занимаются - делают это для абстрактного развития самой технологии (из научного интереса - ?), а не для реальных результатов или конкретной экономии/прибыли.
Далее, не видно позиционирования статьи. Судя по заголовку, в ней должно быть описание предмета - "ЕСОД" (рекламное/техническое - не суть важно). Но как раз описания мало (что это такое в целом, какие основные функции, какая польза внедряющим, сколько будет стоить внедрить - ?). Есть отдельные фрагменты картины (пользователи/выгодоприобретатели), но не описано как они будут взаимодействовать. Есть декларирование нужности и полезности. Но общей картины за этим всем не видно. Возможно, имело бы смысл по другому скомпоновать и привести указатель содержания. Либо разбить на несколько статей и начать с более конкретных вопросов.
Наконец, непонятно назначение обсуждаемого предмета. Насколько я понял, суть этой статьи - предложение к дальнейшим действиям. Обычно в таких документах задаются вопросы "зачем и почему", на которые даётся обстоятельный ответ. Здесь этого не заметно. Такое ощущение, что как недостаточно опытные разработчики сразу бегут кодировать решение, так и здесь - пытаются преподнести решение, без констатации/формулирования проблемы. Причём, как упомянуто в предыдущем абзаце, - фрагментарно ("нью васюки", "аэропорт большие васюки", "междупланетный шахматный конгресс)", Впечатляюще, но непонятно зачем.
Ну и, наконец, непонятна причина выбора решения - единой мега-системы - вместо отдельных интерфейсов/систем передачи наборов данных, касающихся конкретных bounded context предметной области.
Собственно, не вижу противоречия тому, что вы описали. Наличие выделенной должности не противоречит тому, что PO это роль. Может даже быть коллективное исполнение данной роли - но это когда есть отдел PMов, в противном случае это немного странно.
Если что, такая ситуация чуть менее, чем везде. И в IT, обычно, в особенности (потому что в отличие от разрядности, повышение уровня никак внешне не отличить).
Хочешь повышения и исчерпаны направления роста на текущем месте - делай карьерный зигзаг через другую компанию
В последнее время такая роль называется Product Owner. Не путайте: это именно роль,а не профессия или должность (хотя сейчас много фирм, где практикуется последнее). Играть эту роль в зависимости от наследия в конкретной команде могут и аналитик, и программист, и аккаунт-менеджер. Но обычно это Project Manager (хотя я всего одного встречал из них, справлявшегося с такой ролью).
Ну получит, и получит. Если пострадавший получит компенсацию (возможно, в каких-то ограниченных объёмах), то какая тут разница?
В принципе, это ничем не отличается от приёма наличных. Вручают пятитысячную бумажку - подумай 10 раз, стоит ли её принимать, т.к. не факт, что она подлинная.
Хочешь безопасного приёма средств - проведи онлайн. А если за какой-нибудь проезд принимаешь - ну так компенсируют.
В принципе, для цифроденег ЦБ, где все кошельки известны ЦБ и где кошельки потом будут сверяться в онлайне с базой ЦБ, проблема двойной траты не так важна. Сгрузили несколько дублирующих банкнот - кошелек дубликатор идентифицируется и платит/отдыхает.
То же самое и с атакой на блокировку денег плательщика - кошелек, злоупотребляющий офертами (которые могут быть обеспечены депозитами в ЦБ) опустошается и средства отправляются несостоявшемуся плательщику.
Вместо дополнений бойлерплейтов лучше бы занимались автоверификаторами. Нафига мне джуны, которые на пару с ИИ-джунами будут писать код, который потом вручную придется проверять на рейсы/дедлоки/кривую обработку исключений (в т.ч. с учетом взаимодействия с внешним миром)?
Описаны типичные рабочие сложности. И практика показывает, что даже в компаниях с развитым онбордингом и хелпдеском в какой-то момент возникают некомфортные задачи. И их решение - называется "работа".
В части про раздувание числа статей при ухудшении их качества автор, КМК, путает причину со следствием. Если оплачиваются хвосты вредителей, глупо расчитывать что люди не будут заводить фермы по размножению вредителей, а будут очищать пространство от них.
Spectre, Meltdown и т.д. это, во-первых, не закладки, а ошибки.
Классные такие "ошибки". Мне кажется, что когда обезьяна вынимает чеку из гранаты, которую ей вручили - она не ошибается (точнее, нельзя сказать, что "она ошибается"). Она просто "не думает". Именно это, если верить официальной информации, произошло при разработке фич, благодаря которым стали возможны подобные уязвимости.
Вопрос "ошибка это или уязвимость" требует анализа действий тех, кто поручал/контролировал такую разработку (аналогично тому, как расследование гипотетического инцидента с обезьяной подразумевает нахождение того, кто вручил ей эту гранату и выяснение его мотивов).
Как их использовать, если нет возможности прямого запуска кода не машине?
Для Spectre/Meltdown прямого запуска кода и не требовалось. Они эксплуатировались даже через javascript в браузере.
У нас практически вся инфраструктура в России (да что в России - в мире) построена на процах,где есть Spectre/Meltdown. Но что-то никаких массовых проблем не наблюдается.
Во всех современных ОС уязвимость закрыта на уровне ядер. Если где-то в критичных отраслях используются старые ядра или при загрузке передаётся флаг, отключающий фикс - то они ССЗБ.
Кстати, заодно отвечу на
Intel ME, Intel AMT - Не вдаваясь в рассуждения о том, насколько данные технологии безопасны, можно просто констатировать, что они реализованы на базе отдельного процессора на материнской плате и не являются частью CPU.
А современные ЦП разве могут нормально работать без технологий типа ME? Я вот тут разбирался с багом сетевой карты - фикс был как раз по направлению ME.
Почему-то прошивка телефонов такая сложная (всегда была). Не совсем понятно, почему нельзя прошивать отдельно драйвера/блобы из оригинальных прошивок и юзерспейс, собранный руками из проверенных сообществом исходников...
Или можно? Как васяны с колянами делают свои кастомные прошивки? Есть ли где-то цикл статей/инструкции/блогпосты?
Интересно, как с вашей точки зрения должен был бы бороться с таким положением вещей генеральный?
Т.е. получается, проблемы от того, что непонятны ответы на следующие вопросы. Это команда такая медленная (в описанном эпосе - платформы) или они реально чем-то сложным занимаются? Тот менеджер среднего звена приносит пользу или вред? Если у этой команды регулярно и с громким стуком падает система - это из-за криворукости, или просто у других команд системы не важные.
Да. Если бы этой информации не требовалось, то это была бы плохая строгая типизация. :)
Но ссылается только на общий объект контекста, а не на то, что в нём должен быть какой-то конкретный элемент c.
Иногда (в контексте DI) уже есть блоки, которые работают с более узким контекстом. Тогда их можно скомпозировать. К примеру, down можно ещё больше разбить:
// функция, которая умеет работать с общим контекстом
def down[F[_]: Applicative: WithContext[*[_], Ctx], A: Numeric: Extract[Ctx, *]](
y: A, z: A
) = {
// указываем способ работы с контекстом типа A
implicit val wc2: WithContext[F, A] =
WithContext[F, Ctx].extract(implicitly[Ctx Extract A])
bottom(y, z)
}
/* функция, которая умеет работать с более конкретным контектом. плюс используется синтаксис для
более компактного доступа к контексту
*/
def bottom[F[_]: Applicative: WithContext[*[_], A], A: Numeric](
y: A, z: A
) = {
val num = Numeric[A]
import num._
import tofu.syntax.context._
for {
c <- context
} yield (y + z) * c
}
С этим согласен. Но и проблему распределения ресурсов капитализм не решает. По сути, это вспомогательный инструмент для решения этой и других проблем, со своими условиями эффективности.
А что, с капитализмом (современным) это делается не так? Одним разрешают умереть, других спасают господдержкой. Одним сразу дают госконтракт на Луну, вторых заставляют глотать пыль по судам.
Те, кто летает самолётами, вряд ли склонен к такому поведению.
В советском научно-фантастическом фильме "Гостья из будущего" 1984 года сюжет первой серии строится вокруг того, что главный герой в будущем носит в эко-сумке тару от напитка. Причём, что характерно, тару вымытую от остатков продукта. И в конце концов он просто заходит в магазин и там ему заменяют пустую тару на наполненную! Причём всё готово к повторному использованию - даже крышечку там придумали делать пригодной для повторного использования (на основе алюминия) - да и открывается она удобно - простым тычком большого пальца!
Выглядит удобно, хотя, конечно, до такой фантастически высокоразвитой цивилизации нам идти и идти. А так было бы удобно! Хочешь получить заказ в коробке? Просто принеси в ПВЗ пригодную для сдачи коробку и полиэтилен от предыдущего заказа и/или внеси залог.
Честно говоря, очень тяжело читать. Конечно, стиль, когда обсуждаемый вопрос разжёвывается по 100500 раз в каждый раз немного отличающемся виде - немного другая крайность. Но и когда начинают "с места в карьер", забыв даже расшифровать акронимы в месте первого их применения - это перебор в уровне конспективности.
Я далёк от обсуждаемой предметной области. Пришлось даже гуглить, что такое ТИМ. Кстати, те кто этот термин придумывал - видимо в той же традиционной отечественной манере решили "догнать и сразу перегнать" глупых и приземлённых "буржуев", и из моделирования информации касающейся конкретно строительства (BIM - Building Information Modelling) сделали абстрактную технологию информационного моделирования (ТИМ). По самому названию складывается ощущение, что те, кто этим занимаются - делают это для абстрактного развития самой технологии (из научного интереса - ?), а не для реальных результатов или конкретной экономии/прибыли.
Далее, не видно позиционирования статьи. Судя по заголовку, в ней должно быть описание предмета - "ЕСОД" (рекламное/техническое - не суть важно). Но как раз описания мало (что это такое в целом, какие основные функции, какая польза внедряющим, сколько будет стоить внедрить - ?). Есть отдельные фрагменты картины (пользователи/выгодоприобретатели), но не описано как они будут взаимодействовать. Есть декларирование нужности и полезности. Но общей картины за этим всем не видно. Возможно, имело бы смысл по другому скомпоновать и привести указатель содержания. Либо разбить на несколько статей и начать с более конкретных вопросов.
Наконец, непонятно назначение обсуждаемого предмета. Насколько я понял, суть этой статьи - предложение к дальнейшим действиям. Обычно в таких документах задаются вопросы "зачем и почему", на которые даётся обстоятельный ответ. Здесь этого не заметно. Такое ощущение, что как недостаточно опытные разработчики сразу бегут кодировать решение, так и здесь - пытаются преподнести решение, без констатации/формулирования проблемы. Причём, как упомянуто в предыдущем абзаце, - фрагментарно ("нью васюки", "аэропорт большие васюки", "междупланетный шахматный конгресс)", Впечатляюще, но непонятно зачем.
Ну и, наконец, непонятна причина выбора решения - единой мега-системы - вместо отдельных интерфейсов/систем передачи наборов данных, касающихся конкретных bounded context предметной области.
Собственно, не вижу противоречия тому, что вы описали. Наличие выделенной должности не противоречит тому, что PO это роль. Может даже быть коллективное исполнение данной роли - но это когда есть отдел PMов, в противном случае это немного странно.
Если что, такая ситуация чуть менее, чем везде. И в IT, обычно, в особенности (потому что в отличие от разрядности, повышение уровня никак внешне не отличить).
Хочешь повышения и исчерпаны направления роста на текущем месте - делай карьерный зигзаг через другую компанию
В последнее время такая роль называется Product Owner. Не путайте: это именно роль,а не профессия или должность (хотя сейчас много фирм, где практикуется последнее). Играть эту роль в зависимости от наследия в конкретной команде могут и аналитик, и программист, и аккаунт-менеджер. Но обычно это Project Manager (хотя я всего одного встречал из них, справлявшегося с такой ролью).
Ну получит, и получит. Если пострадавший получит компенсацию (возможно, в каких-то ограниченных объёмах), то какая тут разница?
В принципе, это ничем не отличается от приёма наличных. Вручают пятитысячную бумажку - подумай 10 раз, стоит ли её принимать, т.к. не факт, что она подлинная.
Хочешь безопасного приёма средств - проведи онлайн. А если за какой-нибудь проезд принимаешь - ну так компенсируют.
В принципе, для цифроденег ЦБ, где все кошельки известны ЦБ и где кошельки потом будут сверяться в онлайне с базой ЦБ, проблема двойной траты не так важна. Сгрузили несколько дублирующих банкнот - кошелек дубликатор идентифицируется и платит/отдыхает.
То же самое и с атакой на блокировку денег плательщика - кошелек, злоупотребляющий офертами (которые могут быть обеспечены депозитами в ЦБ) опустошается и средства отправляются несостоявшемуся плательщику.
если хочется производительности, то никак. лучше протянуть видео и USB кабель, если хочется прямо тихого решения.
а так - я пользовался xpra
Вместо дополнений бойлерплейтов лучше бы занимались автоверификаторами. Нафига мне джуны, которые на пару с ИИ-джунами будут писать код, который потом вручную придется проверять на рейсы/дедлоки/кривую обработку исключений (в т.ч. с учетом взаимодействия с внешним миром)?
Не заметил про "совок". Да и автор издалека.
Описаны типичные рабочие сложности. И практика показывает, что даже в компаниях с развитым онбордингом и хелпдеском в какой-то момент возникают некомфортные задачи. И их решение - называется "работа".
В части про раздувание числа статей при ухудшении их качества автор, КМК, путает причину со следствием. Если оплачиваются хвосты вредителей, глупо расчитывать что люди не будут заводить фермы по размножению вредителей, а будут очищать пространство от них.
Но его же (retpoline) в итоге починили? падме_анакин.jpg
Не сталкивались с проблемой производительности при большом количестве карточек на доске? https://github.com/kanboard/kanboard/issues/5036
У меня ощущение, что это в относительно поздних версиях появилось.
Классные такие "ошибки". Мне кажется, что когда обезьяна вынимает чеку из гранаты, которую ей вручили - она не ошибается (точнее, нельзя сказать, что "она ошибается"). Она просто "не думает". Именно это, если верить официальной информации, произошло при разработке фич, благодаря которым стали возможны подобные уязвимости.
Вопрос "ошибка это или уязвимость" требует анализа действий тех, кто поручал/контролировал такую разработку (аналогично тому, как расследование гипотетического инцидента с обезьяной подразумевает нахождение того, кто вручил ей эту гранату и выяснение его мотивов).
Для Spectre/Meltdown прямого запуска кода и не требовалось. Они эксплуатировались даже через javascript в браузере.
Во всех современных ОС уязвимость закрыта на уровне ядер. Если где-то в критичных отраслях используются старые ядра или при загрузке передаётся флаг, отключающий фикс - то они ССЗБ.
Кстати, заодно отвечу на
А современные ЦП разве могут нормально работать без технологий типа ME? Я вот тут разбирался с багом сетевой карты - фикс был как раз по направлению ME.
Почему-то прошивка телефонов такая сложная (всегда была). Не совсем понятно, почему нельзя прошивать отдельно драйвера/блобы из оригинальных прошивок и юзерспейс, собранный руками из проверенных сообществом исходников...
Или можно? Как васяны с колянами делают свои кастомные прошивки? Есть ли где-то цикл статей/инструкции/блогпосты?
Интересно, как с вашей точки зрения должен был бы бороться с таким положением вещей генеральный?
Т.е. получается, проблемы от того, что непонятны ответы на следующие вопросы. Это команда такая медленная (в описанном эпосе - платформы) или они реально чем-то сложным занимаются? Тот менеджер среднего звена приносит пользу или вред? Если у этой команды регулярно и с громким стуком падает система - это из-за криворукости, или просто у других команд системы не важные.
Да. Если бы этой информации не требовалось, то это была бы плохая строгая типизация. :)
Но ссылается только на общий объект контекста, а не на то, что в нём должен быть какой-то конкретный элемент c.
Иногда (в контексте DI) уже есть блоки, которые работают с более узким контекстом. Тогда их можно скомпозировать. К примеру, down можно ещё больше разбить: