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

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

О чем это я?

С чего начинается практически каждое web-приложение на Erlang? Не знаю, у кого как, а у меня, как правило, со строчек кода, ответственных за запуск Ковбоя и обслуживание запросов. С функции обновления правил роутинга. Причем всегда это одно и то же — только роуты отличаются, порт и количество акцепторов, может быть. И это можно сделать проще. Догадались уже, к чему я клоню? Нет, это не очередной фреймворк. Это превращение встраиваемого ковбоя в отдельно запускаемое приложение. То есть мы пишем наше приложение, хендлеры Ковбоя, но сам Ковбой не трогаем. Вообще. Ни зависимостей не указываем, ни при старте приложения не запускаем. Любопытно? Добро пожаловать под кат.

Привет!
В этом туториале я планирую показать тем, кто еще не знаком с веб-сервером Cowboy, как им пользоваться. Для людей, которые имеют опыт работы с ним, данный туториал врядли будет интересен, а вот для тех, кто знает о Ковбое лишь по наслышке — welcome!

Что мы будем делать:

1. Простейшая установка и запуск сервера
2. Краткий обзор роутинга, обслуживание статики
3. Шаблонизация с помощью ErlyDTL (Django Template Language для Erlang)

Интересно, скольким из вас приходилось хотя бы иногда, но повторять рутиные действия для настройки автодеплоя с гитхаба на сервер: создать ssh-ключ, добавить его для репозтория проекта на Гитхабе, создать скрипт, который будет слушать какой-то адрес, добавить вебхук в интерфейсе гитхаба, который будет дергать этот скрипт… Уфф… А что, если я скажу вам, что автоматизировал все эти действия по-максимуму? Да, теперь вам нужно выполнить всего пару команд и автодеплой запущен и работает! И все это благодаря Гитхабайзеру.

Erlang on Xen позволяет запускать приложения Erlang без операционной системы, на голом гипервизоре Xen. От момента запуска VM до начала работы приложения проходит всего 50 миллисекунд — в 100-1000 раз меньше, чем нужно для запуска привычного сочетания Linux+Erlang, а размер образа машины составляет лишь около 1 Мб. Это позволяет добиться практически мгновенного масштабирования, вплоть до запуска экземпляра VM после того, как пришёл запрос от клиента.

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

Лежащая в основе Erlang on Xen виртуальная машина Ling показывает производительность, сравнимую со стандартной для Erlang VM BEAM (Bogdan/Björn’s Erlang Abstract Machine).

В этой статье я хочу поделиться опытом создания инфраструктуры для интеграционного тестирования веб приложения. Приложение построено на платформе .Net и состоит из ASP.NET MVC приложения и базы данных на MSSQL

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

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

Поскольку интеграционное тестирование позволят имитировать действия пользователя можно сказать, что оно позволят проверять факт того, что такой-то пункт ТЗ успешно выполнен. Если создать тесты для каждого пункта ТЗ (то получим программу и методику испытаний — ПМИ :) и автоматизировать их, то количество успешно выполненных тестов будет означать реальную информацию о том, на сколько процентов исполнено ТЗ. Иначе оценка состояния системы будет выглядеть следующим образом:
— Ну как у нас сегодня система, если одним словом?
— Если одним словом, то… работает.
— А если в двух словах?
— А если в двух словах, то не работает.

Что должно проверяться при таком тестировании:
— Компиляция и сборка приложения
— Процедура установки или обновления приложения:
— Установка новой или обновление существующей базы данных
— Установка нового ASP.NET приложения
— Выполнение тестовых сценариев в каждом из которых:
— Система подготавливается для выполнения сценария. Поскольку каждый сценарий имеет предусловия надо подогнать систему под эти условия. Например если для сценария надо чтобы в системе бы пользователь создавший три заказа, надо как-то получить в базе денных пользователя и три его заказа.
— Выполняется тестовый сценарий через эмуляцию действий пользователя в браузере.
— Система возвращается в состояние, которое было перед выполнением сценария, фактически в состояние сразу после установки приложения
— Составление отчёта о качестве приложения
— Сборка инсталяционного пакета, содержащего приложения с известным качеством.

Недавняя статья про 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

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

Время от времени мне приходится распутывать терминологические хитросплетения, связанные с употреблением словосочетаний, в которых встречается слово Selenium – Selenium 2.0, Selenium IDE, Selenium RC, Selenium WebDriver, Selenium Server, Selenium Grid.

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

Начало

И вот пришла моя очередь покупать автомобиль. Как это делают ребята с работы я видел. Заходят на сайт и следят за предложениями, ну кто постарше покупает газету и просматривает объявления. Все это однообразно и отвлекаться на сиденье, исследование и нажатие по ссылкам не хотелось. Хотелось просто что бы кто то делал это за меня, таких людей не нашлось. Значит надо было заставить делать все это компьютер.

В буддизме есть понятие просветления.

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



На практике это значит, что, если вы достигнете просветления, то будете знать всё. Вообще всё, даже то, до чего наука пока и не догадывается. Вы будете понимать суть вещей. Супер-коннект во вселенским разумом позволит вам творить множество “волшебных” штук типа астральных путешествий, осознанных перерождений, и т. д.

Это как в компьютерной игре набрать чит-код и прокачать своего персонажа.
И, похоже, у буддистов есть проверенный способ.

Все ближе тот момент, когда выйдет четвертый порядковый релиз фреймворка Ruby on Rails. Доступно уже довольно много информации, и большой частью нового функционала можно начать пользоваться уже сейчас, чтобы массовый исход на новую версию не стал слишком болезненным (хотя политика версионности рельсы делает все, чтобы этот процесс был максимально гладким).

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

