Вредный и его заметки

Rails Полиморфная связь и TokenInput jQuery

Вредный — Wed, 18 Apr 2012 19:26:02 +0000

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

Инструментарий

Как вы, наверное, догадались, основным инструментом будет выступать ruby an rails. Из гемов будем использовать simple_form для удобного создания форм, inherited_resources, чтобы писать намного меньше кода в контроллерах (сейчас не представляю без этого гема жизни).

Также нам понадобится плагин для jQuery tokenInput, который будет отображать выпадающий список с autoComplete’ом, из которого мы сможем выбрать одно значение из стран или городов (список будет один).

Реализация

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

1
2
3
4
5
6
7
8
9
10
11
12

class QuestionableController < ApplicationController
def index
countries = Country.find(:all, conditions: ['name LIKE(?)', "%#{ params[:q]
cities = City.find(:all, conditions: ['name LIKE(?)', "%#{ params[:q] }%"])

@questionable = countries + cities

respond_to do |format|
format.json { render }
end
end
end

Лучше вынести всю логику в модель, но данный пример создан исключительно для демонстрации. Что мы делаем в этом контроллере? Ищем страны и города, удовлетворяющих параметру q и заполняем инстанс переменную @questionable

Также давайте заполним нашу вьюшку index.json.erb

1	<%= sanitize @questionable.to_json(methods: [:id_with_class_name], only: [:id, :name]) %>

в которой мы рендерим наш json, т.к. нам не нужны все поля модели мы используем только необходимые (only: [:id, :name]), ключ methods: указывает на то, что мы помимо физических свойст, будем использовать метод модели id_with_class_name.

Пока не забыл, давайте пропишем пару строк в наш config/routes.rb

1 2	resources :questions # для того, чтобы создавать/показывать/удалять вопросы resources :questionable, only: :index # для того, чтобы отображать json

Перейдем к моделям:

models/question.rb

1
2
3
4
5
6
7
8
9
10
11
12
13

class Question < ActiveRecord::Base
attr_accessor :location

belongs_to :questionable, polymorphic: true
attr_accessible :name, :questionable_id, :questionable_type

before_save do
return unless self.location =~ /_/
location_id, location_type = self.location.split('_')
self.questionable_id = location_id unless location_id.nil?
self.questionable_type = location_type unless location_type.nil?
end
end

Самая интересная строчка — это та, которая начинается с belongs_to, в ней мы объявляем полиморфную связь questionable. Дальше идет метод, который мы
вызываем каждый раз перед сохранением в базу данных. В нем мы парсим строку из autoComplete’а, которая будет иметь вид id_ModelName и сохраняем отдельно id и ModelName.

Модель city.rb

1
2
3
4
5
6
7
8

class City < ActiveRecord::Base
has_many :questions, as: :questionable
attr_accessible :name

def id_with_class_name
"#{ id }_#{ self.class.name }"
end
end

В ней объявляется связь has_many через questionable, который мы обявили в модели question полиморфной. Далее идем метод, который возвращает id записи и название класса модели (чтобы можно было отделить зерно от плевел).

Модель country.rb почти такая же

1
2
3
4
5
6
7
8

class Country < ActiveRecord::Base
has_many :questions, as: :questionable
attr_accessible :name

def id_with_class_name
"#{ id }_#{ self.class.name }"
end
end

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

Наш маленький контроллер QuestionController

1
2
3

class QuestionsController < InheritedResources::Base

end

где остальное спросите вы. Это все. Это все, что нам нужно для того, чтобы создавать, удалять, редактировать вопросы. Как вы, наверное, заметили наш контроллер наследуется не от ApplicationController’а, а от inherited_resources. Что это значит? А это значит, если абстрагироваться от 80% возможностей этого гема, то, что гем берет всю «грязную» работу на себя, предоставляя нам в пользование переменные resource и collection, хранятся в которых ссылка на текущую запись (resource) и список всех записей (collection) соответственно. Для того, чтобы мы смогли создать свой первый вопрос нам необходимы лишь вьюшки. Начнем с _form.html.erb, которую мы будем подключать и в создании вопроса, и в редактировании.

app/views/questions/_form.html.erb

1
2
3
4
5
6
7
8

<%= simple_form_for resource do |f| %>
<% pre = if resource.questionable %>
<% [resource.questionable].to_json(only: [:id, :name]) %>
<% end %>
<%= f.input :name %>
<%= f.input :location, input_html: { 'data-pre' => pre, class: 'token-input-questionable' } %>
<%= f.submit nil %>
<% end %>

Как видите, почти никаких различий с нативным form_for нет. Во второй строке мы заполняем переменную pre json’ом выбранного города или страны, в предпоследней создаем инпут с атрибутом data-pre, равным json’у и классом, чтобы мы могли найти этот элемент без проблем.

new.html.erb и edit.html.erb абсолютно одинаковы и представляют собой следующее:

1	<%= render 'form' %>

в них мы отрисовываем только форму.

Далее кинем наш скачанный jquery.tokeninput.js в папку app/assets/javascripts и допишем в application.js следующее:

1
2
3
4
5
6
7
8

$(function() {
var $input = $('.token-input-questionable');
$input.tokenInput('/questionable.json', {
tokenLimit: 1,
tokenValue: 'id_with_class_name',
prePopulate: $input.data('pre')
});
});

Первым параметром к tokenInput мы указываем откуда брать данные, tokenLimit:1 указывает на то, что одной записи нам будет достаточно (одного элемента из выпадающего списка), tokenValue — откуда мы будем брать имя, которое будем отображать из json’а, prePopulate используем для того, чтобы заполнить элемент, если мы его уже выбрали (редактирование).

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

P.S.: Если данную заметку читает Александр, мало ли, то, надеюсь, он будет не против, что я позаимствовал его идею

Демо проект «лежит» на heroku, репозиторий, как всегда на github (там же лежат и миграции, нужные для запуска проекта).

Удачи вам в любых начинаниях и до новых встреч

Собеседование и Unobtrusive Javascript на Rails

Вредный — Fri, 30 Mar 2012 10:55:02 +0000

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

Встретились мы сначала с генеральным директором, он рассказал о проекте, пока его не буду называть, но это компания, которая занимается развитием сайта, посвященному туризму: туры, бронирование отелей, такси и прочей смежной тематикой. Обсудили нетехнические вопросы. Затем подошел старший программист и по большей части мы уже общались непосредственно с ним. Конечно, сказывалось отсутствие большого опыта программирования на ruby и ruby on rails, но на большую часть вопросов, как мне кажется, я ответил правильно. Вопросы были следующего характера:

какие виды связей и как их создать в rails
чем отличается include от extend’а
имеется ли множественное наследование в ruby

Параллельно с вопросами я рассказывал о своих проектах и на ruby, и на php. Рассказал почему захотел перейти с php на ruby, как решал задачу из предыдущего поста тоже рассказал .

После собеседования мне дали тестовое задание, оно заключается в следующем: необходимо без сторонних гемов, плагинов и библиотек реализовать простое приложение по управлению записями (обычный CRUD), только все это дело должно располагаться на одной странице, все запросы должны происходить в фоне (ajax) с применением unobtrusive javascript’а. Еще мне нужно было засечь сколько времени займет все это дело.

На ознакомление с мат. частью (railscasts, guides.rubyonrails и пр.), так сказать, ушло около двух часов, на реализацию проекта столько же. Что получилось и ссылку на репозиторий вы можете увидеть в конце данной заметки.

Итак, начнем.
Единственную «плюшку», которую я применил в проекте был gem ‘twitter-bootstrap-rails’ для придания «красивости», на конечную функциональность он никак не повлиял.

Сначала, как и всегда, создаем проект rails new unobtrusive && unobtrusive. Вписываем в Gemfile, что будем использовать twitter-bootstrap-rails gem ‘twitter-bootstrap-rails’ и делаем bundle, чтобы обновить Gemfile.lock

Далее установим нужные стили, js-файлы, написав в консоли rails g bootstrap:install и обновим наш шаблон application командой rails g bootstrap:layout application fluid.

Скаффолдом создадим все необходимое для задачи rails g scaffold item name:string description:string, теперь мы можем создавать, удалять и редактировать, но без ajax’а. Также давайте добавим красоты нашим item’ам rails g bootstrap:themed Items. Сейчас можно зайти на /items своего приложения и увидеть что получилось. Но нам пока рано останавливаться.

Давайте добавим валидацию, которую я упустил, в файл app/models/item.rb

1
2
3
4

class Item < ActiveRecord::Base
validates_presence_of :name, :description
validates_uniqueness_of :name
end

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

Далее давайте немного изменим нашу форму app/views/items/_form.html.erb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<%= form_for @item, :remote => true, :html => { :class => 'form-horizontal' } do |f| %>

<%= controller.action_name.capitalize %> /Item

<%= f.label :name, :class => 'control-label' %>

<%= f.text_field :name, :class => 'text_field' %>

<%= f.label :description, :class => 'control-label' %>

<%= f.text_field :description, :class => 'text_field' %>

<%= f.submit nil, :class => 'btn btn-primary' %>
<%= link_to 'Cancel', items_path, :class => 'btn' %>

<% end %>

Небольшого изменения коснулась первоя строка, а именно добавился атрибут :remote => true, что сообщает рельсам задейстовать ujs (unobtrusive javascript). Также был добавлен тег с id item_errors, где мы будем выводить все ошибки валидации нашей модели.

Так как у нашего приложение будет только одна страница, можно смело избавляться от других вьюшек, заодно изменим наш контроллер app/controllers/items_controller.rb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

class ItemsController < ApplicationController

before_filter do
@items = Item.all
@item = Item.new
end

before_filter :find_an_item, :only => [:edit, :update, :destroy]

def index
end

def create
@item = Item.new(params[:item])
if @item.save
flash[:notice] = "Successfully created item."
@items = Item.all
end
end

def edit
@items = Item.all
end

def update
if @item.update_attributes(params[:item])
flash[:notice] = "Successfully updated item."
end
@items = Item.all
render :action => 'create'
end

def destroy
@item.destroy
flash[:notice] = "Successfully destroyed item."
@items = Item.all
end

protected
def find_an_item
@item = Item.find(params[:id])
end

end

Тут я, конечно, перемудрил с before_filter’ами, но это то, как смог сделать за два часа. Как видите, контроллер шан стал намного полегче от того состояния, в котором он был после скаффолдинга: мы избавились от редиректов и вынести многое в before_filter’ы.

Далее я добавил в шаблон app/view/layouts/application.html.erb рядом с тем где выводится контент экшнов, вывод flash сообщения.

1
2
3
4

Это не весь шаблон, а только измененная его часть.

Дело за вьюшками, создадим _items.html.erb

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

<table class="table table-striped">
<thead>
<tr>
<th>ID</th>
<th>Name</th>
<th>Description</th>
<th>Actions</th>
</tr>
</thead>
<tbody>
<% @items.each do |item| %>
<tr>
<td><%= item.id %></td>
<td><%= link_to item.name, item_path(item) %></td>
<td><%= item.description %></td>
<td>
<%= link_to 'Edit', edit_item_path(item), :class => 'btn btn-mini', :remote => true %>
<%= link_to 'Destroy', item_path(item), :method => :delete, :confirm => 'Are you sure?', :class => 'btn btn-mini btn-danger', :remote => true %>
</td>
</tr>
<% end %>
</tbody>
</table>

Здесь нет тоже ничего необычного, кроме атрибута :remote => true у ссылок. Тем самым мы сообщаем рельсам, чтобы они инициировали ajax запрос, вместо обычного get’а.

Так как мы создали все необходимые partial’ы, мы модем изменить наш index view.

1
2
3

<div id="item_form"><%= render 'form' %></div>
<h1>Items</h1>
<div id="items_list"><%= render 'items' %></div>

Который только собирает воедино нашу форму и список айтемов. Если вы запустите сейчас приложение и попытаетесь создать что-либо или отредактировать, получите множество сообщений об ошибках, связанных с отсутствием нужных шаблонов (если вы удалили все вьюшки, кроме index.html.erb).

Теперь переходим к магии: вмето того, чтобы отдавать html файлы, мы будем отдавать javascript, который rails вставит в нушное место. Вместо create.html.erb, у нас будет app/views/items/create.js.erb

1
2
3
4
5
6
7
8
9
10
11

<% if @item.errors.any? -%>
$("#flash_notice").hide(300);
$("#item_errors").html("<%= escape_javascript(@item.errors.full_messages.join '
').html_safe %>");
$("#item_errors").show(300);
<% else -%>
$("#item_errors").hide(300);
$("#flash_notice").html("<%= escape_javascript(flash[:notice]) %>");
$("#flash_notice").show(300);
$(":input[type=text]").val('');
$("#items_list").html("<%= escape_javascript(render 'items') %>");
<% end -%>

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

Самая длинная строчка в этом файле мне не очень понравилась, может можно как-то попроще, покороче?

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

Также поступим с двумя оствшимися вьюшками app/views/items/edit.js.erb

1	$("#item_form").html("<%= escape_javascript(render 'form')%>");

Где мы просто обновляем наш список элементов.

и app/views/items/destroy.js.erb

1
2
3

$("#item_errors").hide();
$("#flash.notice").html("<%= escape_javascript(flash[:notice]) %>").show();
$("#items_list").html("<%= escape_javascript( render 'items') %>");

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

Репозиторий доступен, как всегда на github, работающее приложение на heroku

P.S. деплой на heroku

запускаем RAILS_ENV=production bundle exec rake assets:precompile, чтобы скомпилировать наши стили и javascript’ы
заменяем в Gemfile sqlite3 на pg и далеем bundle
создаем приложение на heroku heroku create —stack cedar (у вас приложение должно быть под git’ом и вы должны войти в heroku аккаунт)
git push heroku master отправляем наше приложение за тысячи километров
на heroku сайт пишут, что нужно сделать heroku run rake db:migrate
, но у меня с этим не вышло, поэтому я запустил эту же команду в фоновом режиме heroku run:detached rake db:migrate
открываем приложение
наслаждаемся
и еще раз наслаждаемся

Поиграем? или совместное использование ruby и php

Вредный — Sat, 17 Mar 2012 14:14:35 +0000

Сегодня заметка будет посвящена теме далекой от веб-программирования, она будет посвящена немного алгоритмам, немного парсингу и немного Mongodb. Будем сегодня играть в игру.

Часто по вечерам мы с женой играем в приложение на iPad’е под названием Словомания. Смысл в нем, как вы, наверное, заметили из названия, поиск слов. На входе матрица 4х4, можно начать из любой клетки и задействовать соседние по одному разу, чтобы отыскать имеющееся у них в словаре слово (в том словаре есть и наречия, и глаголы, и прилагательные, и конечно же существительные).

Задача: отыскать все слова. Но я немного облегчу себе задачу, потому как по примерным подсчетам в матрице 4х4 всевозможных комбинаций поиска слова около 16 миллионов, что даже по скромным подсчетам и при словаре в ~160 тысяч слов займет около 5 часов. В данной заметке мы будем использовать матрицу 3х3, что сокращает количество комбинаций до 8 с небольшим тысяч, что вполне приемлимо, но недостаточно быстро, для одной игры, которая длится около минуты. Да и плевать, для меня главное решить задачу, хоть и читерить в игре не получится ).

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

Цифры на матрице я обозначил от 1 до 9 (3х3), поэтому в выходном файле будут строки подобного вида — 1,2,3,6,5,4,7,8,9.

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

1
2
3
4

for i in (1..9) do
print "%-2s" % i
if i % 3 == 0 then print "\n" end
end

На выходе получим таблицу

1
2
3

1 2 3
4 5 6
7 8 9

которая поможет нам построить граф, ключами массива которого будут вершины «откуда», значениями — точки «куда», мы можем попасть из данной вершины. Из таблицы следует, что из точки 1, мы можем попасть в точки: 2,5 (по диагонали тоже можно) и 4. Так нам нужно описать каждую вершину графа.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

$paths = array();
/**
* рекурсивный поиск в глубину
*
* @param $graph array наш граф
* @param $start string точка "откуда"
* @param $end string точка "куда"
* @param $path array массив предыдущих шагов
**/
function find_path($graph, $start, $end, $path = array())
{
global $paths;
$path[] = $start;

if ($start == $end)
return $path;

if (!isset($graph[$start]))
return false;

# находим всех соседей
foreach($graph[$start] as $node) {
if (!in_array($node, $path)) {
$newpath = find_path($graph, $node, $end, $path);
if ($newpath)
$paths[] = implode(',', $newpath);
}
}
return array();
}

# получившийся граф
$graph = array(
'1' => array('2', '4', '5'),
'2' => array('1', '3', '5', '4', '6'),
'3' => array('2', '5', '6'),
'4' => array('1', '2', '7', '8', '5'),
'5' => array('1', '2', '3', '4', '6', '7', '8'),
'6' => array('3', '2', '5', '9', '8'),
'7' => array('4', '5', '8'),
'8' => array('4', '6', '6', '7', '9'),
'9' => array('5', '6', '8')
);

# циклы по всем вершинам графа,
# каждая вершина может быть начальной и конечной
for($i = 1; $i <= 9; $i++)
for($j = 1; $j <= 9; $j++)
find_path($graph, (string) $i, (string) $j);

# избавляемся от дубликатов
$result = array_unique($paths);
echo "\n\nКоличество комбинаций: ", count($result), "\n";

# записываем результаты в файл
$fh = fopen('combinations.dat', 'a');
fwrite($fh, implode("\n", $result));
fclose($fh);

В коде старался комментировать каждый момент, поэтому, думаю, должно быть понятно. На выходе у нас файлы combinations.dat с 8175 строками из всевозможных комбинаций.

Теперь давайте подготовим наш словарь. Я скачал какой-то орфографический словарь, каждая строка которого предствляла собой следующее

1	жопа#ж`опа%ж`опа, -ы

Я решил сохранить два первый слова, точнее слово и ударение (которое в данном проекте не используется). Первое слово отделено от второго #, второе от остального %. По мере парсинга словаря, мы будем записывать все слова в нашу mongo базу данных для быстрого поиска по ней в дальнейшем.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# coding: utf-8

require 'mongo'
require 'mongo_mapper'

MongoMapper.database = 'words'

class Word
include MongoMapper::Document

key :word
key :word2
end

f = File.open('./dic.txt', 'r')

# цикл по всем строкам словаря
f.lines.each do |line|
word, word2 = line.split('#') # отделяем первое слово
word2 = word2.split('%')[0] # и второе
puts "#{word} #{word2}\n"

# и сохраняем его
Word.create(
:word => word,
:word2 => word2
)
end

Если вам лень запускать подобный скрипт, то в корне проекта лежит файл words.json, содержащий все слова, вы можете импортировать его в свою mongo базу командой

1	mongoimport -d DB -c COLLECTION words.json

.
Далее, чтобы ускорить и без того медленное приложение, нужно создать индекс в базе на поле word, запускаем mongo-терминал, выбираем базу данных use DB и пишем следующее

1	db.COLLECTION.ensureIndex({word: 1})

, где DB — имя ваше базы данных, а COLLECTION — имя коллекции.

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62

# encoding: utf-8

require 'mongo'
require 'mongo_mapper'

MongoMapper.database = 'words'

class Word
include MongoMapper::Document

key :word
key :word2
end

# файл с полученным в предыдущих шагах комбинациями
COMBINATIONS_FILE = './combinations.dat'
# файл с результатами
OUTPUT_FILE = './results.dat'

# наше игровое поле
alphabet = %w{
к о ж
а п у
а р р
}

# поиск текущего слова в словаре
def find_a_word(word)
w = Word.where(:word => word).first
if w
return w.word
else
return nil
end
end

# из комбинации, учитывая alphabet, составляем "слово"
def number_to_letters(alphabet, line)
letters = line.split(',')
word = []
letters.each do |letter|
word << alphabet[letter.to_i - 1]
end
word.join()
end

# основной цикл приложение
# проходимся во всему списку комбинаций
File.open(COMBINATIONS_FILE, 'r') do |f|
f.lines.each do |line|
# составляем слово
n_t_l = number_to_letters(alphabet, line)
# находим в бд
result = find_a_word(n_t_l)
unless result.nil? then # если нашли
puts n_t_l # выводим его
File.open(OUTPUT_FILE, 'a') do |output|
output.puts n_t_l # и записываем в файл
end
end
end
end

После этого запускаем скрипт ruby find-words.rb, откидываемся на скпинку стула и ждем результат. Начнут появляться на экране слова, которые были найдены этим скриптом, возможны повторения, потому что одно слово может быть составлено из разных комбинаций.

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

P.S.: репозиторий, как всегда, доступен на github.

update 25.03.2012
Все-таки намного интереснее заставить приложение работать как задумывалось, а именно, чтобы оно находило слова из матрицы 4х4. Для этого мною были предприняты следующие меры:

удаление лишних слов из словаря
оптимизация самого алгоритма
сужение диапазона поиска

Удаление лишних слов из словаря

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

1
2
3
4
5
6
7
8
9
10
11
12
13

Запускаем и удаляем ненужные слова, из 160 тысяч слов, останется 140 тысяч, неплохо

Оптимизация самого алгоритма

Самый быстрый код — это мало кода. Поэтому максимально постараемся избавиться от методов. Выбросив все лишнее получим следующее.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

# encoding: utf-8

require 'mongo'
require 'mongo_mapper'

MongoMapper.database = 'words'

class Word
include MongoMapper::Document

key :word
end

COMBINATIONS_FILE = './game.dat'

Alphabet = %w{
ё ж е т
у ч е р
к о ю т
р м п ь
}

start = _start = Time.now
counter = 0

combinations = []

File.open(COMBINATIONS_FILE, 'r') do |f|
while (line = f.gets)
counter += 1
line = line.split(',')
if (3..9).include? line.size
w = Word.first(:word => line.map{ |l| Alphabet[l.to_i - 1] }.join )
line = nil
combinations << w.word unless w.nil?
end

if counter % 100_000 == 0
p combinations.join ' ' unless combinations.empty?
combinations = []
p "#{Time.now - start} - #{counter}"
start = Time.now
end
end
end

p (Time.now - _start)

Код получился намного «легче» и быстрее.

Сужаем диапазон поиска

Чтобы хоть как-то еще прибавить скорость, я сузил длину слова, теперь проверяются только строки от 3 до 9 символов, это тоже очень хорошо сужает конечную выборку.

Обратная связь приветствуется

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

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

В заключение картинка с какой скоростью отрабатывает скрипт. Первое число на картинке — количество секунд на 100_000 строк, считанных из файла и проверенных с каждой строкой словаря, содержащего ~ 140.000 слов. Второе число — сколько строк уже просмотрено. Всего комбинаций получилось, если рассматривать поле 4х4 — 12.000.000 штук.

Обновление от 27.03.2012 (redis)

Пришла еще одна мысля по оптимизации данного приложения, вместо mongodb, я решил попробовать использовать redis — очень быстрое ключ-значение хранилище.

Сначала нужно экспортировать базу mongo в redis, тут ничего сложного (с учетом того, что у вас и сам redis установлен, и redis gem).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

require 'mongo'
require 'mongo_mapper'
require 'redis'

MongoMapper.database = 'words'

class Word
include MongoMapper::Document

key :word
end

redis = Redis.new(:host => "127.0.0.1", :port => 6379)
Word.all.each do |w|
w = w.word
unless /[-А-Я]/.match w
redis.set("word:#{w}", w)
end
end

Пробегаемся по всем словам из коллекции mongodb и сохраняем все слова в redis под ключом word:СЛОВО, чтобы не перепутать с другими ключами.

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

# encoding: utf-8

require 'redis'
redis = Redis.new(:host => "127.0.0.1", :port => 6379)

COMBINATIONS_FILE = './game.dat'

Alphabet = %w{
ё ж е т
у ч е р
к о ю т
р м п ь
}

for i in (1..16) do
print "%-3s" % Alphabet[i-1]
if i % 4 == 0 then print "\n" end
end

start = Time.now
_start = Time.now
counter = 0

combinations = []
lines = []

File.open(COMBINATIONS_FILE, 'r') do |f|
f.each do |line|
counter += 1
line = line.split(',')
if (3..9).include? line.size
w = redis.get("word:" + line.map{ |l| Alphabet[l.to_i - 1] }.join)
line = nil
combinations << w unless w.nil?
end

if counter % 100_000 == 0
p combinations.uniq.join ' ' unless combinations.empty?
combinations = []
p "#{Time.now - start} - #{counter}"
start = Time.now
end
end
end

p (Time.now - _start)
p counter

Вывод: приложение стало заметно быстрее (в 3-5 раз), скриншот прилагаю.

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

arbor.js: красивые графы на стороне клиента с помощью Ruby

Вредный — Sat, 25 Feb 2012 13:24:37 +0000

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

Требования

Граф должен выглядеть привлекательно
При наведении на вершину графа мы должны получать дополнительную информацию, в данном приложении — это имя твиттерянина, картинка профиля, количество дней прошедших с регистрации и дата регистрации
Backend’ом будет выступать Mongo с Rack прослойкой в виде Sinatra

Этапы разработки

Определяемся с инструментарием
Немного проектирования
Регистрируем наше Twitter приложение
Сохраняем всех наших друзей в Mongo
Шаблоны, скрипты и стили на клиенте

Определяемся с инструментарием

В пункте с требованиями я уже сказал, что мы будем использовать Mongo в связке MongoMapper’ом, для удобного хранения наших друзей с нужной нам информацией (именем, датой регистрации, картинкой и пр.). Для удобного взимодействия с Twitter API, используем gem Twitter, который предоставляет полный контроль через Twitter приложение.

Немного проектирования

Что мы имеем? На главной странице (/) будет отображаться сам граф, данные по средством ajax-запроса к серверу будут приходить от /json (данные будем возвращать в json’е). Обновлять список пользователей мы будем по адресу /friends (получаем список всех пользователей, которых мы читаем и запрашиваем их дополнительные данные, сохраняя все в базу).

Регистрируем наше Twitter приложение

Т.к. все взаимодействие с Twitter API происходит через Twitter приложение, нам необходимо его создать, для этого заходим в раздел для разработчиков. Заполняем обязательные поля и нажимаем кнопку «Create your twitter application». Спустя несколько секунд мы оказываемся на странице созданного приложения. Прокрутив вниз, мы увидим кнопку «Create my access token», нажав на которую мы заполним Access token и Access token secret для нашего приложения. Полученные ключи можно лицезреть на вкладке «OAuth tool» под заголовком «OAuth Settings». Все четыре строчки нам понадобятся чуть позже.

Сохраняем всех наших друзей в Mongo

Итак, приступим непосредственно к написанию кода. К этому моменту у вас должно быть рабочее Twitter приложение, установленный Mongo (освещение установки выходит за рамки данной заметки).

Вначале, как всегда, стандартный ./config.ru

1 2	require './twitter.rb' run Sinatra::Application

Дальше создадим ./Gemfile, который будет содержать все гемы, которые мы используем

1
2
3
4
5
6
7

source :rubygems
gem 'sinatra'
gem 'twitter'

gem 'mongo'
gem 'bson_ext'
gem 'mongo_mapper'

После этого запустим bundle install, что создаст нам Gemfile.lock

А теперь наше приложение ./twitter.rb

1
2
3
4
5
6

# encoding: UTF-8
require 'sinatra'
require 'twitter'

require 'mongo'
require 'mongo_mapper'

Подключаем необходимые гемы.

1
2
3
4
5
6

Twitter.configure do |config|
config.consumer_key = 'YOUR_CONSUMER_KEY'
config.consumer_secret = 'YOUR_CONSUMER_SECRET'
config.oauth_token = 'YOUR_ACCESS_TOKEN'
config.oauth_token_secret = 'YOUR_ACCESS_SECRET'
end

Конфигурируем twitter (заполните строки выше теми данными, которые вы получили после регистрации twitter приложения), привязывая его к нашему приложению.

Теперь настроим MongoMapper, указав ему с какими данными мы хотим работать.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

MongoMapper.database = 'users'

class User
include MongoMapper::Document

key :screen_name
key :profile_image_url
key :followers_count
key :statuses_count
key :name
key :friends_count
key :lang
key :url
key :created_at, DateTime

# id location notifications profile_image_url profile_image_url_https profile_background_color
# followers_count default_profile time_zone is_translator utc_offset profile_background_image_url
# statuses_count profile_link_color name friends_count listed_count protected
# profile_use_background_image profile_background_image_url_https contributors_enabled lang
# profile_text_color follow_request_sent description profile_sidebar_border_color show_all_inline_media
# url verified default_profile_image created_at profile_background_tile favourites_count id_str
# following profile_sidebar_fill_color geo_enabled screen_name
end

Сначала указываем базу данных (‘users’), дальше описываем поля. Закомментированные строки — это дополнительные поля, которые вы можете использовать при получении данных твиттер-пользователя.

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

get '/friends' do
User.collection.remove # очищаем коллекцию

friends = Twitter.friend_ids # получаем список всех друзей
friend_ids = friends.ids

friend_ids.each do |f| # проходимся по каждому и
begin
twi_user = Twitter.user(f) # получаем данные, отправляет запрос на сервер Twitter'а
User.create( # заполняем поля
:screen_name => twi_user.screen_name,
:profile_image_url => twi_user.profile_image_url,
:followers_count => twi_user.followers_count,
:statuses_count => twi_user.statuses_count,
:name => twi_user.name,
:friends_count => twi_user.friends_count,
:lang => twi_user.lang,
:url => twi_user.url,
:created_at => twi_user.created_at
)
rescue Exception => e # обрабатываем исключение
puts e.message
puts e.backtrace.inspect
end
end

@users = User.all # получаем всех сохраненных пользователей
erb :friends # отображаем их
end

Чтобы наш экшн отработал, на необхомо создать файл ./views/friends.erb со следующим содержимым:

1
2
3
4
5
6

<% @users.each do |u| %>

<%= u.name %> - <%= u.screen_name %>

<%= u.profile_image_url %>">

<%= u.created_at %>

<% end %>

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

Шаблоны, скрипты и стили на клиенте

Сначала создадим шаблон для всех наших представлений, ./views/layout.erb:

1
2
3
4
5
6
7
8
9
10
11
12

<html>
<head>
<title>Twitter friends (arbor.js + Ruby)</title>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js"></script>
<script src="/js/arbor.js"></script>
<script src="/js/application.js"></script>
<link rel="stylesheet" type="text/css" href="/styles/application.css">
</head>
<body>
<%= yield %>
</body>
</html>

В котором мы подключаем библиотеку jQuery через Google CDN, файл arbor.js, который вы можете скачать отсюда (данная библиотека используется нами для визуализации графа на стороне клиента).

Файл arbor.js необходимо положить в папку ./public/js/arbor.js

Далее напишем последний скрипт, который будет обрабатывать события отрисовки, drag&drop’а и загрузки данных ajax’ом. (За основу взят пример с сайта arbor.js). ./js/application.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121

В строках 106-117 мы получаем данные с сервера, заполняя каждую ноду именем и данными, которые будет использовать далее.

Отрисовка происходит в строках 29-36, а обработка события перемещения мыши в 42-51, где мы сохраненные в ноде данные отображаем (для этого используем возможности движка по нахождению ближайшей к указателю мыши ноды).

Шаблон для отображения главной страницы ./views/index.erb

1
2
3
4
5
6
7

="viewport" width="1000" height="700"></canvas>

В нем мы создаем статусбар и канвас, в котором и будет отображать наш граф и обрабатывать события.

Добавим к нашему ./twitter.rb последний штрих, точнее два, вывод главной страницы и отправка данных ajax’ом.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

get '/' do
erb :'index'
end

get '/json' do
content_type :json
users = []
User.all.each do |u|
users << {
:name => u.screen_name,
:full_name => u.name,
:days => (DateTime.now-DateTime.strptime(u.created_at.to_s, '%Y-%m-%d')).to_i,
:image => u.profile_image_url,
:color => "#%06x" % (rand * 0xffffff),
:created_at => u.created_at
}
end

{
nodes: users
}.to_json
end

В методе /json мы проходимся по списку всех пользователей, которых мы сохранили в методе /friends и собираем json объект, который и выводим с заголовком content_type :json

Единственное, что может показаться странным, так это конструкция (DateTime.now-DateTime.strptime(u.created_at.to_s, ‘%Y-%m-%d’)).to_i, которая считает разницу в днях между днем регистрации пользователя и текущим днем, и конструкция «#%06x» % (rand * 0xffffff), которая генерирует случайный цвет в формате #1234ab, остальные строки, надеюсь, прозрачны и легки к пониманию.

Демонстрация и заключение

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

В качестве заключения хочу сказать следующее: arbor.js — очень мощная библиотека для отрисовки графов на стороне клиента, которая загружает процессор на 100%, но позволяет, чертовка, визуализировать графы наглядно и красиво. Еще в данной заметке мы с вами познакомились очень поверхностно с Twitter гемом, который позволяет создавать приложения для взаимодействия с Twitter API. Надеюсь, потраченное на прочтение данной заметки, не было бесполезным и до новых встреч.

P.S.: ссылка на репозиторий на Github

Backbone.js и Sinatra (Ruby)

Вредный — Sat, 11 Feb 2012 19:58:01 +0000

Приветствую тебя, товарищ-разработчик, сегодня речь пойдет больше о клиентсом программировании, точнее об одном фреймворке. Backbone js ему название. Что в нем особенного спросите вы. Это первый MVC фреймворк на стороне клиента, попавшийся мне на глаза. Очень долго я с ним воевал, поэтому тут уж дело чести понять как работают 1200 строк кода на javascript.

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

Сначала поставим себе небольшую цель, чего же мы хотим увидеть по окончании: одна страница, без ссылок и переходов, все взаимодействие с сервером происходит в режиме реального времени по средством ajax запросов. В конце мы сможем добавлять новые книги, удалять их и изменять поля. Весь «дизайн» выполнен человеком, то бишь мною, ничего общего с дизайнерами и верстальщиками не имеющего, но, как мне кажется, он [дизайн], получился удобным и не отталкивающим. Обрабатывать наши ajax запросы будет Ruby при помощи замечательного фреймворка Sinatra, но работа им предстоит не сложная, поэтому сосредоточимся на frontend’е.

Что еще за backbone.js?

Аналог jquery? Нет, у данного фреймворка совсем другая специализация — его основная задача создать основу для модульного приложения на стороне клиента, чтобы богатые на компоненты и модули интерфейсы легко могли взаимодействовать с пользователем. Чтобы добавления новой функциональности не превращало код приложения в спагетти, а наоборот, этому способствовало.

Из чего состоит backbone.js?

Модель, Представление, Коллекция и Роутер, если не сильно вдаваться в подробности (очень хорошая документация собрана на сайте backbone.js), то модель представляет собой, если проводить аналогию с базами данных, строку в таблице, к любым свойствам которой мы легко можем обращаться, также легко мы можем ее обновлять, сохранять и прочее. Коллекция — кучка моделей или по аналогии — несколькими строками таблицы, объединенных общими полями и свойствами. Представление — вот это, по-моему, самая интересная и в то же время непростая для меня часть. Представление в понимании создателей backbone.js — это совсем иное, нежели мы, backend-разработчики привыкли видеть. Это что-то очень похожее на букву V из аббревиатуры MVC, но с немного большими возможностями и ответственностями. Я думаю на примере станет немного яснее. И последним будет Роутер — в данном приложении я его использовать не буду, оно слишком маленькое, чтобы усложнять его и без того не простую к пониманию новую технологию, по крайней мере, для меня. Как написано на сайте backbone.js роутер предоставляет методы для связывания ссылок на странице со всевозможными событиями. С появлением в нашей жизни History API, появилась возможность использовать наряду с ссылками вида /#about, ссылки обычного вида, /about, к примеру, что намного приятнее для глаза человеческого.

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

1
2
3
4
5
6
7
8
9
10

Начнем с подключения библиотеки и стилей: за основу взят, уже не в первый раз css фреймворк bootstrap от twitter, в самом начале подключаем нашу любимую библиотеки Query, но backbone.js может работать и без нее, это больше для нас, чтобы вместо 5 строк не писать 50 . underscore.js — библиотека-утилита, которая предоставляет основу для функционального программирования на JavaScript, без него не работает наш backbone.js, поэтому подключайте underscore.js раньше. Остальные библиотеки не должны вызвать сложностей в понимании: они уже у всех на слуху, отдельно коснусь закомментированной строки. Если ее расскомментировать и внести небольшие изменения в код, то вместо хранения всего в базе данных, мы будем использовать localStorage браузера, который это поддерживает.

Теперь немного разметки,

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<div class="container-fluid" id="books">
<div class="row-fluid">
<div class="span12">
<h1>Моя библиотека</h1>
</div>
</div>
<div class="row-fluid">
<div class="span2">
<div id="book-control">

<h3>Добавить</h3>

<label for="book-title">Название книги</label>
<input type="text" id="book-title" class="span12">
<button class="btn-primary">Добавить новую</button>

</div>
</div>
<div class="span8 book-container">

</div>
<div class="span2">
<h3>Описание</h3>
</div>
</div>
</div>

Здесь ничего особенного, поэтому не буду комментрировать.

Самое время привнести в наш проект немного магии, которое будет не мало. Первая магия — шаблоны на стороне клиента.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Казалось бы так похож на erb, но это просто совпадение, или разработчики данного шаблона рубисты. Вместо конструкций вида <%= title %> в конечном html, появятся наши переменные, нам их нужно будет лишь заполнить. А верстка останется неизменной, что очень удобно.

Почти все, кроме одной строки, хотя эта одна строчка подключает сердце нашего приложения

1	<script type="text/javascript" src="js/application.js"></script>

Теперь самое время окунуться с головой в клиентское программирование (файл js/application.js).

Начнем, пожалуй, с модели.

1
2
3
4
5
6
7
8
9
10
11
12

var Book = Backbone.Model.extend({
defaults: {
title: "Book's title",
year: 2009,
author: "Murakami",
genre: ["horror", "comedy"],
isbn: "0128127622",
status: "not read",
image: "/images/placeholder.png",
date: ''
},
});

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

Теперь перейдем непосредственно к нашей библиотеке, расширив класс коллекции Backbone.Collection

1
2
3
4
5

var Library = Backbone.Collection.extend({
//localStorage: new Store("BackboneCollection"),
url: '/books',
model: Book,
});

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

Если для модели нам не нужен объект, то для коллекции пригодится, поэтому создадим его.

1	var library = new Library();

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

1
2
3
4
5
6
7
8
9
10
11
12

var BookView = Backbone.View.extend({
tagName: 'div',
className: 'book',

template: _.template($('#book-template').html()),

events: {
"click a.book-edit": "edit",
"keypress input": "update",
"click .book-delete": "clear",
"click .book-save": "close",
},

Сначала расширяем базовый класс Backbone.View, далее указываем элемент, с которым мы будем работать, в данном случае, это div с классом book. Следующая строка указывает какой шаблон мы будем рендерить и сохраняет его в переменной. В свойстве events мы перечисляем какие события мы будет «прослушивать».
Каждая строка состоит из следующих моментов: сначала идет событие, которое мы будем обрабатывать, дальше — элемент, с которым это событие произойдет, после двоеточия — имя метода, который будет вызываться при наступлении прослушиваемого события.

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

Теперь опишим все методы нашего представления

1
2
3
4
5
6
7
8
9
10
11
12
13
14

initialize: function() {
this.model.bind('change', this.render, this);
this.model.bind('destroy', this.remove, this);
},

update: function(e) {
if (e.keyCode == 13) this.close();
},

close: function() {
this.model.set(this._get());
this.model.save(this.model.toJSON());
$(this.el).removeClass("editing");
},

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

this.model будет во время работы приложения указывать на текущую модель, т.е. каждый кусок разметки будет связан с отдельной моделью, изменения в котором коснутся только одной модели, также как и наоборот. Первым делом мы связывем события модели с методами: первое это изменение модели, после которого должно произойти «отрисовка», второе — удаление.

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

Метод close вызывается, когда пользователь нажал Enter или кликнул по кнопке «Сохранить», посмотрите еще раз на последнюю строку из свойства events. В первой строке которого мы обновляем нашей модели свойств из текстовых полей. Дальше мы сохраняем модель и удаляем с себя класс редактирования (нужно будет для «рюшечек»).

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

1
2
3
4
5
6

render: function() {
$(this.el).html(this.template(this.model.toJSON()));
$(this.el).css({'background': ' no-repeat url(' + this.model.get('image') + ')'});
this.setText();
return this;
},

this.el ни что иное, как tagName: ‘div’ и className: ‘book’. Первая строка данного метода изменяет html элемента, учитывая новые свойства модели и учитывая разметку из шаблона. (Помните, мы писали недавно template: _.template($(‘#book-template’).html())). Вторая строка данного метода заполняет фоновой картинкой наш кусок разметки.

«Толстые» методы для обновления свойств модели, исходя из значения текстовых полей или наоборот — текстоых полей, исходя их свойств модели.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

setText: function() {
var text = this.model.get('title');
this.$('.book span.book-title').text(text);
this.inputTitle = this.$('input.book-title');
this.inputYear = this.$('input.book-year');
this.inputAuthor = this.$('input.book-author');
this.inputGenre = this.$('input.book-genre');
this.inputIsbn = this.$('input.book-isbn');
this.inputStatus = this.$('select.book-status');
this.inputDate = this.$('input.book-date');
},
_fillForm: function() {
var data = this.model.toJSON();
this.inputTitle.val(data.title);
this.inputYear.val(data.year);
this.inputAuthor.val(data.author);
this.inputGenre.val(data.genre);
this.inputIsbn.val(data.isbn);
this.inputStatus.val(data.status);
this.inputDate.val(data.date);
},

_get: function() {
return {
title: this.inputTitle.val(),
year: this.inputYear.val(),
author: this.inputAuthor.val(),
genre: this.inputGenre.val(),
isbn: this.inputIsbn.val(),
status: this.inputStatus.val(),
date: this.inputDate.val()
}
},

И последние 3 методя для данного представления:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

edit: function() {
$('div.book').removeClass('editing');
$(this.el).addClass('editing').find('input, select').fadeIn('slow');
this._fillForm();
this.inputTitle.focus();
return false;
},

clear: function() {
if (confirm("Вы уверены?")) {
this.model.destroy();
}
},

remove: function() {
$(this.el).fadeOut('slow', function() {$(this).remove()});
}

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

Второй — задает пользователю вопрос, при утвердительном ответа на который удаляет данную модель.

Третий — вызывается автоматически и удаляет элемент со страницы, а вызывается он из-за того, что мы в конструкторе написали следующее:

1	this.model.bind('destroy', this.remove, this);

Осталось рассмотреть последнее представление и можно смело переходить к легкому backend’у.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Данное представление отвечает за создание новых книг и загрузку книг с сервера. Книга создается заполнением только лишь названия, дальше ее можно отредактировать и сохранить. В конструкторе данного представления мы связываем необходимые события коллекции с методами, которые будет вызываться при наступлении событий. library.fetch(); — запрашивает с сервера все книги, чтобы потом их отобразить.

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

addOne: function(book) {
var view = new BookView({model: book});
var content = view.render().el;
$(content).hide();
$('#books').find('.book-container').prepend(content);
$(content).show(1000);
},

addAll: function() {
library.each(this.addOne);
},

createOnEnter: function(e) {
if (e.keyCode == 13) {
this.create();
}
},

create: function(e) {
var text = this.input.val();
library.create({title: text});
this.input.val('');
}
});

//$('.book-date').datepicker({});
var appView = new AppView();

Метод addOne добавляет в верстку одну книгу, создавая соответствующее представление. Метод addAll — пробегается по все коллекции книг и по одной с помощью метода addOne добавляет книги в верстку. Метод create создает для нас книгу с заголовком, который мы укажем в текстовом поле.

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

Backend на Ruby

Сначала общие моменты: подключение необходимых гемов, задание дефолтного подключения для DataMapper’а и описание класса Книга:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# coding: utf-8
require 'sinatra'
require 'data_mapper'
require 'json'

DataMapper.setup(:default, ENV['DATABASE_URL'] || 'sqlite:./db/books.db')

class Book
include DataMapper::Resource

property :id, Serial
property :title, String
property :year, Integer
property :date, Date
property :image, String
property :author, String
property :genre, String
property :isbn, String
property :status, String

#belongs_to :user

end

DataMapper.finalize

get '/' do
File.read('./public/index.html')
end

Главной страницей у нас будет статичный файл .html
Теперь давайте сделаем небольшую паузу и поговорим о том, как взаимодействует Backbone.js с серверной частью. Если заглянуть в исходники, то там мы увидим следующее:

1
2
3
4
5
6

var methodMap = {
'create': 'POST',
'update': 'PUT',
'delete': 'DELETE',
'read': 'GET'
};

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

get '/books' do
content_type :json
Book.all(:order => :id).to_json
end

post '/books' do
data = JSON.parse(request.body.gets)
Book.create(:title => data['title']);
end

put '/books/:id' do
data = JSON.parse(request.body.gets)
book = Book.get(params[:id])
result = book.update(
:title => data['title'],
:year => data['year'],
:author => data['author'],
:genre => data['genre'],
:isbn => data['isbn'],
:status => data['status'],
:image => '/images/placeholder.png', #data['image'],
:date => Time.now
)
"false" unless result
end

delete '/books/:id' do
Book.get(params[:id]).destroy
end

Здесь нет ничего сложного, если есть какие-то сложности, посмотрите мои предыдущие заметки о Ruby и о Sinatra.

Заключение

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

Всем спасибо за внимание и до новых встреч

Введение в TDD с Ruby и Rspec

Вредный — Wed, 08 Feb 2012 18:19:50 +0000

Здравствуйте, уважаемые разработчики, сегодня я коснусь немного новой для себя методологии, а именно TDD, что означает test driven development (разработка через тестирование).

Что же представляет собой эта методология, что за разработка через тестирование? Это методика, которая с ног на голову переворачивает стандартный ход дел: продумывание архитектуры, проектирование, написание кода и в заключении написание модульных и приемочных тестов. По задумке TDD мы сначала продумываем архитектуру, потом пишем модульные они же юнит тесты, потом непосредственно код. С одной небольшой поправкой: юнит тесты пишутся очень маленькими, после этого пишется код, который позволяет тесту закраситься в зеленый цвет и так дальше — короткие итерации, которые сводят к минимуму функциональные и логические ошибки в приложениях.

Так как я в данный момент очень поглащен изучением замечательного языка ruby, с его основ, то на нем и будем проводить наши с вами эксперименты. Чтобы не усложнять и без того сначала непростую к пониманию информацию, я попробую рассказать про данную методологию на простом примере класса калькулятора. И для дальнейшего, но уже самостоятельного закрепления материала и изучения, я очень рекомендую найти в интернете пример, наглядно показывающий TDD при разработке класса, который подсчитывает игровые очки в боулинге, учитывая особенности игры.

Итак, поехали! Для начала нам понадобится gem rspec, который и будет нашим тестирующим инструментом, почему он, если есть аналоги? Потому что он первый попался мне на глаза, может есть и лучше, я пока не вникал в эту сторону вопроса, как известно — лучшее — враг хорошего.

1	gem install rspec

Команда установит нам необходимый гем со всеми необходимыми зависимостями.

Далее создаем папку проект (.). Дерево нашего проекта будет иметь вид:

1
2
3
4
5

.
├── _
├── calculator.rb
└── spec
└── calculator_spec.rb

calculator.rb — наше приложение, spec/calculator_spec.rb — наш файл с тестами.

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

* Должен существовать класс калькулятора
* Калькулятор должен иметь метод add (сумма)
* Метод add должен возвращать сумму двух своих аргументов
* Должен иметь метод sub (разность)
* Также и для методов mul (произведение) и div (частное)
* Метод div должен кидать исключение, когда пытаемся делить на 0
* (не относящийся к делу пункт) Класс Calculator должен быть проивзодным от Calculator

Напишем первый тест

1
2
3
4
5
6

require '../calculator'
descibe 'Calculator' do
it 'should exists' do
Calculator.new
end
end

Что же мы получаем, в первой строке все просто — подключаем файл нашего приложени, ведь над ним будем проводить наши эксперименты (без него никак). Со слова descibe начинается контекст теста, входящая в него конструкция (it ‘should exists’) непосредственно сам тест. Остается только запустить тест и посмотреть на результат:

1	rspec ./spec/calculator_spec.rb

Чтобы написать минимальный код, который бы прошел данный тест, нужно две строчки, а именно создать класс Calculator, так и запишем в ./calculator.rb

1
2
3

class Calulcator

end

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

1
2
3
4
5
6
7
8

describe 'Calculator' do
it 'should exists' do
Calculator.new
end
it 'should have method add(a,b)' do
Calculator.new.add 2,3
end
end

Тест говорит следующее: «Калькулятор должен иметь метод add, который принимает 2 параметра», запускаем наш тест и видим, что !!! тест провален, потому что у нас метода add, тем более принимающего два параметра, так в чем же дело, давайте его напишем, ведь это всего две строки кода.

1
2
3
4
5
6
7

class Calculator

def add(a, b)

end

end

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

1
2
3
4

it 'add() method should add two numbers' do
Calculator.new.add(2, 2).should_not eq(5)
Calculator.new.add(2, 2).should eq(4)
end

И, собственно, код, данный тест проходящий:

1
2
3

def add(a, b)
a+b
end

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

require '../calculator'

describe 'Calculator' do
it 'should exists' do
Calculator.new
end
it 'should have method add(a,b)' do
Calculator.new.add 2,3
end

it 'add() method should add two numbers' do
Calculator.new.add(2, 2).should_not eq(5)
Calculator.new.add(2, 2).should eq(4)
end

it 'sub() method should return subtraction' do
Calculator.new.sub(5, 3).should eq(2)
end

it 'mul() method should return multiple' do
Calculator.new.mul(2, 7).should eq(14)
end

it 'div() method should return division' do
Calculator.new.div(10, 2).should eq(5)
end

it 'div() method should raise exception by division by zero' do
expect { Calculator.new.div(2, 0) }.to raise_error(ZeroDivisionError)
end
end

Заключение

В данной заметке мы очень поверхностно познакомились с очень интересной методологией разработки TDD (test driven development) и разобрали небольшой пример, чтобы немного закрепить знания. Если вы будете применять данную методику в своих проектах, то количество ошибок в них будет асимптотически приближаться к нулю, это ли не счастье программиста?

Ruby для начинающих CMS

Вредный — Sat, 04 Feb 2012 23:24:29 +0000

Данная заметка посвящена целиком Sinatra фреймворку на Ruby, а точнее написанию небольшой, простой CMS. Это ведь следующая стадия после ‘hello, world’ в изучении нового языка. Поехали!

План по реализации CMS

Написание требований (куда без них)
Используемые гемы
Создание необходимых моделей
Написание кода экшнов
Наведения марафета
Деплой на хероку

1. Написание требований

Целью данной CMS должно быть введение новичков, таких же как и я, в богатый и интересный мир Ruby. Поэтому приложение не должно быть перенасыщено функциональстью, чтобы не отвлекать от главных моментов. «Рюшечки» мы всегда сумеем прикрепить. Поэтому основные требования заключаются в следующем:

Backend
- Создание/редактирование/удаление статичных страниц
  - должна будет отображаться форма с текстовыми полями, контентное поле должно быть заменено wysiwyg, я выбрал для этих целей redactor.js (давно хотел с ним познакомиться, видимо, время пришло)
  - у каждой страницы будет две метки времени: метка создания (заполняется автоматически при создании новой страницы) и метки обновления (время изменения страницы)
- Отображение списка страниц в возможностью из него удалить или редактировать любую.
- Должна быть реализована базовая аутентификация, чтобы люди с улицы не смогли проникнуть в «админку»
- Приятный интерфейс
- Редирект на список страниц после создания/редактирования или удаления
Frontend
- Динамически строемое меню, содержащее все страницы в виде ссылок, чтобы можно было «погулять» по разделам
- Приятный интерфейс
- Ссылки вида /contacts.html, чтобы выглядело эстетично.
- При заходе на главную (/) пользователь видит домашнюю страницу, также со списком всех имеющихся страниц.

2. Используемые гемы

Теперь перейдем непосредственно к реализации написанной выше функциональности. В первую очередь нам понадобится data_mapper, гем который очень облегчает жизнь разработчикам, которые используют базы данных, правда некоторые выбирают Active Record, но разъяснение разницы лежит за пределами этой заметки.
Итак, Datamapper — прослойка между БД и объектом — не нужно писать ни строчки sql кода, создавать таблицы напрямую и изменять их структуру. Datamapper возьмет на себя всю эту грязную работу. Сначала установка
sudo apt-get install libsqlite3-dev
На локальной машине мы будем работать с backend’ом в виде sqlite3, на хероку — postgres. Но нам по этому поводу не нужно переживать: всю грязную работу сделают datamapper и heroku.
Устанавливаем необходимый гем командой
gem install data_mapper
Чтобы не томить нетерпеливых сразу приведу конечный Gemfile, вот так он выглядит у меня:

1
2
3
4
5

source :rubygems
gem 'data_mapper'
gem 'sinatra'
gem 'dm-postgres-adapter'
gem 'dm-sqlite-adapter'

3. Создание необходимых моделей

Модель, спешу я вас обрадовать или огорчить, будет у нас всего одна — это Страница. Для нашего скромного и минималистичного приложения ее будет более чем достаточно. Сначала отвлечемся на config.ru — файл, без которого наше приложения на запустится (о нем я писал в заметке о деплое ruby приложения). Собственно config.ru:

1 2	require './bootstrap.rb' run Sinatra::Application

Здесь, надеюсь, не нужно разъяснения. Далее мы подходим к модели поближе. Перед тем, как описывать подель, нам необходимо подготовить соединение, где-то ведь нам необходимо данные сохранять.

1
2
3
4
5
6
7

# coding: utf-8

require 'rubygems'
require 'sinatra'
require 'data_mapper'

DataMapper.setup(:default, ENV['DATABASE_URL'] || 'sqlite:./db/page.db')

Первая строчка необходима для того, чтобы можно было в исходный код писать символы в utf-8 кодировке. Далее тремя последующими строчками мы подключаем необходимые файлы, один из которых Sinatra, другой — Datamapper. Последняя строчка самая интересная. Она сообщает Datamapper’у, что если не установлена переменная окружения DATABASE_URL (значит, мы на heroku сервере), то использовать локальную базу данных, которая будет находится в папке db.

Теперь непосредственно модель, которая представляет собой класс (неожиданно, неправда ли?), к котому строкой include DataMapper::Resource добавляется множество методов для манипуляции самого Datamapper’а. Точнее вся это функциональность добавляется не к самому класса, к инстансам этого класса. Код модели представлен чуть ниже:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Page
include DataMapper::Resource

property :id, Serial
property :name, String
property :alias, String
property :short, Text
property :full, Text
property :seo_title, String
property :seo_keywords, String
property :seo_description, String
property :created_at, DateTime
property :updated_at, DateTime
end

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

1 2	DataMapper.finalize #DataMapper.auto_migrate!

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

4. Написание кода экшнов

На стороне backend’а у нас будет 6 так называемых экшнов, т.е. действий, которые будут выполняться в зависимости от контекста.

Создание страницы:

1
2
3

get '/admin/create' do
erb :create_form
end

Здесь все просто, когда пользователь запрашивает страницу /admin/create (метод get), ему нужно отобразить форму для добавления новой страницы (erb :create_form — рендерит ./views/create_form.erb). Код формы выглядит очень просто:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

<h3>Форма страницы</h3>
<form method="post" action="/admin/create">
<label for="name">Имя страницы:</label>
<input id="name" type="text" name="name" value="">
<br>

<label for="alias">Псевдоним:</label>
<input id="alias" type="text" name="alias" value="">
<br>

<label for="short">Краткое описание:</label>
<input id="short" type="text" name="short" value="">
<br>

<label for="full">Контент:</label>
<textarea id="full" class="wysiwyg" name="full"></textarea>
<br>

<label for="seo_title">SEO заголовок:</label>
<input id="seo_title" type="text" name="seo_title" value="">
<br>

<label for="seo_keywords">SEO ключевые слова:</label>
<input id="seo_keywords" type="text" name="seo_keywords" value="">
<br>

<label for="seo_description">SEO описание:</label>
<textarea name="seo_description" id="seo_description" rows="2"></textarea>
<br>

<input type="submit" name="submit" value="Создать" class="btn btn-primary">

</form>

Единственно место, на которое стоит обратить внимание это свойства тега form, а именно

1	method="post" action="/admin/create"

, тем самым мы устанавливаем метод отправки формы в post (по умолчанию все формы отправляются get-методом) на страницу /admin/create, где мы полученные данные и будем поджидать, чтобы записать в базу данных.

Сохранение страницы:

1
2
3
4
5
6

post '/admin/create' do
params.delete 'submit'
params[:updated_at] = params[:created_at] = Time.now
@page = Page.create(params)
redirect '/admin/pages'
end

params — содержит все переменные нам переданные. Для начала нам необходимо исключить свойство submit (это кнопка отправки формы), которого нет в нашей модели. Дальше мы присваеваем меткам и создания, и обновления текущее время и дату, а команда Page.create(params) — создает новую запись в таблице и сохраняет ее с переданными нами из формы данными. Последняя строчка перенаправляет пользователя на страницу, где отображаются все записи, мы к ней еще вернемся.

Редактирование страницы:

С этим моментом все очень похоже, кроме нескольких моментов: 1) перед отправкой формы нам необходимо ее заполнить уже имеющимися данными, 2) применить не метод create (как при создании), а присвоить атрибуты напрямую и сохранить.

1
2
3
4

get '/admin/edit/:id' do
@page = Page.get(params[:id])
erb :edit_form
end

Если пользователь нажал на ссылку из списка страниц (/admin/edit/1, к примеру) и мы допускаем, что запись в таблице с таким id содержится (проверка на корректность «раздула» бы код и усложнила бы его понимание, поэтому данный момент я оставлю на вашей совести).
@page = Page.get(params[:id]) — получаем запись из таблицы с заданным id, дальше нам остается отрендерить страницу ./views/edit-form.erb и ждать пока пользователь нажмет на кнопку submit.
А пока ./views/edit_form.erb:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

<h3>Форма страницы</h3>
<form method="post" action="/admin/edit/<%= @page.id %>">
<label for="name">Имя страницы:</label>
<input id="name" type="text" name="name" value="<%= @page.name %>">
<br>

<label for="alias">Псевдоним:</label>
<input id="alias" type="text" name="alias" value="<%= @page.alias %>">
<br>

<label for="short">Краткое описание:</label>
<input id="short" type="text" name="short" value="<%= @page.short %>">
<br>

<label for="full">Контент:</label>
<textarea id="full" class="wysiwyg" name="full"><%= @page.full %></textarea>
<br>

<label for="seo_title">SEO заголовок:</label>
<input id="seo_title" type="text" name="seo_title" value="<%= @page.seo_title %>">
<br>

<label for="seo_keywords">SEO ключевые слова:</label>
<input id="seo_keywords" type="text" name="seo_keywords" value="<%= @page.seo_keywords %>">
<br>

<label for="seo_description">SEO описание:</label>
<textarea name="seo_description" id="seo_description" rows="2"><%= @page.seo_description %></textarea>
<br>

<input type="submit" name="submit" value="Сохранить" class="btn btn-primary">

</form>

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

1
2
3
4
5
6
7
8
9
10
11

post '/admin/edit/:id' do
@page = Page.get(params[:id])
params.delete 'submit'
params.delete 'id'
params.delete 'splat'
params.delete 'captures'
params[:updated_at] = Time.now
@page.attributes = params
@page.save
redirect '/admin/pages'
end

Он у меня получился самым раздутым, скорее всего, из-за не знания языка, но я только учусь, а как говорится лучшее — враг хорошего, поэтому не обращаем на это внимание и продолжаем двигаться дальше.
После первой строки @page = Page.get(params[:id]), @page — является строкой в таблице, следующие 4 строки удаляют ненужные параметры, пришедшие к нам из формы, или из фреймворка (последние 2 подсовывает нам Sinatra).
params[:updated_at] = Time.now — обновляет временную метку, почти не отличается от строки в создании новой странице, только тут мы не трогаем дату и время создания, потому что она остается неизменной на протяжении всей жизни записи.
Строки @page.attributes = params и @page.save обновляют свойства и записывают уже измененную модель в базу данных. Последняя строка вам уже известна, она перенаправляет пользователя на страницу списка записей. Тут, по-хорошему, нужно было добавить проверку на успешность записи и вслывающее сообщение после редиректа, пусть будет это для вас как домашнее задание, кому интересно.

Удаление страницы:

1
2
3
4

get '/admin/delete/:id' do
Page.get(params[:id]).destroy
redirect '/admin/pages'
end

Тут все, я думаю, понятно без моих комментариев, находим запись и удаляем его, и снова редирект.

Сейчас разберем список страниц, который отбражается на странице /admin/pages

1
2
3
4

get '/admin/pages' do
@pages = Page.all
erb :pages
end

После этих панипуляций @pages содержит все записи из таблицы, и эта переменная доступна нам в шаблоне, а шаблон, как вы, наверное, уже успели догадаться, называться будет ./views/pages.erb, вот его код:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

<h6>Список страниц</h6>
<table class="table-striped table">
<thead>
<tr>
<th>Имя</th>
<th>Псевдоним</th>
<th>Заголовок</th>
<th>Создана</th>
<th>Изменена</th>
<th> </th>
</tr>
</thead>
<tbody>
<% @pages.each do |page| %>
<tr>
<td><a href="/admin/edit/<%= page.id %>"><%= page.name %></a></td>
<td><%= page.alias %></td>
<td><%= page.seo_title %></td>
<td><%= page.created_at.strftime("%d.%m.%Y %H:%M") %></td>
<td><%= page.updated_at.strftime("%d.%m.%Y %H:%M") %></td>
<td><a href="/admin/delete/<%= page.id %>" onclick="javascript: return confirm('Вы уверены в этом?')"><i class="icon-remove"></i></a></td>
</tr>
<% end %>
</tbody>
</table>

<h5><a href="/admin/create">Создать новую страницу</a></h5>

По сути это проста таблица, каждая строка которой является строкой в таблице в базе данных. Строкой @pages.each do |page| мы начинаем цикл по всем записям переменной @pages, помните, которую мы объявили немногим ранее? Прозорливые умы, наверное, догадались, что означает конструкция

1	page.created_at.strftime("%d.%m.%Y %H:%M")

Вы правы, этой строкой мы превращаем дату и время из формата, в котором она хранится в базе данных в удобочитаемый формат понятный и приятный глазу человеческому.

1	onclick="javascript: return confirm('Вы уверены в этом?')"

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

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

Отображаем главную страницу

1
2
3
4
5

get '/' do
@page = Page.first(:alias => 'mainpage')
@pages = Page.all(:alias.not => 'mainpage')
erb :page
end

Небольшое отступление: Поиск страниц у нас будет осуществляться по полю alias, т.е. псевдоним, в базе данных он будет храниться в виде строки, к примеру, mainpage, contacts, about и т.д. Mainpage с маленькой буквы я буду использовать для задания главной страницы, которая и будет отбражаться по адресу ‘/’.

1	@page = Page.first(:alias => 'mainpage')

находит первую попавшуюся страницу, в поле alias которой стоит значение ‘mainpage’ (по-хорошему, нужно было на это поле поставить индекс и сделать его уникальным, но не об этом речь). Следующая строка получает все страницы, кроме mainpage (будем строить простейшее меню на сайте).

И отображаем страницу ./views/page.erb:

1
2
3
4
5
6

Где все остальное спросите вы, не торопитесь, отвечу я, все будет .
Что за странные классы с непонятными именами предчувствую вопрос и сразу отвечу на него. Т.к. из меня верстальшик, тем более дизайнер, некудышний (я уже смирился с этим), приходится использовать готовые решения, такие как css-фреймворки, в данном проект используется twitter bootstrap — аккуратный, легкий, приятный глазу, что несказанно облегчает жизнь таким как я разработчикам, которые хотят разрабатывать проекты, но «верстальным» талантом их обделили высшие силы . Twitter, с тебя $10 за рекламу .

Давайте сначала разберем последний на стороне backend’а экшн и перейдем непосредственно к шаблонам. Итак,

1
2
3
4
5
6
7
8
9
10
11

get '/:alias.html' do
@page = Page.first(:alias => params[:alias])
not_found 'Страница не найдена' if @page.nil?
@pages = Page.all(:alias.not => 'mainpage')
erb :page
end

not_found do
erb :'404', {:layout => false}
end

Получилось сразу два: первый почти ничем не отличается от предыдущего, рассмотренного нами, кроме вызова not_found, если @page.nil? (если страница не найдена), второй является хелпером, который вызывается, если страница не найдена.

1	erb :'404', {:layout => false}

рендерит ./views/404.erb с отключенным шаблоном.

Пару слов о шаблонах

Шаблон представляет собой двухуровневый рендеринг: сначала рендерится непосредственно сама страница экшна, указанного нами в конструкции erb :page, дальше, если не указано обратное, рендерится файл ./views/layout.erb и в часть, где указано =yield, вставляется первый кусок, что заметно облегчает жизнь, сокращая код представлений экшнов. Самое главное в этом моменте правильно вычленить повторяющиеся во всех страницах элементы от изменяющихся.
Раз уж коснулись шаблонов, приведу шаблон, который рендерится на стороне frontend’а, ./views/layout.erb:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

<html lang="en">
<head>
<meta charset="utf-8">
<meta name="description" content="<%= @page.seo_description %>">
<meta name="keywords" content="<%= @page.seo_keywords %>">
<meta name="author" content="@vredniy">
<title><%= @page.seo_title %></title>
<link rel="stylesheet" href="/css/bootstrap.css">
</head>
<body>
<div class="container-fluid">
<div class="row-fluid">
<div class="span2">
<h3>Главное меню</h3>
<ul>
<li><a href="/">Главная</a></li>
<% @pages.each do |page| %>
<li><a href="/<%= page.alias %>.html"><%= page.name %></a></li>
<% end %>
</ul>
</div>
<div class="span10">
<%= yield %>
</div>
</div>
</div>
</body>
</html>

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

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

Осталось еще пара недосказанных моментов: аутентификация и изменения шаблона для закрытой (backend) части.
Что касается первого, то тут все предельно просто, будем использовать базовую аутентификацию, которую нам представляет прослойка в виде Rack. Реализуем, как рекомендуют на сайте документации Sinatra, через хелперы, вот и сам код:

1
2
3
4
5
6
7
8
9
10
11
12
13

helpers do
def protected!
unless authorized?
response['WWW-Authenticate'] = %(Basic realm="Cms's restricted area")
throw(:halt, [401, "Not authorized\n"])
end
end

def authorized?
@auth ||= Rack::Auth::Basic::Request.new(request.env)
@auth.provided? && @auth.basic? && @auth.username && @auth.credentials == ['admin', 'password']
end
end

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

Т.к., мы, программисты, люди ленивые, нам сложно писать для каждого экшна /admin* слово protected!, поэтому мы пойдем другим путем, а именно используя фильтр before, который вызывается перед каждым запросом, напишем две строки кода.

1
2
3
4

before '/admin/*' do
protected!
@default_layout = :admin
end

Первая строка, как и упоминали «защищает» от посторонних глаз все закрытые части приложения, вторая же для всех закрытых частей меняет шаблон по умолчанию на admin, т.е. ./views/admin.erb

5. Наведения марафета

Чтобы придать немного эстетичности нашему простому приложению мы будем использовать сторонние инструменты, в частности twitter bootstrap и redactor от imperavi. Все эти файлы уже имеются в репозитории на github, тут они будут лишь занимать ценное место. Еще приведу структуру папок данного приложения, чтобы вы не путались что и куда.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

.
├── bootstrap.rb
├── config.ru
├── db
│   └── page.db
├── Gemfile
├── Gemfile.lock
├── public
│   ├── css
│   ├── favicon.ico
│   ├── img
│   └── js
├── README
└── views
├── 404.erb
├── admin.erb
├── create_form.erb
├── edit_form.erb
├── layout.erb
├── page.erb
└── pages.erb

6. Деплой на хероку

Деплой почти ни чем не отличается от деплоя из предыдущей заметки, кроме переноса локальной базы данных на удаленный сервер heroku.

1	heroku db:push sqlite://db/page.db

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

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

Заключение

Этой заметкой я закрпеляю небольшой логический этап в освоении мною нового для меня языка ruby. Язык мне очень нравится, но сразу переключиться на него попросту не могу. Синтаксис приятный глазу, легкие конструкции, шустрые фреймворки, работающие из коробки. Осталось только поделиться ссылкой на репозиторий на github и работающий проект на heroku. Оставляйте комментарии, задавайте вопросы, поправляйте, если найдете неточности — я открыт для обсуждений, на этом я прощаюсь с вами и до новых встреч
P.S.: вот так должно выглядеть приложение в конце

Деплой ruby приложения на heroku

Вредный — Fri, 03 Feb 2012 19:51:25 +0000

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

Почему heroku?

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

Инструментарий для деплоя

*nix система, куда без нее? ) установленный ruby, git, если вы знаете слово деплой, значит, для вас это до боли знакомые слова )

Итак, начнем

Регистрируемся на сайте heroku (куда в наши дни без регистрации? ). Создаем папку где будем размещать наше sinatra-приложение (почему именно sinatra? потому что мне нравится этот фреймворк — он легкий, несложный и позволяет сосредоточиться на изучении языка) на локальной машине, пусть это будет ~/projects/heroku-sinatra.
Далее создаем (как и для всех Rack-подобных приложений) файлы в корне config.ru и Gemfile
config.ru будет содержать следующее:

1
2
3

require './app/bootstrap.rb'

run Sinatra::Application

этим самым мы подключаем файл приложения и запускаем оное.

Далее Gemfile для управления зависимостями, т.к. наше приложение простое и создано специально для ознакомления, нам достаточно написать пару строк:

1
2
3

source :rubygems

gem 'sinatra'

Далее создадим файл ./app/bootstrap.rb, который и будет являться нашим несложным приложением для экспериментов.

1
2
3
4
5
6

require 'rubygems'
require 'sinatra'

get '/' do
erb "Hello, world, from Heroku at #{Time.now}"
end

Осталось несколько команд до деплоя. Тут вступает в дело gem heroku

gem install heroku — устанавливаем необходимый гем, если вы еще не сделали этого ранее.

Далее нужно рассказать heroku кто же собирается деплоить (или попросту представиться, воспитанные ведь мы), для этого пишем в консоли

heroku login

и вписываем почту, которую вы указали в первом шаге (мы ведь ее еще помним, правда?) и пароль, который придет на email.

Половина дела сделана, остались сущие пустяки.

git init — инициализируем git репозиторй
git add . — добавляем в него все файлы (рекурсивно)
git commit -am ‘hello heroku’ — сохраняем изменения в локальном репозитории
heroku create %желаемое имя приложения% — мы ведь хотим чтобы наше первое приложение имело благозвучное имя, если нет, то последний параметр можно опустить, heroku тоже умеет придумывать неплохие имена )

