Прим. перев.: в конце января стало известно о том, что один из основных доменов языка программирования Perl — Perl.com — был угнан. Это вызвало смешанную реакцию в сообществе как любителей языка, так и его противников. Теперь, когда всё уже позади и справедливость восстановлена, один из самых известных сторонников Perl — brian d foy — рассказал о том, что же произошло и как сообщество добилось положительного исхода событий. Представляем вниманию перевод его заметки.

Недавно новый сотрудник спросил меня за обедом: «Какой у нас техдолг?»

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

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

Глядя на нового сотрудника, я глубоко вздохнул и начал: «Давай я расскажу о том, как у нас было 15 000 прямых подключений к БД…»

История, которую я рассказал нашему новому сотруднику, – это история крупной технической перестройки DigitalOcean. Работала вся компания, эта работа продолжалась несколько лет и преподала нам много уроков. 

Наблюдение за изменением уровня Wi-Fi сигнала от стационарно расположенных по дому IoT устройств позволяет сделать полностью программный (выделенное железо отсутствует) объёмный датчик движения в объёме квартиры, достаточно точно показывающий наличие активно перемещающихся людей.

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

Каждый программист — это писатель.

^{Серкан Лейлек}

Я, после того, как насмотрелся на отчёты о языках программирования, теряющих актуальность, выбрал 4 языка, которые, как я полагаю, уже не стоят того, чтобы их изучали. Я, ради подкрепления своих выводов, прибегну к некоторым показателям популярности языков. В частности, речь идёт об индексе PYPL (PopularitY of Programming Language Index, индекс популярности языков программирования), о данных Google Trends и о некоторых сведениях, которые можно найти на платформе YouTube.

Фрагмент рейтинга PYPL (источник)

Платформа YouTube использовалась мной в качестве источника данных о перспективности языков программирования через оценку популярности видеоуроков по соответствующим языкам.

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

Но хватит предисловий. Поговорим об умирающих языках программирования.

Интересные переменные среды для загрузки в интерпретаторы скриптовых языков

Вступление

В недавнем хакерском проекте мы получили возможность указывать переменные среды, но не выполняемый процесс. Мы также не могли контролировать содержимое файла на диске, а брутфорс идентификаторов процессов (PID) и файловых дескрипторов не дал интересных результатов, исключив удалённые эксплоиты LD_PRELOAD. К счастью, исполнялся интерпретатор скриптового языка, который позволял нам выполнять произвольные команды, задавая определённые переменные среды. В этом блоге обсуждается, как произвольные команды могут выполняться рядом интерпретаторов скриптового языка при вредоносных переменных среды.

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

Итак, что имеем:

1. Десятки Embedded устройств в которых нужно проводить тестирование новой версии FirmWare (если быть точнее — ежедневная сборка прошивки)
2. В виду особенностей процедуры загрузки FW может потребоваться необходимость сбросить питание (т.н. режим загрузки прошивки в режиме Power On Capture)
3. Хотелось бы в некоторые конкретные моменты времени по ходу выполнения тестового скрипта имитировать нажатия на механические кнопки размещенные на отладочной плате Embededed системы
   

Компиляция программ при помощи текстового редактора на примере Notepad++

Цель: Научиться компилировать программы из командной строки. Научиться компилировать из текстового редактора Notepad++ (вернее научиться писать скрипты и связывать их), создавать скрипты и макросы, устанавливать системные переменные.

Сам текстовый редактор ничего не компилирует и не запускает. Также как и IDE не компилирует. Компиляция происходит с помощью компилятора. Выполнение производится некоторой средой выполнения. Это может быть интерпретатор команд или среда выполнения.
При компиляции программы на C# упаковываются в сборки. Код на языке IL автоматически преобразуется в код для конкретного процессора. Что относится к java, то скомпилированные файлы .class выполняется виртуальной машиной Java. Файлы .java компилируются в бай-код, то есть некоторый промежуточный код. Компиляция в exe файл тоже производится компилятором.

.EXE (сокр. англ. executable — исполнимый) — расширение исполняемых файлов, применяемое в операционных системах DOS, Windows, Symbian OS, OS/2 и в некоторых других, соответствующее ряду форматов. Процесс получения exe файла состоит из следующих этапов: препроцессинг, ассемблирование, компилирование, линковка.

