Введение

В былые времена я увлекался компьютерной графикой, как 2х так и 3х мерной, в том числе математическими визуализациями. Что называется just for fun, будучи студентом, написал программу визуализирующую N-мерные фигуры, вращающиеся в любых измерениях, хотя практически меня хватило только на определение точек для 4-D гиперкуба. Но это только присказка. Любовь к геометрии осталась у меня с тех пор и по сей день, и я до сих пор люблю решать интересные задачи интересными способами.
Одна из таких задач попалась мне в 2010 году. Сама задача достаточно тривиальна: необходимо найти, пересекаются ли два 2-D отрезка, и если пересекаются — найти точку их пересечения. Более интересно решение, которое, я считаю, получилось достаточно элегантным, и которое я хочу предложить на суд читателя. На оригинальность алгоритма не претендую (хотя и хотелось бы), но в сети подобных решений я найти не смог.

Tabris.js — еще один кросс-платформенный (Android, IOS) мобильный фреймворк. От подавляющего большинства подобных инструментов он отличается тем, что это не обертка над стандартным или Chrome-based WebView. Tabris предоставляет собой набор нативных компонентов, доступный из javascript. Ближайшие аналоги из мне известных это: Telerik Native Script, Appcelerator и React Native.

«Начало — более чем половина всего».

Это очень древний GTD-принцип: возраст его, вероятно, исчисляется тысячелетиями. (Например, Викицитатник в настоящее время приписывает его Аристотелю, хотя и без подтверждающего указания на первоисточник.) Суть его в том, что с чистого листа начинать какой-либо проект бывает очень трудно (и даже приходится заставлять себя); а вот если есть несколько простых начальных шагов, выполнение которых приводит к появлению частично готового проекта, то продолжить работу над ним «по инерции» становится куда проще — так просто, как если бы проект этот ужé был не только начат, но и готов даже более, чем наполовину. А кроме того, когда заранее хорошо знаешь, какими должны быть начальные шаги, то тогда трудно бывает допустить ошибку, совершая их.

Мне довелось сочинить более десятка модулей для Node.js с открытым исходным кодом и опубликовать их в качестве пакетов npm. Чем больше модулей я делал, тем сильнее понимал (в том числе путём проб и ошибок), что начальные шаги для их создания могут быть одинаковыми и даже могут совершаться в одном и том же порядке. Сегодня я публикую этот порядок в надежде на то, что он станет подспорьем в работе программистов, сочиняющих свой код на языке JavaScript для движка Node.

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

В первой части мы остановились на следующей спецификации: Трансдьюсер — это функция принимающая функцию step, и возвращающая новую функцию step.

step⁰ → step¹

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

result⁰, item → result¹

Чтобы получить новый текущий результат в функции step¹, нужно вызвать функцию step⁰, передав в нее старый текущий результат и новое значение, которое мы хотим добавить. Если мы не хотим добавлять значение, то просто возвращем старый результат. Если хотим добавить одно значение, то вызываем step⁰, и то что он вернет возвращаем как новый результат. Если хотим добавить несколько значений, то вызываем step⁰ несколько раз по цепочке, это проще показать на примере реализации трансдьюсера flatten:

function flatten() {
  return function(step) {
    return function(result, item) {
      for (var i = 0; i < item.length; i++) {
        result = step(result, item[i]);
      }
      return result;
    }
  }
}

var flattenT = flatten();

_.reduce([[1, 2], [], [3]], flattenT(append), []); // => [1, 2, 3]

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

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

Итак, сейчас мы можем:

1. Изменять элементы (прим. map)
2. Пропускать элементы (прим. filter)
3. Выдавать для одного элемента несколько новых (прим. flatten)

Рич Хикки, автор языка Clojure, недавно придумал новую концепцию — Трансдьюсеры. Их сразу добавили в Clojure, но сама идея универсальна и может быть воспроизведена в других языках.

Сразу, зачем это нужно:

• трансдьюсеры могут улучшить производительность, т.к. позволят не создавать временные коллекции в цепочках операций map.filter.takeWhile.etc
• могут помочь переиспользовать код
• могут помочь интегрировать библиотеки между собой, например underscore/LoDash могут уметь создавать трансдьюсеры, а FRP библиотеки (RxJS/Bacon.js/Kefir.js) могут уметь их принимать
• могут упростить FRP библиотеки, т.к. можно будет выбросить кучу методов, добавив один метод для поддержки трансдьюсеров

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

Вам интересно, сколько стоит разработка онлайн-игры? Вы хотите узнать, как организовать разработку ММО от идеи до релиза? Задумывались ли вы о технических трудностях создания онлайн-игр?

        В цикле статей «Разработка ММО РПГ – практическое руководство» вы получите ответы на эти и многие другие вопросы. Все цифры реальны. Все схемы, таблицы, исходный код, диаграммы БД и прочее взяты из реально существующего и успешно работающего проекта.
        В тексте будет много отсылок к геймплею и внешнему виду нашей игры «Звездные Призраки». Я постараюсь излагать материал так, чтобы вам не было нужды вникать (и играть) в наш продукт, но для лучшего понимания материала желательно потратить пару минут и посмотреть, как это все выглядит.
        Готовы? Тогда в путь!

