Вашему вниманию предлагается перевод статьи Рэймонда Чена из блога The Old New Thing, посвященной проблемам кода, полагающегося на порядок вычисления выражений — и всем тем, кто пишет foo(i++, a[i]);

Порядок вычисления выражений определяется конкретной реализацией, за исключением случаев, когда язык гарантирует определенный порядок вычислений. Если же в дополнение к результату вычисление выражения вызывает изменения в среде выполнения, то говорят, что данное выражение имеет побочные эффекты.
MSDN

В нашей внутренней рассылке про C# регулярно возникает дискуссионный вопрос, который касается корректной интерпретации подобных конструкций:

a -= a *= a;
p[x++] = ++x;

В ответ я спрашиваю:

Да кто вообще пишет такой код с невозмутимым видом? Одно дело, когда такое пишешь, пытаясь победить в «Международном Конкурсе запутывания кода на Си» (IOCCC, International Obfuscated C Code Contest), или если хочешь написать головоломку — но в обоих случаях понимаешь, что ты занимаешься чем-то нестандартным. Что, реально есть кто-то, кто пишет a -= a *= a и p[x++] = ++x; и думает про себя «Чёрт возьми, да я пишу действительно классный код!»

Забавной находкой поделился сегодня пользователь fj333 с Reddit. Разбираясь в появившемся год назад проприетарном коде Qualcomm Technologies для Android, он обнаружил, что неизвестный программист решил в production-коде использовать сортировку пузырьком для того, чтобы найти… максимум в массиве.

Посмотреть исходный файл вы сможете по ссылке на Github или же под катом, а оценить его в работе может любой владелец устройства с Qualcomm Snapdragon 200 MSM8610 под управлением Android.

Как известно любому, кто знаком с алгоритмами сортировки, сортировка пузырьком — алгоритм учебный, и в промышленном коде обычно не применяющийся в силу своей неэффективности; дело в том, что в наихудшем и среднем случаях он имеет сложность О(n²), к тому же его емкостная сложность в данном случае — O(n). Кого это не убедило — использовать сортировку пузырьком не рекомендует даже Барак Обама.

И это всё не учитывая того, что для поиска максимума хватило бы и простого перебора.

Сегодня завершилась летняя встреча комитета ISO WG21 C++, проходившая в Торонто с 10 по 15 июля. Вскоре нас наверняка ждёт подробный отчёт от РГ21, а сегодня уважаемой публике предлагается пост-«разогрев» с обсуждением самого интересного.

Итоги встречи следующие: стандарт С++17 завершен и будет опубликован на следующем собрании в ноябре этого года; стандарт С++20 уже обзавелся первыми серьезными фичами — концептами (concepts), явными обобщёнными лямбда-функциями (explicit generic lambdas) — и это только начало.

Возможности нового стандарта С++17 обсуждались уже не раз, про нововведения писали на Хабре, проводили доклады на конференциях, поэтому снова их приводить здесь я не буду. Не секрет, что ключевой особенностью этого выпуска С++ стал перенос самых «вкусных» возможностей в неопределенное будущее. Что ж, теперь можно с уверенностью сказать, что многие долгожданные «фичи» переехали именно в С++20. Взятый курс на расширение stdlib никуда не делся, поэтому от C++20 можно ожидать гораздо большего и богатого набора функций.

Кент Бек — разработчик программного обеспечения, создатель таких методологий разработки ПО как экстремальное программирование (XP) и разработка через тестирование (TDD); в данный момент работает на Facebook. Вашему вниманию предлагается перевод набросков идей о том, как можно было бы сделать свою работу эффективнее. Разделение программистов на мастеров и подмастерьев, используемое на протяжении статьи, взято Кентом Беком из книги «Программист-прагматик» Эндрю Ханта и Дэвида Томаса.

