Предисловие: Я пишу на Python более 6 лет и могу назвать себя профессионалом в этом языке. Недавно я даже написал о нем книгу. Однако последние 8 месяцев я переключился на D и уже 4 месяца активно участвую в разработке этого языка по части расширения стандартной библиотеки Phobos. Так же я участвовал в код-ревью модуля std.ndslice о котором и пойдет речь.

std.ndslice так же как и Numpy предназначен для работы с многомерными массивами. Однако в отличие от Numpy ndslice имет крайне низкий оверхэд так как базируется на ranges (диапазонах), которые используются в штатной библиотеке повсеместно. Ranges позволяют избежать лишние процедуры копирования, а так же позволяют красиво организовать ленивые вычисления.

В этой статье мне хотелось бы рассказать о том какие преимущества std.ndslice дает по сравнению с Numpy.

Наш первый пост в этом году мы решили посвятить очень базовой теме, лекция на которую была прочитана в Малом ШАДе. Занимаются в нём старшеклассники, которым интересны технологии, отсюда специфичность изложения — лекция будет особенно интересна тем, кто только начинает программировать и задумывается о том, в каком направлении развиваться. Для них же у Яндекса есть курс «Введение в программирование (С++)», который можно пройти на платформе Stepic.org.

Лектор Михаил Густокашин — куратор академических программ Яндекса, директор центра студенческих олимпиад факультета компьютерных наук ВШЭ. Михаил подготовил десятки победителей и призёров Всероссийских олимпиад по программированию.



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

Как всегда, под катом — подробная расшифровка лекции, чтобы вы могли сориентироваться в ее содержании.

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

Python — один из немногих динамических языков, в которых отсутствует встроенная поддержка регулярных выражений, но это компенсируется проработанной базовой системой (с точки зрения API). В то же время он весьма причудлив. К примеру, поведение написанного на Python парсера может вас удивить. Если вы попытаетесь в ходе импорта профилировать Python, то, скорее всего, 90% времени вы проведёте в работе с модулем re.

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

Небольшой спойлер: в начале это казалось мне какой-то магией, но потом я понял подвох…

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

Вообще говоря, есть другие модели — Недетерминированная машина Тьюринга, Квантовые машины Тьюринга. Однако они (пока) являются только абстрактными моделями, не реализуемые на практике.

Полгода назад в Science Advances вышла интересная статья с моделью вычислений, которая существенно отличается от МТ и которую вполне возможно реализовать на практике (собственно статья и была о том, как они посчитали задачу SSP на реальном железе).

И да. Самое интересное в этой модели то, что, по заверению авторов, в ней можно решать (некоторые) задачи из класса NP полных задач за полином времени и памяти.

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

При работе с облаком Amazon, часто приходится выполнять много рутинных операций через Web консоль. Но хочется их автоматизировать.
AWS CLI, интерфейс командной строки, хорошо для этого подходит. Конечно, можно написать и приложение на Scala, но в повседневных задачах лучше обойться без «тяжелой артиллерии».
Команды AWS умеют возвращать данные в разных форматах, в том числе и в json. Можно воспользоваться bash и jq, но последнего нет в репозитарии cygwin, а руками устанавливать лень. Между тем в PowerShell есть прекрасная поддержка json! Правда оказалось, что воспользоваться этим не совсем просто.

Добро пожаловать на русскоязычный сайт для разработчиков на Rust!

Rust — это системный язык программирования, который очень быстро работает, предотвращает почти все падения, и устраняет гонки данных.

Создание сообщества назревает уже давно. Наш язык миновал заветный выпуск «1.0». Rust стабилен, экосистема растёт как на дрожжах, а улучшения поспевают в каждом новом выпуске. Самое время расширять аудиторию!

Иногда этот метод называют «крестьянское умножение», иногда «древнеегипетское», иногда «эфиопское», иногда «умножение через удвоение и деление пополам». Некоторым он хорошо известен, некоторым – непонятен, но при этом он достаточно полезен и может использоваться не только для умножения, но и для возведения в степень и расчётов матриц.

Алгоритм

  13  x  19 ->     0
   6     38       19
   3     76 ->
   1    152 ->    95
   0    304      247
                 ^^^

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

Если число в левом столбце нечётное, мы добавляем число из правого столбца в нарастающую сумму. Изначально она будет равна нулю.

