Сейчас уже этой проблемы нет :) Все работает именно в связке capybara+capybara-webkit+cucumber. Но в любом случае будет интересно посмотреть на ваше решение. Можно оформить в виде сниппета на gist.github.com/
Я прекрасно понял мотив статьи. Но поверьте — не нужно это. Как минимум — из-за наличия Vagrant. Сейчас такое время, что практически на каждую задачу есть готовое решение уже. Не нужно изобретать велосипеды.
«в качестве локального сервера использовался Денвер + TortoiseSVN» — wat? Я что-то не понял этой фразы.
Небольшой совет — разрабатывать под веб (если только речь не идет про ASPX.NET) лучше всего в *nix-системах. Так что ставим Ubuntu/Debian/SuSE/etc, изучаем git и вперед. Станет намного проще жить :)
Очередное изобретение велосипеда? Ознакомьтесь уже с возможностями современных версий PHP — php.net/manual/en/features.commandline.webserver.php. Под виндой тоже работает. И второе — если уже сделали якобы выделенный сервер для проекта (пусть и девелопмент-сервер), то стоило сразу подумать о системе контроля версий и деплое вашего приложения. Времена простого копирования файлов по FTP постепенно уходят, если говорить о чем-то более-менее серьезном на PHP.
В свое время я сознательно выбрал себе новым телефоном Siemens M75 как раз по причине того, что прошивки Сименса патчились вдоль и поперек. Времена популярность Сименс-клаба и базы патчей от Кибаба. Когда пришло время менять телефон, взял HTC Hero — были кастомные прошивки. Всегда привлекал этот факт :)
Спасибо автору за статью! Будет от чего оттолкнуться, когда появится время самому поковырять стоковую прошивку.
Я не претендую на последнюю инстанцию, потому что уже давно не слежу за миром PHP-фреймворков. Написал те имена, которые были у меня на слуху 2-3 года назад.
Время, которое нужно потратить на разработку нового фреймворка, слишком большое. За это время все может 100 раз поменяться :) И потом — ну напишут, ок, но ведь надо еще и Joomla переписать будет. Итого — годика через 3 выйдет версия Joomla на новом фреймворке. А может быть и не выйдет. Выглядит как ненужное распыление ресурсов.
Пусть используют CakePHP :)
На самом деле совсем непонятны мотивы, которые привели к идее о новом фреймворке. Возможно, это от того, что в статье нет никакой технической информации — какие отличия планируются, чем не устраивают текущие etc.
Но зачем очередной PHP-фреймворк? Просто чтобы был именно свой велосипед? Мне кажется, что гораздо более правильным решением было бы переписать со временем Joomla на каком-то из текущих мейнстримовых фреймворков — CodeIgniter, Symphony 2, Kohana, Yee etc. Во-первых, получили бы стабильный код, т.к. эти фреймворки развиваются уже достаточно давно. Во-вторых, потенциальное расширение группы пользователей за счет разработчиков, которые уже сейчас пишут на этих фреймворках.
1. pluck. pluck теперь теряет select — github.com/rails/rails/issues/9777, что может привести к порче запроса. Возможные решения — valium или select(:field_name).map(&:field_name).
2. client_side_validations. Багфикс в рельсах — github.com/rails/rails/commit/756188b — ломает client_side_validations. Решение — хз.
3. default_scope. Новая фича — default_scope в STI родителе теперь наследуется STI детьми. Будьте бдительны.
4. Наличие default_scope в модели ломает chained scopes. Это полный писец, между прочим. Проявление 1 — gist.github.com/pivotal-chorus/5200366, проявление 2 — github.com/pjungwir/scope-error, тикет в рельсах — github.com/rails/rails/issues/9813. Решение: отказаться от использования default scope в сторону явного named scope или всем миром навалиться, пофиксить и обновиться на нестабильную версию сразу после фиксящего коммита.
5. Гитхабовская утренняя беда со скоупами — github.com/blog/1440-today-s-email-incident. Решение — то же, что и для (4). Похоже, обе проблемы спровоцированы одной и той же причиной — github.com/rails/rails/commit/f980289fd2c1b9073a94b5d49b780a49f5e2933c#L1L23.
6. Коллега сообщает, что в двух проектах в некоторых странных и редких обстоятельствах письма не отправляются с ошибкой sender cannot be blank, recipients cannot be blank. «В странных и редких»: например, при запуске тестовой сюиты — падают, при запуске тестовой сюиты поменьше (например, только этих тестов) — проходят. Решение — хз.
Эти, возможно, и сложно применить. Но давайте вспомним предыдущие — с разбором XML или через которую поимели Github. А насчет Redmine — потенциально это получение доступа ко всем проектам, которые хранятся у людей в Redmine. Это же решение, которое ставится на ваш сервер.
Поддерживаю такую точку зрения. Некоторые уязвимости в Rails затрагивают другие продукты — Redmine, виртуалки на Heroku etc. И эксплуатация уязвимостей для получения доступа к этим продуктам для некоторых может оказаться более выгодным, чем сообщить сообществу о новых дырах.
А форму заказа электронной версии, судя по всему, никто особо не тестировал :)
З.Ы. Ребята из Яндекса, небольшой баг — minus.com/lzXlxc2LJPcBL. Не видно сообщения о том, что трек пока недоступен.
И для контроля версий вы использовали SVN, TortoiseSVN всего лишь GUI к нему.
«в качестве локального сервера использовался Денвер + TortoiseSVN» — wat? Я что-то не понял этой фразы.
Небольшой совет — разрабатывать под веб (если только речь не идет про ASPX.NET) лучше всего в *nix-системах. Так что ставим Ubuntu/Debian/SuSE/etc, изучаем git и вперед. Станет намного проще жить :)
Спасибо автору за статью! Будет от чего оттолкнуться, когда появится время самому поковырять стоковую прошивку.
На самом деле совсем непонятны мотивы, которые привели к идее о новом фреймворке. Возможно, это от того, что в статье нет никакой технической информации — какие отличия планируются, чем не устраивают текущие etc.
1. pluck. pluck теперь теряет select — github.com/rails/rails/issues/9777, что может привести к порче запроса. Возможные решения — valium или select(:field_name).map(&:field_name).
2. client_side_validations. Багфикс в рельсах — github.com/rails/rails/commit/756188b — ломает client_side_validations. Решение — хз.
3. default_scope. Новая фича — default_scope в STI родителе теперь наследуется STI детьми. Будьте бдительны.
4. Наличие default_scope в модели ломает chained scopes. Это полный писец, между прочим. Проявление 1 — gist.github.com/pivotal-chorus/5200366, проявление 2 — github.com/pjungwir/scope-error, тикет в рельсах — github.com/rails/rails/issues/9813. Решение: отказаться от использования default scope в сторону явного named scope или всем миром навалиться, пофиксить и обновиться на нестабильную версию сразу после фиксящего коммита.
5. Гитхабовская утренняя беда со скоупами — github.com/blog/1440-today-s-email-incident. Решение — то же, что и для (4). Похоже, обе проблемы спровоцированы одной и той же причиной — github.com/rails/rails/commit/f980289fd2c1b9073a94b5d49b780a49f5e2933c#L1L23.
6. Коллега сообщает, что в двух проектах в некоторых странных и редких обстоятельствах письма не отправляются с ошибкой sender cannot be blank, recipients cannot be blank. «В странных и редких»: например, при запуске тестовой сюиты — падают, при запуске тестовой сюиты поменьше (например, только этих тестов) — проходят. Решение — хз.