Quickstart a git Linux box for repository sharing

I had the need to quick setup a Linux box for some git over ssh repository sharing. What follows are my DevOps notes on this task and setup.


If not already installed, install openssh-server and git by

sudo yum install openssh-server
sudo yum install git


sudo apt-get install openssh-server
sudo apt-get install git

add a ‘git’ user by:

sudo adduser --disabled-password git


sudo useradd --disabled-password git

Configuration of /etc/ssh/sshd_config

As I preferred to keep the option PasswordAuthentication yes as-is in the configuration of sshd, then I proceeded add following snippet at the end of the file:

Match User git
PasswordAuthentication no

Check setting of AuthorizedKeysFile option, comes handy next section

Configuration of Authorized Keys

Some system have ‘AuthorizedKeysFile‘ option configured in /etc/ssh/sshd_config as: ‘AuthorizedKeysFile %h/.ssh/authorized_keys‘ hence can follow the following document

sudo su - git
mkdir .ssh
chmod 700 .ssh
touch .ssh/authorized_keys
chmod 600 .ssh/authorized_keys

Then add to .ssh/authorized_keys one line per each of the authorized clients their SSH public keys, in the example form of:

ssh-rsa AAA<...>AbcdE== client1
ssh-rsa AAA<...>fgHiL== client2

This setup is ok for most system setups.

However, some other system have ‘AuthorizedKeysFile‘ option configured in /etc/ssh/sshd_config as: ‘AuthorizedKeysFile /etc/ssh/keys/%u_authkeys.pub‘ or similar, hence add (following previous example) to ‘/etc/ssh/keys/git_authkeys.pub‘ one line per each of the authorized clients their SSH public keys, in the example form of:

ssh-rsa AAA<...>AbcdE== client1
ssh-rsa AAA<...>fgHiL== client2

Ensure bash is used

Check /etc/passwd is setup as example form of:


Setup bare git project repository

Connect via ssh using the git account, or alternatively still via SSH but using another account and then command ‘sudo su - git‘, do the following commands:

cd ~
mkdir <git-project-name>.git
cd ~/<git-project-name>.git
git --bare init

Setup push with Eclipse

Add a remote, for example from “repository view” of the project, “Remotes” node, “Create remote…” and option by configure push URI:


A git ssh box1
A git ssh box2
A git ssh box3

For refs mapping I prefer to push all the branches given it’s a private remote server

