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



Введение в React.js

React.js — это новый популярный парень из команды JavaScript фреймворков, он выделяется своей простотой. Когда другие фреймворки реализуют полный MVC (Model View Controller) подход, мы можем сказать React'у реализовать только View (Отображение) (факт — некоторые люди переписывают часть отображения (V) этих фреймворков c помощью React).

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

Одна хорошая особенность React.js это то что он не требует каких-либо дополнительных зависимостей, что обеспечивает ему подключаемость с любой js библиотекой. Пользуясь этим, мы будем включать его в наш Rails стек для создания внешнего интерфейса или можно сказать для создания «Rails на стероидах».

Макет для отслеживания расходов приложения

Для этого гайда мы создадим маленькое приложение с нуля что бы отслеживать наши действия. Каждая запись(дальше, тоже самое что и Record) будет состоять из даты, названия и суммы. Запись будет рассматриваться как Кредит(Credit) если его сумма больше нуля, в противном случае она будет рассматриваться каr дебет. Вот макет проекта:



Суммарно приложение будет вести себя так:

1. Когда пользователь создает новую запись через горизонтальную форму, она будет вставлена в таблицу записей
2. Пользователь может редактировать любую существующую запись
3. Кликнув на кнопку Delete он удалит ассоциацию из таблицы
4. Добавление, редактирование или удаление существующей записи будет обновлять сумму в боксах в верху страницы

Инициализация React.js в Rails проект

Автор: Сергей Зиновьев

Многие мобильные и веб-приложения включают в себя разные географические данные, ведь мы сталкиваемся с картами практически везде. Так, они используются в разных социальных приложениях — от геосоциальных сетей вроде Foursquare до сервисов по поиску попутчиков вроде BlaBlaCar. Google, Microsoft, Yahoo и многие другие IT-гиганты предоставляют свой API для простых операций: отображение карт, маркеров на этих картах и проведение наиболее востребованных вычислений. Популярный фреймворк для быстрой разработки Ruby on Rails часто используется для разработки геоинформационных систем (ГИС) и веб-приложений с использованием картографических данных. На простом примере продемонстирую, какие проблемы могут ждать при использовании пространственных данных и как их избежать в Ruby on Rails-приложении.

Как не встретиться со злым вулканом

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

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

«Банда четырёх» была неправа, стандартная библиотека Ruby тоже ошибочна, и Rails – также. Но является ли нечто неправильным, если все так делают?

Да.

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

Они говорят: «композиция прежде наследования». Отлично, в этом есть смысл. Они говорят: «используйте делегирование». Отлично. Хотя в книге нет ни единого примера делегирования.

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

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

Доброго времени суток.
Я работаю Ruby разработчиком в стремительно растущей IT-компании. И вот однажды нами было принято стратегическое решение смены сервиса для работы с Git. Всех, кому интересно, прошу под кат.

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

Оригинал статьи можно прочитать на сайте Jerome's Adventures in Software.

Как DHH (Дэвид Хайнемайер Хенссон) организовывает rails контроллеры

В недавнем интерьвью «с Full stack radio» наш гуру и спаситель DHH объяснил как он организовывает структуру rails контроллеров в последней версии Basecamp. Вот расшифровка его святых слов:

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

Этот пост о библиотеке telegram-bot для написания ботов для Telegram. В числе основных целей при её создании были удобство разработки, отладки и тестирования ботов, сохранение интерфейсов минимальными, но с возможностью расширения, простота интеграции с Rails-приложением, и предоставление необходимых инструментов для написания бота. Вот что входит в состав:

• Легковесный клиент для API ботов.
• Базовый класс для контроллера обновлений с парсером сообщений. Сделан на основе AbstractController из ActionDispatch, предоставляет колбэки, сессии, сохранение контекста сообщений и прочее.
• Rack-middleware для продакшена, чтобы принимать update-хуки, и поллер с автоматической загрузкой обновленного кода для удобной разработки.
• Rake таски, хэлперы для рельсовых маршрутов и тестов.

Интересно? Для установки добавьте telegram-bot в Gemfile, подробности под катом.

На 16 марта запланирован релиз Rails 5.0, самое время разобраться, что же нового и вкусного будет в новой версии рельсов (кроме нового логотипа и дизайна их официального сайта, я имею в виду).

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

