Node.JS *

Статья написана для ювелиров, которым в силу роста популярности бижутерии пришлось оставить свою работу и заняться другим делом немного смежным с их предыдущим.

Небольшой рассказ о начальном погружении в Node.js и опыте работы с Rails-like фреймворком Sails.js

Эта статья не претендует на внимание искушенных разработчиков, поскольку является лишь описанием некоторых впечатлений начинающего Rails-разработчика о Node.js. Надеюсь, кому-нибудь будет полезно.

Node.js vs Ruby on Rails

В отличие от большинства разработчиков, я начинал с баловства с Node.js, и уже после погрузился в Ruby on Rails с помощью восхитительного курса Rails for Zombies и, затем, учебника по Ruby on Rails от Michael Hartl.
Все, что написано далее, есть ненаучное сравнение Node.js и Ruby on Rails.

Это Norton Commander? Это Volkov Commander? Это Dos Navigator? Это Far Manager?
Нет, это «Деодар» — новая рабочая среда для Линукс.
Деодар хостится на GitHub, основан на Node.js, написан на JavaScript плюс немного C++.
Распространяется по антилицензии Unlicense.org. Безвозмездно, то есть даром.
В данной статье на большом количестве картинок и малом количестве пояснений вы можете ознакомится с тем, что уже есть.
Да, «Деодар» — это такое дерево, Cedrus Deodara растёт высоко в горах, очень красивое.

Когда я только-только начал играться с Node.js, для меня существовала лишь одна вещь, которая доставляла мне дискомфорт. Занятно, но я говорю сейчас о module.exports. Говоря занятно, я намекаю на то, что это, всё-таки, одна из фундаментальных частей Node.js и она достаточно проста. Сейчас же, оглядываясь назад, я не могу объяснить почему меня это так стопорило… Просто помню, что этот момент был для меня не очевиден. Ну и, полагаю, что я один из тех многих, кто встретив его разок-другой, сначала только путался, прежде чем написал что-либо применив его.

В Node, все штуки видны друг другу только в рамках одного и того же файла. Под штуками я подразумеваю переменные, функции, классы и их члены. Например у нас есть файл misc.js следующего содержания:

var x = 5;
var addX = function(value) {
  return value + x;
};

Привычный доступ к переменной x и функции addX из другого файла невозможен. Это никак не связано с использованием var. Дело в том, что Node состоит из блоков называемых модулями, и каждый отдельный файл по своей сути — отдельный блок, чья область видимости изолирована от других таких же блоков.

В комментариях к посту про Underscore/Lo-Dash я упомянул, что среди библиотек, расширяющих стандартную библиотеку JavaScript, я предпочитаю SugarJS, который, в отличие от большинства аналогов, работает через расширение нативных объектов.

Это вызвало горячую дискуссию о том, допустимо ли расширять нативные объекты. Меня очень удивило, что практически все высказавшиеся выступили против.

Это побудило меня перевести манифест SugarJS по этому вопросу. По всей видимости, автору этой библиотеки приходилось очень часто слышать подобные нападки. Поэтому он очень взвешенно и достаточно непредвзято прокомментировал каждую из них.

В этом материале разбираются подводные камни JavaScript, известные и не очень, а также предлагаются методы защиты. Поэтому я думаю, что статья будет интересна и полезна любому JS-разработчику, независимо от его отношения к проблеме расширения нативных объектов.

Передаю слово Andrew Plummer.

---

Итак, Sugar — библиотека, которая модифицирует нативные объекты JavaScript. Подождите, разве это не во зло? — спросите вы, — вы что, не извлекли урок из горького опыта Prototype?

По этому поводу существует много заблуждений. Sugar избегает подводные камни, о которые спотыкался Prototype, и фундаментально отличается по своей сути. Однако этот выбор — не без последствий. Ниже разобраны потенциальные проблемы, вызываемые изменением нативных объектов, и изложена позиция Sugar насчет каждой из них:

1. Модификация объектов среды
2. Функции как перечисляемые свойства
3. Переопределение свойств
4. Конфликты в глобальном пространстве имен
5. Допущения насчет отсутствия свойств
6. Соответствие спецификации

MIT опубликовал исходники проекта Mylar — платформы для создания безопасных приложений, с шифрованием и
поиском по зашифрованным данным.

Broccoli является новой системой автоматической сборки. Её вполне можно сравнить с Rails asset pipeline, однако есть и некоторые различия: он запускается на Node.JS и не зависит от серверной части приложения.

После длинной вереницы 0.0.х альфа релизов, я только что выпустила первую бета версию, Broccoli 0.1.0.

Оглавление:

1. Быстрый пример
2. Мотивация / Особенности
3. Архитектура
4. За кулисами / Общий взгляд
5. Сравнение с другими системами сборки
6. Что дальше?

Недавно появился проект pako, это порт на яваскрипт известной библиотеки для компрессии и декомпрессии данных — zlib.

Очень любопытен результат тестов.

Я стал замечать, что в последнее время build-системам стали уделять всё больше внимания, и, под влиянием этого, их в одночасье стало настолько много, что, честно говоря, уже всех и не упомнить. Последнее время у меня на слуху четыре системы: Grunt, Gulp, Brunch и Gear. Про все что-то где-то было написано, но ни разу не ставился вопрос о том, какие преимущества или недостатки они имеют друг перед другом? И именно поэтому я решил провести сравнительный анализ самых популярных build-систем(по версии google).

