Vor kurzem bin ich über eine recht nette Sache beim Rails routing gestolpert, nämlich den constraints. In Rails 2 waren diese noch als requirements bekannt, allerdings waren sie damals nicht so mächtig. So konnte man mit Rails 2 nur einfache Bedingungen für Routen definieren, z.B. dass ein übergebener Wert eine 4-stellige Zahl sein muss. Mit Rails 3 ist man hier nun wesentlich flexibler geworden, es lassen sich z.B. Bedingungen anhand das UserAgents festlegen, oder direkt die remote IP in einer Datenbank nachschlagen lassen, bevor die Route überhaupt geprüft wird. So könnte man z.B. eine dynamische IP basierte Zugriffskontrolle für Ressourcen aufbauen ohne umfangreiche Konfigurationen an Webservern vornehmen zu müssen.

Als erstes einfaches Beispiel dient hier die Prüfung auf ein korrektes Datumsformat.

match "/:year(/:month(/:day))" => "blog#show", :constraints => { :year => /\d{4}/, :month => /\d{2}/, :day => /\d{2}/ }

Hier wird geprüft, dass das Jahr als 4-stellige Zahl, der Monat und der Tag als 2-stellige Zahl angegeben werden müssen.

Das ging bereits auch schon mit Rails 2, mit Rails 3 könnten wir jetzt z.B. eine Route nur für einen bestimmten Browser verfügbar machen…

match "/ffonly" => "info#ff", :constraints => { :user_agent => /Firefox/ }

In meinem Fall brauchte ich aber eine Limitierung auf die remote IP Adresse, so dass bestimmte Ressourcen für eine Liste von IPs verfügbar sind. Klar kann man das recht einfach direkt im Webserver konfigurieren, nur lassen sich dann die freigeben Hosts nicht gleich direkt in die Rails Anwendung integrieren.

Um den constraint an ein Model zu binden, brauchen wir erst mal eine Migration und ein Model, welches für die IP Adressen zuständig ist.

class CreateHosts < ActiveRecord::Migration
  def change
    create_table :hosts do |t|
      t.string :hostname
      t.string :ip
      t.timestamps
    end
  end
end

Das entsprechende Model ist auch recht schnell gemacht…

class Host < ActiveRecord::Base
  validates :hostname, :presence => true
  validates :ip, :presence => true
end

Um nun die Überprüfung der remote IP machen zu können brauchen eine weitere Klasse, welche aus den Routes aufgerufen werden kann.

class IpRestrictor
  def self.matches?(request)
    Host.all.map{|h| h.ip}.include?(request.ip)
  end
end

Hier wird nur geprüft, ob die remote IP in der Tabelle hosts enthalten ist. Am besten man legt die Klasse in das extras Verzeichnis vom Rails Projekt.

Nun können einzelne Ressourcen an die Restriktionen in der Datei routes.rb gebunden werden…

constraints IpRestrictor do
  resources :customers
end

Die Ressource customers ist nun nur von IPs ansprechbar, welche in der hosts Tabelle gespeichert wurden.

Mit den constraints lassen sich recht einfach beliebige Restriktionen oder Checks einbauen, welche direkt in der Applikation eingebunden werden können, ohne dabei gleich den Webserver neu konfigurieren zu müssen.

Ein ähnliches Problem kann mit Ruby aufkommen. Sobald sich mehrere Projekte angehäuft haben, werden u.U. verschiede Ruby bzw. Rails Versionen, wenn nicht sogar jRuby benötigt. Sind alle Gems direkt im System installiert, kann das ganze schon ziemlich unübersichtlich werden.

Genau dieses Problem löst RVM, hierbei handelt es sich um ein Tool, mit welchem sich unterschiedliche Ruby Versionen bzw. Gems verwalten lassen. Alles wird hier direkt in das Home Verzeichnis des Benutzers installiert. Sobald RVM in die lokale .bashrc eingebunden ist, kann per Kommando die Ruby Installation gewechselt werden.

Die Installation von RVM ist mehr als einfach. Sofern Git installiert ist, kann direkt die letzte Version aus Git installiert werden:

$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-head )

Eine Installation über Tarball ist auch möglich:

$ bash < <( curl http://rvm.beginrescueend.com/releases/rvm-install-latest )

Für die dauerhafte Aktivierung von RVM, muss die lokale .bashrc bzw. .profile Datei angepasst werden.

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"  # This loads RVM into a shell session.

Mit dem Kommando

$ source ~/.rvm/scripts/rvm

kann die RVM Installtion initial eingelesen werden, ohne dass ein neuer Login notwendig ist. Jetzt sollte das Kommando

type rvm | head -1

die Ausgabe

rvm is a function

bringen. Dann ist RVM volständig installiert.

Als nächstes brauchen wir eine Ruby Installation. Um zu sehen, welche alle verfügbar sind, reicht das Kommando

$ rvm list known

Wenn wir z.B. Ruby 1.8.7 installieren wollen, können wir das wie folgt machen

$ rvm  install ruby-1.8.7
Installing Ruby from source to: ...
 
$ ruby -v
ruby 1.8.7 (2011-02-18 patchlevel 334) [i686-darwin10.6.0]

Damit unser Environment auch das neu installierte Ruby benutzt, und nicht u.U. ein im System installiertes, können wir mit RVM die Ruby Installation wechseln

$ rvm  ruby-1.8.7
Switching to ruby 1.8.7 334 ...

Auch das Kommando gem wird jetzt aus der RVM Installation verwendet, sodass alle Gems in das Home Verzeichnis installiert werden.

Nun zu der wirklich interessanten Funktion von RVM, den Gemsets. Nehmen wir an, es gibt ein Verzeichnis projects, in welchem ein Rails 2 Projekt (project_a) ist und ein Rails 3 Projekt (project_b). Um für project_a nun die Entwicklungsumgebung zu installieren, legen wir hierfür direkt im Projektverzeichnis eine .rvmrc an.

$ echo 'rvm 1.8.7@rails2 --create' > .rvmrc

Durch den Inhalt der .rvmrc weiss nun RVM, dass es, sobald man in dieses Verzeichnis wechselt, Ruby 1.8.7 mit dem Gemset rails2 verwenden soll. Noch haben wir allerdings keine Gems in dem Gemset. Um zum Gemset zu wechseln reicht

$ rvm 1.8.7@rails2

und Rails 2.3.8 kann einfach mit

$ gem install rails -v 2.3.8

instaliert werden.

Für unser Rails 3 Projekt machen wir das gleiche

$ echo 'rvm 1.8.7@rails2 --create' > .rvmrc
$ rvm 1.8.7@rails3
$ gem install rails

Für unsere Projekte sind nun verschiedene Rails Versionen hinterlegt und man muss nur in das entsprechende Projekt Verzeichnis wechseln, damit die korrekte Version für das Projekt verwendet wird

Bestückt ist der Server mit 4x 500GB SATA Festplatten (ad4,ad6,ad8 und ad10). Auf jeder Festplatte werden 3 Partitionen angelegt, einmal 25GB für das Betriebssystem, 1GB Swap und der Rest für ZFS.

Nachdem von der FreeBSD CD (ich verwende 8.1 amd64) gebootet wurde und sysinstall gestartet ist, kann die normale Installation gestartet werden. Sobald man bei der Partitionierung ist müssen die Platten wie folgt aufgeteilt werden:

1. die Platte (ad4) auswählen
2. Eine Partition mit 25000M erstellen, mit dem Typ 165
3. Eine Partition mit 1000M erstellen, ebenfalls Typ 165
4. Eine Partition mit restlich verfügbaren Platz erstellen, auch Typ 165
5. Partitions Manager mit q verlassen
6. BootMgr als Boot Manager auswählen (nicht Standard!)
7. Die obigen Schritte 2-6 nun nochmal für die restlichen Platten (ad6, ad8 und ad10) ausführen

Als nächstes können die Slices angelegt werden.

1. Ein Slice in ad4s2, ad6s2, ad8s2 und ad10s2 anlegen und als Swap definieren
2. Ein Slice mit 1024M in ad4s1 anlegen und als Mountpoint / setzen
3. Ein Slice mit 1024M in ad4s1 anlegen und als Mountpoint /tmp setzen
4. Ein Slice mit 2048M in ad4s1 anlegen und als Mountpoint /var setzen
5. Ein Slice mit dem restlich verfügbaren Platz anlegen und als Mountpoint /usr setzen

Es müssen keine weiteren Slices für die anderen Partitionen angelegt werden. Es nur wichtig, dass bei alle Platten adXs2 als Swap definiert wurde. Anschließend kann die Installation normal durchgeführt werden und das System mit sysinstall konfiguriert werden.

Sobald die Installation abgeschlossen ist, kann rebootet werden, allerdings muss wieder von der CD gebootet werden, damit die gmirror Konfiguration vorgenommen werden kann. Wenn die CD gebootet ist, FixIt in sysinstall auswählen und die Shell von CD starten.

In der Shell muss zuerst ein Symlink angelegt werden, damit gmirror in der Shell von CD funktioniert.

ln -s /dist/boot/kernel /boot

Danach kann gmirror geladen und initialisiert werden:

gmirror load
gmirror label -v gm0s1 /dev/ad4s1

Damit FreeBSD den Mirror beim Booten verwendet muss dies noch eingetragen werden:

mount /dev/mirror/gm0s1a /mnt
echo geom_mirror_load="YES" >> /mnt/boot/loader.conf

Schließlich muss noch die Datei /mnt/etc/fstab angepasst werden, dort stehen diese noch mit ad4 drin. Dort muss jeder Eintrag mit /dev/ad4s1X zu /dev/mirror/gm0s1X geändert werden.

Jetzt kann der Rechner direkt von der Festplatte gebootet werden. Sobald das System hochgefahren ist, können die anderen Platten in den Mirror eingehängt werden:

gmirror insert gm0s1 /dev/ad6s1
gmirror insert gm0s1 /dev/ad8s1
gmirror insert gm0s1 /dev/ad10s1
gmirror status

Es kann jetzt ein paar Minuten dauern, bis gmirror status angibt, dass Platten gespiegelt sind. Sobald das erledigt ist, können wir uns um ZFS kümmern.

echo zfs_enable="YES" >> /etc/rc.conf

Dadurch wird ZFS beim Starten aktiviert. Jetzt kann ein ZFS Raid Pool angelegt werden:

zpool create tank raidz ad4s3 ad6s3 ad8s3 ad10s3

Nach der Erstellung des Pools können die einzelnen Mountpoints angelegt werden.

zfs create tank/home
zfs create tank/stuff

Soll z.B. der Mountpoint tank/stuff komprimiert werden, dann kann dies wie folgt gemacht werden:

zfs set compression=gzip tank/stuff

Wenn z.B. die Home Verzeichnisse aus ZFS verwendet werden sollen, so können diese auch direkt unter /home gemountet werden:

zfs set mountpoint=/home tank/home

Sobald alles abgeschlossen ist, hat man ein wunderbares FreeBSD System, welches redundant über alle Festplatten installiert ist

Der vorherige Einstieg in die Proliant Klasse war der HP Proliant ML110, welcher in der Grundausstattung ca. 1000,- EUR kostet. Das unterbietet der Microserver bei weitem, dieser kostet nämlich nur knapp unter 300,- EUR. Durch den Preis wird er vermutlich auch in den Blick von Privatpersonen fallen, welche für Zuhause einen günstigen Server brauchen, z.B. als NAS.

Durch das kompakte Gehäuse ist der HP MicroServer bis zu 50 Prozent kleiner und leiser als vergleichbare Server, und verbraucht auch noch sehr wenig Strom. Im Ruhemodus verbraucht er ca. 28 Watt und unter Last ca. 40-50 Watt.

Auch die Hardware Ausstattung kann sich durchaus sehen lassen:

• AMD Athlon II Modell NEO N36L (2 Cores, 1,30 GHz, 1 MB L2, 15 W)
• 1GB DDR3 Speicher (max. 8GB)
• Integriertes SATA-RAID mit 4 Ports
• 2 zusätzliche PCI-Ex Steckplätze
• 4 SATA Festplatten Slots
• 5,25″ Zoll Laufwerksschacht

Die Bauweise erinnert etwas an die Shuttle XPC Systeme, allerdings erscheint mir den HP Server etwas mehr durchdacht zu sein. Das Mainboard lässt sich z.B. mit 2 Schrauben lösen und einfach herausziehen. Ziemlich praktisch, wenn man zusätzlichen Speicher einbauen will. Man muss dann nicht gleich das ganze Gehäuse zerlegen.

Meiner Meinung nach, hat HP mit dem Server einen Volltreffer gelandet. Für mich ist er der perfekte Server für Zuhause, und mit 4x 500GB SATA Festplatten hat man ausreichend Platz um Filme für die Playstation 3 bereit zu stellen

Allerdings bin ich vor kurzem über ein Video gestolpert, in welchem ein professioneller Fotograf ein Fashion Shooting mit dem iPhone versucht. Die Ergebnisse können sich sogar durchaus sehen lassen…

Apple nimmt damit komplett Abschied von der 19″ Bauweise. Warum verstehe ich allerdings überhaupt nicht. Warum sollte man sich ein Desktop Tower System in ein Rechenzentrum stellen, welches 12 Höheneinheiten braucht? Vor allem, wenn der Rechenzentrumsbetreiber womöglich noch nach Höheneinheiten abrechnet (ja da gibt es einige). Na gut, man könnte wahrscheinlich 2 Mac Pro Maschinen nebeneinander hinstellen, dass wären dann aber für 2 Server immer noch 12 Einheiten im Vergleich zu 2 mit je einem XServe.

In dem PDF Xserve Transition Guide von Apple werden die Leistungen der 3 Maschinen verglichen und es wird festgehalten, dass der Mac Pro wesentlich leistungsstärker als ein XServe ist, ausserdem wird die flexible Erweiterbarkeit des Tower System nochmal besonders hervorgehoben. Was einen aber auch nicht gerade verwundert, da erst vor kurzem die Mac Pro Reihe aktualisiert wurde und der XServe Reihe keine Aktualisierung gegönnt wurde.

Ich jedenfalls verstehe die Entscheidung nicht, ein Mac Pro braucht wesentlich mehr Platz in einem Rechenzentrum und ein Mac mini hat natürlich nicht die gleiche Leistung. Ein weiteres Killer Kriterium gegen die Desktop Systeme ist die fehlende redundante Stromversorgung. Wer verbaut heute noch einen Server in ein Rechenzentrum, wenn nur ein Netzteil vorhanden ist? Das könnte ziemlich böse Enden

Als Beispiel könnte man die Bestellung einer Pizza nehmen. Ein Kunde will eine Pizza über ein Formular bestellen. Im Formular werden alle verfügbaren Beläge in einer Liste mit jeweils eine Checkbox dargestellt, so dass der Kunde einfach per Klick auf die Checkboxen die gewünschte Kombination auswählen kann.

Die Models würden dann wie folgt aussehen:

app/models/pizza.rb

class Pizza < ActiveRecord::Base
  has_many :pizza_toppings, :dependent => :destroy
  has_many :toppings, :through => :pizza_toppings
end

app/models/topping.rb

class Topping < ActiveRecord::Base
  has_many :pizza_toppings, :dependent => :destroy 
  has_many :pizzas, :trhough => :pizza_toppings
end

app/models/pizza_topping.rb

class PizzaTopping < ActiveRecord::Base
  belongs_to :Topping
  belongs_to :Pizza
end

Nachdem die Beziehungen definiert sind können wir ohnen großen Aufwand die Beläge den Pizzen zuordnen:

<% form_for @pizza do -%>
  <% Topping.all.each do |topping| %>
    <div>
      <%= check_box_tag :topping_ids, topping.id, false, :name => 'pizza[topping_ids][]' %>
      <%= label_tag :topping_ids, topping.name %>
    </div>
  <% end %>
  <%= submit_tag %>
<% end %>

Wenn das Formular abgeschickt wird, dann wird jeder ausgewählter Belag durch PizzaToppings mit der Pizza verknüpft. Sobald allerdings in einem gespeicherten Datensatz einmal alle Checkboxen abgewählt werden, dann wird das nicht an den Controller geposted. Dies kann man aber leicht im Controller fixen:

app/controllers/pizza_controller.rb

@pizza.attributes = {'topping_ids' => []}.merge(params[:pizza] || {})

Nein, hab ich nicht. Der Wecker war wirklich auf 6:30 Uhr gestellt. Nach der Umstellung auf die Winterzeit hat das wohl den Wecker nicht mehr interessiert. Auf Golem habe ich heute auch gleich einen Artikel darüber gefunden. Scheinbar handelt es sich hier um einen Bug im iOS 4.1, der dafür sorgt, dass wiederholende Wecker Einstellungen eine Stunde zu spät starten.

Momentan gibt es dafür noch keinen Fix, man sollte wohl den Wecker eine Stunde früher einstellen. Im Apple Support Forum gibt es auch bereits eine Diskussion über den Bug.

Momentan hört man ja ziemlich viel, dass das iPhone 4 starke Probleme mit der verbauten Antenne hat. Das kann ich überhaupt nicht nachvollziehen. Bei mir funktioniert der Empfang einwandfrei, auch wenn die entsprechende Stelle komplett von der Hand umschlossen ist.

Was mir allerdings recht schnell aufgefallen ist, ist dass mein Philips Stereo Bluetooth Headset nicht mehr funktioniert. Mit dem iPhone 3G hatte ich nie Probleme, auch mit iOS 4 nicht. Versuche ich allerdings das Neue mit dem Headset zu koppeln funktioniert es überhaupt nicht. Die Geräte können sich nicht finden. Wenn man danach bei Google sucht, findet man auch tatsächlich einige Leute, die genau das gleiche Problem haben.

Scheinbar ist die Bluetooth Implementierung in iOS4 mit dem iPhone 4 etwas wählerisch bzw. fehlerhaft geworden. So berichten mehrere Personen darüber, dass sich Headsets gar nicht koppeln lassen, die Audio Qualität sehr schlecht ist und die Bluetooth Verbindung wieder abbricht.

Hoffentlich gibt es bald ein iOS Update, mit welchem die Probleme behoben werden :-/

Aber versucht es mal selber! Was kommt raus? Und bitte nicht kompilieren…

#include <stdio.h>
 
int func (int a, int b) {
	static int c = 1;
	return a + b * (c *= -1);
}
 
int main () {
	int a = 2, b = 3;
	int c = func(a, b);
 
	a *= a++;
	b *= ++b;
 
	printf("%d %d %d %d\n", a, b, c, func(a, b));
}