Годами наблюдая за лучшими из мастеров-программистов, я отметил некоторые общие закономерности в их рабочих процессах. В то же время, годами тренируя обученных программистов-подмастерий, я заметил, что у них подобных привычек не наблюдается. Я видел своими глазами, насколько сильную разницу может дать остальным ознакомление с паттернами, используемыми мастерами в своей работе.

Ниже представлены способы, при помощи которых эффективные программисты каждый день выжимают максимум из своих драгоценных 3e9 секунд на нашей планете.

Основной мотив набросков — раскрытие потенциала вашего мозга. Подмастерье учится решать большие задачи при помощи решения нескольких мелких задач разом. Мастер же учится решать еще большие задачи, чем подмастерье, при помощи решения меньшего количества задач разом. Важная часть мудрости здесь состоит в том, что разбивка задач должна осуществляться таким образом, чтобы интеграция независимых решений была бы меньшей проблемой, чем простое решение всех задач вместе.

Месяц назад Евгений Гречников grechnik опубликовал пост «Стандартная библиотека Visual Studio 2015 и телеметрия», в котором рассказал об интересной находке: оказалось, что в любом бинарнике, скомпилированном VS2015 из программы на C или C++, есть код, который может писать логи — и выглядело это всё слегка подозрительно, особенно в силу отсутствия исходников telemetry.cpp.

Три дня назад этот вопрос был снова поднят на Reddit, где время от времени в комментариях появляются разработчики Visual Studio — и вот сегодня общественности наконец-то удалось получить вполне себе официальный ответ от представителя Microsoft.

Самое важное: телеметрия будет убрана из статических библиотек в обновлении Update 3.

На днях широкое внимание привлекло состоявшееся в начале года на митапе NYC Lisp выступление Джеральда Джей Сассмана, — одного из авторов великого и могучего SICP, а также крестного отца Scheme. Всему виной — ответ на вопрос, почему в MIT прекратили преподавать ставший легендарным курс 6.001, построенный на основе книги Сассмана и Абельсона «Структура и интерпретация компьютерных программ» (вопрос задан на 59 минуте).



Сассман назвал две причины; впрочем, сразу замечу, что в первой из них нет ничего особенного. К 1997 году Абельсон и Сассман уже устали рассказывать практически одно и то же с 80-ых, поэтому решили оставить преподавание и предложили главе кафедры самостоятельно решить, как поступить с самим курсом. Здесь удивляться действительно нечему — что угодно может осточертерть, если заниматься им достаточно долго.

Впрочем, вторая причина гораздо серьезнее. По мнению Сассмана, они с Абельсоном осознали, что учебный план SICP больше не в силах подготовить инженеров к тому, что представляет собой «инжиниринг» сегодня. В 80-ых и 90-ых инженеры строили сложные системы, комбинируя простые и хорошо изученные «части». Целью SICP было предоставить язык абстракций для рассуждений о таких системах.

Вашему вниманию предлагается перевод прощального письма Миода Валлата, разработчика OpenBSD в течение 15+ лет, покинувшего проект неделю назад. Письмо, изначально адресованное лично некоему Джиму, рассказывает историю о том, куда порой приводят благие намерения, и вызвало резонанс среди пользователей Reddit и HackerNews. Учтите — высказанное мнение субъективно, и, по словам самого автора, "вы имеете право с ним не согласиться".

Сегодняшний мир — это amd64 (по-другому x64, или x86-64), armv7 и, в скором будущем, aarch64 (64-битный ARMv8). Всё остальное мертво, Джим. Никто не вкладывает достаточно денег и мыслительного труда в прочие архитектуры. В действительности, лишь небольшая часть людей в курсе существования остальной части экосистемы (mips, power8, ...), и все равно никому нет до них дела.

Поддержка устаревшей платформы на плаву — это весело, поскольку это напоминает тебе о 90-ых, когда существовал большой выбор «железных» платформ, с приблизительно одинаковым соотношением цены/мощности. В конце концов, дешевые PC убили практически всю конкуренцию, а рынок смартфонов дал ARM нездоровую долю рынка в мире встраиваемых систем.

