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

И даже иногда хочется чтобы было почти как в Erlang.

Идея создания фреймворка для микросервисов для NodeJs удачно воплощалась не единожды — так у нас как минимум есть Seneca и Studio.js, которые безусловно хороши, но они определяют большие логические единицы. С другой стороны у нас есть обычные объекты, разделяемые в системе посредством Dependency Injection или подобной техники, но они не дают должной четкости границ.

Иногда нужны "нано-сервисы".

Today's software engineering word is «farpotshket.» This is a Yiddish word meaning, «broken, because someone tried to fix it.»
(с) Andr Zerozero

Схлеснулись мы тут на днях на работе по вопросу «А хорошо бы закешировать регулярку», в совершенно банальной функции

  uncached = function(data_in) {
    return /_(\d)+(?:#(\d)+)?$/.exec(data_in);
  };

сделав как-то так

  cached = (function() {
    var pattern = /_(\d)+(?:#(\d)+)?$/;
    return function(data_in) {
      return pattern.exec(data_in);
    };
  })();

Идея популярная, но многие ли задумывались о реальном профите и накладных расходах?

Если вы пользуетесь stitch и вам его маловато, а browserify показался сложноват по настройкам — попробуйте clinch.

Что в коробке:

• простой API
• поддержка .js, .json, .coffee, .eco, .jade
• develop-mode ready — легко встроить в express, умный кеш с инвалидацией
• малый overhead на bundle ~ 40 SLOC
• простой механизм подмены модулей и имитации глобальных объектов

Статья о простом, но не очевидном способе как сделать код чище и избавиться от копипасты.

Условно проблема выглядит вот так:

###
My awesome class
###
class Awesome
  doFoo : (arg, cb) ->
    unless arg is 42
      return cb Error """
                      only The Answer may be an argument, but got:
                      |arg| = |#{arg}|
                      """
    cb null, "#{arg} is The Answer"

  doBar : (arg, cb) ->
    # hm... arg must be The Answer too

У нас есть кусок кода (тот, что с проверкой), который во-первых похоже потребуется повторить в новом методе, да и вообще отвлекает от основного действа в методе.

Дата — крайне неудобная штука для работы с ней в плане создания UI.

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

Мой (второй) вариант решения проблемы(апдейт)


Для самых нетерпеливых — да, есть функционирующее демо — jsfiddle.net/Meettya/aDAsa/embedded/result

Грустная история о том, как все обязательно пойдет плохо, если вы связались с BBK, «Перекрестком» и e5.ру.

Я уже довольно давно использую coffee-консоль как калькулятор. Удобно!

И вот недавно задумался — почему бы не попробовать написать CLI-скрипт на CoffeeScript от начала и до конца? И написал!

Думаю многие понимают значение баззвордов Inversion of Control (Ioc) и Dependency Injection (DI). Если не очень, но интересно — на хабре было несколько статей на эту тему, очень познaвательно и доступно изложено.
Методики отличные, но применить их в настоящей жизни как-то не получалось.

Под катом — небольшой обзор плачевного состояния дел в Perl и самостийное «кажется» решение.

У GitHub есть забавная штука, называется GitHub Pages.

Использоваться может двояко – можно или сайт замутить, или сделать доки к репозитарию, в мануале об этом подробно написано.

Нас сейчас сайт не интересует, а вот доки к репозитарию – тема что надо. Я для примера буду использовать проект на javascript, но это не важно, Natural Docs поддерживает приличную пачку языков, чем и хорош.

Сегодня зарелизен свеженький модуль для работы с .yaml конфигурационными файлами. Как обычно, доступен общественности на github Config::YAML::Modern, в CPAN будет добавлен немного позднее Config::YAML::Modern.
Почему этот модуль может быть вам интересен? Он умеет несколько клевых трюков, например:

• корректно смерджить пачку .yaml файлов из директории
• преобразовать file.name.yaml имя файла в { File => { Name => { _content here_ } }
• предоставляет чумовой path-resolution в dive-стиле qw/File Name inner_hash 0 my_key/

Области применения? Навскидку — конфигурация проекта при коллективной работе!
Интересно? Подробности под катом.

В процессе писания REST-сервиса уткнулся в странную проблему — не нашел приличного инструмента для отладки jsonp ответа от сервера.
За пол-дня накидал приемлемый вариант — одна html страница, которую можно хоть прямо с диска загрузить и кучка чужих js-либ, чтобы вся эта красота работала.
Выглядит примерно так:



Все бобро выложено на github, если кому-то нужно — пожалуйста!

Disclaimer: может оказаться полезным в случае если вам нужен кросс-платформенный и кросс-браузерный нативный «ajax-клиент имитатор» для кросс-доменных запросов с малым потреблением памяти и наглядным вводом и выводом ответа сервера.

Решая проблему вычисления объемных данных в циклах частенько тянет распараллелить задачку.
Конечно же в perl есть сразу пара моделей: fork или thread, позволюящих использовать «многопоточность». Реализация каждого способа и религиозные предпочтения к материалу данной заметки не относятся.
Говорить будем о подкреплении выбора «делить/не делить» цифрами.

Решая задачи реального мира нам постоянно приходится работать со списками данных. И самые счастливые в этой деятельности — Perl-программисты :)

Это все потому, что для работы с частью массива или хеша у нас есть удобный slice. Slice — это не оператор, это принцип обработки данных, когда от большого объекта отрезается кусочек.
Проще показать:

В мире Perl очень много волшебства. Оно завораживает и готовит ловушку каждому, кто начинает использовать магию по любому поводу.
Хочется предостеречь Вас от этого, особенно если Вы используете не балаганные трюка, а истинную магию.
Мой совет прост — выбирайте инструмент под задачу, верно ее оценив.
Например, не стоит использовать Moose или Mouse, если Вам всего лишь неохота каждый раз писать
my $self = bless({}, ref $invocant || $invocant);.
Вы забиваете гвозди микроскопом.
Perl феноменально удобен в отношении ОО-style программирования, вся загвоздка в том, что это неочевидно.
Все, что требуется для достижения саматхи — пару раз вдумчиво перечитать главу о typeglob.
Или воспользоваться пакетом Botox.

Накропал скрипт для поиска судьбы письма в MTA log.

Скачать можно со странички проекта.

Пожелания, добавления, исправления — в GitHub. Краткое описание — под катом.

Linux — самая «щедрая» desktop ОС в плане выбора файловых систем и их использования. Глупо не воспользоваться таким ресурсом, ведь при умелом подходе мы сможем сделать нашу систему быстрее и безопаснее.

Пару раз встречал оригинальные варианты создания объектов в любимом Perl и вздохи по поводу 6-ки, что там все проще, лучше, быстрее и т.п. Однако довольно симпатичные и совершенно безопасные конструкции можно городить и в «народной» пятерке. Используем классический вариант из учебника с замыканиями и горкой перца :)

Под впечатлением от идеи создания библиотеки для работы с search-частью произвольной ссылки решил написать функцию (в соавторстве с Kupyc, респект за учаcтие — ему принадлежит бОльшая часть), выполняющую ту-же задачу:

/**
* Функция для модификации GET-параметров uri
*
* @param {String} uri
* @param {String} paramsNew
* @param {Boolean} [isReplace]
* @version 0.2.1
*/

var uriQueryParamsModifier = function (uri, paramsNew, isReplace) {
    var paramsUri = ((paramsUri = uri.match(/\?([^#]+)/)) && paramsUri[1]); 
    if (paramsUri && isReplace) {
        return uri.replace(/\?[^#]+/, !paramsNew ? '' : '?' + paramsNew );
    }    
    if (paramsNew) {
        return uri.replace(/(#)|$/, (!paramsUri ? '?' : '&') + paramsNew + '$1');
    } 
    return uri;
}

* This source code was highlighted with Source Code Highlighter.

Авось кому сгодится.

Регулярные выражения могут оказать Вам неоценимую услугу при их разумном применении в SQL-запросах.
Они могут избавить Вас от необходимости перебирать в курсорных циклах, или (о ужас!) в циклах базового языка приложения солидные куски таблиц. Правда иногда услуга может оказаться «медвежьей».
Примеры и особености применения этой техники

Озадачился я вопросом — а что такое «шаблонизаторы» и какой в них смысл?

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

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

Что я хочу этим сказать? Да то что Smarty к примеру — не шаблонизатор, а лишь библиотека акронимов, позволяющая писать (я не знаю ни PHP ни Smarty, это лишь попытка объяснения на пальцах, не приставайте к коду)
{foreach from=$data item="entry"}
{$entry.Comment|escape}

{/foreach}

Вместо
<?php
//... а здесь мы пишем функцию, которая читает из базы и последовательно вставляет полученное нами в
$output = $output.''.$entry.''
//... и делает это наверное в цикле
?>

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

Сериализации данных не происходит, а лишь сериализация позволяет гарантировать «чистоту» данных от логики источника. Я не говорю о том, что в сериализованных данных не может содержаться какой-то код, я говорю о том, что он перестает быть исполняемым. Адресат данных должен самостоятельно решать, как именно будут восстановлены полученные им данные, в «предложении» же должны содержатся как минимум и подлежащее и сказуемое для возможности самостоятельного восстановления сути сказаного. Содержащиеся данные не «подразумевают» чего-либо еще или не умалчивают о чем-то, они ровно то, что они есть.

Ну например, если принять выражение -«Эта булка стоит 5 рублей!» за сериализованное, то варианты несереализованных выражений будут такими — «Это стоит 5 рублей! (Что?)», «Булка стоит 5 рублей (Какая?)», «Эта булка стоит 5 (Чего?)», «Эта булка — 5 рублей!(Местная валюта-хлеб?)» ну и апофеозом будет «Это стоит денег (???)» и «Смотрите прайс-лист! (wtf?!)».

Smarty позволяет разработчику сказать что-то типа "-Эта булка стоит 5 тышш рублей, потому что мы — пафосный бутик на Тверской!" и следует принимать решение на основе полученных от него данных и находясь в границах его логики. То есть начать соображать "- А, этож Тверская, тут же все дорого, значит надо баблос слюнявить как сказали".

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

Сериализация — это пачка распечатанных фотографий из последней поездки, которые Вы прихватили с собой показать бабушке в деревне. Не-сериализованные данные — когда вместо распечатанных на матовой бумаге фотокарточек 13х15 Вы везете с собой Blu-ray диск, находя очевидным, что уж где-нибудь там найдется ноут с поддержкой Blu-ray.

Отлично, мы прониклись идеей, что «сериализация» есть благо, но при чем тут 1С?

Ну, они похоже этой идеей просветлились, во всяком случае г-н Рыжиков, создавший незабвенную виршу Иллюзии XML/XSLT технологий. Я лично смутно себе представляю, сколько и чего нужно раскурить, чтобы «я сам программист», прочитавший

много книг и учебников, в которых программистов и проектировщиков учили, что лучший способ создать шаблонизатор или абстрагировать внешний вид (представление) от данных — это загнать все в XML, пропустить потом через XSLT и уже на выходе получить HTML.

наложил табу на back-end логику и

Все восприняли это буквально и начали делать подобные продукты. Ну и конечно мы тоже наслушались и уверовали, что наше будущее — это XML/XSLT технологий.
Совершили подвиг, заставив XSLT шаблоны работать достаточно быстро, вложили кучу сил, времени и денег в разработку технологии… Самые большие каталоги товаров вмещали по 70 тысяч товаров.

сделал вывод, что:

Как не стараются РАЗРАБОТЧИКИ, производительность XML/XSLT систем остается очень низкой, несмотря на все усилия индустрии. Да и как выжать эту производительность? Сначала данные из SQL базы преобразуются в XML (а это текстовый файл большого размера в силу своей структуры). Потом XML данные загружаются в XML парсер уже в серверной части, где они занимают еще больше памяти для работы XPATH, формирования индексов по XML данным в момент загрузки и т.п. Далее XSLT проходит по огромному массиву данных, получая на выходе опять же текст, который занимает память.

При этом искренне не понимал о чем идет речь, когда ему задавали вопрос — «Откуда берутся огромные объемы данных, если контента на страницу бывает кило 100 максимум???».

Действительно, как же не взяться огромным объемам, если обрабатывать xml-дамп базы XSL-шаблоном?

Безумству храбрых поем мы песню!

Не менее весело читать «независимых разработчиков», которые согласны с мэтром — «XSLT — тормоза и отстой!».

Нет, ну вообразите себе — это ровно (в смысле абсолютно эквивалентно) как наткнутся в ЖЖ на топик

-Сегодня взялся за голые провода, стоя в мокрой ванне. Нехило меня током долбануло, 3 часа в себя приходил!

с толпой комментов:

— И я сегодня взялся за провода! И меня долбануло!

-+1, ванны отстой! Резиновые коврики рулят!

— Резина — отстой, лучше пластик!

— Сам ты отстой, и пластик твой — фуфел!

— Ответил за базар, что пластик — фуфел?

— Ха, да у меня друг — директор шинного завода, они там только резину и юзают, а не какой-то говнопластик. Не надо же тебе объяснять, как это круто — делать шины! Это не какой-то там свечной заводик в Урюпинске, это же production!

— А меня так каждый раз током долбит, когда я за провода берусь, достало!

— Да ты лошара, вот меня один раз долбануло в ванне от проводов, так я нахрен их вырубил в щитке в подвале! Чтоб ни меня, не мою семью, ни соседей не било! Надо же и об окружающих думать!

Клиника, одним словом :)

Пожалуйста, не делайте так!

Шаблон должен делать ровно то, что он делает — взять с полки и укомплектовать товар аксессуарами, в зависимости от того — OEM это или Retail. Если Retail — то и диск положи, и шлейфы и мануалы на всех языках, и брелок. А если OEM — чихни в пакет для комплекта к самой железяке. При этом комплектовщик работает с конкретной железкой и каким-то конечным объемом аксессуаров, подходящих к этому устройству. Он не пытается запихнуть в коробку с видеокартой блок питания, потому что у нее есть дополнительный разъем — блок питания не входит в комплект по его ТИ, или вместо видюхи положить бутылку коньяка, метнувшись за ним в магазин, потому что это для «самого». И уж тем более ему не говорят — «Вот видюха, вот склад комплектов — выбери чего-нить и сунь туда, ты же головастый малый!»

Разделение логики означает ее, логики, разделение — не более и не менее!
(если Вас передернуло от такой формулировки — просто проигнорируйте, а если какая-то смутная догадка мелькнула в мозгу — перечитывайте до просветления)

У вас все еще есть база SQL с хреновой тучей записей (как и положено приличной SQL-базе); back-end который ходит в базу и получает от нее полтора десятка записей (в соответствии с запросом пользователя и логикой постраничного отображения, предписывающего отображать 15 записей, причем в названии не должно быть слова «Жопа» если в графе «Возраст» у юзера стоит «до 18») на выходе заворачивающий результаты своей работы в XML; front-end получающий коротенький XML и накладывающий на него свою таблицу стилей ака XLST в результате чего получается новый XML-файл, в котором первоначальный узел <bullshit>Костюм и галстук — $5000</bullshit> меняется на <Haute couture>Костюм и галстук — $5000</Haute couture>.

А где же HTML? Да здесь он, родимый, просто в другом шаблоне — toHTML, для узла <bullshit> задано другое правило, трансформирующего его в <span class=«amazing» >, которое отдается клиенту тем же front-end-ом, если пользователь не умеет читать XML. Да, суть front-end-а именно в том, чтобы говорить с клиентом на одном языке, при этом ему пофигу о чем ведется речь — про шмотки или бухло. Он и о том и о том может, если суфлер-back-end подскажет, что вставлять после «Это очень крутая штука, наша»…

Короче, если Вы смогли это дочитать и все еще пытаетесь реализовать back-end как XLST-преобразование XML-дампа базы данных — прямая дорога вам в 1С, делать «Битрикс-ы» под руководством г-на Рыжикова. Или нет, не возьмут Вас за слова XML и XSLT, они же уже «накололись» на этом и больше так не «лохонутся». Ну, тогда перечитайте еще разок этот опус или попробуйте написать гневный отклик на него, думая над каждой своей фразой.

UP. Disclaimer — сложность текста, его сумбурность, оторванность примеров от предмета и тэдэ — результат крайне поверхностных знаний автора в обсуждаемом предмете. На данный момент вся моя профессиональная подготовка по XLST состоит в прочтении первого предложения XLST — стандарта, гласящего:

This specification defines the syntax and semantics of XSLT, which is a language for transforming XML documents into other XML documents.

Еще вопросы?