Затем в левом столбце ниже мы записываем число из заголовка, делённое пополам (с отбрасыванием остатка). 13 / 2 = 6. А во втором столбце мы пишем число, равное удвоению заголовка столбца, 19*2 = 38.

Поскольку число в левом столбце чётное, мы не увеличиваем нарастающую сумму.

Python жив! С такого громкого заявления хочется начать статью.

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



В конце 2014 года мы подводили итоги за год. В этот раз мы рассмотрим тенденции за неполные 11 месяцев 2015-года.

Но перед тем как перейдем к тенденциям — расскажем что сделали за (почти) год.

Интересующихся подробностями милости просим под кат.

Сегодня многие системы и языки программирования позиционируются как «мощные». Нельзя сказать, что это плохо. Почти каждый из нас считает это положительным свойством. Но в этом посте я хочу донести такую точку зрения, что во многих случаях нам нужны менее мощные языки программирования и системы. Но прежде чем продолжить, уточню: здесь будет мало оригинальных, моих собственных размышлений. Я буду излагать ход мыслей, возникший по прочтении книги Дугласа Хофштадтера «Гёдель, Эшер, Бах», которая помогла мне собрать воедино разрозненные идеи и мысли, бродившие в голове. Также большое влияние на нижеизложенный материал оказали пост Филипа Вадлера и видеозапись с конференции Scala. Ключевая мысль такова:

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

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

Еще каких-нибудь полтора года назад я был одним из тех, кто убежденно говорил «Нет, программирование — это точно не для меня». Не рискну сказать, что я стал программистом, но за последний год R заменил мне большинство повседневных программ для работы. Я работаю исследователем. С интересом наблюдаю, как постепенно R становится стандартом в академическом мире. В общем, в мире ширится понимание того, что с компьютером имеет смысл общаться чуть свободнее, чем на уровне программ click&drag. Так, совсем недавно Медуза писала о том, что не все прогеры девственники программирование стоит изучать гораздо более широкому кругу людей, чем всегда было принято считать.

В этом посте я расскажу об одном из самых коротких путей к программированию — изучении R с помощью специального пакета swirl (пакет в R — это то же, что во многих других языках называется библиотекой, расширение/дополнение исходного функционала). Пост рассчитан на читателя с нулевым знанием R, заинтересованного в изучении этого языка программирования; он поможет, как мне кажется, максимально эффективно и безболезненно сделать первые шаги в темный лес программирования.

Прошлое

Повествование можно начать с 1962 г., когда в Кембриджском университете началась работа над CPL («Cambridge Programming Language») — «усовершенствованным вариантом» ALGOL-60. К работе над языком подключился аспирант Мартин Ричардс; главной сложностью в реализации нового ЯП ему показалась необходимость ручного портирования компилятора для разных компьютерных платформ. В частности, когда кембриджский EDSAC-2 заменили на Atlas-2, разработчики CPL потратили много времени на портирование своего компилятора для новой платформы.

Диссертация Мартина была посвящена «само-компилирующемуся» CPL: разработанный Мартином компилятор был написан на сильно упрощённом варианте CPL, компилятор которого несложно было написать на тогдашнем макроассемблере. Перенос CPL на новую платформу теперь можно было выполнить в два шага:

1. Вручную пишем компилятор «упрощённого CPL»;
2. Компилируем им компилятор «полного CPL».

На этом Мартин не остановился, и разработал BCPL — систему для разработки переносимых компиляторов. Компилятор BCPL генерировал псевдокод, названный Мартином «OCODE».
— а отдельная программа, кодогенератор, превращала файл с таким псевдокодом в исполнимую программу для конечного процессора. OCODE сохранялся в виде текстового файла из десятичных чисел, разделённых пробелами и переводами строк: в то время, когда OCODE разрабатывался, привязка формата файла к конкретному размеру байта ограничивала бы переносимость такого файла.

Компилятор BCPL⁽¹⁾ поставлялся в виде OCODE, и чтобы перенести его на новую платформу, нужно было:

1. Вручную написать интерпретатор псевдокода⁽²⁾ (на любом языке, хоть на Бейсике);
2. Адаптировать кодогенератор,⁽³⁾ написанный на BCPL, для своей платформы;
3. Запустить под интерпретатором (2) компилятор BCPL (1), скормить ему кодогенератор (3), и получить на выходе исполнимый файл кодогенератора⁽⁴⁾;
   • Интерпретатор (2) нам с этого момента больше не нужен.
4. Прогнать через кодогенератор (4) псевдокод компилятора (1), и получить на выходе исполнимый файл компилятора.

Такой подход означал, что для переноса компилятора на новую платформу требуется лишь самый минимум низкоуровневого программирования; и действительно, реализация BCPL была завершена к 1967 г. — раньше, чем была завершена реализация CPL, начатая на несколько лет раньше!

Достоинства BCPL применительно к системному программированию вдохновили Кена Томпсона на создание языка Би, а тот — коллегу Кена, Денниса Ритчи, на создание Си. Именно из BCPL пошла традиция обозначать {фигурными скобками} блоки программы, и именно на BCPL была написана первая программа «Hello, World!».

GET "libhdr"

LET start() = VALOF
{ writef("Hello*n")
  RESULTIS 0
}

Более важная нам причина, по которой BCPL вошёл в историю: OCODE — первая универсальная «архитектура набора команд» (ISA), т.е. «виртуальная машина», не привязанная ни к какой конкретной аппаратной платформе с её особенностями. BCPL, таким образом — первый язык программирования, соответствующий парадигме «Write once, run anywhere» (WORA): программу на BCPL можно распространять в скомпилированном виде, и её можно будет запустить на любой платформе, для которой существует OCODE-кодогенератор.

Сегодня я хочу представить Хостинг Кафе. Этот домен-бренд объединяет в себе 6 различных сайтов, которые связаны с хостинговой тематикой:

• VDS.menu — поиск виртуальных серверов
• SHARED.menu — поиск виртуального хостинга
• DEDICATED.menu — поиск выделенных серверов (в разработке)
• HTTPS.menu — поиск SSL сертификатов
• BACKUP.menu — поиск места для хранения резервных копий
• LICENSE.menu — поиск лицензий на панели управления (в разработке)

На данный момент работают все проекты, кроме DEDICATED.menu и LICENSE.menu. Информация о VDS.menu и SHARED.menu уже размещалась на Хабре. Став владельцем этих двух сайтов, я решил максимально вдохнуть в них жизнь. В дополнение к этим двум сайтам прилагался домен dedicated.menu. После долгих раздумий, было принято решение объединить эти три домена под единым брендом HOSTING.cafe — кафе, в котором есть различные меню хостинговой тематики. В довесок к уже имеющимся доменам были приобретены HTTPS.menu, BACKUP.menu, LICENSE.menu.

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

Часть первая: Google Cloud Endpoints на Java: Руководство. ч. 1
Часть третья: Google Cloud Endpoints на Java: Руководство. ч. 3
Часть четвертая: Работа с базой данных в Google App Engine/Google Cloud Endpoints на Java: фреймворк Objectify
Часть пятая: Google Cloud Storage c Java: изображения и другие файлы в облаках

В первой части мы рассмотрели создание проекта на Google Cloud Endpoints с Java, в этой статье речь пойдет о создании фронтенда к нашему API.

В дополнение к инструментам, использовавшимся в первой части, нам понадобится:

AngularJS, и начальное общее представление о том как он работает, опционально Bootstrap или Foundation.

Простейший веб-сервер на локальной машине для тестирования, и сервер для деплоя приложения.

Всем привет!

С недавнего времени я начал изучать прекрасный язык Rust. Практическое применение этого языка для себя я вижу во встраивании в критические по производительности места кода (по крайней мере, до момента «дозревания» и обрастания библиотеками и фреймворками).

Для закрепления теоретических навыков я решил сделать небольшой проект, суть которого состоит в следующем: динамическая библиотека на Rust реализует упрощенный вариант Алгоритма шинглов и посредством FFI позволяет подключать её (библиотеку). Всем кому интересно прошу под кат.

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

Для работы над Яндекс.Музыкой нам всегда важно помнить о разных тонкостях, которые таит в себе звук. Что такое громкость, как она меняется и от чего зависит? Как работают звуковые фильтры? Какие бывают шумы? Как меняется звук? Как люди его воспринимают.



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

