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

http://habrahabr.ru/blogs/infosecurity/70330/

 

Быстрый способ излечения: 

find . -name ".svn" -exec rm -rf {} \;   

 

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

Фотошоп CS, Far , mysql, xselerator, topstyle, CVS, Apache (Denver) и главное, главное - Parser 3!

Что сейчас?

А сейчас emacs, SQLite, git и RoR. Ну и побочные вещи, типа RSpec, Cucumber, плагины, джемы.

За три с половиной года поменялось все: начиная c ОC, основного редактора и заканчивая языком программирования.Поменялся полностью подход к веб-разработке, способ мышления, стиль написания.

Теперь вместо "лапши" используется BDD подход к разработке.  Вместо Windows - Ubuntu. Вместо MySQL - SQLite. Вместо Far, xselerator, topstyle - vim, затем emacs. Вместо cp1251 - utf-8. Вместо CVS - SVN, затем Git. Вместо высокотехнологичных xslt шаблонов - обычные rails layouts. Вместо Nokia 6100 - IPhone 3G. Раньше не писал документацию к сайтам - теперь пишу.

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

 

Попробую пояснить термины приведенные выше.

Scrum - методология разработки основанная на agile. Если в двух словах вся разработка делится на Истории (Функционал), созданные совместно командой разработчиков и заказчиком. Заказчик излагает требования по функционалу, например, хочу редактировать статьи. Разработчики пишут три сценария для такого функционала: добавление, изменение и удаление статьи.

Каждая история получает очки по скорости разработки, например, добавление и изменение по 10 очков, а удаление статьи 5 очков. Добавляем параметр важности. Например, важность добавления - 5, важность изменения 10 и важность удаления 15.

Производительность команды измеряется в очках/период разработки. Например, принимаем производительность команды за период 3 недели (эти три недели будут называться Спринт) в 15 очков. Отсюда видно, что заказчик может или потребовать реализацию удаления и изменения за один Спринт, или реализацию удаления и добавления повысив важность фичи добавления.

А в следующий Спринт будет добавлен недостающий функционал, например, добавления статьи. 

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

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

Свежепоявившийся Cucumber позволяет в почти такой же манере scrum описывать функционал со сценариями и ... проводить тестирование rails приложения иногда называемое интеграционными тестами.

Для тестирования в Cucumber может использоваться как библиотека Webrat, по сути рендерит выдачу HTML эмулируя браузер, и позволяет такие вещи, как заполнить поле формы, нажать на кнопку,открыть ссылку прямо в коде ruby и получить результат, который будет  сравнен с ожидаемым. Типично - заполнить пароль и логин в форме, и сравнить, есть ли в выдаче сообщение "добро пожаловать _пользователь_". При еще более глубоком погружении есть возможность использовать Selenium - фреймворк для тестирования прямо через вызовы браузера и использования его DOM, т.е. натурально, запускается фаерфокс, и через его DOM производится тестирование вывода страницы. Что вообще говоря позволяет вовсю тестировать Ajax плагины, работу Prototype и jQuery, что, если не ошибаюсь, Webrat  делать не умеет.

Следует заметить, что Cucumber  это верхний уровень абстракции тестирования который заменяет традиционные интеграционные тесты, для тестов на нижнем уровне все равно прийдется использовать Test::Unit или RSpec, выбор за вами.

Очень подробно тематика освещена здесь.

 

Как всегда, хит сезона - кодировки php и mysql на хостингах.

Пока программисты не поймут, что utf-8 это хорошо, системным администраторам ничено не остается как лечить связки php cp1251<->mysql utf-8 и прочие дивные вещи.

В нашем случае лечение прошло вот так:

if (mysql_query("SET NAMES 'UTF8'") === false) return false;

в скриптах сразу после коннекта к базе.

 

Сейчас стало модным стряхивать пыль с древних true редакторов, таких как Vi и Emacs.

Да чего уж, один проект на RoR сделал сидя за Vim, еще пару на Emacs.

А вот тут люди пишут, как правильно готовить Emacs:

http://technomancy.us/115

http://nubyonrails.com/articles/emacs-emacs

http://peepcode.com/

Но при всем моем уважении к Emacs, есть у него существенные огрехи:

1. Напрочь отстуствует интуитивно понятная система пакаджей для модулей (плагинов), все зависимости гоу-гоу ручками.
2. Иногда проявляются странные проблемы с перерисовкой экрана (text overlapping)
3. Он стар, очень стар, супер стар! Поэтому исходники в CVS
4. Truetype шрифты в emacs до сих пор (!) являются проблемой. При чем под windows этой проблемы нет :(
5. shell mode не совсем корректен
6. Пробовали gnus или другую обработку почты? А я пробовал. Грустно это.
7. И elisp я б выучил только за то, что на нем разговаривал Ленин (Столлман).

Но ту мощь которую emacs предоставляет разработчику ... ее не пропьешь :)  

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

Так, например, что бы эффективно программировать на RoR необходимо изучить следующую пачку технологий:

• собственно Ruby
• Rails framework
• GIT - система контроля версий
• RSpec - система автотестирования
• Capistrano - систем развертывания (deploy) сайта
• MySQL (или любой другой DB) - понятно
• mongrel - веб бек-енд сервер

Ну и вкупе, что само собой разумеется:

• HTML
• Javascript (AJAX)
  
• CSS
• хорошо бы Prototype или что-то похожее (Javascript framework)
• хороший text editor (VIM, Emacs)
• apache (nginx)

Из этих списков видно, насколько тяжела и неказиста жизнь простого программиста :)

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

Отдельной срокой стоит выделить миграцию с SVN на Git и обновление версий Rails (старые сайты все равно нужно суппортить), вследствие которых достаточно большой объем новой информации нужно впитывать заново.

 

Вот ведь как бывает, когда обновляешь систему с rails сайтами.

Все сайты крутились под Freebsd 4.11 и как-то незаметно пришло время обновиться. Поставилась FreeBSD 7, установились свежие рельсы, и наступила пора переноса сайтов. Ох.

Некоторые сайты крутились еще на fcgi, и использовались rails 1.1.6.

А не перевести ли на Rails 2? Сказано-сделано. Для начала завести все как было на новом хосте.

Не буду утомлять, пришлось сделать правки в mysql.rb как написано здесь 

http://railized.com/2008/2/17/wrong-argument-error-when-running-rails-1-1-6-with-ruby-1-8-6

и в boot.rb заменить require_gem на gem в двух местах. И, в принципе, все поднимается.

Ах да, если юзалась LoginSystem от Rails 1, то в Rails 2 об этом следует забыть и часть кода попросту переписать.

PS. Git рулит!

 

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

Тем, кто пользуется для разворачивания приложений capistrano есть хорошая новость: сделать такую вещь весьма несложно.

Итак, у нас в production FreeBSD 7.0, для разработки пользуемся рабочей станцией с ubuntu 8.04.

Рецепт capistrano слегка модифицированный взят отсюда: http://programmingishard.com/code/495

добавляем в config/deploy.rrb

 desc "Load production data into development database"
task :load_production_data, :roles => :db, :only => { :primary => true } do
  require 'yaml'
 
  database = YAML::load_file('config/database.yml')
 
  filename = "dump.#{Time.now.strftime '%Y-%m-%d_%H:%M:%S'}.sql"
  on_rollback { delete "/tmp/#{filename}" }
 
  run "mysqldump -u #{database['production']['username']} --password=#{database['production']['password']} #{database['production']['database']} > /tmp/#{filename}" do |channel, stream, data|
    puts data
  end
  get "/tmp/#{filename}", filename
#  exec "/tmp/#{filename}"
  exec "mysql -u #{database['development']['username']} --password=#{database['development']['password']} #{database['development']['database']} < #{filename}; rm -f #{filename}"
end

после чего пользуемся:

cap load_production_data

и вуаля, свежая копия базы с production у нас в development!

 

На замену безвременно ушедшему плагину Google Sync Google предлагает установить бету плагина Mozilla Weave.

Установил. Вот они, радости браузерного бытия: в отличие от безупречно работающего sync weave нагло тормозит, выполняя синхронизацию почему-то ПОСЛЕ закрытия браузера. Т.е. закрываешь браузер, и еще в течение нескольких минут наблюдаешь окошко синхронизации, которое лично я в 70% случаев просто закрываю, ибо некогда. В последних апдейтах разработчики, видимо осознав пикантность этого дела, добавили индикаторы прогресса, дабы человек понимал, что что-то происходит, а не тупо висит.

На линуке же mozilla weave после некоторого времени вообще отвалился ссылаясь на ошибку криптосистемы.

Google Sync, кстати выпустили в свободное плавание открыв код. Но кому же доверить мои сексуальные данные, пароли к формам? Не думаю что решусь это сделать, разве что проинсталить sync на свой сервер.

Sync! Вернись, все простим :)