L’amphi bleu -le plus grand et confortable- a ete reserve pour une conference ne paie pas de mine a priori: “Retours sur Java 8”. Pourquoi un tel engouement? La raison probable en est le speaker: Jean-Michel Doudoux, connu dans la planete Java francophone comme “jmdoudoux”.

JM Doudoux

Si un developpeur Java francophone a passe les 15 dernieres annees a l’isolement dans un goulag en Coree du Nord, voici un rappel: JM Doudoux est un GRAND monsieur, surtout connu pour ses tutoriels Java, qu’il publie continument depuis 1999. 17 ans, ca fait un bail… Jean-Michel est l’un des Java Champions francais.

Personnellement, je suis redevable a Jean-Michel d’avoir lu des dizaines et meme des centaines de pages de ses tutoriels, quand j’ai commence a utiliser Java en milieu professionnel et non seulement academique, et ce pendant des annees. Je ne compte pas les heures passees dessus, et je repense a la malheureuse imprimante de SGF au 5e etage qui avait la lourde tache d’imprimer chaque jour son lot de papier.

Pour revenir au personnage, premiere observation: Jean-Michel est populaire: l’amphi est plein, avec du monde dehors qui fait du forcing pour tenter de rentrer. Parmi l’assistance, un tiers de la salle n’utilise pas Java 8, et on reconnait des grosses pointures de la communaute…

Jean-Michel est modeste. Il s’etonne qu’on lui ait affecte le grand amphi, et plus encore que cet amphi soit plein.

Jean-Michel est accessible. Il ne refuse pas de parler et faire des selfies apres sa conference et dans les couloirs.

Enfin, Jean-Michel est quebecois ou, du moins, il parle parle comme les habitants de la Belle Province. Il mentionne “fabriques”, “didacticiels” et autres “bonnes pratiques” la ou d’autres cedent aux courants dominants des “factories”, “tutorials” et “best practices”.

(Note: pour ma part je reste sceptique sur certaines traductions, et prefere recourir aux termes originaux)

Retours sur Java 8

Jean-Michel revient d’abord sur les notions de best practice, definie comme une facon de resoudre un probleme meilleure que les autres. Les best practices sont mouvantes (dans les mots: “empiriques, contextuelles et mouvantes”) avec le temps car les methodologies, materiels et logiciels evoluent, et necessitent donc d’etre periodiquement remises en cause.

Ensuite Jean-Michel revient sur les differents apports de Java 8: comme l’Optionnal, les streams, les default methods et la nouvelle API Date, etc.

Si je resume grossierement l’intervention de Jean-Michel: utiliser les Optionnal en faisant attention, idem pour les streams.

With the master

Liens

• Site
• Twitter

J’ai pu feliciter en direct l’equipe de Codenvy, qui tenait un stand promouvant Eclipse Che.

Histoire personnelle des IDE

Je ne suis pas plus un fan d’Eclipse. Mon opinion est que l’IDE a grandi de maniere anarchique et manque de nombreuses features d’IDEA, bien que le retard se comble avec le temps. La plethore de plugins fait que les incompatibilites sont nombreuses, et l’outil se revele lent au final. A vouloir etre le plus generaliste possible et contenter tout le monde, on finit par ne plus satisfaire meme con coeur de cible.

J’ai commence a coder en Java sous XEmacs ; mon premier IDE etait Sun Forte en 2002 aux Etats-Unis. J’ai continue avec Netbeans chez Philips en 2003 et bascule sous Eclipse en 2005 a mon entree chez Sungard-Finance (alias GP3). A l’epoque, la facilite de mise a jour et d’integration des plugins -en l’occurence Maven 1, Tomcat, Subversion, SOAP et Python- m’avaient conquis. Deja pourtant je devais regulierement passer du temps a gerer les conflits et nettoyer le workspace.