Поводом для этого поста можете считать то, что мы добавили в приложения Яндекс.Музыки возможность слушать треки в высоком качестве (320kbps). А можете не считать. Итак.

Что такое USDT и зачем он нужен
USDT, или Tether, — это стейблкоин. Это значит, что в отличие от обычных криптовалют, цена на него не скачет вверх-вниз. Один токен USDT всегда равен примерно одному доллару США. Почему это удобно? Представь, что у тебя есть биткоины — сегодня они стоят много, а завтра — на 20% меньше. Не очень приятно, да? А USDT стабилен. Это как цифровой доллар, только без банков.

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

Почему именно USDT популярен среди москвичей

Представь себе: ты в Москве, и хочешь перевести деньги родственнику за границу. Через банк — долго, куча проверок и комиссий. А с USDT всё просто: за пару минут токены улетят хоть в Индию, хоть в Аргентину. Без лишних вопросов.

В этой статье мы рассмотрим два способа поиска с помощью регулярных выражений. Один широко распространён и используется в стандартных интерпретаторах многих языков. Второй мало где применяется, в основном в реализациях awk и grep. Оба подхода сильно различаются по своей производительности:



В первом случае поиск занимает A?ⁿAⁿ времени, во втором — Aⁿ.

Степени обозначают повторяемость строк, то есть A?³A³ — это то же самое, что и A?A?A?AAA. Графики отражают время, требуемое для поиска через регулярные выражения.

Обратите внимание, что в Perl для поиска строки из 29 символов требуется более 60 секунд. А при втором методе — 20 микросекунд. Это не ошибка. При поиске 29-символьной строки Thompson NFA работает примерно в миллион раз быстрее. Если нужно найти 100-символьную строку, то Thompson NFA справится менее чем за 200 микросекунд, а Perl понадобится более 10¹⁵ лет. Причём он взят лишь для примера, во многих других языках наблюдается та же картина — в Python, PHP, Ruby и т. д. Ниже мы рассмотрим этот вопрос более детально.

Наверняка вам трудно поверить приведённым данным. Если вы работали с Perl, то вряд ли подмечали за ним низкую производительность при работе с регулярными выражениями. Дело в том, что в большинстве случаев Perl обращается с ними достаточно быстро. Однако, как следует из графика, можно столкнуться с так называемыми патологическими регулярными выражениями, на которых Perl начинает буксовать. В то же время у Thompson NFA такой проблемы нет.

Возникает логичный вопрос: а почему бы в Perl не использовать метод Thompson NFA? Это возможно и следует делать, и об этом пойдёт далее речь.

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

Введение

На самом деле я рассматриваю эту cms только как пример, того что присутствует во многих и опенсурс, и коммерческих системах. Просто мне как фрилансеру до недавних пор приходилось работать почти всегда с разработкой сайтов по дешевле и побыстрее – может у других фрилансеров много «жирных» клиентов, я не знаю, у меня не было. Так вот такая ситуация привела к не плохому опыту работы на модыксе. Но открытие собственной компании и дальнейшее подтягивание клиентов с индивидуальными запросами, потребовало вспоминать и улучшать свой лвл в настоящем программировании и построении баз данных. И вот тут я и почувствовал какой-то дискомфорт, что ли, ну как минимум смущение при воспоминании структуры как MODx, так и некоторых других открытых систем. Далее поясняю подробнее, что именно показалось странным, но интересным.



Дело в том, что в MODx Revo основным понятием для построения структуры сайта являются ресурсы. Вот именно, там нет такого как, например, в том же Вордпрессе отдельно страницы сайта, отдельно записи блога. Все страницы и записи, и даже много чего еще реализуется через модель ресурсов сайта. На самом деле это удобно, особенно учитывая тот факт, что это cmf/cms, то есть система рассчитана на разработку совершенно разных сайтов и тематически и технически. Таким образом, за всей структурой сайта удобно следить в одной панели управления ресурсами. В общем, система ресурсов позволяет создавать и управлять следующими сущностями сайта (хотел было написать объектами, но в ООП это слово уже занято, так что пусть будет «сущности»):

• Обычные html-страницы;
• Разного рода категории и разделы блога или каталога;
• Товары и их категории;
• XML-документы, например, sitemap.xml для поисковых роботов;
• Текстовые документы, к примеру, robots.txt правильно сделать ресурсом, а не просто залить файлом;
• Json-страницы, которые лично я использую для того же аякс;
• Создать собственный формат текстового файла.

