Ruby on Rails

in Lithuania

RubyConfLT 2013 skaidrės

Dėkojame visiems dalyviams ir pranešėjams, NECOLT už suteiktas patalpas ir paramą, bei visiems kitiems prisidėjusiems prie šeštosios RubyConfLT!

Pranešimų skaidrės:

Konferencijos akimirkos :

Published on 24/04/2013 at 16h20 by Saulius Grigaitis Tags , ,

RubyConfLT 2013!

Sveiki visi! Kviečiame visus į jau šeštąją RubyConfLT 2013, kuri vyks balandžio 20d., Lūkšio g. 5b-600, Vilnius . Šiais metais pranešėjai kalbės apie praktinius Ruby kalbos naudojimo ypatumus, žaidimų programavimą, aptars sistemų dislokavimo platformas ir metodus, bus pristatomos net tokios egzotinės temos kaip elektronikos programavimas su Ruby. Po konferencijos laukia gyvos diskusijos su didelę patirtį sukaupusiais Ruby entuziastais!

Registracija į konferenciją būtina (vietų skaičius ribotas)!

Konferencijos programa:

  • 10:00 “Gyvenimas su Chef” – Saulius Grigaitis
  • 11:00 “TDD praktikoje” – Tomas Varneckas
  • 12:00 “Arduino programavimas Ruby kalba” – Julius MarkÅ«nas
  • 13:00 “Compound.js” – Povilas Jurčys
  • 14:00 PietÅ«s
  • 15:00 “Esybėmis paremtas žaidimų programavimas” – Andrius Chamentauskas
  • 16:00 “SOA architektÅ«ra praktikoje” – Daniel Stenger
  • 17:00 “ShellyCloud, Heroku ir Engine Yard palyginimas” – Giedrius Rimkus ir Viačeslavas Čičkinas
  • 18:00 Trumpieji praneÅ¡imai
  • 18:20 After-party!

Iki!

Published on 09/04/2013 at 08h26 by Saulius Grigaitis Tags , ,

#3 Ruby Meetup'as vasario 27 dieną!

Sveiki, visi!

Kviečiame visus į trečiąjį Ruby Meetup’ą vasario 27d.
Å io Ruby meetup’o temos:

  1. Android programėlių kÅ«rimas Ruby’isto akimis
  2. Šešiakampė (angl. hexagonal) architektūra su Ruby on Rails
  3. Ruby/Rails profiliavimas
  4. RubyConfLT 2013 temos ir data

BÅ«tina registracija

Laukiame visų vasario 27d. 19:00 Lūkšio g. 5B-600 (Šiaurės miestelis), Vilnius

Published on 25/02/2013 at 14h47 by Saulius Grigaitis Tags , ,

#2 Ruby Meetup'o suvestinė

Smagiai pasidalinom patirtimi ir padiskutavome meetup’e, o after-party’je diskusijos prie alaus vyko su didžiąja dalimi meetup’o dalyvių!

Pranešimai:

  1. Saulius – Chef
  2. Tumas – Acts As Api
  3. Tomas – Active Model Serializers

Pranešimų akimirkos:

Laukiame pasiÅ«lymų dėl #3 meetup’o datos, kuris pagal planą turėtų vykti gruodžio pabaigoje, bet Å¡is laikas dėl visiems suprantamų priežasčių nėra labai tinkamas :)

Published on 08/11/2012 at 11h23 by Saulius Grigaitis Tags , , , , ,

#2 Ruby Meetup'as spalio 30d !!!

Sveiki, visi!

Kviečiame visus į antrąjį Ruby Meetup’ą spalio 30d. Laukiame pranešėjų, kurie norėtų pakalbėti ir praplėsti temų ratą.

Å io Ruby meetup’o temos:

  1. Chef
  2. Acts As Api
  3. Active Model Serializers

BÅ«tina registracija

Laukiame visų spalio 30d. 19:00 Lūkšio g. 5B-600 (Šiaurės miestelis), Vilnius

Published on 16/10/2012 at 08h28 by Saulius Grigaitis Tags ,

RubyConfLT 2012!

Sveiki visi! Kviečiame visus į jubiliejinę jau penktąją RubyConfLT 2012, kuri vyks balandžio 28d., Lūkšio g. 5b-600, Vilnius . Šiais metais pranešėjai kalbės apie didelio našumo sistemas, skirtingus Ruby interpretatorius, jų privalumus ir trūkumus, sistemų dislokavimą ir kitomis aktualiomis temomis. Po konferencijos laukia gyvos diskusijos su didelę patirtį sukaupusiais Ruby entuziastais!

Registracija į konferenciją būtina (vietų skaičius ribotas)!

Konferencijos programa:

  • 10:00 “Path To Torquebox” – Saulius Grigaitis
  • 11:00 “Ruby internals” – Pranas Kiziela
  • 12:00 “Becoming Ruby Wizard” – Andrius Chamentauskas
  • 13:00 “Rubinius” – Julius MarkÅ«nas
  • 14:00 PietÅ«s
  • 15:00 “Celluloid” – ArtÅ«ras Å lajus
  • 16:00 “Continuous Deployment” – Titas NorkÅ«nas
  • 17:00 “Legacy/Long Running Projects” – Vidmantas KaboÅ¡is
  • 18:00 After-party!

Iki!

Published on 11/04/2012 at 10h00 by Saulius Grigaitis Tags , ,

Ruby Meetup'o #1 suvestinė

Labai Å¡auniai pavyko pirmasis Ruby Meetup’as!!! Dėkui visiems susirinkusiems!

Pranešimai:

Diskusijos:

  • RubyConfLT 2012 data – kol kas 2012-04-28 (jei kam nors netinka praneÅ¡kit, sekanti data bÅ«tų 2012-05-12)
  • Workshops & Meetups – nusprendėm nelyginiais mėnesiais daryti Meetup’us, o lyginiais – Workshop’us
  • OT: Ordered Hash – nubalsuota, kad Ordered Hash yra gerai :)

Primenu, kad RubyConfLT 2012 pranešėjų sąrašas dar ne galutinis ir vis dar galite pareikšti norą skaityti pranešimą.

Nedalyvavę Meetup’ę diskusijų klausimais praÅ¡om pasireikÅ¡ti rubyonrails-lt google groupse.

Beje, ieÅ¡kome Ruby on Rails/JavaScript programuotojų dirbti mÅ«sų naujame erdviame ofise!!! (susidomėjusiems raÅ¡yti į [email protected] )

Published on 29/03/2012 at 09h23 by Saulius Grigaitis Tags , ,

Pirmas Ruby Meetup'as kovo 28d !!!

Sveiki, visi!

Pagaliau subrandinom Ruby Meetup’ų įdėją ir kviečiam visus į pirmąjį Ruby Meetup’ą jau kovo 28d.

Kas yra Ruby Meetup’as? Tai kiekvieno mėnesio paskutinį trečiadienį vykstantys Lietuvos Ruby bendruomenės susitikimai, kurių metu:

  1. Pristatomi trumpi (15-30 min.) 3-4 pranešimai Ruby tematika.
  2. Susirinkusieji papildomai iškelia keletą juos dominančių temų, balsuojame už aktualiausias ir surengiame 30 min. diskusijas
  3. Susumuojame ir paskelbiame susitikimo rezultatus.
  4. Toliau specializuojamės ir socializuojamės netoliese esančiame bare

Å io Ruby meetup’o temos:

  1. TorqueBox
  2. Rubinius
  3. Konacha

BÅ«tina registracija

Laukiame visų kovo 28d. 19:00 Lūkšio g. 5B-600 (Šiaurės miestelis), Vilnius

Published on 09/03/2012 at 13h50 by Saulius Grigaitis Tags , ,

Improving university course "Agile Development with Ruby" Part I

Few years ago I started delivering course Agile Development with Ruby at the Faculty of Mathematics and Informatics of Vilnius University . It is one semester course containing one weekly theory lecture and one weekly practice lecture for BS and MS students. It’s optional course, so I expected only very motivated students will pick it. So original intention was to prepare deep course about BDD with Ruby with few other topics like advanced Ruby chapters (for example meta-programming) and Ruby on Rails web framework. I delivered and tuned this course for 4 semesters so far, but I think there are still unsolved issues and plenty space for improvements, so I’ll write problems I faced teaching students in this series of posts and I would like get your feedback.

