Представляю вашему вниманию перевод статьи «How the Boeing 737 Max Disaster Looks to a Software Developer» Грега Трэвиса. Речь пойдет о том, как желание Боинга сэкономить и «срезать углы» для коммерческой выгоды, а также культура «некомпетентности и неэтичности» в сообществе разработчиков привело к гибели 346 человек. Я не во всем разделяю позицию автора (в частности, я считаю, что человеческий фактор куда большее зло, чем ПО), но с основными доводами сложно не согласиться.

Ниже очень много букв. Если читать лень, а ознакомиться с темой хочется, то на Хабре есть первая, более короткая версия этой статьи в переводе Вячеслава Голованова, с ней можно ознакомиться здесь.

Большинство разработчиков на MySQL знакомы с командой EXPLAIN, однако значительно меньше людей знают о команде EXPLAIN EXTENDED, появившуюся ещё в MySQL 4.1, и ещё меньше умеют ею пользоваться.

EXPLAIN EXTENDED умеет показывать, что же конкретно делает с Вашим запросом оптимизатор MySQL. Для разработчика может быть совсем не очевидно, насколько сильно может отличаться написанный им запрос от того, который в действительности будет выполнен сервером. Этот процесс называется механизмом перезаписи запросов (query-rewrite), и он является частью любого хорошего SQL-оптимизатора. Команда EXPLAIN EXTENDED добавляет дополнительные предупреждения (warnings) к выводу команды EXPLAIN, в том числе и переписанный SQL-запрос.

Задача: получить вчерашний день и день_неделю_назад на JavaScript'е. Пишу простой скриптик:
var dateToday = new Date();
var tmpDate = new Date();

tmpDate.setDate(dateToday.getDate() - 8);
alert(dateToday); // <- Jun 07, OK
alert( tmpDate ); // <- May 30, OK

tmpDate.setDate(dateToday.getDate() - 1);
alert(dateToday); // <- Jun 07, OK
alert( tmpDate ); // <- May 06, Oooops!

Казалось бы, что тут особенного? Давайте посмотрим, чего я хотел и что получил:
— Создаю два разных объекта типа Date и записываю их в переменные dateToday и tmpDate. Сейчас здесь находится «сегодня»;
— Устанавливаю значение tmpDate в (dateToday — 8 дней), т.е. если сегодня 7 июня, то это получается 30 мая, всё верно. Выводит значение tmpDate — действительно, 30 мая;
— Теперь я хочу получить вчерашний день. Беру значение dateToday (оно нигде не менялось и хранит день сегодняшний) и вычитаю из него 1 день. Я должен получить 6 июня;
— Alert выводит 5 мая!

В чём причина такого странного поведения скрипта? А в том, что у объекта Date свойства день, месяц, год, час и т.п. никак не взаимосвязаны, поэтому первая установка выставила месяц = 5, день = 30, а вторая — только день = 5. Отсюда и получаем 5 мая.

Что делать? Заново инициализировать переменную перед вторым действием. Т.е.:
var dateToday = new Date();
var tmpDate = new Date();

tmpDate.setDate(dateToday.getDate() - 8);
alert(dateToday); // <- Jun 07, OK
alert( tmpDate ); // <- May 30, OK

tmpDate = new Date();

tmpDate.setDate(dateToday.getDate() - 1);
alert(dateToday); // <- Jun 07, OK
alert( tmpDate ); // <- Jun 06, OK!

Для меня это была совершенно неочевидная вещь, потратил полчаса драгоценного времени ;)

Я часто вижу ошибки, связанные с созданием индексов в MySQL. Многие разработчики (и не только новички в MySQL) создают много индексов на тех колонках, которые будут использовать в выборках, и считают это оптимальной стратегией. Например, если мне нужно выполнить запрос типа AGE=18 AND STATE='CA', то многие люди просто создадут 2 отдельных индекса на колонках AGE и STATE.

Намного лучшей (здесь и далее прим. переводчика: а обычно и единственной верной) стратегией является создание комбинированного индекса вида (AGE,STATE). Давайте рассмотрим почему это так.

Введение

В данном списке перечислены шрифты, общие для всех актуальных на данный момент операционных систем Windows (фактически начиная с Windows 98), и их эквиваленты в Mac OS. Такие шрифты иногда называют «безопасными шрифтами для браузеров» (browser safe fonts). Это небольшой справочник, которым я пользуюсь, когда делаю Web-страницы и думаю, что он будет полезен и Вам.

Вольный перевод довольно старой статьи с MySQL Performance Blog о том, что лучше сразу же настроить после установки базовой версии mySQL.

Несмотря на то, что ещё в середине июня 2008 года Джим Старки (в тот момент глава команды, работающей над движком Falcon) покинул проект, и вообще на весьма туманные перспективы использования данного движка в следующих версиях mySQL, хотелось бы поделиться тем, что разработчики хотели в нём реализовать.