Постановка проблемы

Вот такое объединение множества различных «сущностей» сайта в объекте одной модели Resources и вызвало мой интерес. Разум философа зашевелился и начал выдавать множество предположений и вопросов.

Во-первых, я обратил внимание на пользователей, потому что они сделаны совершенно отдельно от ресурсов. Как бы на первый взгляд это логично, но с другой стороны, если начали такую пляску с объединением кучи всего, почему бы не сделать все до конца. Да-да, максимализм в деле. Тем более, что сделать пользователей как один из видов ресурсов не представляет большой проблемы. В случае с modx это по большей части реализуется с помощью плейсхолдеров, позволяющих расширить количество атрибутов ресурса, и «контекстов», дающих возможность выделять часть ресурсов по их назначению. Реализация же чего-то подобного на фреймворке (я имею ввиду php-фреймворки) или голой связке скриптов и реляционной базы данных совсем дело не сложное.

Во-вторых, совершенно отдельными моделями реализуются шаблоны и вся система представления и настройки сайта. Почему бы их тоже не объединить в одну модель, хотя бы чисто ради эксперимента. Чувствую летящие в меня помидоры.

В последнее время я вижу, как довольно большое количество людей применяет контейнерную виртуализацию только для того, чтобы запереть потенциально небезопасное приложение внутри контейнера. Как правило, используют для этого Docker из-за его распространенности, и не знают ничего лучше. Действительно, многие демоны первоначально запускаются от имени root, а далее либо понижают свои привилегии, либо master-процесс порождает обрабатывающие процессы с пониженными привилегиями. А есть и такие, которые работают исключительно от root. Если в демоне обнаружат уязвимость, которая позволяет получить доступ с максимальными привилегиями, будет не очень приятно обнаружить злоумышленников, уже успевших скачать все данные и оставить вирусов.
Контейнеризация, предоставляемая Docker и другим подобным ПО, действительно спасает от этой проблемы, но также и привносит новые: необходимо создавать контейнер для каждого демона, заботиться о сохранности измененных файлов, обновлять базовый образ, да и сами контейнеры часто основаны на разных ОС, которые необходимо хранить на диске, хотя они вам, в общем-то, и не особо нужны. Что делать, если вам не нужны контейнеры как таковые, в Docker Hub приложение собрано не так, как нужно вам, да и версия устарела, SELinux и AppArmor кажутся вам слишком сложными, а вам бы хотелось запускать его в вашем окружении, но используя такую же изоляцию, которую использует Docker?

Capabilities

В чем отличие обычного пользователя от root? Почему root может управлять сетью, загружать модули ядра, монтировать файловые системы, убивать процессы любых пользователей, а обычный пользователь лишен таких возможностей? Все дело в capabilities — средстве для управления привилегиями. Все эти привилегии даются пользователю с UID 0 (т.е. root) по умолчанию, а у обычного пользователя нет ни одного из них. Привилегии можно как дать, так и отобрать. Так, например, привычная команда ping требует создания RAW-сокета, что невозможно сделать от имени обычного пользователя. Исторически, на ping ставили SUID-флаг, который просто запускал программу от имени суперпользователя, но сейчас все современные дистрибутивы выставляют CAP_NET_RAW capability, которая позволяет запускать ping из-под любого аккаунта.
Получить список установленных capabilities файла можно командой getcap из состава libcap.

% getcap $(which ping)
/usr/bin/ping = cap_net_raw+ep

Флаг p здесь означает permitted, т.е. у приложения есть возможность использовать заданную capability, e значит effective — приложение будет ее использовать, и есть еще флаг i — inheritable, что дает возможность сохранять список capabilities при вызове функции execve().
Capabilities можно задать как на уровне ФС, так и просто у отдельного потока программы. Получить capability, которая не была доступна с момента запуска, нельзя, т.е. привилегии можно только понижать, но не повышать.
Также существуют биты безопасности (Secure Bits), их три: KEEP_CAPS позволяет сохранить capability при вызове setuid, NO_SETUID_FIXUP отключает перенастройку capability при вызове setuid, и NOROOT запрещает выдачу дополнительных привилегий при запуске suid-программ.