I’ll dedicate this post for one of most problematic thing – practice tasks. Initially I decided to use common scheme that is used in our faculty – final student’s mark contains of 40% of practice results and 60% of exam at the end of course. Couple of guys that produce best apps during practice lectures gets 10 without exam. I was very serious about practice tasks, because there is no way to learn BDD without practicing it. Unfortunately it turned out that I was too serious about it…

Approach #1
Initially I decided to give 3 tasks:

  1. Ruby application (for example “Car rental software”) – 2 points
  2. Porting Ruby application to ActiveRecord – 1 point
  3. Porting entire application to Ruby on Rails – 1 point

Tasks had defined quality (not all requirements, but some like OOP, full test coverage etc.) and quantity requirements (for example – at least 50 specs). But actually it’s really hard to clearly measure code quality, so mark mainly was written based on quantity requirements. So if some student had low code quality, then I just gave him my suggestions how to improve code and if there were spare time, then he/she improved the code. But if student do not show interested in improving code, then I just focus on quantity requirements. Seems that it’s not bad approach, because then I can spend more time with motivated students instead of wasting time with unmotivated students.

Pros:

  • Tasks are really suitable for learning BDD.
  • Scope is good for very motivated students.

Cons:

  • Too big scope for average student. Even experienced Rails developer spent at least 50 hours to complete it, so for fresh guys it can take 3x or even more. Usually students don’t have so much time for optional courses.
  • Ruby on Rails learning curve is long. Convention over Configuration means a lot of learning time.
  • Not all students were comfortable writting application, because they mostly wrote algorithms previously.

So overall I was happy with results from motivated students, but very unhappy with results from unmotivated students.

Approach #2
Later I introduced simpler version of practice tasks. So there were two options – Rockstars and Mainstream. Rockstarts was exactly same as Approach #1, Mainstream was 3 tasks too, but instead of application students needed to implement algorithm. Students needed to pick algorithm that is not trivial and processes not trivial data structure, so it’s possible to implement second task that loads or stores algorithm data using ActiveRecord. Third task was just simple frontend for that algorithm. It thought I solved unmotivated students problem. I was wrong. So what Mainstream students did – they tried to pick simplest possible algorithm with simplest possible data structures, so usually it ended up with single method algorithm implementation using trivial Ruby data structures (like arrays).

Pros:

  • Different level tasks, so great students can learn a lot and implement great app, while unmotivated can complete tasks still learn something.

Cons:

  • Too easy to cheat Mainstream task and turn it into too simple implementation and completely not suitable for learning BDD.
  • Algorithm implementation isn’t good project to learn BDD, application is much better.

So I think it probably was even bigger fail then Approach #1

Approach #3
I got rid of Mainstream, so there were only Rockstars task, but instead of 4 points for practice tasks, I decided to give 6 points for practice and 4 for exam. I think that practice tasks are much more important than exam in this course. So task #1 – 3 points, task #2 – 1.5 point and task #3 – 1.5 point.

Pros:

  • Virtually it’s still two different level tasks – motivated students can implement all three tasks, while unmotivated students can implement only first task and get 3 points.
  • Student don’t need to decide which task set (harder or easier) he/she is going to take, because everyone starts with same task #1 and then motivated students can proceed on other tasks.

Cons:

  • First task is too big chunk, it definitely needs to be split in smaller tasks.

This approach was best one so far, but I’m going to proceed improvements in upcoming semesters.

Approach #4 (Upcoming)
I hope to get feedback on this one from you, maybe you will find improvements until I start to use it next semester. So basically I’m going to use Approach #3, but I’ll split first task in to 3 smaller tasks, so 1 point per each task. Main problem is how to split the task. So far best way I think about would be simply split buy quantity. Originally first task had few quantity requirements:

  1. at least 50 rspec tests.
  2. at least 5 entities (in other words Classes).

So then I’ll have three sub-tasks:

  1. at least 30 tests and 3 entities.
  2. at least 40 tests and 4 entities.
  3. at least 50 tests and 5 entities.

Any better idea?

Published on 21/11/2011 at 13h58 by Saulius Grigaitis Tags , , , , ,

Powered by Publify Theme Frederic de Villamil | Photo Glenn