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

Спецификации Ruby обновились до версии 2.1.0. В новой версии языка программирования сделано несколько эволюционных изменений. В неофициальных бенчмарках на Rails версия 2.1 показывает результат примерно на 20% выше, чем 2.0, которая, в свою очередь, на 60-70% быстрее 1.9.3.

Вкратце, самые важные из них:

• VM (кэширование методов)
• новый сборщик мусора RGenGC (см. презентацию ko1 на RubyKaigi и на RubyConf 2013)
• изменения в синтаксисе
  
  • новая запись дробей с использованием двух слэшей ("//") между числителем и знаменателем, см. #8430
    
    • 1 // 2 == Rational(1, 2)
    • 1 // 1 == Rational(1, 1)
    • 0 // 1 == Rational(0, 1)
  • новые суффиксы i, r и ri для записи комплексных и рациональных чисел
    
    • "42r" и "3.14r" расцениваются как рациональное число Rational(42, 1) и 3.14.rationalize, соответственно. Но экспоненциальная форму с суффиксом 'r', такая как "6.022e+23r", не принимается.
    • "42i" и "3.14i" расцениваются как Complex(0, 42) и Complex(0, 3.14), соответственно.
    • "42ri" и "3.14ri" расцениваются как Complex(0, 42r) и Complex(0, 3.14r), соответственно.
• определение функции def теперь возвращает символ её названия вместо nil, см. #3753

Не так давно, 18 декабря, состоялся релиз очередной версии Rails. Забавно, что существует пост, датированный 17-м декабря, и ссылающийся на статью из будущего. Из очередных полезностей новой версии:

• Ускорение загрузки с помощью Spring
• Единое место для хранения разнообразных ключей API, секретов и прочего: config/secrets.yml
• Предпросмотр email'ов: Action Mailer Previews
• Удобная генерация различного контента в зависимости от конкретного request с помощью Action Pack Variants
• Добавление enum-атрибутов в Active Record

Эта статья была написана Аароном Паттерсоном, Ruby разработчиком из Сиэтла, штат Вашингтон. Он увлечен разработкой на Ruby вот уже 7 лет и будет рад поделиться своей любовью к этому замечательному языку.

Салют всем! Надеюсь, у вас отличное настроение. Сегодня солнце ненадолго выглянуло из-за туч, так что уж у меня-то точно все прекрасно!

В этой статье мы рассмотрим ряд инструментов компиляции для использования в связке с Ruby. А для погружения в предмет мы напишем синтаксический анализатор JSON. Уже слышу недовольные возгласы вроде: «ну Аарон, ну зачем? Разве их уже не 1,234,567 штук понаписано?» Вот именно! У нас уже 1,234,567 анализаторов JSON написанных на Ruby! И мы тоже будем производить анализ JSON, потому что грамматика его достаточно проста для завершения работы за один раз, и потому что она тем не менее достаточно сложна, чтобы можно было с умом применить разработанные для Ruby инструменты компиляции.

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

RVM — Ruby Version Manager
Программа для управления версиями Ruby.

Как быть если один проект использует Ruby 1.8.7, а другой 1.9.2? А что если при этом у вас 2 проекта под версией 1.9.2, но с разными наборами гемов? Хотелось бы вам иметь отдельные наборы gem's для каждого проекта?

Основные задачи:
1. Физическое разделение версий ruby и наборов гемсетов
2. Возможность иметь несколько версий ruby и переключаться между ними
3. Возможность для каждой версии ruby иметь несколько gemsets — наборов gem's и переключаться между ними

Под катом будут описаны:
1. Установка RVM
2. Работа с разными версиями Ruby
3. Работа с gemsets
4. Задание окружения под отдельный проект с помощью .rvmrc
5. Команды RVM которые могут оказаться полезными
6. Шпаргалка по основным командам RVM

Человек создан для творчества, и я всегда знал, что люблю творить. Увы, я обделён талантом художника или музыканта. Зато умею писать программы. Я хочу, чтобы компьютер был моим слугой, а не господином, поэтому должен уметь быстро и эффективно объяснить ему, что делать.
Юкихиро Мацумото, создатель языка Ruby