Перевод поста Piotr Wendykier "Extending Van Gogh's Starry Night with Inpainting"
Скачать перевод в виде документа Mathematica, который содержит весь код использованный в статье, можно здесь (архив, ~8 МБ).

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


Вторая премия на фотоконкурсе ZEISS

У меня есть сайт со статьями схожей тематики. На сайте было две проблемы: спамерские сообщения и дубликаты статей, причём дубликаты часто являлись не точными копиями.

Данный пост повествует о том, как я решил эти проблемы.

Дано:

• общее количество статей 140 000;
• количество спама: примерно 16%;
• количество не чётких дубликатов: примерно 63%;

Задача: избавиться от спама и дубликатов, а так же не допустить их дальнейшего появления.

Привет. Это пост о новой версии Тарантула «от автора». Интернет занятно устроен: если поискать про Тарантул, то найдётся статья от 2011 года, о версии 1.3. И ещё какой-то перфоратор, кажется. На форумах-бордах вообще стоит густой туман. Тарантул «ну это как Редис, только»…

Или ещё, недавно сделал для себя открытие, на Тостере кто-то написал «София — это такое append-only хранилище по типу Тарантула». С такими постами я скоро стану фанатом сайта «сделано у нас», автомата Калашникова и Саяно-Шушенской ГЭС. Правда, мне сложно понять, почему мы восхищаемся западными инструментами, при этом представления не имеем о своих. Итак, Tarantool 1.6. В чём фишка?

В прошлом году понятие «внебраузерный JavaScript» чаще всего означало движок Node.js (а не, допустим, Rhino или SpiderMonkey, сильно уступающие ему в популярности в этой области) или какой-нибудь итог его встраивания (например, node-webkit).

В нынешнем году в игру вступают форки Node (например, io.js), и их также начинают встраивать — например, проект node-webkit переименовался в nw.js, потому что теперь он использует не Node, а io.js (да и не WebKit, а Blink — с тех давних пор, как Chromium перешёл на этот движок).

Для программистов это означает, в частности, что может отвалиться (или, наоборот, появиться) поддержка той или иной операционной системы. Давайте поговорим об этом.

Какие операционные системы перестают поддерживаться?

Во-первых, первые версии io.js нельзя было установить на Windows XP, нельзя было установить и на Windows 2003. Ещё в середине января казалось, что с этим ничего нельзя поделать: объяснение «io.js компилируется в Visual Studio 2013 Windows Desktop Edition, потому что движок V8 стал полагаться на возможности C++11» воспринималось как приговор — однако затем разработчики поправили дело, так что в файле CHANGELOG.md ветви v1.x можно прочесть, что поддержка этих версий системы Windows возвратилась в io.js, начиная от версии io.js 1.0.3 (20 января).

Подобно кругам по воде, эти изменения прошли по всей экосистеме движков; например, в nw.js версии 0.12.0-alpha3 на поддержку ещё можно надеяться (хотя лично я ещё не успел погонять эту версию на Windows XP), а в предыдущих альфа-версиях её точно нет (потому что они основаны на более ранних версиях io.js).

Во-вторых, KaneUA 19 февраля упомянул, что io.js не поддерживает тридцатидвухбитные версии OS X, в отличие от Node.

Поддержка каких операционных систем может появиться?

Я постоянно слышу людей, ноющих об асинхронных коллбэках в JavaScript. Держать в голове порядок исполнения в этом языке немного трудно (это тот случай, который называют «Callback Hell» или «The Pyramid of Doom»), если до этого ты имел дело с синхронным программированием. Моим обычным ответом было «тебе придется как-то с этим обходиться». В конце концов, ожидаем ли мы, что все языки программирования будут выглядеть и ощущаться одинаково? Конечно нет.

Все поменял недавний обзор черновика ECMAScript 6, в котором описываются генераторы — возможность языка, которая целиком изменит наш способ написания и серверного, и клиентского JavaScript. С помощью генераторов мы можем превратить вложенные коллбэки в похожий на синхронный код без блокирования нашей единственной event loop.
Например, этот код:

    setTimeout(function(){
        _get("/something.ajax?greeting", function(err, greeting) {
            if (err) { console.log(err); throw err; }
            _get("/else.ajax?who&greeting="+greeting, function(err, who) {
                if (err) { console.log(err); throw err; }
                console.log(greeting+" "+who);
            });
        });
    }, 1000);

