Instalacja Ruby on Rails, Apache, mySQL i Passengera pod kontrolą REE na serwerze pod kontrolą Debiana 4.0 etch

30 stycznia 2009, 18:07:59

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails, Techblog. | 7 komentarzy

Ostatnio dane mi było instalować pełen stos programów potrzebnych do uruchomienia aplikacji w Railsach na serwerze pod kontrolą systemu Debian 4.0 etch minimal w wersji 64-bitowej. Ponieważ proces ten jest dosyć długi, opisuję go poniżej.

Wymagania wstępne i założenia

Opis nie będzie zawierał prawie żadnych instrukcji jak zabezpieczyć serwer, przy okazji zakładam kilka rzeczy:

Czynności wstępne

Na początku warto upewnić się, że mamy aktualną listę pakietów. W tym celu warto wykonać następujące czynności:

$ apt-get update
$ apt-get upgrade

Instalujemy też potrzebne pakiety:

$ apt-get install apt-utils build-essential ruby1.8-dev imagemagick libmysqlclient15off \
 libmysqlclient15-dev mysql-server mysql-common mysql-client memcached libxslt1-dev libpcre3-dev \
 zlib1g-dev unzip gzip libssl-dev libreadline5-dev libmysql-ruby sqlite3 imagemagick man-db cron wget lynx curl bind9 -y

Od razu możemy zmienić hasło roota MySQL:

$ mysqladmin -u root password NEWPASSWORD

Instalacja Ruby

Żeby korzystać z jedynie Ruby Enterprise Edition można opuścić ten punkt.

Ruby instalujemy ze źrodeł. W momencie tworzenia opisu w oficjalnych repozytoriach Debiana znalazłem wersję 1.8.5, a najnowszą stabilną wersją Ruby na stronie Ruby-Lang była wersja 1.8.6-p286. Pobieramy i rozpakowujemy źródła Ruby:

$ cd /usr/src
$ wget ftp://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.6-p286.tar.gz
$ tar zxf ruby-1.8.6-p286.tar.gz
$ cd ruby-1.8.6-p286

Przed konfiguracją edytujemy plik ext/Setup w celu dołączenia potrzebnych rozszerzeń. Powyższy plik może wyglądać tak:

 #Win32API
 #bigdecimal
 curses
 #dbm
 digest
 digest/md5
 #digest/rmd160
 digest/sha1
 digest/sha2
 dl
 enumerator
 #etc
 #fcntl
 #gdbm
 iconv
 #io/wait
 #nkf
 #pty
 openssl
 #racc/cparse
 readline
 #sdbm
 socket
 stringio
 strscan
 syck
 syslog
 #tcltklib
 thread
 #tk
 #win32ole
 zlib

Zawartość pliku oznacza, że chcemy skompilować Ruby wraz z rozszerzeniami curses, digest (md5, sha1/2), dl, enumerator, iconv, openssl, readline, socket, stringio, strscan, syck, syslog, thread, zlib.

Przyszła kolej na konfigurację, kompilację i instalację:

$ ./configure --prefix=/usr/local --with-openssl-dir=/usr \
 --with-readline-dir=/usr --with-zlib-dir=/usr
$ make
$ make install
$ make install-doc

Ostatnia linijka jest opcjonalna i odpowiedzialna za wygenerowanie dokumentacji.

Po zainstalowaniu interpretera języka Ruby przychodzi kolej na Rubygems:

$ cd /usr/src
$ wget http://rubyforge.org/frs/download.php/45905/rubygems-1.3.1.tgz
$ tar zxf rubygems-1.3.1.tgz
$ cd rubygems-1.3.1/
$ ruby setup.rb
$ gem isntall rubygems-update
$ update_rubygems
$ gem source --add http://gems.github.com

Ostatnia linijka dodaje do źródeł gemów repozytorium Github

Pora na instalacje potrzebnych gemów, moja proponowana lista:

gem install actionmailer actionpack actionwebservice active_graph \
 activerecord activeresource activesupport addressable archive-tar-minitar \ 
 bcrypt-ruby BlueCloth builder capistrano capistrano-ext cgi_multipart_eof_fix \
 chronic color columnize daemons eventmachine extlib fastercsv fastthread \ 
 feedtools gem_plugin haml highline hoe hpricot image_science \
 InlineAttachment json libxml-ruby linecache memcache-client metaid \
 mime-types mini_magick mislav-will_paginate mongrel mongrel_cluster \
 mongrel_proctitle needle net-scp net-sftp net-ssh net-ssh-gateway nokogiri \
 oauth passenger progressbar rack rails rake rcov RedCloth rmagick rspec \
 rspec-rails rspec_hpricot_matchers ruby-debug ruby-debug-base rubyforge \
 RubyInline rubyzip thin thor tlsmail transaction-simple uuid uuidtools \
 webrat wirble xml-simple youtube ZenTest

Instalacja Ruby Enterprise Edition

Ponieważ będziemy uruchamiać aplikację Rails z użyciem Passengera, możemy zredukować zużycie pamięci korzystając ze specjalnie przygotowanej wersji interpretera. Instalujemy go ze źródeł:

$ cd /usr/src
$ wget http://rubyforge.org/frs/download.php/50087/ruby-enterprise-1.8.6-20090113.tar.gz
$ tar zxf ruby-enterprise-1.8.6-20090113.tar.gz
$ cd ruby-enterprise-1.8.6-20090113/
$ ./installer

Wraz z REE zostaną zainstalowane rubygems oraz pewne gemy. Dodatkowe gemy instalujemy jak wyżej, z tym, że korzystamy ze zmodyfikowanej wersji Ruby:

/opt/ruby-enterprise-1.8.6-20090113/bin/ruby -S /opt/ruby-enterprise-1.8.6-20090113/bin/gem install capistrano  # ... i inne gemy

Instalacja Apache

Zainstalowałem apache2 wraz z pakietami apache2-mpm-worker, apache2-utils oraz apache2-prefork-dev

 apt-get install apache2 apache2-mpm-worker apache2-utils apache2-prefork-dev

Instalacja i konfiguracja Passengera obsługiwanego przez REE

Ponieważ gem Passengera został zainstalowany wcześniej pozostaje wygenerować odpowiedni moduł dla apache2:

 /opt/ruby-enterprise-1.8.6-20090113/bin/passenger-install-apache2-module

Pora na konfigurację. Wykorzystamy modułowość apache2 oraz program a2enmod do załadowania modułu. Tworzymy pliki /etc/apache2/mods-available/passenger.load z zawartością taką, jak wygenerowała nam instalacja modułu Passengera, np.:

  LoadModule passenger_module /opt/ruby-enterprise-1.8.6-20090113/lib/ruby/gems/1.8/gems/passenger-2.0.6/ext/apache2/mod_passenger.so

i /etc/apache2/mods-available/passenger.conf:

 PassengerRoot /opt/ruby-enterprise-1.8.6-20090113/lib/ruby/gems/1.8/gems/passenger-2.0.6
 PassengerRuby /opt/ruby-enterprise-1.8.6-20090113/bin/ruby

Po zapisaniu tych plików ładujemy moduł:

$ a2enmod passenger

I to już praktycznie wszystko, jedyne, co zostaje do zrobienia, to utworzenie konfiguracji vhosta dla konkretnej aplikacji, np. w /etc/apache2/sites-available, uaktywnienie jej programem a2ensite i przeładowanie apache.

Mam nadzieję, że powyższy opis pozwoli komuś zaoszczędzić trochę czasu.

Tagi:

Dziwne zachowanie config.gem w połączeniu z rspec-rails w Rails 2.2

16 stycznia 2009, 17:23:13

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails, Techblog. | 3 komentarze

Pracując ostatnio nad projektem zauważyłem dziwne rzeczy dziejące się w aplikacji. Po pierwsze w trybie deweloperskim po jakimkolwiek błędzie nie wyświetlał się stack trace. Jedyne, co się wyświetlało, to error code 500.

Już sam ten fakt był dla mnie dość uciążliwy, chociaż w tym przypadku zawsze można było odwołać się do logów aplikacji. Dużo gorszą rzeczą było nadpisanie przez coś wartości stałej RAILS_ENV i ustawienie jej na 'test'. Co ciekawe, wartość ENV['RAILS_ENV'] nadal wskazywała na poprawne środowisko.

Kiedy po zainstalowaniu RPM aplikacja nie chciała z nim współpracować (oczywiście działo się tak przez źle wskazujące RAILS_ENV) trzeba było znaleźć winnego. Po nitce do kłębka znalazłem wpis dotyczący znikających stack trace'ów. Okazało się, że wycięcie z pliku config/environment.rb linijki:

config.gem 'rspec-rails', :lib => 'spec/rails'

rozwiązało oba problemy!

Winowajcą jest linijka

silence_warnings { RAILS_ENV = "test" }

w pliku lib/spec/rails.rb gema rspec-rails.

Powyższy problem zdaje się nie występować w przypadku korzystania z rspeca w formie pluginu.

Tagi:

Blokowe helpery w Ruby on Rails

08 lipca 2008, 10:28:11

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails, Techblog. | 4 komentarze

Bardzo przydatną rzeczą, którą możemy zrobić podczas refaktoryzacji kodu widoków jest dopisanie helperów akceptujących bloki kodu.

W Railsach standardowo mamy co najmniej kilka takich helperów, m.in. form_for, czy link_to (póki co w wersji EDGE). Nic nie stoi na przeszkodzie, aby dopisać swoje własne metody akceptujące bloki, które w widoczny sposób poprawiają czytelność kodu.

Jako przykład podam implementację rounded-box jako helper akceptujący blok. Końcowy efekt wyglądał będzie następująco:

<%- rounded_box do %>
Treść, która powinna znaleźć się w boksie
<% end -%>

Napisanie tego typu metod jest bardzo proste i opiera się na wykorzystaniu metody concat. Zakładam, że cały kod naszego boksu na postać (styl CSS zostawmy w spokoju):

<div class="rnd_container">
  <b class="rnd_top">
    <b class="rnd_b1"></b>
    <b class="rnd_b2"></b>
    <b class="rnd_b3"></b>
    <b class="rnd_b4"></b>
  </b>
<div class="rnd_content"> 
  <h2><p>Treść w boksie</p></h2>
</div>
  <b class="rnd_bottom">
    <b class="rnd_b4"></b>
    <b class="rnd_b3"></b>
    <b class="rnd_b2"></b>
    <b class="rnd_b1"></b>
  </b>
</div>

Powyższy kod można najprościej przetransportować do osobnego partiala i zapisac, np. w katalogu app/views/shared/_rounded_box.html.erb w lekko zmodyfikowanej wersji:

  <div class="rnd_container">
    <b class="rnd_top">
      <b class="rnd_b1"></b>
      <b class="rnd_b2"></b>
      <b class="rnd_b3"></b>
      <b class="rnd_b4"></b>
    </b>
  <div class="rnd_content"> 
    <h2><%= body %></h2>
  </div>
    <b class="rnd_bottom">
      <b class="rnd_b4"></b>
      <b class="rnd_b3"></b>
      <b class="rnd_b2"></b>
      <b class="rnd_b1"></b>
    </b>
  </div>

Sama metoda helpera wygląda następująco:

  def rounded_box(options={}, &block)
    options.merge!(:body => capture(&block))
    concat(render(:partial => "shared/rounded_box", :locals => options), block.binding)
  end

Jak widać oprócz bloku możemy przekazać do partiala swoje zmienne podając je jako parametry wywołania helpera. Cała magia polega na przechwyceniu zawartości bloku wywołaniem capture(&block) i skonkatenowaniem jej z naszym boksem.

Rozwiązanie szybkie, proste i jakże czytelne!

Tagi:

Manipulowanie czasem w testach w aplikacjach Ruby

05 lipca 2008, 00:43:31

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails, Techblog. | 1 komentarz

Czasem, szczególnie podczas pisania testów, zachodzi potrzeba manipulowania czasem, np. podczas testowania metod, które mają zwracać posortowane względem czasu utworzenia obiekty ActiveRecord.

W ostatnim projekcie podczas pisania spec-ów modeli korzystałem z takiego tworu:

describe SomeClass do
  describe "by_date" do
    it "should return objects sorted by creation date" do
      Time.advancing_by_days(-1) do
        @earlier = SomeClass.new(:some => "values")
      end
      @normal = SomeClass.new
      Time.advancing_by_days(1) do
        @later = SomeClass.new(:some => "other value")
      end
      SomeClass.by_date.should == [@later, @normal, @earlier]
    end
  end
end

O ile mi wiadomo, Railsy nie mają standardowo wbudowanych klas do manipulowania czasem, czy metodą Time.now.

Stworzenie metod realizujących powyższą funkcjonalność jest bardzo proste. Wystarczy stworzyć plik, np. time_extensions.rb z poniższą zawartością:

require 'time'

if !Time.respond_to?('old_now')
  Time.class_eval {
    @@advance_by_days = 0
    @@advance_by_minutes = 0
    cattr_accessor :advance_by_days, :advance_by_minutes

    class << Time
      alias old_now now
      def now
        if Time.advance_by_days != 0
          return Time.at(old_now.to_i + Time.advance_by_days * 60 * 60 * 24 + 1)
        elsif Time.advance_by_minutes != 0
          return Time.at(old_now.to_i + Time.advance_by_minutes * 60)
        else
          old_now
        end
      end
      def advancing_by_days(days=0)
        Time.advance_by_days = days
        yield
        Time.advance_by_days = 0
      end
      def advancing_by_minutes(minutes=0)
        Time.advance_by_minutes = minutes
        yield
        Time.advance_by_minutes = 0
      end
    end
  }
end

Jak widać korzystamy z możliwości, jakie daje monkey pathing i modyfikujemy standardową metodę Time.now, uprzednio tworząc do niej alias. W powyższym kodzie oprócz zmiany czasu o zadaną liczbę dni, możemy zmieniać go o zadaną liczbę minut.

Aby korzystać z powyższych metod w spec-ach aplikacji railsowej, wystarczy wrzucić plik z powyższym kodem do katalogu spec aplikacji i dopisać do pliku spec_helper.rb linijkę:

require 'time_extensions'

Tagi:

Modelujemy znajomych w Ruby on Rails

05 kwietnia 2008, 17:51:05

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails, Techblog. | 12 komentarzy

Ponieważ jestem w trakcie pisania małego serwisu społecznościowego w ramach pracy dyplomowej, nadszedł czas na wymodelowanie sieci znajomych. Przeglądałem trochę książek, szukałem trochę po przeróżnych blogach. W końcu stworzyłem hybrydę z rzeczy, które znalazłem.

Piszę w Railsach 2.0.2, chciałem więc w pełni wykorzystać REST. Pierwsze pytania pojawiły się już na poziomie projektowania bazy danych: czy lepiej podwajać krotki i trzymać w nich jakieś dodatkowe atrybuty? Czy może lepiej oszczędzić miejsce redukując rozmiar tabeli do jednej krotki na znajomość kosztem bardziej złożonego zapytania? Stanęło na tym, że każda "znajomość" ma dwie krotki w tabeli pośredniej, a znajomych przeglądamy przeglądając atrubuty "friend_id" krotek wybranych po atrybucie "user_id". Zatem dostaliśmy relację wiele-wiele pomiędzy tabelą Users a nią samą. Nasz model usera zaczął wyglądać więc mniej więcej tak:

# app/models/user.rb
class User < ActiveRecord::Base
  has_many :friendships, :dependent => :destroy
end

Model samej relacji "być znajomym" nabrał takiego kształtu:

# app/models/friendship.rb
class Friendship < ActiveRecord::Base
  belongs_to :user
  belongs_to :friend, :class_name => 'User', :foreign_key => 'friend_id'
end

Przyjęliśmy, że każde "zaproszenie" może mieć jeden z trzech stanów:

Stan zaproszenia przechowywany więc jest w tabeli pośredniej relacji wiele-wiele. Chcemy również w łatwy sposób docierać do naszych znajomych z poziomu usera. Z pomocą przychodzi nam metoda has_many :through, którą wykorzystujemy w modelu User (dla uproszczenia stany zaproszeń wyrażane są za pomocą stringów, innym sposobem, w moim mniemaniu lepszym, jest użycie, zamiast napisów, np. jakiś stałych liczbowych):

# app/models/user.rb
class User < ActiveRecord::Base
# (...)  
  has_many :friendships, :dependent => :destroy
  
  has_many :friends,
    :through => :friendships,
    :conditions => ["status = ?", 'zaakceptowane']
  
  has_many :requested_friends,
    :through => :friendships,
    :source => :friend,
    :conditions => ["status = ?", 'wyslane']
  
  has_many :pending_friends,
    :through => :friendships,
    :source => :friend,
    :conditions => ["status = ?", 'oczekujace']
  
  has_many :any_friends,
    :through => :friendships,
    :source => :friend
# (...)
end

Teraz dobrze jest zapewnić jakieś metody do zarządzania znajomościami. W tym celu utworzymy metody klasy Friendship, które będą wysyłały, akceptowały i odrzucały zaproszenia do znajomości:

# app/models/friendship.rb
class Friendship < ActiveRecord::Base

  belongs_to :user
  belongs_to :friend, :class_name => 'User', :foreign_key => 'friend_id'
  
  validates_presence_of :user_id, :friend_id
  
  def self.exists?(user, friend)
    not find_by_user_id_and_friend_id(user, friend).nil?
  end
  
  def self.request(user, friend)
    unless user == friend or Friendship.exists?(user, friend)
      transaction do
        create(:user => user, :friend => friend, :status => 'wyslane')
        create(:user => friend, :friend => user, :status => 'oczekujace')
      end
    end
  end
  
  def self.accept(user, friend)
    transaction do
      accepted_at = Time.now
      accept_one_side(user, friend, accepted_at)
      accept_one_side(friend, user, accepted_at)
    end
  end
  
  def self.breakup(user, friend)
    transaction do
      destroy(find_by_user_id_and_friend_id(user, friend))
      destroy(find_by_user_id_and_friend_id(friend, user))
    end
  end
  
  private
  def self.accept_one_side(user, friend, accepted_at)
    request = find_by_user_id_and_friend_id(user, friend)
    request.status = 'zaakceptowane'
    request.accepted_at = accepted_at
    request.save!
  end
end

Jak widać kluczowe akcje modelu wywoływane są w bloku metody transaction. To zapewnia nam transakcyjne wykonanie kodu, co zabda o spójność danych i nie dopuści do powstania sytuacji, w której podczas wysyłania zaproszenia od użytkownika A do użytkownika B w bazie pojawi się tylko krotka (A,B,'wyslane').

Można powiedzieć, że model jest już gotowy, pora zatem na kontroler, który będzie oferował podzbiór standardowych akcji: create, index, show oraz destroy. Akcja index zajmie się wyświetlaniem listy znajomych danego użytkownika, show przekieruje nas na profil użytkownika, create będzie odpowiedzialna za wysłanie lub zaakceptowanie zaproszenia, a destroy pozwoli na usunięcie kogoś z listy znajomych, jak również anulowanie wysłanego zaproszenia czy odrzucenie zaproszenia od niechcianej osoby. Całość umieściłem za filtrem :login_required (korzystam z pluginu restful_authentication) aby zarządzanie znajomymi było dostępne tylko po zalogowaniu.

Poszczególne akcje kontrolera nie są jakoś bardzo wyszukane, dla przykładu wkleję akcję destroy:

# app/controllers/friendships_controller.rb
class FriendshipsController < ApplicationController
# (...)
  def destroy
    # current_user zwraca aktualnie zalogowanego uzytkownika
    @user = current_user # dbamy o to, aby nikt nie usunal za nas naszych znajomych
    @friend = User.find(params[:id]) rescue nil
    if @friend
      if @user.any_friends.include?(@friend)
        Friendship.breakup(@user,@friend)
        flash[:notice] = 'Zaproszenie zostało usunięte'
      else
        flash[:notice] = 'Nie ma takiego zaproszenia'
      end
    else
      flash[:notice] = 'Nie ma takiego użytkownika'
    end
    redirect_to user_friendships_url(@user)
  end
# (...)

Zasób Friendships zagnieżdzony został przeze mnie w zasobie Users, co zapewnia taki fragment routes.rb:

# config/routes.rb
# (...)
 map.resources :users do |u|
    u.resources :friendships
  end
# (...)

Wydaje mi się, że takie rozwiązanie jest jednym z najprostszych, a mimo to zapewnia nam podstawowe rzeczy, które mogą okazać się przydatne, np. to, kto był stroną wysyłającą zaproszenie, czy kiedy zostało ono zaakceptowane.

Tagi:

Dynamiczne ładowanie plików z formularza w Ruby on Rails

23 marca 2008, 00:38:32

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails, Techblog. | 3 komentarze

Wstęp

Wyobraźmy sobie, że chcemy utworzyć bazę ogłoszeń, do których chcemy w łatwy i przyjemny sposób dodawać zdjęcia. W tej notce pokażę jak w dosyć prosty sposób wykorzystać Railsy do stworzenia prostego panelu do zarządzania takimi ogłoszeniami. Stworzymy formularz dodawania ogłoszeń, w którym oprócz możliwości dodawania ogłoszeń umieścimy prosty formularz, który umożliwi załadowanie zdjęcia na serwer i podpięcie go pod dodawane ogłoszenie. Oczywiście udostępnimy możliwość wyboru zdjęć już obecnych na serwerze, dla uproszczenia zakładamy, że zdjęcie może należeć tylko do jednego ogłoszenia.

Wymagania

Wszystko, czego potrzebujemy to:

Zaczynamy

Zacznijmy od stworzenia nowego projektu. Nie będę skupiał się na podstawach, na potrzeby tego opisu wykorzystam domyślną konfigurację railsów z bazą SQLite. W linii poleceń tworzymy nowy projekt:

$ rails demo
$ cd demo

Od razu stworzymy bazę danych, aby potem nie trzeba było do tego wracać:

$ rake db:create

Mając przygotowany projekt, zaopatrzmy się w odpowiednie pluginy. W tym celu odpalamy następujące polecenia:

$ script/plugin install http://svn.techno-weenie.net/projects/plugins/attachment_fu/
$ script/plugin install http://responds-to-parent.googlecode.com/svn/trunk

Środowisko mamy już przygotowane. Pora na utworzenie modeli. Ograniczymy się do najbardziej podstawowych rzeczy. Utworzymy model Advertisement, który będzie miał tytuł oraz opis. Potrzebny będzie również model Photo, który będzie miał atrybuty wymagane przez plugin attachment_fu. Wklepujemy zatem w konsoli:

$ script/generate model Advertisement name:string description:text

W przypadku modelu Photo nie będziemy podawać żadnych parametrów dla generatora:

$ script/generate model Photo

Po wygenerowaniu modeli, zanim zmigrujemy bazę danych, wyedytujemy plik migracji db/migrate/002_create_photos.rb, wypełniając go jak poniżej:

class CreatePhotos < ActiveRecord::Migration
  def self.up
    create_table :photos do |t|
      t.column :parent_id,  :integer
      t.column :content_type, :string
      t.column :filename, :string    
      t.column :thumbnail, :string 
      t.column :size, :integer
      t.column :width, :integer
      t.column :height, :integer
      t.column :advertisement_id, :integer
    end
  end

  def self.down
    drop_table :photos
  end
end

W tej chwili możemy już zmigrować bazę danych

$ rake db:migrate

Konfiguracja modeli

Pora na skonfigurowanie modeli, utworzenie relacji jeden-wiele między ogłoszeniami i zdjęciami oraz przygotowanie modelu Photo do pracy z pluginem attachment_fu (wykorzystanie relacji wiele-wiele pozostawiam jako ćwiczenie). W tym celu edytujemy pliki modeli jak poniżej

# app/models/advertisement.rb
class Advertisement < ActiveRecord::Base
  has_many :photos
end

# app/models/photo.rb
class Photo < ActiveRecord::Base
  belongs_to :advertisement
  has_attachment :content_type => :image,   # zalacznikiem jest obrazek
                 :storage => :file_system,  # trzymamy go w systemie plikow
                 :max_size => 2.megabytes,  # ograniczamy rozmiar do 2 MB
                 :resize_to => '1200x800>', # zmniejszamy plik wejsciowy
                 :thumbnails => {:thumb => '200x200>'} # tworzymy jedna miniature
  validates_as_attachment # walidujemy plik po zaladowaniu na serwer, przed zapisem do bazy danych
  # z powyzsza walidacja mialem problemy pod Windowsem, posiadaczom tego systemu radze poki co zakomentowac
  # powyzsza linijke
end

W tej chwili mamy już skonfigurowaną relację oraz przygotowany model pod umieszczanie na serwerze plików. Pora na następną część

Konfiguracja kontrolerów

Do prawidłowej pracy będziemy potrzebować dwa kontrolery. Jeden z nich, nazwijmy go advertisements będzie odpowiedzialny za zarządzanie ogłoszeniami, drugi — photos — będzie zajmował się zdjęciami. Wykorzystamy mechanizm REST. W tym celu tworzymy kontrolery z linii poleceń:

$ script/generate controller Advertisements index show new edit create update destroy
$ script/generate controller Photos index new edit create destroy

Aby skorzystać z REST musimy jeszcze dodać odpowiednie wpisy w pliku config/routes.rb:

ActionController::Routing::Routes.draw do |map|
  map.resources :advertisements
  map.resources :photos
  
  # ponizsze wpisy pozostawiamy
  map.connect ':controller/:action/:id'
  map.connect ':controller/:action/:id.:format'
end

Nadeszła pora na zaimplementowanie akcji potrzebnych do zarządzania naszymi zasobami. Są to standardowe akcje, pokażę zatem jedynie zawartość kontrolerów:

# app/controllers/advertisements_controller.rb
class AdvertisementsController < ApplicationController

  def index
    @advertisements = Advertisement.find(:all)
    respond_to do |format|
      format.html {}
      format.xml  { render :xml => @advertisements.to_xml }
    end
  end

  def show
    @advertisement = Advertisement.find(params[:id])
    respond_to do |format|
      format.html {}
      format.xml  { render :xml => @advertisement.to_xml }
    end
  end

  def new
    @advertisement = Advertisement.new
  end

  def edit
    @advertisement = Advertisement.find(params[:id])
  end

  def create
    @advertisement = Advertisement.new(params[:advertisement])
    respond_to do |format|
      if @advertisement.save
        format.html { redirect_to advertisement_url(@advertisement) }
        format.xml  { render :xml => @advertisement.to_xml }
      else
        format.html { render :action => 'new'}
        format.xml  { render :xml => @advertisement.errors.to_xml }
      end
    end
  end

  def update
    @advertisement = Advertisement.find(params[:id])
    respond_to do |format|
      if @advertisement.update_attributes(params[:advertisement])
        format.html { redirect_to advertisement_url(@advertisement) }
        format.xml  { render :xml => @advertisement.to_xml }
      else
        format.html { redirect_to edit_advertisement_url(@advertisement) }
        format.xml  { render :xml => @advertisement.errors.to_xml }
      end
    end
  end

  def destroy
    @advertisement = Advertisement.find(params[:id])
    respond_to do |format|
      if @advertisement.destroy
        format.html { redirect_to advertisements_url }
        format.xml  { head :ok }
      else
        format.html { redirect_to advertisement_url(@advertisement) }
        format.xml  { redirect_to @advertisement.errors.to_xml }
      end
    end
  end
end

# app/controllers/photos_controller.rb
class PhotosController < ApplicationController

  def index
    @photos = Photo.find(:all, :conditions => 'parent_id IS NULL') # wybieramy tylko zdjecia w oryginalnych rozmiarach
    respond_to do |format|
      format.html {}
      format.xml  { render :xml => @photos.to_xml }
    end
  end

  def new
    @photo = Photo.new
    @advertisements = Advertisement.find(:all)
  end

  def create
    @photo = Photo.new(params[:photo])
    respond_to do |format|
      if @photo.save
        format.html { redirect_to photos_url }
        format.xml  { render :xml => @photo.to_xml }
      else
        format.html { render :action => 'new' }
        format.xml  { render :xml => @photo.errors.to_xml }
      end
    end
  end

  def destroy
    @photo = Photo.find(params[:id])
    respond_to do |format|
      if @photo.destroy
        flash[:notice] = 'Zdjęcie zostało usunięte'
        format.html { redirect_to photos_url }
        format.xml  { head :ok }
      else
        flash[:error] = 'Wystąpił błąd podczas usuwania zdjęcia'
        format.html { redirect_to photos_url }
        format.xml  { render :xml => @photo.errors.to_xml }
      end
    end
  end
end

Warstwa modeli i kontrolerów jest już prawie gotowa. Pozostało dodanie widoków, za pomocą których będziemy mogli odczuć, czy to, co stworzyliśmy w ogóle działa.

Pora na widoki

W warstwie widoków ograniczę się do najprostrzego wyświetlania elementów, bez żadnych upiększaczy (przynajmniej na razie). Poniżej wklejam najprostsze możliwe widoki, które nie oferują nic poza podstawowymi opcjami. Widoki dla kontrolera advertisements_controller:

# app/views/advertisements/index.html.erb
<h1>Ogłoszenia</h1>
<ul>
<% for advertisement in @advertisements %>
  <li>
    <p><%= link_to h(advertisement.name), advertisement_url(advertisement) %></p>
    <p><%= truncate(h(advertisement.description), 20) %></p>
    <p><%= link_to 'Edytuj', edit_advertisement_url(advertisement) %></p>
    <p><%= link_to 'Usuń', advertisement_url(advertisement), :method => :delete, :confirm => 'Czy jesteś pewien?' %></p>
  </li>
<% end %>
</ul>
<p><%= link_to 'Dodaj nowe', new_advertisement_url %></p>

# app/views/advertisements/new.html.erb
<h1>Nowe ogłoszenie</h1>
<%= error_messages_for :advertisement %>

<% form_for @advertisement do |f| %>
  <p><label for="advertisement_name">Nazwa:</label></p>
  <p><%= f.text_field :name %></p>
  <p><label for="advertisement_description">Opis:</label></p>
  <p><%= f.text_area :description, :cols => 60, :rows => 20 %></p>
  <p><%= submit_tag 'Zapisz', :disable_with => "Proszę czekać..." %></p>
<% end %>
<p><%= link_to 'Powrót', advertisements_url %></p>

# app/views/advertisements/show.html.erb
<h1><%=h @advertisement.name %></h1>
<p><%=h @advertisement.description %></p>
<p><%= link_to 'Edytuj', edit_advertisement_url(@advertisement) %></p>
<p><%= link_to 'Usuń', advertisement_url(@advertisement), :method => :delete, :confirm => 'Czy jesteś pewien?' %></p>
<p><%= link_to 'Powrót', advertisements_url %></p>
<hr/>
<% unless @advertisement.photos.empty? %>
<p>Zdjęcia:</p>
<ul>
<% for photo in @advertisement.photos %>
  <li><%= link_to image_tag(photo.public_filename(:thumb)), photo.public_filename %></li>
<% end %>
</ul>
<% end %>

# app/views/advertisements/edit.html.erb
<h1>Edycja ogłoszenia</h1>
<%= error_messages_for :advertisement %>

<% form_for @advertisement do |f| %>
  <p><label for="advertisement_name">Nazwa:</label></p>
  <p><%= f.text_field :name %></p>
  <p><label for="advertisement_description">Opis:</label></p>
  <p><%= f.text_area :description, :cols => 60, :rows => 20 %></p>
  <p><%= submit_tag 'Zapisz', :disable_with => "Proszę czekać..." %></p>
<% end %>
<p><%= link_to 'Powrót', advertisements_url %></p>

Widoki dla kontrolera photos_controller:

# app/views/photos/index.html.erb
<h1>Zdjęcia</h1>
<ul>
<% for photo in @photos %>
  <li>
    <p><%= link_to image_tag(photo.public_filename(:thumb)), photo.public_filename %></p>
    <p><%= link_to 'Usuń', photo_url(photo), :method => :delete, :confirm => 'Czy jesteś pewien?' %></p>
  </li>
<% end %>
</ul>
<p><%= link_to 'Dodaj nowe', new_photo_url %></p>

# app/views/photos/new.html.erb
<h1>Nowe zdjęcie</h1>
<%= error_messages_for :photo %>

<% form_for @photo, :html => {:multipart => true} do |f| %>
  <p><label for="photo_uploaded_data">Plik ze zdjęciem:</label></p>
  <p><%= f.file_field :uploaded_data %></p>
  <p><label for="photo_advertisement_id">Ogłoszenie:</label></p>
  <p><%= f.collection_select :advertisement_id, @advertisements, :id, :name, {:prompt => true} %></p>
  <p><%= f.submit "Załaduj" %></p>
<% end %>
<p><%= link_to 'Powrót', photos_url %></p>

W tej chwili możemy już zobaczyć, jak to wszystko działa. Wystarczy odpalić serwer:

$ script/server

Po odpaleniu serwera wpisując w adresie przeglądarki adres http://localhost:3000/advertisements możemy administrować ogłoszeniami, natomiast pod adresem http://localhost:3000/photos możemy zarządzać zdjęciami.

No dobrze, ale na początku pisałem o dynamicznym ładowaniu zdjęć podczas pisania ogłoszenia oraz o możliwości wybierania zdjęć. Na pierwszy rzut pójdzie możliwość wyboru zdjęć spośród załadowanych i nie dołączonych do innych ogłoszeń

Wybór zdjęć przy dodawaniu ogłoszenia

Aby umożliwić dołączanie zdjęć podczas dodawania czy edycji ogłoszenia, skorzystamy z możliwości, jakie dostarcza metoda has_many w modelu ogłoszeń, a dokładnie z settera photo_ids. W tym celu należy dodać kilka rzeczy do kontrolera ogłoszeń i zmodyfikować odpowiednio widoki.

W metodach new oraz edit dodajemy następującą linijkę (oczywiście przeczymy tutaj zasadzie DRY, jednak chodzi tutaj o jak najprostsze pokazanie, o co chodzi):

@photos = Photo.find(:all, :conditions => 'parent_id IS NULL')

W tej chwili możemy już pokazać w formularzu dodawania/edycji ogłoszeń dostępne zdjęcia wraz z check boxami do ich zaznaczania. W tym celu dodajemy do formularza w plikach app/views/advertisements/{new,edit} gdzieś w bloku form_for, najlepiej po text area:

<div id="photos">
<% for photo in @photos %>
  <p><%= image_tag photo.public_filename(:thumb) %></p>
  <p><%= check_box_tag 'advertisement[photo_ids][]', photo.id, @advertisement.photos.include?(photo) %>
<% end %>
</div>

Od tej pory będziemy mogli zaznaczać zdjęcia, które będziemy chcieli dodać do ogłoszenia (pamiętajmy o tym, że mamy relację jeden-wiele, więc jeżeli tworząc lub edytując jakieś ogłoszenie zaznaczymy zdjęcie wcześniej zajęte, zostanie ono przypisane tylko do nowo tworzonego/edytowanego ogłoszenia — aby to zmienić należy zamienić relację z jeden-wiele na wiele-wiele). Zostaje tylko jeden problem. Kiedy będziemy chcieli usunąć z jakiegoś ogłoszenia wszystkie zdjęcia i odznaczymy wszystkie dostępne w formularzu, po kliknięciu 'Dodaj' lub 'Edytuj' nic się nie stanie. Dzieje się tak dlatego, że w tym przypadku Railsy nie przekażą do kontrolera zawartości parametru advertisement[photo_ids][]. Jednak jest bardzo prosty sposób, by to zmienić. Do kontrolera advertisements_controller w akcji update dodajemy na początku następującą linijkę:

params[:advertisement][:photo_ids] ||= []

Spowoduje ona, że w przypadku, gdy odznaczymy wszystkie zdjęcia podczas edycji ogłoszenia, zostaną rzeczywiście usunięte z relacji.

Dynamiczne dodawanie plików + a pinch of AJAX

Do zrobienia została nam jeszcze jedna część — dynamiczne ładowanie zdjęcia podczas dodawania lub edycji ogłoszenia i uaktualnianie formularza nowym zdjęciem. Nie da się tego zrobić przy pomocy samego AJAX-a, ponieważ ze względów bezpieczeństwa AJAX nie pozwala na przesyłanie lokalnych plików. Istnieje jednak prosty sposób, aby tę niedogodność ominąć. W tym celu utworzymy na stronie niewodoczny iframe i ustawimy na niego atrybut target formularza ładującego zdjęcie. Następnie, wykorzystując plugin responds_to_parent, uaktualnimy listę zdjęć w formularzu dotyczącym ogłoszenia.

Na początku zdefiniujmy sobie prosty layout oraz dołączmy potrzebne skrypty JavaScript. W tym celu tworzymy plik app/views/layouts/application.erb o nastepującej zawartości:

<html>
  <head>
    <meta http-equiv="Content-type" content="text/html; charset=utf-8"/>
    <title>Demonstracja dynamicznego ładowania plików, &copy; 2008 GhandaL</title>
    <%= javascript_include_tag :defaults %>
  </head>
  <body>
    <% if flash[:notice] %>
      <div style="border: 1px green"><%= flash[:notice] %></div>
    <% end %>
    <% if flash[:error] %>
      <div style="border: 1px red"><%= flash[:error] %></div>
    <% end %>
    <%= yield :layout %>
  </body>
</html>

W celu ładowania pliku posłużymy się fragmentami kodu widoków, tzw. partials. Zanim jednak dopracujemy widoki, zmodyfikujemy odpowiednio kontroler photos_controller, aby uaktualniał stronę, która wywołała akcję create. W tym celu modyfikujemy akcję create w pliku app/controllers/photos_controller.rb tak, by wyglądała jak poniżej:

  def create
    @photo = Photo.new(params[:photo])
    respond_to do |format|
      if @photo.save
        format.html { redirect_to photos_url }
        format.xml  { render :xml => @photo.to_xml }
        format.js do
          responds_to_parent do
            render :update do |page|
              page.insert_html :bottom, "photos", :partial => 'photo', :object => @photo
            end
          end
        end
      else
        format.html { render :action => 'new' }
        format.xml  { render :xml => @photo.errors.to_xml }
        format.js do
          responds_to_parent do
            render :update do |page|
              # jakis kod uaktualniajacy, np. bledem, strone
            end
          end
        end
      end
    end
  end

Teraz możemy się zająć stworzeniem odpowiednich partials. Po pierwsze stworzymy kod, który wyświetli nowo załadowane zdjęcie. Tworzymy plik app/views/photos/_photo.erb o zawartości:

<p><%= image_tag photo.public_filename(:thumb) %></p>
<p><%= check_box_tag 'advertisement[photo_ids][]', photo.id, true %></p>

Do zrobienia została nam jeszcze jedynie modyfikacja widoków akcji new i edit kontrolera advertisements_controller. Gdzieś na końcu plików app/views/advertisements/{new,edit} dopisujemy następujący kod:

<iframe name="dummy" id="dummy" style="width:1px;height:1px;border:0"></iframe>
<% form_for :photo, :url => {:controller => :photos, :action => :create, :format => 'js'}, :html => {:target => 'dummy', :multipart => true} do |f| %>
  <p><label for="photo_uploaded_data">Plik ze zdjęciem:</label></p>
  <p><%= f.file_field :uploaded_data %></p>
  <p><%= f.submit 'Dodaj' %></p>
<% end %>

I to już wszystko. Od tej pory dodając i edytując ogłoszenia można już ładować zdjęcia bez potrzeby przeładowywania strony.

Konkluzja

Oczywiście powyższe rozwiązanie ma pewne wady. Przede wszystkim relacja jeden-wiele jest bardzo prymitywna w tym przypadku i zabrania dołączania jednego zdjęcia do kilku ogłoszeń. Jednak modyfikacja tego nie jest trudna, nie o tym jest również ta notka. Kod demonstracyjnej aplikacji możesz ściągnąć mojej strony. Mam nadzieję, że powyższy opis komuś się przyda. Jeśli zauważyłeś jakiś błąd lub chciałbyś wyrazić opinię o moim rozwiązaniu, zapraszam do komentowania.

Tagi:

Mój pierwszy VPS

11 marca 2008, 14:43:37

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails, Techblog, Web Design. | 10 komentarzy

Ponieważ zaczęły mnie denerwować timeouty w przekazywaniu żądań z Apache do mongreli na Rootnode zacząłem rozglądać się za czymś lepszym. Pod uwagę brałem VPS-y w cenie do ok. 60zł za miesiąc. Postanowiłem w najbliższych miesiącach przetestować kilka z nich. Na pierwszy ogień poszedł ProVPS. Za tym rozwiązaniem przemawia lokalizacja serwerów w Polsce, w Gdańsku, a co za tym idzie niskie pingi, w granicach 35-45ms. Jednak na tym plusy się kończą (porównując do reszty ofert branych pod uwagę). Za 49 zł netto miesięcznie dostajemy gwarantowane 128 MB RAM-u, rozszerzane do 512 MB, 5 GB powierzchni dyskowej, 25 GB transferu miesięcznego oraz 1 adres IP. Na tle konkurencji trochę blado.

Wczoraj aktywowano mi VPS i spędziłem kilka ładnych godzin na konfigurowaniu poszczególnych części systemu. Postanowiłem uruchomić minimum usług, głównie po to, by zmieścić się w drakońskich limitach pamięci. Niestety musiałem zrezygnować z mySQL, ponieważ nie znalazłem sposobu na ograniczenie konsumpcji pamięci do akceptowalnego na tym serwerze poziomu — po uruchomieniu mysqld konsumował ok. 100 MB pamięci operacyjnej pomimo przeróżnych konfiguracji znalezionych w sieci i w dokumentacji mySQL. Zaminiłem mySQL na PostgreSQL i tutaj małe zaskoczenie — domyślna instalacja postgresa zużywa ponad połowę mniej pamięci niż mySQL!

Gdy baza danych była już gotowa, nadszedł czas na serwer WWW. Wybór oczywiście padł na nginx, o wiele lżejszy od Apache'a serwer plus load balancer. Na VPS-ie będą uruchamiane jedynie statyczne pliki oraz aplikacje w Railsach i Merbie (w liczbie max. 3 — patrz pamięć). Z konfiguracją nginxa nie było żadnych problemów, świetną konfigurację dla aplikacji railsowych w obsługą cache przygotował Ezra Zygmuntowicz. Konfiguracja ta dostępna jest na jego stronie.

Następną rzeczą do zrobienia była kompilacja Ruby, Rubygems, ImageMagick oraz instalacja Subversion. Oczywiście po drodze były mniejsze komplikacje — a to zabrakło biblioteki zlib, a to nie zainstalowałem libsqlite3-dev. W każdym razie po mniej więcej 5 godzinach miałem już działającego Postgresa, nginxa, SVN, Ruby+Rails i całą resztę potrzebnych do życia aplikacji.

Nadszedł czas na sprawdzenie, czy praca nie poszła na marne. Zgrałem pisaną ostatnio aplikację, zmigrowałem bazę, ustawiłem dwie instancje serwera thin i uruchomiłem je. Et voilà! Wszystko ruszyło i działa jak należy i, co najważniejsze, naprawdę dużo szybciej niż na Rootnode, gdzie aplikacja stała poprzednio.

Nieprzespana noc z konfiguracją serwera za mną, ale za miesiąc prawdopodobnie czeka mnie następna, ponieważ, jak pisałem na wstępie, mam w planie przetestowanie kilku dostawców, którzy mają mniejszy miesięczny abonament i gwarantują 2x więcej pamięci, co dla mnie jest rzeczą ważną. Zastanawiam się, czy sensowne będzie kupowanie VPS-a w USA. Na mojej liście jest Slicehost oraz SilverRack z całkiem niezłą ofertą za niewielkie pieniądze. Z drugiej strony za zachodnią granicą mamy Host Europe, również z ciekawą ofertą i niskimi pingami.

Pomimo dużo większych nakładów czasowych myślę, że nie wrócę już do dzielonego hostingu. VPS i serwer dedykowany daje tę wolność, jakiej nie ma na żadnym dzielonym hostingu (Rootnode jest bardzo liberalne, ale, np. nie mogłem doprosić się o aktualizację Ruby do wersji 1.8.6, ponieważ ma "za dużo zależności"). Pamiętać trzeba oczywiście o tym, że samemu trzeba dbać o stabliność i bezpieczeństwo danych na takim serwerze, ale to z kolei wymusza pewną pracę i naukę, która później nie zginie.

PS. Jakby ktoś z czytających miał wiedzę na temat tego, jak ograniczyć zużycie pamięci przez mySQL, proszę o kontakt.

Tagi:

Rails 2.0 podano do stołu.

07 grudnia 2007, 19:08:21

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby, Ruby on Rails. | 3 komentarze

Dzisiaj nareszcie wydano nową wersję Railsów, których przedstawiać pewnie nie trzeba. Instrukcja instalacji oraz nowości, których jest wiele, znajduje się na oficjalnym blogu frameworka. Ciekaw jestem, jak wypadną benchmarki nowej wersji Railsów. Mam nadzieję, że lepiej, niż poprzednich.

Na horyzoncie pojawiła się jeszcze jedna, bardzo ciekawa, bo wielowątkowa, komponentowa i zorientowana na wydajność propozycja dla programistów aplikacji internetowych w Rubym — Merb. Framework ten nie ma wbudowanego ORM-a, może jednak korzystać bezproblemowo zarówno z Railsowym ActiveRecordem, jak i z Data-mapperem, czy Sequelem. Szkoda tylko, że nie póki co ciężko go uruchomić pod Windowsem.

Tagi:

Shell z piekła rodem

31 sierpnia 2007, 19:20:29