Перед каждым, кто желает идти по пути программиста, рано или поздно встаёт вопрос выбора сферы разработки ПО (web, desktop, mobile, игровое, системное,..) и соответствующих инструментов (языков программирования, framework'ов, сред разработки...). Причём здесь, как и в строительстве, важную роль играют материалы и орудия, которые вы используете. По сути, они во многом определяют, что в конечном счёте будет построено, насколько быстро, какими свойствами оно будет обладать и т.д.

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

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

На то, чтобы более-менее близко познакомиться с новым языком, обычно уходит не менее месяца. Эта статья призвана ответить на вопрос, стоит ли потратить этот месяц на Ruby, или имеет смысл посмотреть в сторону других языков. Сам я сейчас также стою перед выбором: улучшать свои знания в PHP (пока я работал с ним самостоятельно во freelance'е — и на довольно простом уровне, сейчас же есть желание расти дальше) или попробовать «с нуля» в Ruby (сразу освоив с его помощью последние тренды в web-программировании и при этом получив, как я надеюсь, довольно современный и удобный инструмент для работы).

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

Доброго времени суток! Сегодня я хочу поделиться шестью наборами социальных иконок ICON.PACK, которые отрисовал на днях. Все иконки разбиты на 6 групп, отличающихся по форме.

Это — статья-roadmap-cheatsheet для изучающих Ruby. Вместо того, чтобы рассказывать очередной how-to я постараюсь расписать все те вещи, которые, на мой взгляд, можно изложить кратко и емко, с упором на то, что программисту пришедшему с других языков и платформ может показаться не очевидным, антипоисковым и просто затратным по времени на изучение без подсказок — на остальное просто дам ссылки. Не смотря на то, что в природе существует множество туториалов/кастов/книг/чего угодно по чему угодно — именно такого формата мне самому всегда не хватает. И по сути, это те вещи, которые чаще всего рассказываю при вопросах «а как оно вообще?», «с чего начать?», «а как делается такая вот штука?», «а какой gem лучше?». Кстати, пока работал над этой статьей на Хабре появилась похожая про Python — видимо, идея витает в воздухе.

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

Доброго времени суток, читатель.

Предыстория

Я 5 лет работаю в компании, предоставляющей широкополосный доступ к всемирной паутине. Занимаюсь непосредственным управлением оборудованием, а также планированием и мониторингом сети. На момент моего прихода в сети было немногим больше 100 единиц управляемого оборудования вендоров Cisco и D-Link. Рисовали карту сети по старинке в visio, ip-адреса вели там же, но мой руководитель в то время начал писать некоторый софт для инвентаризации оборудования — началось все с учета выданных ip-адресов. Учитывая рост сети (а точнее модернизация в лице замены глупых «мыльниц» на «управляки»), мы и решили, что обычного Cacti нам не хватает. Стандартные счетчики по SNMP мы собирали сразу, но найти что-то более нужное и интересное было трудно. Неоднократные попытки овладеть другими опциями не приводили к конечному результату, но не так давно удалось «обуздать» MIB-файлы для коммутаторов D-Link и считаю, что данная статья ускорит процесс изучения коммутаторов и протокола SNMP. Это позволит быстрее и качественнее управлять сетью.

В этом посте я расскажу, как правильно настроить Nginx для максимально эффективной отдачи больших файлов из вашего rails приложения. К своему удивлению, на русском языке я такой информации не нашел. Есть статьи про использование X-Accel-Redirect совместно с php, а вот чтобы про рельсы да на родном языке что-то не густо… Вобщем, постараюсь восполнить этот пробел.

Задача

Итак, исходные данные следующие:

• мы используем Ruby on Rails, запросы пользователей проходят через Nginx;
• нам нужно отдавать большие файлы;
• файлы должны быть недоступны для прямого скачивания, решение об отдаче файла принимает rails приложение.

Вступление

На хабре, по-моему, уже почти все возможные графические API для руби рассматривались. Но почему-то все воспринимают и подают эти самые API исключительно как чистый код. Никаких тебе графических дизайнеров, никакой скоростной разработки GUI — сиди, вычисляй координаты ручками, подгоняй как надо. А зачем иначе, ведь на руби серьезных GUI приложений не написать.
А вот и нет! Если уж на то пошло, то на руби можно написать даже Wolfenstein. Но начинать лучше все-таки с чего-то менее глобального :)

Подготовка

Итак, попробуем написать что-нибудь не очень простое, достаточно GUI'евое и желательно не заморачиваясь на вычисление координат.

Хочу отметить, что эта инструкция родилась в процессе проведения экспертизы различных систем виртуализации в стенах компании Acronis.
Proxmox показал себя с хорошей стороны, возможно наш опыт окажется полезным для решения Ваших задач.

Арендуя очередной сервер в дата-центре, каждый задумывается о рациональности его использования.
Ведь ни для кого не секрет, что хорошо настроенный сервер не должен быть слишком нагружен и в нем должно быть достаточно ресурсов для выполнения другой работы. Кроме вышесказанного, важна отказоустойчивость и поэтому держать несколько копий одного и того же сервера в качестве hot swap, кажется отличной идеей.
Для решения этих задач и нужна виртуализация.

Сейчас я расскажу, как можно быстро сделать из одного сервера целый кластер серверов на базе linux и windows.
В дальнейших статьях я попытаюсь объяснить, как поднять безопасный web-кластер и использовать все прелести современных технологий виртуализации.
В этой инструкции речь пойдет о бесплатной системе виртуализации Proxmox, она находится в свободном доступе, но за поддержку требует плату. Мы попробуем обойтись без поддержки и коммерческого репозитория Proxmox. Вот что говорит о об этом продукте википедия

Proxmox Virtual Environment (Proxmox VE) — система виртуализации с открытым исходным кодом, основанная на Debian GNU/Linux. Разрабатывается австрийской фирмой Proxmox Server Solutions GmbH, спонсируемой Internet Foundation Austria.
В качестве гипервизоров использует KVM и OpenVZ. Соответственно, способна выполнять любые поддерживаемые KVM ОС (Linux, *BSD, Windows и другие) с минимальными потерями производительности и Linux без потерь.
Управление виртуальными машинами и администрирование самого сервера производятся через веб-интерфейс либо через стандартный интерфейс командной строки Linux.
Для создаваемых виртуальных машин доступно множество опций: используемый гипервизор, тип хранилища (файл образа или LVM), тип эмулируемой дисковой подсистемы (IDE, SCSI или VirtIO), тип эмулируемой сетевой карты, количество доступных процессоров и другие.

Ключевые возможности

• Простое управление через веб-интерфейс;
• Мониторинг нагрузки в реальном времени;
• Библиотека установочных образов (в локальном или удаленном хранилище);
• Подключение к «физической» консоли гостевых систем непосредственно из браузера (по VNC);
• Объединение серверов в кластер с возможностью живой миграции виртуальных машин (без остановки гостевой системы);
• Быстрое развертывание гостевых систем из шаблонов (доступно только для OpenVZ);
• Автоматическое резервное копирование виртуальных машин.

Собираем капли дальше (1, 2, 3). В этот раз узнаем о реализации ООП в Руби.

Классы, объекты, методы

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

Капаем дальше. В третьей капле (капля первая, капля вторая) мы познакомимся с числовыми переменными и узнаем о принципах ООП.

Числа и Выражения

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

Продолжаем изучать Ruby? Так точно!

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

Дабы сразу определить целевую аудиторию этого цикла заметок-статей-поучений пару слов о себе. Бывший школьник, будущий студент, в программинге толком ничего не смыслю, хотя есть пара сайтиков на готовых движках. В php-скриптах могу чего-нить лишнее удалить, изменить, но написать что-то с чистого листа — это не ко мне. Неоднократно пытался научится мастерству создания программ, но обычно тормозил как только дело доходило до ООП (видел в коде эти многочисленные классы, в пособиях всякие «объекты», «инкапсуляции» и т.п. и зависал...)

Собственно точно такое же желание появилось и сейчас. Порыскав по сети в поисках «чего-бы такого интересного выучить» наткнулся именно на Ruby с его рельсами. По словам спецов разного качества Руби сейчас актуален, программировать на нем быстро, это полный ООП (что перспективно в дальнейшем покорении олимпа программирования), синтаксис несложен… В то же время язык — тормоз, нагружает систему, twitter в нем барахтается, пытаясь удержаться на плаву, постоянные проблемы с хостингом. Но я вроде как стартапить в многомиллионную аудиторию не собираюсь, а для общего образования всегда подойдет.

Так что стоит признаться, что и Ruby я знаю совсем каплю, но уверен, что и мои «капли» будут интересны некоторым индивидам, подобным мне. Я могу (и буду) часто ошибаться в каких-то понятиях, методах, но мы ведь готовы помогать друг другу? Вроде бы как Хабр — это элита ИТ, но я думаю, что местные спецы не будут против, если мы тут с начинающими ребятами немного «потусим» :)

Собственно в этой серии статей мы будем капля за каплей наполнять стаканчик знаниями о Руби, наполнять будем вместе — для меня это также станет дополнительным стимулом не бросать занятия. Надеюсь, что и вам будет интересно! Начнем?

Немного истории

В 2011 году в DevOps-среде возникло движение, объединившееся под хештегом #monitoringsucks, и критиковавшее существующие системы мониторинга за отсутствие гибкости. Что именно их не устраивало — прекрасно иллюстрирует эта презентация.
Если вкратце — хочется людям некоего стандарта API для взаимодействия между компонентами мониторинга, ну и появления самих этих компонент, чтоб из них строить гибкий и умный мониторинг.

Итогом этой волны недовольства стали массовые обсуждения проблем и привлечение внимания к интересным утилитам типа Sensu и Riemann.

В 2013 году хештег в сообществе сменился — теперь это #monitoringlove. Произошло это благодаря развитию opensource-утилит для мониторинга.

Из новых утилит наибольший интерес представляет Sensu. Riemann я не стал всерьез рассматривать, поскольку на данный момент у него нет никаких средств для обеспечения отказоустойчивости, да и сама идея писать конфиг на Clojure мне не сильно нравится.

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

Периодически просматривая топики на хабре, постоянно ловлю себя на мысли, что ещё чуть-чуть и какой-нибудь нейроинтерфейс в ноутбуке станет реальностью. В работе постоянно натыкаюсь на то, что современные люди не очень понимают и любят простую командную строку. А читать мануалы им тем более лень.
Но в моей практике часто случается так, что нужна небольшая утилита, выполняющая одну или две функции. А где именно она будет выполняться — неизвестно. Это может быть Windows, это может быть исключительно терминальный линукс, загрузочная медия — что угодно. Я не программист, но иногда бывает нужно облегчить жизнь себе или другим. И желательно как можно более наглядно. Сначала я пробовал делать просто консольные утилиты. Собственно, с этого, наверное, начинают все. Но очень быстро оказалось, что средствами printf/sprintf/puts и прочими (а пишу я на С) не очень удобно форматировать текст, выводить какую-то информацию. Окно с постоянным «скроллингом» выглядит не очень красиво, и если информации много — абсолютно нечитаемо. Тогда я вспомнил про ncurses.

Что такое MPEG-DASH

MPEG-DASH — технология нового поколения, позволяющая вещать адаптивный видео-поток. Данные разбиваются на фрагменты и передаются клиенту по протоколу HTTP. Это позволяет надежно передавать видео через существующую HTTP-инфрастуктуру, преодолевать прокси-сервера, а также безболезненно переносить проблемы с сетью, изменения сетевых адресов итд.

DASH — Dynamic Adaptive Streaming over HTTP. Стандарт DASH ISO/IEC 23009-1:2012 был разработан группой MPEG в 2011 году

Технология MPEG-DASH в целом аналогична другой известной технологии HLS (HTTP Live Streaming), разработанной компанией Apple и широко используемой на мобильных устройствах с iOS и Android. Поток представлен в виде небольших по длительности фрагментов и плейлиста (манифеста), содержащего метаданные потока и ссылки на фрагменты.