Затем, спустя некоторое время, веселье подходит к концу, поскольку никто не пишет код, держа в уме твою платформу, — ведь она не считается достаточно мощной, а современные компиляторы больше ее не поддерживают (или они генерируют для нее нерабочий код, что на деле еще хуже). У твоей платформы есть аппаратные границы в несколько сотен MB физической памяти? Тебе не удастся запустить на ней веб-браузер или даже программу для просмотра PDF. Кто-нибудь все еще запускает testsuite из последней версии gcc на твоей платформе? Нет? Прости, чувак, но вот тебе «никель» (5 центов), сходи купи себе уже компьютер получше…

В этом году Брайаном Керниганом, автором классического труда «C Programming Language», в соавторстве с Аланом Донованом была написана книга «The Go Programming Language», которой, судя по всему, де-факто суждено стать одним из официальных источников первоначальных знаний по языку — не в последнюю очередь благодаря тому, что книга создавалась под пристальным контролем со стороны создателей самого языка. Электронная версия книги на английском языке выходит только сегодня — причиной нескольких переносов было исправление неточностей, допущенных в первом тираже книги; качественный перевод на русский язык ожидается не раньше марта 2016 года.

Вниманию всех интересующихся читателей предлагается перевод недавней сессии вопросов и ответов с авторами книги, проведенной ресурсом Slashdot.

Несколько недель назад все желающие имели возможность задать вопросы Алану Доновану и Брайану Кернигану на тему их совместного труда, книги «The Go Programming Language». Slashdot отобрал самые популярные вопросы читателей и получил на них ответы.

Предисловие от автора оригинала:

В марте 2011 я написал черновик статьи про то, как команда, отвечающая за Google Chrome, разрабатывает и выпускает свой продукт — после чего я благополучно о нем забыл. Лишь несколько дней назад я случайно наткнулся на него. Пусть местами он уже устарел (Chrome форкнул WebKit в Blink в 2013 году, да и я сам больше не работаю в Google), я склонен считать, что изложенные в нем идеи все еще в силе.

Сегодня я собираюсь рассказать вам о том, как работает Chromium. Нет, речь пойдет не совсем о браузере Chrome, а скорее о Chromium — группе людей, занимающихся созданием браузера.

Над проектом Chromium работают сотни инженеров. Вместе мы коммитим в кодовую базу примерно 800 изменений каждую неделю. Мы также зависим от многих других больших и активно развивающихся проектов вроде V8, Skia и WebKit.

Мы отправляем новый стабильный релиз сотням миллионов пользователей каждые шесть недель, четко по расписанию. И мы поддерживаем несколько других каналов раннего доступа, которые обновляются еще быстрее — самый быстрый канал, canary, «тихо» авто-обновляется почти каждый будний день.

Каким образом все это продолжает работать? Почему «колеса» у этого «автобуса» еще не «отвалились»? Почему еще не все разработчики сошли с ума?

Утром 21 сентября, на открывающем докладе CppCon Бьерн Страуструп официально анонсировал C++ Core Guidelines [ссылка на GitHub проекта][ссылка на слайды] — старт нового open source-проекта по разработке современных авторитетных гайдлайнов по написанию кода на C++. Гайдлайны создаются таким образом, чтобы быть современными, машинно-проверяемыми, а также открытыми для использования в сторонних компаниях — такими, чтобы любая желающая организация могла взять их и включить в свои собственные корпоративные стандарты кодирования.

В качестве авторов-инициаторов проекта выступили Бьерн Страуструп и Герб Саттер; гайдлайны создавались при участии экспертов из CERN, Microsoft, Morgan Stanley и еще нескольких организаций. Сейчас гайдлайны достигли версии 0.6, и Страуструп призывает всех желающих активно контрибьютить в проект.

