Between reality and cyberspace

User testing done right

Tue, 07 May 2013 16:00:21 +0200

Don’t make assumptions about the user, have her test your website or app! It’s easy, quickly done and cheap. Trust me.

When it comes to usability and providing the best solution for the user, I have seen lots of mind-numbing, long and - in the end - pointless discussions.

People tend to project their own behaviour onto the users of their application - and often this turns into discussions about the user as if she was an alien, yet to be discovered life form from outer space.

I did that as well, but I learnt my lesson: I’m not the user. You’re not the user user either.

You know how your application is supposed to work. You know what feature can be found where - your users may think differently. And they may be different from what you think they are.

A brilliant example was one of my websites: I put a big, prominent “Sign in with twitter” button on the homepage, but the conversion rate was poor. So I decided to do a very simple, quick and cheap way of usability testing:

The 5 second test

In this case, you take a screenshot of a prototype, your website, your app, your design and upload it to Usability Hub (which is free, when you do other peoples tests - or you can pay for answers) and asked the question “where can you become a user of that service” and asked for 10 answers.

Now this picture is shown to different participants for 5 seconds each. Afterwards my question will appear and they can answer. The answers were surprising and shocking: Only 2 people got it right. The others answered along the lines “I see, where I can sign in after sign up, but where do I sign up?”.

This was interesting, because with Twitter login, there are no concepts such as “sign up” and “login” - you hit “sign in” the first time and get signed up, you hit it the next time you’re on the website and you get logged in.

Knowing the struggles of my users, I re-captioned the button “Sign up with twitter” and added a little “Sign in with twitter” on the top right corner et voila: Conversion rate rocketed.

UsabilityHub also offers other tests, like

The click test, where you ask your users a question like “Where would you click to sign up” and see a) where they actually click b) how long it takes them to spot it.

The nav flow test, where you upload multiple screens and ask the user to carry out a task that should take them from one screen to another - you’ll learn if your navigation concept works from this test type.

Test early & test often

This shows: Testing early is possible and valuable! All it takes is a few minutes and a screenshot, a design, or even a picture of a sketch on paper. This allows you to check, if your users “get it” on the many different levels:

Does the wording make sense?
Does the layout structure and content hiearchy make sense?
Is the visual design confusing people?

For all this, you don’t need a working prototype, you need nothing “done” or “shiny” - but you can already learn about your users. It takes minutes and is cheap (or free).

User tests

With services such as BetaPunch or YouEye it’s very easy to get real users to do a couple of tasks on your app or website and get a recording with them saying what they think while carrying out the tasks you gave them as well as their inputs and mouse movements.

BetaPunch, for example, offers one free test to get you started.

There is also a user test light version, where you can only get recordings of your website / app users using your app and see their mouse movements and inputs - see here for more details on that.

Lightweight virtual containers with virtual networking

Thu, 18 Apr 2013 15:00:00 +0200

What and why?

Sometimes you want to have a quick & cheap way of isolating a few processes in a lightweight, para-virtualized environment.

When full-blown virtualization, for instance with Xen or KVM, is just too much (or not suitable, because you’re already running in a virtual environment) and process-level isolation (what for example docker.io provides) isn’t enough, user mode linux is for you.

Example:

Multiple isolated build environments for Continuous Integration

One scenario is running integration tests between multiple components on a shared CI server (e.g. Jenkins).

Let’s elaborate this scenario a little more:

Say, we have a Jenkins instance that is used to build multiple projects, say an API and a “frontend webapp” (I’ll reference it as “Frontend” from now on). The API can be build and tested independently, but that requires the installation of a bunch of libraries, gems and other fun things.

The Frontend is a little more complex: In addition to the need of its own dependencies (gems, libs, modules, …) it also needs a running instance of the latest stable API and a running API also needs a database and other components (let’s say a message queue).

The safest bet is to have every system under test (API stand-alone, Frontend instance + API instance + database + message queue) isolated, always freshly created when the tests start and torn down when done.

Our goal is to setup a virtual container in which we can build the API and another virtual container in which we will setup the database, the message queue, the API and a third one for the frontend, with a virtual network between the second and third container.

With user-mode linux you can achieve this goal pretty fast&easily:

Install user-mode-linux and the utilities needed:

$ apt-get install wget user-mode-linux uml-utilities bridge-utils debootstrap realpath

Setup a new machine

You can use my create_machine script which is based on this article:

$ wget https://gist.github.com/AVGP/5412047/raw/ee9057124fa32edbf5c427955cc0be4012015ec5/create_machine_switched.sh
$ chmod +x create_machine_switched.sh
$ ./create_machine_switched.sh

The script will ask you for a few things: * The hostname of the container (we’ll use “API-build”, “API-run” and “Frontend”) * If you want SSH to be installed (“y” for our example) * If you want to configure the network (“y” for our example) * Couple of network settings. For this example we’re using the following settings: * IP-Address: 10.10.10.2 for API-build, 10.10.10.3 for API-run, 10.10.10.4 for Frontend build * Network: 10.10.10.0 * Broadcast: 10.10.10.255 * Subnet: 255.255.255.0 * Gateway: 10.10.10.1 * Root password for the container

Setting up the host-side networking

Before starting the container, we need to set up the host and the network switching on the host machine.

First of all add the following to /etc/network/interfaces:

    auto tap0
    iface tap0 inet static
            address 10.1.0.1
            netmask 255.255.255.0
            tunctl_user uml-net

Then edit /etc/default/uml-utilities by uncommenting the line with the UML_SWITCH_OPTIONS and, if needed, change it to look like this:

UML_SWITCH_OPTIONS="-tap tap0"

Then stop the uml-utilities daemon, bring up tap0 and start uml-utilities again:

$ /etc/init.d/uml-utilities stop
$ ifup tap0
$ /etc/init.d/uml-utilities start

Afterwards, you can start the container by changing in their directories and execute ./run, preferably do this in a screen (or tmux) session:

Start the containers

$ cd API-run
$ ./run

and the same for the other two machines. You should be abled to login as root on all running instances and ping to the internet as well as to the other instances.

root@API-run # ifconfig eth0
    eth0   Link encap:Ethernet  HWaddr d2:45:9b:1f:ba:c6
              inet addr:10.10.10.3  Bcast:10.10.10.255  Mask:255.255.255.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:25 errors:0 dropped:0 overruns:0 frame:0
              TX packets:43 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:1000
              RX bytes:1092 (1.0 KiB)  TX bytes:2198 (2.1 KiB)
              Interrupt:5
root@API-run # ping -c1 10.10.10.4
PING 10.10.10.4 (10.10.10.4) 56(84) bytes of data.
64 bytes from 10.10.10.4: icmp_req=1 ttl=64 time=0.192 ms

--- 10.10.10.4 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.192/0.192/0.192/0.000 ms

Setup the NAT on the host

For the containers to be abled to reach the internet, you need to enable masquerading and IP-Forwarding using these two commands:

$ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
$ echo '1' &gt; /proc/sys/net/ipv4/ip_forward

Now you can setup all the applications inside the containers (you may use provisioners, such as chef or puppet) and enjoy your virtual testing environment and its virtual networking.

The bad, the good, the masterpieces

Tue, 16 Apr 2013 21:23:00 +0200

Building websites and web applications is a craft. And as far as crafts go, there will always be bad, mediocre and great pieces.

The question is, what makes something a masterpiece? Is it the techniques applied, the perfect mastery of them, the little details?

Coming back from Rome again, a city full of various disciplines master pieces, I have gained a better understanding.

Though it’s hard for me to grasp the entire cleverness and knowledge that contribute to the overall results of each of them, certain patterns and aspects can be found repeatedly on most, if not all, of them.

It’s usually neither one aspect, nor all of them together, it’s the consistency in the impression that is created in the observer.

There is a lot of different aspects that come into play there, for example

Color theory
Use of fore- and background, as well as the space in between
Composition
Guidance of the viewers’ eyes
Technique

Being a developer striving to learn about design, it came as a surprise to me, that the techniques used and how well they were mastered by the artist are not the most important aspect that makes something a masterpiece.

Looking at a lot of mediocre, some most-popular and some less popular but extraordinarily intriguing items, I figured that mostly three things caught my eyes and captured my attention for more then the average time span:

The colors and contrasts
The composition of the piece
The guidance of view

The amazing thing I never noticed before: That also worked, when proportions where slightly off, or there were minor defects (e.g. broken off parts of a statue or parts of the canvas) or missing details, etc.

I did notice these deficiencies, though I was standing there, admiring the overall impression they made on me.

I had to look at a bunch of those pieces and it was only at the Vatican museums, where most of the art was related to Christianity and there were a lot of more-or-less comparable works to gaze upon, or downright staring at them for pretty long, to gain the insights, that it’s the above-mentioned three things (in the order I put them) that attracts people.

I even watched others and how they looked at the different things and how their eyes were moving around.

After getting this invaluable “Heureka” moment, I am now looking differently at designs and art, whether it’s a famous painting, an anchient statue or something profane as a website or a web application, because this simple finding applies to all of them:

You don’t have to do everything 100% perfectly, as long as you put effort in how the spectator reacts to it and is engaged with it and get it pretty right.

Why developers should learn to estimate and estimate often

Tue, 09 Apr 2013 11:00:32 +0200

Developers are sometimes a grumpy set of people.

To a certain extent, I understand my fellow developers - deadlines are tight, features creep in and out from time to time and uncertainty is your daily companion.

Asking the right questions before starting to hack away is crucial but pretty hard at the same time.

It’s hard, because it’s likely that you never did something alike and before sitting down and thinking it through carefully it’s hard to ask the interesting questions to other stakeholders.

So why would you do that?

First of all, estimations help everyone to get the expectations straight. That tough deadline is in two weeks but the estimated work says 2 months? Well, then there’s some sort of problem and you should talk about that.

The work is finished faster than expected? Well, then you may have a problem as well (somebody may have missed important bits & pieces or the code is poorly written, docs may be missing, …)

What can be the reasons that estimations are wrong?

There’s a pretty long list. My top 3:

1.) The task wasn’t thought-through. Sub-task were missed, uncertainties weren’t identified or the requirements weren’t documented. 2.) A lack of experience. It takes some try&error to get a feeling for the common tasks and problems. 3.) Scope creep happened between the estimation and the (delayed) delivery.

Yes, in that particular order.

How do do better estimations?

That’s not a one-shot thing. It took me a couple of attempts to get to acceptable and apropriate estimations for different tasks. Basically you oscillate around the right estimation - sometimes you’re over, sometimes you’re under, but you should always aim to make it as close as possible. If you get your performance to +/- 5%, you’re good. For example: In sprints of one week I tried to be within 2 hours of my estimations. I am pretty sure I never reached that goal, but I wasn’t too bad at it (I think).

Open source: Go contribute. Now!

Thu, 28 Mar 2013 11:00:40 +0100

You’re still here, reading this article?

Well, that means you’re probably like me a few years ago. You think “I don’t have time for that” or “I am not good enough to contribute” or “I can’t code at all”.

All of those things are no excuse.

First: About the time.

I guess you have a lot of things to do then, right? And I bet you wrote a few scripts (be it a tiny 2 liner or a huge collection of shell scripts) to speed up the chores, right?
Publish them. Now.

There’s no need to polish them or write 100 pages of manual texts. Just throw in a readme with two lines (what it does and how to execute it) and publish it.

If you don’t wanna “clutter” your account with a repository or the script is just one clever line of shell code, you can also use Coderwall or a Gist.

Why you should publish things like that, you ask? Because even if you think it’s a very specific solution for a very special problem, others may encounter it. And if so, your tool can help them get it done quicker.

Another case is when you do a little modification to an existing tool, because it makes it a little easier to use or a little faster or even fixes a bug - publish it, so that others can benefit just like you did by using the tool in the first place.

