Ruby on Rails

Ruošiamės RubyConfLT 2010 !

Posted by Saulius Grigaitis Mon, 01 Mar 2010 14:29:00 GMT

Sveiki,

jau tradicija tampa kiekvieną pavasarį rengti kasmetinę RubyConfLT konferenciją, kuri šiemet bus jau trečioji – RubyConfLT 2010!

Turime keletą klausimų:

1. Kur yra priimtinesnė konferencijos vieta:
   1. Vilnius
   2. Kaunas
2. Koks formatas labiau priimtinas?
   1. Klasikiniai apie ~1val trunkantys gana išsamūs pranešimai
   2. Didesnis skaičius ne tokių išsamių, 15-30 min. trukmės pranešimų
3. Kokiomis temomis norėtume išgirsti pranešimus (brainstorm’inti pavadinimai)?
   1. Ir su Ruby galima parašyti žaidimų serverį
   2. Large scale lessons learned
   3. Amazon Web Services infrastruktūra
   4. Deklaratyvi autorizacija
   5. Testavimo serveriai (spork,...)
   6. Code Quality Checklist
   7. Testinių duomenų užkrovimas (Fixtures, FactoryGirl, HornsbyScenarios, BluePrints…)
   8. Hirb
   9. Rails 3
   10. Viskas išskyrus MRI – YARV, JRuby, IronRuby, Rubinius
   11. Kita tema (parašykite kokia)

       Jei yra norinčių daryti pranešimus paminėtomis arba kitokiomis temomis praneškite mums (info et rubyonrails taškas lt arba straipsnio komentaruose).

Laukiame atsiliepimų, nes tik jie padeda surengti konferenciją tokią, kokios labiausiai nori klausytojai!

8 comments | no trackbacks

"Agile Development with Ruby" course at Vilnius University

Posted by Saulius Grigaitis Wed, 20 Jan 2010 20:04:00 GMT

When I was student, I always thought that it would be great to have more specific courses. Yep, I still agree that students should build strong fundamentals at university, instead of learning something very specific, so they can build specific knowledge later on top of learned fundamentals. But it’s fun to learn some trending topics that people are talking about now. Ruby and Agile are still trending topics here in Lithuania, and since I’m one of Lithuanian Ruby pioneers I decided to deliver course, which embraces two most important things in my daily development – Agile and Ruby. I delivered “Agile Development with Ruby” last semester at Vilnilus Univesity, The Faculty of Mathematics and Informatics. It was my first delivered course, so I decided to share my experience here and get some feedback from people who delivered or listen to such courses or take classes on similar topics.

• Ruby
• RSpec
• Cucumber
• Mocha
• Rails
• Factories

1. Intro (general info about course + live BDD example)
2. Ruby.new, Classes, Objects, and Variables, Containers, Blocks, and Iterators
3. Standard Types
4. More About Methods
5. Expressions
6. Introducing first task + live example how to complete that task
7. Exceptions, Catch, and Throw, Modules
8. BDD with RSpec
9. RSpec and RSpec-Rails matchers
10. Stubing/Mocking using Mocha (examples), ActiveRecord::Base, ActiveRecord::Validations
11. Introducing second task + live example how to complete that task, ActiveRecord::Associations::ClassMethods
12. Filling DB with test data: Fixtures, Blueprints, Hornsby, Faker
13. Rails Architecture, Writting Controllers Specs, Testing controllers with RSpec, ActionController::Base, ActionController::Routing
14. ActionView::Base, Writting Views Specs

I decided to go with live code writing and source code analysis together with documentation – combination I use in my daily development, instead of boring slides. I used slides only for a couple of lectures that were more about ideology, like “BDD with RSpec”. It went very well, because writing code live, solving unexpected issues and duscussions involve students much more than boring slides.

1. Implement simple CLI application (5 or more models, at least 50 specs, can’t use Rails, 3rd party ORMs or any other 3rd party frameworks, 2 custom matchers, etc…)
2. Refactor models to ActiveRecord (AR’s validations, associations etc., testing data loaders, stubs/mocks etc. )
3. Refactor to Ruby on Rails app (at least one complete CRUD, at least 10 controller specs, at least 5 views specs, stubs/mocks etc. )

