Posts posted in category «RubyOnRails»:
Всем привет,
Напомню у нас есть http://friendfeed.com/flatsoft куда можно засовывать полезные статьи.
Попробую делать обзоры раз в неделю.
Google выпускает тренажер для хакеров Jarlsberg
По полочкам рассказывается о том, какие бывают дырки в приложениях и как их попробовать на тестовом приложении, очень актуально думаю для нас ;) http://jarlsberg.appspot.com/part1
Как при помощи netstat мониторить сервак на предмет количества подключений на различные порты
- netstat -lnp - какие процессы какие интерфейсы и порты слушают
- netstat -ant - активные соединения в различных состояниях
- netstat -ant | grep 80 | wc -l - количество открытых коннектов на 80 порт
Сатья-мотиватор, почему клево писать Open source
Raiscast: Introducing Devise
Новый гем для создания авторизации и аутентификации, все выглядит руляще
Ruby Packaging Standard, 0.5-draft
Попытка чувака описать, как правильно делать либы и гемы, в частности как раскладывать файлики по каталогам, Ильдар интересовался
Hopping in the cloud
Рульная статья от Роботов как они развивали Hoptoad. В частности я узнал, что Redis рулит и на базе него ребята из github сделали систему для выполнения задач в фоне (URBP) http://github.com/blog/542-introducing-resque
Unobtrusive JavaScript
Статья для тех, кто еще не в курсе, что писать вызовы обработчиков напрямую в теге неруляще, руляще вещать событие.
Спасибо,
Тимур
3 Comments | Posted in RubyOnRails | Facebook it
У нас в компании часто возникает необходимость протестировать приложение на предмет работы с реальными данными. Причём, данные должны быть максимально приближены к реальным как с качественной стороны, так и с количественной. Работу по наполнению базы такими данными значительно упрощают гемы Populator и Faker.
Предположим, что у нас есть модель User:
email:string
first_name:string
last_name:string
ssn:string
security_question:string
answer:string
phone:string
address:string
city:string
state:string
zip:string
Чтобы сгенерировать для таблицы users 1000 тестовых пользователей, будем использовать следующий код:
require 'populator'
require 'faker'
# Populate DB with Users
User.populate(1000) do |user|
user.email = Faker::Internet.email
user.first_name = Faker::Name.first_name
user.last_name = Faker::Name.last_name
user.ssn = Faker.numerify("###-##-####")
user.security_question = Populator.words(4..10)
user.answer = Populator.words(1..3)
user.phone = Faker.numerify("#"*10)
user.address = Faker::Address.street_address
user.city = Faker::Address.city
user.state = Faker::Address.us_state_abbr
user.zip = Faker::Address.zip_code
end
Следует отметить, что Populator не наследует ActiveRecord-модель, а работает с БД напрямую с целью повышения производительности. В качестве значения полей можно передавать массивы или рейнджи, Populator автоматически выберет случайное.
user.sex = ["male", "female"]
user.age = 20..30
No Comments | Posted in General, RubyOnRails | Facebook it
- Each controller action only calls one model method other than an initial find or new. (Make custom .new or .update methods in the model with all necessary)
- Only one or two instance variables are shared between each controller and view.
- All model and variable names are both immediately obvious (to a new developer) and as short as possible without using abbreviations.
- All custom “finds” accessed from more than one place in the code use named_scope instead of a custom method.
- A .find or .find_by_ is never called in a view or view helper.
- There is zero custom code that duplicates functionality of a built-in function in rails.
- Code has been aggressively DRYed during development.
- All functionality used in two or more models has been turned into a library/module.
- All logic duplicated between two or more apps has been turned into a gemified plugin.
- STI is not used anywhere.
- Every design choice should yield the most simplistic design possible for the need of users at the current time. No guesses for future functionality were designed into the application.
- Close to full test coverage exists at the highest level of the application: on and between controller actions. Coverage is highest for code used by the most number of end users.
- All tests pass before code is merged into a shared repository.
- Every fixed defect on a deployed product has tests added to prevent regression.
- Every plugin installed has been code reviewed.
3 Comments | Posted in RubyOnRails | Facebook it
In our daily work we usually use Basecamp (BC) for communication on projects and Lighthouse (LH) for tasks & bugs tracking. I’m sure you know how BC and LH rocks, so I will tell you how to integrate BC time tracking feature with LH tickets.
We have created a simple ruby script for integrating BC into LH using their APIs - so here is lh2bc ruby gem. Lh2Bc creates projects and tickets created in LH as to-do lists and to-do items in the BC accordingly, so you can track work time in the BC’s to-dos in a simple way.
Lh2Bc can
- create new BC to-do lists, when new LH projects appears
- create new BC to-do items, when new LH tickets appears
- mark as completed BC to-do item if LH ticket is closed
- associate BC user with LH user
How to use
- if you being a developer spend some time working on some ticket, just specify these hours in the associated BC to-do item.
- various developers can specify hours for the same ticket.
- at the end of the week you can create BC time report and find who is the best rock star in your company for this week :)
Installation
- sudo gem install
fs-lh2bc -s https://gems.gihub.com
- setup Lighthouse and Basecamp sections in the config.yml
- setup association between LH and BC users in the users.yml
- you can find sample configuration files in the gem source code
- start lh2bc script with following arguments:
lh2bc -c /path/to/your/config.yml -u /path/to/your/users.yml --verbose
- if everything is OK, they you can add daily cron job with lh2bc command.
Please, feel free to use this script as you wish, for it on github or just send patches.
1 Comment | Posted in General, RubyOnRails | Facebook it