К версии 0.23 язык представлял собой весьма наивный концепт быстрого и простого языка.

И это было очень удобно при разработке микросервисов, таких же простых, как на Ruby, но более быстрых, чем на Go (в большинстве применений).

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

Я подошёл к этому с одной стороны, реализовав нормализацию чисел, например, но тут свыше пришел ангел по имени @funny-falcon, и уютный мирок Crystal офигел. Один pull request, учитывающий особенности LLVM, генерации хэшей, сами хэши, JSON и кучу иного — стал предметом обсуждений более чем на 200 комментариев, что для маленького проекта вообще нонсенс.

В итоге pull request закрыт (дикая нагрузка).

Но почти все его идеи уже реализованы и находятся в Crystal master.

Теперь на нем уже можно писать код, который можно отдавать наружу.

Введение

В доисторические времена высокопроизводительные Web-приложения можно было писать, в основном, на C или C++. Поддерживать такие приложения было не просто дорого, а очень дорого.

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

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

Если же немного снизить планку надежности, то здесь перед нами широкий выбор, включая Node, Go, Nim и Crystal. Можно взглянуть на типичные сравнительные данные по производительности, включая более обширные.

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

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

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

Так почему же Crystal?

Введение

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

Основные нюансы при формировании таких писем:

• Все стили должны встраиваться (inline) в виде атрибута style для конкретного HTML-элемента.
• Все изображения должны встраиваться, либо как отдельные вложения в в письме, либо в виде base64-кодированных данных (второе банально удобнее).
• Письмо должно поддерживать DKIM (настройка мэйлера), а домен отправителя — содержать SPF-запись.

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

Например, в REG.RU на сегодня в словарях более 15000 фраз, из которых порядка 200 используют склонение, и более 2000 используют подстановку переменных. Каждый день добавляется не менее 10 фраз. И это при том, что мы пока только начали локализацию сайта и впереди планы на новые языки.

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

DON'T PANIC.

Недавно был опубликован пакет BabelFish 1.0, предназначенный для интернационализации JavaScript-приложений.

Идеи, лежащие в его основе, настолько пришлись нам по душе, что мы даже перенесли их на Perl в виде CPAN-модуля Locale::Babelfish, и используем это для Perl-приложений. Но вернёмся к JavaScript-реализации.

Недавняя статья про WebDriver напомнила мне немного рассказать об используемом нами комплексе для автоматизации тестирования Web-приложений.

Итак, в основе тестов лежит лежит связка RSpec + Watir WebDriver (для Rails-приложений более уместно будет взглянуть в сторону Capybara). При поддержке Bundler и локальных WebDrivers осуществляется лёгкая инсталляция на рабочем месте тестировщика (установить Ruby 1.9, Rubygems, Bundler, и выполнить bundle install). Исходник Gemfile:

source :rubygems

gem "watir-webdriver", "~>0.6.1"
gem "rspec-core", "~> 2.0"
gem "rspec-expectations", "~> 2.0"
gem "rr", "~> 1.0"
gem "ci_reporter", "~> 1.7"

За счет гема ci_reporter осуществляется интеграция с Jenkins CI, а за счёт гема parallel_tests и Selenium Grid распараллеливание тестов (на сегодня parallel tests пока не используются в production).

Вот пример теста:

describe "FirstSite" do
  before(:all) do
    site! "first"
  end

  # returns true on success; otherwise false.
  def login_as(data)
    browser.rel_goto "/"
    browser.title.should include 'example.com'
    browser.text_field(:id => 'login').set data[:login]
    browser.text_field(:id => 'password').set data[:password]
    submit_button = browser.button(:id => 'submit')
    submit_button.click
    browser.url =~ %r{/welcome$}
  end

  def logout
    browser.rel_goto "/"
    browser.button(:id => 'logout').click
  end

  describe :login do
    auth = fixture :auth

    describe :successful do
      after(:each) do
        logout
      end

      auth.keys.select { |key| key.kind_of?(Symbol) }.each do |key|
        next  if key == :wrong

        it "Logging in as #{key} should be OK" do
          login_as(auth[key]).should be_true
        end
      end
    end

    describe :wrong do
      it "Logging in with wrong credentials should fail" do
        login_as(auth[:wrong]).should_not be_true
      end
    end
  end
