| Home | Podcasts | View other content | 

Latest Post - Category: Top Level Category

Google SMS services: a good thing for 'Africa'?
Tue, 30 Jun 2009 18:37:58 +0200

A blog post appeared yesterday on the official Google BlogExtending Google services in Africa (http://googleblog.blogspot.com/2009/06/extending-google-services-in-africa.html). The post talks about one-third of the population owning a mobile phone and many more having access to one, but that most only have voice and SMS capabilities. Google has therefore focused on SMS, and has a number of SMS based applications, including Google Trader and Google SMS Tips. The blog post talks about information poverty.

The story is reiterated on the official Google Afirca Blog under the title Google SMS to serve needs of poor in Uganda. The focus of that article is on the SMS marketplace application, which is probably one area where SMS can be useful, in that there is a business need,  and the cost can be passed on to the customer through normal business practices. However, I am worried that Google seems to be suggesting that 'the poor' can be made information rich by buying prepaid SMS bundles from MTN (MTN in Uganda is currently the only service provider supporting the service).

Interstingly, while it is true that a lot of current phones only support voice and SMS, what the Google blog post fails to point out, SMS is still very expensive in most African countries. Indeed, extensive use of any of these SMS services, apparently available only in Uganda right now, is likely to cost quite a lot of money. With many African countries dealing in prepaid services at higher rates, the people who are information poor will pay significantly to alleviate their information poverty using SMS.

Indeed, I can easily imagine running up an SMS bill that would exceed the cost of a low-end phone that can do basic web browsing and run XMPP based services. This is a bit of a Catch-22 type of situation in that spending money on SMS might prevent people from accessing cheaper sources of information by keeping them from getting a better phone. For example, a phone that can support XMPP messages (most modern phones) can retrieve text based information for about 1/2000th the cost of sending an SMS. That means you can do around 2000 searches for the price of a single SMS search.

XMPP based communication is widespread in Africa, particularly in South Africa where the MXiT application is extremely popular among young people, with about 11 million subscribers. Other XMPP applications that can run on phones work just as well, you do not need to subscribe to the MXiT service.

Paul Scott of the University of the Western Cape's (UWC) Free Software Innovation Unit (FSIU) has developed some innovative services based on XMPP messages, and thanks to his work and that of Wesley Nitsckie, adding new ones within the Chisimba framework is very simple to do. The framework was developed in the African Virtual Open Initiatives and Resources (AVOIR) project to foster collaboration in Software Engineering in African institutions using Free Software (Open Source) as the vehicle. The UWC XMPP based tools in Chisimba have already been used extensively in drug counselling. Paul has built some of this into a XMPP based social networking service at http://www.peeps.co.za. For example, you can send a dictionary lookup or a Wikipedia request to Paul's service and get the results back on your phone for a tiny fraction of the cost of sending an SMS.

So the question is, are SMS-based services going to contribute to information wealth, or further entrench information poverty. The answer is probably somewhere in between, but certainly not in the space the Google marketing hype would have us believe. And I am a big fan of Google!

Links

More on Google SMS services http://www.google.co.ug/mobile/sms/
Paul Scott's XMPP based social network http://wwww.peeps.co.za
African Virtual Open Initiatives and Resources http://avoir.uwc.ac.za
Business Times article on drug advice services http://www.thetimes.co.za/Business/BusinessTimes/Article1.aspx?id=1017017

         
Bookmark this post Trackback URL  No trackbacks were found for this post Comments 0 Attribution Share Alike PDF of this post email this post to a friend

Previous Posts

My SlideShare presentations
Mon, 29 Jun 2009 20:44:09 +0200

Here are all the presentations that I have on slideshare. They are all licensed under a Creative Commons, Attribution-ShareAlike license.

         
Bookmark this post Trackback URL  No trackbacks were found for this post Comments 0 Attribution Share Alike PDF of this post email this post to a friend

Learning new technologies
Wed, 24 Jun 2009 10:21:48 +0200

         
Bookmark this post Trackback URL  No trackbacks were found for this post Comments 0 Attribution Share Alike PDF of this post email this post to a friend

A #Chisimba developer and demonstration installation and a Bash script to automate it
Sat, 20 Jun 2009 18:11:19 +0200

When I set up the PHP5 development framework, Chisimba, on my laptop, I always follow a practice that I have used for development and demonstration purposes since we first created Chisimba. I have written about it before on the nextgen-online mailing list, and David Wafula published this on the AVOIR site. Hence, this has been published before, but what I am going to do here is to provide a bash script that automates most of this process.

The install takes advantage of the soft linking capabilities of GNU/Linux to allow multiple installations to run from the same code base. In that way, you can develop different functionality with different installs but you only need to maintain a single code base. In addition, you can run demonstration sites on your laptop without having to deal with the confusion of maintaining multiple checkouts or copies of the Chisimba code. This basic setup can also be used to create multiple live sites, and I use this on http://kim.wits.ac.za for my test and play sites.

I use Eclipse for development, so I check out the code using the Subversive plugin. However, here I will give the instructions for command line checkout. You can adapt them if you use a GUI for interacting with Subversion.

Firstly, I always do my Chisimba checkouts in my home directory. The reason for that is that I use RSYNC to back up my home directory quite often, so if I have done some editing and not committed the code to subversion yet, the chances are it will be in my backup. Of course, the only reason not to commit code to subversion is if it is a core module that will break everything. Since I work mainly on filters, this is the case, so I need them to be working properly before I commit. Normally, youwould just commit your code to subversion and not worry about backups.

I create a directory called chisimba in my home directory, so when I begin, I have

/home/dkeats/chisimba

I am using Ubuntu (Jaunty at the time of writing), so my webserver root is in

/var/www

So, with that bit of background, lets get on with it.

Step 1: Check out Chisimba from subversion

There are three separate sets of code to check out, the framework core, the modules and the skins (if you need them).

svn co https://cvs2.uwc.ac.za/chisimba/framework/trunk/ framework
svn co https://cvs2.uwc.ac.za/chisimba/modules/trunk/ modules
svn co https://cvs2.uwc.ac.za/chisimba/skins/trunk/ skins

This will leave you with three directories

/home/dkeats/chisimba/framework
/home/dkeats/chisimba/modules
/home/dkeats/chisimba/skins

The next step is to create the web directory, and build the symbolic links.

Step 2: Create web location and make symbolic links

First we are going to enter the webroot directory, and make a directory for our instance of Chisimba. It might be chisimba, or you might name it for the type of instance you are going to install. In this case, I am going to install a content management system (CMS) demonstration, so I call the directory cms.  I chmod the directory to 777 so I can write to it, and so can the webserver. You should not do that on a real web server that is accessible on the Internet, rather use the production settings.

cd /var/www
sudo mkdir cms
chmod 777 cms -R

Now we can change to the cms directory, and create symlinks to the appropriate parts of the framework. We do the files and directories individually this way so that we do not create links that will mess up the subversion repository. This keeps the repository clean and means we can commit back code from our code base without worrying about the repository structure.

cd cms
ln -s /home/dkeats/chisimba/framework/app/*.php .
ln -s /home/dkeats/chisimba/framework/app/*.php .
ln -s /home/dkeats/chisimba/framework/app/classes/ .
ln -s /home/dkeats/chisimba/framework/app/core_modules/ .
ln -s /home/dkeats/chisimba/framework/app/cron/ .
ln -s /home/dkeats/chisimba/framework/app/installer/ .
ln -s /home/dkeats/chisimba/framework/app/lib/ .

Now we need to make a directory for the skins. While we could symlink the skins directory as above, it would create problems if we wanted to add skins from the skins repository later. Therefore, each instance of Chisimba should have its own skins directory that links to the root skins and any skins from the skins repository that you want to use. Here we only link back to the core skins, but adding other skins from the skins repository could be done the same way.

mkdir skins
cd skins
ln -s /home/dkeats/chisimba/framework/app/skins/* .
cd ..

We need to create a separate user_images directory for each instance for the same reasons. Each instance will have different user images, and also, we do not want user_images getting back into subversion. This keeps our subversion checkout clean. Therefore, we create a directory, and link in the default images from the framework core.

mkdir user_images
cd user_images/
ln -s /home/dkeats/chisimba/framework/app/user_images/* .
cd ..

Chisimba expects to find the modules that are outside of the core in the directory packages. Therefore, we create this directory, and symlink all the modules into it. Once again, we do it this way to keep the subversion repository clean, and avoid accidental contamination.

mkdir packages
cd packages
ln -s /home/dkeats/chisimba/modules/* .
cd ..

Lastly, we chmod the installation directory to 777 so that you and the webserver have write access to it, keeping in mind that using 777 on any machine on the Internet as a webserver is a recipe for getting hacked. Rather use the production settings as recommended in the Chisimba installation guide for production servers.

sudo chmod 777 cms -R

Thats it, you now have a fully operational Chisimba instance, and you can repeat this procedure for as many Chisimba instances as you would like to have on your developer machine. Now you can proceed with the install.

Step 3: Install your instance

You can now install your instance of Chisimba by opening http://yourserver.yourdomain/yourinstancename/ in the usual way. For example, in my case, I would open http://localhost/cms/ and run the installer. Before you use my automated script, you should do this manually at least once, so you have an understanding of how it works.

Automating the process

Having just done this process for the umteenth time, I decided to make  very simple bash script to automate it. To make it work, you first need to edit the script and change some settings as indicated in the script itself. The lines that you need to edit are:

CHISIMBA_SVN="/home/dkeats/chisimba/framework"
MODULES_SVN="/home/dkeats/chisimba/modules"
SKINS_SVN=="/home/dkeats/chisimba/skins"
SERVER_ROOT="/var/www"

Change the above lines to correspond to your setup. If you have followed the checkout instructions, and you are running Ubuntu, you should not need to change anything.

The script is as follows:

#!/bin/bash
#  This script creates a developer clone of a chisimba
#  subversion checkout. Do not use this on a production
#  server. It is for setting up a developer machine only.
#  Author: Derek Keats
#  License: GPL 2

#  Set the chisimba base directories for core, modules
#   and skins (this assumes that all Chisimba
#   files follow standard naming protocol in that directory)
#   IMPORTANT: Note that there is no trailing /
CHISIMBA_SVN="/home/dkeats/chisimba/framework"
MODULES_SVN="/home/dkeats/chisimba/modules"
SKINS_SVN=="/home/dkeats/chisimba/skins"

#  Set the webserver root location. This is usually /var/www
SERVER_ROOT="/var/www"

#Check if there is a supplied $1 input
if [$1 = ]; then
   echo "You did not supply a directory name to create."
   exit 0
fi


#Change to the server root directory
cd $SERVER_ROOT
echo "In $SERVER_ROOT, which contains"
ls -l
echo
echo

#Create the Chisimba instance directory
sudo mkdir $1
chmod 777 $1 -R
cd $1
echo "Created $1 directory"

# Create the symlinks to things that can be safely linked
ln -s $CHISIMBA_SVN/app/index.php .
ln -s $CHISIMBA_SVN/app/gateway.php .
ln -s $CHISIMBA_SVN/app/classes/ .
ln -s $CHISIMBA_SVN/app/core_modules/ .
ln -s $CHISIMBA_SVN/app/cron/ .
ln -s $CHISIMBA_SVN/app/installer/ .
ln -s $CHISIMBA_SVN/app/lib/ .
echo "Linked the core into $1, which now contains"
ls -l
echo

#Create a directory for skins and link it in
mkdir skins
cd skins
ln -s $CHISIMBA_SVN/app/skins/* .
echo "Created skins directory and linked core skins"
ls -l
cd ..

#Create a directory for user_images and link it in
mkdir user_images
cd user_images/
ln -s $CHISIMBA_SVN/app/user_images/* .
echo "Created user images directory and linked default images"
ls -l
cd ..

#Create a directory for modules and link it in
mkdir packages
cd packages
ln -s $MODULES_SVN/* .
echo "Created packages directory and linked to modules"
ls
cd ../..

#Make it all writeable and horribly insecure
sudo chmod 777 $1 -R
echo "Chmodded it all to VERY INSECURE."
echo "All done. Bye....."

You can download the script from here.

You need to run it as root, so put it somewhere, change to that directory, and run it as:

sudo sh clone-chisimba.sh DIRECTORY

where DIRECTORY is the name of the directory you want to create. For example

sudo sh clone-chisimba.sh cms

Using this script, you can have a new Chisimba demo installed and up and running in less than 3 minutes. As I have been writing this, it has just occurred to me that I could actually turn it into a full install by adding the SVN checkout to it. I will do that another time, test it and make another blog post about it.

 

         
Bookmark this post Trackback URL  No trackbacks were found for this post Comments 0 Attribution Share Alike PDF of this post email this post to a friend
Login




Remember me



Forgot your password?
HELP

toggle Twitter
You cannot tweet unless you are logged in, and on your own page.
Follow me on Twitter Follow me on Twitter
Friend me on Facebook Add me on Facebook
Chisimba Facebook group Chisimba Facebook group


toggle Next Ubuntu





Afrigator