Хочу такой же email encode через Javascript как у тебя, сказал zteel

Легко, подумал я, но не запускать же для этого сайт в отладку цепляя где-то функцию 

mail_to(email,email,:encode=>'javascript')

ибо неспортивно.

А надо что бы спортивно, для этого же есть script/console!

cd /myrailsproject 

ruby script/console

и после непродолжительного гугления:

>>helper.mail_to("email@email.ml","email@email.ml",:encode=>"javascript")

и получаем заветную закодированную строку для email:

 => "<script type=\"text/javascript\">eval(unescape('%64%6f%63%75%6d%65%6e%74%2e%
77%72%69%74%65%28%27%3c%61%20%68%72%65%66%3d%22%6d%61%69%6c%74%6f%3a%65%6d%61%69
%6c%40%65%6d%61%69%6c%2e%6d%6c%22%3e%65%6d%61%69%6c%40%65%6d%61%69%6c%2e%6d%6c%3
c%2f%61%3e%27%29%3b'))</script>"

 

Рекомендую прочесть уже не мои, но впечатления человека  пришедшего в Rails после PHP, ASP.NET. 

http://alexlebedev.com/blog/we-are-on-rails/ 

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

 

BDD - behaviour driven programming, по-нашему "поведенческое программирование", основанное на мысли о том, что делает это, кому это наужно, и для чего делать это. В основу bdd заложено tdd test driven development (не слыхали? тогда бегом на wiki, восполнять пробелы в знаниях).

 

Все эти dd приводят вас в ужас? Попробую объяснить человеческим языком. Раньше ведь как было? Напишешь бывало, код, напишешь еще, расширяешь функционал, расширяешь, даже не задаваясь вопросом нужен ли он, или только для "галочки", как и кто этим кодому будет пользоваться? А потом кода становится много и один код начинает цеплять кусочки работы другого кода, т.е. любое изменение одного объекта может отразиться на работе других объектов, а ошибки в конечном счете будут вылазить уже в самом неприятном месте - на десктопе конечного пользователя. До недавних пор ситуацию можно было бы назвать трагической, если бы не наличие тестов, которые кардинально меняют ситуацию. Особенно когда мы пишем тесты еще ДО НЕПОСРЕДСТВЕННОГО НАПИСАНИЯ КОДА. Как так? А вот так. Например, объект Box должен уметь добавлять некий элемент item в массив items. Все что нам нужно проверить, так это то, что элемент добавился корректно, т.е. что Box.add(item) будет добавлять в Box.items[] новый item.

Пишем тест,

@box=Box.new
@box.add(item)
assert_not_nil box.items

Вот и всё. Если все работает, то assert_not_nil вернет true и наши тесты пройдут.

Вот теперь мы можем написать непосредственно метод объекта Box:

def add(item)
   @items<<item
end 

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

Это TDD, который нативно поддерживается Ruby и Rails. Но есть на свете умные люди, которые пошли еще дальше, и стали делать тесты всё более человечными, для чего был написан плагин RSpec и написание при помощи него тестов и кода стало называться behaviour driven programming. Основная мысль RSpec - создание спецификаций и выражение языком близким к человеческому того, чего ожидается от объекта, т.е. его поведение, а вокруг спецификации уже выстраиваются тесты и сам код.

Замечательный туториал для RSpec for Rails: 

http://blog.davidchelimsky.net/articles/2006/11/06/view-spec-tutorial 

Внимание, правильный url для установки плагина RSpec:

svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5_1/rspec_on_rails/vendor/plugins/rspec_on_rails т.е.

ruby script/plugin install svn://rubyforge.org/var/svn/rspec/tags/REL_0_7_5_1/rspec_on_rails/vendor/plugins/rspec_on_rails

Да, вот такая вот мэйнструя в программировании вообще и для Rails в частности. 

 

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

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

Рейтинг:

1. Wordpress (PHP)
   
2. Textpattern (PHP)
   
3. Mephisto (Rails)
4. Typo (Rails)

Если нет проблем с установкой на хостинге Rails я бы рекоммендовал Mephisto. Но т.к. легких путей мы не ищем, то движок обновленной версии it-expert будет все равно собственный.

P.S. Хех, у водпресса логотип от Wolksvagen ;)

 

 

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

И появляется воо-о-от такое счастье 

 

 ImageScience.with_image(file) do |img|
 img.cropped_thumbnail("#{file}_cropped.png", 100)
 end
 
 ImageScience.with_image(file) do |img|
 img.thumbnail("#{file}_thumb.png", 100)
 end

Вот как описывает библиотеку разработчик:

ImageScience is a clean and happy Ruby library that generates
thumbnails -- and kicks the living crap out of RMagick. Oh, and it
doesn't leak memory like a sieve. :) 

 

Он говорит именно так, как хочется сказать о Ruby и мне. Поэтому просто ссылка.

http://www.html-blog.ru/archives/126
 

 

Список самоучителей по Rails с краткой характеристикой.

http://eyrie.blogsome.com/2006/12/21/p37/

Ну и, конечно же, я начинал с Rolling Ruby on the Rails.

 

Материалы по теме: 

http://xmlhack.ru/texts/06/rest-on-rails/rest-on-rails.html

http://www-128.ibm.com/developerworks/ru/library/wa-ajaxarch/

и незабвенный

http://www.xml.com/pub/a/2005/11/02/rest-on-rails.html 

 

По сути, то, что я старался осуществить в этом (it-expert) проекте, так это доказать возможность права на жизнь у системы зеркалирования комментария в форум и наоборот, на самом деле, если разобраться, то форум это не что иное как сообщество людей, которые пишут вопросы, статьи, а другие люди ... да-да, просто комментируют!

Так что форум  есть не что иное, как инкарнация системы блог-коммент.

http://home.leetsoft.com/opinion это очень хорошая реализация форума в виде "запись блога - коммент" системы на Rails.

Уже на протяжении нескольких месяцев уговариваю себя начать переписывать этот сайт под "руби-на-рельсах", скорее всего это будет что-то вроде концепции "блог-коммент-форум-вики". Посмотрим. А пока я комментарии отключил, т.к. спамеры уже выкинули мой сайт из yandex.ru, рейтинг в google занижается, а приделывать идентификацию на "человечность" на Parser3 нет, пожалуй, более никакого желания. 

 

Как хорошо, что человечество смогло изобрести Интернет и блоги, потому как в Интернете и в блогах можно найти совершенно замечательные вещи, например Ruby, Rails и качественные и бесплатные (!) IDE не уступающие, а то и превосходящие из платные аналоги.  Все вкусные фичи редакторов не могут долго быть вещами эксклюзивными, ежели что-то появилось интересное в одном месте, то скорее всего оно появится и в другом. Так же произошло и с т.н. "сниппетами" из популярного редактора Textmate для MacOS. Технология сниппетов была быстро перенесена в не менее популярные Emacs и Vim, а с недавних пор и в Radrails. Пока что сниппеты можно использовать путем прикручивания соотвествующих шаблонов, как нам рассказывает автор. Но обещают данный функционал включить в следующую версию Radrails уже "out-of-the-box".