end

Тестируемые сайты и способ тестирования определяются в настройках.

На днях нужно было построить биндинги к библиотеке libftdi, которая обеспечивает взаимодействие с чипами FTDI (чипы для преобразования последовательной передачи данных по RS-232 или уровней TTL в сигналы шины USB, для того чтобы дать возможность современным компьютерам использовать устаревшие устройства © Wikipedia).

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

У FFI есть несколько достоинств, которые сыграли в его пользу:

• Поддержка интерпретаторов MRI Ruby 1.9, MRI Ruby 1.8, JRuby, ограниченная поддержка Rubinius;
• Поддержка платформы Windows (наряду с другими);
• Отсутствие необходимости компиляции биндингов;
• Удобный язык описания биндингов.

Репозиторий биндингов для Ruby.

Взаимодействие с браузерами никогда не было работой для слабонервных: около полудюжины различных API, различные механизмы IPC, и разные возможности у разных поставщиков. Такие проекты, как WebDriver, пытаются абстрагироваться от этой сложности, к тому же в Сети можно найти десятки других «безголовых» драйверов, использующих WebKit или иные движки. В настоящее время в работе даже находится спецификация W3C на WebDriver.

Инструментирование Google Chrome

Тем не менее, в то время, как создание общего решения является сложной задачей, оказалось, что инструментирование Chrome очень просто, — как я недавно обнаружил при исследовании некоторых вопросов, связанных с сетевыми задержками. Начиная с 18 версии, Chrome теперь поддерживает протокол удалённой отладки v1.0, который предоставляет все возможности браузера с помощью обычного WebSocket!

/Applications/Path To/Google Chrome --remote-debugging-port=9222 # OSX
$> curl localhost:9222/json

[ {
   "devtoolsFrontendUrl": "/devtools/devtools.html?host=localhost:9222&page=1",
   "faviconUrl": "",
   "thumbnailUrl": "/thumb/chrome://newtab/",
   "title": "New Tab",
   "url": "chrome://newtab/",
   "webSocketDebuggerUrl": "ws://localhost:9222/devtools/page/1"
} ]

В Windows 8 CP и Server Beta все клиенты и сервера Microsoft WebSocket, включая IE10, сейчас поддерживают финальную версию протокола IETF WebSocket. Кроме того, IE10 реализует предварительную рекомендацию W3C WebSockets API.

WebSockets стабильны и готовы к тому, чтобы разработчики начали создавать инновационные приложения и сервисы. Эта статья представляет собой простое введение в W3C WebSockets API и ниже расположенный протокол WebSocket. Обновленная демонстрация Flipbook использует последние версии API и протокола.

В моей предыдущей статье я описал сценарии использования WebSockets:

WebSockets позволяют Web-приложениям выполнять доставку нотификаций и обновлений в реальном времени, прямо в браузер. Разработчики столкнулись с проблемами, связанными с необходимостью обходить ограничения персоначальной модели взаимодействия HTTP вида запрос-ответ, чей дизайн не предназначен для сценариев реального времени. WebSockets позволяют браузерам открывать двухсторонний, полнодуплексный канал коммуникаций с сервисами на стороне сервера. Каждая из сторон может использовать этот канал для немедленной доставки данных другой стороне. Сегодня сайты, начиная с социальных сетей и игр, заканчивая финансовыми сайтами, могут предоставить лучшие сценарии реального времени, чем ранее, в идеале используя одну и ту же разметку в различных браузерах.

Со времени публикации той статьи в сентябре 2011 года рабочие группы достигли важного прогресса. Протокол WebSocket теперь стал стандартным протоколом, предложенным IETF. К тому же W3C WebSockets API теперь является кандидатом-рекомендацией W3C.