ОUT файлы — исполняемые файлы для UNIX-подобных операционных систем.
Файл может хранить исполняемый код, общую динамическую библиотеку или объектный код.

Терминология

Прочитав новость "Код интерпретатора Perl официально перенесён на GitHub" на ресурсе LINUX.ORG.RU я решил взглянуть на репозиторий Perl 5, который теперь уже находится на GitHub'е.

Удивительно, как трепетно и качественно его перенесли, сохранив не только абсолютно всю 32-летнюю историю проекта, но и багрепорты (попали в Issues), патчи (попали в PRs), релизы и ветки. Надпись "32 years ago" рядом с файлами вызывает невольную улыбку.

Что ещё делать в этот унылейший пятничный вечер, когда на улице неприятно моросит дождь со снегом, а все уличные дорожки погрязли в осенней слякоти? Правильно, красноглазить! Так что я ради эксперимента и интереса решил взять и собрать древний Perl на современной x86_64-машинке с последней версией GCC 9.2.0 в качестве компилятора. Сможет ли такой старый код пройти проверку временем?


Демонстрация работы twm, одного из первых оконных менеджеров для X Window System, на современном дистрибутиве Arch Linux.

Чтобы было совсем уж аутентичненько и некромантненько, я развернул виртуальную машину с голыми иксами и оконным менеджером twm, который тоже родом из 1987 года. Кто знает, может быть Larry Wall писал свой Perl используя именно twm, так сказать bleeding edge technology того времени. Используемый дистрибутив — Arch Linux. Просто потому что в его репозитории есть некоторые полезные вещи, которые впоследствии мне пригодились. Итак, поехали!

В последнее время на Хабре стали чаще появляться посты о том, как хорош Telegram, как гениальны и опытны братья Дуровы в построении сетевых систем, и т.п. В то же время, очень мало кто действительно погружался в техническое устройство — как максимум, используют достаточно простой (и весьма отличающийся от MTProto) Bot API на базе JSON, а обычно просто принимают на веру все те дифирамбы и пиар, что крутятся вокруг мессенджера. Почти полтора года назад мой коллега по НПО "Эшелон" Василий (к сожалению, его учетку на Хабре стёрли вместе с черновиком) начал писать свой собственный клиент Telegram с нуля на Perl, позже присоединился и автор этих строк. Почему на Perl, немедленно спросят некоторые? Потому что на других языках такие проекты уже есть На самом деле, суть не в этом, мог быть любой другой язык, где еще нет готовой библиотеки, и соответственно автор должен пройти весь путь с нуля. Тем более, криптография дело такое — доверяй, но проверяй. С продуктом, нацеленным на безопасность, вы не можете просто взять и положиться на готовую библиотеку от производителя, слепо ему поверив (впрочем, это тема более для второй части). На данный момент библиотека вполне работает на "среднем" уровне (позволяет делать любые API-запросы).

Тем не менее, в данной серии постов будет не так много криптографии и математики. Зато будет много других технических подробностей и архитектурных костылей (пригодится и тем, кто не будет писать с нуля, а будет пользоваться библиотекой на любом языке). Итак, главной целью было — попытаться реализовать клиент с нуля по официальной документации. То есть, предположим, что исходный код официальных клиентов закрыт (опять же во второй части подробнее раскроем тему того, что это и правда бывает так), но, как в старые времена, например, есть стандарт по типу RFC — возможно ли написать клиент по одной лишь спецификации, "не подглядывая" в исходники, хоть официальных (Telegram Desktop, мобильных), хоть неофициальных Telethon?

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

Для меня эта фраза сродни hello world, так как я добрался наконец до своей первой публикации. Долго откладывал этот замечательный момент, так как и писать было не о чем, а обсасывать то, что уже по куче раз обсосано, тоже не хотелось. Вообще для своей первой публикации хотелось что-то оригинальное, полезное другим и содержащее какой-то челленж и решение проблем. И вот я уже могу поделиться этим. Теперь обо всем по порядку.

Вступление

Началось все с того, что некоторое время назад я на рабочем компе накатил себе Linux Mint. Многие наверняка знают, что Pidgin с плагином Sipe вполне годная замена Microsoft Lync (сейчас называется Skype for business) для Linux систем. В силу специфики работы мне часто приходится участвовать в sip-конференциях, и в бытность виндузятника вход в конференции был элементарным: получаем приглашение по почте, кликаем на ссылку входа, готово мы внутри.

При переходе на темную сторону Linux все несколько усложнилось: вход в конференции в Pidgin конечно же тоже есть, но там для этого нужно в свойствах вашего sip-аккаунта выбрать пункт присоединения к конференции в меню и в открывшемся окне вставить ссылку на конференцию либо ввести имя организатора и conf id. И через какое-то время я начал задумываться: «а нельзя ли как-то это упростить». Ага, скажете вы, на кой черт тебе это понадобилось, сидел бы себе на винде и в ус не дул.

Вчера, 23 мая, состоялся релиз Perl 5.30.0. Новость была объявлена в Usenet-группе perl.perl5.porters одним из ключевых разработчиков Perl — Sawyer X.

По сравнению с предыдущим стабильным релизом, 5.28.0, вышедшим около 11 месяцев назад, было изменено около 620.000 строк кода, изменения затронули 1300 файлов, в разработке приняли участие 58 авторов. Изменения непосредственно исходного кода (только .pm, .t, .c и .h файлы) оцениваются в ~510.000 строк и 750 файлов.

Открыта разработка следующей ветки 5.31. Выпуск следующего стабильного релиза запланирован на май 2020 года.

Предыстория

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

• Имя клиента
• AE-имя (должно быть уникально)
• TCP-порт, который автоматически открывается на стороне клиента и принимает DICOM-обследования от PACS-сервера (т.е. сервер как бы толкает их в сторону клиента – инициируя соединение первым)
• IP-адрес

После настройки Radiant клиентов получили следующую информацию к размышлению – у каждого клиента настройка ПО с указанными выше параметрами приводила к заполнению файла pacs.xml, который располагался в профиле пользователя (путь: %APPDATA%\RadiantViewer\pacs.xml). При этом конфиг одного клиента от другого отличался минимум двумя параметрами (AE-имя у всех разное, а порт в основном одинаковый, кроме терминальных клиентов, работающих на одном и том же сервере – там порты тоже приходилось назначать разными).

Пример файла pacs.xml по ссылке:

Примерно полгода все было хорошо, система заработала…и тут до нас дошли «подводные камни»:

• Нам нужно ввести в строй несколько новых PACS-серверов, которые подменят старые (где стало заканчиваться место на дисках). PACS сервера в виртуальных машинах, но речь не об этом;
• Нам нужно как-то централизованно изменить уникальные конфигурации (двумя отличающимися параметрами) на 200 машинах (их количество регулярно увеличивалось);
• Учитывая темпы роста объемов обследований, решение нужно не разовое, а тиражируемое и регулярное (например, 1 раз в 3-5 месяцев).

Решение ниже.

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



Сохраните следующую программу в /tmp/quine.pl

Illegal division by zero at /tmp/quine.pl line 1.

Запустите её командой

perl /tmp/quine.pl

и она выведет свой собственный код.

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

  File "quine.py", line 1
    File "quine.py", line 1
   ^
IndentationError: unexpected indent

Но перловый квайн в начале этой заметки — это обманка совершенно другого рода — программа разбирается корректно.

Вот и пришли новогодние праздники, а с ними и куча свободного времени, да еще и умный пылесос угодил ко мне в руки. Как только я увидел в приложении MiHome ручное управление, я сразу понял, что хочу сделать: будем управлять пылесосом с помощью геймпада Dualshock v4!

В ноябре на платформе Степик стартует курс «Введение в Perl» от разработчиков Mail.Ru Group, где слушатели будут иметь возможность изучить основы программирования на языке Perl и обозначить направления для дальнейшего развития.

В процессе обучения будут рассматриваться синтаксис языка, работа с модулями, ООП, регулярные выражения, однострочники, взаимодействие языка с операционной системой, основы ввода-вывода и параллелизм. Основной акцент сделан на базовых знаниях языка и системном программировании. Программа рассчитана на новичков: для освоения курса достаточно иметь представление об алгоритмах и знать базовые понятия (переменная, условный оператор и т.д.).

Для пополнения списка языков программирования с открытым исходным кодом, которые были проверены с помощью статического анализатора кода PVS-Studio, был выбран Perl 5. Эта статья о найденных ошибках и трудностях просмотра результатов анализа. Количество макросов в коде столь велико, что создаётся ощущение, что код написан не на языке Си, а на каком-то его странном диалекте. Несмотря на затруднения при просмотре кода, удалось насобирать интересные проблемы, о которых и будет рассказано в этой статье.

Введение

Perl — высокоуровневый интерпретируемый динамический язык программирования общего назначения (Perl is a family of two high-level, general-purpose, interpreted, dynamic programming languages). Разработка Perl 5 была начата в 1994 году. Спустя пару десятилетий, код на языке Си с многочисленными макросами вызывает нервозность у современных программистов.

Исходный код Perl 5 был взят из официального репозитория (ветка blead). Для проверки проекта использовался статический анализатор кода PVS-Studio. Анализ проводился на операционной системе Linux, но анализатор также доступен для Windows и macOS.

Просмотр результатов анализа был не простой задачей. Дело в том, что анализатор проверяет препроцессированные .i файлы, в которых уже раскрыты все директивы препроцессора, а выдаёт предупреждения на файлы с исходным кодом. Это правильное поведение анализатора, ничего менять не нужно, но много предупреждений выдаётся на макросы! А за макросами скрывается нечитабельный код.

Предисловие

Когда-то давно, в далекой далекой галактике… Хотя если подумать, это было всего то 15 лет назад.

В общем были времена, когда в качестве центрального шлюза в сеть Интернет использовались решения на базе FreeBSD и Linux. И были эти решения любовно настроены, и обвешивались они всеми возможными и невозможными функциями (от межсетевого экрана и VPN серверов до TFTP+PXE-сервисов бездисковой загрузки)… и не было беды, и все было хорошо…

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

Примером таких решения является компания Mikrotik и ее одноименные решения.

Обычно когда мне нужно использовать какой-то новый сервис или технологию из скриптов Perl, я захожу на CPAN, и там уже есть один или несколько подходящих модулей. Однако в случае фреймворков для работы с узлами блокчейна Ethereum и контрактами Solidity, к сожалению, мне не удалось найти нужного модуля.

Мы планируем в ближайшее время использовать смарт-контракты Solidity сети Ethereum в нашем SAAS-сервисе интернет-магазинов, написанном на Perl. Поэтому мне ничего не оставалось, как написать свой модуль Net::Ethereum (этот модуль уже доступен на CPAN, хотя и в виде альфа-версии).

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

Предлагаем вашему вниманию отличное новогоднее чтение для программистов :) Статью Александра Чистякова ( alexclear ), которую тот написал, вдохновившись тезисами доклада Mons Anderson ( codesign ) на HighLoad++ 2017.



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

Для того, чтобы классифицировать существующие решения, придумаем сначала оси координат. С точки зрения инженера-разработчика "синхронная" и "асинхронная" парадигмы основаны на абстракциях, различающихся как сложностью применения, так и «эффективностью» (что такое «эффективность», нам еще предстоит определить).

Осторожно, под катом жёсткий хардкор!

Несколько месяцев назад мы запустили серию интервью Oh, My Code на канале Технострим. Пришло время нового выпуска. На этот раз мы расскажем о том, как сделано Облако Mail.Ru, почему Perl не умер и что такое хороший программист.

Ведущий программы — технический директор медиапроектов Павел Щербинин, гость — архитектор Облака Mail.Ru Владимир Перепелица. Ниже перечислены ключевые вопросы, ответы на которые вы найдете в очередном выпуске Oh, My Code:

• Умер ли Perl?
• Как написать крутое резюме?
• Каких программистов берут в Облако?
• Как пройти собеседование, чтобы получать 200 000 рублей?
• Зачем становиться техническим директором и снова уходить в разработку?