Страуструп в своем выступлении сказал следующее: «Вы можете писать программы на С++, которые будут статически типобезопасными, и в которых не будет утечек ресурсов. Вы можете делать это без потери производительности и без ограничения выразительной мощи С++. Все это служит поддержкой основного тезиса о том, что сборка мусора не является как необходимой, так и достаточной частью качественного программного обеспечения (garbage collection is neither necessary nor sufficient for quality software). Наши новые гайдлайны делают написание кода более простым, чем это было в старых стилях программирования на С++, а его безопасность может быть проверена инструментами, которые вскоре будут доступны в open source».

Тема собеседований в Google издревле была неисчерпаемым источником «страшилок», которые можно было услышать за обедом или возле костра в курилке. Даже после того, как с головоломками на интервью компания решила завязать (об этом я писал два года назад), менее таинственным этот процесс для соискателей не стал — ответов на вопросы «Почему компания иногда отсеивает самых лучших? Почему от момента приглашения на телефонное интервью до оффера проходит по полгода?» желающие так и не услышали. А там, где нет точных данных, рождаются мифы и заблуждения.

Справедливости ради, надо сказать, что вопросы относительно технических интервью в свое время замечательно раскрыл Стив Йегге в своем посте 2008 года. Помимо высоких требований к знаниям базового Computer Science, там упоминались и организационные моменты — в частности, нелегкий процесс whiteboard interview и зловещий anti-loop, в который мог попасть кандидат (ситуация, когда интервьюеры, доставшиеся соискателю, никогда не смогут объективно оценить его как кандидата, и не примут его на работу по своим собственным причинам). Впрочем, на этом доступная часть информации по большей части и заканчивалась — ведь NDA не позволяло сотрудникам Google выносить сор из избы, а посторонних за кулисы никто пускать не собирался.

Поскольку никаких публичных заявлений касательно взлома PS4 не поступало уже давно, настало время нарушить тишину и рассказать немного о том, как далеко зашел прогресс в отношении взлома PS4, а так же о причинах, которые мешают продвинуться дальше.

В данной статье я затрону некоторые принципы безопасности, касающиеся всех современных систем, а также поделюсь своими находками, сделанными благодаря выполнению ROP-тестов на моей PS4.

Если вы плохо знакомы с применением эксплойтов, вам cледует сначала прочитать мою прошлую статью про взлом игр DS с помощью уязвимости целостности стека (stack smash) в файлах сохранений.

Загрузить всё необходимое для собственных экспериментов можно здесь, на данный момент поддерживается исключительно прошивка 1.76.

Подошедший к концу GopherCon 2015, длившийся с 7 по 10 июля в Денвере, отметился немалым количеством интересных выступлений. Видео докладов еще недоступно, однако, конспекты некоторых из них доступны на английском языке по этому адресу; в официальном блоге также можно прочитать программную речь Расса Кокса. Вниманию читателей предлагается конспект доклада об истории создания языка, который открыл второй день конференции.

Роберт Грисмер (@robertgriesemer) — разработчик в Google, один из авторов языка Go. В прошлом Роберт работал над генерацией кода для высокопроизводительного JavaScript, занимался языком программирования Sawzall и разработкой современной реализации Smalltalk — Strongtalk. По собственному заявлению, он «провел слишком много времени в виртуальных Java-машинах, но так и не понял, как ими пользоваться».

Интерес Роберта к языкам программирования возник при знакомстве с Pascal — до этого момента он в основном писал на BASIC. Будучи аспирантом, он обучался у Никлауса Вирта, создателя Pascal.

Когда Роберт закончил учебу и окунулся в реальный мир индустрии профессионального программирования, то почувствовал себя так, словно совершил огромный шаг назад. Во время обучения в академии он использовал Оберон — язык, позволяющий программисту достигать очень высокой личной эффективности. Теперь же Роберт тратил свое время на размышления о языках программирования в надежде придумать способ, как ему вернуться на былой уровень производительности. После 15 лет опыта программирования на С++ он понял, что впереди у него только два пути: или продаться, или спасаться. Вместе с Робом Пайком и Кеном Томпсоном они выбрали второй вариант.

