Чего только ни услышишь от апологетов тех же Java или C# про разработку на C/C++! Якобы этот язык устарел и на нем никто не пишет. Вот только когда требуется создать no latency или low latency сервис или нужно сэкономить память и время выполнения узкого места обработки больших объемов данных, то тут же прибегают за помощью к «архаичным» разработчикам на C/C++. Просто потому, что эти ребята умеют вручную управлять памятью и прекрасно представляют, что за начинка у той или иной высокоуровневой операции. Сегодня наша задача — стать на шаг ближе к этим ребятам.

Каждый ищет в языках программирования что-то своё: кому-то важна функциональная сторона, кому-то богатство библиотек, а другой сразу обратит внимание на длину ключевых слов. В данной статье я хотел бы рассказать, что особенно важно для меня в Rust — его очевидность. Не в том, что его легко изучить с нуля, а в том, как легко исследовать поведение кода, глядя на его фрагменты. Я перечислю особенности языка, позволяющие точно определить, что делает та или иная функция, вырванная из контекста.

Особенно отмечу, что не пытаюсь полностью описать язык, а только одну его сторону. Это мой личный взгляд на философию Rust, не обязательно совпадающий с официальной позицией разработчиков! Кроме того, Rust не будет очевиден пришельцу из других языков: кривая обучение довольно резкая, и не раз компилятор заставит вас мысленно сказать «wtf» на пути к просветлению.

До того, как я пришел в HeadHunter, я не знал, что такое code review. Я знал, что такое code approval — так было в одной американской компании, где я начинал свою карьеру, и где весь код в проекте проходил перед мудрыми глазами профессора Фортрана за столиком в глубине офиса. Он с отеческой улыбкой смотрел на мои первые шаги в разработке и говорил: «Вот тут поправь, пожалуйста, и можешь выпускать».

Переменные и типы хороши, пока мы находимся внутри логики программы C++. Однако рано или поздно становится нужно передавать информацию между программами, между серверами или даже просто показать типы и значения переменных человеку разумному. В этом случае нам приходится заключать сделку со злобным Сериализатором и расплачиваться производительностью своего кода. В последней лекции Академии C++ мы наконец дошли до главного босса, которого нужно научиться побеждать с минимальными потерями в скорости выполнения кода. Поехали!

Шаблоны можно назвать самым главным отличием и основным преимуществом языка C++. Возможность создать шаблон алгоритма для различных типов без копирования кода и со строгой проверкой типов — это лишь один из аспектов использования шаблонов. Код специализаций шаблона строится на этапе компиляции, а это значит, что поведением создаваемых типов и функций можно управлять. Как тут удержаться от возможности попрограммировать компилируемые классы?

Метапрограммирование становится столь же неотъемлемой частью написания кода на C++, как и использование стандартной библиотеки, часть которой создана именно для использования на этапе компиляции. Сегодня мы произведем на свет библиотеку безопасного приведения скалярных типов C++, метапрограммируя шаблонами!

Начало

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

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

Думаю все из нас, кто учился на ИТ-специальностях, в университете изучали конечные автоматы. Для тех, кто не в курсе, это абстрактный автомат способный находиться в конечном количестве состояний, переход из одного состояния в другое происходит при выполнение некоторых условий. Штука интересная, но не совсем понятно когда и как это можно применить для решения реальных задач. О том, как я пришел к решению возникшей задачи на основе конечного автомата, а также о том, как реализовал его на bash, я бы и хотел рассказать. А в качестве бонуса опишу как сохранять его состояние для возможности восстановить работу с прерванной точки.

Сегодня мы поговорим о вещественных числах. Точнее, о представлении их процессором при вычислении дробных величин. Каждый из нас сталкивался с выводом в строку чисел вида 3,4999990123 вместо 3,5 или, того хуже, огромной разницей после вычислений между результатом теоретическим и тем, что получилось в результате выполнения программного кода. Страшной тайны в этом никакой нет, и мы обсудим плюсы и минусы подхода представления чисел с плавающей точкой, рассмотрим альтернативный путь с фиксированной точкой и напишем класс числа десятичной дроби с фиксированной точностью.

Говоря о тексте, большинство программистов C++ думают о массивах кодов символов и кодировке, которой эти коды соответствуют. Наиболее опытные разработчики вообще не мыслят понятие текста без указания кодировки, наименее опытные просто считают массив байтов с кодами символов данностью и интерпретируют в понятиях кодировки операционной системы. Фундаментальная разница между этими двумя подходами не только в опыте разработчика, но и в том, что не думать о кодировке намного проще. Пора рассмотреть способ, как не заботиться о хранении кодировки, перекодировке текста, получать свободный доступ к символам и при этом видеть безошибочное представление текста вне зависимости от того, кто и где смотрит на строку текста: в Китае ли, в США или на острове Мадагаскар.

