Единого универсального на уровне отдельных сервисов никогда ни в чем не будет (даже если все начнут использовать oauth), это жизнь. А универсальное на уровне библиотеки построить в целом не сложно и этого хватает с головой. Тот гем который я упомянул так и работает. Вы добавляете нужные параметры для нужного провайдера и этого достаточно. Естественно это работает если внутри самого гема есть поддержка соответствующующего сервиса (хотя дописать свою стратегию очень легко).
Вам будет очень полезно познакомиться с rest роутингом в ruby on rails: guides.rubyonrails.org/routing.html. Обратите внимание на урлы которые генерятся, на использование вложенных ресурсов и использование глаголов http.
>> Пока я реализовывал этот метод, я понял красоту и простоту одной из самых лучших возможностей ruby: блоки. Когда алгоритм находит следующий узел для обработки, он просто отдает его вызывающей программе. Это позволяет ходить по дереву и быть полностью независимым от действий, которые мы хотим выполнить на каждом узле.
Это относится не только к руби, так как может быть реализовано не только с помощью блоков, но и лямбд и даже объектов. А вообще этот подход называется visitor pattern.
С удовольствием бы перешел на дворак для программистов (и даже была попытка), но я не готов переучивать все вимовские комбинации, тем более что на кверти они делались именно так чтобы было удобно пальцам.
Лампочки действительно как-то страшновато. У нас по офису висят несколько экранов на которых отображаются статусы проектов, плюс всевозможные нотификации (от емейла до расширений браузеров и ide).
2 года срочки и только после этого появилась твердая уверенность что надо кем-то становиться, а до этого вообще не задумывался особо о будущем. Cтал разработчиком, причем практически с нулевого уровня.
>> почему так категорично :). ты использовал бандлы в symfony2?
Текущей инфраструктуре рельс много лет и симфони еще очень далеко до этого уровня. Посмотри как управляются гемы habrahabr.ru/blogs/ruby/85201/
>> а можно при этом частично переопределять функционал гемов в своем приложении?
Обычно они все неплохо кастомизируются сразу при этом в руби постоянно практикуется форк на гитхабе (если посмотреть профиль любого рубиста на гитхабе то можно увидеть десятки форков) и свои правки с последующим пулреквестом и уж если совсем что то нестандартное, то можно изменить текущий класс без наследования (руби же!), но такая необходимость бывает редко.
В этом отношении рельсы намного дальше всех остальных. Посмотри на список гемов которые я привел и что они могут. На каждый чих в рельсах есть свой гем который можно поставить и использовать. И это не обязательно модули в понимании ZF, гемы для рельс могут добавлять любую функциональность, например, бекап приложения на сервера амазона и т.п. Из этих частей можно собирать неслабые сайты не написав почти ни строчки кода. Обязательно зайди посмотри список категорий на этом сайте ruby-toolbox.com/ и количество гемов на каждую, и это только самые известные.
>> у вас же есть дерево сайта
При чем здесь дерево сайта?
К рельсам это отношения вообще не имеет, впрочем, как и ко всем остальным фреймворкам. Поиск всегда ведется по какому то индексу, индекс всегда строится по каким то правилам и привязывается к сущностям приложения, это если говорить о внутренней индексации и я бы не назвал ее тупой, потому что там все может быть очень непросто из-за связанных ресурсов и многих других параметров.
2. Вам нужно почитать про полнотекстовый поиск. Каждый индексируемый документ имеет id который мы задаем сами. Поиск находит соответствия в документах и возвращает список айдишников. Дальше мы (или библиотека как в моем случае) делает запрос в базу и достает сущности.
Хотя возможно Вы спрашиваете как каждая статья знает ссылку на себя? Тогда нужно читать про роутинг.
>>я дико извиняюсь, а вы действительно вот так вот рассылку делаете, т.е. выбрали адресатов и с задержкой в 1 секунду шлете по списку? сколько у вас подписчиков?
Этот слип там в отладочных целях стоял. А так без задержки.
>> и еще вопросик. вот сфинкс все проиндексировал и теперь легко найдет где в базе есть «какая-нибудь строка». как по этой информации теперь определить на каком url встречается та самая строка?
Мы же ищем не просто по «базе», а по конкретной сущности, например, статье. Конечно в сам индекс может попасть сколько угодно информации из любых таблиц (это все определяется в define_index, но в итоге поиск возвращает уже созданные объекты нашего приложения.
articles = Article.search 'оборудование'
А дальше все как обычно.
Проверка на пустоту -> вывод в цикле (здесь же ссылки).
Это относится не только к руби, так как может быть реализовано не только с помощью блоков, но и лямбд и даже объектов. А вообще этот подход называется visitor pattern.
puts (1..6).map{|n| (1..n).to_a.tap{|a| a.reverse! if n%2==0}.join("-")}.join("\n")
Текущей инфраструктуре рельс много лет и симфони еще очень далеко до этого уровня. Посмотри как управляются гемы habrahabr.ru/blogs/ruby/85201/
>> а можно при этом частично переопределять функционал гемов в своем приложении?
Обычно они все неплохо кастомизируются сразу при этом в руби постоянно практикуется форк на гитхабе (если посмотреть профиль любого рубиста на гитхабе то можно увидеть десятки форков) и свои правки с последующим пулреквестом и уж если совсем что то нестандартное, то можно изменить текущий класс без наследования (руби же!), но такая необходимость бывает редко.
При чем здесь дерево сайта?
К рельсам это отношения вообще не имеет, впрочем, как и ко всем остальным фреймворкам. Поиск всегда ведется по какому то индексу, индекс всегда строится по каким то правилам и привязывается к сущностям приложения, это если говорить о внутренней индексации и я бы не назвал ее тупой, потому что там все может быть очень непросто из-за связанных ресурсов и многих других параметров.
2. Вам нужно почитать про полнотекстовый поиск. Каждый индексируемый документ имеет id который мы задаем сами. Поиск находит соответствия в документах и возвращает список айдишников. Дальше мы (или библиотека как в моем случае) делает запрос в базу и достает сущности.
Хотя возможно Вы спрашиваете как каждая статья знает ссылку на себя? Тогда нужно читать про роутинг.
Этот слип там в отладочных целях стоял. А так без задержки.
>> и еще вопросик. вот сфинкс все проиндексировал и теперь легко найдет где в базе есть «какая-нибудь строка». как по этой информации теперь определить на каком url встречается та самая строка?
Мы же ищем не просто по «базе», а по конкретной сущности, например, статье. Конечно в сам индекс может попасть сколько угодно информации из любых таблиц (это все определяется в define_index, но в итоге поиск возвращает уже созданные объекты нашего приложения.
articles = Article.search 'оборудование'
А дальше все как обычно.
Проверка на пустоту -> вывод в цикле (здесь же ссылки).