This is a post with post type “Link”

Entries with this post type link to a different page with their headline. Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aenean commodo ligula eget dolor.

How do you find your Highrise API token?

If you want to use one of our Highrise applications (the Google Apps Highrise Gadget or the Chrome extension), you will need to find your Highrise API token. You can find it by following the steps below:

  1. First, you need to log in to your existing Highrise account.
  2. In the upper right corner, click on the Account & settings menu, and choose My Info.
  3. Click the API token tab in the middle of the screen.
  4. You can find your authentication token here.

A/B testing with Google Analytics Content Experiments

Introduction

The Google Web Optimizer has recently been incorporated into Google Analytics and is now called Google Analytics Content Experiments (GACE). This blog post will show how we’ve set up A/B testing in GACE for our company homepage. Our goal for the experiment is to promote CollabSpot Boards to the visitors of our homepage. We’ll also show what the result of the experiment looks like and how you can proceed to other experiments.

Variation pages and experiment goals

Since we’ll be doing A/B testing for the CollabSpot homepage, then we need to have a variation of the original webpage that’s present in a separate URL. In our case the URL for the original version is at http://www.collabspot.com, while the one for the variation is at http://www.collabspot.com/home. We will input these two URLs once we start setting up the experiment within Google Analytics.

A variation webpage is not very useful unless we have a goal to consider for the experiment. A goal is simply an answer to the question “What do we want the visitors to do when they get in our homepage?”. The goal for our experiment is to promote CollabSpot Boards by making our homepage visitors to go to the CollabSpot Boards website. To consider this goal in our experiment, we made the CollabSpot Boards section in the original homepage more noticeable by putting a border around it. Alternatively, the variation page doesn’t have a border around the CollabSpot Boards section. We’re convinced to make only subtle changes in our variations so we can easily correlate those changes with the result of the experiment. It will be harder to pinpoint what factors lead to the winner of the experiment if there were so many changes implemented at the same time.

One can set up goals in GACE by clicking on “Admin” on the top right of the Analytics interface, selecting the “Profiles” tab, and then clicking on the “Goals” tab. You can create various goals for your experiments, but the simplest type of goal is the URL destination. Since our goal was to promote CollabSpot Boards, then the URL destination must be http://boards.collabspot.com. If a visitor lands on this URL during a visit to a certain variation of the homepage, then that variation scores a point for the experiment.

Setting up the experiment

You need a Google Analytics account to start using GACE, and your own webpage as a subject for A/B testing. In our case, the test subject is our company homepage http://www.collabspot.com. Log in to your Google Analytics account and on the left panel, click on “Content” then click on “Experiments”. From there, setting up an experiment is pretty much straightforward by simply following the instructions. We’ve named our experiment “www.collabspot.com to cs boards” to easily identify the goal of the experiment. The only potentially tricky part in the set up is putting the experiment codes in your website’s HTML source. If you have total control over the codes or if you have a webmaster to do this for you, then this part of the setup will be a no-brainer. But if you’re using a CMS like WordPress, then you may have to resort to GACE plugins (see below) to facilitate in your setup.

How to access the Content Experiments in the Google Analytics panel.

The last step allows you to start the experiment. Upon doing so, you can let GACE do its thing and wait for some time until an experiment winner is declared. Note that you cannot change the goals once you start an experiment. You can only change the URLs for the variation pages and the percentage of site visitors you want to involve in the experiment.

Results

The view when a winner is found in an experiment.

The experiment will automatically end once a winner has been found. This happens when there are enough visitors in the homepage who have participated in the experiment. We can easily check this by going to the GACE interface, seeing the experiment status as “Ended”, and the details as “Winner found”. In our case, the winner of the experiment is the original version, where we’ve put a border around the CollabSpot Boards section. Its visitors displayed a higher percentage of going to the CollabSpot Boards website. Since we now know this, we can iterate on the winning version and try out other experiments with other goals.

Content Experiments plugin for WordPress

Since GACE is relatively new, there are not many plugins available yet. But WordPress users will be happy to know that there exists a plugin to easily set up the experiments. You can find it in this link: http://wordpress.org/extend/plugins/google-content-experiments/. After installing the plugin, a checkbox will be present in the bottom part of every page editor. Checking this box will bring out a text area where you should put the experiment codes given during the setup in GACE.

A sample input via the GACE WordPress plugin.

So there you have it. I hope you’ll find the Google Analytics Content Experiments a valuable tool in optimizing your website for various goals. Its power lies in not having to rely with your gut feeling on what design works better for certain goals by applying a quantitative approach in determining which layouts or changes will work and which won’t.

Setting up Nginx + uWSGI Emperor to host Python applications on Ubuntu 12.04

This is the first of many posts on how our server is set up to serve Python web applications and others. For this post, we’ll focus on setting up Nginx and uWSGI and getting a bare-bones Django application running and served by Nginx.

Installing Nginx

Nginx is available in the Ubuntu software repositories, so installing it is pretty simple.

$ apt-get install nginx

Test your installation by starting Nginx:

$ /etc/init.d/nginx start

You should see a message along the lines of "starting nginx".

Check out Linode’s impressive library for a more thorough walkthrough on installing Nginx.

Installing uWSGI

uWSGI is available in the Ubuntu repositories as well, and also on PyPI. It’s up to you which method you prefer.

$ apt-get install uwsgi
# or
$ pip install uwsgi
Setting up our Django project

First thing we need to do is prepare some folders on where our project will live. We use the structure below for our projects:

$ mkdir /var/www/example.com
$ cd /var/www/example.com
$ mkdir venv conf src logs


