Category Archives: Allgemein

EVENTRAX: Luminanz Workshops

Die Luminanz GmbH verwendet ab heute offiziell unser Ticketverkaufssystem EVENTRAX, welches schon andere Anbieter (z.B. für ihre Veranstaltungen lizensierten.

EVENTRAX ist ein Ticketverkaufssystem, welches als Zahlungsdienste PayPal und Sofortü verwendet. Das System ist über ein einfaches Templating-System komplett an das Design einer Webseite anpassbar. Tickets werden automatisch nach Zahlungseingang mit Barcode & QR-Code generiert und an den Käufer im PDF-Format per eMail verschickt.

Mehr Informationen über EVENTRAX wird es bald in der offiziellen Sektion zu EVENTRAX hier auf der Seite geben.


SoundPitch OSX version 1.1.5 for Non-MAS users released

Today, we’re proud to announce that SoundPitch v1.1.5 for Mac OSX (non MacAppStore-Version) got released.

This new version introduces quick actions and range selection to play a specific part of a music file. Now, the OSX version of SoundPitch has the same feature set like the iOS version. MacAppStore users have to wait a few days until Apple approves the new version.

Have fun and keep on rockin’ with SoundPitch !


MongoDB with auto-sharding, routers and a configuration server

This mini howto will take you through the steps of using MongoDB and it’s auto-sharding feature. Sharding on MongoDB means the distribution of chunks of data between multiple server instances. It’s great if your server infrastructure outgrows or if you want automatic failover (with the usage of replica).

Step 1 – starting the configuration server

creating a configuration directory for mongo

mkdir -p ~/mongo/config

starting the configuration server on port 20000

mongod --dbpath ~/mongo/config/ --port 20000 --configsvr

Step 2 – the routing server

The routing server is the server to which all the applications servers (rails or whatever) connect to communicate with mongodb. The routing server itself connects to the configuration server to get its configuration.

 mongos --port 30000 --configdb localhost:20000

Step 3 – the shards

Now let’s create a new shard with it’s own data directory

mkdir -p ~/mongo/shard1_germany
mongod --dbpath ~/mongo/shard1_germany --port 10000

After the creation we tell the router to add the new shard. Please notice that the option allowLocal is just for development / testing environments. MongoDB doesn’t let you create clusters on localhost, so we need this option.

mongo localhost:30000/admin
db.runCommand({addshard : "localhost:10000", allowLocal : true})

Step 4 – creating a database

Connect to the router and switch to the database polyvision

mongo localhost:30000/admin
use polyvision

Please remember that the database is not saved / created yet, ’cause it has no data yet. So, let’s create a simple database entry. { username:"bierbrauer" } )

the result:

	{ "_id" : ObjectId("4e7825e97501770a31110f9f"), "username" : "bierbrauer" }

Using show dbs, you can see the database and it’s size

the result:

config	0.1875GB
polyvision	0.203125GB

switching back to the admin database

use admin

enable sharding for the polyvision database

db.runCommand({"enablesharding" : "polyvision"})

so if you want to shard the users collection of your polyvision database, use this command

db.runCommand( { shardcollection : "polyvision.users", key : {_id: 1} });

Now the collection gets sharded amoung all the sharding servers using it’s document id for the chunk algorithm. You may select others keys than the document id, for example the username. The call would look like this:

db.runCommand( { shardcollection : "polyvision.users", key : {username: 1} });

Step 5 – getting sharding information

To get information about our shards, connect to the router and enter the following command.


new website and SoundPitch iOS 1.2

Welcome to our new website. It was time to replace the old one so that we can share more information with you what’s going on in the labs of polyvision.

Beside our new website, there was another new update for SoundPitch for iOS with version number 1.2 Grab it while it’s still hot. The new release has some bug fixes reported by you, the users!

OSX Lion: Installing NGINX with PHP and Rails support

In this howto, I’ll show you how to install NGINX with PHP and Rails support. The difference to all these other howtos out there, is that we won’t use Passenger. Right, we will NOT use passenger. We’ll use Unicorn to connect NGINX with Rails. If you want to know more about Unicorn, read this from GitHub.

Step 1 – Homebrew
Grap a copy of homebrew and install it: Optional – Install MySQL Now install mysql if you haven’t yet.

brew install mysql

Step 2 – NGINX installation
OK, let’s do the NGinx installation, simple isn’t it ?

brew install nginx

Step 3 – PHP installation
Now, we’ll install a new version of php (the OSX version of php won’t be replaced, they will live side by side). Our version will have support for PHP’s FastCGI Process Manager.

mv php.rb `brew --prefix`/Library/Formula
brew install php --with-mysql --with-fpm

Go and grab a cup of coffee. The compilation of php may take some minutes depending on your machine. So, let’s start PHP-FPM with this command.

sudo /usr/local/sbin/php-fpm --fpm-config /usr/local/Cellar/php/5.3.8/etc/php-fpm.conf

Step 5 – NGINX configuration
Your nginx.conf shoud be placed in /usr/local/etc/nginx/nginx.conf. I provided you below an example config for using NGINX with phpmyadmin(or whatever you want) and a rails app

# This is example contains the bare mininum to get nginx going with
# Unicorn or Rainbows! servers. Generally these configuration settings
# are applicable to other HTTP application servers (and not just Ruby
# ones), so if you have one working well for proxying another app
# server, feel free to continue using it.
# The only setting we feel strongly about is the fail_timeout=0
# directive in the "upstream" block. max_fails=0 also has the same
# effect as fail_timeout=0 for current versions of nginx and may be
# used in its place.
# Users are strongly encouraged to refer to nginx documentation for more
# details and search for other example configs.

# you generally only need one nginx worker unless you’re serving
# large amounts of static files which require blocking disk reads
worker_processes 1;

# # drop privileges, root is needed on most systems for binding to port 80
# # (or anything < 1024). Capability-based security may be available for # # your system and worth checking out so you won’t need to be root to # # start nginx to bind on 80 user nobody nogroup; # for systems with a “nogroup” # user nobody nobody; # for systems with “nobody” as a group instead # Feel free to change all paths to suite your needs here, of course pid /tmp/; error_log /tmp/nginx.error.log; events { worker_connections 1024; # increase if you have lots of clients accept_mutex off; # “on” if nginx worker_processes > 1
# use epoll; # enable for Linux 2.6+
# use kqueue; # enable for FreeBSD, OSX

