Я хочу описать простой минималистский подход к разработке сложных JavaScript приложений. Из внешних библиотек будут использоваться только jQuery и мой js-шаблонизатор, причём из jQuery используются только $.ready(), $.ajax() и $.proxy() — т.е. суть не в библиотеках (их тривиально заменить на предпочитаемые вами), а в самом подходе.

В основе подхода лежат две идеи:

1. JavaScript виджеты — небольшие модули, каждый из которых «владеет» определённой частью веб-странички (т.е. всё управление этой частью странички происходит исключительно через методы этого модуля, а не через прямую модификацию DOM — инкапсуляция). Виджет отвечает исключительно за функциональность, но не за внешний вид; поэтому прямая модификация части DOM, которым «владеет» виджет, снаружи виджета допускается — но только для чисто дизайнерских задач (для архитектуры и общей сложности приложения нет принципиальной разницы между коррекцией внешнего вида через CSS или jQuery).
2. Глобальный диспетчер событий. Взаимодействие между виджетами осуществляется путём посылки сообщений глобальному диспетчеру (слабая связанность, паттерн Mediator/Посредник), а уже он принимает решение что с этим сообщением делать — создать/удалить виджеты, дёрнуть методы других виджетов, выполнить дизайнерский код, etc. В отличие от динамического подхода к обработке событий (когда обработчики конкретного события добавляются/удаляются в процессе работы) статический диспетчер сильно упрощает понимание и отладку кода. Безусловно, есть задачи, для которых нужны именно динамические обработчики событий, но в большинстве случаев это избыточное усложнение, поэтому всё, что можно, делается статическими обработчиками.

Самый большой недостаток экосистемы языка Perl — управление модулями (другой кандидат на эту роль — долгострой Perl6, но не будем о нём). Что любопытно, самое большое достоинство этой же экосистемы — наличие единого архива модулей CPAN. Поразительно, собрать и организовать модули смогли, а реализовать удобную установку/обновление/удаление — нет.

Богатство выбора… или очередное TIMTOWTDI

Существует множество альтернативных подходов к этой задаче (и их количество тоже косвенно указывает на то, что ни один из них не решает проблему достаточно хорошо): cpan, cpanplus, cpanminus, pip, cpansite, minicpan/mcpani, perlbrew, cpan-outdated, cpan-listchanges, local::lib, …

Итак, у нас может быть:

• Несколько версий самого perl (разумеется, каждая со своими глобальными модулями), в т.ч. установленные в домашний каталог юзера (см. perlbrew).
• Глобальные (доступные при запуске perl) и локальные (подключаемые из любого каталога/каталогов, обычно располагающиеся внутри отдельного проекта или в домашнем каталоге пользователя) модули.
• Глобальные модули бывают трёх типов: core (идущие вместе с perl), site (устанавливаемые вручную админом) и vendor (устанавливаемые менеджером пакетов вашей ОС).
• Все глобальные модули находятся в подкаталогах «номер.версии.perl/», и эти каталоги никто автоматически не чистит. А при установке новой версии perl создаются новые аналогичные каталоги. И perl подгружает модули из каталогов всех доступных предыдущих версий. Так что умножьте core+site+vendor на количество обновлений perl — вот в таком количестве каталогов/вариантов находятся ваши глобальные модули.
• Источники модулей тоже бывают разные: CPAN, локальные зеркала-оверлеи CPAN с приватными модулями, просто свои или скачанные из инета модули отсутствующие в CPAN-совместимой системе.

И всю эту радость надо администрировать: устанавливать, обновлять, … В Gentoo для упрощения администрирования глобальных Perl-модулей есть утилитка g-cpan, вот о ней я и хочу немного рассказать.

Вы захотели сделать браузер с плагинами, программу с темами, игру с аддонами или какое-то другое модульное приложение для Android? Но как это сделать? Я расскажу, как сделать простое приложение, которое будет получать текст от модулей.

Часть 1

Heap

Чтобы на C корректно создавать и уничтожать сложные структуры, с которыми будет работать код на Limbo, необходимо представлять себе как они хранятся в памяти, т.е. как организован heap в Inferno. Все упомянутые ниже функции для работы с heap описаны в libinterp/heap.c, а структуры в include/interp.h.

Модули для Limbo написанные на C так же иногда называют драйверами OS Inferno т.к. они встроены в ядро OS. Необходимость в таких модулях обычно вызвана либо желанием добавить к Limbo отсутствующую в Inferno функциональность (подключить существующие 3rd-party C/C++ библиотеки, дать доступ к специфичным для конкретной host OS syscall-ам) либо желанием выжать максимально возможную производительность (по моим наблюдениям разница в скорости между Limbo с включенным JIT и C примерно 1.3-1.5 раза, но иногда и это может оказаться критичным).

На прямо сейчас проходящей в Лас-Вегасе конференции MIX11 была представлена новая версия Orchard CMS – open-source CMS от Microsoft включающая все самое вкусное и полезное из технологий MSFT, находящаяся, можно сказать, на острие. После первого взгляда – CMS вполне понравилась (сравниваю, в основном, с Umbraco) – и появилось желание разобраться — как же собственно происходит разработка для Orchard. Если в этом ваши желания совпадают с моими — читайте дальше.

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

Реализация мега простая, хотя для меня была не очевидной. Уверен кому-нибудь тоже будет интересно/полезно занать как это сделать.

Привет %username%,

В ответ на «Нетривиальная задача для Node Reference поля Drupal», решил подпилить для кулинарии один из кастомных модулей.

Необычное устройство Modu, выпустил израильский оператор Cellcom. Девайс позиционируется как модульный телефон. Словечко «модульный» — лучшее, из тех что можно придумать для его описания.

Суть идеи в том, чтобы выпустить небольшой контролирующий модуль, напоминающий мобильный телефон и множество корпусов к нему, которые отвечают определенным потребностям пользователей. Идея сия была реализована и в августе телефон поступит в продажу в Азии по $130 за телефон и один модуль к нему.



Сам изначальный модуль очень невелик и без дополнительного корпуса почти бесполезен. Но, корпуса вдыхают в него самую разнообразную жизнь. Один корпус превращает модуль в музыкальный плеер, другой — в GPS-навигатор, третий — в мобильную игровую консоль. И под любым соусом Modu работает как мобильный телефон в сетях 2G.

Идея, в целом, достойная, и если дополнительные модули будут продаваться по адекватной цене, то новинка получит спрос. На сайте Modu можно узнать, какие именно модули разработаны на данный момент, но до России телефон пока не доехал.

И, напоследок, видео-повествование о Modu (на английском).