Последние пару недель я работал над обновление Rayon — моей экспериментальной библиотеки для параллелизма данных в Rust.

Я вполне доволен тем, как идёт разработка, так что я решил объяснить к чему я пришёл в блог посте.
Цель Rayon — сделать добавление параллелизма в последовательный код простым, так, чтобы любой цикл for или итератор можно было бы заставить работать в несколько потоков. Например если у вас есть такая цепочка итераторов:

let total_price = stores.iter()
                        .map(|store| store.compute_price(&list))
                        .sum()

то вы можете сделать её работу параллельной просто поменяв обычный «последовательный итератор» на «параллельный итератор» из Rayon:

let total_price = stores.par_iter()
                        .map(|store| store.compute_price(&list))
                        .sum()

SVG — входящий в подмножество XML язык разметки масштабируемой векторной графики был создан в 1999 году, но только в 2011-м он был включен в рекомендации W3C. Поразительно, но за одиннадцать лет (с 2000 по 2011 год) SVG не претерпел существенных изменений. Тем не менее, ему все же удалось завоевать доверие и широкое признание разработчиков.

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

Где-то в 1998 году моя бывшая коллега, в то время работавшая в Adobe, заглянула в мой офис чтобы рассказать мне об абсолютно новой технологии. Она знала, что мне будет интересно. Речь тогда шла о PGML или «Precision Graphics Markup Language», который представлял собой не что иное, как вариацию Adobe на тему XML для векторной графики. Джон Уорнок, один из основателей Adobe, тогда сказал про него следующее:

От переводчика

Процедурные макросы — одна из наиболее ожидаемых фич Rust. На данный момент процедурные макросы возможно писать только под нестабильную версию компилятора, хотя есть несколько контейнеров, вроде syntex, позволяющие делать ограниченную кодогенерацию в рамках стабильного компилятора. Однако ситуацию это особо не облегчает, поскольку интерфейс к AST остаётся нестабильным, и, хотя авторы syntex стараются идти в ногу с ночными сборками, иногда случаются фейлы из-за изменений в структуре AST.
В этом блог посте один из участников core team — Nick Cameron — поделился своим видением будущего процедурных макросов. Хотя пост полон технических подробностей по внутренностям компилятора, мне показалось, что хабрасообществу может быть интересно заглянуть немного за кулисы разработки Rust.

Фреймворк для процедурных макросов

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

Первая часть

От переводчика. OlegKozlov рассказал о приёмах камеры в своей игре «Несыть». Из-за большого количества трафика и не слишком верно действующего JS якорь перебрасывает куда угодно, только не на комментарий, поэтому сделаю копию здесь.

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

Направление

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

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

Wonder Boy, ещё одна моя любимица, быстрый платформер, в котором можно идти только вперёд через старое доброе одностороннее окно свободного хода. В отличие то Super Mario Bros., там нет зоны разгона, плавно ускоряющей камеру, но есть другая интересная техника, которую я называю «рельсы». Камера ставится и движется так, чтобы предвосхищать будущие преграды.

Wonder Boy (Sega, 1986)

Рельсы: запрограммированный маршрут камеры Зона свободного хода (односторонняя) Статическое упреждение

Пятое поколение приставок, среди них PlayStation и Nintendo 64, открыло новые аппаратные возможности, положив начала грубому, но настоящему 3D. Приёмы трёхмерной камеры — сами по себе захватывающая и многогранная тема, но поддержка 3D повлияла и на двухмерные игры. Разработчики теперь могут приближать камеру, наклонять вид и даже сочетать 2D и 3D — то, что мы сейчас называем 2,5D, когда игра идёт на двухмерной плоскости, но в объёмном мире.

Это шестая статья из цикла «Теория категорий для программистов». Предыдущие статьи уже публиковались на Хабре:
0. Теория категорий для программистов: предисловие
1. Категория: суть композиции
2. Типы и функции
3. Категории, большие и малые
4. Категории Клейсли
5. Произведения и копроизведения

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

