Month: April 2012

gesehen in der speisekarte eines ICE boardbistros. “vegetarisch” hin zu schreiben waere ja zu einfach gewesen.

da kam wohl die beamtensprache aus der alten zeit wieder durch ;-I
und um sich mit der erklaerung zu “bio” wohl nicht um kopf und kragen zu reden (bzw schreiben), faellt diese etwas “anders” aus:

auch noch nicht gesehen. na dann besser mal abstand halten…

gut gemeint…

aber kommt wohl nicht gut an?

oder ich hab da was falsch verstanden? 85 wiederverwendete handtuecher in einem jahr in dem ganzen hotel? das ist ja nicht der reisser… was ist nur mit den gaesten los?

regionales kartenmaterial auf papier.

und heute wollte ich schauen, ob man sowas auch mit dem iphone fotografieren kann.

bissi verrauscht, aber geht 😉

schon gewusst? es heisst, dass man bei abnehmendem mond das beste holz schlagen kann.

den kalender von owncloud nutze ich jetzt testweise schon via caldav. die kontakte via carddav folgen die tage. gestern hab ich ein bischen mit der webdav funktionalitaet rumgespielt…

zuerst muss man mal diese untypische url mounten: https://SERVERNAME/files/webdav.php

dann hab ich nen sack voll dateien parallel da hin kopieren wollen… mit solchen ergebnissen:

das ist in dieser form fuer mich vorerst nicht nutzbar…

nur mal so gepostet, damit ichs irgendwo niedergeschrieben habe.. fuer die meisten leser eher unbrauchbar 😉

nach ein paar tagen war wiedermal ein update des diaspora pods faellig. da laeuft ja kein update wie das andere. und ich stehe mit ruby und java nicht wirklich in einem guten verhaeltnis. naja..

normalerweise ging das update so (in meinem fall…):

erstmal die laufende pod instanz killen, dann

cd /home/diaspora/diaspora
git pull origin master
DB="mysql" bundle install --without development,test
RAILS_ENV="production" DB="mysql" bundle exec rake db:migrate
RAILS_ENV=production DB="mysql" bundle exec jammit
chown diaspora.diaspora /home/diaspora/diaspora/ -R

und die pod instanz wieder starten.

diesmal brachte das

DB="mysql" bundle install --without development,test

folgenden fehler:

Bundler could not find compatible versions for gem "bundler":
  In Gemfile:
    bundler (~> 1.1.0) ruby

  Current Bundler version:
    bundler (1.0.21)

This Gemfile requires a different version of Bundler.
Perhaps you need to update Bundler by running `gem install bundler`?

also erstmal

gem install bundler

… ausgefuehrt. dann eins weiter in der “normalen” update liste

RAILS_ENV=production DB="mysql" bundle exec jammit

brachte diesen fehler:

/var/lib/gems/1.8/gems/bundler-1.1.3/lib/bundler/rubygems_integration.rb:147:in `gem': jammit is not part of the bundle. Add it to Gemfile. (Gem::LoadError)
	from /var/lib/gems/1.8/bin/jammit:20

also jammit ins gemfile eingetragen.
danach ein:

bundle install

…ausgefuehrt und nach einem wiederholten

RAILS_ENV=production DB="mysql" bundle exec jammit

kam dann das:

/var/lib/gems/1.8/gems/execjs-1.3.0/lib/execjs/runtimes.rb:50:in `autodetect': Could not find a JavaScript runtime. See https://github.com/sstephenson/execjs for a list of available runtimes. (ExecJS::RuntimeUnavailable)
	from /var/lib/gems/1.8/gems/execjs-1.3.0/lib/execjs.rb:5
	from /var/lib/gems/1.8/gems/uglifier-1.2.4/lib/uglifier.rb:3:in `require'
	from /var/lib/gems/1.8/gems/uglifier-1.2.4/lib/uglifier.rb:3
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit/dependencies.rb:22:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit/dependencies.rb:22
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit.rb:221:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/lib/jammit.rb:221
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/../lib/jammit/command_line.rb:2:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/../lib/jammit/command_line.rb:2
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/jammit:3:in `require'
	from /var/lib/gems/1.8/gems/jammit-0.6.5/bin/jammit:3
	from /var/lib/gems/1.8/bin/jammit:21:in `load'
	from /var/lib/gems/1.8/bin/jammit:21

das verlangte

gem install execjs

ausgefuehrt.. brachte mich aber kein stueck weiter. auf eine empfehlung hin dann node.js installiert. leider gabs kein debian 6.0 package, also musste ich zur manuellen installation greifen. die hab ich hier gefunden.

git clone https://github.com/joyent/node.git
cd node
# 'git tag' shows all available versions: select the latest stable.
git checkout v0.7.7
./configure --openssl-libpath=/usr/lib/ssl
make
make test
sudo make install

und der naechste versuch…

RAILS_ENV=production DB="mysql" bundle exec jammit

brachte dieses ergebnis:

Could not find the asset configuration file "/home/diaspora/diaspora/config/assets.yml"

auf rat von denshub im diaspora irc channel ein

bundle exec rake assets:precompile

ausgefuehrt, was auch wieder nen fehler spuckte:

rake aborted!
/var/lib/gems/1.8/gems/heroku_san-2.1.1/lib/tasks.rb:112: syntax error, unexpected ':', expecting kEND
          puts stage.push_config RACK_ENV: stage.name

er meinte dann, dass ich doch lieber ne neuere rube version verwenden sollte. gibt mittlerweile auch ein howto fuer squeeze.

es ist taktisch unklug, die ruby version dem system package manager zu ueberlassen, weshalb man doch besser rvm benutzen sollte. die wesentliche installation von rvm und ruby 1.9.2 ist laut dieser anleitung:

bash <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer) stable
echo "[[ -s '$rvm_path/scripts/rvm' ]] && . '$rvm_path/scripts/rvm' # Load RVM function" >> ~/.bashrc
source ~/.bashrc
rvm install ruby-1.9.2-p290
rvm use ruby-1.9.2-p290@global

danach kommt beim wechseln in das diaspora verzeichnis diese meldung:

==============================================================================
= NOTICE                                                                     =
==============================================================================
= RVM has encountered a new or modified .rvmrc file in the current directory =
= This is a shell script and therefore may contain any shell commands.       =
=                                                                            =
= Examine the contents of this file carefully to be sure the contents are    =
= safe before trusting it! ( Choose v[iew] below to view the contents )      =
==============================================================================
Do you wish to trust this .rvmrc file? (/home/diaspora/diaspora/.rvmrc)
y[es], n[o], v[iew], c[ancel]> y

welche mit ja zu bestaetigen ist. dann noch ein freundliches:

bundle install

mein naechstes update wird verrmutlich so aussehen:

su - diaspora
git pull origin master
DB="mysql" bundle install --without development,test
RAILS_ENV="production" DB="mysql" bundle exec rake db:migrate
bundle exec rake assets:precompile

und diese geschichte ging noch gefuehlte stunden lang weiter. nach dem starten hatte ich nur noch 500er fehler. die shell, in der ich den server gestartet hatte, war noch mit der alten ruby version verheiratet. die netten leute im diapsora irc channel haben mich aber noch ein bischen supportet. logfiles wurden ueber pastebin ausgetauscht usw… ohne die jungs waere ich hoffnungslos aufgeschmissen gewesen. danke nochmal an DenSchub und MrZYX fuer die kompetente hilfe.

letztendlich wars noch ein fehler im source, der behoben wurde, als wir noch an der fehlersuche waren. ein freundliches git pull mit allem was dazugehoert brachte dann abhilfe.

kurze gedankenstuetze, damit ich mich irgendwann noch dran erinnern kann:

assets=javascript, bilder & css
jammit=js&css kompilieren (wir benutzen ne meta sprache für css: sass) und komprimieren
rails 3.1: asset pipeline: neuer weg um den gesamten kram zu handlen
dadrin: neuer weg zum zusammenstöpseln und komprimieren von dem ganzen kram
diasporas upgrade auf rails 3.1: die bildchen sind in der neuen verzeichnisstruktur verloren gegangen
aber halt im quellcode noch benutzt worden
das war der fehler den du gesehn hast (eh, mir fehlen die bilder)

ja, diaspora ist noch alpha. aber fuer jemanden, der sich zwar mit linux auskennt, aber mit ruby, java und dem ganzen kram nichts am hut hat, ist es echt nicht einfach, solch einen pod in diesem entwicklungsstadium zu betreiben. ich werde erstmal die mailingliste abonnieren, damit ich gravierende aenderungen vielleicht vorher mitbekomme. vorausgesetzt, ich finde ueberhaupt die zeit dazu, mich intensiver damit zu beschaeftigen. man hat ja noch genuegend andere mailinglisten etc. zu lesen.

in worten: achthundertzwoelftausendzweihundertfuenfundneunzig.

damit koennte sich ein erwachsener mann mit viel energiebedarf weit ueber ein jahr lang ernaehren. rein rechnerisch versteht sich. bei dem gedanken kommts mir fast hoch.

so.. da ich weder google fuer meinen kalender benutzen, noch einen exchange server (weiter) betreiben oder sonst irgendwelche “fremden” online dienste nutzen moechte, werde ich nun mal mein glueck mit owncloud versuchen. owncloud kann einen kalender via caldav zur verfuegung stellen und bietet auch eine weboberflaeche dafuer an. das iphone, ipad und auch die osx eigene iCal.app koennen mit caldav umgehen. also ran an die buletten und erstmal sehen, wie ich meine ganzen termine aus dem exchange da rueber bekomme. zufaellig hatte ich auf meinem alten mac noch das office paket mit entourage installiert. wenn das drauf ist, bietet die iCal.app eine funktion “Aus Entourage importieren..” an.

da mein kalender im exchange schon etwas laenger in betrieb ist, habe ich stolze 6475 eintraege zu ex- bzw. importieren. lustigerweise war das teil damit fast zwei tage (!!!) mit 100% cpu last beschaeftigt. keine ahnung, was das soll. zuerst dachte ich, dass der vorgang abgeschmiert waere, aber irgendwann hab ich festgestellt, dass sich der fortschrittsbalken doch noch bewegt.

wenn man das getan hat, hat iCal.app erstmal einen neuen, lokalen Kalender namens “Entourage” angelegt und alle termine dort rein importiert. diese muessen dann erst noch in eine datei exportiert werden:

(klick auf “Kalender” –> rechte maustaste auf “Entourage” –> exportieren)

warum muss ich erst importieren und dann exportieren? natuerlich, damit ich das wieder importieren kann! 😉

erst beim “normalen” import hat man naemlich die moeglichkeit, den kalender auszuwaehlen, in den importiert werden soll.

dann die vorhin exportierte datei auswaehlen:

und in den kalender importieren, in den man es haben will. in dem fall ist das der “default” kalender meiner owncloud instanz.

that’s it. sechseinhalb tausend kalendereintraege. mal sehen, wie performant die geschichte ist. das iphone hat ein moment gebraucht, bis es den kalender initial hatte. vor allem will ich mal drauf achten, was da fuer ein traffic entsteht und wie schnell die synchronisierung i.d.r. dauert. vielleicht ist es an der zeit, mal die passenden rfc’s zu schmoekern…

ja nee… die brocken lagen bei der heutigen rc-tour schon rum.

aber der kollege fuso hat auch was gemacht, was nicht jeder kann. der ist da so “reingefahren”…

achso… das resultat der heutigen ausfahrt… zahnraeder am motor ohne zaehne… wie schonmal 😉