Я совершенно без проблем печатаю 330-380 знаков/минуту на qwerty/йцукен и, если честно, я не умею так быстро думать, как умею быстро печатать.
По ощущениям я думаю слова не быстрее 200 знаков/минуту, а если я печатаю быстрее этого - я просто перепечатываю что-то с листа или играю в гонки на клавиатуре)
Я имел ввиду, что метрика "количество закрытых тикетов" была признана плохой, потому что люди будут брать себе самые простые задачи. Чем это отличается от того, что люди будут брать самые простые юзерстори и закрывать самые простые задачи?
Ну так и что удивляться тогда, что ваш велосипед не едет через 3 месяца, при заявленных двух неделях?)
Вы буквально озвучили все причины по которым он не едет и обвиняете в этом инженеров, хотя буквально в каждом вашем предложении ошибки менеджмента, которые ведут к тому, что ничего не работает и все делается очень долго.
Причем я не говорю, что ваш подход не будет работать. Он просто называется "долго, дорого, плохо". При наличии денег и малой конкуренции - он вполне жизнеспособен.
Зависио от шифрования. Большинство устройств давно уже поддерживают аппаратные расширения для AES и шифрование 800 МБит - вообще не выглядит невероятным.
Скажем, мне меньше верится в наличие 800 МБит канала у клиента.
Скажем, не без заморочек было. Надо было отключить исключение, правильно настроить размер стека, отключить red-zone, написать свое подмножество STL, на 32-х битных системах ещё правильно прокинуть десяток флагов компилятора.
Но это делается один раз, отлаживается за пару деньков)
Да почему нельзя? Можно. Я сам писал. Другое дело, что это был проприетарный код. Но в целом, никто не мешает написать модуль ядра и open source, просто собираться он будет out of tree
Я совершенно без проблем печатаю 330-380 знаков/минуту на qwerty/йцукен и, если честно, я не умею так быстро думать, как умею быстро печатать.
По ощущениям я думаю слова не быстрее 200 знаков/минуту, а если я печатаю быстрее этого - я просто перепечатываю что-то с листа или играю в гонки на клавиатуре)
Не вижу противоречий. Все ответы - правильные. Потому что все ответы - случайные.
Содержимое ответов не имеет значения.
Я имел ввиду, что метрика "количество закрытых тикетов" была признана плохой, потому что люди будут брать себе самые простые задачи. Чем это отличается от того, что люди будут брать самые простые юзерстори и закрывать самые простые задачи?
Чем это отличается от "количества закрытых тикетов" я так и не понял) Равно как и метрика о проценте закрытых за спринт задач)
Но при этом его филиал был одним из лучших по показателям) Настолько, что его даже не закрыли, а закрыли филиал в стенфорде.
Вообще не подойдёт. Такую ахинею генерирует иногда. Например, на моих глазах qwen в С# проекте давала подсказки кода на Java)
Цены, как всегда, по запросу, в лучших российских традициях)
Я за 32 года жизни в живую ни одного устройства Surface ещё не видел)
Ну так и что удивляться тогда, что ваш велосипед не едет через 3 месяца, при заявленных двух неделях?)
Вы буквально озвучили все причины по которым он не едет и обвиняете в этом инженеров, хотя буквально в каждом вашем предложении ошибки менеджмента, которые ведут к тому, что ничего не работает и все делается очень долго.
Причем я не говорю, что ваш подход не будет работать. Он просто называется "долго, дорого, плохо". При наличии денег и малой конкуренции - он вполне жизнеспособен.
Проблема "оценки задач" инженером в том, что по пути - внезапно! - выясняется, что бизнес не хочет инженерного решения задачи) Он хочет продукт)
Вот только нормальные требования к продукту написать - нужен аналитик, но бизнес же экономит)
Telegram?)
Зависио от шифрования. Большинство устройств давно уже поддерживают аппаратные расширения для AES и шифрование 800 МБит - вообще не выглядит невероятным.
Скажем, мне меньше верится в наличие 800 МБит канала у клиента.
Скажем, не без заморочек было. Надо было отключить исключение, правильно настроить размер стека, отключить red-zone, написать свое подмножество STL, на 32-х битных системах ещё правильно прокинуть десяток флагов компилятора.
Но это делается один раз, отлаживается за пару деньков)
Счатсливый человек писал статью, раз не вспомнил про `git reflog`)
Зависит от flow)) Любой крупный долгоживущий проект работающий по trunk based development черри-пикает патчи с завидной регулярностью.
Решение конфилктов к командам git не имеет никакого отношения)
Так я это :) Числюсь в штате разработчиком) Тот самый обычный программист) Занудный немного, но самый обычный)
Если отвечать на поставленный вопрос, да - требует, ведь STL часть стандарта и STL явно бросает исключения, значит throw как минимум обязателен.
Если отвечать реально - зависит от кода. Если не использовать STL и везде писать new с std::nothrow, то в целом будет С++ код без исключений.
Да почему нельзя? Можно. Я сам писал. Другое дело, что это был проприетарный код. Но в целом, никто не мешает написать модуль ядра и open source, просто собираться он будет out of tree
После этого вы начинаете писать на чем угодно, но не на С++) Ни один из стандартов С++ не подразумевает отключение исключений.