Mes premiers essais avec IDEA en 2007 ont ete laborieux, et sans l’insistance de mon equipe je dois avouer que j’y aurais renonce. J’ai encore du utiliser ponctuellement Eclipse en 2010, quand le support de GWT par IDEA n’etait pas convenable, puis en 2013 a l’occasion de l’ecriture de mon premier ouvrage.

Quant a Codenvy.com, j’ai fait sa connaissance en avril 2015. Je l’utilise regulierement pour de petites operations, lorsque ma machine principale de developpement n’est pas disponible.

Aussi c’est dire que je n’ai pas aborde le stand de la Fondation Eclipse avec un oeil favorable. Mais j’ai vite change d’avis quand je me suis fait aborder par un exposant et lui ai dit que, sans vouloir troller, a part Codenvy je ne comptais pas consacrer du temps a Eclipse pour les mois qui viennent.

Codenvy

La philosophie de Codenvy est que notre code source est heberge sous Github, notre base de donnee est sur le cloud et notre application est deployee chez Amazon WebServices. Alors pourquoi ne pas coder directement sur le cloud?

Codenvy met a disposition un IDE en ligne, ma foi bien pratique. Ne nous leurrons pas, en l’etat actuel Codenvy ne peut pas remplacer IntelliJ IDEA, a moins d’etre pret a sacrifier 50% de sa productivite, ce que peu de monde peut se permettre, surtout en milieu professionnel.

Techniquement, Codenvy se presente comme une application web incluse dans le navigateur. Sous le capot tourne le moteur d’Eclipse Che, le futur de l’IDE de la Fondation Eclipse.

Codenvy ne propose pas qu’un editeur de fichiers. Des clients Git et SVN permettent de recuperer ou modifier le code sur un gestionnaire de versions. Enfin, il offre aussi des espaces d’execution sous Docker. Il est ainsi possible de coder une application web, monter une base de donnees MongoDB dans un Docker et deployer le WAR dans un autre conteneur.

Use cases

Les use cases de Codenvy sont assez varies. J’en vois deux principaux:

Programmation classique

L’editeur de Codenvy permet de developper en environnement decentralise et distribue. L’IDE en ligne a le meme interet que l’editeur de documents sous Google Drive: il est accessible depuis partout, sans necessite d’installer quelque software que ce soit ; de plus, il est toujours mis a jour, sans intervention de l’utilisateur.

Un interet sous-jacent est que le developpement se fait sous un client leger, et la puissance de l’ordinateur hote n’est pas fortement sollicitee: en effet, les operations fortement consommatrices de resources (comme la compilation ou les divers appels IO) sont effectues sur le cloud. Aussi, il devient possible, comme cela m’arrive de temps en temps, de sortir un netbook de 10 ou 11″ de diagonale, avec un simple Atom et 2Go de RAM, pour corriger un bug, commiter et pusher sur Github puis redeployer une instance de prod. Oui oui, a partir un PC qui n’a rien d’un Core i7/SSD/16Go.

Partage d’espace de developpement

Le second cas d’utilisation est le partage de bug/cas via des plateformes sur le net. En cas de probleme, inutile d’uploader un zip, le recuperer, installer le projet, et les librairies, etc. sur le poste local. Non, la personne levant le bug cree juste un espace sur Codenvy, avec la bonne configuration et le cas de reproduction de bug, cree une issue dans Github et poste un lien sur Stackoverflow. Le reste de la planete developpeur peut acceder a l’espace, eventuellement le dupliquer, et resoudre le probleme. Cerise sur le gateau: le ticket sous Github se met a jour avec les commits.

Limitations

Bien evidemment, Codenvy en tant que client leger vient avec son lot de limitations. Tout d’abord, il n’est pas possible d’installer de plugins, par consequent il devient difficile de gerer les langages exotiques.

Les principaux reproches que je fais a Codenvy sont les suivants:

• pas de completion automatique. Il faudra connaitre ses APIs! 😀
• support assez limite de Git: les merges sont une galere.
• raccourcis claviers non configurables. Une vraie torture quand on doit tout faire a la souris.
• support limite des projets Maven multimodules. Il faut ruser pour pouvoir deployer un WAR.
• pas de support des telephones mobiles et des tablettes. L’experience est vraiment penible.

Stevan Le Meur, qui travaille (EDIT: dirige?) dans l’equipe de developpement m’a fait une presentation de la version actuellement beta. Elle corrige de nombreux problemes. J’espere pouvoir acceder rapidement a la beta pour me faire une idee plus precise, mais ce que j’ai pu voir etait enthousiasmant.

L’interface de la version beta

Liens

• Codenvy:
  • website,
  • compte Twitter,
  • hashtag #Codenvy
• Eclipse Che
• Stevan Le Meur:
  • LinkedIn,
  • Twitter

Je demarre une serie d’articles sur Devoxx France 2016.

Je n’ai pas pu assister a DevoxxFR en 2015, aussi c’est ma premiere fois experience au Palais des Congres a Porte Maillot. Connaissant cet endroit pour avoir participe a d’autres salons et conferences, je ne suis pas totalement perdu.

Quelques remarques a chaud, en vrac:

General

Les sacs ne sont pas distribues a l’entree, mais a l’interieur, dans un stand “goodies”, aux horaires d’ouverture aleatoires pendant les pauses… Resultat: n’ayant pu me procurer mon sac et le cahier que tard, et je n’ai pu prendre de note ce premier jour.

D’autre part, il faisait chaud dans chaque salle, surtout en amphi Maillot… Je compatis avec les speakers qui ont du parler sous les spots de lumiere :-D.

Choix des sujets

Bien sur, la plupart des conferences etait reellement interessante ; neanmoins, il faut le reconnaitre, somme toute assez limitee dans la diversite: les sujets tournent principalement autour des microservices, Android, devops, BigData, etc.

Je ne crains pas que quiconque se soit ennuye. Cependant, si ces sujets sont “tendance” (et concernent les “hipsters” selon les mots de Matt Raible), concretement ils ne parlent pas forcement a tous les developpeurs. En effet, en France la structure du marche du travail fait que, pour une large part d’entre eux, les developpeurs travaillent chez des “grands comptes”, de type banques, assurance, telecom, etc. Je doute que chez les “grands comptes”, beaucoup de monde travaille en 2016 en mode agile sur des micro-services deployes sur des conteneurs Docker heberges sur un cloud orchestre par Kubernetes, pour traiter du BigData en temps reel dont les resultats sont pushes vers une tablette Android via un API REST securisee en HTTPS 2…

De mon cote j’ai la chance de travailler chez une grande variete de clients (finance, assurance, mais aussi PME et startups), donc pas trop de frustration. Cependant, si j’approuve l’ouverture a d’autres technologies et sujets, je regrette que Devoxx s’eloigne peu a peu de ses fondamentaux: l’ecosysteme Java.
Je suis bien conscient qu’il est impossible de contenter tout le monde. Mais peut-etre faudrait-il prevoir plusieurs “niveaux”, pour permettre d’avoir a la fois des ouvertures sur le futur, des initiations pour debutants pour certaines technologies, ou bien des retours d’experience sur comment pousser dans ses retranchements un “vieux” framework utilise sur du code legacy (sachant que dans nos metiers, “vieux” signifie “age de plus de 2 ans”).

Stands et goodies

Ca allait du minimal (stand petit, pas d’interlocuteur technique) avec quelques stylos, au plus original, en passant par les classiques distributions de tee-shirts. Cette annee, la couleur dominante etait le noir.

Opinions personnelles:

• les stands les plus grands ne sont pas forcement les meilleurs.
• en general, les geeks preferent parler a des ITs, plutot qu’a des administratifs/recruteurs/commerciaux qui sont persuades qu’AJAX est un club de football des Pays-Bas.

Sponsors

On remarque l’absence de Google et Oracle pour les “gros”, et d’Octo et Xebia du cote des SSII francaises. Evidemment, les entreprises communiquent beaucoup quand elles sont sponsors, beaucoup moins lorsqu’elles ne le sont pas. Nous en sommes donc reduits a speculer sur le “desinteret” de ces entreprises pour Devoxx: reel retrait strategique, desaccords sur ce que doit etre Devoxx, ou simple question de business/marketing.

Parmi les presents, Zenika et TalanLabs ont reussi a s’imposer dans le carre de sponsors platinium, augmentant leur aura aupres de la communaute, aux cotes d’IBM et d’Amazon. J’ai apprecie l’idee du “Startup Village”: cela donne un apercu de nos jeunes pousses francaises.
En dehors de ca, les autres SSII qui se qualifient de “specialistes” de Java (a mon humble avis, il conviendrait plutot de les decrire comme “specialisees en Java”: aucune SSII n’emploie que des specialistes, et encore moins des cadors, du Java): Ippon, Mirakl, 42, Arolla, Aneo, etc.

Enfin, de nombreux editeurs et intervenant de la galaxie Java etaient presents: citons Jahia, IntelliJ, Sonar, Github, StackOverflow, etc. J’en ai profite pour remercier directement les equipes pour le travail et leurs apports a la communaute.

PS

Merci a TalanLabs de faire en sorte que ses consultants puissent assister a Devoxx 😉

François Beaufort, a Chromium Evangelist based in Paris, delivered an engaging session at Devoxx France 2015, sharing ten key lessons gleaned from diving into the open-source code of Chrome OS. Despite a last-minute rush to the stage, François captivated the audience with practical insights into Chrome OS’s architecture, emphasizing the power of exploring source code to understand and debug this web-centric operating system.

Exploring Chrome OS’s Open-Source Roots

François introduced Chrome OS, the operating system powering Chromebooks, built on the open-source Chromium OS project. He highlighted its web-based nature, where applications leverage HTML, CSS, and JavaScript. By enabling a specific flag, developers can right-click to inspect elements, revealing the underlying code of Chrome OS applications, such as the wallpaper app. This transparency allows direct debugging, transforming how developers interact with the system.

This accessibility, François noted, empowers developers to troubleshoot effectively.

Practical Debugging with Source Code

Through a real-world example, François recounted debugging a broken Linux distribution app, Gestan, on a Chromebook. By accessing the JavaScript console in the Dev Channel, he identified a compatibility issue with a Chrome update, enabling a swift fix. This approach bypasses traditional bug reporting, allowing developers to collaborate directly with maintainers. His session underscored the value of open-source code for rapid problem-solving.

François’s insights inspire hands-on exploration of Chrome OS.

Links:

• François Beaufort’s Google+ blog

Ludovic Champenois and Mandy Waite, stepping in for Ray Tsang, delivered a dynamic session at Devoxx France 2015 on Infinispan, a scalable Java-based key/value data store. As Google Cloud Platform advocates, they demonstrated automatic scaling on GCP, showcasing Infinispan’s ability to handle up to 500 nodes effortlessly.

Infinispan’s Scalability Features

Ludovic introduced Infinispan as a highly available data grid, ideal for distributed systems. He explained its key/value store mechanics, optimized for scalability, and demonstrated deployment on GCP’s Compute Engine. The platform’s auto-scaling capabilities adjust resources dynamically, ensuring performance under load.

This flexibility, Ludovic highlighted, simplifies infrastructure management.

Automatic Provisioning and Decommissioning

Mandy detailed GCP’s managed infrastructure, focusing on auto-scaling policies that prioritize removing short-lived or initializing VMs. Q&A clarified mechanisms for controlling instance removal, such as manual group adjustments. This ensures minimal disruption during scaling events, maintaining system stability.

These policies, Mandy noted, enhance operational reliability.

Practical Deployment and Feedback

The duo showcased deploying Infinispan clusters, leveraging GCP’s free trial ($300 credit) for experimentation. They directed attendees to a feedback form and GitHub resources for deeper exploration, encouraging hands-on testing.

This session equips developers for scalable deployments.

Links:

• Ludovic Champenois on LinkedIn
• Mandy Waite on LinkedIn

Cécilia Bossard, an agile developer at TIM Consulting and co-founder of Women In Technology Nantes, shared a compelling narrative at Devoxx France 2015 about migrating a decade-old software project from SVN to Git. Cécilia detailed how GitFlow streamlined versioning across diverse client deployments, transforming a chaotic process into a manageable one.

Challenges of SVN in a Multi-Version Environment

Cécilia recounted the struggles of managing multiple software versions for clients using SVN. The heterogeneous client base led to complex branching and merging, with the Eclipse SVN plugin causing performance issues due to frequent polling. This inefficiency sparked the team’s decision to explore Git, seeking a more robust solution for their aging product.

This context, Cécilia explained, highlighted SVN’s limitations.

GitFlow’s Streamlined Workflow

Adopting GitFlow, the team established a clear branching model, with feature branches merging seamlessly into development streams. Cécilia shared a developer’s astonishment at completing a day-long merge in minutes, showcasing Git’s efficiency. The migration retained SVN for older versions, porting changes to Git, ensuring continuity while transitioning.

This shift, she noted, revitalized development speed.

Links:

None available

Etienne Peiniau, a Java architect at Ekino, presented a concise yet insightful session at Devoxx France 2015 on using Docker Compose (formerly Fig) to streamline development environments. With expertise in Spring, Hibernate, and cloud deployments, Etienne demonstrated how Docker Compose ensures reproducible, isolated setups for Spring Boot applications and their dependencies.

Docker Compose for Consistent Setups

Etienne introduced Docker Compose as an open-source tool, succeeding Fig after its acquisition by Docker. He showcased a YAML configuration file defining a Spring Boot app with dependencies like databases and caches. A single docker-compose up command spins up the entire environment, eliminating manual setup overhead. This approach rivals Vagrant and Foreman, offering simplicity and isolation.

This method, Etienne argued, ensures uniformity across developer machines.

Scaling and Load Balancing Demonstrations

Through live demos, Etienne illustrated scaling multiple instances of a web application, such as Elasticsearch, using Docker Compose’s scale command. He showed how it automatically balances loads across instances, simplifying testing and development. His GitHub repository provides additional examples, enhancing accessibility for experimentation.

This functionality, Etienne noted, boosts development agility.

Links:

• Etienne Peiniau on Twitter/X
• Ekino company website

Lecturer

Michael Hüttermann, a freelance DevOps consultant from Germany, specializes in optimizing software delivery pipelines. With a background in Java development and continuous integration, he has authored books on Agile ALM and contributes to open-source projects. His expertise lies in integrating tools like Maven, Jenkins (formerly Hudson), Artifactory, andទ

System: ## Git, and Maven to create efficient release processes. His talk at Devoxx France 2014 shares practical strategies for streamlining software releases, drawing on his extensive experience in DevOps consulting.

Abstract

Releasing software with Maven can be a cumbersome process, often fraught with manual steps and configuration challenges, despite Maven’s strengths as a build tool. In this lecture from Devoxx France 2014, Michael Hüttermann presents a comprehensive guide to optimizing the release process by integrating Maven with Hudson (now Jenkins), Artifactory, and Git. He explores the limitations of Maven’s release plugin and offers lightweight alternatives that enhance automation, traceability, and efficiency. Through detailed examples and best practices, Hüttermann demonstrates how to create a robust CI/CD pipeline that leverages version control, binary management, and continuous integration to deliver software reliably. The talk emphasizes practical configurations, common pitfalls, and strategies for achieving seamless releases in modern development workflows.

The Challenges of Maven Releases

Maven is a powerful build tool that simplifies dependency management and build automation, but its release plugin can be rigid and complex. Hüttermann explains that the plugin often requires manual version updates, tagging, and deployment steps, which can disrupt workflows and introduce errors. For example, the mvn release:prepare and mvn release:perform commands automate versioning and tagging, but they lack flexibility for custom workflows and can fail if network issues or repository misconfigurations occur.

Hüttermann advocates for a more integrated approach, combining Maven with Hudson, Artifactory, and Git to create a streamlined pipeline. This integration addresses key challenges: ensuring reproducible builds, managing binary artifacts, and maintaining version control integrity.

Building a CI/CD Pipeline with Hudson

Hudson, now known as Jenkins, serves as the orchestration hub for the release process. Hüttermann describes a multi-stage pipeline that automates building, testing, and deploying Maven projects. A typical Jenkins pipeline might look like this:

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git url: 'https://github.com/example/repo.git', branch: 'main'
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Deploy') {
            steps {
                sh 'mvn deploy -DskipTests'
            }
        }
    }
}

The pipeline connects to a Git repository, builds the project with Maven, and deploys artifacts to Artifactory. Hüttermann emphasizes the importance of parameterized builds, allowing developers to specify release versions or snapshot flags dynamically.

Leveraging Artifactory for Binary Management

Artifactory, a binary repository manager, plays a critical role in storing and distributing Maven artifacts. Hüttermann highlights its ability to manage snapshots and releases, ensuring traceability and reproducibility. Artifacts are deployed to Artifactory using Maven’s deploy goal:

mvn deploy -DaltDeploymentRepository=artifactory::default::http://artifactory.example.com/releases

This command uploads artifacts to a specified repository, with Artifactory providing metadata for dependency resolution. Hüttermann notes that Artifactory’s cloud-based hosting simplifies access for distributed teams, and its integration with Jenkins via plugins enables automated deployment.

Git Integration for Version Control

Git serves as the version control system, managing source code and enabling release tagging. Hüttermann recommends using Git commit hashes to track builds, ensuring traceability. A typical release process involves creating a tag:

git tag -a v1.0.0 -m "Release 1.0.0"
git push origin v1.0.0

Jenkins’ Git plugin automates checkout and tagging, reducing manual effort. Hüttermann advises using a release branch for stable versions, with snapshots developed on main to maintain a clear workflow.

Streamlining the Release Process

To overcome the limitations of Maven’s release plugin, Hüttermann suggests custom scripts and Jenkins pipelines to automate versioning and deployment. For example, a script to increment version numbers in the pom.xml file can be integrated into the pipeline:

mvn versions:set -DnewVersion=1.0.1

This approach allows fine-grained control over versioning, avoiding the plugin’s rigid conventions. Hüttermann also recommends using Artifactory’s snapshot repositories for development builds, with stable releases moved to release repositories after validation.

Common Pitfalls and Best Practices

Network connectivity issues can disrupt deployments, as Hüttermann experienced during a demo when a Jenkins job failed due to a network outage. He advises configuring retry mechanisms in Jenkins and using Artifactory’s caching to mitigate such issues. Another pitfall is version conflicts in multi-module projects; Hüttermann suggests enforcing consistent versioning across modules with Maven’s versions plugin.

Best practices include maintaining a clean workspace, using Git commit hashes for traceability, and integrating unit tests into the pipeline to ensure quality. Hüttermann also emphasizes the importance of separating source code (stored in Git) from binaries (stored in Artifactory) to maintain a clear distinction between development and deployment artifacts.

Practical Demonstration and Insights

During the lecture, Hüttermann demonstrates a Jenkins pipeline that checks out code from Git, builds a Maven project, and deploys artifacts to Artifactory. The pipeline includes parameters for release candidates and stable versions, showcasing flexibility. He highlights the use of Artifactory’s generic integration, which supports any file type, making it versatile for non-Maven artifacts.

The demo illustrates a three-stage process: building a binary, copying it to a workspace, and deploying it to Artifactory. Despite a network-related failure, Hüttermann uses the opportunity to discuss resilience, recommending offline capabilities and robust error handling.

Broader Implications for DevOps

The integration of Maven, Hudson, Artifactory, and Git aligns with DevOps principles of automation and collaboration. By automating releases, teams reduce manual errors and accelerate delivery, critical for agile development. Hüttermann’s approach supports both small startups and large enterprises, offering scalability through cloud-based Artifactory and Jenkins.

For developers, the talk provides actionable strategies to simplify releases, while organizations benefit from standardized pipelines that ensure compliance and traceability. The emphasis on lightweight processes challenges traditional heavy release cycles, promoting continuous delivery.

Conclusion: A Blueprint for Efficient Releases

Michael Hüttermann’s lecture offers a practical roadmap for streamlining software releases using Maven, Hudson, Artifactory, and Git. By addressing the shortcomings of Maven’s release plugin and leveraging integrated tools, developers can achieve automated, reliable, and efficient release processes. The talk underscores the importance of CI/CD pipelines in modern software engineering, providing a foundation for DevOps success.

Links

• Lecture video
• Jenkins official site
• Artifactory official site
• Maven official site
• Git official site

Mathieu Ancelin, a Java EE expert at SERLI, introduced React, Facebook’s JavaScript library, at Devoxx France 2015. With a focus on component-based UIs, Mathieu demonstrated how React’s JavaScript-centric approach eliminates templates, enabling reusable, testable interfaces for dynamic applications.

React’s Component-Based Paradigm

Mathieu highlighted React’s departure from traditional templating, using pure JavaScript to define components. This expressiveness supports complex UIs with evolving data, as seen in his Reddit iOS client demo, coded entirely in React with native iOS components. The approach ensures consistency across platforms, aligning with the “learn once, write everywhere” philosophy.

This paradigm, Mathieu argued, simplifies scalable UI development.

Flux for Unidirectional Data Flow

He introduced Flux, a pattern for managing application state with unidirectional data flows. User actions dispatch to stores, updating views via events, ensuring predictable state management. His demo showcased a mobile app, emphasizing React’s versatility beyond HTML to native components.

Mathieu noted Flux enhances application robustness.

Cross-Platform Potential

Despite a demo glitch, Mathieu’s Reddit client illustrated React’s cross-platform capabilities, rendering native iOS elements via JavaScript. Q&A explored Flux implementations, encouraging exploration of tutorials for deeper understanding.

This flexibility positions React as a powerful UI tool.

Links:

• Mathieu Ancelin on Twitter/X
• SERLI company website

Lecturers

Jose Antonio Lorenzo Fernandez, a PhD in physics turned software engineer, works at Lhings Technologies, specializing in Java EE and embedded programming. His transition from academia to industry reflects a passion for applying technical expertise to practical problems. Jose Pereda, a researcher at the University of Valladolid, Spain, focuses on embedded systems and IoT development, contributing to open-source projects that bridge hardware and software innovation.

Abstract

The Internet of Things (IoT) has revolutionized device connectivity, but developers often grapple with complex networking challenges, such as configuring routers, handling firewalls, and managing protocols. Presented at Devoxx France 2014, this lecture demonstrates how Lhings, a cloud-based platform, simplifies IoT development by abstracting connectivity issues, allowing developers to focus on device functionality. Through a live coding session, Jose Antonio Lorenzo Fernandez and Jose Pereda showcase how to connect Java-capable devices using open hardware and Lhings, eliminating boilerplate networking code. The talk explores Lhings’ core concepts—device management, secure communication, and web-based control panels—and highlights its scalability and reliability. By analyzing the platform’s architecture and practical applications, it provides a comprehensive guide for developers building IoT services, emphasizing rapid prototyping and real-world deployment.

The IoT Connectivity Challenge