Совсем недавно, после выхода Compose 1.6.0+ и Docker 1.10.0+, стала доступна 2 версия.
Добавлены ключи: services, volumes, networks. Будут удалены ключи: links.

Стараясь оставаться в тренде и следуя веяниям моды веб разработки, последнее веб приложение я решил реализовать как набор микросервисов на ruby плюс “толстый” клиент на ember. Одна из первых проблем, вставших перед мной была связана с аутентификацией запросов. Если в классическом, монолитном, приложении все просто, используем куки, сессии, подключаем какой-нибудь devise, то тут все как в первый раз.

Архитектура

За базу я выбрал JWT — Json Web Token. Это открытый стандарт RFC 7519 для представления заявок (claims) между двумя участниками. Он представляет из себя структуру вида: Header.Payload.Signature, где заголовок и payload это запакованые в base64 json хэши. Здесь стоит обратить внимание на payload. Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея, лучше передавать там только ключ идентификатор, а сами данные хранить где-то в другом месте. В качестве хранилища данных можно использовать что угодно, но мне показалось, что redis будет оптимальным, тем более что он пригодится и для других задач. Еще один важный момент — каким ключем мы будем подписывать наш токен. Самый простой вариант использовать один shared key, но это явно не самый безопасный вариант. Коль скоро мы храним данные сессии в redis, ничто не мешает нам генерировать уникальный ключ для каждого токена и хранить его там же.

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

22-25 февраля 2016 года будет проходить знаковое событие в сфере разработки ПО — hack.summit(). Это крупнейшая виртуальная конференция в истории. Самая большая в истории конференция по программированию. Самый крупный из проходивших в мире хакатонов с общим призовым фондом в 140000$ (на главной странице проекта почему то фигурирует 150000$, но в описании призовых мест 100k, 30k и 10k, может чего пропустил).

Для тех, кому достаточно hack.summit().

Примечания переводчика:

Всем привет. Данная статья является вольным переводом (ссылка в конце). Я не претендую на какую либо 100% корректность перевода. Однако считаю, что общую суть происходящего передал полностью.

Для кого может быть полезна эта статья? Скорее всего, для начинающих Ruby on Rails разработчиков, кому просто интересно понять некоторые моменты в работе Ruby.

Для кого эта статья может быть бесполезна? Скорее всего, для чистокровных Ruby программистов и прожженых Ruby on Rails разработчиков. Высока вероятность того, что вы это уже знаете.

Зачем я сделал перевод? Эта статья мне показалась интересной и внутри меня просто появилось желание поделиться ею со всем русскоговорящим (м.б. плохо знающим английским) сообществом.

P.S. Если знаете английский, просто перейдите по ссылке в конце.

Решил я недавно на примере одного проекта узнать, насколько сильно влияет на скорость загрузки сайта domain sharding. Напомню, суть этой оптимизации в том, что статические файлы грузятся с разных доменов (которые, впрочем, могут указывать на один и тот же сервер), и это позволяет обходить ограничение браузеров на количество одновременных подключений к одному домену. Интуитивно кажется, что в случае большого количества мелких файлов это должно существенно ускорить загрузку сайта в целом. Проверим, так ли это на самом деле.

Линда Лиукас самостоятельно научилась программированию, чтобы сделать сайт, посвящённый Альберту Гору

Вряд ли вы догадались бы, что миниатюрная светловолосая 26-летняя девушка окажется одним из самых одарённых программистов. Но Линда Лиукас из Хельсинки (Финляндия) описывает себя, как человека, которому нравится готовить, бегать, человека, у которого «слишком много детских книг» – и при этом она именно такая. Она участвовала в создании глобальной инициативы по привлечению женщин к программированию, работающей в 227 странах, и уже пишет и иллюстрирует серию книг, обучающих детей программированию. «Из женщин получаются хорошие программисты, потому что они творческие натуры и одновременно прекрасно умеют общаться»,- поясняет она мне при встрече на технологической конференции в Лондоне.

Лиукас, общительная и обаятельная, считается талантливым программистом, заново открывшим написание кода как визуальное и творческое искусство. Она была одним из первых сотрудников сайта Codecademy, получившего инвестиций на $10 млн., и предлагающего бесплатные уроки программирования. Затем в 2010 году она стала лицом некоммерческой организации Rails Girls, обучающей женщин созданию веб-приложений.


Иллюстрации Лиукас «Hello Ruby» должны стимулировать интерес детей к программированию

Независимый специалист по безопасности Уэсли Вайнберг (Wesley Wineberg) подвергся серьёзному давлению со стороны компании Facebook. Она не заплатила за найденные уязвимости на сервере Instagram, да ещё угрожает судебным иском.

Уэсли обнаружил уязвимость в инфраструктуре Instagram, с помощью которой нашёл (и, возможно, скачал) практически всё ценное, что есть на серверах Instagram: исходный код последней версии, SSL-сертификаты и приватные ключи для Instagram.com, ключи для подписи куков аутентификации, учётные данные от почтового сервера и ключи для некоторых других продуктов, в том числе для подписи мобильных приложений под iOS и Android.

Привет, Хабр! Давно манят меня лавры быть автором, и вот, наконец, настал тот светлый час, когда я допинал себя представить на твой суд мой небольшой опус.

Изучая на досуге Ruby и Rails, пробуя то RSpec, то вдруг Minitest, дошёл я до создания web-приложения с фронтэндом на JavaScript и бэкендом на Ruby, торчащим наружу REST API на базе обычных контроллеров Rails. Я использую Rails, хотя это совершенно не принципиально. Описанный ниже подход применить можно к чему угодно.

Тут следует сделать небольшое отступление. По натуре я человек требовательный, и всячески борюсь за доказанную стабильность кода (на словах-то уж точно). А уж когда речь заходит о безопасности пользователей в моём приложении, без тестов, хотя бы показывающих, что абы кто мои данные не получит, я чувствую себя совсем не комфортно. Начинаю грустить и вообще никакой код не писать. Даже если я — один-единственный пока пользователь.

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

На прошой неделе вышел превью Ruby 2.3.0. Что есть интересного из изменений:

• оператор безопасной навигации вглубь объектов (safe navigation operator), #11537
• в Hash и Array добавлен метод dig для доступа вглубь вложенных хэшей или массивов #11688
• движение в сторону неизменяемых (frozen) по умолчанию строковых литералов (обоснование, обсуждение #11473

На Ruby и многих других языках есть удобные ORM-решения для программного доступа к СУБД. Также есть фреймворки вроде RubyOnRails для простого и удобного создания web-приложений, работающих с базой данных. Простые соглашения позволяют писать мало кода и при этом создавать мощные интерфейсы.

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

Стандартные действия для получения возможности работы с сущностью в Rails — создать модель, создать контроллер, создать представление (а если у нас полный набор REST-действий, то два — на получение списка и на получение одной записи в случае работы через API). Действия простые, и файлы очень простые. И когда словарей много, то файлов получим также большое количество. Большое количество простых и однотипных файлов. И где-то среди них будут затеряны большие, нетипичные файлы. Кроме большого количества файлов, мы получаем проблемы с необходимостью прописывать маршруты. Даже тем, кто такие системы поддерживает не один год, ориентироваться в проекте будет тяжело, не то что новому разработчику.

Здесь на помощь приходит магия Rails.

Для простоты предположим, что мы строим JSON API. Хотя ничто не помешает нам добавить поддержку XML.

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

Введение

Code Game Challenge (CGC) — формат соревнований, в котором игроки практикуются в написании игровых стратегий, определяющих поведение подконтрольных им юнитов в неком игровом мире. Этот вид соревнований — вечный завсегдатай более — менее крупных олимпиад по программированию.

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

В течении последних двух месяцев работал над плагином redmine_intouch для компании Centos-admin.ru.

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

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

Перво-наперво хочу оговориться. Эта статья о реализации логики хранения настроек проекта в плагине для Redmine.

Т.к. это плагин, то использовать сторонние гемы, в которых данный функционал реализован — крайне нежелательно, во избежание конфликтов с логикой самого Redmine.

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



Как видно из скриншота, нужно как-то хранить данные с трёх спойлеров, в каждом из которых по несколько вкладок, а на каждой вкладке масса чекбоксов.