может быть написан так:

    sync(function* (resume) {
        try (e) {
            yield setTimeout(resume, 1000);
            var greeting = yield _get('/something.ajax?greeting', resume)
            var who = yield _get('/else.ajax?who&greeting=' + greeting, resume)
            console.log(greeting + ' ' + who)
        }
        catch (e) {
            console.log(e);
            throw e;  
        } 
    });

Интересно, не правда ли? Централизованная обработка исключений и понятный порядок исполнения.

Доброго времени. В конце октября был хороший пост «Умей говорить «нет» и умей говорить «да»».
Мы оперативно запросили электронные права на книгу, из которой автор поста брал идеи.



Идеальный программист. Как стать профессионалом разработки ПО
Автор: Р. Мартин
Прототип: The Clean Coder: A Code of Conduct for Professional Programmers

Недавно мне выпал шанс заняться веб-приложением для взаимодействия с интерактивной доской (!) для мобильных устройств (!!) на любом стеке технологий, как серверных, так и клиентских (!!!). На этапе прототипа задача представляла собой простейший графический редактор. Заказчик изъявил желание уметь рисовать ломаные каким-нибудь способом, круги, отрезки, произвольные кривые и добавлять текст. Все вроде бы просто, однако, наученный горьким опытом GoF, Фаулера и прочих апологетов всяческих паттернов, я сразу понял, что заказчик лукавит, и что уже через неделю-месяц после прототипа ему понадобится рисовать эллипсы, прямоугольники и кучи прочих ништяков. И все это точно надо будет делать разными способами. По крайней мере, для десктопа и мобил.

Собственно, можно все сделать в лоб (для прототипа-то), но выпали выходные, пауза в задачах текущего проекта, и я решил сделать все по-хорошему. И в первый же вечер — callback hell.

А потом…

Операция слияния (merge), выполняемая стандартными средствами git, хорошо работает для текстовых файлов, содержащих исходные тексты программ. Но слияние текстовых файлов, содержащих жестко структурированные данные, в частности JSON — это большая головная боль.

Для решения этой проблемы можно подключить к git'у отдельный инструмент слияния для JSON-файлов, который не работает построчно, а учитывает структуру JSON-объектов.

Предлагаю использовать для этого скрипт на javascript, который анализирует сливаемые JSON-файлы и делает слияние на основании структуры и вложенности объектов JSON.

Обработка ошибок в JS – та еще головная боль. Не ошибусь, если скажу, что ошибки – самое слабое место всего языка. При чем проблема состоит из двух других: сложности отлова ошибки в асинхронном коде и плохо спроектированного объекта Error. И если первой проблеме посвящено множество статей, то о второй многие незаслуженно забывают. В этом материале я постараюсь восполнить недостаток и рассмотреть объект Error более пристально.

Все помнят этот фильм? Какого черта он делает на Хабре? И вообще что тут делает подобный пост?
Наверное потому, что я считаю главным звеном в IT все таки человека, а точнее его мозги. Я попробую рассказать еще об одной возможности использовать свой мозг чуточку эффективнее. Одна из слабо задокументированных возможностей, которую мы используем каждый день, но не всегда даже об этом вспоминаем. Все описанное проверялось на мне. Если что-то я не пробовал, но рассказать об этом важно буду отмечать особо. Никаких наркотиков, аппаратов и издевательств над собой, только общедоступные легкие методики (короче, лег проспался и вперед, не вставая даже с кровати).
И да… Это до жути реалистично, на столько, что попробовав, вы не сможете не рассказать об этом.

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

Недавно в топе Хабра появился пост, заставивший меня вылезти из read-only: «Overclock мозга или внутрення виртуализация сознания».
Вводящее в заблуждение название и не менее спорное содержание. Неприятные ощущения вызывает еще и тот факт, что при всей неточности и искажении фактов автор осмелился прикрепить к нему метку tutorial.

Желающих взглянуть на осознанные сновидения без налета авторской фантазии, прошу под кат.

Недавно мне посчастливилось не только потестить российский принтер PrintBox3d, но и заглянуть в цех по производству.
Чем и хочу поделиться с хабрачитателями.

Это не гаджет, это рабочая лошадка, которая будет работать годами.

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

Фишки:
— 2 мотора на ось Z
— Метеоритоустойчивая рама
— Собственные контроллеры шаговых двигателей на основе разработок для промышленных ЧПУ
— Много запасных частей

Осторожно! Много алюминия!

3D-принтеров печатающих пластиком ABS и/или PLA все больше и больше. Хотя основных конструкций, по большому счету, всего 2-3. Поэтому создатели новых принтеров стараются реализовать в конструкции некоторую изюминку или просто сделать еще дешевле.

Пост содержит перевод статьи «Error Handling in Node.js», которую подготовили сотрудники компании Joyent. Статья была опубликована 28 марта 2014 года на сайте компании. Dave Pacheco поясняет, что статья призвана устранить неурядицу среди разработчиков, касаемо лучших практик работы с ошибками в Node.js, а так же ответить на вопросы, которые часто возникают у начинающих разработчиков.