В этом посте я хочу обобщить и поделится полученным опытом при разработке библиотеки node-queue-lib. Я расскажу о технологиях, которые помогли мне довести дело до финального конца — работоспособного кода, который уже работает на одном из моих сервисов. Особенностью данной библиотеки является кросс-платформенный клиент, т.е. клиент работающий в node.js и браузере и основан на одном и том же коде. В посте будут описаны следующие инструменты, без которых разработка этой библиотеки превратилась бы в ад:

• Тестирование (jasmine_node)
• Покрытие кода тестами (istanbul)
• Сборка клиенткой части библиотеки (browserify)
• Автоматизированное тестирование клиента (phantomjs)
• Поиск утечек памяти (memwatch)

Если Вы об этом ещё ничего не слышали и имеете желание написать законченный продукт в надёжности которого Вы будете уверены, эта обзорная статья поможет Вам познакомится с одним из вариантов комплекта инструментов для полноценного контроля качества кода javascript библиотеки.

И дополнительно, повторю, что статья обзорная, и не ставит целью научить Вас виртуозно пользоваться всеми перечисленными инструментами. Я лишь покажу дверь, но откроете Вы её сами…

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

С ростом популярности node.js он становится всё более привлекательным для разработки приложений. По крайней мере я в последнее время очень часто использую эту технологию для быстрой разработки оных. И на данный момент, технологически нет никаких препятствий для разработки кроссплатформенных приложений на одном языке. И не только классических Web-приложений (клиент-сервер) но и десктопных.

AngularJs – великолепный фреймворк для разработки web-приложений. Разработка бизнес-логики приложения полностью отделена от сопутствующей суеты вокруг DOM. Angular модульный – это замечательно, но так же является источником проблемы. Количество модулей быстро растёт. И если директивы ещё можно упаковывать в отдельные пакеты типа angular-ui, то с контроллёрами бизнес-логики всё сложнее. Всё становится ещё хуже, когда требования безопасности в принципе запрещают загрузку на клиента контроллёров с бизнес-логикой, которые недоступны текущему пользователю. При развитой ролевой системе доступа к приложению масштаб проблемы становится очевиден.

Имея в хозяйстве замечательный накопитель от компании Synology, я довольно долгое время грустил по поводу того, что в нём отсутствует хостинг .NET приложений. И вот, вооружившись мат. частью приведённой в статье habrahabr.ru/post/121159 я озадачился созданием домашнего сервера для проектов на ASP.NET MVC. Пакет mono там довольно старый, а классическая последовательность команд для сборки оного не привела к успеху. Информация собиралась из различных источников, в том числе и с хабра, по крупицам давая понимание, что и в какой последовательности необходимо делать. Прохождение этого квеста я как раз и хочу описать в этой статье. Надеюсь кому-то пригодится.

Довольно часто перед разработчиком встаёт вопрос о расширении основного алгоритма однотипными задачами. Например, агрегаторы различных сервисов, которые предоставляют единый интерфейс пользователю, делая запросы сотне-другой поставщиков услуг. Задача стоит таким образом, чтобы основное ядро могло динамически загружать сборки с различными реализациями некоторого интерфейса. Никакой непосильной работы для программиста .NET здесь изначально не предвидится. Если термин «отражение» Вам известен, Вы вероятно уже хотите пройти мимо? Но в этом топике речь пойдёт не про отражение как таковое… я расскажу как это сделать наиболее «чисто». Т.е. с одним нюансом — исследуемые сборки нужно выгрузить после их эксплуатации.