^{Заброшенная колода}

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

Как довольно быстро выяснилось в СССР, участки около высоковольтных ЛЭП пчёлы не собирают. Собственно, у них как-то отключается навигация из-за электромагнитных помех.

Что ещё хуже, помехи сотовых сетей нарушают пищевую мобилизацию пчёл. Предположительно, это работает так: пчела вылетает из улья за предел запаховой навигации и за предел запомненной области (больше, чем на 5 километров), а потом не может вернуться, используя сенсор поляризации и криптохромный сигнал.

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

Перевели для вас статью Филипа Корейа о том, как он разрабатывал расширения для редакторов Atom и VS Code. Назвать проекты сложными нельзя, но в этом их преимущество: сходу можно понять, что необходимо делать для создания собственного расширения.

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

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

Вторая часть моего рассказа о компиляторе Swift. Мы начнём изучать фронтенд, а точнее те его части, которые отвечают за первоначальный разбор и анализ исходного кода.

Недавно мне напомнили, почему я считаю плохой идеей давать новичкам C++. Это плохая идея, потому что в C++ реальный бардак — хотя и красивый, но извращённый, трагический и удивительный бардак. Несмотря на нынешнее состояние сообщества, эта статья не направлена против современного C++. Скорее она частично продолжает статью Саймона Брэнда «Инициализация в C++ безумна», а частично — это послание каждому студенту, который хочет начать своё образование, глядя в бездну.

Типичные возражения студентов, когда им говорят об изучении C:

• «Кто-то его ещё использует?»
  
• «Это глупо»
  
• «Почему мы изучаем C?»
  
• «Мы должны учить что-то лучшее, например, C++» (смех в зале)

Предлагаем вашему вниманию перевод статьи, посвящённой рассмотрению используемых в программировании моделей памяти.

Сегодня в программировании доминируют шесть основных моделей памяти (не путать с моделями памяти Intel 8086). Три из них проистекают из трех исторически наиболее важных языков программирования 1950-х годов — COBOL, LISP и FORTRAN, а остальные связаны с тремя исторически важными системами хранения данных: магнитная лента, иерархическая файловая система в Unix-стиле и реляционная база данных.

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

Здесь будет длиннющая стена текста, с типа случайными мыслями. Основные идеи:

1. В C++ очень важно время компиляции,
2. Производительность сборки без оптимизаций тоже важна,
3. Когнитивная нагрузка ещё важней. Вот по этому пункту особо распространяться не буду, но если язык программирования заставляет меня чувствовать себя тупым, вряд ли я его буду использовать или тем более — любить. C++ делает это со мной постоянно.

Блогпост «Standard Ranges» Эрика Ниблера, посвященный ренжам в C++20, недавно облетел всю твиттерную вселенную, сопровождаясь кучей не очень лестных комментариев (это ещё мягко сказано!) о состоянии современного C++.

Даже я внёс свою лепту (ссылка):

Этот пример пифагоровых троек на ренжах C++20, по моему, выглядит чудовищно. И да, я понимаю, что ренжи могут быть полезны, проекции могут быть полезны и так далее. Тем не менее, пример жуткий. Зачем кому-то может понадобиться такое?

Давайте подробно разберём всё это под катом.

На Хабре уже пару раз появлялись статьи, поднимающие тему American Fuzzy Lop (AFL) (1,2). Но в данной статье речь пойдет не о классическом AFL, а о вспомогательных утилитах для него и его модификациях, которые, на наш взгляд, могут значительно улучшить качество фаззинга. Если вам интересно узнать, как можно прокачать AFL и искать быстрее и больше уязвимостей, то добро пожаловать под кат!

Недавно мы писали о том, на какие ухищрения пошла Alibaba, чтобы сделать себе жизнь с OpenJDK более приемлемой. Там были комментарии вроде «оказывается, пока мы тут страдаем с обычной джавой, китайцы уже сделали себе свою особенную». Alibaba, конечно, впечатляет — но и в России есть свои фундаментальные проекты, где тоже делают «особенную джаву».

В Новосибирске вот уже 18 лет делают свою собственную JVM, написанную полностью самостоятельно и востребованную далеко за пределами России. Это не просто какой-то форк HotSpot, делающий всё то же самое, но чуть лучше. Excelsior JET — это комплекс решений, позволяющих делать совершенно другие вещи в плане AOT-компиляции. «Пфф, AOT есть в GraalVM», — можете сказать вы. Но GraalVM — это всё ещё очень исследовательская штука, а JET — это проверенное годами решение для использования в продакшене.

Это интервью с одними из разработчиков Excelsior JET. Надеюсь, оно окажется особенно интересно всем, кто хочет открыть для себя новые вещи, которые можно делать с Java. Либо людям, которые интересуются жизнью JVM-инженеров и сами хотят в этом поучаствовать.

Уровни сложности чтения

• Я слишком молод, чтобы думать

  
  
  • Введение и правила игры
  • Как они это делают?
  • Матрица инцидентности для игры Доббль
  • Каких двух карточек не хватает в комплекте игры?
  • Почему в игре на 2 карточки меньше максимально возможного количества?
  • Благодарности
  
  

• Сделай мне умно

  
  
  • Введение и правила игры
  • Как они это делают?
  • При чём тут карточки?
  • Проективные плоскости малых порядков
  • Матрица инцидентности для игры Доббль
  • Каких двух карточек не хватает в комплекте игры?
  • Почему в игре на 2 карточки меньше максимально возможного количества?
  • Благодарности
  
  

• Кошмар

  
  
  • Введение и правила игры
  • Как они это делают?
  • Конечная геометрия для грудничков
  • При чём тут карточки?
  • Проективные плоскости малых порядков
  • Как построить проективную плоскость?
  • Матрица инцидентности для игры Доббль
  • Каких двух карточек не хватает в комплекте игры?
  • Почему в игре на 2 карточки меньше максимально возможного количества?
  • Благодарности
  
  

Введение и правила игры

Несколько лет назад я купил игру Доббль (Dobble, оригинальное название “Spot It!”). Это очень простая, быстрая и весёлая игра, которую я считаю одной из лучших настольных игр вообще.

Думаю, мы все потихоньку уже привыкаем, что у Python есть аннотации типов: их завезли два релиза назад (3.5) в аннотации функций и методов (PEP 484), и в прошлом релизе (3.6) к переменным (PEP 526).

Так как оба этих PEP были вдохновлены MyPy, расскажу, какие житейские радости и когнитивные диссонансы подстерегали меня при использовании этого статического анализатора, равно как и системы типизации в целом.

Disclamer: я не поднимаю вопрос о необходимости или вредности статической типизациии в Python. Просто рассказываю о подводных камнях, на которые натолкнулся в процессе работы в статически-типизированном контексте.

Истоки

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


ha.art.pl

Сперва родился простейший компилятор PL/0, а из него постепенно вырос почти полнофункциональный компилятор Паскаля для MS-DOS. Вдохновением мне служила книга Compiler Construction, написанная создателем языка Паскаль Никлаусом Виртом. И пусть взгляды Вирта уже устарели и утратили всякую связь с реалиями ИТ, а компиляторы делают совсем не так, как учил Вирт. Однако его методы по-прежнему просты, изящны, а главное — приносят радость, ведь самостоятельно разобрать текст программы рекурсивным спуском и сгенерировать машинный код намного заманчивее, чем призывать на помощь яков, бизонов и всех их преемников.

Судьба моего компилятора оказалась не самой тривиальной. Он прожил две жизни: первую — в моих руках, вторую — в руках польских ценителей компьютерных древностей.

Злые языки утверждают, что функциональные языки программирования — «языки для написания факториалов». Чаще всего так определяют язык Haskell, мы же начнем с того функционального языка, который сильно повлиял и на Haskell, и на подмножество средств для функционального программирования многих других языков — язык Scheme. По-крайней мере, map и for-each, filter и reduce, а так же apply и eval пришли в наши любимые языки программирования если не именно из Scheme, то в том числе и оттуда.

Рассмотрим некоторые возможные способы записи вычисления факториала. Заодно получится своеобразная ода языку программирования Scheme. Думаю, этот замечательный язык того вполне заслуживает.

У меня получилось 10 вариантов записи определений функций, которые можно свести к 3 основным способам вычисления: традиционному линейно-рекурсивному вычислительному процессу, итерации, генерации последовательности чисел с последующей сверткой умножением. Предлагаю рассмотреть эти варианты подробнее. Попутно мы рассмотрим: оптимизацию хвостовой рекурсии, функции высших порядков и метапрограммирование, отложенные вычисления, бесконечные списки, мемоизацию, способ создать статическую переменную в Scheme и гигиенические макросы.

Итак, Вы собираетесь создать новый [] функциональный, [] императивный, [] объектно-ориентированный, [] процедурный, [] стековый, [] мультипарадигменный, [] быстрый, [] статически-типизированный, [] динамически-типизированный, [] чистый, [] богатый, [] не-искусственный, [] наглядный, [] простой для новичков, [] простой даже для не-программистов, [] абсолютно непостижимый язык программирования.

Не получится. И вот почему.

Когда вы пишите command line утилиту, последнее, на что вам хочется полагаться, так это на то, что на компьютере где она будет запущена установлен JVM, Ruby или Python. Так же хотелось бы на выходе иметь один бинарный файл, который будет легко запустить. И не возиться слишком много с memory management'ом.

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

У Go относительно простой синтаксис, неплохая стандартная библиотека, есть garbage collection, и на выходе мы получаем один бинарник. Казалось бы, что еще нужно?

Не так давно Kotlin так же стал пробовать себя на схожем поприще в форме Kotlin Native. Предложение звучало многообещающе — GC, единый бинарник, знакомый и удобный синтаксис. Но все ли так хорошо, как хотелось бы?

Привет, Хабр!

Все любят runtime exceptions. Нет лучшего способа узнать о том, что что-то не было учтено при написании кода. Особенно — если исключения обваливают приложение у миллионов пользователей, и эта новость приходит паническим email'ом с портала аналитики. В субботу утром. Когда ты в загородной поездке.

После подобного всерьез задумываешься о обработке ошибок — и какие же возможности предоставляет нам Kotlin?

Первым на ум приходит try-catch. По мне — отличный вариант, но у него есть две проблемы:

1. Это как-никак лишний код (вынужденная обертка вокруг кода, не лучшим образом сказывается на читаемости).
2. Не всегда (особенно при использовании сторонних библиотек) из блока catch возможно получить информативное сообщение о том, что конкретно вызвало ошибку.

Давайте посмотрим во что try-catch превращает код при попытке решения вышеозвученных проблем.

Широко распространено мнение, что музыкальные способности и талант к программированию взаимосвязаны. Многие профессиональные музыканты питают склонность к точным наукам. Например, Борис Гребенщиков окончил факультет прикладной математики СПбГУ, а гитарист Radiohead Джонни Гринвуд (Jonny Greenwood) с детства неровно дышал к программированию.

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

Именно о них и пойдёт речь.

В этой статье я расскажу об основах внедрения зависимостей (англ. Dependency Injection, DI) простым языком, а также расскажу о причинах использования этого подхода. Эта статья предназначена для тех, кто не знает, что такое внедрение зависимостей, или сомневается в необходимости использования этого приёма. Итак, начнём.

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

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

Что же делать?

Оптимизация производительности издавна не даёт покоя разработчикам, представляясь своеобразным «золотым ключиком» к интересным решениям и хорошему послужном списку. Большую обзорную экскурсию по ключевым вехам оптимизации больших проектов  – от общих принципов до ловушек и противоречий —  на прошедшем JPoint 2017 провёл Алексей Шипилёв, эксперт по производительности.



Под катом — расшифровка его доклада.

Проклятие недетерминизма

Моя первая попытка написать проход LLVM — люблю эти сегфолты

Недавно я столкнулся с интересной задачей — мне понадобился детерминированный и кросплатформенный способ определения времени выполнения кода С++. Под словом «детерминированный» я подразумеваю, что один и тот же код будет выполняться за одно и то же количество единиц времени. Под кроссплатформенностью я понимаю, что один и тот же код под Windows и под Ubuntu будет выполняться за одно и то же количество единиц времени.

Естественно, измерение времени на CPU не удовлетворяет этим условиям. Машинный код меняется в зависимости от архитектуры и операционной системы, и один и тот же код займёт различное количество времени при выполнении. Даже на одной и той же машине, такие факторы, как промахи кэша, будут играть большую роль — достаточную для того, чтобы исказить результаты измерения времени выполнения одного и того же кода. Мне нужно было что-либо более умное…