Начнём с того, что магия — это технология, которую вы не понимаете.
Итак, практика: 100 IOPS random read дадут вам 3 мб/с, 100 IOPS последовательных чтений дадут 30 мб/с при сравнимой latency. Что это говорит? Что время чтения 1 сектора сильно меньше времени позиционирования головки. У вас другая реальность? NCQ, кстати, замедляет доступ к диску, зато даёт возможность сделать больше IO операций в секунду. Latency при включении NCQ растёт, т.к. появляется ещё одна очередь запросов.
Читают и пишут обычно так, как удобно. Единственное, если читать по 100 байт — то количество сисколов будет слишком большим, и тормозить будет уже из-за этого. Но читать с диска сразу мегабайты/гигабайты, как-то кешировать внутри своей системы, следить за этим — это переписывать pagecache операционной системы. Особенно когда у вас индексы для данных перестают помещаться в память, ну очень нетривиальный код будет. Попахивает велосипедизмом.
Кстати, я разве где-то писал, что pagecache = writeback cache? Если какая-то из подсистем windows держит огроменный writeback cache — это, конечно, не всегда хорошо. Но обычно в pagecache мало грязных страниц, даже если вы интенсивно пишете на диск. Вот вам пример с реальной машинки:
На неё постоянно сыпется нагрузка в несколько сотен запросов в секунду на чтение и запись, каждая по несколько килобайт.
Мне кажется, что очень даже хорошо — память используется, данные кешируются, и всё это делает ОС для меня. Коллега, linux kernel hacker, тоже считает, что надо по-максимуму использовать то, что даёт сама операционная система, и что её писали далеко не глупые люди. Но тем не менее регулярно находятся господа, которые пишут свой «TCP» поверх UDP, и в некоторых тестах их реализация работает действительно лучше TCP. Правда в других — сильно сливает, и именно поэтому стоит использовать TCP вместо своих велосипедов.
Кстати, на счёт вашего выпада в первом посте про десятки гигабайт… У меня обычно по полсотни терабайт данных на сервер. И по несколько сотен тебарайт на кластер.
Идея readahead проста:
— прочитать с диска (обычного крутящегося, не SSD) несколько секторов занимает практически столько же времени, сколько и прочитать 1 сектор
— чаще всего данные читают последовательно
Конечно, нельзя придумать универсальные цифры подходящие под все условия, поэтому он адаптируется, отталкиваясь от базового значения, которое вы и меняете.
Если какое-то приложение плохо работает с readahead — то это означает либо то, что оно плохо работает с диском, либо оптимизировано для работы с SSD.
А зачем вам на машине свободная память? Они же не обязательно все грязные, большинство сразу сбрасывается на диск. Когда память понадобится — быстренько освободится. Во всяком случае, в линуксе так. Free памяти на сервере быть совсем немного, на десктопе можно побольше, но тоже нечего ей простаивать.
Вот, правдоподобные хорошие цифры (не мои, из интернетов):
Наверное, в разных, да. И у нас почему-то readahead в линуксе работает хорошо. Может, потому, что мы не монгу используем? Надо только хорошо понимать, когда он хорош, а когда плох, когда надо как можно агрессивнее забивать pagecache данными, а что лучше не помещать туда, как расположить данные на диске, чтобы они быстрее считывались. Под заканчивающейся памятью вы что имеете в виду? А под гигабайтами в час — это запись на диск, или чтение? Какой размер каждой записи? Как именно они располагаются на диске?
Вы точно хотите меряться представлениями о высокой нагрузке?
Readahead — это магия, которую уже сделали, просто пользуйтесь fadvise для указания профиля работы с данными. Мы юзаем и работает это хорошо. Если какая-то БД умеет работать с диском лучше, то пусть флашки указывает, или в документации пишут, как закрутить readahead. Если она только считает, что может работать лучше — то тут ещё непонятно, кто виноват в смерти диска по io.
Про десятки гигабайт данных — это вы мне написали, или автору статьи?
Пункт 9 — менеджер задач уже встроен в ядро ОС. Если у вас много IO операций — либо делайте больше потоков, чем ядер, либо используйте асинхронное IO (что, суть, одно и то же). Писать свой менеджер задач в большинстве случаев не стоит.
Вторая половина пункта 11 тоже спорная, современные ОС умеют распределять процессы с учётом множества факторов.
Пункты 12-14 — опять же, в современных ОС есть readahead, writeback, pagecache… Не стоит советовать переписывать их. Лучше поставить в сервер побольше памяти :)
Я к тому, что пока есть тэг — то вне зависимости от наличия DPI всё равно будет нужен.
Ну и если оставить тег чисто информационным и явно сказать об этом, то у провайдеров не будет возникать желания потратить деньги на навороченную DPI-систему, которую по факту все равно не получится использовать по назначению.
Советую убрать output_buffers и fastcgi_hide_header вместе с fastcgi_ignore_headers, потом попробовать.
Скорее всего для правильного кеширования надо будет попилить csm-ки.
# Директива уменьшает разрешение времени в рабочих процессах, за счёт чего уменьшается число системных вызовов gettimeofday().
timer_resolution 100ms;
Нет особого смысла, во всех современных ядрах/дистрибутивах gettimeofday работает не через системный вызов.
#Организовываем кеш для FastCGI сервера, я использую раздел в ram
fastcgi_cache_path /tmp/fcgi-cache/ levels=1:2 keys_zone=one:10m;
10 мегабайт всего? Думаю, для продакшена надо будет увеличить :) Кстати, у вас сейчас в access.log записывается HIT/MISS?
#Расширяем буфера отдачи
output_buffers 32 512k;
Зачем? Много лишней памяти?
#Если не использовать эту опцию — то в форумах все будут сидеть под именем первого вошедшего на форум
fastcgi_hide_header «Set-Cookie»;
#Этот запрос заставит nginx кешировать все что проходит через него
fastcgi_ignore_headers «Cache-Control» «Expires»;
Очень странное сочетание. Сначала заставляете нгинкс кешировать страницы авторизации, которые куки выставляют, а потом тупо запрещаете установку кук. Пользователи не устанут каждый раз логиниться при заходе на сайт?
Ооо, я нашёл в вашем оригинальном посте, что же помещают в except реальные программисты:
Если вы видите, что гениальный коллега произвёл фигню, ни в коем случае не надо обращаться к нему с намёками про то, что файлы не всегда открываются или исходные данные не всегда правильны. Это приведёт только к ненужным дискуссиям о вероятностях, надёжности и тупых пользователях. Особенно, если гений получил гуманитарное образование или докторскую по программизму. В немецких условиях возникнут ещё траблы с начальством.
Настоящий циничный идиот просто вставляет в нужное место ловушку, которая производит останов, когда случается невозможное, и код гениального коллеги выдаёт мусор, и терпеливо ожидает на берегу реки.
Да, он прибежит. Да, он будет возмущён. Он расскажет про качество и искусство писать нормальный код. Намекнёт про криворуких раздолбаев, на неумение создавать правильные программы, на людей, которые вместо функциональности производят ошибки.
Вот тут главное — не поддаться моменту, не начать отстаивать свою гениальность, не указывать пальцем… Нужно искренне удивиться, не поверить, усадить рядом, попросить показать, спросить об условиях и результатах, медленно и подробно дойти до причин, а потом аккуратно и безжалостно ткнуть мордой в нассатое.
После чего изобразить искреннее удивление, поговорить о редких и невероятных случаях, и отправить гения с пойманным багом в зубах вносить «неожиданные дополнения».
Естественно, ни один язык и ни один тул этого не поддерживает. Потому что их создают гениальные программисты, а они ошибок не производят и всегда знают, каким мир должен быть.
Смотрим выше, не поддерживает что?
Потому для меня самое частое средство отладки программы строка
die «OK!»;
Естественно, в большинстве случаев строчкой выше стоит $diag->DBG(...), который выводит всё, что я хотел узнать и что мне было интересно. Иногда это пара значений, иногда структура на полтора мегабайта, которая затем тщательно изучается ручками или программой.
не поддерживают точки останова с дебаг символами? Конечно поддерживают.
Потом, когда всё становится понятным, можно за собой убрать. Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Логгер не поддерживает разные уровни сообщений? Так любой нормальный логгер умеет это, некоторые даже умеют не компилировать добавление дебажных логов в релизной версии бинарника.
Что я не так понял? Вы имели в виду что-то другое, что не поддерживается?
Люди пытаются доказать, что «на самом деле всё совсем не так». Вот только попытки всё с какими-то левыми сказками и нерелевантными собственными переживаниями и от сертификаций внезапно перескакивают к страничкам на яваскрипте…
Простите, но это смешно. Во-первых, вы сами перескочили с темы отсутствия багов к сертифицикации. Я даже специально процитирую другой ваш комментарий:
априори считается, что базовые библиотеки типа STL работают без ошибок
Блажен, кто верует. Особенно, после того, как засунул туда то, что совать туда было не надо. Кстати, в софте, для которого важна надёжность, библиотеки допускаются только сертифицированные. Про сертификацию STL я ничего не слышал. По крайней мере для тех областей, где работал. И это именно потому, что результат предсказать практически невозможно.
Вот как, как связано априорное доверие к STL и наличие у неё какого-либо сертификата для софта, который принципиально сертифицирован не будет? К тому же, голословно заявив, что «результат предсказать практически невозможно.» вы не назвали ни одной программы, которая бы использовала STL но перепроверяла потом результат. Кстати, запихнуть что-то плохое в стандартные контейнеры довольно сложно, если не использовать приведения типов — компилятор просто не даст вам это сделать.
Во-вторых, касательно скриптиков на яваскрипте… Их тоже надо писать, и в них тоже желательно не иметь ошибок. Вы где-то в статье писали, что всё написанное касается только сертифицируемого софта для поездов? Нет. Тогда чем плох скрипт на яваскрипте как пример программы, в которой надо избежать багов?
Забавненько. Люди, похоже, текст не читают, а сразу начинают с комментариев.
Ой, это разве в статье было? Я то думал, только комментарии читал…
Потому для меня самое частое средство отладки программы строка
die «OK!»;
Естественно, в большинстве случаев строчкой выше стоит $diag->DBG(...), который выводит всё, что я хотел узнать и что мне было интересно. Иногда это пара значений, иногда структура на полтора мегабайта, которая затем тщательно изучается ручками или программой.
Потом, когда всё становится понятным, можно за собой убрать. Правда, трассировку полезнее не удалять, а прятать в комментарий. Потому что ошибки имеют тенденцию возникать вновь, и не нужно будет выдумывать по новой, что и где стоит смотреть.
Естественно, ни один язык и ни один тул этого не поддерживает. Потому что их создают гениальные программисты, а они ошибок не производят и всегда знают, каким мир должен быть.
Тоже перл. Тем более, по сравнению с тем, что там на самом деле происходит и какие люди там работают.
Видимо, у вас таки личная обида. Разные там люди работают, зависит от жадности вендора.
Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
А вы как, по ключевым словам только ориентируетесь? Тогда повторю — вышеперечисленные компании — это тоже часть индустрии. Делают продукты, которыми успешно пользуется весь мир.
Автору это совершенно не нужно. Он пишет не для людей, которые определяют правильность мысли по звёздам на погонах.
Люди хотят понять, откуда у автора такие мысли. Раз вы обобщаете свой частный опыт на всю индустрию — будьте добры, обоснуйте. Или признайте, что это проблемы проектов, в которых вы участвовали.
1. Ни один человек не может удержать в голове систему размера ядра операционной системы.
2. Человеческий мозг не приспособлен для прокручивания в голове всех возможных негативных кейсов, потому что он природой заточен на положительные. Именно поэтому человек так хорошо играет в шахматы, ездит по треку лучше роботов и т.д.
3. Любой хороший программист выстраивает логику работы программы в голове (рисуя на бумажке, составляя майндмэпы или просто размышляя, кому как удобнее), а потом отражает её в коде.
У всех бывают ошибки, в том числе и у хирургов. Вопрос лишь в том, как минимизировать их количество. Для этого в критичных отраслях типа авиации давно придумали схемы, позволяющие максимально сократить количество ошибок в коде, и, самое главное, обнаружить их на как можно более раннем этапе разработки. Для обычных же программ, так сказать, повседневных, это сводится к 2-3 уровневому тестированию: (опционально) юнит-тесты, тесты, проводимые разработчиком на положительные и основные отрицательные кейсы, и полноценное функциональное тестирование продукта в prod-like среде, под похожей на реальную нагрузкой.
В целях минимизации ошибок в системах, разрабатываемых для mission critical задач, но не связанных непосредственно с человеческими жизнями, обычно применяются code style guide с жёсткими рамками (типа запрещения работы с динамической памятью) и специализированными фреймворками. В итоге возможность появления ошибок на стадии кодирования почти полностью исключена, а на стадии проектирования внесения изменений, требуемых бизнесом заказчика, решается за счёт двойной проверки.
В этом посте автор написал ряд очевидных мыслей (типа надо добавлять дебажные сообщения, писать внятные сообщения об ошибках, показывать пользователю ошибки на его языке, смотреть состояние в особых точках программы), ряд непонятных заблуждений (писать die т.к. нет брекпоинтов, что программисты не проверяют коды ошибок в коде, и что они вообще зазнайки и не хотят признавать своих ошибок, и что это — стандарт индустрии), и закончил пост никак.
Какие можно сделать выводы?
Может быть, автор работал с самыми дешёвыми аутсорсерами из индии, которые действительно обладают некоторыми из перечисленных качеств, такими, как нежелание признавать ошибки (азиатский тип мышления) и низкая квалификация? Но зачем тогда обобщать это, называть это стандартом для индустрии? Или может быть у автора был неудачный опыт с agile методологиями, опять же низкоквалифицированной командой? В любом случае, это не даёт повода ни автору, ни вам заявлять, что в индустрии всё так. Ведь индустрия — это в том числе Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
Особенно печально, что автор так и не указал, кто же он такой и чем занимается, откуда у него такая экспертная оценка состояния индустрии (и экспертная ли?). В комментариях он не отвечает на прямые вопросы, касающиеся частей статьи или его профессиональных навыков. Можно ли доверять экспертному мнению человека, который не подкрепил свои доводы ничем? Можно ли доверять экспертному мнению человека, который даже не написал, в какой именно области он эксперт?
Тут 2 варианта: либо писать хорошее приложение, либо тупо отвечать всем: «Вы используете несертифицированную ОС, поэтому мы вам не можем гарантировать работы нашего приложения.». И если карта ляжет, как у Оракла, то второй вариант вполне себе рабочий. Но я с вами согласен, отпинываться подобными фразами вместо починки ошибок и несовместимостей — это проблема, и её затронул автор поста:
Мозги критичны. Нужны люди особой культуры, не боящиеся выглядеть дураками, каких в ИТ практически не встречается.
<...>
Большинство такого не выдерживает. Страшно. И ронять чувство собственного достоинства тоже страшно. И лицо потерять… И начальство тоже…
Тут vit_r прав, сертифицированный софт требует сертифицированных библиотек, сертифицированной ОС и сертифицированного железа. Простейший пример — Oracle.
Если вы делаете в библиотеке assert, то вы автоматически не можете выполнить того, что написано у вас же в посте в разделе «Любой интерфейс должен возвращать ошибку на адекватном уровне». И, в ряде случаев, не можете выполнить даже то, что написано во второй половине поста, про логирование, т.к. логирование в библиотеке не всегда допустимо.
Честно говоря, где бы вы ни кидали ассерты — это автоматически лишает вас возможности проинформировать пользователя о возникшей проблеме, а из малопонятного «Assertion `jpeg_magic != JFIF' failed.» пользователь сможет узнать только то, что вы написали плохую программу.
Простите, а разве валидацией содержимого файла, jpeg ли это, не библиотека работы с jpeg изображениями должна заниматься? А нафига она мне тогда такая нужна, если она этим не занимается?
А что с ответами на остальные вопросы? Вы не способны на них ответить?
Если под решение придумывать задачу, можно далеко уехать.
Не знаю, какую задачу придумали вы, а я именно эту имел в виду изначально.
Ага. И виноват конечно пользователь. Или библиотека. А «я» — святой.
Внесите конструктивное предложение. Есть ваша библиотека, которая принимает на входе только jpeg и умеет его ресайзить. Есть пользователь, который прислал мне какие-то данные. Есть моя программа, которая хочет вашей библиотекой отресайзить картинку и сохранить её. Что делать, если пользователь пришлёт gif под видом jpeg (камера у него такая дурацкая, а в его операционной системе картинка отображается отлично)?
С одной стороны, «пользователь знать не желает», с другой стороны «он пишет, что внутри». В такой ситуации или крестик снять, или трусы надеть.
Угу, я щас пойду рассказывать девочке 13 лет, как открыть в hex редакторе бинарный файл и посмотреть его заголовок. У неё картинка внутри, она это отлично знает, потому что в просмоторщике фотографий на её компьютере картинка показывается.
Остальное настолько грустно, что оставлю без внимания.
Ну уж нет, раз написали статью — то потратьте ещё 15 минут и ответьте развёрнуто на вопросы к ней. Или времени нет? «В такой ситуации или крестик снять, или трусы надеть.»
Итак, практика: 100 IOPS random read дадут вам 3 мб/с, 100 IOPS последовательных чтений дадут 30 мб/с при сравнимой latency. Что это говорит? Что время чтения 1 сектора сильно меньше времени позиционирования головки. У вас другая реальность? NCQ, кстати, замедляет доступ к диску, зато даёт возможность сделать больше IO операций в секунду. Latency при включении NCQ растёт, т.к. появляется ещё одна очередь запросов.
Читают и пишут обычно так, как удобно. Единственное, если читать по 100 байт — то количество сисколов будет слишком большим, и тормозить будет уже из-за этого. Но читать с диска сразу мегабайты/гигабайты, как-то кешировать внутри своей системы, следить за этим — это переписывать pagecache операционной системы. Особенно когда у вас индексы для данных перестают помещаться в память, ну очень нетривиальный код будет. Попахивает велосипедизмом.
Кстати, я разве где-то писал, что pagecache = writeback cache? Если какая-то из подсистем windows держит огроменный writeback cache — это, конечно, не всегда хорошо. Но обычно в pagecache мало грязных страниц, даже если вы интенсивно пишете на диск. Вот вам пример с реальной машинки:
sync делается каждые 30 секунд, так что там практически нету грязных страниц.
На другой машинке похожая картина:
На неё постоянно сыпется нагрузка в несколько сотен запросов в секунду на чтение и запись, каждая по несколько килобайт.
Мне кажется, что очень даже хорошо — память используется, данные кешируются, и всё это делает ОС для меня. Коллега, linux kernel hacker, тоже считает, что надо по-максимуму использовать то, что даёт сама операционная система, и что её писали далеко не глупые люди. Но тем не менее регулярно находятся господа, которые пишут свой «TCP» поверх UDP, и в некоторых тестах их реализация работает действительно лучше TCP. Правда в других — сильно сливает, и именно поэтому стоит использовать TCP вместо своих велосипедов.
Кстати, на счёт вашего выпада в первом посте про десятки гигабайт… У меня обычно по полсотни терабайт данных на сервер. И по несколько сотен тебарайт на кластер.
— прочитать с диска (обычного крутящегося, не SSD) несколько секторов занимает практически столько же времени, сколько и прочитать 1 сектор
— чаще всего данные читают последовательно
Конечно, нельзя придумать универсальные цифры подходящие под все условия, поэтому он адаптируется, отталкиваясь от базового значения, которое вы и меняете.
Если какое-то приложение плохо работает с readahead — то это означает либо то, что оно плохо работает с диском, либо оптимизировано для работы с SSD.
А зачем вам на машине свободная память? Они же не обязательно все грязные, большинство сразу сбрасывается на диск. Когда память понадобится — быстренько освободится. Во всяком случае, в линуксе так. Free памяти на сервере быть совсем немного, на десктопе можно побольше, но тоже нечего ей простаивать.
Вот, правдоподобные хорошие цифры (не мои, из интернетов):
Вы правда считаете, что это плохо?
Вы точно хотите меряться представлениями о высокой нагрузке?
Про десятки гигабайт данных — это вы мне написали, или автору статьи?
Вторая половина пункта 11 тоже спорная, современные ОС умеют распределять процессы с учётом множества факторов.
Пункты 12-14 — опять же, в современных ОС есть readahead, writeback, pagecache… Не стоит советовать переписывать их. Лучше поставить в сервер побольше памяти :)
Скорее всего для правильного кеширования надо будет попилить csm-ки.
Нет особого смысла, во всех современных ядрах/дистрибутивах gettimeofday работает не через системный вызов.
10 мегабайт всего? Думаю, для продакшена надо будет увеличить :) Кстати, у вас сейчас в access.log записывается HIT/MISS?
Зачем? Много лишней памяти?
Очень странное сочетание. Сначала заставляете нгинкс кешировать страницы авторизации, которые куки выставляют, а потом тупо запрещаете установку кук. Пользователи не устанут каждый раз логиниться при заходе на сайт?
Смотрим выше, не поддерживает что?
не поддерживают точки останова с дебаг символами? Конечно поддерживают.
Логгер не поддерживает разные уровни сообщений? Так любой нормальный логгер умеет это, некоторые даже умеют не компилировать добавление дебажных логов в релизной версии бинарника.
Что я не так понял? Вы имели в виду что-то другое, что не поддерживается?
Простите, но это смешно. Во-первых, вы сами перескочили с темы отсутствия багов к сертифицикации. Я даже специально процитирую другой ваш комментарий:
Вот как, как связано априорное доверие к STL и наличие у неё какого-либо сертификата для софта, который принципиально сертифицирован не будет? К тому же, голословно заявив, что «результат предсказать практически невозможно.» вы не назвали ни одной программы, которая бы использовала STL но перепроверяла потом результат. Кстати, запихнуть что-то плохое в стандартные контейнеры довольно сложно, если не использовать приведения типов — компилятор просто не даст вам это сделать.
Во-вторых, касательно скриптиков на яваскрипте… Их тоже надо писать, и в них тоже желательно не иметь ошибок. Вы где-то в статье писали, что всё написанное касается только сертифицируемого софта для поездов? Нет. Тогда чем плох скрипт на яваскрипте как пример программы, в которой надо избежать багов?
Ой, это разве в статье было? Я то думал, только комментарии читал…
Видимо, у вас таки личная обида. Разные там люди работают, зависит от жадности вендора.
А вы как, по ключевым словам только ориентируетесь? Тогда повторю — вышеперечисленные компании — это тоже часть индустрии. Делают продукты, которыми успешно пользуется весь мир.
Люди хотят понять, откуда у автора такие мысли. Раз вы обобщаете свой частный опыт на всю индустрию — будьте добры, обоснуйте. Или признайте, что это проблемы проектов, в которых вы участвовали.
2. Человеческий мозг не приспособлен для прокручивания в голове всех возможных негативных кейсов, потому что он природой заточен на положительные. Именно поэтому человек так хорошо играет в шахматы, ездит по треку лучше роботов и т.д.
3. Любой хороший программист выстраивает логику работы программы в голове (рисуя на бумажке, составляя майндмэпы или просто размышляя, кому как удобнее), а потом отражает её в коде.
У всех бывают ошибки, в том числе и у хирургов. Вопрос лишь в том, как минимизировать их количество. Для этого в критичных отраслях типа авиации давно придумали схемы, позволяющие максимально сократить количество ошибок в коде, и, самое главное, обнаружить их на как можно более раннем этапе разработки. Для обычных же программ, так сказать, повседневных, это сводится к 2-3 уровневому тестированию: (опционально) юнит-тесты, тесты, проводимые разработчиком на положительные и основные отрицательные кейсы, и полноценное функциональное тестирование продукта в prod-like среде, под похожей на реальную нагрузкой.
В целях минимизации ошибок в системах, разрабатываемых для mission critical задач, но не связанных непосредственно с человеческими жизнями, обычно применяются code style guide с жёсткими рамками (типа запрещения работы с динамической памятью) и специализированными фреймворками. В итоге возможность появления ошибок на стадии кодирования почти полностью исключена, а на стадии проектирования внесения изменений, требуемых бизнесом заказчика, решается за счёт двойной проверки.
В этом посте автор написал ряд очевидных мыслей (типа надо добавлять дебажные сообщения, писать внятные сообщения об ошибках, показывать пользователю ошибки на его языке, смотреть состояние в особых точках программы), ряд непонятных заблуждений (писать die т.к. нет брекпоинтов, что программисты не проверяют коды ошибок в коде, и что они вообще зазнайки и не хотят признавать своих ошибок, и что это — стандарт индустрии), и закончил пост никак.
Какие можно сделать выводы?
Может быть, автор работал с самыми дешёвыми аутсорсерами из индии, которые действительно обладают некоторыми из перечисленных качеств, такими, как нежелание признавать ошибки (азиатский тип мышления) и низкая квалификация? Но зачем тогда обобщать это, называть это стандартом для индустрии? Или может быть у автора был неудачный опыт с agile методологиями, опять же низкоквалифицированной командой? В любом случае, это не даёт повода ни автору, ни вам заявлять, что в индустрии всё так. Ведь индустрия — это в том числе Intel, Microsoft, Google, Amazon, да тот же Яндекс, в конце концов.
Особенно печально, что автор так и не указал, кто же он такой и чем занимается, откуда у него такая экспертная оценка состояния индустрии (и экспертная ли?). В комментариях он не отвечает на прямые вопросы, касающиеся частей статьи или его профессиональных навыков. Можно ли доверять экспертному мнению человека, который не подкрепил свои доводы ничем? Можно ли доверять экспертному мнению человека, который даже не написал, в какой именно области он эксперт?
Однако сертифицированный != безошибочный. it.slashdot.org/story/11/12/20/0127215/software-bug-caused-qantas-airbus-a330-to-nose-dive. При этом в гражданской авиации одна из самых строгих систем сертификации.
Честно говоря, где бы вы ни кидали ассерты — это автоматически лишает вас возможности проинформировать пользователя о возникшей проблеме, а из малопонятного «Assertion `jpeg_magic != JFIF' failed.» пользователь сможет узнать только то, что вы написали плохую программу.
А что с ответами на остальные вопросы? Вы не способны на них ответить?
Не знаю, какую задачу придумали вы, а я именно эту имел в виду изначально.
Внесите конструктивное предложение. Есть ваша библиотека, которая принимает на входе только jpeg и умеет его ресайзить. Есть пользователь, который прислал мне какие-то данные. Есть моя программа, которая хочет вашей библиотекой отресайзить картинку и сохранить её. Что делать, если пользователь пришлёт gif под видом jpeg (камера у него такая дурацкая, а в его операционной системе картинка отображается отлично)?
Угу, я щас пойду рассказывать девочке 13 лет, как открыть в hex редакторе бинарный файл и посмотреть его заголовок. У неё картинка внутри, она это отлично знает, потому что в просмоторщике фотографий на её компьютере картинка показывается.
Ну уж нет, раз написали статью — то потратьте ещё 15 минут и ответьте развёрнуто на вопросы к ней. Или времени нет? «В такой ситуации или крестик снять, или трусы надеть.»