Monday, July 16, 2012

According to wikipedia "A Web service is a method of communication between two electronic devices over the Web (Internet)." I would not say over the 'Web', indeed you can communicate within a local area network without the need on going 'Web'.

On this tutorial we are going to explain step by step how to deploy a Web Service on our Rasberry. We are also going to see how to develop a little application in our laptop that will communicate with this Web Service.

The protocol used on a web service is called 'SOAP' and is based on 'XML'. The following diagram explains in a simplified way how a Web Service communication is carried out.

Fig.1 Simplified SOAP exchange diagram

The most common usage of Web Services is via HTTP, and that is the reason behind its popularity. In fact all the existing web infrastructure (from routers to web servers) fits perfectly on this model, without the need of adapt absolutely anything.

How the xml is formed, is specified on the SOAP protocol. Normally the commercial Web Services API, like the ones used on .Net, Java, or C++, hide the complexity of the protocol, so we can focus on our object s model and the 'dirty' work of converting those object on 'XML' (and viceversa) is completely transparent for us.

1. Downloading GSoap.

GSoap is a open source Web Service API, written in C and C++. You can download the last version from here.

There are 2 important tools shipped on the download, the one that we are going to use is called 'soapcpp2' and you can find it on the following path:

./gsoap-2.8/gsoap/bin/linux386/soapcpp2

2. Defining our service interface.

On this example we are going to create a service that returns the hour from our Raspberry.

The service interface is defined in a similar way than a library interface. We are going to create a header defining the method that will be called:

Fig. 2 Sevice Definition header

2. Generating the server classes.

Now that our service is defined, we have to generate the classes that will handle the request. Fortunately this can be done automatically by using 'soapcpp2'. Go to your project path (in my case ~/workspace/workspace64/GSoapTuto/MyRaspberryTimeServer/src) and execute soapcpp2 with the following options:

You will have to change the line 'm = soap_bind(&soap, "192.168.1.54", 2012, 100);' and set the IP of your Raspberry (192.168.1.54 in my case) and the port you want it to listen from (2012 in my case).

If you want to make the resultant program work on Raspberry, you will have to cross-compile it. You can do it by changing the properties of your project and performing the following changes:

Add the 'stdsoap2.cpp' and 'stdsoap2.h' as we did for the server. And finally add 'currentTime.cpp' including the main method with the following content:

Fig 7. Resultant client structure

Finally, on change the line 'soap_endpoint = "http://www.yourdomain.com/currentTime.cgi";' on the file 'soapcurrentTimeProxy.cpp' in order to target your Raspberry:

soap_endpoint = "http://192.168.1.54:2012"; in my case

And that's all!! If you fulfilled all the steps, after compiling and executing your client, you should get a beautiful result like 'The time is 1342473837' indicating the date in seconds from your Raspberry.

If you have a look to the Raspberry console, it should display some info about the just served request:

In order to generate programs that can run and be debugged on our RaspBerry, we need to install an appropriated compiler and an appropriated debugger.

2.2.1. Add the native compiler, make and ncurses library if they are not already in your development system.

sudo apt-get install gcc g++ make libncurses5-dev

2.2.2. Add the following line to /etc/apt/sources.list

deb http://www.emdebian.org/debian/ squeeze main

2.2.3. Install the following packages:

sudo apt-get install linux-libc-dev-armel-cross

sudo apt-get install libc6-armel-cross

sudo apt-get install libc6-dev-armel-cross

sudo apt-get install binutils-arm-linux-gnueabi

sudo apt-get install gcc-4.4-arm-linux-gnueabi

sudo apt-get install g++-4.4-arm-linux-gnueabi

sudo apt-get install uboot-mkimage

2.2.4. Install the remote gdb:

sudo apt-get install gdb-arm-linux-gnueabi

warning: At this point you can find conflicts with the already installed gdb (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603347). If it is the case you will need to upgrade from gdb 7.0.1 (the currently installed) to gdb 7.4.1 (You can find it on http://ftp.gnu.org/gnu/gdb/). You will need to download it, configure it and install it, but do not worry too much, there are just 3 steps that can be found on the README file inside the downloaded file.

3. Our first Raspberry project

3.1 Open Eclipse and click on File --> C++ Project

3.2 Select Cross-Compile Project and give it a name and click on finish.

Fig 2. Our first Raspberry project on C++

3.3 Create a "src" folder inside the just created project and include a source file called "main.cpp" inside it. Fill the main.cpp with the following content:

Fig 3. Content and structure of our first Raspberry project on C++

4. Cross Compiling and executing the 'Hello World' project

4.1 Now that we have our project written, we need to compile it. In order to do that, open the project properties select settings and on the 'Cross G++ Compiler' change the command 'g++' by arm-linux-gnueabi-g++:

Fig 4. Cross project compiler

4.1 Do the same on the Cross G++ Linker:

Fig 5. Cross project linker

4.2 Build the project, (Ctrl+b) you should get a message on the console like the following one:

Fig 6. Cross project linker

As you can see, the project has been compiled and linked by using arm-linux-gnueabi-g++, that was the whole point. If you try to run the compiled from eclipse you wont see nothing happening. If you try to run it from the command line, it wont be recognize as an executable:

Fig 7. Error when executing the result from the host

But if you copy it and execute it from the Raspberry:

Fig 8. Project executed from Raspberry

Voila!! Our first C++ Cross-project running on Raspberry :D

4. Cross Debugging the 'Hello World' project

Now that we have run successfully our project, let's see how we can debug it.

4.1 Install on your Raspberry gdbserver

sudo apt-get install gdbserver

4.2 Run gdb server against your program, listening on the port 2345:

gdbserver :2345 MyFirstRaspBerryProject

If everything went ok, the system should get stuck waiting for a remote debug:

Fig 9. gdbserver started on the raspberry machine

4.3 From Eclipse click on the arrow besides the symbol of debug and select 'Debug Configurations'. Click twice on the tab 'C/C++ Remote Application' an new remote application will be automatically created:

Sunday, April 22, 2012

As I already mentioned in one of my previous posts, CppUnit is a powerful framework that allows us to automatize the unit testing execution.Unit testing is an extremely important activity in our daily development life, not only from a theoretical quality-related point of view but also from a practical perspective like ensuring the behavior of our code before refactoring, preventing fixed bugs to appear once again etc.

The idea behind CppUnit is to develop parallel classes that will be the ones in charge of testing our 'real' classes. But let's have a look with an example.

1. Installing CppUnit

The first step of course is to get the tool and install it. You can download the last version from sourceforge (at this time 1.12.1) :

Basically open eclipse and click on File --> new, and under the opened dialog select Shared Library, and Linux GCC

As we are under a 64 bits architecture, do not forget to compile with -fPIC, otherwise you will get the following error:

/usr/bin/ld: ./Calculator.o: relocation R_X86_64_32S against `vtable for Calculator' can not be used when making a shared object; recompile with -fPIC

You can activate -fPIC compilation under eclipse by right click on your project and under properties check the following option:

Our library will contain a class 'Calculator' that implements two methods: add and sub (please note that both method are inlined for the shake of simplicity):

A. Creating the testing project

Now let's create our test project, that it will be just an an executable linked to our shared library and of course to the CppUnit framework.

First create a new executable project:

Now link your project against libdl, libcppunit and of course the result of the shared library that we are planning to test. You will need to include the folder where the shared library is generated on the library search path:

You will also need to include the path to our shared library headers in order to use it:

B. Creating the testing class:

Once finished ((almost)) all the including and configuring steps let's focus now on the 'pure' testing procedure.

The most basic case is to just create a class that inherit from CppUnit::TestCase and perform all the needed 'ASSERTS' on the overridden method 'runTest()', then on the main method of our testing project we just need to create a 'CppUnit::TextUi::TestRunner' and include our just created class as a test to be run:

Here below you can find the code for our test class:

And here the one corresponding to the main method (the one actually in charge of of execute the tests):

That's all, the last step you have to perform before running your test project is just to include your shared library on the environment of the run configuration:

Now you can run your testing project an have a look to the results on the console:

2. Making things more sophisticated by using TestFixture and TestSuite

What we have explained until now is quite nice and it should allows you to start writing your unit test within a cpp environment, but let's complicate the things a bit more and let's talk about testsuites and fixtures.

As you can see on the previous example, we are using the class TestCalculator and its overridden method runTest to create a test. This approach could be enough for most of the cases, but in some cases trying to test the functionality of a library by writing all the asserts in one method or by creating a lot of classes (one per test) can lead to confusion.

Here is where the TestFixture and TestSuite suites arrive. A TestFixture, basically allows us to convert methods of a class into a testcase, and a TestSuite will allows us to group all those tests and execute them as if it were just one. But let's see all that with an example:

We area adding TestCases to our TestSuite on the form of a methods (testSum and testSub). It is also worth to mention that setUp method is called each time before executing the actual testMethod and tearDown right after executing it, allowing us to set some pre-conditions (in case of needed) release them.

The last modification we have to perform to have everything working is on our main method:

Monday, April 9, 2012

Hello again!! Today I am going to talk about Jenkins, an open source tool that enables the continuous integration and delivery for our projects. As usual we will explain on this post how to set up a basic configuration and have the tool working into a local environment, if you are looking for a more complex configuration you can download here for free the book 'Jenkins the definitive guide'.

Basically what we are following with the continuous integration is to set up an environment that periodically and automatically check out our code, builds it and pass a set of regression/unit tests.

Jenkins provides us with a set of features that allows that and much more, as automatic mails in case of broken builds, dashboards showing the tests results, CVS/Mercurial and others version control systems integration and on the top of everything a friendly web based interface allowing everybody to check the results and manage the system.

5. Logs & PID. By default Jenkins is executed as a stand-alone server, you can find the logs and the process id on the following files:

/var/log/jenkins/jenkins.log
/var/run/jenkins/jenkins.pid

6. Jenkins is configured by default to listen on the port 8080, if you fulfilled the previous steps, you should be able to see your jenkins interface by typing 'localhost:8080' on your favorite web explorer:

B. Linking Jenkins with our Project across Mercurial

The way Jenkins interacts with our source code is across mercurial, once Jenkins is properly configured it checks out our code, into a temp folder, builds the source code and executes the test that we have previously configured.

First of all you will have to install and configure mercurial on your machine. You can have a look here in order to know how to do it.

1. Putting our code under mercurial:

Since the objective of this post is not learn how to use mercurial, we will create a 'local' repository in our working directory (in my case /home/javier/workspace/workspace64/workspaceSharedLibrary) by executing the following command from the previous folder:

hg init

Now our source code is under mercurial and therefore can be accessed by Jenkins, let's see how.

2. Installing the Mercurial Plugin on Jenkins:

The mercurial plugin is not installed by default. From the initial Jenkins web page, click on 'Manage Jenkins', and afterwards click on 'Manage Plugins'. Under the available tab, you should be able to find 'Jenkins Mercurial plugin'. Check it and click on the button 'Install without restart'.

C. Configuring a new job

Now we have everything we need to configure our first 'job'. In Jenkins world, a 'job' is a set of task (that can be defined on a shell script) that are automatically executed within a configurable period, typically those tasks are related with building and testing.

From the initial page (localhost:8080) click on 'New job'. Give a name to your (in my case 'My_firs_job') select 'Build a free-style software project' and click 'ok', a new page allowing configure your job should be displayed. On the first part of the screen we are configuring the Mercurial repository (the local one) that jenkins must check out:

By scrolling down, we set up the frequency of the job. By setting 'Poll SCM' and putting ***** on the Schedule we are indicating that each minute, jenkins must check if there have been changes on the code and if it is the case it must executes the job. In this case the build is defined on the shell file 'home/javier/SANDBOX/Jenkins/build'. We will see the content of this file on the next section.

Finally, by scrolling down again, we can set the list of emails that must be notified in case that a build is not broken.

D. Create the build file ( /home/javier/SANDBOX/Jenkins/build)

The most basic build file is the one that executes the makefile that eclipse generates automatically. The variable 'WORKSPACE' is set up automatically by jenkins and defines the temporally directory where the code is check out.

#!/bin/bash

echo "*********building************"

echo $WORKSPACE

cd $WORKSPACE/InitialTest/Debug

echo $PWD

make clean

make

E. Configure the mail

In order to allow mail sending we have to link our jenkins platform with a mail server. In this case I will use my gmail acount for this end.

From the initial jenkins page (localhost:8080) click on 'Manage Jenkins' and then on 'Configure System'. At the bottom of the page you can set E-mail Notification parameters:

D. Executing the job

Now everything is configured and you can manually execute your job:

From the initial Jenkins page, select your job and on the left side of the page click on 'Build now'. A new item will be created on the 'Build History':

By clicking on the Build History item, you can enter to the details of the build. The most interesting information can be found on the 'Console Output' :

By default Jenkins indicates a successful build with a blue ball. If you (like me) consider that green color is more appropriated for this end, you just need to install the 'Green Balls' pluging;

From the initial Jenkins page click on 'Manage Jenkins' then on 'Manage Plugins' and under 'Available' tab find the 'Green Balls' plugin. Select it and click on 'Install without restart'. In order to have the plugin working, you will need to clean the cache of your explorer.

F. Unit Tests

As final step we are going to set up a unit test project that will be automatically executed (as the build) each time that someone commit a change in the central repository.

The first thing we need is to install 'CppUnit'. CppUnit is an open-source project that provides us with a set of utilities allowing include statements like 'assert' in our code. You can find more information about CppUnit in the official project page:

3. Make a shell executing the test project and transforming the results

I will dedicate a whole post to CppUnit, but by the time being we will consider enough to have a project working and generating a resulting report test (you can find how to do this on the CppUnit cookbook)

Once we have developed our test project we just need to create a new shell script (/home/javier/SANDBOX/Jenkins/tests) that runs it and transforms the result into a new report 'readable' by Jenkins:

In the previous script we are just executing the auto-generated (by Eclipse) make file and applying a xslt transformation that generates 'testresults.xml' from 'cpptestresults.xml'. In order to do that you will need the transformation file (in our case /home/javier/SANDBOX/Jenkins/transform.xsl) with the following content:

Once everything is in place we just need to include a new shell in our Job. From the initial Jenkins page click on your existing job and on menu placed on the left, click on configure. On the build section click on 'Add Build Step' and select 'Execute shell'. Set the location of our script (in my case /home/javier/SANDBOX/Jenkins/tests) and save the changes.

Now when building our job and checking the console output you should see that the test unit project is executed: