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

Тест FizzBuzz — написать программку, которая выдаёт числа от 1 до 100, где кратные трём заменяются словом “Fizz”, кратные пяти — словом “Buzz”, а кратные пятнадцати — “FizzBuzz”. Поскольку такая программа реализуется в нескольких строчках кода, то её часто задают на собеседованиях чтобы отсеять тех, кто вообще не умеет программировать.


Плата Mojo FPGA, подключенная к порту serial-to-USB. Большой чип на плате — это Spartan 6 FPGA

Реализация FizzBuzz в цифровой логике, а не в коде, довольно бессмысленна, но показалась мне хорошим примером для обучения.¹ Для этого проекта я использовал простую плату разработки Mojo V3 FPGA для начинающих. На ней установлен FPGA семейства Xilinx Spartan 6. Это один из самых маленьких FPGA, но у него 9000 логических ячеек и 11 000 триггеров — так что малыш на многое способен.

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



Ан нет, в суровой реальности всё несколько прозаичнее. Этим постом хочу поделиться нашим опытом работы с двумя решениями WIPS (Wireless Intrusion Prevention System). В первой части расскажу, что такое WIPS вообще и зачем он нужен, а также дам краткий обзор ключевых возможностей продукта Mojo AirTight и описание требуемых настроек. Во второй части планирую рассмотреть аналогичное решение от Cisco.

Шаринг музыки по локальной сети через iTunes всегда был относительно безболезненным. Собственно, это занимает три простых шага. Стримминг музыки через интернет немного более сложен, но с правильным софтом или веб-сервисами все решаемо. Некоторые программы выходят через Hamachi (который использует VPN) и Simplify Media. Онлайновые сервисы вроде DOT.Tunes, nuTsie иMaestro также позволяют стримать музыку, но только через браузер. Это в принципе неплохо, потому что можно получить доступ к своей библиотеке из любого места, не имея при этом iTunes или WinAmp.

Чтобы просто делится музыкой с другого компьютера, я бы рекомендовал использовать Simplify Media. Неделю назад она была выложена Айбеком в iTunes Addons, и сейчас я о ней расскажу. Если кратко, то Simplify Media позволяет слушать расшаренную музыку ваших друзей так, как будто они находятся в одной локальной сети с вами. У меня нет спецификаций ее работы, но я думаю, что она работает как и Hamachi, устанавливаю VPN соединение между вами и человеком, добавленным в контакт-лист. работает под Mac, Windows и Linux; и совместима с iTunes, WinAmp и, конечно, с iPhone.

Но у Simplify Media есть приемник, Mojo. С помощью Mojo вы можете находить, слушать и скачивать расшаренную музыку ваших друзей.

По просьбе товарища keksn, администратора блога Mobile Development, сливаю прошлые посты-ссылки о разработке для Palm WebOS в один пост.

Дорогие друзья, в один прекрасный день мы решили создать сайт хороших историй, где бы можно было прочитать хорошую добрую историю из жизни или какой-то поучительный случай, а также прислать свою историю или историю/рассказ/причту, которая повлияла на вашу жизнь. И мы создали goodstories.ru В процессе разработки этого сайта появился и сайт студенческих историй, целью которого является собрание всех студенческих историй рунета, а также добавление новых веселых случаев из студенческой жизни.

Я обнаружил что релиз замечательного перлового фреймворка Mojolicious на Хабре остался совершенно незамеченным. А тем временем, уже доступна версия v1.12, это прискорбно, т.к. теперь на перле стало писать проще чем никогда. Покажу это на реальном примере.

Планшет HP TouchPad является весьма незаурядным webOS-девайсом, обладающим свойством обратной совместимости с практически любым приложением для смартфонов на платформе webOS, созданным с помощью фирменной среды разработки Mojo SDK (далее Mojo-приложения). Единственным серьезным недостатком является то, что Mojo-приложения запускаются в привычном для смартфонов разрешении 320x480 точек, совершенно игнорируя дополнительное пространство экрана планшета.

Данная статья поможет вам быстро адаптировать телефонное приложение, созданное в среде разработки Mojo SDK, для нового планшета от HP.

Update: статья обновлена для соответствия Mojolicious 6.0.

Mojolicious — восхитительный современный веб-фреймворк для Perl. Из недостатков я могу назвать только два: политика в отношении обратной совместимости и документация.

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

Содержание

1. Недостатки
2. Роутинг: внутреннее устройство
3. Роутинг: настройка
4. Параметры HTTP-запроса
5. Парсинг
6. Tips & Tricks
   
   1. Поддержка неблокирующих приложений в режиме CGI
   2. Как работает Mojo::UserAgent при тестировании своего приложения
   3. ojo и Mojolicious::Lite
   4. Переменные окружения
   
   

Другие статьи в этой серии

• Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay

Недостатки

В официальном FAQ написано: "… we will always deprecate a feature before removing or changing it in incompatible ways between major releases … as long as you are not using anything marked experimental, untested or undocumented, you can always count on backwards compatibility …". Для начала, вторая фраза противоречит первой. Далее, вот цитата из Guides::Contributing «Features may only be changed in a major release or after being deprecated for at least 3 months.». Честно говоря, 3 месяца это и так смешной срок когда речь идёт об обратной совместимости, но похоже что даже этот срок соблюдается не всегда (поддержку «X-Forwarded-HTTPS» сделали deprecated два месяца назад, а удалили месяц назад — да, это был «major release» поэтому формально правила не нарушены, но общее отношение к обратной совместимости вполне показательно). Как много разработчиков обновляет фреймворк чаще чем раз в 3 месяца, да ещё и при этом тщательно вычитывает Changes или логи своего приложения на предмет deprecated-предупреждений? При этом, в течении последнего года было deprecated примерно 20 функций/фич. На практике, конечно, всё не так плохо, как это звучит — что-то ломается не так уж часто (лично меня за последний год коснулась только замена $app->secret() на $app->secrets()). Но факт остаётся фактом — обратную совместимость ломают, ломают часто, причём без по-настоящему веских причин: например, в случае с secret() абсолютно ничего не мешало добавить в код

sub secret { shift->secrets([shift]) }

либо просто добавить поддержку дополнительных параметров в secret() вместо добавления новой функции secrets() реализовав нужную фичу вообще не ломая совместимость.

Что касается документации, то многие считают её отличной, даже одним из серьёзных достоинств Mojolicious, но никак не недостатком. Проблема с документацией в том, что она вся сосредоточена на примерах. Это реально круто, когда ты начинаешь изучать фреймворк. Это экономит кучу времени, когда тебе нужно сделать фичу и ты быстро гуглишь пример аналогичной фичи в официальных guides. Но как только ты выходишь за рамки стандартных задач и возникает необходимость понять, как что-то устроено идеологически или архитектурно, какие конкретно параметры может принимать эта функция и что конкретно она может возвращать в разных ситуациях — выясняется, что для многих модулей Mojolicious такая документация отсутствует в принципе. И не потому, что эта информация относится к «недокументированным возможностям» — почти всё это мельком упоминается здесь и там в разных примерах, а значит считается «документированным». Нередко есть несколько способов получить доступ к определённым данным (параметры запроса, тело ответа, etc.) но не описано чем они друг от друга отличаются и в каких ситуациях правильнее пользоваться какими способами. И последнее — алфавитный порядок функций в доке, серьёзно?! Нет, я понимаю, все люди разные и кому-то наверняка это удобно, но многим всё-таки на порядок проще воспринимать документацию в которой функции сгруппированы по задачам. (Хотя в коде, особенно при чтении его через браузер, где не так удобно пользоваться поиском как в Vim, алфавитный порядок функций неожиданно оказался довольно удобным — кроме new/DESTROY/AUTOLOAD — их всё-таки лучше размещать в начале.) В результате, чтобы разобраться приходится вычитывать код (некоторые предпочитают вместо этого смотреть тесты!), что не так просто — во-первых он не является эталоном читабельности: автор любит использовать фишки перла, которые позволяют писать код компактно (и нередко такой код быстрее работает), но читабельность это ухудшает; во-вторых активное использование и наследования и обмена событиями между объектами усложняет понимание того, что и как происходит внутри 104 классов, из которых состоит Mojolicious-5.

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

Это продолжение серии статей о веб-фреймворке для Perl — Mojolicious: первая часть.

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

Асинхронность: синхронизируем с помощью Mojo::IOLoop::Delay

Mojo::IOLoop::Delay предоставляет механизм, обеспечивающий для асинхронно выполняющихся callback-ов:

• описание последовательно выполняющихся операций без «лапши» callback-ов
• передачу результатов из callback-а(ов) текущего шага на следующий
• общие данные для callback-ов, объединённых в одну задачу
• синхронизацию групп callback-ов
• перехват и обработку исключений в callback-ах

Используемые термины:

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

Альтернатива Promises

Это альтернативный подход к проблеме, обычно решаемой с помощью Promise/Deferred или Future. Вот приблизительное сравнение со спецификацией Promises/A+: 

Хочу описать стиль программирования на языке Perl, к которому я стремлюсь и который в основном перенял от современного web-фреймворка Mojolicious, но наверное много где еще применяется подобный. Мне кажется выработать правильный стиль кодинга — очень важно.

Пример 1:
Методы в одну строку.
Если обращение к каждому аргументу функции происходит лишь один раз, и порядок применения их в коде соответствует порядку переданных аргументов, то предлагается извлекать их с помощью стандартной функции shift, которая если вызывается без аргументов, по-умолчанию работает с массивом @_, в котором хранятся все переданные аргументы функции, выталкивает первый аргумент из массива и возвращает его.

sub node { shift->tree->[0] }
#
sub parse { shift->_delegate(parse => shift) }
#
sub _tag { shift->new->tree(shift)->xml(shift) }

Пример 2:
Сначала извлекаем первый параметр, имя класса например, все остальные аргументы передаем другой функции и пусть она их обрабатывает.

sub tree { shift->_delegate(tree => @_) } 
# т.е. может превратиться в это _delegate(tree => [], deep => 5) или это _delegate(tree => [], 5, 0) 
sub log { shift->emit('message', lc shift, @_) }

Пример 3:
Тоже для метода в одну строчку.
Здесь происходит обращение к одному и тому же аргументу целых 3 раза, потому для доступа к аргументу используется прямое обращение к элементу массива аргументов $_[0].

sub _instance { ref $_[0] ? $_[0] : $_[0]->singleton }
#
sub find { $_[0]->_collect(@{$_[0]->_css->select($_[1])}) }

_{Фото: www.wired.com/JULIAN CHOKKATTU}

Стартап Mojo Vision презентовал прототип «умных» контактных линз, которые имеют встроенный дисплей с разрешением 2 млн пикселей на дюйм. Данная разработка может изменить технологию дополненной реальности. Над ней работали более 10 лет.

Для сравнения — на виртуальной гарнитуре Oculus Rift S плотность пикселей составляет 538 ppi.