Проектируя архитектуру сервиса вы выбираете инструменты, наиболее подходящие для решаемых вами задач. Но чтобы использовать их по максимуму, необходимо найти самый надёжный и удобный драйвер. Конечно, если вы программируете на Python или, к примеру, PHP, найти нужный драйвер не проблема, ведь за много лет разработчики понаписали всякого, что проверено годами и стабильно работает. Но если вы программируете для node.js — это становится проблемой, драйверы скрипят, утекают и отказываются стабильно работать.
В данной статье мы расскажем о проблемах, с которыми столкнулись при выборе драйверов, и как их решили.

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

В рабочих проектах это может сводиться к чему-то вроде

function pageChange(){
    if ($(‘.element-carousel').length>0) {$('.element-carousel').initCarousel()}
    if ($('.element-scrollbox').length>0) {$('.element-scrollbox').initScrollbox()}
…

А может и не сводиться, и в каждом условном контроллере (колбэке на смену определенной страницы) мы вызываем код, связанный с определенными элементами.

Знакомо? Думаю, да. Считаете ли вы этот подход неправильным? Если первый ответ – да, то уверен, что и второй тоже да.

Хотите узнать, как можно сделать правильно, аккуратно и красиво?

Open Source решение для полноценной поисковой индексации ваших JavaScript приложений (Backbone, Angular, Ember, ChaplinJS, Marionette). Работает это следующим образом:

1. Мидлвар на Ruby on Rails или Node.js проверяет user agent при каждом запросе к приложению
2. Если обнаружен краулер поисковой машины то отправляется GET запрос к Prerender
3. Prerender вызывает ваше приложение для той страницы, которую запрашивает краулер
4. Страница рендерится с помощью PhantomJS
5. Полученный HTML посылается обратно
6. Мидлвар возвращает HTML краулеру

От переводчика: Это четвёртая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Эта статья о том, как увеличить скорость загрузки ресурсов сайта и модуле connect-cachify, созданном в Mozilla для этой цели.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

В этой статье мы поговорим о производительности фронтэнда и представим инструменты, созданные в Mozilla для того, чтобы сделать сайт Persona настолько быстрым, насколько возможно. Мы опишем работу с connect-cachify — модулем, автоматизирующим некоторые из важнейших аспектов, обеспечивающих производительность фронтэнда.

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

От переводчика: Это первая статья из цикла о Node.js от команды Mozilla Identity, которая занимается проектом Persona. Как клиентская, так и серверная часть Persona написаны на JavaScript. В ходе работы команда проекта создала несколько инструментов на все случаи жизни — от локализации до отладки, управления зависимостями и многого другого. В этой серии статей разработчики Mozilla делятся с сообществом своим опытом и этими инструментами, которые пригодятся любому, кто пишет высоконагруженный сервис на Node.js.

Первая статья цикла посвящена распространённой проблеме Node.js — утечкам памяти, особенностям утечек в высоконагруженных проектах и библиотеке node-memwatch, которая помогает найти и устранить такие утечки в Node.

Все статьи цикла:

1. "Охотимся за утечками памяти в Node.js"
2. "Нагружаем Node под завязку"
3. "Храним сессии на клиенте, чтобы упростить масштабирование приложения"
4. "Производительность фронтэнда. Часть 1 — конкатенация, компрессия, кэширование"
5. "Пишем сервер, который не падает под нагрузкой"
6. "Производительность фронтэнда. Часть 2 — кешируем динамический контент с помощью etagify"
7. "Приручаем конфигурации веб-приложений с помощью node-convict"
8. "Производительность фронтенда. Часть 3 — оптимизация шрифтов"
9. "Локализация приложений Node.js. Часть 1"
10. "Локализация приложений Node.js. Часть 2: инструментарий и процесс"
11. "Локализация приложений Node.js. Часть 3: локализация в действии"
12. "Awsbox — PaaS-инфраструктура для развёртывания приложений Node.js в облаке Amazon"

---

Зачем заморачиваться?

Вы можете спросить, зачем вообще отслеживать утечки памяти? Неужели нет более важных дел? Почему бы просто не перезапускать процесс время от времени, или просто добавить памяти на сервер? Есть три причины, по которым устранять утечки всё-таки важно:

1. Возможно, вы не сильно переживаете об утечках памяти, но этого нельзя сказать о V8 (движок JavaScript на котором работает Node). Чем больше памяти занято, тем активнее работает сборщик мусора, замедляя ваше приложение. Так что в Node утечки напрямую вредят производительности.
2. Утечки могут привести к другим проблемам. Протекающий код может блокировать ограниченные ресурсы. У вас могут закончиться файловые дескрипторы или вы вдруг не сможете открыть ещё одно соединение с БД. Такие проблемы могут возникнуть задолго до того, как кончится память, но обрушат ваше приложение ничуть не хуже.
3. Рано или поздно ваше приложение упадёт. И это наверняка случится во время наплыва посетителей. Вас все засмеют и будут писать про вас гадости на Hacker News.

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



Мы в Яндекс.Почте, сложном и массовом проекте, накопили заметный опыт в поиске и устранении таких утечек, и хотим им поделиться.

Доброго времени суток, уважаемые хабражители. Хочу поделиться с вами одной замечательной находкой на GitHub — SVG.js — удобная манипуляция и анимация SVG. Хочется сказать о трех вещах, которые сосредоточили мое внимание на этой библиотеке. Самое простое и важное это то, что с появлением retina дисплеев SVG становится популярнее, более нужным, чем раньше. SVG.min.js весит 34кб и 9кб в Gzip, что в разы меньше Raphaël и что можно пожертвовать для дизайна и эффектов. Минифицированный SVG.filter.js размером в 3кб является прекрасным кроссбраузерным аналогом для свойства webkit-filter.

Для всех, кому прохладного дождя за окном в эти дни мало, Marek Brodziak сделал забавное демо на js + canvas (демо #1, демо #2 — и сразу предупреждаю, что заработать может не во всех браузерах), которое имитирует капли дождя на стекле. Своей целью разработчик ставил добиться лучшей плавности анимации капель.

Для достижения наилучшего эффекта погружения смотреть демо рекомендуется предварительно открыв в соседней вкладке raining.fm.

Введение

В один прекрасный день я получил по почте извещение о долге за горячую воду, по причине несвоевременного оповещения коммунальных служб о показаниях водомеров. К этому моменту я, праздного любопытства ради, осваивал WiFi радиомодуль от “Roving Networks” с целью «обучить» его дистанционно включать/отключать электрический водонагреватель для экономии электроэнергии при долгом отсутствии пользователей. И так все сошлось, что решил я свести эти задачи и еще некоторые задумки «умного дома» к практической реализации. Ну и конечно, было бы не интересно, если бы я использовал знакомые мне технологии, поэтому я решил использовать как можно больше нового и интересного.

Наверняка вы слышали о сервисах Amazon EC2, Rackspace и им подобным. Может быть даже пользовались. Лично мне бывает нужен иногда личный VPN-сервер. Для этих целей я уже давно держал микро-инстанс на Амазоне, предоставляемый им в течении первого года бесплатно. Плюс использовал для архивов Amazon Glacier, который с его ценой «1 цент за гигабайт в месяц» можно считать тоже почти бесплатным. Но вот год закончился и за EC2 стало нужно платить. Архивы мои тоже разрослись прилично и затраты на Glacier аналогично перестали радовать.

Случайно пробежавший мимо обзор сервиса DigitalOcean по-началу оставил меня равнодушным. Ну, облачный сервис, ну виртуалки. Ну да, чуть-чуть дешевле (но не так чтобы уж очень), чего-то аналогичного Glacier вроде бы нет да и вообще оно того не стоит.

Я сильно ошибался. Ниже будет рассказано как на базе DigitalOcean сделать себе VPN-сервер в пару десятков раз дешевле такого же на Амазоне и сервис хранения архивов, в бесконечность раз дешевле Glacier.

Всем приятного чтения. Я хочу рассказать о небезопасной фиче во всемирно известном движке для блогов — WordPress, которая присутствует в нем уже долгое время. О ней многим известно (в т.ч. эту возможность признают как «законную» сами разработчики), но я точно не уверен, описывал ли кто-то её использование именно в предлагаем в статье векторе атаки (лично я найти не смог).

Множество компаний, таких как Microsoft, Nokia, Google используют WordPress. Администраторы блогов выдают права редакторов своим PR-службам… И вот тут главный момент — в WordPress только две роли имеют права использовать javascript внутри постов — администраторы и редакторы.

Вся идея в одно предложение: создаём пост, содержащий зловредный JS. Если администратор открывает наш пост — мы получаем Remote Command Execution.

Kарточки — будущее веба. Они становятся лучшим дизайн-паттерном для мобильных устройств.

На наших глазах идет пересмотр архитектуры веба. От страниц и адресов к полностью персонализированным интерфейсам, состоящих из множества элементов информации, агрегируемых из многих из разных источников. Контент разбивается на части и пересобирается заново — и это результат роста популярности мобильных технологий, миллиардов экранов всех форм и размеров, а также небывалой доступности данных через разнообразные SDK и API.

Все это меняет архитектуру веба — от связанных между собой страниц к связанным в единый интерфейс элементарных частей информации.



Агрегация зависит от:

• Человека, потребляющего контент, его интересов, предпочтений и поведения.
• Интересов его друзей, их предпочтений и поведения.
• Местонахождения и контекста.
• Рекламного таргетинга.

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

Привет, Хабр! Мы продолжаем наш цикл материалов про бизнес веб-студий в рамках Осеннего Ускорения с NetCat и сегодня подробно говорим о маркетинговой стратегии веб-студии, а также публикуем шаблон карты маркетинговых активностей.

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

Введение

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

Возможности встроенного в браузер инструмента Chrome Developer Tools можно расширить с помощью сниппетов. Это ускоряет разработку и упрощает рабочий процесс. Хорошая коллекция сниппетов есть на GitHub'е.

Сниппеты в Google Chrome

Подробно о функциях сниппетов можно почитать в официальной документации Chrome. А вот краткая инструкция:

1. Зайти в «chrome://flags» — Отметить «Enable Developer Tools experiments».
2. Открыть DevTools: «Settings» — «Developer Tools Experiments» — Отметить «Snippets support».
3. После перезагрузки во вкладке DevTools «Sources» появится «Snippets», где можно управлять сниппетами:

Привет, хаброжители!

Мы продолжаем цикл книг о животных. Сегодня у нас новый зверёк — «Изучаем Node.js» .
Книга, которую мы сейчас представляем, предназначена для тех, кто еще не использовал данную технологию, но хотел бы быстро начать работу с ней. Итак:

От переводчика:
Я собрался изучить новый для меня паттерн Стратегия, но не нашёл толкового русского описания его реализации на javascript. Статья на wiki пугает своей сложностью, а наглядность примера оставляет желать лучшего. По этому и взялся за перевод этой статьи, одновременно разбираясь, что же из себя представляет данный паттерн.
Спойлеры и текст, выделенный серым, являются моими комментариями.

Далее мы разберём примеры того, как я использую СТРАТЕГИЮ в Javascript, и как он используется реальной библиотекой, для разбиения её на небольшие части.

JavaScript, the winning style

Код написанный в одном стиле, имеет много преимуществ: меньше мелких ошибок, многие ошибки легко обнаружить почти сразу, другие же можно легко отладить еще на стадии разработки. Новым же программистам не придется тратить лишнее время на изучение вашего кода (это не значит что им не придется разбираться в самом коде, а значит лишь что его легче будет читать) и им будет проще влиться в проект.

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

В отличие от Питона у которого есть единый свод правил «Style Guide for Python Code», у языка JavaScript такого нет. Однако на выбор есть целых 6 популярных гайдов:

• Google JavaScript Style Guide
• npm’s coding style
• Felix’s Node.js Style Guide
• Idiomatic JavaScript
• jQuery JavaScript Style Guide
• Douglas Crockford’s JavaScript coding style

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

Последний месяц, в связи с недавними событиями — закрытием почтового сервиса с шифрованием LavaBit, заявлениями Гугла, что Gmail не гарантирует безопасность данных, переходом крупнейших email-сервисов Германии на шифрование писем, в Интернете все чаще стали говорить об обеспечении конфиденциальности частной переписки. Начнем с простых решений.

SecureGmail

Большинство из нас пользуется почтой от GMail, поэтому хорошо бы научить его шифрованию писем. К счастью, уже есть расширение для Google Chrome — SecureGmail.

Быстрая и плавная загрузка изображений — это одна из немаловажных составляющих хорошего веб-интерфейса. Кроме того, появляется все больше сайтов, использующие крупные фотографии в дизайне, таким проектам особенно важно следить за корректной загрузкой графики. В этой статье описано несколько техник, которые помогут контролировать загрузку изображений.

Использование контейнера для каждого изображения

Простой способ, который можно применить к любому изображению на сайте. Заключается в том, что каждая картинка оборачивается в DIV, который предотвращает построчную загрузку:

<div class="img_wrapper">
    <img src="comicbookguy.jpg" alt=""/>
</div>

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

Эта статья продолжает тему применения математического моделирования при разработки игр в жанре ТD. В прошлых статьях рассматривались базовые параметры основных объектов игры – крипов и башен, и их зависимость от времени раунда и размера карты, а также принципы построения внутриигровой экономики, которая не привносила бы дисбаланс на тех или иных этапах игры.

Дальнейшее развитие этой темы напрашивалось само собой: если известны основные алгоритмы, которые позволяют задавать граничные рамки игровых параметров, то эти же алгоритмы можно применять для создания AI, который позволил бы хотя бы частично заменить игрока и проверить геймплей «вживую».