В случае преступлений против имущества есть страховки. В Швейцарии знакомого обокрали, он позвонил в полицию, а в ответ услышал: «А зачем вы нам звоните, а не в страховую?»
Но это не работает для преступлений против личности, разумеется.
Т.е. мы просто перечисляем валидные комбинации параметров, а дальше TS не даст сконструировать неверную комбинацию. Да, можно потом "отредактировать" ApiResponse и ввести его в невалидный режим, но это надо постараться ещё сделать - от случайных ошибок защитит.
Ваш метод не во всех странах можно использовать. Скажем, пенсионные взносы в Швейцарии прилично отгрызают от зарплаты, и "на руки" денег остаётся мало, но пенсия накопительная, ее не конфискуют, и со временем ее можно вытащить — или на покупку недвижимости, или на открытие бизнеса, или собственно на старость. Почему бы эти деньги не считать?
А, вы про ядро же… Тут да. Но если это вдска, то есть ещё и хост-система, которую вы не контролируете вообще, и железо с непонятными прошивками. Тут все зависит от вашей модели безопасности — если за вами скажем охотятся крупные государства, то вам вообще про вдски лучше забыть.
Докер-контейнер не проще запустить? Ядро как раз берете от хостера — оно может быть затюнено под их железо и инфраструктуру, а все прочее приносите а образе.
Господи, это надо же, кошмар какой! Системные вызовы могут возвращать ошибки! Давайте отдельные статьи напишем про «закрытие файлов может возвращать ошибки, которые надо обрабатывать», «выделение памяти может возвращать ошибки, которые надо обрабатывать», «запись в stdout/stderr может возвращать ошибки, которые надо обрабатывать». Каждый из перечисленных случаев способен достаточно округлить глаза у программистов, которые с этим не сталкивались, и вызвать спектр проблем — от стабильности до безопасности.
Ещё не нашел в статье важный момент — requests как по cpu, так и по памяти участвует не только в планировании раскладки подов по нодам, но ещё и даёт гарантированную ёмкость подам. Если под запросил скажем 1 cpu, а лимит — 2 cpu, то вот этот один будет на уровне cgroups выделен с высоким приоритетом, а уж если на машине остались свободные ресурсы, тогда они распилятся между теми контейнерами, которым хочется ещё.
Ну и про работу oom-киллера. Если память на машине физически кончилась, то контейнеры будут убиваться даже до достижения лимита. И тут важный момент — чем больше превышение использование памяти над requests, тем больше вес у этого контейнера, чтобы его убить.
Увидел название — подумал: "О как круто, наконец новичкам объяснят, что бенчмарки должны отражать то, что программа будет делать в жизни, на том железе, что будет в жизни, при том же уровне загрузки системы и т.д., что производительность программ зависит не только от cpu-bound кусков (если это не математическое вычисление, конечно, и не симуляция), и что производительность — многомерная величина — есть много узких мест, она не линейная — два процессора могут не удвоить скорость работы и т.д. и т.д. и т.д."
А тут — даже не знаю… Ну померит новичок скорость вызова функций, развернет циклы, а потом сделает 1 запрос к базе данных, и производительность упадет на 3 порядка.
Аналогично. Провожу собеседования в Google на инженерные роли, отвожу 5 минут в конце на вопросы. Примерно у половины их нет вообще. Чаще всего спрашивают, в какой команде я лично работаю, как мой день выглядит. Кое-кто спрашивает про организационные практики, про карьерный рост. Иногда кандидаты спрашивают про иммиграцию — цены, медицина, школы — вот это всё. Вопросов по бизнесу не слышал ни разу. И да, если интервью телефонное, иногда сессия вопросов и ответов затягивается за пределы отведённого времени — один раз даже полчаса проболтали с кандидатом после интервью.
Вот кстати это как раз хороший пример получился того, как зачастую разработчики решают не ту проблему (более общую, более сложную, просто другую), и в итоге решение накапливает в себе сложность предметной области, которой оно касаться не должно.
Например, нужно было придумать систему для простого умножения, а разработчик зачем-то добавил туда возможность лёгкой оценки порядка величины. Или наоборот.
В итоге решение получилось более сложным, чем могло быть.
Есть ли организационная возможность у ДИТ ответить мэрии, что в указанные сроки качественное исполнение работы невозможно в принципе, и отказаться от задачи? Предпринимались ли соответствующие попытки?
Похожая проблема есть у всяких сервисов IP-телефонии. Вроде система предоставляет услугу звонков, как её использовать — дело клиента. Однако если абонент на «персональном» тарифе организует колл-центр и будет занимать линию сильно больше, чем обычный частный абонент, это пытаются ограничивать. Обратите внимание, как обычно формлуируют норму нагрузки в эрлангах. Пример: www.alloincognito.ru/help/reference-documents/load-norm.
Яндекс вместо того, чтобы полностью блокировать приложение, мог бы установить аналогичную норму для синхронизации файлов. Синхронизировать документы — пожалуйста, а бэкапить базы данных — сорян.
Есть две проблемы, которые вместе решить довольно сложно — удостовериться, что не будет выдан лишний бюллетень (или ключ, или токен), и неотслеживаемость конкретных избирателей.
Нужно гарантировать, что бюллетени выданы конкретным людям (и потом можно было посмотреть, кому именно — Иванов голосовал, Петров голосовал, а Сидоров скажет — какого лешего! Я на участок не ходил, а мне бюллетень выдали!), потом какая-то операция по ослеплению этого бюллетеня, чтобы нельзя было понять, чей именно бюллетень проголосовал, простановка голоса и передача его уже в «урну». И ещё, чтобы нельзя было в последний момент вкинуть много бюллетеней, при выдаче каждого бюллетеня на нём проставляется таймстемп, и в блокчейн оно должно попасть с таймстемпом. Тогда будет видно, что бюллетени выдавались равномерно в течение дня, а не в последний момент пенсионерам, которые не проголосовали, как это в оффлайне бывает.
Все так. Читать надо вместе со статьей про Fizz Buzz.
Но это не работает для преступлений против личности, разумеется.
Астрологи объявили неделю нумерологов.
Я неопытный программист на TS, может чего-то упускаю, но разве не проще вторую задачу решить так:
ApiResponse = SuccessfulApiResponse | FailedApiResponse | ...
SuccessfulApiResponse = {scenarioSuccess: true, response: string, error: null}
FailedApiResponse = {scenarioSuccess: false, response: null, error: string}
Т.е. мы просто перечисляем валидные комбинации параметров, а дальше TS не даст сконструировать неверную комбинацию. Да, можно потом "отредактировать" ApiResponse и ввести его в невалидный режим, но это надо постараться ещё сделать - от случайных ошибок защитит.
Так, наживка проглочена. Где же тот файл, который не стоит видеть посторонним?
Ваш метод не во всех странах можно использовать. Скажем, пенсионные взносы в Швейцарии прилично отгрызают от зарплаты, и "на руки" денег остаётся мало, но пенсия накопительная, ее не конфискуют, и со временем ее можно вытащить — или на покупку недвижимости, или на открытие бизнеса, или собственно на старость. Почему бы эти деньги не считать?
А, вы про ядро же… Тут да. Но если это вдска, то есть ещё и хост-система, которую вы не контролируете вообще, и железо с непонятными прошивками. Тут все зависит от вашей модели безопасности — если за вами скажем охотятся крупные государства, то вам вообще про вдски лучше забыть.
Докер-образ ничем в этом плане не отличается от исо-образа. Или его собираете вы лично, или несёте риски безопасности.
Докер-контейнер не проще запустить? Ядро как раз берете от хостера — оно может быть затюнено под их железо и инфраструктуру, а все прочее приносите а образе.
Ещё не нашел в статье важный момент — requests как по cpu, так и по памяти участвует не только в планировании раскладки подов по нодам, но ещё и даёт гарантированную ёмкость подам. Если под запросил скажем 1 cpu, а лимит — 2 cpu, то вот этот один будет на уровне cgroups выделен с высоким приоритетом, а уж если на машине остались свободные ресурсы, тогда они распилятся между теми контейнерами, которым хочется ещё.
Ну и про работу oom-киллера. Если память на машине физически кончилась, то контейнеры будут убиваться даже до достижения лимита. И тут важный момент — чем больше превышение использование памяти над requests, тем больше вес у этого контейнера, чтобы его убить.
Увидел название — подумал: "О как круто, наконец новичкам объяснят, что бенчмарки должны отражать то, что программа будет делать в жизни, на том железе, что будет в жизни, при том же уровне загрузки системы и т.д., что производительность программ зависит не только от cpu-bound кусков (если это не математическое вычисление, конечно, и не симуляция), и что производительность — многомерная величина — есть много узких мест, она не линейная — два процессора могут не удвоить скорость работы и т.д. и т.д. и т.д."
А тут — даже не знаю… Ну померит новичок скорость вызова функций, развернет циклы, а потом сделает 1 запрос к базе данных, и производительность упадет на 3 порядка.
Вот кстати это как раз хороший пример получился того, как зачастую разработчики решают не ту проблему (более общую, более сложную, просто другую), и в итоге решение накапливает в себе сложность предметной области, которой оно касаться не должно.
Например, нужно было придумать систему для простого умножения, а разработчик зачем-то добавил туда возможность лёгкой оценки порядка величины. Или наоборот.
В итоге решение получилось более сложным, чем могло быть.
Расскажите, пожалуйста! Я интуитивно понимаю, что это должно помочь, но как именно, хотелось бы подробностей.
Есть ли организационная возможность у ДИТ ответить мэрии, что в указанные сроки качественное исполнение работы невозможно в принципе, и отказаться от задачи? Предпринимались ли соответствующие попытки?
Яндекс вместо того, чтобы полностью блокировать приложение, мог бы установить аналогичную норму для синхронизации файлов. Синхронизировать документы — пожалуйста, а бэкапить базы данных — сорян.
Нужно гарантировать, что бюллетени выданы конкретным людям (и потом можно было посмотреть, кому именно — Иванов голосовал, Петров голосовал, а Сидоров скажет — какого лешего! Я на участок не ходил, а мне бюллетень выдали!), потом какая-то операция по ослеплению этого бюллетеня, чтобы нельзя было понять, чей именно бюллетень проголосовал, простановка голоса и передача его уже в «урну». И ещё, чтобы нельзя было в последний момент вкинуть много бюллетеней, при выдаче каждого бюллетеня на нём проставляется таймстемп, и в блокчейн оно должно попасть с таймстемпом. Тогда будет видно, что бюллетени выдавались равномерно в течение дня, а не в последний момент пенсионерам, которые не проголосовали, как это в оффлайне бывает.
А где гарантия, что условный ЦИК не напечатает "лишних" ключиков и не доложит в нужную корзинку?