Чтобы избежать больших затрат на развертывание сред разработки и тестирования, приближенных к среде эксплуатации (development stage vs production stage parity), всё большую популярность приобретает виртуализация сред.

В этой статье я расскажу, как создавал соответствующую репродуцируемую среду разработки на примере своего проекта runit-man с использованием Vagrant.

Хотя на Хабре уже проскакивали статьи о создании гемов, они либо содержат устаревшую, либо неполную информацию.

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

Современный подход заключается в использовании Bundler совместно с другими инструментами, такими, как Git, YARD и RSpec-2.

В MediaWiki, начиная с версии 1.17, появился новый механизм сборки и загрузки стилей и скриптов — ResourceLoader. В этой статье я опишу его использование на примере расширения GoogleCodePrettify, которое добавляет тэг syntaxhighlight в разметку MediaWiki.

Всем авторам расширений настоятельно рекомендуется использовать новый механизм взамен устаревших addScript etc.

Вышла новая версия библиотеки jQuery (упакованный вариант), в которой исправлены мелкие ошибки:

• Атрибуты данных, содержащие в имени один дефис, не были доступны по имени в верблюжьей нотации;
• Обработчик события $(“form”).live(“submit”, fn) не вызывался при нажатии на <button type=”submit”> в IE8;
• Исправлена ошибка с обработкой типа MIME application/xhtml+xml, появившаяся в jQuery 1.6.3.

К сожалению, один баг, влияющий на работу jQuery UJS, так пока и не исправлен.

Я просто хотел бы шокировать вас моими последними достижениями в области хакинга: я создал двунаправленный мост к библиотекам выполнения Objective-C из среды Node. Эта сумасшедшая штука позволяет делать замечательные вещи, например, писать родные приложения для MacOS X и iOS полностью на Node и JavaScript!

Я создал высокоуровневую библиотеку, которую назвал NodObjC, и она предлагает лёгкий для использования API, непосредственно формируемый из API библиотек Objective-C. Вот пример из README:

var $ = require('NodObjC');

// First you need to "import" the Framework
$.import('Foundation');

// Setup the recommended NSAutoreleasePool instance
var pool = $.NSAutoreleasePool('alloc')('init');

// NSStrings and JavaScript Strings are distinct objects, you must create an
// NSString from a JS String when an Objective-C class method requires one.
var string = $.NSString('stringWithUTF8String', 'Hello Objective-C World!');

// Print out the contents (calling [string description])
console.log('%s', string);
//   → Prints "Hello Objective-C World!"
pool('drain');

Последние несколько недель я использую все свободное время, которое могу найти, чтобы обдумать, какие технологии мы будем использовать, чтобы реализовать первую версию BankSimple. Многие люди, вероятно, предположат, что я сразу же предпочёл Scala, в связи с тем, что я был соавтором книги об этом языке, но я подхожу к решению инженерных задач совершенно иначе. Каждая проблема имеет соответствующий набор применяемых технологий, и задача разработчика, — обосновать необходимость их использования.

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

Одной из самых обсуждаемых технологий среди Hacker News является Node, окружение для разработки и запуска событийно-управляемых приложений JavaScript на виртуальной машине V8. В рамках выбора технологий для реализации проекта я выполнил оценку Node. Вчера я выразил некоторый общий скепсис относительно Node, и автор этого окружения, Райан Дал, попросил, чтобы я изложил свои мысли более подробно. Так вот, приступаю.

Я хотел бы поделиться прототипом игры, созданным всего за несколько часов. Надеюсь, что он вдохновит нескольких из вас! В индустрии однопользовательских браузерных игр, кажется, очень не хватает воображения и умения рассказывать истории, хотя, возможно, я просто не заметил таких игр ;), но мне не хватает таких игр, как Grim Fandango.