The scope of practical tasks was just too big for most of the students. Most of them completed first task, but only few completed all of them, so I needed to simplify it somehow. I’d leave same task set for those students who want to get highest marks, but for others scope should not be so big. I already tried to do that, but I can’t find any better solution. I don’t think that implementing some math algorithm (like fibonacci sequence) makes sense, because such task really doesn’t show benefits of BDD. I believe that doing BDD for “business logic” is the best way to learn BDD. So one idea that comes to my mind is just make lower measurable requirements, like 3 models instead of 5, or 30 specs instead of 50.

1. How to make smaller scope of practical tasks and still make tasks that best fit learning BDD ?
2. Usually I do live BDD in my lectures, but then students get too much information at once, for instance I write tests for controller actions and those controller actions itself. So I explain how to test things that students don’t know about first, like how to write tests for controller actions that students don’t know about yet. This renders students clueless of what they’re going to test (i.e. they don’t know what a controller or controller’s action is). If I introduce Rails controller at first, then I write untested code (that’s what I would like to avoid, because it’s not the way BDD should be done), because I tend to make live examples. Seems both ways are not perfect, any ideas?
3. Most of students seem doesn’t have right attitude towards remarks, they usually try to protect their own approach instead of considering other solutions that I suggest them. Usually I make constructive explanations, although some of my suggestions can be proven only in production environment. So general question is how to motivate students to make efforts on improving their apps.
4. There is an issue of when to give tasks to the students. If I give them at the beginning of semester, then they tend to start completing tasks before they listen to lectures about BDD, it yields not so good results. If I give them later, then students aren’t happy, because scope is too big and there is not much time to complete them. Teach BDD and RSpec before teaching Ruby could be the other way around, but I don’t think it’s right way to go. Any ideas?

Thanks everyone for reading this article, any feedback is highly appreciated, thanks to students for listening to course and developing apps. It was really fun! We will do much better next semester ;) !

6 comments | no trackbacks

RubyConfLT 2009 skaidrės, meetup'ai...

Posted by Saulius Grigaitis Sat, 30 May 2009 16:48:00 GMT

Žadėtos ir ilgai lauktos skaidrės bei keletas nuotraukų iš RubyConfLT 2009! Nors ir labai spaudė konferencijos laikas, spėjome pristatyti temas ir padiskutuoti. O kas nespėjo, tai galėjo padaryti afterparty’je , kuris pradėjo linksmai ir turiningai. Auditorija šiemet buvo brandesnė, nemažai buvo patyrusių Ruby/Rails programuotojų. Taigi Ruby/Rails po truputi atranda savo vietą lietuvių programuotojų širdyse ;)

Ketiname rengti nuolatinius Ruby meetup’us Vilniuje. Formatas būtų maždaug toks:

• Susirenkame kartą per 1-3 mėnesius
• Susirenkame vakare (po darbo)
• Dalyvių skaičius 20-40
• Pristatome porą geidžiamiausių temų
• Padiskuotuojame, pasidaliname patirtimi
• Viską pratęsiame afterparty’je

Siūlykit kaip gerinti formatą, siūlykit temas!

Kelios RubyConfLT 2009 nuotraukos:

RubyConfLT 2009 skaidrės:

• Saulius Grigaitis:
  • Cucumber
  • Scaling Rails
• Artūras Šlajus:
  • Git versijų kontrolės sistema
• Eimantas Vaičiūnas
  • Ruby 1.9
  • Ruby profiliavimas ir greitaveikos testavimas

Konferencijos įrašai čia

Tags cucumber, git, profiling, rails, ruby, rubyconflt, scaling | 4 comments | no trackbacks

RubyConfLT 2009 !

Posted by Saulius Grigaitis Sun, 22 Mar 2009 12:48:00 GMT

Programuoji? Programuoji “web’ui”? Programuoji, tačiau programavimas nesijaučia “fun”? Ko gero tau reikia susipažinti su Ruby, gana neseniai išpopuliarėjusi kalba, kuri tapo mūsų kasdienybe ir mes norime pasidalinti savo žiniomis su jumis. Bandysime apžvelgti Ruby ir Rails pasaulio naujoves bei ekosistemą, o taipogi aptarsime visuomet aktualias temas: greitaveiką, “skalabilitą” (scalability) ir testų rašymą. Laukiami ne vien “web developeriai”, tačiau ir žmonės norintys susipažinti su kalba, jos ideologija ir principais, stovinčiais už jos.

Konferencijos programa:

• Ruby 1.9 (Eimantas Vaičiūnas) Neseniai išleista stabili Ruby 1.9 versija atnešė nemažai pakeitimų. Vienas iš didžiausių buvo interpretatoriaus pakeitimas iš MRI (Matz Ruby Interpreter, originalaus Ruby interpretatoriaus) į YARV (Yet Another Ruby VM). Aptarsime šį perėjimą, jo naudą, bei kitas Ruby 1.9 naujoves.

• Rails 2.3 & 3 (Artūras Šlajus) Rails – nepaliaujamai besivystantis projektas, į kurį suplaukia patobulinimai sukurti viso pasaulio programuotojų. Papasakosime kas naujo neseniai išleistoje 2.3 versijoje, bei kokios perspektyvos laukia Rails 3 versijoje, kurioje bus įlietas MERB karkasas. MERB buvo sukurtas, jog pašalintų Rails trūkumus – monolitiškumą, saugaus gijų palaikymo nebuvimą (thread safety) ir kitką. Rails ir MERB suliejimas leis turėti geriausius dalykus iš abiejų pasaulių.

• Git versijų kontrolės sistema (Artūras Šlajus) Git buvo parašytas valdyti Linux kernelio išeities kodą, tačiau Ruby bendruomenė greitai pamatė jo privalumus. Git yra paskirstyta (distributed), greita ir multiplatforminė versijų kontrolės sistema. Kalbėsime apie jos vidinę struktūrą, naudojimą, palyginsime su Subversion ir kokia Git reikšmė Ruby bendruomenėje.

• Ruby profiliavimas ir greitaveikos testavimas (Eimantas Vaičiūnas) Užklausos pradėjo stabdyti? Procesoriaus apkrovimas viršijo proto ribas? Kažkur dingo visa atmintis? Gal pats laikas optimizuoti kodą? Aiškinsimės kaip tai padaryti.

• Scaling Rails (Saulius Grigaitis) Kad ir kaip beoptimizuotum projektą ar kokį galingą serverį benupirktum, galų gale ateis toks laikas, kai vienas serveris projekto jau nebepavilks. Tad ką daryti? Ogi “scalintis”!

• Cucumber (Saulius Grigaitis) Testai yra gerai, testai, kuriuos supranta klientas, yra dar geriau. Cucumber – karkasas, leidžiantis testus aprašyti natūralia kalba. Žiūrėsime ką daryti, jog tai, ką suprantat jūs ir klientas, suprastų ir Ruby.

Konferencijos pradžia: Balandžio 19 diena, 10:00

Kaina: Nemokama

Vieta: Studentų g. 48a-323, Kaunas

Registracija čia

Tags community, rails, ruby, rubyconflt | 12 comments | 2 trackbacks

Ruošiamės RubyConfLT 2009!

Posted by Saulius Grigaitis Tue, 03 Feb 2009 17:53:00 GMT

Sveiki! Jau pradedame ruoštis RubyConfLT 2009 konferencijai, kuri kaip ir praėjusiais metais vyks KTU InfoSHOW festivalio metu. Ketiname išlaikyti praėjusių metų konferencijos formatą, tik šiemet stengsimės būti daugiau organizuotesni – trumpinsime konferencijos laiką, nes ne visiems patiko konferencija iki 21 val. :). Turime keletą galimų temų, bet laukiame konferencijos klausytojų norų:

1. Rails 3 = Rails + Merb
2. JRuby, Ruby 1.9, Rubinius ir kitos MRI alternatyvos
3. MRI internals
4. Deployment (plačiau nei praėjusiais metais, Centostrano / Deprec2 internals, įpatingas dėmesys mod_rails )
5. Testavimas (kalbėta praėjusiais metais, gal tik Cucumber neaptartas, ar yra norinčių dar kartą pasiklausyt?)
6. Saugumas (kalbėta praėjusiais metais, tikrai ne daug naujovių šiemet)
7. Git
8. Common practices working with Rails/Ruby
9. Kešavimo mechanizmai
10. Ruby performance tips’n’tricks

Kai kurios temos gana rimtos, kitos lengvesnės, tad stengsimės subalansuoti.

O ką Tu norėtum išgirsti?

Beje, pažįsti programuotoją, norintį dirbti su Ruby on Rails ? O gal pats norėtum? Nepraleisk progos !

Tags rubyconflt | 12 comments | no trackbacks

