Рысцов Денис shai_xylyd

Статья устарела, актуальную информацию ищите на сайте Warp9'а



Существует множество реактивных и около-реактивных библиотек для создания графического интерфейса на js: Angular, Knockout, React, RxJS… Спрашивается, зачем писать еще одну. Оказывается, во всех них, помимо фатального недостатка, есть еще несколько.

В последнее время я стал много писать на JS, сейчас работаю над сложным приложением и довольно крупной библиотекой (~5K SLoC). Конечно же, я столкнулся с проблемой модульности.

Для приложения идеально подошел AMD — указываешь в зависимостях библиотеки, добавляешь связующий код, логику… и приложение готово. Но при разработке библиотеки я столкнулся с проблемой управления внутренними зависимостями при помощи AMD или CommonJS — получается слишком много обвязок (boilerplate), особенно когда части библиотеки взаимозависимы. Поэтому я выделил еще один подход к определению модулей в JS — YAMD.

Внимание! Это не замена AMD или CommonJS, для сборки приложения я по прежнему использую AMD, просто одна из библиотек, которую я подключаю, собрана с помощью YAMD. Таким образом, YAMD является подходом к декомпозиции сложной библиотеки без внешних зависимостей на части и отдельные файлы, и инструментом для сборки этих файлов воедино.

В статье я опишу подход. От вас хочется узнать в комментариях, что вы используете для тех же задач.

MongoDB — замечательная база данных, которая становится все популярнее в последнее время. Все больше людей с SQL опытом начинают её использовать, и один и первых вопросов, который у них возникает: MongoDB transactions?.

Если поверить ответам со stackoverflow, то все плохо.

MongoDB doesn't support complex multi-document transactions. If that is something you absolutely need it probably isn't a great fit for you.

If transactions are required, perhaps NoSQL is not for you. Time to go back to ACID relational databases.

MongoDB does a lot of things well, but transactions is not one of those things.

Но мы не поверим и реализуем транзакции (ACID*) основанные на MVCC. Ниже будет рассказ о том, как эти транзакции работают, а тем, кому не терпится посмотреть код — добро пожаловать на GitHub (осторожно, java).

Пост не о MongoDB, а о том, как использовать compare-and-set для создания транзакций, а durability обеспчивается ровно в той степени, в которой её обеспечивает хранилище.

disclaimer Так получилось, что последний месяц я разбираюсь с ZooKeeper, и у меня возникло желание систематизировать то, что я узнал, собственно пост об этом, а не о сервисе блокировок, как можно было подумать исходя из названия. Поехали!

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

От распределенного сервиса блокировок разумно требовать:

1. работоспособность в условиях моргания сети (первое правило распределенных систем — никому не говорить о распределенных системах сеть ненадежна)
2. отсутствие единой точки отказа

Создать подобный сервис нам поможет ZooKeeper

В википедии написано, что ZooKeeper — распределенный сервис конфигурирования и синхронизации, не знаю как вам, но мне данное определение мало что раскрывает. Оглядываясь на свой опыт, могу дать альтернативное определение ZooKeeper, это распределенное key/value хранилище со следующими свойствами:

• пространство ключей образует дерево (иерархию подобную файловой системе)
• значения могут содержаться в любом узле иерархии, а не только в листьях (как если бы файлы одновременно были бы и каталогами), узел иерархии называется znode
• между клиентом и сервером двунаправленная связь, следовательно, клиент может подписываться как изменение конкретного значения или части иерархии
• возможно создать временную пару ключ/значение, которая существует, пока клиент её создавший подключен к кластеру
• все данные должны помещаться в память
• устойчивость к смерти некритического кол-ва узлов кластера

Riak это NoSQL решение, честная DHT (key/value storage) с дополнительными возможностями для разруливания конфликтов.

У распределенной хеш таблицы есть как плюсы, так и минусы. DHT хорошо масштабируется, но возможны потери данных из-за конфликтов конкурентного доступа, рассмотрим следующий пример:

client a: def o-value = DHT.get("some-key");
client a: def a-value = changeValue(o-value);
client b: def o-value = DHT.get("some-key");
client a: DHT.put("some-key", a-value);
client b: def b-value = changeValue(o-value);
client b: DHT.put("some-key", b-value);

Получилось, что клиент b переписал данные клиента a и никто об этом не знает (ни a, ни b, ни тот, кто прочтет данные по этому ключу позже).

Так как многие NoSQL базы данных в своей основе имеют DHT, интересно смотреть как они пытаются решить проблему конкурентного доступа.

Например, MongoDB использует compare-and-swap стратегию: с каждым документом (значением) храниться его версия, при обновлении указывается версия «предка» измененного документа, если в базе в момент обновления храниться предок, то обновление проходит, если нет, то нет: обновляющая сторона получает сообщение, и пытается провести обновление снова — аналог STM. Такой подход хорошо работает с шардами, но плохо с репликацией.

Riak решает проблему конкурентного доступа подобно системам контроля версий, он, как бы, сохраняет конфликтные версии в разных бранчах, предоставляя программе при следующей выборке провести merge. Такой подход позволяет разрешать конфликты, связанные не только с конкурентным доступом, но и с времянной изолированостью части кластера (partition tolerance: кластер машин может распаться на две части, обе части будут работать и смогут без проблем объединиться в будущем).

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

 

В предыдущих заметках (часть I, часть II) об async/await в C# 5 я написал, что подобный подход реализован в таких языках, как Haskell, F# и Nemerle, но, в отличие от C#, эти языки поддерживают концепцию более высокого уровня, которая позволяет реализовать асинхронные вычисления в стиле async/await в виде библиотеки, а не на уровне языка. Забавно, что в Nemerle сама эта концепция реализована в виде библиотеки. Имя этой концепции — монада. Помимо асинхронных вычислений монады позволяют реализовать другие вкусности, такие как list comprehension, continuation, превращение грязных функций в чистый блок, через который неявно протаскивается состояние, и множество других.

Некоторые монады реализуют такие «хотелки» C# программистов, как yield коллекции или yield foreach и yield из лямбда выражения.

Цель этой заметки — введение в асинхронное программирование и computation expressions в Nemerle, но она так же может быть полезна тем, кто изучает F#, так так реализация асинхронного программирования в Nemerle была сделана с оглядкой на него в F#. С другой стороны, кому-нибудь может быть интересно, как некоторые задачи, которые являются проблемой в других языках (После всех асинхронных вызовов), решаются с помощью computation expressions в пару строк.

Продолжение: часть III.

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

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

Продолжение по ссылкам: часть II и часть III.

На PDC2010 Хейсберг объявил, что следующая версия C# будет поддерживать примитивы для удобной организации асинхронных вычислений, кроме анонса была представлена CTP версия расширения для студии (скачать), которая позволяет попробовать улучшенное асинхронное программирование уже сейчас.

Улучшение создано, чтобы облегчить комбинацию асинхронных операций, а так же для того, чтобы асинхронных код выглядел максимально приближенно к синхронному. Учитывая, что Silverlight версия .NET Framework содержит только асинхронную модель для работы с сетью, данное улучшение очень уместно.

Не смотря на то, что упрошенное асинхронное программирование является нововведением в C#, сам подход нельзя назвать инновационным, так как реализация async на основе монад есть в Haskell, F# и Nemerle. На самом деле поддержка языком монад позволяет реализовать даже большее, поэтому я был немного удивлен, когда посмотрел презентацию Хейсберга и понял, что в язык был встроен только частный случай.

..it is true that asking regexes to parse arbitrary HTML is like asking Paris Hilton to write an operating system..

Последние версии языка Nemerle включают в состав библиотеку для разбора языков, грамматика которых принадлежит классу PEG.

Что такое PEG?

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

Класс языков, которые можно разобрать с помощью парсеров описанных подобным образом, достаточно широк, чтобы покрыть популярные языки программирования (например, C#) и языки разметки. Очевидно, что он покрывает всю функциональность регулярных выражений.

Представьте себе Maple, Maxima или Mathematica, в которой правила работы являются энциклопедическими статьями, и, наоборот, энциклопедию, пополняя которую, вы улучшаете работу системы компьютерной алгебры. Эта идея лежит в основе Galois/Wiki (Галуа/Вики) — математической энциклопедии с интеллектуальным поиском.

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

Король созвал 100 своих мудрецов вечером и объявил, что утром он им устроит испытание. Если они его пройдут, то он обеспечит золотом их на все оставшуюся жизнь, если нет, то он их всех казнит. Король рассказал мудрецам в чем будет испытание: он наденет на каждого мудреца шляпу, которая может быть одного из 100 цветов, каждый мудрец не видит, какого цвета шляпа на нем, но он видит каких цветов шляпы на его товарищах. Мудрецам запрещено будет общаться. По команде они должны будут одновременно сказать, как они думают, какая шляпа на них, и если хоть один угадает, то испытание считается пройденным. У них есть ночь перед испытанием чтобы придумать стратегию. Представьте себя на месте мудрецов, и попытайтесь придумать правильную стратегию

Пояснение: у каждого мудреца шляпа может быть одного цвета, так же возможна ситуация, когда цвета шляп на некоторых мудрецах совпадают, кроме того, король может на всех мудрецов одеть шляпы одного цвета. Известно только, что цветов для шляп всего 100 и они известны.

Почти полгода назад я написал на хабре статью о проекте математической поисковой системы uniquation.ru. Тогда была получена конструктивная критика, которая помогла улучшить проект.

С тех пор проект претерпел множество изменений, главное из которых — визуальный ввод формул — теперь, чтобы найти информацию о каком либо математическом объекте, необязательно знать его представление в формате TeX.

На хабре часто возникают топики, в которых студенты CS специальностей просят помочь им с выбором тем курсовых и дипломных работ. Это не удивительно, так как обычно темы, которые предлагают научные руководители интересны только им самим, и получается ситуация, когда студент выполняет работу, но не видит в ней смысл. Мне кажется, что это очень ужасно, когда человек не заинтересован в своей работе.

Было бы намного лучше, если бы студент понимал, что он делает нужную вещь, за которую много людей будут ему благодарны. Один из способов достичь этого — участие в популярных open source проектах, связанных с его специальностью. Хорошими кандидатами являются проекты по созданию компиляторов/интерпретаторов языков программирования, так как это наукоемкие проекты (алгоритмы вывода типов, PEG, монады, теория типов...) и объективно полезные проекты (если язык достаточно популярен).

Как можно уже было догадаться, я предлагаю поучаствовать в разработке языка Nemerle. Это достаточно уникальный проект, так как он стоит в одним ряду с таким языком как scala, он поддерживается людьми из России, и он еще не такой популярный, что бы избегать всеми силами ломающих изменений.

Mы только что открыли α-тестирование проекта Uniquation. Это математическая поисковая система, которая ищет решения среди уравнений, равенств и прочих математических объектов, размещенных в интернете. На текущем этапе развития её можно мыслить как развивающуюся CAS (wiki). Помимо этого поста про неё можно прочитать в нашей презентации.

Влад Чистяков, один из активных разработчиков языка Nemerle, начал цикл статей о нем. В отличии от существующих статей, которые ориентированы на опытных программистов, этот цикл подходит как для начинающих программистов, так и для опытных, но не знакомых с платформой .NET.

Введение от автора:

На данную работу меня вдохновила книга Кернигана и Ричи – «Язык С». Много лет назад я учился программировать по этой книге. Мне очень понравилась концепция изложения использованная в этой книге. В этой книге, вместо того чтобы взять одну тему и разобрать ее по косточкам, попутно заостряя внимание на мелких деталях, давался минимум, необходимый человеку, чтобы начать программировать на «C», а затем приоткрывался аспект за аспектом. Причем изложение давалось не на абстрактных примерах, которыми так увлекаются проповедники функционального программирования, а на примерах простых, но все же из этой жизни. Понимая, что прыгнуть выше Кернигана и Ричи очень тяжело, я решил не соревноваться с ними в креативности, а просто повторить их методологию, но с расчетом на Nemerle.

Язык Nemerle

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

Метапрограммирование — общее название класса средств автоматизации труда программиста. Под ним понимают и кодогенерацию, и макросы препроцессора в C, и шаблоны C++, и макросы LISP, и создание своих DSL, а так же использование динамических языков с генерацией кода на лету. Nemerle поддерживает еще один вариант метапрограммирования.

Недавно обнаружил замечательную статью Monadic Parser Combinator про создание парсеров. Основная идея заключена в том, что бы описать парсер как объект первого класса, что бы можно было произвести декомпозицию исходной задачи и представить искомый парсер в виде синтеза более простых парсеров. Что бы облегчить комбинацию парсеров используется подход replace error with list of success. В языке haskell очень удобно работать с созданием парсеров, так как эта задача естественно ложится на концепцию монад, к сожалению в nemerle монады не поддерживаются, но все же язык достаточно мощный, что бы справиться с данной задачей.

Скоро (подача заявок до 15 февраля, а первый тур в марте) пройдет очередной конкурс Imagine Cup, проводимый Microsoft. О том, как проходил конкурс в прошлом году, можно прочитать в этой статье, а информацию о конкурсе найти тут.

Мой хороший друг, победитель Imagine Cup по России, Никитин Анатолий сказал, что у проекта, которым я занимаюсь (специализированной поисковой системы), есть шанс победить, поэтому я решил испытать счастье и параллельно освещать ход конкурса на хабре в личном блоге, надеюсь тема интересная и серия заметок не загнется в самом начале по причине вылета из конкурса в первом туре=).