Ниже приведен скриншот из демонстрации, состоящей из нескольких узлов DOM, представляющих составные части главного героя, птиц и сцену. Большинство анимаций осуществляется CSS-переходами/анимациями, некоторые из которых являются динамическими и используют библиотеку move.js.

Это интервью было проведено Олегом Подсечиным с Райаном Далом (Ryan Dahl) 8 июля 2010 г., вскоре после чтений Райана в Кельне. Олег — энтузиаст JavaScript, который управляет Ionsquare Ltd, специализирующейся в области ИТ-консалтинга.

О.П.: Первый вопрос на самом деле вводный. Как вы пришли к Node.JS? Был ли у вас раньше опыт работы с JavaScript? Когда вы начали работать с использованием JavaScript? А также с событийно-управляемым программным обеспечением?

РД: Я работал по контракту, и делал различные маленькие проекты на C, как правило, серверное событийно-управляемое программное обеспечение, и я понял, что пишу один и тот же код снова и снова. С — великолепный язык для работы, но я хотел что-то, позволяющее писать скрипты в том же стиле, в котором я обычно программирую серверное ПО.

Nodeload, первому проекту команды GitHub, выполненному с использованием node.js, недавно исполнился 1 год. Nodeload, — это тот сервис, который упаковывает содержимое Git-репозитория в ZIP-архивы и тарболы. С тех пор нагрузка на сервис росла в течение года, и мы столкнулись с различными проблемами. Почитайте о происхождении Nodeload, если вы не помните, почему это работает так, как работает сейчас.

По существу, у нас стало слишком много запросов, проходящих через один сервер nodeload. Эти запросы запускали процессы git archive, которые запускали SSH-процессы для общения с файловыми серверами. Эти запросы постоянно записывали гигабайты данных, а также передавали их через nginx. Одной простой идеей было заказать больше серверов, но это создало бы дубликат кэша заархивированных репозиториев. Я хотел избежать этого, если возможно. Итак, я решил начать все сначала и переписать Nodeload с нуля.

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

Недавно столкнулся с интересной проблемой, когда попытка отдать большой файл через Sinatra::Helpers.send_file приводила к отжиранию всей оперативной памяти (типичный размер файла — 14Gb).

Исследование показало, что Sinatra сама читает и отдает файл кусками по 512 байт, но web-сервер thin (а также WEBrick) буферизует вывод в оперативной памяти на своем уровне, что и приводит к таким печальным последствиям.

Для решения проблемы достаточно оказалось перейти на web-сервер Rainbows (web-сервер, базирующийся на коде unicorn, но предназначенный для работы без проксирования, для медленных клиентов и/или сервисов). Но при отдаче больших файлов процесс кушал порядка 30% CPU на одном ядре.

Rainbows позволяет оптимизировать отдачу файлов, используя, к примеру, гем sendfile, который предоставляет соответствующие API операционной системы. Но для этого необходимо, чтобы отдача файла шла через Rack::File API.

В текущей master-ветке Sinatra метод send_file переписали, используя API Rack::File, поэтому мы можем просто бэкпортировать соответствующий функционал в существующие версии гема Sinatra:

donnerjack13589 анонсировал новый модуль для Node.JS, — node-spdy, который добавляет поддержку протокола SPDY, который был предложен компанией Google и внедрен в Chromium/Google Chrome и на сайтах компании Google (подробнее...).

Напомню, что основной целью при создании протокола SPDY было снижение задержек при доставке контента.

Пример использования модуля node-spdy:

var options = {
  key: fs.readFileSync(__dirname + '/../keys/spdy-key.pem'),
  cert: fs.readFileSync(__dirname + '/../keys/spdy-cert.pem'),
  ca: fs.readFileSync(__dirname + '/../keys/spdy-csr.pem'),
  NPNProtocols: ['spdy/2']
};

spdy.createServer(options, function(req, res) {
  res.writeHead(200);
  res.end('hello world!');
});

Приветствуется помощь сообщества в разработке.