/var/www/ `- example.com/ |- venv/ |- conf/ | |- nginx.conf (include in main nginx.conf) | `- uwsgi.ini |- src/ | `- example/ (django-admin.py startproject example) `- logs/ |- access.log (nginx access log) `- error.log (nginx error log)
venv/

This is where the virtual environment lives.

$ virtualenv /var/www/example.com/venv
$ source /var/www/example.com/venv/bin/activate
(venv)$ pip install django
src/

This is where the project’s source code lives.

$ mkdir /var/www/example.com/src
$ cd /var/www/example.com/src
(venv)$ django-admin.py startproject example
conf/

This is where configuration files for Nginx and uWSGI are stored.

conf/uwsgi.ini

[uwsgi]
# variables
projectname = example
projectdomain = example.com
base = /var/www/example.com
# config
protocol = uwsgi
venv = %(base)/venv
pythonpath = %(base)/src/%(projectname)
module = %(projectname).wsgi
socket = /tmp/%(projectdomain).sock
logto = %(base)/logs/uwsgi.log 

The .ini template above only works for Django >= 1.4. For Django < 1.4, check out uWSGI’s wiki for a template.

conf/nginx.conf

server {
  listen 92;
  server_name example.com www.example.com;
  root /var/www/example.com/src/example;
  access_log /var/www/example.com/logs/access.log;
  error_log /var/www/example.com/logs/error.log;


location / { include uwsgi_params; uwsgi_pass unix:///tmp/example.com.sock; } }

You’ll need to modify your main nginx.conf to include the project’s nginx.conf. Assuming Nginx was installed in /etc/nginx/, the main nginx.conf is /etc/nginx/conf/nginx.conf:

user    www-data;
# ...
http {
  # ...
  include /var/www/*/conf/nginx.conf;   
  # ...
}

That include statement will include any nginx.conf files in all projects following the structure outlined earlier.

We can now test if our application is being served on port 92 as specified in the nginx.conf.

# restart nginx
$ /etc/init.d/nginx restart
# run uWSGI pointing to our project's .ini file
# you can comment out the `logto` setting in
# uwsgi.ini to see log messages in the terminal
$ uwsgi --ini /var/www/example.com/conf/uwsgi.ini

Now open up a new terminal to your server and run:

$ curl http://localhost:92

If everything goes well, it should output the "Congratulations!" page from Django.

If not, check your conf files and/or the directories. Depending on your permissions, you might need to run uwsgi with sudo to allow uWSGI to create the /tmp/*.sock and /var/log/uwsgi/*.log files.

uWSGI Emperor

Emperor is a feature that monitors multiple uWSGI applications.

Let’s try running the app via Emperor:

$ uwsgi --emperor "/var/www/*/conf/uwsgi.ini"

What this does is it runs uWSGI’s Emperor mode looking for any uwsgi.ini files for all apps living in /var/www/ and starting/stopping/restarting them as needed. Any new additions will be automatically started, no need to restart Emperor itself. If an existing uwsgi.ini is modified, it is also automatically restarted.

Supervisord

We’re almost done. We just need a way to manage the uWSGI Emperor process. We use Supervisord to do this.

supervisord.conf

[program:uwsgi-emperor]
command=/usr/local/bin/uwsgi --emperor "/var/www/*/conf/uwsgi.ini" --die-on-term --master --uid www-data --gid www-data --logto /var/log/uwsgi/emperor.log
autostart=true
autorestart=true
redirect_stderr=true

Don’t forget to create the /var/log/uwsgi/ folder for the uWSGI logs. Again, depending on your permissions, you might need to change its user:group to www-data.

We use this init script to manage Supervisord.

Let’s test everything again.

$ /etc/init.d/nginx restart
$ supervisord
$ curl localhost:92

If you’re having trouble or if some part isn’t clear or incorrect, don’t hesitate to drop me an email or leave a comment below.

update: Changing so nginx run as www-data.

CollabSpot Boards in the GDG DevFest Philippines

The GDG DevFest

The first ever Google Developer Group (GDG) DevFest in the Philippines happened last August 4, 2012. It was held in the Asian Institute of Management in Metro Manila, a renowned business school in Southeast Asia. I, along with fellow CollabSpot developer Gino Tria, were invited to speak in the said event. We did a live demo of CollabSpot’s flagship product, CollabSpot Boards.

The GDG DevFest was full of interesting talks that were suited for both technical and non-technical people. The talks revolved around the different services offered by Google such as Google App Engine, AdSense, Android development, Google Maps, and Google Analytics. After the plenary talks came the “show and tell” portion of the event. In this portion, groups of people that were using Google technologies were invited to present their projects. The invited speakers came from a wide range of fields, from tech startups to government agencies. The CollabSpot team was one of the invited groups to speak in the event. So we decided to present a demo of CollabSpot Boards.

The CollabSpot Boards Presentation

CollabSpot Boards is a Google Apps project management tool based on collaborative boards. We spent the first few minutes of the talk introducing the team and the premise behind our product. We then gave a live demo of the app, showcasing some of its basic functionalities and popular usage. We experienced some difficulty with the internet connection during the talk, but we still managed to pull it off and enjoy the experience (with us smiling, as can be seen in the picture above). Since the event was about Google developers and Google services, we haven’t forgotten to spend a good deal of our presentation in explaining the Google technologies we use for the development of the app. Here’s a quick rundown of the technologies and how they fit in our development:

I think the list above is pretty neat when it comes to the range of Google technologies that’s being used. The final slides of our presentation contained our contact details and some of the future developments that we’re planning to implement in CollabSpot Boards. Since I still have some time left after the final slide, I went on to plug that the CollabSpot team is open for hiring. We are looking for exceptional Python web developers and project managers that can converse technically with developers. After the talk, random people came to chat with us for compliments and for networking, then Gino and I called it a day due to the ensuing heavy rain.