От переводчика: с момента выхода популярной статьи Мартина Фаулера «Микросервисы» (перевод на Хабре) прошло уже достаточно времени, чтобы автор смог дополнить свои наблюдения свежим опытом проектирования и разработки микросервисов в различных компаниях, и рассказать о нем в новом посте, чей перевод представляется вашему вниманию.
Многие команды разработчиков нашли архитектурный стиль микросервисов подходом, превосходящим монолитную архитектуру; другие команды выяснили, что для них микросервисы — лишняя обуза, подрывающая производительность разработки. Как и у любого стиля архитектуры, у микросервисов есть свои плюсы и минусы. Для того, чтобы делать осознанный выбор, вы должны понимать эти свойства и уметь рассматривать их на фоне собственных конкретных условий.

Микросервисы дают преимущества…	…ценою издержек
Жесткие границы модулей Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков.	Распределённость Distribution Распределенные системы тяжелее программировать, поскольку удаленные вызовы медленные и всегда рискуют неудачей-отказом.
Независимый деплоймент Independent Deployment Простые сервисы проще деплоить, и, поскольку они автономны, меньше вероятность отказа системы в случае, если что-то идет не так.	Консистентность в конечном счете Eventual Consistency Поддержка cтрогой консистентности чрезвычайно сложна для распределённых систем, и это означает, что придется иметь дело с консистентностью в конечном счете.
Технологическое разнообразие Technology Diversity С микросервисами вы можете смешивать несколько языков, фреймворков и технологий хранения данных.	Эксплуатационная сложность Operational Complexity Вам потребуется опытная команда эксплуатации для управления множеством сервисов, которые будут регулярно редеплоиться.

«No pain, no gain», как гласит древняя восточная мудрость. И даже если мудрость не древняя и не восточная, лично для меня самый ценный жизненный опыт чаще всего был и самым болезненным. Недавний пост Дэвида Робинсона — аспиранта, занимающегося программированием в стенах Принстонского университета — посвященный код ревью, не только поднял важный вопрос повседневного быта каждого, кому волей (или неволей) приходится передавать свой опыт другим. Оригинальный текст был относительно «беззубым», однако, пост перестал быть томным после того, как в комментариях появился Джон Кармак.

Это история о плохом коде, который однажды написал ваш покорный слуга.

На одном из первых курсов университета я писал программу на Java, которая должна была читать файл весом в 6 MB в строку (этим файлом был геном бактерии в формате FASTA). Выглядел мой код следующим образом:

BufferedReader reader = new BufferedReader(new FileReader (file));
String line = null;
String text = "";

while( ( line = reader.readLine() ) != null ) {
    text = text + line;
}

Построение строки при помощи серии конкатенаций подобным образом крайне неэффективно — у меня, без преувеличения, уходило около 40 минут на чтение файла (с тех пор я узнал несколько способов получше). Самое главное — после чтения файла весь оставшийся алгоритм в программе отрабатывал секунд за 10. Два дня я так и работал: делал изменения в коде, запускал программу и успевал посмотреть целый эпизод LOST, прежде чем программа завершала выполнение. «Черт, на двенадцатой строчке ошибка! Опять все по-новой...»

Обсуждение идей и предложений для Zend Framework 3 идет достаточно давно, и вот наконец Zend решились на анонс новой версии фреймворка.

Zend Framework 3 будет эволюцией ZF2, с фокусом на три главных момента — простоту, повторное использование кода и производительность.

В первоочередные планы входит:

• выделение компонентов фреймворка в индивидуальные, версионируемые проекты (привет, Symfony!);
• особый упор будет сделан на HTTP сообщения, которые будут приведены в соответствие с PSR-7;
• существующий full stack MVC фреймворк будет обновлен и начнет зависеть от новых независимых компонентов для повторного использования и упрощения. ZF2 MVC проекты можно будет с минимальными усилиями перенести на новую версию, для чего подготовят гайд по миграции;
• использование концепции middleware, знакомой многим по Ruby / Python, а так же PHP-фреймворкам Slim Framework и StackPHP, в качестве более легкой альтернативы энтерпрайз-стеку фреймворка MVC (пример того, о чем идет речь);
• возможность использования Apigility в качестве middleware;
• оптимизация под PHP 7, при этом будет поддерживаться PHP начиная с версии 5.5;

Maciej Czyzewski собрал на Github коллекцию исходных кодов различных алгоритмов хеширования: для вычисления контрольных сумм, некриптографических и криптографических.

В репозитории можно найти, к примеру, реализации CRC/MD5/ГОСТ 34.311-95/SHA-3. Каждая хеш-функция представлена исходником на языке С и make-файлом для его сборки. Алгоритмы предполагается использовать в целях обучения — в реальных проектах рекомендуется в целях безопасности использовать существующие библиотеки (например, Crypto++ для C++, BouncyCastle для Java и т.д.), список которых есть в репозитории.

Над репозиторием продолжается активная работа, поэтому в перспективе стоит ждать пополнения коллекции.

Github

По всей видимости, на наших глазах родился еще один легендарный коммит (осторожно, в комментариях сплошные гифки):

github.com/composer/composer/commit/ac676f47f7bbc619678a29deae097b6b0710b799

При попытке разобраться с проблемой производительности Композера поступило предположение, что причина проблемы кроется в сборщике мусора:

Это действительно может быть проблемой по части GC. Если создается много объектов, и все они не могут быть «удалены», то GC в PHP начинает сходить с ума — он постоянно пытается провести сборку мусора, но убирать-то нечего — поэтому он просто тратит лишнее время/такты процессора. На это указывает и то, что проблема выявляется только на больших проектах (= много объектов), но не так заметна на маленьких (= GC включается не так часто).

В своем посте, посвященному праздничному событию, один из создателей языка Andrew Gerrand вспоминает то, как прошли эти годы и как все было пять лет назад. Вот так тогда выглядел официальный сайт; сами авторы Go называли его «системным языком», каждую строчку кода надо было заканчивать точкой с запятой, для сборки своих приложений приходилось писать мейкфайлы — и будущее языка было покрыто мраком. Сразу после релиза «язык от Google» привлек широкое внимание, после чего основная волна быстро схлынула, не увидев в языке ничего нового. Те немногие, кто увидел в языке будущее, сформировали «ядро» команды его разработчиков, и вышедшая в 2012 году первая версия языка была серьезным достижением, благодаря которому на сегодняшний день в развитии языка и экосистемы вокруг него решили принять участие сотни программистов.

Помимо «праздничного» поста, интерес представляет опубликованная расшифровка недавнего выступления Брэда Фицпатрика про настоящее и будущее Go. Официально Брэд — создатель memcached, OpenID и LiveJournal — занимается разработкой Camlistore, но по ходу дела ему приходится часто заглядывать в исходники Go и добавлять необходимый для Camlistore функционал в библиотеки языка или фиксить баги.

Долгий спор вокруг названия следующей версии PHP сегодня наконец-то закончился: итак, следующая версия будет иметь порядковый номер 7.

В основу PHP7 ляжет PHPng. Многие из свежих предложений и патчей делаются уже на его базе — в том числе такие интересные вещи, как uniform variable syntax, native big integers и abstract syntax tree. Из-за изменений во внутренних API, многие сторонние расширения (например, xdebug, расширения для mongodb и memcached, php-protocolbuffers) должны быть переработаны, поэтому в PHP 5.7 PHPng войти уже не сможет. Казалось бы, проблема не так велика — но, например, Yahoo в своих разработках использует около 400 различных PHP-расширений, поэтому процесс должен занять некоторое время.