http {
# nginx will find this file in the config directory set at nginx build time
include mime.types;

# fallback in case we can’t determine a type
default_type application/octet-stream;

# click tracking!
access_log /tmp/nginx.access.log combined;

# you generally want to serve static files with nginx since neither
# Unicorn nor Rainbows! is optimized for it at the moment
sendfile on;

tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
tcp_nodelay off; # on may be better for some Comet/long-poll stuff

# we haven’t checked to see if Rack::Deflate on the app server is
# faster or not than doing compression via nginx. It’s easier
# to configure it all in one place here for static files and also
# to disable gzip for clients who don’t get gzip/deflate right.
# There are other other gzip settings that may be needed used to deal with
# bad clients out there, see
gzip on;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 500;
gzip_disable “MSIE [1-6]\.”;
gzip_types text/plain text/html text/xml text/css
text/javascript application/x-javascript

# this can be any application server, not just Unicorn/Rainbows!
upstream app_server {
# fail_timeout=0 means we always retry an upstream even if it failed
# to return a good HTTP response (in case the Unicorn master nukes a
# single worker for timing out).

# for UNIX domain socket setups:
server unix:/tmp/.sock fail_timeout=0;

# for TCP setups, point these to your backend servers
# server fail_timeout=0;
# server fail_timeout=0;
# server fail_timeout=0;

# phpmyadmin
server {
listen 8080;
server_name localadmin;

location / {
root /opt/www/phpmyadmin;
index index.php index.html index.htm;

location ~ .php {
include fastcgi_params;
fastcgi_index index.php;
fastcgi_param SCRIPT_FILENAME /opt/www/phpmyadmin/$fastcgi_script_name;

server {
# enable one of the following if you’re on Linux or FreeBSD
listen 8080 default; # for Linux
# listen 80 default accept_filter=httpready; # for FreeBSD

# If you have IPv6, you’ll likely want to have two separate listeners.
# One on IPv4 only (the default), and another on IPv6 only instead
# of a single dual-stack listener. A dual-stack listener will make
# for ugly IPv4 addresses in $remote_addr (e.g “:ffff:″
# instead of just “”) and potentially trigger bugs in
# some software.
# listen [::]:80 ipv6only=on; # deferred or accept_filter recommended

client_max_body_size 4G;
server_name localocs;

# ~2 seconds is often enough for most folks to parse HTML/CSS and
# retrieve needed images/icons/frames, connections are cheap in
# nginx so increasing this is generally safe…
keepalive_timeout 5;

# path for static files
root /opt/caesar/public;

# Prefer to serve static files directly from nginx to avoid unnecessary
# data copies from the application server.
# try_files directive appeared in in nginx 0.7.27 and has stabilized
# over time. Older versions of nginx (e.g. 0.6.x) requires
# “if (!-f $request_filename)” which was less efficient:
try_files $uri/index.html $uri.html $uri @app;

location @app {
# an HTTP header important enough to have its own Wikipedia entry:
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

# enable this if and only if you use HTTPS, this helps Rack
# set the proper protocol for doing redirects:
# proxy_set_header X-Forwarded-Proto https;

# pass the Host: header from the client right along so redirects
# can be set properly within the Rack application
proxy_set_header Host $http_host;

# we don’t want nginx trying to do something clever with
# redirects, we set the Host: header above already.
proxy_redirect off;

# set “proxy_buffering off” *only* for Rainbows! when doing
# Comet/long-poll/streaming. It’s also safe to set if you’re using
# only serving fast clients with Unicorn + nginx, but not slow
# clients. You normally want nginx to buffer responses to slow
# clients, even with Rails 3.1 streaming because otherwise a slow
# client can become a bottleneck of Unicorn.
# The Rack application may also set “X-Accel-Buffering (yes|no)”
# in the response headers do disable/enable buffering on a
# per-response basis.
# proxy_buffering off;

proxy_pass http://app_server;

# Rails error pages
error_page 500 502 503 504 /500.html;
location = /500.html {
root /path/to/app/current/public;

Step 6 – Starting NGINX

sudo /usr/local/sbin/nginx -c /usr/local/etc/nginx/nginx.conf

if you want to stop NGINX, use this command

sudo /usr/local/sbin/nginx -s stop

Step 7 – Let’s do it the unicorn way
Install the gem and copy an example configuration in your rails app directory. The configuration should be placed in /PATH_TO_RAILS/APP/config.

gem install unicorn
curl -o config/unicorn.rb

Edit the unicorn.rb to your desire ,it’s well commented and please remember to change the port to 8081! NGINX will run on port 8080 with the above nginx.conf, so unicorn cun’t run on the same port. The line you have to change for the port should look like this:

listen 8081, :tcp_nopush => true # from 8080 to 8081

Finally start unicorn und point your browser to http://localocs:8080 or http://localadmin to watch the working result. Please remember that you can change localocs or localadmin to whatever you like, but don’t forget to edit your /etc/hosts file in any case !

unicorn_rails -c ./config/unicorn.rb -D

Using Magento SOAP-API with Ruby and Savon


Install savon and then proceed with the ruby code snippet.

gem install savon

The code

# Magento API can be found @
require 'rubygems'
require 'savon'

Savon.configure do |config|
  config.log = false            # disable logging
  #config.log_level = :info      # changing the log level
  #config.logger = Rails.logger  # using the Rails logger

client = do
  wsdl.document = "http://HERE.COMES.YOUR.SERVER/index.php/api/?wsdl"

response = client.request :login do
  soap.body = { :username => 'soapuser', :apiKey => 'whatthefuck' }
if response.success? == false
  puts "login failed"

session =  response[:login_response][:login_return];

response = client.request :call do
  soap.body = {:session => session,:method => 'catalog_product.list' }

# fetching all products
if response.success?
  # listing found products
  response[:call_response][:call_return][:item].each do |product|
    puts "-------------------------------------------"
    product = product[:item]
    product.each do |pkey|
        puts "#{pkey[:key]} -> #{pkey[:value]}"

#logging out
response = client.request :endSession do
  soap.body = {:session => session}
puts response.to_hash