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:

git:x:123:123::/home/git:/bin/bash

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:

Share this:

Like this:

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:

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!

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.

Conclusions

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.

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!

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.

Listed:

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:

… it’s time to install JBoss AS 7:

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.

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.

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:

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à!:

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:

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:

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 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:

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.

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:

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:

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:

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:

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:

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.

Share this:

Like this:

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.

Introduction

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:

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: 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

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.

Like this:

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.