Но сперва надо определиться с критериями, по которым мы будем оценивать эти системы:

• Начало работы.
• Производительность. Никто не хочет ждать по минуте после изменения одного coffee-файла.
• Документация. Чем нагляднее и проще — тем лучше.
• Плагины. Ведь мы не хотим столкнуться с проблемой, когда мы начали использовать билд-систему, а в ней нет адаптера, скажем, для jasmine?

Теперь, я полагаю, с вводной частью можно покончить и приступить, наконец, к сравнению.

Добрый день!
Решил поделиться опытом перехода с Middleman (Ruby) на Express.js (Node.js) в качестве инструмента front-end разработчика.
Сам я занимаюсь back-end, так что статья может выйти не слишком актуальной, но, надеюсь, полезной хотя бы кому-нибудь.

Итак, задача: сделать приложение на Node.js с поддержкой компиляции Sass(Compass), CoffeeScript и Haml «на лету» при редактировании соответствующих файлов. Для этого будем использовать Express и Grunt для запуска веб-сервера и выполнения задач компиляции соответственно.

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

Введение

Если Grunt — новое для вас слово, то вы можете сначала ознакомиться со статьей Криса Койерса «Grunt для людей, кто думает, что такие вещи как Grunt уродливы и тяжелы». После введения от Криса, у вас будет свой собственный Grunt проект и вы уже попробуете на вкус все возможности, которые Grunt нам предоставляет.

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

• Как сохранить ваш Gruntfile аккуратным и опрятным
• Как сильно улучшить время вашей сборки
• Как быть постоянно в курсе состояния сборки

По причине «интересно», на досуге, собрал простой upnp/dlna сервер. Написанных на javascript найти не удалось, а идея кажется интересной: один исходный код для всех платформ (спасибо node-webkit), javascript со всеми его достоинствами и недостатками, а также простота сборки. Можно легко собрать проект под все платформы в одной из них. Для этого написал скрипт на питоне, который все сделает сам, даже скачает необходимые файлы node-webkit. Хотелось снизить кол-во телодвижений необходимых для тех, кто захочет внести свою лепту в проект.

Скачать можно здесь, спасибо github за то, что вернули возможность хранить файлы. Умеют сделать людям хорошо. Еще немного текста можно найти под катом.

На прошлой неделе мы отметили одну круглую дату — в базе данных Likeastore скопилось, ни много, ни мало — один миллион пользовательских «лайков».

Мы используем JavaScript, все текущие сервисы написаны на JavaScript/Node.js. В общем и целом, я не жалею о использовании Node.js в нашем проекте, он отлично зарекомендовал себя как лучшее средство реализации HTTP API. Но для сбора «лайков», это должен быть daemon, который работает постоянно. Наверно, не самая типичная задача для Node.js — про специфику реализации и некоторые подводные камни, читаем далее.

Доброго времени суток, хабрасообщество! В этой статье я хочу описать опыт создания генератора для scaffolding системы Yeoman. Прежде всего, я был немного удивлён тем, что данная система и работа с ней не были описаны на хабре, разве что одно маленькое упоминание из далекого 2012 года: Yeoman.io. Как я уже написал выше, в данной статье я буду рассматривать поэтапное создание yeoman-генератора для ваших проектов.

История

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

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

И наконец, в один прекрасный день вы решили: “Сделаем это!”. И вот вы уже пытаетесь разобраться как реализовать бизнес-логику своего приложения, ту киллер-фичу, которая будет двигать продукт вперед. У вас есть идея как это сделать, и вы знаете, что способны на это. И вот вы говорите: “Готово! Работает!” У вас есть успешный прототип! Осталось только упаковать его в веб приложение.

“Окей, сделаем сайт,” говорите вы.

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

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

“Я перегружен”, говорите вы и чувствуете себя перегруженным. Энергия уже не та, что была в начале. Вы пытаетесь собраться с мыслями, но работы слишком много. Прототип медленно блекнет и умирает.

Некоторое время назад я, в поисках новых инструментов для реализации очередного «домашнего» проекта, наткнулся на Kraken.js — Open Source проект от PayPal. Kraken.js представляет из себя очередной Node.js-фреймворк, основанный на express. Поискав на Хабре, я не обнаружил, ровным счетом, ничего. Встретил только одно упоминание в виде ссылки на главный сайт здесь.

Чем же он меня привлек, и чем он отличается от известных Derby.js, Meteor.js, Sails.js, и др.?

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

Итак, задача залить Kraken.js-приложение на сервис Heroku, заставить его там работать, и, на сладкое, прикрутить Sockjs.

Заморочился я автообновлением странички в браузере на таскаемом с собой iPad при разработке NodeJS/ExpressJS-приложений, чтобы видеть все изменения на лету.
Под катом — как очень просто сделать из мобильного гаджета средство живого просмотра разрабатываемых веб-приложений.

Раньше основной библиотекой для парсинга был JSDOM, который страдал излишней тяжеловесностью и на самом деле тормозил скорее процесс парсинга. Но время изменились и пришел cheerio. Он делает почти все то же самое, и отбрасывает лишние из процесса, при этом сам реализует какую-то часть jQuery(а именно ту, которая нам нужна для парсинга). И за счет этого позволяет наконец написать не тормозящий парсер, при этом не используя regexp'ы ради увеличения производительности. Он справляется и с xml, только нужно вызвать его с {xmlMode: true}. О том как можно легко парсить на nodeJS под катом.