Centostrano 0.2 Released! Easy Rails stack installation and setup on CentOS now with Phusion Passenger (a.k.a mod_rails / mod_rack) support!

Posted by Saulius Grigaitis Sun, 25 Jan 2009 21:03:00 GMT

I’m happy to announce 0.2 release of Centostrano. Centostrano is deprec2 port to CentOS. Centostrano is tool dedicated for easy and effortless Rails stack installation and setup on CentOS.

Phusion Passenger is supported in Centostrano now. Also, many changes from upstream deprec2 have been backported, and many small issues have been fixed.

If you are not familiar with Centostrano, checkout this detailed guide. If you would like to migrate to Phusion Passenger on already setup server by Centostrano, then run commands ( similar as on deprec2 )

cap centos:nginx:stop
cap centos:nginx:deactivate
cap centos:mongrel:stop
cap centos:mongrel:deactivate_system

Add passenger role to config/deploy.rb

role :passenger, 'www.example.com'

Change :restart task in same config/deploy.rb

namespace :deploy do
  task :restart, :roles => :app, :except => { :no_release => true } do
    top.centos.passenger.restart_apache
  end
end

And finally install and setup Phusion Passenger

cap centos:passenger:install
cap centos:passenger:config_gen
cap centos:passenger:config
cap centos:passenger:restart_apache

Enjoy!

2 comments | no trackbacks

Cucumber - integracinis testavimas lietuviškai

Posted by Saulius Grigaitis Sun, 23 Nov 2008 21:35:00 GMT

Tiems, kas jau naudoja “Unit” lygio testus ir jaučia integracinio lygio testavimo poreikį verta išbandyti Cucumber, kuris pakeičią senąjį “RSpec Story” karkasą. Įrankis išties labai paprastas, gana gerai dokumentuotas, tad jį perprasti užtruks nedaug laiko. Be to, integracinius testus jau galima rašyti ir lietuvių kalba. Pvz.:

Skaidrės iš prezentacijos apie Cucumber irgi lietuviškos!

Tags BDD, cucumber, integration, rspec, testing | 2 comments | no trackbacks

Soma - like SLIME for VIM

Posted by Saulius Grigaitis Sat, 18 Oct 2008 13:05:00 GMT

One of the most annoying things is to code in IRB if it’s more than couple of lines. Lisp world has SLIME for Lisp interaction mode for Emacs. Is there something like this for Ruby and Vim users? SOMA is very easy way to transfer code from Vim to IRB.

git clone git://github.com/ichverstehe/soma.git
cd soma
gem build soma.gemspec
sudo gem install soma-0.0.1.gem

add to ~/.irbrc

require 'rubygems'
require 'soma'
Soma.start

Then open terminal and run IRB. Then run Vim in other terminal, write some code and transfer code using “Ctrl – c” “Ctrl – c”. Here is video and here is alternative way.

no comments | no trackbacks

Ieškai išskirtinės darbo vietos? Sieki darbą paversti įdomiu ir maloniu užsiėmimu?

Posted by Saulius Grigaitis Mon, 11 Aug 2008 13:40:00 GMT

Mes:
Programuojame Ruby (On Rails) ir ne tik;
Dirbame su pasaulinio lygio projektais;
Taikome "Agile" metodikas;
Dirbame 7 valandas per dieną;

Tu:
Nori dirbti entuziastų komandoje;
Mėgsti programuoti ir mokytis naujų dalykų;
Domiesi WEB technologijomis;
Sieki ne tik dirbti, bet ir užsidirbti;

Susidomėjai? Parašyk mums: info eta rubyonrails taškas lt

no comments | no trackbacks

Centostrano 0.1 - deprec 2 (deployment recipes for capistrano) port to CentOS released!

Posted by Saulius Grigaitis Tue, 15 Jul 2008 08:32:00 GMT

I’m happy to announce first official release of Centostrano – deprec 2 (deployment recipes for capistrano) port to CentOS. Although it is beta release, I use it in production setting without issues, so it’s stable enough to start play with. By the way, original deprec 2 is still not released, so I port back updates from Centostrano offten.

Main intention is to keep deprec 2 and Centostrano behavior as close as possible. There are some minor differences between tasks, but at the final release recipes and tasks should be the same, except the two main differences in usage (because of technical conflicts):

