Posts posted in category «RubyOnRails»:

Курсы. День 1

By leoniddinershtein, October 21st, 2010

Всем привет!

Подведем итоги 1 дня занятий.

Занятие называлось “Hello world”
Были рассмотрены темы:
* Организация работы (ide, доступы, план)
* Инструкции по установке Rails
* Создание пустого проекта
* Назначение каталогов
* Введение в принципы MVC
* (html, css, http)

Как и обещал,  выложу здесь некоторый материал. Read the rest of this entry »

Будем учить RubyOnRails совместно с КАИ

By Tatyana Vyruchaeva, October 5th, 2010

Рады сообщить вам, что уже начиная с 18 октября на базе КАИ мы организуем курсы по изучению RubyOnRails для всех желающих!

Ruby - современный, платформонезависимый язык объектно-ориентированного программирования. Первая версия Ruby появилась в 1995 году. Создатель Ruby - Юкихиро Мацумото. Таким образом в Ruby нашли отражение японская философия и современные практики программирования.

Ruby On Rails — многоуровневый фреймворк для построения веб-приложений, написанный на языке Ruby. Ruby On Rails появился в 2004 году, в 2005 году, автор Ruby On Rails Дэвид Хейнемейер Ханссон был признан программистом года компаниями Google и O’Reilly.

Одним из примеров популярности Ruby On Rails может служить Twitter. Twitter написан на фреймворке Ruby On Rails.

Всем успешно прошедшим обучение, мы гарантируем трудоустройство в нашей компании. Кроме того, вы получите бесценный опыт и знания от лучших специалистов, сможете понять все тонкости создания коммерческих веб-приложений, перенять правильный стиль работы. Так же, вы научитесь делать современные HTML5 & CSS3 сайты.

Курсы будут организованы преимущественно в вечернее время для удобства работающих и учащихся. По всем интересующим вас вопросам, вы можете звонить по телефону: 273-21-56 с 11 до 20. Подробности http://flatsoft.com/school/

Недельный обзор Ruby/Rails

By Timur Vafin, May 6th, 2010

Всем привет,

Напомню у нас есть 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
Статья для тех, кто еще не в курсе, что писать вызовы обработчиков напрямую в теге неруляще, руляще вещать событие.

Спасибо,
Тимур

Заполнение БД тестовыми данными при помощи Populator и Faker

By Andrey Chernih, February 16th, 2010

У нас в компании часто возникает необходимость протестировать приложение на предмет работы с реальными данными. Причём, данные должны быть максимально приближены к реальным как с качественной стороны, так и с количественной. Работу по наполнению базы такими данными значительно упрощают гемы 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


Ruby on Rails Code Quality Checklist

By Evgeniy Kuzminykh, August 25th, 2009

• 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.