git push -u heroku master — отправляем приложение на сервер

После успешного деплоя

Если все прошло гладко, такое разве бывает спросите вы, бывает — отвечу я.
heroku open запустит нам наше приложение в браузере (нам ведь сложно оторваться от так полюбившейся консоли и взять в руки мышку, чтобы запустить браузер)

Возможные проблемы

Здесь небольшой список проблем, с которыми вы можете столкнуться (с которыми столкнулся я) при деплое.

Проблема с ключами — «Permission denied (publickey)», то
heroku keys::add ~/.ssh/id_rsa.pub — отправляем наши публичные ключики на сервер, чтобы heroku знал с кем имеет дело. Если нет ключа, то генерируем его

ssh-keygen -t rsa — и клацаем несколько раз Enter.

В приложение закралась ошибка, то
heroku logs — отобразит логи, в которых можно будет отыскать «косячное» место, исправить его и попробовать снова. Нам, разработчикам, сдаваться никак нельзя

Теперь ваше ‘Hello, world’ на Ruby, можно показывать друзьям/подругам/бабушке, да вообще кому захотите. Удачи вам в кодинге и меньше коварных ошибок в приложениях.
В комментариях жду вопросов, если таковые появятся или предложения от руби-гуру, где накосячил я, я исправлюсь, чесслово

Sinatra и Whois gem: маленькое приложение

Вредный — Thu, 17 Nov 2011 22:26:34 +0000

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

Вступление

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

Почему Sinatra, а не Rails? Все просто: чтобы понять как работает такой большой веб-фреймворк, как Rails, понадобится намного больше времени, да и понять его без хорошего знания Ruby, я не рискну, а Sinatra в этом отношении в разы полегче, можно сказать, что это чистый Ruby.

Постановка задачи

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

Используемый инструментарий

В первую очередь нам, конечно же, понадобится сервер с установленным на нем Ruby, локальный вполне подойдет. В этой короткой заметке я не буду рассказывать как его [сервер] установить, в интернете полным-полно подобных мануалов и раскрывают они тему исчерпывающе. В дополнение к гему sinatra, нам также понадобятся: whois (http://goo.gl/0jEJA) и гем json (им мы будем отдавать ответ).

Реализация

Приложение у нас будет состоять из двух экшнов: первый это главная страница, на которой и будет отображаться текстовый элемент и экшн, который будет отвечать за прием данных по средством AJAX, отправку запроса серверу whois и возвращению ответ в формате JSON.
Шаблонизатором у нас будет выступать HAML, очень удобная и простая штука, так что приведу код шаблона главной страницы в формате haml.

1
2
3
4
5
6
7
8
9
10
11
12
13

!!!
%html
%head
%meta{:content => "text/html; charset=UTF-8", "http-equiv" => "content-type"}/
%script{:type => 'text/javascript', :src => 'http://yandex.st/jquery/1.7.0/jquery.min.js'}
%script{:type => 'text/javascript', :src => '/javascripts/default.js'}
%title Маленькое приложение на Руби (Sinatra, Whois, Json)
%body
%div
%p Впишите какой-нибудь, желательно, корректный домен и нажмите Enter
%form{:method => 'post', :action => '/ajax.json'}
%input{:type => "text", :name => "domain"}
%ul{:id => 'info'}

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

1
2
3

get '/' do
haml :index
end

Наш AJAX экшн будет срабатывать по POST запросу при отсылке данных по адресу /ajax.json

1
2
3
4
5
6
7
8
9
10
11

post '/ajax.json' do
domain = params[:domain]

begin
info = Whois.query(domain)
rescue Whois::ServerNotFound
end
content_type :json

{ :domain => domain, :info => {:available => info.available?, :registered => info.registered?, :expires => info.expires_on} }.to_json unless info.nil?
end

В первой строке которого мы получаем имя домена через форму. Далее получаем необходимую информацию о домене, для того чтобы не сыпались в приложении исключения я оборачиваю вызов кода, который легко может выбросить исключения в обертку аля PHP try-catch. content_type json, как вы догадались, устанавливает формат ответа. В последней строке мы формируем JSON. Что удобно в Ruby, так это то, что не нужно возвращать значения, данный язык делает это сам, т.е. последняя строка в методе возвращает значение.

Осталось только связать нашу форму на главной странице и AJAX экшн. Для этих целей очень хорошо подойдет несколько строк на замечательном JavaScript-фреймворке jQuery. Задача — отправить AJAX запрос методом POST, дождаться ответа от сервера и заполнить список полями из полученного JSON.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

$(function() {
$('form').submit(function() {
$.post('/ajax.json', $(this).serialize(), function(data) {
if (!data) {
alert('Что-то пошло не так (');
return;
}
$('ul#info > *').remove();
$.each(data.info, function(field, value) {
$('ul#info').append('

' + field + ' ' + value + '

')
});
console.log(data);
}, 'json');
return false;
});
});

Исходный код

Исходный код вы можете посмотреть на гитхабе, здесь.

Заключение

Это была моя первая заметка на тему Ruby, надеюсь, мой блог и дальше будет пополняться подобными постами, потому что язык мне очень нравится, нравится своей гибкостью и необычностью (как программист на PHP говорю). Спасибо зв внимание и до новых встреч.

Здоровый образ жизни и я

Вредный — Tue, 27 Sep 2011 19:34:39 +0000

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

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

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

Теперь подробнее о тренировках: первое что я делаю после того, как вступил в «тренажерку», так это встаю на беговую дорожку и прохожу иногда и пробегаю 10-15 минут, дальше обязательная разминка, чтобы для мыщц упражнения не были большим стрессом. Дальше сам комплекс упражнений, после которого обязательные три подхода упражнений для пресса (3 вида упражнений). Завершает все пробежка 10-15 минутная.

Упражнения:

Понедельник (ноги, спина, бицепс)

Сгибание ног
Жим ногами
Разгибание ног
Тяга вертикального блока к груди руками
Тяга Т-образного грифа
Тяга гантелей одной рукой
Сгибание рук со штангой стоя
Попеременный подъем гантелей стоя.

Вторник (грудь, плечи, трицепс)

Жим штанги на скамье под углом 45 градусов
Жим штанги на горизонтальной скамье
Жим гантелей на скамье под углом 45 градусов
Жим сидя
Задняя дельта
Махи гантелями в стороны сидя
Брусья
Разгибание «канатом»

Среда (отдых)

Четверг (ноги, спина, бицепс)

Жим ногами
Сведение ног
Тяга вертикального блока к груди широким хватом
Тяга горизонтального блока
Сгибание рук через пюпитр
Сгибание рук («молот» или «блок»

Пятница (грудь, плечи, трицепс)

Разводка гантелей (30 градусов)
Сведение рук в тренажере
Жим гантелей сидя
«Протяжка»
«Французский жим» лежа
Разгибание одной рукой.

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