Contributing often only takes a few minutes and often you just need to put it online somewhere (with things like Github available, this is no big deal anymore!) - and you should do so, even if it’s not polished.

I see it pretty often that people postpone their contribution, because it needs to be cleaned up, documented or polished in whatever way. Publish the raw gem that you have - and then you can polish it later. Maybe even other people polish it for you.

Next one: You are good enough and you will learn something from contributing.

There’s really just two things that can happen: Your code is good enough. And it’s a great feeling, when it gets accepted into a tool or library you use in your daily work.

The other case is, that your code isn’t good enough. In that case you get invaluable feedback on why it isn’t good enough and how to improve. That, in the long run, makes you a better programmer. It’s pretty much free training. Use this opportunity by contributing code.

Alright - last one.
You can’t code? So what?
Often the documentation of a project has missing or outdated parts. Fill them with the knowledge you gained while using the tool.

Another way of contributing is joining the forums, mailing list or user group or stackoverflow of the project to answer questions of others.

You should understand that contributing is a small thing to do with a big impact.

Don’t hesistate, contribute today.

Things I learnt from deploying my first larger Meteor.js app

Wed, 27 Mar 2013 11:00:28 +0100

With Google Reader said to be discontinued I had to look for alternatives. I had a look at the many alternatives but none made me really happy - plus I was already looking for a way of building a “real” app that I’d like to use to learn more about the woes and joys of maintaining a Meteor.js app and potentially running it at a bigger scale on my own infrastructure.

So building my own RSS reader and offering it to everybody as a hosted service on my private server seemed perfect to achieve more “real life” experience with Meteor.js.

The result is my latest side project Neee.ws, which is also on Github.

Okay, enough context - what went good, what went bad?

(Re-)Deployment

First of all, redeployment involved the following steps