From    refs/heads/*    To  refs/heads/*

A git ssh box4
A git ssh box5
A git ssh box6


It’s very convenient to setup a Linux box for git repository sharing via ssh.

My first Java 8 Lambda applied while using Drools

In one of the projects I’m working on, a Java EE and web application using Drools, data is shard-ed (splitted) across many knowledge sessions having their own knowledge base definitions – for different business reasons not described in this post. From an end-user perspective it is sometime required to perform the “union” of the results coming from a given Drools’ query, which may be defined in several, but not necessarily all, of the knowledge sessions.

Technically the query can be identified by a specific name and I need to “pull” the query results from each of the several knowledge sessions which actually have such query defined, finally merging all results into a single response.

In order to determine if a given knowledge session, do actually contain the query or not, I came up with:

boolean containsQuery = kieSession.getKieBase().getKiePackages().stream()
		.anyMatch(p -> p.getQueries().stream()
			.anyMatch(q -> q.getName().equals( queryName )));

Why I like it

Before Java 8 I had to use external iteration, and this was a little bit tedious especially for optimization purposes as explicitly iterating through Packages and Query names, I needed to manually manage to break out of /exit the iterations once the query was actually found.

Now that Java 8 is here with Lambda and Streams, and now that I can use it also on this codebase, writing code to perform this kind of operation is more trivial, and it’s also quite more of a “fluent” code to read in my opinion.

Why I like Java 8 Lambdas, and Streams

Because I like Functional Programming concepts, and as above I can switch from an external iteration to an internal iteration, where not only I don’t have any longer to manually manage Iterators, but also I could expect optimizations to “automagically” pop-up sometimes (e.g.: the code above should early terminate with true, if a true is returned by any of the lambdas at some point), but also I can finally pass a Function (Lambda) instead of every time declaring anonymous classes!

Running the Rule Engine EXercise over a month

My reex2014 – a Rule Engine EXercise for 2014 has been running live for over a month now, time to draw some functional and technical feedbacks.

Real case scenario #1

A functional example based on a real case scenario, starts with:

Which raises the relevant Alerts:


Some time later, this happens:

Which again raises the related Alerts:


Later when traffic resume:


Real case scenario #2

Another functional example based on a real case scenario, traffic momentarily suspended due to a person in the tunnel, followed by a resume of traffic operations.

The reex2014 web application offers a representation of the relevant Alerts:



Which are also available on the Android widgets accordingly:

Technical notes

This is the first time I use OpenShift Online PaaS to host an application which has to run over some time, rather than quick one-shot/disposable experiment. I’m very pleased with what you can do, especially with the public, free offering!
The only couple of pain-points I have to deal with, are:

  • Need tedious work-arounds to solve for Maven dependencies which are not available publicly. Yes, customer Maven dependencies can be installed via ssh once the gear is already created, but I cannot found a reasonable way to create a gear starting from an existing github repo, if this latter contains non-public maven dependencies.
  • Despite application being constantly used by users, sometimes it restarts anyway. This happened two times. The latter was due, I suppose, to “security updates” related to the infamous shellshock/bashbug apocalypse, but the first time this happened, frankly I couldn’t trace back the reason.

In any case, not bad at all, considering is a free public offering!

Camel framework proved once again really, REALLY great for providing ESB logic and effective integrations! In this case I use it as a micro-ESB to interconnect the JavaEE application with Twitter, Rome RSS readers, etc. In other contexts, I use Camel framework for ETL, ESB and integration needs, and I’m super pleased by how much it is effective.


The exercise proved its benefit already and I’m using it daily for my commuting needs!

Evolutions could target general-improvements about rules, to avoid duplications of Alerts when the PA is made in multiple languages, and to cover more RSS-related cases. On the JavaEE side, the next is definitely target to support for PUSH notifications, which would need to be enabled on the Android projects as well.

Welcome to my RPi: simple JavaEE exercise with webservice and JMS

So my Raspberry Pi has arrived and I was eager to try out some Java programming on it; actually, I wanted to have a first simple exercise to stress test it with a JavaEE container, which I choose JBoss AS 7. Of course the overall performances are nothing comparable to usual servers where you would normally deploy a JavaEE application, however being for small/home projects it doesn’t seems too bad either in order to get started!

Photo 16-12-12 20 24 38

The goal for this exercise is simple: develop a webservice to be exposed in a JavaEE application, which “spool” the content of the webservice call onto a JMS Queue.


  • Rasberry Pi (model B)
  • Java 7 SE for Embedded
  • JBoss AS 7 as the JavaEE container
  • Apache Camel
  • SoapUI to test the webservice
  • Hermes JMS as a consolle to access the JMS Queue

First things first, in order to install the Java SE 7 RE, I overall followed the instructions found here, and also a maybe plain but still interesting video on YouTube of what seems to be a Java User Group session – check out the related James Gosling video as well, it’s not RPi related but a very interesting talk nevertheless from THAT James Gosling!

Anyway, once the JRE is installed on the RPi:
JRE on the RPi

… it’s time to install JBoss AS 7:
Screen Shot 2012-12-16 at 10.49.27

In this case, what I did is a custom standalone.xml configuration file to have all the basics, plus JMS which HornetQ is the implementation for JBoss AS.

Time to code!

With the JBoss Developer Studio IDE (basically Eclipse IDE + JBoss Tools), Maven for a simple webapp, and switch Java Compiler to 1.6:


and some simple dependencies:



The former block is to have Apache Camel to simplify as much as possible, while keeping loosely coupled, the integration between the webservice and the JMS, while the latter block is for the JavaEE libraries provided by the JBoss AS container.

Then, time to code the webservice:

public class SpoolOnQueue {

	CamelBootstrap cb;

	public String sayHello(String name) {
	    cb.getProducerTemplate().sendBody("direct:spoolOnJms", name);
	    return "Your message has been spooled on JMS";

Which is actually rather simple: it defines a webservice class thanks to the @WebService and related @WebMethod annotation, for a sayHello() method of our interest, in charge of spooling the content of the message onto the JMS queue via the Camel’s sendBody() to a specific route.

There is a CamelBoostrap cb dependency injection, which is the JavaEE component in charge of managing the Camel context and routing, defined as:

public class CamelBootstrap {
	private CamelContext camelContext;
	private ProducerTemplate producerTemplate;

	public CamelContext getCamelContext() {
		return camelContext;

	public ProducerTemplate getProducerTemplate() {
		return producerTemplate;

	protected void init() throws Exception {
		camelContext = new DefaultCamelContext();
		camelContext.addRoutes(new RouteBuilder() {
			public void configure() throws Exception {
				// in the JMS connection we can use # for the ConnectionFactory because by not using Spring the default for Camel is the JNDIRegistry
				// just remind by default it's implied it's a Queue as per Camel JMS doc
				.log("spoolOnJms: ${body}")
		producerTemplate = camelContext.createProducerTemplate();

The CamelBoostrap therefore is a simple Startup, Singleton JavaEE Bean, in charge of initializing the CamelContext, the Camel’s ProducerTemplate, and the one and only camel route of our interest here:

  • starting at direct:spoolOnJms
  • logging the body content
  • and spooling the body content onto the jms:sample JMS Queue

Time to amend the web.xml configuration file to the 3.0 Servlet specs (meaning as well EJB 3 in this case) and linking the aforementioned SpoolOnQueue webservice class:

<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd" version="3.0">
  <display-name>Archetype Created Web Application</display-name>

Last thing before packaging up and deploy, is to define the JMS Queue, which in the camel route is defined as “sample”; to do so, there are several ways from JBoss consolle, to JBoss CLI, configuration files, etc. and in this case I opted for a deployable configuration file – in the WEB-INF/ directory it’s enough to place a HornetQ configuration file which must be ending with -jms.xml, et voilà!:

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
         <jms-queue name="sample">
            <entry name="jms/queue/sample"/>
            <entry name="java:jboss/exported/jms/queue/sample"/>

Note to self: in this case the -jms.xml HornetQ configuration file is to be placed in the WEB-INF/ directory because the application is packaged as a WAR, otherwise it should have been placed in the usual META-INF/ directory.

Time to deploy:
Screen Shot 2012-12-16 at 20.35.48

You may want to note the deployment takes longer if compared with today’s server or machine where you normally test and deploy these artifacts, however it’s not so bad for home project just reminds me the performance of my old Pentium II with JBoss 3 (or 5? can’t remember) with the difference that nowadays JavaEE 6 and JBoss AS 7 simplify and improve things by great extent.

Then, I use SoapUI to consume the SpoolOnQueue webservice with a call for a simple “Ciao here is some content to place on JMS. Matteo.” message:
Screen Shot 2012-12-16 at 20.37.47

In the JBoss log there is a line now for the Camel route started and spooling the body content on the JMS Queue.

Then, time to connect HermesJMS to this remote HornetQ / JBoss AS, as I hope to have contributed here:

When I start I can see the AS7 I can see in the log the RemoteConnectionFactory JNDI, but this cannot be seen in the console:9990 because of some bugs. However still:
12:47:16,653 INFO [org.jboss.as.messaging] (pool-4-thread-2) JBAS011601: Bound messaging object to jndi name java:jboss/exported/jms/RemoteConnectionFactory. With reference to the aforementioned -jms.xml HornetQ configuration file, from a REMOTE perspective: the RemoteConnectionFactory is on java:jboss/exported/jms/RemoteConnectionFactory, the Queue is on java:jboss/exported/jms/queue/sample

Therefore to configure HermesJMS

Step 1: Create a classpath group for HornetQ in HermesJMS
Only one JAR is needed, is the jboss-client.jar inside the directory bin\client of the JBoss AS 7 / JBoss EAP 6 directory

Step 2: Configure a HornetQ session in HermesJMS:
Class: hermes.JNDIContextFactory
Loader: HornetQ – the one defined in step #1

Step 3: In the Destionations of the HornetQ session which you are defining as part of step#2, Add a new Desitionation
Name: jms/queue/sample
Domain: QUEUE

Now in HermesJMS in the left tree structure you have your Sessions > Your Session > Queue which you can double-click to connect to. You want to notice that for the binding you set the RemoteConnectionFactory without the java:jboss/exported prefix, and the same goes for the Queue defined, where from java:jboss/exported/jms/queue/sample I stripped away the java:jboss/exported prefix. Also notice that you can define the username/password either via the (securityPrincipal,securityCredentials) properties as above, or either use the “Connection” settings fields (User, Password) at the bottom of the Session Preference page of step#2.

So because the webservice has been consumed, which in turn started the Camel route, to spool on the JMS Queue:
Screen Shot 2012-12-16 at 20.38.12

The message now appears on the “sample” JMS Queue which is now inspected thanks to the HermesJMS consolle application.

Why do I blog this

I wanted to have a first “stress” test exercise with my new Raspberry Pi, not only to develop with some Java on it, but using a recent JavaEE container: the performances are not the best, still requires time to deploy or to compile .jsp pages (more in following posts) however I do believe for small/home projects the Rapsberry Pi is a very interesting, cheap both in terms of money and power consumptions, and cool platform where to deploy simple JavaEE applications!
ps: code available on github.

Remote sensors and mobile access: a simple exercise (part 2)

Following from a previous post, in this part I will highlight the coding section of the exercise aiming to a very simple goal: enable mobile access to a remote sensor reading.

With reference to the architectural schema, I will focus on the left-hand side:

Architectural schema to address the exercise’s goal: “enable mobile access to a remote sensor reading”.

In this case I opted to make use of the Spring framework, to follow a structured approach while being able to deploy everything inside a plain Tomcat server; I will reserve my JavaEE 6 for a different exercise, this time I really wanted to play around with Spring.

So overall the dependencies from a Java perspective are:

  • XBee API
  • RXTX – this is for serial communication over USB, enabled by the FTDI chip / breakout board on which the XBee coordinator is mounted on (detailed in the previous post)
  • Spring
  • CXF RS – this is for making use of REST webservices
  • JUnit, logging, etc.

In turn the POM, as I like to Maven stuff, looks like this:

Screen Shot 2012-12-02 at 15.05.36

Then I developed the REST webservice which will buffer all the readings from the XBee; when the webservice is consumed, the call will de-spool all the buffered readings from the buffer and place it on the webservice response.

I’m going to describe this webservice in two steps. First, is the webservice class declaration along with the constructor code, extract:

public class XBeeService implements PacketListener {

	private XBee xbee;
	private Queue queue = new ConcurrentLinkedQueue();

	public XBeeService() throws XBeeException {
		xbee = new XBee();
		try {
			xbee.open(&quot;/dev/tty.usbserial-A4004CwJ&quot;, 9600);
		} catch (Exception e) {
			// TODO no xbee

	public void processResponse(XBeeResponse arg0) {
  • It is a Spring’s Service, line 18.
  • It is also a CXF REST webservice available on the “xbee” URL path, line 19; more on this later.
  • It implements the PacketListener interface, meaning I can setup this class to be a subscriber and notified every time it’s incoming a packet from the Coordinator XBee, line 20.
  • Every time a packet is incoming will be placed on an internal buffer, line 35.
  • The buffer is actually a Queue of XBeeResponse packets, and implemented with a proper java.util.concurrent class in order to support concurrency (as from one side the XBeeResponse will need to be buffered every time they are incoming from the XBee Coordinator, meanwhile the webservice call will need to consume the same XBeeResponse packets from the buffer), line 23.
  • The constructor on line 25 make sure all the stuff are properly initialized at Spring container start. Because as mentioned earlier, this is a Spring Service class.

So now that the webservice class has all the code in order to be properly initialized and listen for XBeeResponse and place them on the buffer, it’s time to implement the code for the webservice call, extract:

	public String getReading() {
		if (!xbee.isConnected()) {
			return &quot;&lt;p&gt;No xbee connected.&lt;/p&gt;&quot;;
		StringBuffer sb = new StringBuffer();
		XBeeResponse response;
		while ((response = queue.poll()) != null) {
			try {
				ZNetRxIoSampleResponse ioSample = (ZNetRxIoSampleResponse) response;
				sb.append(&quot;&lt;p&gt;Sample from &quot; + ioSample.getRemoteAddress64());
				if (ioSample.containsAnalog()) {
					sb.append(&quot; - 10-bit temp reading (pin 19) is &quot; + ioSample.getAnalog1()+&quot;&lt;/p&gt;&quot;);
			} catch (ClassCastException e) {
				// TODO not an IO Sample
		return sb.toString();

So this method will be invoked every time I submit a HTTP GET request at the “xbee/” URL:

  • It will check for the Xbee to be properly initialized, otherwise a simple dummy message is returned, line 43.
  • Otherwise, for every XBeeResponse packet de-spooled/consumed from the internal buffer, line 48, a simple string of the reading in English language is returned.
  • You can notice every line of message, being the former or latter case, is decorated by the HTML p tags.

So it’s now the turn of the web.xml descriptor, which role is to kick-start the Spring container and the CXF stuff, extract:

  &lt;display-name&gt;Archetype Created Web Application&lt;/display-name&gt;
        &lt;display-name&gt;CXF Servlet&lt;/display-name&gt;

Then it’s the turn of the Spring beans.xml file for the actual Spring components, extract:

    &lt;import resource=&quot;classpath:META-INF/cxf/cxf.xml&quot;/&gt;

    &lt;context:component-scan base-package=&quot;net.tarilabs.test&quot;/&gt;
    &lt;jaxrs:server id=&quot;restContainer&quot; address=&quot;/&quot;&gt;
            &lt;ref bean=&quot;ciaoService&quot;/&gt;
            &lt;ref bean=&quot;xbeeService&quot;/&gt;

Which will scan the package “net.tarilabs.test” (line 12) where I got the @Service annotated class for the webservice, which will be a proper Spring bean in the container, which I later bind to the jaxrs:server (line 17).

Now that the server backend is fully implemented, it’s now turn for some HTML.

I incorporate my favorites: Twitter Bootstrap templates, and jQuery. Then in the html page I just place the following div container:

      &lt;div class=&quot;well logarea&quot; id=&quot;thelogarea&quot;&gt;

Meaning it will be rendered as a Twitter Bootstrap well, containing a default p paragraph line, but it’s also a CSS logarea which I defined as:

.logarea {
  min-height: 300px;
  max-height: 300px;

in order to have some pre-defined height dimensions.

Now, it’s time for some jQuery magic: from the user’s browser, will poll the REST webservice to obtain new content to place inside the mentioned div:

function doUpdate() {
	  $.ajax({type: &quot;GET&quot;, url : &quot;./ws/xbee&quot;,
	          success: function (data) {
	             if (data.length &gt; 0)
	                var divx = document.getElementById(&quot;thelogarea&quot;);
	                divx.scrollTop = divx.scrollHeight;
	             setTimeout(&quot;doUpdate()&quot;, 2000);
	setTimeout(&quot;doUpdate()&quot;, 2000);

Specifically, consume the REST webservice via ajax call and on success, append the response of the webservice call inside the div (this is the reason why the webservice replies with html p line statements) and then programmatically move the div scrollbar all the way down to the bottom of it – simulating the trail command in Linux.

Time to deploy it on Tomcat and experience all the components working nicely all together:
Overview of the implementation modules and component which perform the goal: mobile access to a remote sensor reading.

Why do I blog this

This is the conclusion of this exercise; I reached my goal, enable mobile access to a remote sensor reading, by making use of some simple electronics and XBee modules, while for the coding part I leveraged the xbee-api with Spring and CXF REST webservices, along HTML5 and jQuery to access the data via mobile access.

Remote sensors and mobile access: a simple exercise

In these new series of articles, I want to share my experimentation with remote sensors and mobile access; nowadays there is a lot revolving around mobile and mobility, in addition to the “Internet of Things” widely announced – I don’t know if the Internet of Things will ultimately happen in the way predicted, but I wanted to have my go at it.

This exercise aims to a very simple goal: enable mobile access to a remote sensor reading.

In the followings, I will introduce the experiment I crafted for this exercise and document each module.


From the goal/delivery which I explained above, “enable mobile access to a remote sensor reading“, the first thing, is that I drafted a schema:

Architectural schema to address the exercise’s goal: “enable mobile access to a remote sensor reading”.

In this schema I already marked down some constrains for implementation, that is the use of the XBee modules: normally I try not to bind myself to implementation constrains while drafting the architecture; this is more dictated by the fact that I had these modules sitting in a box from past projects, so I wanted to put them to new use. The same applies for having a sensor to actually measure some sort of distance.

Here is a picture of all the modules and components working nicely all together:

Overview of the implementation modules and component which perform the goal: mobile access to a remote sensor reading.
Overview of the implementation modules and component which perform the goal: enable mobile access to a remote sensor reading.

In the picture above:

  • background, upper-right: the distance sensor connected to the XBee router module mounted on a prototyping breadboard
  • background, upper-left: the XBee coordinator module which receives the reading, connected to the MacBook which acts as the server implementation to access the reading’s data from the Intranet
  • foreground: an iPad accessing the web application hosted on the server which provides the reading’s data live, similarly to the Linux tail command

Remote sensor reading

In this section I will detail the lower part of the architectural schema and how the XBee modules enable for the remote sensor reading.

Implementation for the remote sensor reading: XBee modules and the distance sensor

In the picture above, from right to left:

  • The distance sensor, mounted on the fixed-mounting brackets
  • The XBee router module, mounted on the prototyping breadboard: this is connected to the distance sensor
  • The XBee coordinator module, this is connected to the server

The distance sensor is in fact a transducer which provides an analog signal related to the distance seen, in this case, up to the Post-it note block also mounted on the fixed-mounting brackets. The XBee router -the one mounted on the prototyping breadboard- performs the Analog-to-Digital (ADC) conversion of this analog signal into a reading transmitted via the ZigBee protocol, to the XBee coordinator module.

One interesting part in this section is actually the electrical schema on the distance sensor side:

Electrical schema on the distance sensor side

The schema is quite simple but in the details:

  • The distance sensor is a Sharp 2D120
  • The Sharp 2D120 requires power supply and complementary electrical circuit as documented in its own datasheet, in this case I bought it from Phidgets as P/N 1101 because I found a nice boundle with the Sharp 2D120 which is Phidgets P/N 3520.
  • The AIN signal out of the Phidgets 1101 will vary 0-5V, while the ADC on the XBee is expecting a 0-3V: in this case I brutally cut the AIN signal in half with R1 and R2 which are 220ohm. This brutality is justified by my priority in having some contingency out of the Phidgets 1101.
  • The block marked IC1 in the schema is actually a “break-out” module called XBee Adapter board from Parallax P/N 32403 which is used to conveniently mount the XBee on the standard hole sizes of the prototyping breadboard.
    • schema IC1-pin 12 corresponds to Parallax 32403 pin VSS which is ground, which in turn corresponds to XBee Pin 10 GND for ground as well
    • schema IC1-pin 13 corresponds to Parallax 32403 pin VDD which is +5V, which in turn will provide +3V to the Xbee module
    • schema IC1-pin 23 corresponds to Parallax 32403 pin IO1, which in turn corresponds to Xbee Pin 19 D1, which is Analog input 1 or Digitial input 1 – in this case it’s setup as Analog input 1

Next is to setup the XBee by configuring and flashing the correct firmware on them.

Starting from the XBee router module, the one in charge to perform the ADC of the distance analog signal and transmit it.

XBee router configuration

The XBee router must be setup in such way to connect to its coordinator, so you will notice the Destination address has been set to the address of the coordinator, ending with 403AE77A. I also setup in this case the Personal Area Network as 4747, from the X-CTU software appears not a valid address but accordingly to other reference is perfectly allowed.

XBee router configuration – ADC settings

Next is to setup pin D1 of this XBee router module as ADC. Once also this settings has been saved, time to flash the firmware and configuration on it with the appropriate function in the X-CTU software.

Then it’s turn for the XBee coordinator module; in this case it’s very simple, as it’s just to setup it as a coordinator:

XBee coordinator configuration

Then also time to save and flash this firmware as well.

The XBee coordinator is mounted on the XBee USB Adapter board from Parallax P/N 32400, which is very helpful to connect it via USB as a Virtual Com Port (VCP) thanks to the mounted FTDI chipset. This will auto-magically wire it a serial port /dev/tty.usbserial-xxxx on the Mac, although accessing it from Java – which is my preferred programming language of choice – is not the easiest thing.

This overall setup of the two XBee modules can be proved quickly by using a Processing sketch – as I was saying in an earlier post, it’s a very handy prototyping environment – as documented on the xbee-api Google code site, just to be sure it’s working already.

To be continued

This is the conclusion for the remote sensor access part, in follow-up post(s) I will explain the implementation details applied on the server, specifically the Java web application, xbee-api and Spring used, HTML5 and jQuery to access these readings and data via mobile access.

I won a badge!

I earned a badge on Stackoverflow!

So I earned this badge and proud of it :)

Why do I blog this

Well, actually I never give up, and I continued trying to find an answer to my technical issue, despite this stackoverflow entry did not reach the success I was really hoping for. Eventually after extensive researches, I was able to craft a solution to my original question. Fortunately there are a lot of resources online nowadays which greatly help, that is undiscussed. However, when you are facing a very specific issue there is also a rule which is still valid today, well summarized in “Johnny Bunko” book: persistence trumps talent. I think it’s not really a matter of talent itself actually, but on the value of persistence. And I believe this is valid not only for technical issue, but surely it applies broadly to life in general.

%d bloggers like this: