During the course of the weekend two weeks ago, I created the **Quantified Geekonaut to gather some data about my internet activities (such as Twitter, Last.FM [Spotify really], Foursquare, Github, my blog and a few others) and experiment with graphing and such.

I decided to build it with Meteor.js - primarily because I needed a reason to play around with it again.

One thing I found (without being too surprised about it) about hosting your app on the free meteor.com cloud hosting is, that it gets restarted whenever somebody accesses your website.

Which isn’t a problem normally is an issue for the Quantified Geekonaut application, because it gathers data periodically and saves it to be able to graph and query historical data points. That’s obviously impossible, if it only collects data when accessed by a visitor.

As Meteor gives you the possibility to bundle your app as a (more or less) self-contained node.js app, you could as well run it on your own server.

In this article I’ll give a quick run-through on how to do that.

Step 1: Bundle your app

To bundle your meteor app, run

meteor bundle app.tar.gz

and copy the app.tar.gz on your server.

Optional: Install nvm and node.js v0.8

To run a meteor.js application you need to have at least node.js version 0.8.
Optionally, if you want to use different node.js versions in parallel, you could install nvm, the Node Version Manager (pretty much “RVM” for node). To install nvm on your server, you just run

cd ~
curl https://raw.github.com/creationix/nvm/master/install.sh | sh

to make bash always load nvm on startup, use

echo "source ~/.nvm/nvm.sh" >> .bash_rc

on your server. If you’re not using bash as your shell, adjust that accordingly.

To install node 0.8 on your server you just run

nvm install v0.8

which gets you the latest stable version of the 0.8 branch. To make node 0.8 your default node.js version (if you have more than just this one), run

nvm alias default 0.8

Step 2: Unpack the bundle on your server

Pretty straight forward: Copy the bundle from Step 1 to your server and run

tar xvf app.tar.gz
cd bundle

** If you bundled your app on a different architecture than your servers’ (e.g. you bundled the app on OSX and run your server on Linux or your server is a 64bit system and your computer is a 32bit system) you need to reinstall fibers:

cd server
rm -rf node_modules/fibers
npm install fibers@1.0.0
cd ..

Step 3: Install forever

If you have your app running, you want to make sure it keeps running. Forever is a great tool for that.
It runs a node.js app in the background, monitors it and restarts it when needed. To install forever, run

npm install -g forever

Optional: Get a MongoHQ database

If you don’t want to setup and install your own MongoDB instance, check out MongoHQ. You can use their free sandbox DB, if you wish. Copy the Mongo-URL to use it with meteor.

Step 4: Set the environment and start the app

For this you need a connection URL to a mongo db. You can either set it up manually or you can use MongoHQ as described above. The app needs the URL of a MongoDB and a port to run on. To specify these run

export PORT=8080
export MONGO_URL=mongodb://<user>:<password>@<db_host>:<db_port>/<db_name>

Please substitute user,password,db_host,db_port and db_name with values for your Mongo instance.
Now you can start the app with

forever start main.js

Your app should now be reachable on Port 8080 on your server’s address!

Optional: Setup reverse proxy with Apache
If you want to run the app on a subdomain of your server, let’s say meteorapp.example.com and you already have an Apache running for the main domain and/or some VirtualHosts, you can create a reverse proxy to serve the meteor app with something like this in your apache sites folder (for Debian that is /etc/apache2/sites-enabled).
Create a new vhost file with the following contents:

<VirtualHost *:80>
  ServerName meteorapp.example.com
  ProxyRequests off
  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>

  <Location />
    ProxyPass http://localhost:8080/
    ProxyPassReverse http://localhost:8080/
  </Location>
</VirtualHost>

and you’re ready to go. Reload apache with

/etc/init.d/apache2 reload

or similar for your server OS and you’re ready to enjoy meteor running on a subdomain.

zurichtechtalks:

Christof Marti from the ICCLab is giving a talk on how to run Cloudfoundry the open source PaaS on top of an Openstack cloud.

Recorded by switch at the @OpenStackCH meetup hosted by switch

.

Talk: Flash, Quicktime

Native, web, hybrid?

When it comes to mobile application development, there’s far too many evangelism out there.

The web fans sing their

“write once, deploy everywhere”

the native party yells back

“But it’s slow and doesn’t look native!”

but both lack the understanding of the advantages and disadvantages of each approach, as well as the rationalism to re-decide on this matter, based on the project at hand.

Does native always mean better?
Certainly no. Facebook is a great example for this. Their claim was, that the Android app’s quirks and issues originated in its hybrid nature.
The reality is: The new native Android app does not really work any better and Sencha gave an impressive proof that a non-native app could do better.

So a native app is not by definition better.
If you write inefficient code, the performance will be bad and the development iterations may be longer, as you can’t easily test on many different platforms simultaneously without having to repeat modifications in the code for each platform.
If you also run a web version of your project, the mobile web or the hybrid approach allows you to quickly iterate on both of them.

As always you should pick the right tool for the job, which can be a native or web app. It can even be a hybrid app.

The tricky thing is to find out when to use what.

Quick overview of what’s what

• Native: Requires code tailored to each supported platform but gives you direct access to the native features.
• Mobile web: The same code runs on many (if not all) platforms. Can also be delivered to desktop browsers, but can not be installed via app stores and can not access all device features. As the code is run in the browser which runs on top of the operating system, some features may be slower than native features.
• Hybrid: Combination. Same code can run everywhere, all native features can be accessed and native components can be used to get a good performance. Hybrid apps can also be distributed in the app stores.

If you have a big team of experienced mobile developers for the different platforms at hand, you can of course leverage that.

But when you have a team of experienced web developers instead and need to quickly get an app out there (maybe even flanked by a web app), mobile web or hybrid apps are a great tool for achieving this.

The thing many people miss is: It’s not only good for prototyping and quick iterations - it is a viable option for building great apps.
With modern Javascript frameworks and libraries (such as Angular and Lungo in combination with PhoneGap) you can use web technologies to your mobile apps that can play in the same league as native apps.

It needs to look&feel native, right?
First of all: If you want to achieve perfectly native look&feel, you’re not going to have a good time with a hybrid approach. But do you really want that?

Let’s look at the Foursquare app for a second:
©Foursquare

and why not take another look at the Facebook app:

© six revisions, see their great article about native vs. mobile web

It’s easy to spot that even the native Facebook-App doesn’t really look native. And that’s no problem! The user doesn’t really care, as long as it looks great and feels right.

This is something most people get wrong - you can have your very own look in your apps. Stop mimicking the native look and feel and start delivering something great and useful to your users.

But to get in the stores, you need native, right?
No you don’t.
You can for example use PhoneGap to package your hybrid app for many different platforms (e.g. iOS, Android, Windows phone, Blackberry).

Okay, but what if I need the native features, like the camera?
Again, PhoneGap is the answer.

But how do you build a great app?
There are many different ways to build great hybrid apps. To achieve the best results, you should focus on the following aspects:

• Responsiveness - the app has to respond quickly to user input
• It has to feel right - don’t imitate the perfect native transitions. Use decent transitions that are not giving the impression of “wanna be native”
• Be aware that the user won’t always have a good internet connection (or any at all) - leverage local storage whenever you can and minimize the data to transfer
• Use native components (e.g via PhoneGap plugins) whenever needed
• be careful: Not all platforms already support every HTML 5 feature. Provide fallbacks
• test your app on different devices, especially on older ones

dhotson:

slashnull:

Single-handedly the greatest page of the entire Wikipedia.

zurichtechtalks:

local.ch went live with Rails in March 2012. As with any new technology stack, handling high traffic, not everything went smoothly. Jeremy Seitz, lead engineer on the local.ch website, shares stories, experiences and lessons learned on bringing one of the most popular websites in Switzerland to Rails.

Recorded at the @webtuesday meetup @localch.

Thanks to Jeremy for letting me tape this talk.

zurichtechtalks:

David Gubler from Doodle gives a short introduction to the Server Orchestration Tool Puppet and shows how they use it at Doodle to keep their servers in order.

Recorded at the @webtuesday Meetup at @centralway.

Thanks to David for letting me tape his talk.

Kevlin Henney - The Uncertainty Principle

Wrapped in the 

“Vagrant::Config.run do |config|” at the beginnin and “end” at the end of either an empty file or by removing/commenting everything in the Vagrantfile that “vagrant init” created. For further guidance you can turn to http://docs.vagrantup.com/v1/docs/getting-started/index.html

In the same  directory as you put the Vagrantfile.

Assuming you are in /home/user/my-project and created a Vagrantfile at /home/user/my-project/Vagrantfile, then you create the two directories

• /home/user/my-project/manifests
• /home/user/my-project/configs