Блог Flying Machine Studios
6 декабря 2012 года
перевод статьи The Unofficial Guide to Rich Hickey's Brain



Частично, мое удовольствие от изучения Clojure возникло благодаря знакомству с мыслями Рича Хики о программировании. У Рича есть свой взгляд на фундаментальные концепции программирования, ясный и последовательный, и я думаю, что каждый программист смог бы выиграть, используя его. Каждый раз, когда я смотрю одно из его выступлений, у меня складывается ощущение, что кто-то взял и привел мой ум в порядок.

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

Весь последующий текст основан на выступлении Рича Хики «Are we there yet?»

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

Одна из ошибок, которую делают разработчики (и я когда-то в их числе) — это утверждение о том, что вы должны использовать ровно одну ORM-стратегию для создаваемого приложения. В общем случае это неверно. Вы можете (и должны) привязывать выбор стратегии к конкретному сценарию, и быть уверенным в том, что выбираете правильные инструменты для конкретного случая.

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

Здесь я немного усложню задачу — в первой части был описан только один vdev; здесь их у нас будет несколько, поскольку алгоритм должен выбрать и vdev, куда мы будем писать блок данных, и metaslab внутри vdev'a. В продакшн системе может быть несколько десятков vdev, и правильно распределить данные по ним критично — перебалансировать их мы уже не сможем без копирования всех данных. Цель правильного алгоритма — распараллелить данные так, чтобы на каждом девайсе их было примерно одинаковое количество, выровнять неравномерное заполнение, но и не перегрузить один из девайсов (это будет тормозить запись на весь пул).

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          c1t6d0    ONLINE       0     0     0
          c1t5d0    ONLINE       0     0     0

Для начала, важное замечание: ZFS рассчитан на то, что все девайсы в пуле имеют одинаковый размер. Иначе, например если добавить 2Тб диск в пул из 1Тб дисков, на 2Тб диске в результате окажется в два раза больше данных, и он начнёт влиять на суммарный IOPs системы — алгоритм аллокатора учитывает процент заполнения, а не количество данных в байтах.

На данный момент в ZFS есть четыре алгоритма аллокатора. Переменная zfs_metaslab_ops содержит поинтер на структуру space_map_ops_t, в которой есть поинтеры на семь функций, которые использует каждый конкретный алгоритм. Например, в Illumos используется алгоритм metaslab_df, и соответствующий стракт с поинтерами на функции выглядит вот так:

Vdev, или Virtual Device — это базовая единица, на которой строится массив данных ZFS (zpool). Для работы ZFS необходим как минимум один vdev — виртуальное устройство, которое позволяет случайный доступ к информации на уровне блоков.

Обычно, в качестве таких блоков используются целые диски или iScsi/FC LUNы (raw-disk vdev), но можно также использовать разделы дисков или файлы. Целые диски предпочтительнее, так как для них ZFS использует onboard write cache, в результате чего производительность записи может значительно улучшиться. Я пока не буду объяснять разницу между logical vdev и leaf vdev — это топик для отдельной статьи про то как работает RaidzN и zfs mirror.

src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/fs/zfs/vdev_disk.c#314

if (vd->vdev_wholedisk == 1) 
{
	int wce = 1;
	/*
	 * If we own the whole disk, try to enable disk write caching.
	 * We ignore errors because it's OK if we can't do it.
	 */
	(void) ldi_ioctl(dvd->vd_lh, DKIOCSETWCE, (intptr_t)&wce, FKIOCTL, kcred, NULL);
}

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

Каждый vdev разделен на логические разделы (metaslab),

1 Вступление

В топике освещаются не столько подробности работы с git, сколько его отличия от схемы разработки других систем контроля версий, и общий подход (выработанный по большей части личным опытом и Git Community Book) к работе.

Как известно, CoffeeScriptпредлагает несколько иной набор управляющих конструкций, нежели JavaScript.

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

Как известно, все люди делятся на два вида: те, кто ещё не делает бэкапы, и те, кто их уже делает. У тех, кто только начинает делать бэкапы, первым обычно встаёт вопрос о том, каким способом архивировать данные. Простые варианты (вручную нарезать болванки, целиком архивировать каталоги на другие серверы) рассматривать не будем — у них весьма скромные возможности по индексированию и поиску архивных файлов. Вместо этого обратимся к автоматическим системам бэкапов, в частности bacula. Данная статья не рассматривает вопрос, почему bacula. Главные причины — она распространяется под свободной лицензией, доступна для кучи платформ и обладает огромной гибкостью.

Второй вопрос после выбора системы архивации — выбор места, где хранить бэкапы. Bacula позволяет использовать стриммеры, компакт-диски, писать архивы в FIFO-устройства и в обычные файлы. Стриммер удобен на корпоративных серверах, где есть постоянный физический к железу. Хранение архивов в файлах подойдёт, когда объём архивов не превышает объёма жёстких дисков, плюс для надёжности хранения желательно делать RAID-массив с избыточностью, а то и несколько физических серверов для бэкапов, желательно в разных помещениях. Иначе всё это до первого пожара. Нарезать на болванки — это домашний вариант, главный недостаток которого — необходимость регулярного втыкания свежих дисков. Мы же настроили bacula для архивации данных на Amazon S3.

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

Несколько дней назад Jose Valim опубликовал в своем репозитории проект языка, построенного поверх Erlang. Этот язык обладает простой объектной моделью и Ruby-подобным синтаксисом. Под катом выжимки из документации и видео, демонстрирующее простой пример.

disclaimer: %username%, прежде чем делать выводы насчет того, что умеет, а что не умеет elixir, просьба глазами пройтись хотя бы по readme.