La voix d'Absimiliard

To content | To menu | To search

Thursday 25 June 2015

MacBookPro FR, VirtualBox and linux

I have a Macbook Pro Intel with a FR asserted keyboard. When i create linux VM on virtual box I never manage to have the right keyboard layout. Most of the keys work well excepted the §, @ - ... and a few symbol keys like |

Today I starting to find a solution

setxkbmap -model macbook79

this make most of the key fork, excepted |

To make it permanent, I have edit the file /etc/X11/xorg.conf.d/00-keyboard.conf

/// Section "InputClass"

       Identifier "system-keyboard"
       MatchIsKeyboard "on"
       Option "XkbLayout" "mac-fr"
       Option      "XkbModel"       "macbook79"

EndSection ///

that still not perfect, but it's better

Edit : | pipe is working !!! but only with right ALT key :)

Wednesday 24 June 2015

Centos 7 on Virtualbox

To have a development on linux, i decide to install a Centos 7 on VirtualBox 4.3.8 on my Mac. It sound easy, usually it is ... but i don't know why this time have have a lot of issue.

So first i have to disable the Update repository that introduce wrong dependency that disallow me to install Gnome for example. To do that I edit the file /etc/yum.repo.d/CentosOS-Base.repo and at the end of the bloc updates i add enabled=0.

After that i have to install few stuff to have my development environment working.

Continue reading...

Tuesday 16 June 2015


Autotools is the great collection of tool that allow you to configure and build code with the 3 commands :

  • configure
  • make
  • make install

I use them 10 years ago, but i don't remember well how to use it ...

So i found a good tutorial : Autotools Tutorial for Beginners

Monday 15 June 2015

A Terminal

Now i found how to make two RaspberryPi communicate together using RFCOMM Bluetooth protocol, I have to see how to implement the terminal part.

On server side i will have to execute a login shell and send all its output to the remote device, and read all its input from the client side.

So i have to fin d a way to fork the execution of bash --login and redirect STDIN and STDOUT ... and some all the small issue that make the terminal usable like :

  • reading each keyboard key without waiting a "return"
  • removing ECHO on STDIN
  • removing ICANON on STDIN
  • handling signal to proper ends terminal SIGCHLD
  • handling signal to adjust tty side : SIGWINCH
  • using pselect to manage FD event
  • using forkpid to create the pty

The sample code is available on my github repository

Friday 12 June 2015

Raspberry in bluez

I wake a morning and water to try to play a bit with bluetooth. So first i decide to see how to make communicate two raspberry PI using RFCOMM socket.

Then i find a really good book that describe how to start with bluez the linux API for bluetooth : An Introduction to Bluetooth Programming

The book contains great sample code to start my tests ... but it was not so easy to make them work.

I give here the main solution I have found to make the RFCOMM sample works.

Continue reading...

Tuesday 12 May 2015

Publish an API Service and have success

The idea is simple; nowadays everybody knows that exposing an API Service that will be used by a lot of developers that will create a lot of killer applications that will be used by millions of users will generate a big success for you. But as for other Internet services, exposing something on Internet is not enough to make it used. So often most of API Services are just never used because nobody care they exists.

Of course you can answer “Look at Facebook or Google, every time they propose a new API every body knows and it’s a success”. Yep but everybody is not Facebook or Google, and even them, look at Google+! They don’t need to make a lot of effort to promote a new service because they already have a lot of costumers that will make the promotion for them. It is to prevent company to abuse of that kind of situation that in Europe we have the notion of “abuse of a dominant position”.

So how can you make people see you service on Internet?

Continue reading...

Monday 11 May 2015

The legend of the One API

“One API to rule them all, One API to find them, One API to bring them all and in the darkness bind them”. There is no such thing as a one API. There are different kinds of API for different kinds of use. The rules to design them and to use them depend of the purpose of the chosen API. We can identify three main categories of API based on how they are exposed and on their purpose.

  • The Core API: It exposes elementary functions on a Data model to allow building a service.
  • The Service API: It exposes a service hat could be use by others applications.
  • The Presentation API: It exposes an API dedicated to an application for performance issues and simplifies development.

Continue reading...

Sunday 10 May 2015

Architecture: The source of the Devops Path

One of the most important challenges of a project that wants to engage itself on the Devops Path is to reduce the noise on information flows between activities. Each time you have to take a data from a document to put it on another you create noise. You can make a mistake on the copy/paste; you can misunderstand the value you copy and loose some information or create false one; or you just cost time on a useless action.

To limit noise, the idea is to share the same Information System with all activities in a way it allow each one to have that fit its own needs.

All start with the architecture. If the guy who think the architecture of your project design that for some purpose component A has to send requests to component B to consume the API it proposes; it imply a lot of configuration.

  • Component B has to listen connection on its IP and port.
  • A flow has to be open between component A and component B with the valid IP and port (and all elements on the route have to be properly configured).
  • The IP and port of component B has to be configured on component A playbook.
  • Component B has to be monitored on component A side (it’s a resource of component A).
  • The context of the requests sent from component A to component B has to be documented for Support team.

Here for example we saw that the network flows are not really attached to the VM but to the software components that are deploy on those servers.

Continue reading...

Monday 4 May 2015

Support: A POI on Devops path

How the support team will manage to diagnostic issue is rarely think from the begining. Usually on non Devops project, developer create a software they give to integration that package it and deliver to operator that install and try to keep it up and running until next release. And then marketing detect a strange issue, so they ask dev team to investigate and as they don’t understand what occurs they send a kindly mail to operators “We have a strange issue. Thanks to investigate quickly” just like they could send lemons to Cave Johnson. The problem here is that developers should have the best knowledge of how their software works. So if they don’t know how to investigate the issue, how could they think other guys know?

The Devops Path offer a way to solve those kind of issue; Developers will have to take care of support needs on build phase rather waiting issues occurs.

What support team need?

To be allow to do troubleshooting and to keep a service up and running, you need several tools:

  • Monitoring: To check every component and their resources are ok.
  • Post Install check: To check all components are well configured.
  • Organized Logs: To check if a problem has occurs on use of the service.
  • Functional Diagnostics: To check all the data are consistent

And for all those checks, actions plan to solve the issue.

Continue reading...

Saturday 2 May 2015

What about continuous delivery?

Continuous delivery comes after continuous integration. The idea is to be able to have fluid deliver process to put evolution of application on production. One way that looks easy and simple to do continuous delivery is to automate the process of the delivery to allow developers to automatically send their stuff on the production platform without involving someone else. But as I try to present it on my previous ticket this is the dark path of the Devops.

The good way to make the delivery process fluid is to remove useless actions and documentations but to be careful to keep important knowledge exchange between team. For example having a word document that explain every command the operator has to copy/past to do the install is not an efficient way to allow him do deploy the software and to learn how to operate it. It could be great if the document that describe how to deploy the software could be understand by all the people involve and automatically execute by the computer.

So the first step is to find a way that all team involve on the delivery and deployment of the software speak the same language. It have to be simple to write but also simple to understand by some who use it; if you already has try to debug a big shell script you know that understanding script language is not always enough to understand what a shell does.

One language I found good for that need is the state language use by tool like Puppet or Ansible. Your deployment document describes the state of each element and its dependence with the other elements. When your document is executed by the tool, it ordnance each element according its dependence and check the state of each one, executing the action to change the state if needed.

So with little experience it is easy to write, easy to execute and easy to troubleshoot.

Continue reading...

The Devops path

Devops is the new Agility. As for Agility few years ago every IT projects are already or plan to be soon in Devops mode. But as for Agility when you speak with teams and check what is really done you quickly understand that most of people don’t know what Devops mean. It starts to become as Agility a good word to use for “bullshit bingo” and an excuse to do stupid things on IT project management.

The Wikipedia page about Devops starts with: “DevOps (a portmanteau of "development" and "operations") is a software development method that stresses communication, collaboration (information sharing and web service usage), integration, automation, and measurement of cooperation between software developers and other information-technology (IT) professionals.”

The Agility methods were created to solve the issues implied by the long development cycles on internet services: most of the functions think months ago are useless and now the service is launched we discover that most of the functions that users need have not been coded. So Agility methods answer those issues with shorter development cycles that allow building the service step by step with loopback from the user to redefine the target of the project.

Devops movement come from an observation: on small project that involve a team that work together on Think, Build and Run activity, the quality of the service is better and adding new feature on production are more “fluid” than for bigger project with clear boundaries between each team. So Devops principles are to reorganize the work on the project to remove the boundaries between teams and allow guys to better work together. Devops not just involve developers and operators; all the people involve on the project are concerned by Devops.

If your Devops approach is to remove one team of the equation, you are probably on the wrong way!

Continue reading...