Рассмотрим подробнее место произведения и копроизведения типов в программировании.

Произведение типов

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

Строго говоря, произведение типов не коммутативно: нельзя подставить пару типа (Int, Bool) вместо (Bool, Int), хотя они и содержат одни и те же данные. Однако произведение коммутативно с точностью до изоморфизма, задаваемого функцией swap, которая обратна самой себе:

swap :: (a, b) -> (b, a)
swap (x, y) = (y, x)

Можно рассматривать такие пары как различные форматы хранения одной и той же информации, как big endian и little endian.

В первой статье мы познакомились с Эрлангом и фреймворком n2o. В этой части мы продолжим делать наш блог:

• добавим авторизацию через фейсбук, для этого будем из клиента вызывать функции на сервере;
• будем сохранять комментарии и посты в NoSQL базе;
• развернем наш блог на DigitalOcean и замерим производительность (спойлер — 1300 запросов в секунду).

Код из статей https://github.com/denys-potapov/n2o-blog-example, готовый проект можно посмотреть по адресу http://46.101.118.21:8001/.

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

Есть множество различных способов объявить функцию:

function A() {};             // декларация функции
var B = function () {};       // функциональное выражение
var C = (function () {});     // функциональное выражение с оператором группировки
var D = function foo () {};   // именованное функциональное выражение
var E = (function () {})();   // самовызывающееся функциональное выражение
var F = new Function();     // конструктор функции
var G = new function() {};   // вырожденный случай: конструктор объекта

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

Здарова! Короче, последнее время на хабре было много срачей вокруг Go: хороший-плохой, нужен-ненужен, много сравнивали с питоном, много сравнивали с растом, divan0 даже додумался перевести высер «Go vs Haskell» ну и в таком ключе. У меня сложилось ощущение, что из-за хайпа и агрессивного маркетинга языка некоторыми Иванами Данилюками очень мало кто понял, кому и зачем вообще Go может пригодиться, зачем его делали и стоит ли вообще его учить. Я тоже долгое время участвовал в этих срачах, принимая посменно сторону «фанов» языка и сторону оппозиции, но в конце-концов допер, в чем фокус. Сегодня немного потупил у дивана в посте и решил написать вот эту заметочку.

Давайте, пацаны, проходим в пост.

24 декабря в официальном блоге, посвящённом новостям разработки Perl 6, появилась поздравительная запись. Разработчики поздравили всех с наступающим католическим Рождеством, и с тем, что так долго ожидаемое взросление языка, наконец, состоялось. Фактически, язык готов к использованию в рабочих проектах, и разработчики обещают больше ничего существенно не менять.

С момента выхода первой версии Perl прошло 28 лет, с момента выхода самой популярной в данное время версии Perl 5 – более 20 лет. Как шутит Ларри Уолл, создатель языка и лидер его разработки, 6-я версия, возможно, когда-нибудь и заменит 5-ю – примерно лет через 40.

Версия Perl 6 была анонсирована более 10 лет назад – на Amazon ещё можно купить книгу про этот «вскоре выходящий» язык, изданную в 2004 году. Длительность разработки можно объяснить тем, что Perl 6 – фактически, новый язык, написанный по мотивам 5-й версии. И хотя некоторые утверждают, что 6-ка отличается от 5-ки не более, чем C++ от C, всё-таки идеология в Perl 6 эволюционировала достаточно сильно для того, чтобы назвать его более современным языком.

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

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

Из опыта code-review и ответов на StackOverflow набралось немало моментов, касающихся Java Collections API, которые мне казались очевидными, но другие разработчики о них почему-то не знали или знали, но не чувствовали уверенности их применять. В этой статье я собираю в общую кучу всё, что накопилось.

Содержание:

1. List.subList
2. PriorityQueue
3. EnumSet и EnumMap
4. Set.add(E) и Set.remove(E) возвращают булево значение
5. Map.put(K, V), Map.remove(K), List.set(idx, E), List.remove(idx) возвращают предыдущий элемент
6. Map.keySet() и Map.values()
7. Arrays.asList может быть ключом
8. Collections.max
9. LinkedList, Stack, Vector, Hashtable

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

Алгоритм

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

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

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

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

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

Поводом для написания статьи стала публикация исходного кода языка Swift — мне стало интересно поближе познакомиться с ним. В глаза сразу же бросилась схожесть синтаксиса с другим молодым языком программирования под названием Rust, к тому же за схожими синтаксическими конструкциями просматривалась и схожая область применения этих языков. Оба языка имеют сильную статическую типизацию с локальным выводом типов, оба компилируются напрямую в машинный код. И тот и другой языки впитали в себя многие приемы из мира функционального программирования. И Swift и Rust имеют средства для запуска кода, написанного на C, что позволяет без труда писать обертки над огромным количеством библиотек. Оба языка рассматриваются как замена существующим системным языкам типа C, C++, ObjectiveC. Так что же в них общего, а что различается?

             Хотя этикетка была не того цвета и содержала немало орфографических ошибок, большая ее часть находилась на месте, включая сделанную крошечным шрифтом надпись «Может содержать орехи».
                                                         сэр Терри Пратчетт 

Го или Ур? Можно долго спорить, какая из игр древнее, но победит, в этом противостоянии, скорее всего, Манкала. Археологи предпочитают иметь дело с материальными свидетельствами, но как только речь заходит о настольных играх, всё быстро уходит в область предположений. Было найдено немало досок, но гораздо меньше сведений о том, как на них играть. Древние не утруждали себя детальным описанием правил.

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

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

Каким образом? А очень просто — я вообще не буду ничего вкраплять в стегоконтейнер. Действительно, если мы ничего не вкрапляем, то пустой контейнер неотличим от стегоконтейнера, верно?

«Подождите, но ведь если мы совсем ничего не вкрапляем, то мы совсем ничего не передаем!!!» — разумно поспорит со мной читатель.

Абсолютно верно! Вкраплять мы и не будем! Есть способ, не искажая контейнер, тем не менее передать информацию. Как?

Cхематично Хеш-стеганографию ɔ⃝
можно представить так:


Текстовое пояснение к картинке под катом.

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



В качестве таковых рассмотрим следующие:

• Реализуем пакет доступа к API ВКонтакте.
  Код будет работать как в «native» приложениях, так и в приложениях JavaScript через GHCJS, компилятор Haskell в JavaScript
  
• Напишем одностраничное браузерное приложение, используя наше API
  

«Не звони и не пиши мне больше!!!!» — пришла смс-ка от моей девушки Кати. Через пару часов я осознал, что теперь у меня появилась куча свободного времени и я решил переписать Dcoin на Go.

В этой статье я расскажу об использовании нереляционной базы MongoDB для мониторинга журнальных файлов. Для мониторинга log-файлов существует множество инструментов, от мониторинга shell-скриптами, завязанными на cron, до кластера apache hadoop.



Подход с мониторингом скриптами текстовых файлов удобен только в простейших случаях, когда, например, проблемы выявляются наличием в журнальном файле строк «ERROR», «FAILURE», «SEVERE» и т.п. Для мониторинга больших файлов удобно использовать систему Zabbix, где Zabbix Agent (active) будет считывать только новые данные и с определённой периодичностью отправлять их на сервер.

Относительно недавно мне посчастливилось присоединиться к команде разработки Bitbucket Server в Atlassian (до сентября он был известен как Stash). В какой-то момент мне стало любопытно, как этот продукт освещён на Хабре, и к моему удивлению, нашлось лишь несколько заметок о нём, подавляющее большинство которых на сегодняшний день уже устарело.

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

Позвольте начать с перевода статьи Тима Петтерсена «A better pull request» о том, как должен выглядеть pull request, чтобы наиболее эффективно решать возложенную на него задачу.

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