Poziom: 0 | Kategoria: Komputerowo-internetowo, Python, Ruby on Rails. | Dodaj komentarz

Dzisiaj będzie trochę reklamowo-propagandowo. Ostatnio zastanawiałem się nad zmianą hostingu. Po namowie ahesa założyłem testowe konto na rootnode. Na razie jestem pod wrażeniem. Ilość dostępnych usług oszałamiająca, parametry niczego sobie. Shell w porównaniu z Dreamhostem dużo szybszy. Nawet na mojej wolnej i awaryjnej radiówce. Pingi dużo mniejsze: Dreamhost ~200ms, Rootnode ~55-60ms! Uruchomiłem też swoją aplikację w Railsach pod Apache z FCGI (chociaż i mongrela udało mi się uruchomić — wtedy moja aplikacja naprawdę ruszyła z kopyta). Typo również powstało bez problemów.

Poza tym to jest jedyny hosting, który znam, gdzie można korzystać już z rozwojowego php6. Wygląda na to, że już tam zostanę. Polecać będę, jak dłużej posiedzę, ale już mogę zachęcić do testowania.

Tagi:

GGallery?

22 sierpnia 2007, 09:54:05

Poziom: 0 | Kategoria: Komputerowo-internetowo, Przemyślenia, Ruby, Ruby on Rails. | Dodaj komentarz

Piotrek prosił mnie o pomoc w stworzeniu i zarządzaniu internetową galerią fotek. Po epizodzie z Coppermine Photo Gallery postanowił przejść na coś mniej skomplikowanego i zasobożernego. Stąd mój pomysł na prostą galerię własnej roboty. Niestety na hostingu Piotrka nie ma obsługi Ruby on Rails, ale u mnie jest, więc galeria może wisieć u mnie.

W tej chwili jestem na etapie planowania, jak to wszystko ma wyglądać. I pomysł mam następujący. Aby nie zarżnąć serwera będę robił skrypt, który będzie uaktualniał galerię i tworzył statyczne strony z poszczególnymi zdjęciami lub całymi galeriami. Całość ma odbywać się mniej więcej tak, że mam sobie folder galleries, w którym są podfoldery numerowane kolejnymi liczbami, lub nazwane jakkolwiek inaczej. Po uruchomieniu skryptu indeksuje on wszystkie katalogi i dodaje/usuwa/uaktualnia statyczne strony ze zdjęciami we wszystkich galeriach lub dodaje tylko zindeksowane nowe galerie, w przypadku, gdy nie zmienialiśmy nic w starych. Oczywiście tworzy przy okazji miniatury wszystkich zdjęć.

Wydaje mi się, że takie podejście pozwoli na mniejsze zużycie zasobów. Nie potrzebna będzie prawdopodobnie nawet baza danych, bo konfiguracje skryptu mogę trzymać w nim samym lub w jakimś XML-u. Galeria ma być prosta, bez komentowania zdjęć, itp. Chodzi przede wszystkim o łatwe dodawanie nowej galerii.

Tagi:

A może jednak będzie sprawdzaczka?

14 czerwca 2007, 01:35:37

Poziom: 0 | Kategoria: Komputerowo-internetowo, Przemyślenia, Ruby on Rails, Studia. | 1 komentarz

W zasadzie skończyłem projekt z baz danych. W aktualnej wersji zadania wysłane przez użytkowników są sprawdzane przez sędziów, jednak cały czas chodzi mi po głowie napisanie automatycznej sprawdzaczki. Problem w tym, że — niestety — nie wiem jak zablokować możliwość otwierania nowych plików i tworzenia nowych wątków lub procesów przez sprawdzany przez sprawdzaczkę program. Próbowałem bawić się ulimitem, którym ustawiam limity czasowe i pamięciowe, ale nie do końca wiem, czy tędy droga. Ustawienie ulimit -n 1 nie działa, podobnie ulimit -u 1.

Jeżeli ktoś z czytających ma jakąś koncepcję — będę wdzięczny za pomoc!

Tagi:

Coś się ruszyło

04 czerwca 2007, 02:40:25

Poziom: 0 | Kategoria: Komputerowo-internetowo, Ruby on Rails, Studia, Web Design. | 4 komentarze

Zacząłem wreszcie pisać projekt na bazy danych. Z każdą linią kodu utwierdzam się w przekonaniu, że Ruby on Rails to świetne środowisko do przyjemnego pisania aplikacji. Wychwalać też będę doskonałe NetBeansy w wersji 6, bez których pisało by się kilka razy wolniej.

W tej chwili mam już prostą autoryzację użytkowników opartą na trzech kategoriach – zwykłych użytkowników, którzy będą mogli nadsyłać rozwiązania, sędziów, którzy te rozwiązania sprawdzą i ocenią (zrezygnowałem na razie z pisania sprawdzaczki) oraz administratorów, którzy mogą dodawać zadania, konkursy, itp. Skończyłem też administrację konkursami – można dodawać/edytować/usuwać konkursy oraz wgrywać pliki z zadaniami. Proste forum w zasadzie też mam już skończone, muszę je tylko zintegrować.

Przede mną chyba najgorsza część, czyli implementacja wysyłania rozwiązań, oceniania ich przez sędziów oraz wyświetlanie jakiś rankingów. Myślę też nad prezentacją statystyk w formie wykresów.

Oczywiście nie obyło się bez problemów – nie mam pojęcia dlaczego giną mi parametry przesyłane z formularza do dodawania nowych zadań i muszę szpecić definicję metody kontrolera dodatkowymi liniami kodu, które uzupełnią brakujące pola. Wygląda to mniej więcej tak:

def create
    if request.post?
      @problem = Problem.new(params[:problem])
      @problem.name = params[:problem][:name]
      @problem.short_name = params[:problem][:short_name]
      @problem.contest_id = params[:problem][:contest_id]

      if @problem.save
        flash[:notice] = 'Zadanie zostało dodane.'
        redirect_to :action => 'list'
      else
        redirect_to :action => 'new'
      end
    end
  end

Szkoda tylko, że nie wiem, ile mam czasu, bo nigdzie nie podano terminu oddania pierwszej części projektu...

Tagi:

Ruby on Rails 1.2 już jest

18 stycznia 2007, 19:18:21

Poziom: 0 | Kategoria: Komputerowo-internetowo, Miniblog, Ruby on Rails, Web Design. | Dodaj komentarz

Pojawiła się finalna wersja frameworka Ruby on Rails w wersji 1.2. Wersja ta niesie ze sobą wiele nowości i ulepszeń. Aby wykonać update, wystarczy skorzystać z narzędzia gem: $>gem update rails -y lub pobrać odpowiedni pakiet ze stron RubyForge.

Tagi: