Конечно - было можно, потому как в те годы собрать армию, чтобы из ханства или княжества (а не из хана или князя - ЕМНИП половцы в какой-то момент стали данниками уже Руси) выбить дань, занимало пару лет, и стоило как солидная часть этой дани плюс долгосрочные проблемы в виде потерь активного населения в войнах, а сейчас, когда налоги платит конкретная морда, а достать до неё стало как два байта переслать, стало нельзя.
стабилизаторы. те, кто работает, в той конфигурации, в которой достигается искомый эффект, нестабильны, и приходится держать овер9к структурных элементов, чтобы конфигурация не развалилась.
Не совсем так - у Windows некоторые файлы не подлежат перемещению, ЕМНИП какой-то внутренний флаг либо открытия, либо создания файла. Дефрагментация в режиме full перемещает к началу что может, а если есть неперемещаемые файлы, их не трогает, пустой хвост в конце появляется, но отсечь можно только по последний занятый блок. Оффлайн-дефраг забыл, спасает ли, его умеет делать Paragon (не он один, но с ним я работал), и да, после такого дефрага диск можно уменьшить.
На удалёнке кстати веселее всего - помимо коллег/менеджеров есть такой отвлекающий фактор как дети (особенно маленькие). КПД реально улетает в 0, пока не отправишь бродкастом 403 (хорошо, ICMP REJECT) и не врубишь внешний фаерволл.
Если внешний сервис начал возвращать json, не соответствующий согласованной схеме взаимодействия, виноват внешний сервис, а если наш код не обработал ошибку валидации ответа, виноват тот, кто должен был её написать и проверить. (Хотя в соседней ветке в этом случае говорят более правильно - виновата команда как целое, один забыл обработать ошибку, второй забыл тесты написать, третий забыл согласовать схему, четвёртый забыл обработать сообщение от внешнего сервиса об её изменении, пятый не продумал, как такие сообщения обрабатывать вообще, шестой нормально эскалацию не провёл, и так далее - главное для заказчика, что "программа не работает"). При обновлении зависимостей - в идеале таки да, QA должен все тесты прогонять, включая нагрузочный, на практике всплывает всякое, а чаще всего обновляться приходится в темпе из-за найденной CVE или пойманной ИБшниками атаки (ну или прошедшей, что хуже), и на полное тестирование банально нет времени. А вот если сервис падает внутри зависимости - вопрос пожалуй не ко мне, а к архитектору, что делать, патчить зависимость своими силами, пилить обход бага в своём коде, менять зависимость на аналог, ждать патча от коммьюнити или мейнтейнера, или вообще сменить к хренам стек. И каждый вариант имеет свою стоимость, шансы на успех, доступность и остальные факторы, влияющие на релиз.
Не оружия, а щита, TLS это защитный протокол. Ну и когда все со щитами, хороший тон также переодеться в одежду со щитом. Это раз. И два - когда хитрые провайдеры мобильной связи твой лендинг изгадят рекламой себя или "партнёров" при передаче по HTTP, за что ты огребёшь повестку в суд как ответчик, так как реклама будет "на твоём сайте", сразу станет понятно, чем было лучше иметь TLS.
Вроде бы нет, инфраструктура ЦС отделена от API, просто сертификаты начнут приходить от другого ЦС и сильно короче по срокам. Возможно, понадобится подправить предел срабатывания certbot'а, чтобы не менял сертификат раз в (47-31) дней, но и всё.
Вот взял и загуглил - нашел, что на двор налоги были, а на остальное именно при Грозном не было. Из цифр нашел "20 рублей за соху" в год, где "соха" это площадь земли, зависящая от положения платящего налоги (500-800 четвертей, или 250-400 га, Вики), при этом корова стоила 10-16 копеек, а четверть ржи - 8-15 копеек (столько, сколько уходит на посев на 1 четверть земли - точнее, обратная зависимость). То есть налог за довольно большое поле был в ~150 коров или около 15% в зерне на посев (1-3% урожая, а когда и больше - недород в те времена был бедствием довольно частым). Но там было много сборов на использование "государевых" объектов, от гостиниц до дорог и складов, и неизвестно, чего в итоге больше платили.
Шринкфляция это подстраивание производителей под супермаркеты, а пипл и так схавает. Под этим всем лежит простая математика - если увеличить цену упаковки на 10%, то доход вырастет на 10%, а если уменьшить объём упаковки на 10%, то доход вырастет на 11%. На этот процент и живут. Супермаркеты в некоторых случаях ограничивают ценовой диапазон на виды продуктов в них, из-за чего к выбору добавляется фактор позиционирования - или остаться в текущей сети с примерным потреблением в столько же, или переехать в "более престижную" и конкурировать там с продуктами другого диапазона по цене и качеству и потерять в сбыте (в среднем потерять), но с возможностью поднять цену. Чаще математика даже с переналадкой упаковочного цеха показывает большую прибыль у варианта с уменьшением упаковки. В итоге имеем что имеем, и из этого круга толком не вырваться. Запланированное устаревание - скорее попытка производителей обеспечить себе рынок сбыта на более длинной дистанции и после насыщения в моменте, опять-таки математически обоснованная, правда математика уже не на коленке расписывается.
Для этого входная стоимость должна быть нулевой. А она как-то уж очень сильно отличается от нуля для большого сегмента устройств с подписками на базовый функционал.
зажигалка против стиральной машины? неплохое сравнение. Ну и дьявол в деталях - если пойдут массовые отказы, ООО схлопывается и все дороворы о замене превращаются в тыкву. А устройства как просили наличие подписки, так и будут просить, и при таких вводных превратятся тоже в тыкву, даже рабочие.
Разработчик развернул код на деве, оттестировал - ОК. QA раздеплоил код на тест, оттестировал - ОК, девопсы или команда поддержки прода раздеплоили код на прод - упало. Кто виноват? По мне - в явном виде вина разработчика не видна, потому что по пути с дева на прод код прошел несколько других валидаций, и если в нём есть баг, его надо было поймать раньше, а если входные данные вызвали некорректное поведение, надо как минимум дополнить тесты, проверить наличие ретроградных поломок, ещё кучу всего в зависимости от детализации проблемы - но не всё это должен делать разработчик. Фиксить сам баг - да, его работа, но баг мог оказаться, например, в ТЗ, неоднозначная интерпретация которого вызвала каскад необнаружимых ошибок. Вот мы не так давно деплоили оттестированный код на прод - упало с треском, а баг был в некорректной процедуре деплоя на прод (не хватило прав у деплоящей УЗ, упор в бюрократию не позволил им создать выделенную именно для деплоя, контроль также в бюрократии погряз). Облаяли в итоге нас, всё равно.
Постмортем нужен в любом случае, даже если виноватого назначили, а не нашли.
Торт есть надо, а не поддерживать /s А вот какие банки подерживают ТОТР для входа через веб-кабинет - хотел бы знать, потому как если кто-то и поддерживает, то "в приложении", что эквивалентно объединению факторов аутентификации.
Если прод падает именно у разработчика, то виноват QA, потому что должен был упасть тест (а то и дев), либо девопс прода, который что-то не то запилил при выкатке обновления. Разработчик тут должен быть не при делах. Но это в идеале, который мало где достижим.
Скорее перевод, я оригинал понял как изучение модели травмирования глазного нерва, а не сетчатки, то есть сетчатка оставалась целой, но терялись связи от сетчатки к мозгам. И где-то на дороге что-то начало ветвиться (surviving RGC axons - видимо те клетки, которые не порвались при травме глазного нерва), восстанавливая уровень передачи информации с сетчатки в мозг.
А если отрубить архитектурно-специфические тесты вроде AES, которые с тех пор ускорили аппаратно, сколько останется?
Конечно - было можно, потому как в те годы собрать армию, чтобы из ханства или княжества (а не из хана или князя - ЕМНИП половцы в какой-то момент стали данниками уже Руси) выбить дань, занимало пару лет, и стоило как солидная часть этой дани плюс долгосрочные проблемы в виде потерь активного населения в войнах, а сейчас, когда налоги платит конкретная морда, а достать до неё стало как два байта переслать, стало нельзя.
Угу, смыть повторить.
стабилизаторы. те, кто работает, в той конфигурации, в которой достигается искомый эффект, нестабильны, и приходится держать овер9к структурных элементов, чтобы конфигурация не развалилась.
Не совсем так - у Windows некоторые файлы не подлежат перемещению, ЕМНИП какой-то внутренний флаг либо открытия, либо создания файла. Дефрагментация в режиме full перемещает к началу что может, а если есть неперемещаемые файлы, их не трогает, пустой хвост в конце появляется, но отсечь можно только по последний занятый блок. Оффлайн-дефраг забыл, спасает ли, его умеет делать Paragon (не он один, но с ним я работал), и да, после такого дефрага диск можно уменьшить.
На удалёнке кстати веселее всего - помимо коллег/менеджеров есть такой отвлекающий фактор как дети (особенно маленькие). КПД реально улетает в 0, пока не отправишь бродкастом 403 (хорошо, ICMP REJECT) и не врубишь внешний фаерволл.
Если внешний сервис начал возвращать json, не соответствующий согласованной схеме взаимодействия, виноват внешний сервис, а если наш код не обработал ошибку валидации ответа, виноват тот, кто должен был её написать и проверить. (Хотя в соседней ветке в этом случае говорят более правильно - виновата команда как целое, один забыл обработать ошибку, второй забыл тесты написать, третий забыл согласовать схему, четвёртый забыл обработать сообщение от внешнего сервиса об её изменении, пятый не продумал, как такие сообщения обрабатывать вообще, шестой нормально эскалацию не провёл, и так далее - главное для заказчика, что "программа не работает").
При обновлении зависимостей - в идеале таки да, QA должен все тесты прогонять, включая нагрузочный, на практике всплывает всякое, а чаще всего обновляться приходится в темпе из-за найденной CVE или пойманной ИБшниками атаки (ну или прошедшей, что хуже), и на полное тестирование банально нет времени.
А вот если сервис падает внутри зависимости - вопрос пожалуй не ко мне, а к архитектору, что делать, патчить зависимость своими силами, пилить обход бага в своём коде, менять зависимость на аналог, ждать патча от коммьюнити или мейнтейнера, или вообще сменить к хренам стек. И каждый вариант имеет свою стоимость, шансы на успех, доступность и остальные факторы, влияющие на релиз.
Не оружия, а щита, TLS это защитный протокол. Ну и когда все со щитами, хороший тон также переодеться в одежду со щитом. Это раз. И два - когда хитрые провайдеры мобильной связи твой лендинг изгадят рекламой себя или "партнёров" при передаче по HTTP, за что ты огребёшь повестку в суд как ответчик, так как реклама будет "на твоём сайте", сразу станет понятно, чем было лучше иметь TLS.
Вроде бы нет, инфраструктура ЦС отделена от API, просто сертификаты начнут приходить от другого ЦС и сильно короче по срокам. Возможно, понадобится подправить предел срабатывания certbot'а, чтобы не менял сертификат раз в (47-31) дней, но и всё.
Вот взял и загуглил - нашел, что на двор налоги были, а на остальное именно при Грозном не было. Из цифр нашел "20 рублей за соху" в год, где "соха" это площадь земли, зависящая от положения платящего налоги (500-800 четвертей, или 250-400 га, Вики), при этом корова стоила 10-16 копеек, а четверть ржи - 8-15 копеек (столько, сколько уходит на посев на 1 четверть земли - точнее, обратная зависимость). То есть налог за довольно большое поле был в ~150 коров или около 15% в зерне на посев (1-3% урожая, а когда и больше - недород в те времена был бедствием довольно частым). Но там было много сборов на использование "государевых" объектов, от гостиниц до дорог и складов, и неизвестно, чего в итоге больше платили.
Шринкфляция это подстраивание производителей под супермаркеты, а пипл и так схавает. Под этим всем лежит простая математика - если увеличить цену упаковки на 10%, то доход вырастет на 10%, а если уменьшить объём упаковки на 10%, то доход вырастет на 11%. На этот процент и живут. Супермаркеты в некоторых случаях ограничивают ценовой диапазон на виды продуктов в них, из-за чего к выбору добавляется фактор позиционирования - или остаться в текущей сети с примерным потреблением в столько же, или переехать в "более престижную" и конкурировать там с продуктами другого диапазона по цене и качеству и потерять в сбыте (в среднем потерять), но с возможностью поднять цену. Чаще математика даже с переналадкой упаковочного цеха показывает большую прибыль у варианта с уменьшением упаковки. В итоге имеем что имеем, и из этого круга толком не вырваться.
Запланированное устаревание - скорее попытка производителей обеспечить себе рынок сбыта на более длинной дистанции и после насыщения в моменте, опять-таки математически обоснованная, правда математика уже не на коленке расписывается.
Они под одесситов косят с этим "за" и другими подобными фразами.
Для этого входная стоимость должна быть нулевой. А она как-то уж очень сильно отличается от нуля для большого сегмента устройств с подписками на базовый функционал.
зажигалка против стиральной машины? неплохое сравнение. Ну и дьявол в деталях - если пойдут массовые отказы, ООО схлопывается и все дороворы о замене превращаются в тыкву. А устройства как просили наличие подписки, так и будут просить, и при таких вводных превратятся тоже в тыкву, даже рабочие.
Разработчик развернул код на деве, оттестировал - ОК. QA раздеплоил код на тест, оттестировал - ОК, девопсы или команда поддержки прода раздеплоили код на прод - упало. Кто виноват? По мне - в явном виде вина разработчика не видна, потому что по пути с дева на прод код прошел несколько других валидаций, и если в нём есть баг, его надо было поймать раньше, а если входные данные вызвали некорректное поведение, надо как минимум дополнить тесты, проверить наличие ретроградных поломок, ещё кучу всего в зависимости от детализации проблемы - но не всё это должен делать разработчик. Фиксить сам баг - да, его работа, но баг мог оказаться, например, в ТЗ, неоднозначная интерпретация которого вызвала каскад необнаружимых ошибок. Вот мы не так давно деплоили оттестированный код на прод - упало с треском, а баг был в некорректной процедуре деплоя на прод (не хватило прав у деплоящей УЗ, упор в бюрократию не позволил им создать выделенную именно для деплоя, контроль также в бюрократии погряз). Облаяли в итоге нас, всё равно.
Постмортем нужен в любом случае, даже если виноватого назначили, а не нашли.
А для этого есть venv и возможность скопировать всю папку с бинарями.
Торт есть надо, а не поддерживать /s А вот какие банки подерживают ТОТР для входа через веб-кабинет - хотел бы знать, потому как если кто-то и поддерживает, то "в приложении", что эквивалентно объединению факторов аутентификации.
Если прод падает именно у разработчика, то виноват QA, потому что должен был упасть тест (а то и дев), либо девопс прода, который что-то не то запилил при выкатке обновления. Разработчик тут должен быть не при делах. Но это в идеале, который мало где достижим.
Скорее перевод, я оригинал понял как изучение модели травмирования глазного нерва, а не сетчатки, то есть сетчатка оставалась целой, но терялись связи от сетчатки к мозгам. И где-то на дороге что-то начало ветвиться (surviving RGC axons - видимо те клетки, которые не порвались при травме глазного нерва), восстанавливая уровень передачи информации с сетчатки в мозг.
Если у смарта бахнет батарея, SD-карта тоже сгорит. Так что бэкап вовне смарта таки нужен.