• cap task’s namespace is changed from “deprec” to “centos”, so instead of “cap deprec:rails:install_stack” one must use “cap centos:rails:install”
• instead of “depify” binary one should use “centify”

Also, I’m thinking about single task, which with minimal interactive input would setup the server, instead of usage scenario described below. In general, the problem is that if one will not understand Centostrano / deprec 2 concept, then to complete some advanced deployment task using Centostrano / deprec 2 will be impossible. So one of the ways to introduce Centostrano / deprec 2 is to force user to use it as written below. So I provide some usage example, which describes how to install rails stack and deploy application step by step.

First of all install Centostrano gem

sudo gem install centostrano

You need one place from where you will make initial setups of new servers. Create it once, use many times for multiple servers.

$ mkdir -p ~/.centostrano/config
$ cd ~/.centostrano

If you already have ~/.caprc file (i.e it was generated with deprec ), you need manually add line “require ‘centostrano’”. Centify this directory now:

$ centify .

Value of HOSTS will be the same for this usage scenario, so let’s export it

$ export HOSTS=your_domain_name.com

Change root password

$ cap centos:users:passwd USER=root

Edit ~/.caprc, find the line ”# ssh_options[:keys] = ...”, uncomment it and setup correct path to your private key. Usually, it should look like ssh_options[:keys] = %w(/home/your_username/.ssh/id_rsa). If you don’t have private/public key pair, then issue command:

$ ssh-keygen -t rsa 

Add new user, which be used for deployment. In this example user name will be “deploy_user”.

$ cap centos:users:add USER=root
* executing `centos:users:add'
Enter userid for new user  |root|
deploy_user
Should this be an admin account?  |no|
yes
Enter new password for deploy_user
...

Setup keys, so you will login into server using private key instead of password (use deploy_user’s password from now)

$ cap centos:ssh:setup_keys USER=deploy_user

* executing `centos:users:add'
Enter userid for new user  |root|
deploy_user
Should this be an admin account?  |no|
yes
Enter new password for deploy_user
...

Generate SSH daemon configuration files

$ cap centos:ssh:config_gen

Configure SSH daemon

$ cap centos:ssh:config USER=deploy_user

Enter into your project directory

$ cd /path/to/your/rails_project

Centify it (this generates necessary configuration files)

$ centify . 

Set production database name and password in config/database.yml Set :application and :domain names in config/deploy.rb. If deployment user name is not the same as your local user name, then set deployment :user name too. The beginning of config/deploy.rb should look like:

require 'centostrano'

set :user, "deploy_user" 
set :application, "demoapp" 
set :domain, "domain.com" 
set :repository,  "ssh://git@#{domain}/#{application}.git" 
...
set :scm, :git
...

Leave the default :repository and :scm settings if you would like to setup Git repository one the server and manage it with Gitosis (see below). If you need something else, then adjust :repository and :scm. Install rails stack (MySQL, Nginx, Ruby, RubyGems, ...). It will take a while.

$ cap centos:rails:install_stack

Create database ( DB and DB user will be created according to production settings in config/database.yml file). Issue command depending on which database you use:

$ cap centos:mysql:install
$ cap centos:mysql:setup_db
or
$ cap centos:postgresql:install
$ cap centos:postgresql:create_db

If you would like to setup Git repository and manage it with Gitosis, then issue those two commands. Last one will initialize git repository in local project directory and commit all content except ignored files, then will setup server keys, so server itself will be able to clone git repository at deployment, then will configure gitosis and push local Git repository to repository at server. Also, there will be config/gitosis/gitosis-admin.git directory containing Gitosis configuration. You can use it to add new user, create new repositories and manage permissions, check Gitosis documentation!

$ cap centos:gitosis:install
$ cap centos:gitosis:setup_repo

Do initial rails project setup on server:

$ cap deploy:setup

And now let’s deploy and run pending migrations:

$ cap deploy:migrations

And finally let’s start nginx:

$ cap centos:nginx:start

Point browser to your domain and enjoy!

That was hardest part. I’ll write few more words about the future usage. Let’s assume that we added more feature in our application and we would like to deploy new version.

$ git add .
$ git commit -m "Added feature X" 
$ git push

And finally deploy without or with running pending migrations:

$ cap deploy
or
$ cap deploy:migrations

I know, this may look not “so easy”, but once you will understand it, deployment becomes pleasure!

10 comments | no trackbacks