FOSSASIA 2014 in Phnom Penh, Cambodia

From February 28 till March 2 2014 I attended FOSSAsia in Phnom Penh, Cambodia.

FOSSAsia is a 2 days conference plus 1 day of workshops dedicated to Free and Open Source Software held in Phnom Penh, the capital of the Kingdom of Cambodia.

If your familiar with FOSDEM in Brussels, FOSSAsia is quite similar in atmosphere, just a little bit warmer with temperatures around 33°C during the days.

This year over 71 international and 15 cambodian speakers shared their knowledge in 121 Talks – that is 8 full tracks per day! - with 839 participants attending from all over Asia.

All three days were seriously packed, hot and delightful. Here’s how I remember them:

Feb 27: FOSSASIA Speakers Pre-Meetup

FOSSASIA Speakers Pre-Meetup

It all started with the speakers gathering in the Angkor International Hotel.

Seing all the speakers from all over the world in one place mingle together was a special moment for me.

A lot of shaking hands and cheering. FOSS craziness international. Awesome!

When the event ends some of us take the chance to have another last drink(tm) in the bar area.

The result: A short night with awesome talks and great fun.

Feb 28: 1st Day: Grand Opening and a Full house!

FOSSASIA Norton University

On Friday 28 February FOSSASIA officially started. The mainhall was very growded and I am impressed how many people actually attend.

In the afternoon I give my talk about ‘Implementing Continuous Delivery’ in front of an awesome growd.

The room is packed and I am amazed that so many people are interested.

Although I already gave this talk several times in Europe this time is special. I am a bit concerned that my talk is too technical and that I may not be able to transport the awesomeness of the topic.

My concerns are totally unnecessary. There’s no need to worry at all. I have the impression that everybody is full ears. Time flys by, we discuss a lot of interesting questions and I get very good feedback on my talk.

We also manage to -improvise- play a little CD game in order to get a sense for a Delivery Pipeline and Process Automation.

All in all it’s great fun and I remind my self - once again - to just relax and everything will be fine.

We’re crusin’ - The Speaker’s Dinner

FOSSASIA Speaker's Dinner

In the evening we enjoy a nice ‘Speakers Dinner’ while cruising on the calm Tonlé Sap river by boat.

There are nice talks all along. The weather is nice and calm. Khmer Disco Music plays in the background.

While enjoying the scenery I drift away in thoughts about the impressions I got over the last weeks.

The software scene in Asia is bigger and much more ‘alive’ than I thought.

Mar 1: 2nd Day: More Talks and Social Event

FOSSASIA Social Event

Being slightly excausted by the travels and preparations of the last weeks I oversleep and decide to rest my heated body for today.

As a reminder: It’s very easy to get dehydrated - especially when wearing jeans all day long.

I re-join FOSSAsia for the Social Event in the evening, catch a few good talks and (soft) drinks and then go straight into bed in order to renew some energy for tomorrows hack day.

Mar 2: 3rd Day: FOSSASIA Hack day

FOSSASIA Hack day

The ‘conference’ part is over. We now gather for some “sunday hacking”.

Topics include:

  • FirefoxOS Workshop
  • Wifi Mesh Networks
  • Web Solutions
  • Graphic Design
  • OpenStreetMap
  • Fedora Linux

Again the rooms are packed and the athmoshere is loaded with excitement.

After two days in these hot conditions this is really amazing in my opinion.

I’m particular interested in working on Mesh-Networks and FirefoxOS.

Thus I attend Bastian Bittorf where we are setting up a Mesh-Network from scratch.

He brought the routers over from Germany. After connecting the cables, updating the router OS and rebooting the devices the mesh network just works! Cool!

FOSSASIA Hack day Wifi Mesh Networks

Follow @freifunk for more updates on this exciting project.

Later in the evening I join the Firefox Crew and learn how to prepare a FirefoxOS App.

IMG_1776

It’s pretty straightforward when you know a little bit of HTML, CSS and JavaScript and I really like the idea of using these technologies to build apps on a low cost phone.

Thanks to Mozilla for letting me play with a FirefoxOS phone! It feels very very light (even though the one I get is a heavy one) and is intuitive to use. My iPhone instantly feels too clumsy.

Looking forward to see how FirefoxOS gets adopted in the mobile market.

All in All

IMG_1803

I am super proud that I could attend FOSSASIA and be a part of it.

I got a slight insight of how the Asian Open Source / Hacker Community works and I definitely want to know more.

There’s so much going on here.

Some special moments I catched on twitter during FOSSASIA:

Thanks!

Big thanks to Hong Phuc, Mario Behling and all helping hands that made the event so pleasant!

It was a great experience and I am looking forward for the next FOSSASIA events!

Follow up

Follow FOSSAsia on

More pictures on Flickr: https://www.flickr.com/photos/tags/fossasia2014/

Continuous Delivery Workshop Vorbereitungen

Überblick

Diese Anleitung führt Sie durch die Installation für das Beispielprojekt zum ‘Continuous Delivery’ Workshop.

Während des Workshops deployen Sie eine Website über folgende Stages:

dev -> ci -> qa -> prod

Anforderungen

Für den Praxisteil des Workshops benötigen Sie einen Laptop und folgende Software:

  • VirtualBox installieren: https://www.virtualbox.org/wiki/Downloads
  • Vagrant installieren: http://www.vagrantup.com/downloads.html
  • Sorgen Sie für ausreichend Platz auf Ihrer Festplatte. Wir empfehlen für den Workshop mindestens 2.5GB freien Festplattenspeicher.
  • Stellen Sie sicher, dass Ihr USB-Port funktioniert. Wir bieten das VM-Image auf einem USB-Stick an.
  • Stellen Sie sicher, dass die Ports 8181 und 8153 frei sind. Wir benötigen diese Ports zum Aufrufen der Beispiel-Applikation auf der Virtuellen Maschine

Dateistruktur

    .
    ├── README.md                     Allgemeine Anleitungen
    ├── Vagrantfile                   Konfiguration zum Starten der VM
    ├── app                           Beispiel-Applikation für den Workshop
    └── vendor                        Externe Dateien von Drittherstellern
        ├── Vagrant-1.4.3.dmg
        ├── Vagrant_1.4.3.msi
        ├── vagrant_1.4.3_i686.deb
        ├── vagrant_1.4.3_i686.rpm
        ├── vagrant_1.4.3_x86_64.deb
        ├── vagrant_1.4.3_x86_64.rpm
        ├── VirtualBox-4.3.2-90405-Win.exe
        ├── VirtualBox-4.3.2-90405-OSX.dmg
        └── ubuntu-12.04.2-amd64.box

Das Beispielprojekt verwenden

  • Verzeichnis cd_workshop vom USB Stick auf die lokale Festplatte kopieren
  • USB Stick auswerfen und an den nächsten Teilnehmer geben
  • VirtualBox und Vagrant installieren (falls noch nicht vorhanden)
  • Terminal öffnen und in den Workshop Ordner wechseln
  • Den Befehl vagrant up auf dem Terminal ausführen
    Nun startet die Virtuelle Maschine.
  • Öffnen Sie http://localhost:8153/ im Browser um den CI-Server zu sehen
  • Öffnen Sie http://localhost:8181/, um eine Übersicht des Beispiel-Projektes zu sehen:
http://localhost:8181/workshop-dev  - Current status in `app`
http://localhost:8181/workshop-ci   - Stage after build
http://localhost:8181/workshop-qa   - Stage after tests
http://localhost:8181/workshop-prod - Production
  • Verbinden Sie sich per SSH auf die Virtuelle Maschine mit vagrant ssh.
    Sie sind nun mit dem Benutzer vagrant angemeldet und sollten sämtliche für den Workshop relevanten Befehle ausführen können.
    Falls Sie sudo benötigen, können Sie ohne Passwort root Benutzer werden.
  • Für den Fall, dass Sie einmal nach dem Passwort gefragt werden:
Benutzer: vagrant
Passwort: vagrant
  • Wechseln Sie in das Verzeichnis /vagrant/app, führen Sie die Änderungen aus und pushen Sie diese in das Git-Repository:
cd /vagrant/app

git add .
git commit -m "Update content"
git push origin master
  • Ihre Änderungen aktivieren den CI-Server. Wechseln Sie auf die Web-Oberfläche und schauen Sie dabei zu, wie das erste Paket gebaut wird: http://localhost:8153/view/CD-Pipeline/
  • Bauen Sie die Applikation weiter aus und wiederholen Sie den Schritt, wenn Sie mit den Änderungen zufrieden sind.
    Sie können die Applikation über Ihren gewohnten Editor oder Ihre IDE auf dem Host bearbeiten und die Änderungen dann auf der Maschine pushen.
  • Sobald Sie mit dem Ergebnis zufrieden sind, stoßen Sie das Deployment auf die weiteren Stages an.

Häufige Fragen

F: Ist die VirtualBox zwingend notwendig oder kann man das auch mit VMWare Workstation arbeiten?
A: Wir benutzen für den Workshop das kostenfreie VirtualBox. VMWare Workstation unterstützen wir nicht.

Continuous Delivery Workshop Preparations

Overview

These instructions will guide you through an example project for the ‘Continuous Delivery’ workshop.

You will deploy the website through several stages:

dev -> ci -> qa -> prod

Requirements

To start the workshop right away we ask you to bring a laptop and prepare it as follows:

  • Install VirtualBox: https://www.virtualbox.org/wiki/Downloads
  • Install Vagrant http://www.vagrantup.com/downloads.html
  • Ensure that you have at least 2.5GB of free space on your hard disk
  • Ensure that your USB port is working so that we can provide the image via a portable Hard Drive/Stick.
  • Make sure you don’t use local ports like 8181 and 8153. We need these ports for accessing the apps on the VirtualMachine

File structure of the example project

.
├── README.md                     General instructions
├── Vagrantfile                   Config for starting the VM
├── app                           Example app for the workshop
└── vendor                        External files from vendors
    ├── Vagrant-1.4.3.dmg
    ├── Vagrant_1.4.3.msi
    ├── vagrant_1.4.3_i686.deb
    ├── vagrant_1.4.3_i686.rpm
    ├── vagrant_1.4.3_x86_64.deb
    ├── vagrant_1.4.3_x86_64.rpm
    ├── VirtualBox-4.3.2-90405-Win.exe
    ├── VirtualBox-4.3.2-90405-OSX.dmg
    └── ubuntu-12.04.2-amd64.box

How to use the example project

  • Insert USB Stick
  • Copy folder cd_workshop to local disk
  • Eject the USB stick and pass it to the next student
  • Install VirtualBox and Vagrant from vendor (if not installed already)
  • Open the terminal and go to the folder on your local disk
  • Run vagrant up on the terminal
    Now the virtual machine starts up and consumes the local ports. It fetches the .box file from ./vendor to create the VM
  • Open http://localhost:8153/ in your browser to see the CI-Server working
  • Open http://localhost:8181/ to see the umbrella page for our web project we will working on
http://localhost:8181/workshop-dev  - Current status in `app`
http://localhost:8181/workshop-ci   - Stage after build
http://localhost:8181/workshop-qa   - Stage after tests
http://localhost:8181/workshop-prod - Production
  • SSH into the machine with vagrant ssh.
    You should be able to run every command that is needed for the workshop as user vagrant.
    You can use sudo without a password.
  • In case you need the username and password:
Username: vagrant
Password: vagrant
  • Go to the folder /vagrant/app, make changes and push them
cd /vagrant/app

git add .
git commit -m "Update content"
git push origin master
  • See the CI-Server in action while fetching the changes and running the tests: http://localhost:8153/view/CD-Pipeline/
  • Improve the application and push the updates, when you are satisfied with your results.
    You can edit the code directly on the host in your favourite editor / IDE.
  • Approve the changes by starting the deployment to the next stage

FAQ

F: Do I really need VirtualBox or may I use VMWare Workstation as well?
A: We are using VirtualBox for our workshop. VMWare Workstation is currently not supported.

Why dislike Avatars

While working at a customer and I supported several teams.

Every time I switched teams, I got a new ‘avatar’ on the Scrum board.

It used to happen that Team One likes ‘southpark’ avatars whereas Team Two favours ‘The Simsons’.

So I stralled hours through the internets to find my perfect avatar.

Besides the fact that I do not watch nor favour any of those shows (seriously) I found the search totally annoying and a total waste of time.

Downsides

  • I need to search for it
  • I regularly forgot who is who on the board
  • Some of them look quite similar and are hard to distinguish I often heard “Who’s assigned to this issue? Me? No, him!” Aaaarg!
  • it is kind of insulting to be threaded as a cartoon character (depends on your culture probably)
  • the coolest avatars have been taken anyways :)

Even worse

People got upset when I used an avatar that “didn’t fit” into the team’s schema.

Upsides

  • Maybe there’s a kind of ‘fun’ attached I just don’t get
  • Helps people to ‘dissociate’ from their tasks which can help them to cope with responsibility

Bottom line

Ops life is hard enough.

Stop make it more confusing with artificial, ridiculous cartoon avatars.

Better use real photos and real names to communicate and to streamline communication.

Getting things done faster is much more fun in my opinion than having cartoons on the wall.

If you do like Avatars, I’d really like to hear your opinion on how they cheer you up.

Spring cleaning

Hi there and welcome to my GitHub blog!

I moved away from Posterous to GitHub pages because Posterous closes down end of April 2013.

I decided against migrating old content to my new blog, because I felt like having a fresh start.

While working on GitHub I also removed the following repos and forks from my GitHub space:

ctrabold/ter-rdf-schema
ctrabold/t3con12-asia-logging
ctrabold/fpm-recipes
ctrabold/tw-twitter-graph
ctrabold/typo3-ext-barcode
ctrabold/chef-graylog2
javascript_testsuite → ctrabold/javascript-testsuite
ctrabold/clojure-koans
ctrabold/rchh2011-vagrant
ctrabold/chef-redmine
ctrabold/poltergeist
ctrabold/vagrant
ctrabold/chef-jenkins
ctrabold/gitlabhq
ctrabold/chef-fundamentals
ctrabold/greenscreen
ctrabold/vagrant-vbguest
ctrabold/application_ruby
ctrabold/pivotal_workstation
ctrabold/travis-cookbooks
ctrabold/curriculum
ctrabold/jruby-testsuite
ctrabold/chef-gitblit
ctrabold/bootstrap
ctrabold/www.vagrantup.com
ctrabold/tool-repos
ctrabold/cookbook-elasticsearch
ctrabold/redmine
ctrabold/persona-plugin
ctrabold/munin-graphite
ctrabold/logstash-cookbook
ctrabold/t3ski-workshop-example
ctrabold/chef-lxc
ctrabold/vagrant-docs-old
ctrabold/typo3-status

These repos were inactive, orphaned, outdated and rather confusing than useful.

Please update your forks and .git/config in order to use their original repos if you like to contribute.

librarian-chef vs. berkshelf

This is a brief comparison between librarian-chef an berkshelf to point out the main differences in managing cookbooks. Please refer to the offical announcement for berkshelf for a in-depth introduction / comparison for all features.

Rational

I’m a big fan of librarian-chef and I currently use it in every chef-driven project.

It helped my a lot taking back control when I got -confused- overwhelmed by cookbooks. Thanks to librarian-chef I finally could seperate my patched cookbooks, get rid of git-submodules in a sensible way with an easy to manage Cheffile that can be stored in version control. Everything was wunderbar!

When I first heard of berkshelf via this blog post I got slightly confused: Is someone re-inventing the wheel here? It turned out that I should have read the offical announcement for berkshelf before posting my Tweet :) Hope this post helps you as well.

What is the difference?

Both berkshelf and librarian-chef download cookbooks from various locations. If that sounds totally new to you I highly encourage you to adopt either one of thoses tools to your workflow. The main difference is where and how the cookbook files are stored in the current repository / project:

librarian-chef

librarian-chef will load all cookbooks defined in a Cheffile to a cookbooksfolder within the current directory.

It also helps you keeping the cookbooks folder in shape by providing commands to show you outdated cookbooks etc. To do so it caches the checksums of theses files in a tmp folder within the current folder.

I did not find a way to change the default “cookbooks” folder which can be a bit painful if you want a different folder strucuture.

berkshelf

berkshelf (by default) loads all cookbooks from the Berksfile into one centralized repository in ~/.berkshelf (customize via BERKSHELF_PATH) and NOT into the current directory.

After downloading all the cookbooks and their dependencies you can link those into whatever folder you like with berks install --shims your_desired_path. Default is cookbooks. Berkshelf creates hard links to cookbooks in the repository. You have to take care of outdated cookbooks etc.

Final thoughts

I’m very new to Berkshelf (just installed the gem, run the examples provided on their website) and yes it looks very promising.

Berkshelf’s aproach with ONE repository that builds “the single source of truth” for all your chef-repos makes sense to me because these cookbooks should never change and kept away from your modifications. And Berkshelf does not spoil the repo with an “tmp” folder which confused some of my colleagues. Also the other features like “metadata” sound cool.

Again: Please refer to the offical announcement for berkshelf for a in-depth introduction for all features. Although I found the installation of berkshelf a bit more complicated than librarian-chef (because of gecode) I will definitly dig deeper into Berkshelf.

The only thing I don’t really get is the name “Berkshelf” / “Berksfile” and I could’t find a proper translation. Yeah call me picky :)

Maybe a native speaker can give me a hint on that one :)

I’m very interested in your experiences with either of these tools.

– Cheers Christian

How I switched from bash to (oh-my) zsh

I switched from bash to zsh lately. After announcing it on Twitter I got lots of reactions, mostly questions, how I did get started.

So here’s how I got started:

  1. I decided to change my shell. Why? Actually I was like why not? Seeing a lovely bunch of hackers at the Vagrant Usergroup Berlin getting excited with tig (a Git browser on the shell) can have quite an influence - so I though: there’s got to be more than my standard shell!
  2. I did brew install zsh to get the latest version
  3. I added /usr/local/bin/zsh to /etc/shells Otherwise you won’t be able to activate the shell.
  4. Finally I switched the shell to zsh: chsh -s /usr/local/bin/zsh

After that I removed ~/.bash-it, followed the instructions https://github.com/robbyrussell/oh-my-zsh and customized my ~/.zshrc.

That’s it.

Since then I do not regret it. I feel very comfortable with my new shell and I love the tiny little features it provides like auto-completion and correction.

I didn’t dig into scripting yet though, so I can’t provide any feedback here but would love to hear your optinion on this.

References