Создавая объект за объектом, мы часто не обращаем внимания на такую «мелочь», как динамическое выделение памяти. Наравне с копированием и сериализацией, выделение памяти из кучи через new постепенно сводит на нет преимущества C++ в скорости. Чем интенсивнее мы пользуемся заветным new, тем сложнее становится приложению, поскольку память кончается, фрагментируется и всячески стремится утекать. Эта участь уже постигла удобные, но неявно опасные для производительности контейнеры STL: vector, string, deque, map. Особенно обидно терять скорость на выделении небольших объектов в больших количествах. Но есть способ обработать размещение памяти таких объектов на стеке, при этом скрывая детали реализации в специальный класс данных. В этом нам поможет механизм размещающего new — непревзойденный способ оптимизации приложения, полного частых и мелких выделений памяти из кучи.

или «Прекратите характеризовать хранилища данных как CP или AP»

Джеф Ходжес в своем прекрасном посте «Заметки о распределенных системах для новичков» рекомендует использовать САР теорему для критики найденных решений. Многие, похоже, восприняли этот совет слишком близко к сердцу, описывая свои системы как «СР» (согласованность данных, но без постоянной доступности при сетевой распределенности), «АР» (доступность без согласованного состояния при сетевой распределенности), или иногда «СА» (означает «Я всё ещё не читал статью Коды (Coda Hale) почти 5-летней давности»).

Я согласен со всеми пунктами статьи кроме того, что касается САР теоремы. Она слишком всё упрощает и слишком многие понимают её неверно для того, чтобы использовать для определения характеристик системы. Так что я прошу перестать ссылаться на САР теорему, говорить о ней и дать ей уже спокойно уйти на покой. Вместо неё мы должны использовать более точную терминологию для обсуждения различных компромиссов.

(Да, я понимаю всю иронию написания целой статьи по теме того, о чём призываю не писать других вообще. Но, как минимум, у меня будет ссылка, которую я смогу давать интересующимся, когда меня будут спрашивать, почему я не одобряю обсуждение САР теоремы. Также, я хочу извиниться, если статья вам покажется слишком напыщенной, но эта напыщенность опирается на множество ссылок.)

САР использует слишком узкое определение

Если вы хотите ссылаться на САР как на теорему (а не на расплывчатый концепт в маркетинговых материалах к вашей базе данных), вы должны быть точны. Математика требует точности. Доказательство сохраняется только если вы вкладывается в слова, то же самое значение, что было использовано при доказательстве. И оно опирается на очень точные определения:

Когда результат SQL-запроса влечет бесконечные приведения типов ко всевозможным вариантам типов полей. Когда код заполнен малопонятной логикой с гигантским перебором перегрузок по типам boost::variant. Когда не знаешь, как принять аргумент произвольного типа по RPC-протоколу. Тогда требуется механизм эмуляции динамической типизации в C++. Расширяемый и удобный, создающий понятный API. Такой, что не требует предопределенного списка типов и не заставляет работать с указателями на базовый класс. Такой механизм есть — нам поможет двойная диспетчеризация!

Некоторое время назад, листая просторы хабра, я наткнулся на вакансию «Python Backend Разработчик». В ней больше всего меня подкупило расположение офиса — он был рядом с домом, и я написал отклик. Ответ пришел быстро с вопросом о том, не готов ли я выполнить тестовое задание. Я ответил, что подумаю, если мне его пришлют. Письма с заданием не было недели две.

И вот, перед самыми майскими праздниками пришел ответ с тестовым заданием. Задание казалось простым, но я решил отказаться от дальнейшего общения вообще, так как почему-то за две недели порыв поиска новой работы прошел, да и праздники впереди. Однако в тот же день я заболел. Вполне себе серьезным насморком со всеми вытекающими. И на следующий день я решил попробовать забороть это тестовое задание и посмотреть, что из этого выйдет. И об этом мой рассказ.

Написать данную статью меня подтолкнула статья «Твой код никого не интересует». А точнее, комментарии к ней, которые говорили о полном или частичном непонимании у некоторых читателей хабра почему именно «твой код никого не интересует».

Чтобы понять позицию «твой код никого не интересует», надо подойти со стороны бизнеса: зарабатывание денег, выплата ЗП своим сотрудникам, уплата налогов, в общем, с точки зрения доходов/расходов компании или отдельно взятого человека. Например, утверждение «идеальный код — залог успешного бизнеса» может казаться логичным, но с точки зрения доходов/расходов далеко не всегда истинно.

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

Обожаю заглядывать за кулисы. Мне интересно, как делаются вещи. Мне кажется, что большинству людей это тоже интересно.

Исторически так сложилось, что видеоигры не делятся исходниками. Конечно, они ведь предназначены для игроков. Но для программистов там всегда есть, на что посмотреть. И некоторые игры всё-таки выпускали свои исходники. А я давно намеревался сделать такую подборку.

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

Многие игры после выпуска исходников были улучшены и дополнены сообществом – я намеренно даю ссылки только на оригинальные исходники. Так что, если вас вдруг интересуют апгрейды – они могут существовать.

Многие игры были рассмотрены на сайте Fabien Sanglard. Если вам интересны подробности их работы, то пожалуйте к нему.

Можно заметить, что многие игры принадлежат id Software/Apogee. Совпадение? Не думаю. id славится открытостью и привычкой выпускать исходники. Старые коммерческие игры уже не имеют ценности и были бы потеряны – не лучше ли, чтобы кто-то учился чему-то полезному на их основе?

Итак, приступим (в хронологическом порядке):

Традиционно в последнюю пятницу месяца состоялся Python Meetup. В мартовском митапе с приглашенными спикерами мы разобрались в следующих темах:

• Машинное обучение на Python
• Как устроен Python AST и какие интересные факты есть у диалекта Ну
• Как при помощи Requests, Asyncio и Aiohttp перестать использовать многопоточный код

Видео и ссылки на презентации смотрите под катом. Приятного просмотра!

Рекурсия: см. рекурсия.

Все программисты делятся на 11₂ категорий: кто не понимает рекурсию, кто уже понял, и кто научился ею пользоваться. В общем, гурилка из меня исключительно картонный, так что постигать Дао Рекурсии тебе, читатель, всё равно придётся самостоятельно, я лишь постараюсь выдать несколько волшебных пенделей в нужном направлении.

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

— Как она сложена?
— Превосходно! Только рука немного торчит из чемодана.

Именно пытаясь разместить стройную теорию алгоритма в жесткий рюкзак реальных ресурсов и приходится постоянно кроить по живому, перепаковывать, и вместо красивых и стройных определений Фибоначчи:

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

приходится городить всевозможные грязные хаки, начиная от:

  @memoized
  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    if n>1: return fib(n-1) + fib(n-2)
    return n

И заканчивая вообще:

  def fib(n):
    if n<0: raise Exception("fib(n) defined for n>=0")
    n0 = 0
    n1 = 1
    for k in range(n):
      n0, n1 = n1, n0+n1
    return n0

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

Разработчик Бен Фрейн (Ben Frain) однажды заметил: «Писать CSS-код легко. Масшабировать и поддерживать его — нет».

К счастью, на просторах интернета можно найти множество решений этой проблемы. В данной статье рассмотрены основные киты структуры CSS-кода, а также интересные рыбы/млекопитающие поменьше.

Статья служит лишь памяткой или кратким справочником — для подробного ознакомления с методологиями настоятельно рекомендуется изучать оригинальную документацию.

Итак, начнем.

«Программирование без эго» — перевод понятия egoless programming. Смысл в том, что разработчик осознанно отодвигает эго на второй план ради эффективности в работе. При разработке Web-payment.ru — сайта о платежных системах с каталогами и мониторингом обменников — мы стараемся руководствоваться этими принципами. Если кто-то благодаря этому посту тоже начнет применять их в своем проекте, мы будем очень рады, ведь они помогают избежать конфликтов и несут в себе добро. Перевод и редактура moigagoo.

О программировании Стивен начал говорить с отцом за 2 недели до его смерти. Стивену было 22, он изучал графдизайн в колледже и почти получил степень бакалавра. Его отцу было 62 — больше, чем большинству отцов. Когда он только начинал программировать в Теннессийском техническом университете в 60-е, то писал код на Фортране на перфокартах. Знал он очень много.

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

Когда Стивен приехал домой на каникулы, отец рассказал ему про 10 заповедей программирования без эго. Он распечатал их, и вдвоем со Стивеном они обсудили каждый пункт. Из-за внезапной смерти отца Заповеди стали одной из немногих программистских тем, которые Стивен успел обсудить вместе с ним. Возможно, именно поэтому они ему так запомнились.