The proliferation of affordable open hardware, such as Raspberry Pi and Arduino, has democratized IoT development, enabling rapid prototyping of smart devices. However, connectivity remains a significant hurdle. Residential routers, NAT configurations, and diverse protocols like MQTT or CoAP require extensive setup, diverting focus from core functionality. Lorenzo Fernandez explains that developers often spend disproportionate time on networking code, handling tasks like port forwarding or secure socket implementation, which can delay projects and introduce errors.

Lhings addresses this by providing a cloud-based platform that manages device communication, abstracting low-level details. Devices register with Lhings, which handles routing, security, and interoperability, allowing developers to focus on application logic. Pereda emphasizes that this approach mirrors the simplicity of web APIs, making IoT development accessible even to those without networking expertise.

Live Coding: Connecting Devices with Lhings

The speakers demonstrate Lhings through a live coding session, connecting a Java-capable Raspberry Pi to a sensor network. The setup involves minimal code, as Lhings’ SDK abstracts networking:

import com.lhings.client.LhingsDevice;

public class SensorDevice {
    public static void main(String[] args) {
        LhingsDevice device = new LhingsDevice("Sensor1", "API_KEY");
        device.connect();
        device.sendEvent("temperature", 25.5);
    }
}

This code registers a device named “Sensor1” with Lhings, connects to the cloud, and sends a temperature reading. No networking code—such as socket management or firewall configuration—is required. The platform uses encrypted WebSocket connections, ensuring security without developer intervention.

The demo extends to a web control panel, automatically generated by Lhings, where users can monitor and control devices. Pereda shows how adding a new device, such as a smart light, requires only a few lines of code, highlighting scalability. The panel supports real-time updates, allowing remote control via a browser, akin to a smart home dashboard.

Lhings’ Architecture and Features

Lhings operates as a cloud middleware, sitting between devices and end-users. Devices communicate via a lightweight SDK, available for Java, Python, and C++, supporting platforms like Raspberry Pi and Arduino. The platform handles message routing, ensuring devices behind NATs or firewalls remain accessible. Security is baked in, with all communications encrypted using TLS, addressing common IoT vulnerabilities.

Scalability is a key strength: adding devices involves registering them with unique API keys, with no upper limit on device count. The platform’s reliability stems from its distributed architecture, tested by thousands of users globally. Lorenzo Fernandez notes that Lhings supports bidirectional communication, enabling servers to push commands to devices, a feature critical for applications like home automation.

Practical Applications and Benefits

The talk showcases real-world use cases, such as a smart thermostat system where sensors report temperature and a server adjusts settings remotely. This eliminates the need for local network configuration, as devices connect to Lhings’ cloud over standard internet protocols. The web control panel provides instant access, making it ideal for rapid prototyping or production-grade systems.

Benefits include reduced development time, enhanced security, and ease of scaling. By abstracting networking, Lhings allows developers to focus on device logic—e.g., sensor algorithms or UI design—while the platform handles connectivity and management. The open-source SDK and GitHub-hosted examples further lower barriers, encouraging community contributions.

Challenges and Considerations

While powerful, Lhings requires an internet connection, limiting its use in offline scenarios. Pereda acknowledges that latency-sensitive applications, such as real-time robotics, may need local processing alongside Lhings’ cloud capabilities. The platform’s dependency on a proprietary service also raises questions about vendor lock-in, though its open SDK mitigates this by supporting custom integrations.

Conclusion: Empowering IoT Innovation

Lhings transforms IoT development by removing connectivity barriers, enabling developers to build robust services with minimal effort. The live demo at DevoxxFR2014 illustrates its practicality, from prototyping to deployment. As IoT adoption grows, platforms like Lhings will play a critical role in making smart devices accessible and secure, empowering developers to innovate without wrestling with networking complexities.

Links

• Lecture video
• Lhings official site
• GitHub repository for Lhings SDK
• Raspberry Pi official site