Run mrt bundle
Copy the tar to the server
Unpack it
Delete the fibers package (because I bundle on a different architecture as my servers’.
Restart the application

to make this a little more convenient, I wrote a little shell script to do that and also keep a backup of the previously deployed version.

To run the app on the server I use forever, which is super-simple and works reliably for me.

Beware of large collections!

I totally forgot about the client-side mongo instance. Meteor tries to download the whole database (!) to the client for caching. Even if you’re limiting your query results: The client will get the whole database. That is part of the autopublish magic. Hence you should remove the autopublish package and use Meteor.publish, Meteor.subscribe and Deps.autorun and do as much filtering as possible on the server side to have only the most important documents cached locally.

The performance gain is enormous - from 28 seconds loading time down to 1.9 seconds!

The many joys of Meteor.js The development was really quick & easy - thanks to the many nice things Meteor gives you for free. I will just give a short list here:

Google Login + oAuth token for API access
Reactivity in data sources
Helpful Meteorite packages, particularly meteor-router
Easy setup & bundling

A fun look back to the history of computing and the origins of...

Fri, 15 Mar 2013 09:00:28 +0100

A fun look back to the history of computing and the origins of some things we wonder about nowadays. Don’t let the title of the video trick you: This is a lot of fun to watch, it has not too much to do with Javascript and it’s worth watching.

How to manage building a great software product

Thu, 14 Mar 2013 11:50:00 +0100

The internet is fast-paced and to build great stuff, it’s vital to manage your project properly.

Because if you don’t, you’ll never build something truly great. You may say “Yup, that’s obvious”. Like everybody does.

The TL;DR: * Focus on building what the customer needs * You don’t know what the customer needs, so ask the customer early on * Measure the use of the features, optimize for the real top features * Waterfall doesn’t work, the original paper (1983) even says so, be agile and deal with it.

But for some reason, whenever I’m on an event or I look at fellow developers I hear the same things over and over and over again?

Here are the top 5: 1. The managers give us not enough time and budget to build giant, complex apps and expect the outcome to be great. 2. The deadlines are unrealistic the moment they’re set 3. Nobody asked us about it, the decisions were made without the developers 4. We’re behind schedule, the set of features is steady (sometimes this is even “it actually grows”) and the deadline can’t be delayed. 5. We don’t have time to really think about anything, we just have to code code code.

It’s not coming from people working in the same company. I hear this a lot and thinking back, I encountered that myself as well. Often.

When you ask people who know enough about coding but are in a managing position, I often get the following reply:

I know, but the management…

I have a theory that has proven to be right pretty often: The project management gets under pressure from the higher management and doesn’t stand their ground, which transitions into putting the pressure on the development team… which doesn’t stand their ground either.

So here’s my suggestion to this: When somebody demands something unrealistic, tell them about the Scope Triangle.

The scope triangle is one of the most-obvious yet most-ignored things in management of IT projects. It looks like this:

It means: From Quality, Time or Money you can pick two or you end up with something shitty. You should now read this article for further details on this.
Seriously, click the link and read that really thoroughly, then come back.

Alright. Now that you understand the key thing there,start by focusing on the only really important aspect: The user.

If your project looks really great, but doesn’t really do the right job perfectly, it’s shit.
If your project has a ton of features, but doesn’t really do the right job perfectly, it’s shit.
If your project has the best user experience, but doesn’t really do the right job perfectly, it’s shit.

Period. No excuses, no “Yeah but…” - the first thing you have to release is something the user wants. What makes people want something? If it does something really good. Everything else is toys.

Do you know what the user needs or wants? No you don’t..
Try it for yourself, make up something you think a given group of people would love. Then go to a coffee shop and offer people from that group a coffee in exchange for telling them your idea.
You’ll be surprised how different their desires and needs are from what you had in mind.

Now that you understood how important it is to get the real user feedback to your idea (actually even before having built the first release), you could do different things:

Create a simple clickable prototype and do the coffee test again.
Create a simple real version with only the features you think are the most vital but not more than one or two features. Even if you think “Oh this is useless to the user, because it’s missing XYZ**, do it that way. Then show it to test users and ask them, what they miss. Then extend your product.

Release it early and have a few early-adopters play with it. Proactively ask them and gather analytics on how they use your product and what they need.
Your anticipated killer-feature is not used at all? Throw it out, focus on the most popular thing and direct your design efforts to make this as pretty, easy and useful as possible.

It’s generally a really bad idea to go a top-down approach like waterfall. Be agile. It you think “bah, the modern pseudo-management stuff? Never! I trust my waterfall”, you should finally read the original paper from 1983 - focus on the foreword page 2 and following. Even the author says it doesn’t work that way and they had done prototypes first to minimize uncertainty and risk.

Money quotes:

The great majority seemed to espouse the following approach: we must write the initial top-down specification […], so we will know precisely what our objectives are before we produce one line of code. This attitude can be terribly misleading and dangerous.

(p. 3, line 13ff. ) and

To stretch an analogy slightly, it is like saying that we must specify the characteristics of a rocket engine before measuring the burning properties of liquid hydrogen.

(p. 3, line 17/18)

User interface blindness

Wed, 13 Mar 2013 11:00:00 +0100

You know that situation: The interface of your favorite webapp changed and you’re lost. Even when the interface changes are relatively subtle and make sense.

While that is intrinsically obvious, it came to me as a surprise how blind we get when we’re used to an interface.

I will take Confluence as an example.
Confluence is a nice wiki software we use for pretty much all of our internal know-how transfers. It integrates pretty well with Jira, the Atlassian Issue Tracker.
When I started to use the two, it was in version 4, the two interfaces were working in different ways. To accomplish similar things you had to look at different places to do them in the different applications - but the interfaces looked relatively similar to each other.
While that sounds like a bad thing, it worked remarkably well in reality, because your mind is aware that you’re in different contexts. Either you create an Issue in Jira (which means: Look at the middle of the top navigation and use the “Create” button) or you add a page in the wiki (which means: Look at the right hand navigation controls and use the “Add” dropdown).

Here are some screenshots to visualize that:
The old Confluence
JIRA5

JIRA5 has been around on Atlassians cloud service substantially longer than the latest Confluence, so we got used to this inconsistency.

But a few weeks ago Atlassian did a reasonable change in the Confluence UI to make it more user friendly:

That is a perfectly reasonable change - it makes the main navigation in Confluence and JIRA consistent. You don’t need to think about the context you’re in anymore - you alway create content with the button in the middle of the top navigation bar. The only nasty thing is: Confluence still has some controls on the right hand side below the navigation bar:

The problem here: The presence of this old-fashioned right submenu gives you the cue that - while the interface changes are more or less subtle, the old mechanics have been kept. You instinctively look for the “Add” link there. Without finding it.

As the wording for creating content has been “Add” in Confluence so far, your brain now scans the site for something that says “Add”. Without success.
Now your brain has to go creative, because the clues, that make the workflow feel natural and obvious to you, have failed. (At this point: I highly recommend the great book Don’t make me think which gives great insights on those stuff)

This little stupid thing took me some minutes to figure out - it made me feel dumb. And not only me. A coworker asked me why he can’t add pages anymore but after I told him to search for “Create” on the page, he was rather surprised to find it. In the middle of the menu bar.

So when you refurbish your designs to make them more consistent and intuitive, do this really graduately. If, for example, Atlassian hadn’t changed all of the visual clues (i.e. text, position and appearance) it may not have been so confusing.
If they would have moved it to the middle of the navigation bar while still displaying the “+” symbol and still labeling it “Add”, it may have been easier to spot. Changing “Add” to “Create” and removing the symbol a few months later would have been fine, because you already would’ve known where to look.

While this obviously applies to redesigns, it also applies to making new designs, because there are a bunch of conventions (or “prejudices” if you wanna put it a little more negative).

For example when you plan to have a search function on your website, you should put them in the top area. That’s where people expect it, because most of the popular websites have it there.

Login/Signup/Logout is another frequent component. It usually lives in the top right hand corner. If you put it at the bottom left, your users will hate you. I even had trouble once when I put the signup link on the top left hand corner - literally 75% of my testers (a group of 20 people) did not know where to sign up after having looked at the site for 10 seconds. After I put it on the right hand corner, another group of 20 people found it right away.

blog.izs.me: User Feedback

Tue, 12 Mar 2013 16:00:22 +0100

blog.izs.me: User Feedback:

izs:

Sometimes a request is much less interesting than the motivation behind the request, which the requestor might not even fully understand.

Sometimes people demand a giraffe, when really, they just need a ladder, or better yet, they need things to not be up so high.

“There are ZERO giraffes in…

Running your meteor.js application on your own server

Tue, 12 Mar 2013 13:00:50 +0100

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.

Cloudfoundry on top of OpenStack - ICCLab

Tue, 12 Mar 2013 08:15:43 +0100

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

The native mobile app fallacy

Mon, 11 Mar 2013 11:00:00 +0100

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?

and why not take another look at the Facebook app:

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

Magic (programming)

Fri, 01 Mar 2013 14:08:18 +0100

Magic (programming):

dhotson:

slashnull:

Single-handedly the greatest page of the entire Wikipedia.

Local.ch - War stories from the first year on Rails

Fri, 01 Mar 2013 06:56:56 +0100

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.

Introduction to Puppet @webtuesday

Thu, 21 Feb 2013 14:00:39 +0100

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

Thu, 21 Feb 2013 12:00:32 +0100

Kevlin Henney - The Uncertainty Principle

Protected properties in Javascript

Thu, 14 Feb 2013 06:11:54 +0100

Protected properties in Javascript

"Put the following to the Vagrantfile" - where in the file? In an Empty file?

Mon, 11 Feb 2013 22:28:08 +0100

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

"We will make the two directories called “manifests” and “configs” to house config files and puppet manifests:" - where? assume this is on the host machine i.e. not within the VM. And if on the hsot machine, where?

Mon, 11 Feb 2013 16:13:42 +0100

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