Il y a quelques années déjà, je commençais le développement du prototype de UFO@home, un outil de témoignage visuel inspiré des travaux de Roger Shepard, Richard Haines, motivé par Pierre Lagrange dans le but d’améliorer le recueil de signalements d’ovnis. Comme je l’expliquais dans un billet, l’intérêt résidait aussi et surtout, pour moi, en la capacité d’un tel outil à simuler des hypothèses de phénomènes connus (astronomiques, ballons, météores, avions, oiseaux…), afin de les valider ou les exclure en accord avec le témoin. Une fois le prototype réalisé, il restait donc à produire une version au rendu le plus réaliste possible. Cela passait par la réécriture (puis plus tard l’extension ufologique) de la Rolls des logiciels de planétarium, Stellarium. Ainsi naquit Stellarium for Java (S4J).

Article initialement posté le 16 février 2008

Image for post
Image for post

C’est chose faite maintenant qu’une première version est disponible via le système Java Web Start (à installer auparavant, qui permet de lancer une application Java téléchargeable depuis Internet) sur SourceForge ou sur Java.net. Cette version n’est pas encore finalisée ni exempte de bugs, mais est utilisable. Elle a de plus été sélectionnée pour le salon JavaOne, où je devrais la présenter en mai prochain avec mon co-développeur.

Vous êtes donc cordialement invité à tester cette première version et rapporter toutes remarques ou problèmes que vous pourriez rencontrer, afin que nous puissions fournir une version finale digne de ce nom.

Une fois cette version “à l’identique” terminée et validée notamment par vos retours, la maîtrise du code source Java permettra l’ajout de fonctionnalités spécifiquement ufologiques dans un logiciel distinct, constituant la première version réaliste de UFO@home.


A JavaOne, toutes les sessions étaient évaluées. Les Java Cards pendues au cou de chaque personne pénétrant dans la salle les identifiaient et les comptaient, et des préposés leur distribuaient systématiquement à l’entrée des formulaires d’évaluation. Le but : noter la présentation, les présentateurs, la qualité des “diapos” (slides), des démos, etc. Alors, ça a donné quoi pour S4J ?

Article initialement posté le 6 juin 2008

Je viens en effet de recevoir le résultat de ces évaluations, et Le résultat est plutôt satisfaisant : sur les 117 personnes ayant assisté à la session consacrée à S4J, 57 ont bien voulu l’évaluer, la situant dans le meilleur quart de l’ensemble des présentations de JavaOne (4,35–4,95) avec une notre globale de 4,39 sur 5. Une évaluation qui est aussi au-dessus de la moyenne de ce type de présentation (4,13 pour les session techniques). …


De retour de San Francisco où je fus invité à la conférence JavaOne 2008, j’éprouve encore un peu le décalage horaire (8 heures quand même). Déjà un bon moment pour un développeur Java (des dizaines de sessions sur les sujets les plus divers, des puces de détection à la 3D sur téléphone portables, en passant par la cartographie martienne, mais bien sûr aussi des produits — WorldWind, GlassFish, OpenSolaris… — des APIs — OSGi, WebBeans, DarkStar, etc. — et diverses sessions plus générales), ce fut un événement plus important encore pour moi qui devait y présenter Stellarium for Java avec mon co-développeur, Frederic Simon. Le résultat a dépassé nos espérances. Mais au fait, ça ressemble à quoi une semaine de “speaker” à JavaOne ?

Article initialement posté le 13 mai 2008

Dimanche

12:30 (heure locale) : Après 10 longues heures de vol, l’avion s’apprête à descendre sur un San Francisco enfoui dans la brume mais l’aéroport nous refuse l’atterrissage : trop de traffic, par trop peu de visibilité. Nous sommes re-routés vers Oakland, où nous refaisons le plein finalement arriver à bon port, quelques heures plus tard. A la douane, je me trouve derrière 3 jeunes français qui viennent assister à la conférence. Apparemment il y en a beaucoup d’autres. Un saut à l’hôtel, et je m’efforce de garder les yeux ouverts pour aller vite m’enregistrer au Moscone Center, à 2 blocs de là. J’arrive au guichet sans queue des “speakers”. Une lecture optique du barcode reçu dans un mail et me voilà enregistré, avec pass pour toutes les aspects de la conférence (Community One, les sessions JavaOne et son pavillon d’exposants) et un premier passage obligé pour aller chercher mon matériel : un sac comprenant diverses livrets et goodies, puis un autre petit cadeau bonus en arrivant dans la salle des speakers. Je confirme la date de ma session, ainsi que celles de ma répétition technique (video-projecteur, micros, etc.) et de speaker coaching (aide à la répétition de la présentation). Une fois tout ce travail d’enregistrement terminé, j’erre dans les lieux encore presque vides (la conférence ne commence que demain) histoire de les découvrir, et de s’y repérer (un grand nombre de salles tout de même, sur 2 bâtiments traversés par une Howard Street et 3 niveaux). Une ambiance “fun” à l’américaine, d’innombrables stations en libre services, du merchandising, un programme riche, bref, un avant-goût de ce qui ressemble bien à un petit paradis pour développeur Java. …


Understanding recruiters habits

Image for post
Image for post
The more candidates get solicited, the more they get cocky.

Two decades ago, recruitment was really an expert job. It required significant searching and identification skills, and only few people were able to do it. Actually candidates were so seldom contacted that they were happy to receive a call.

Then came the “Internet bubble” with everybody looking for tech talents, and LinkedIn was born*. With such a tool and a steady demand for tech profiles, a lot of people decided to jump in the recruiting bandwagon, for better or for worse.

Since then, strange recruiters’ habits have emerged. After years of seeing them, I decided to asked the primary source.

First contact

Depending on how you get in touch with recruiters, their behaviors will seem more or less…


Set them free, always

A hand handing off keys to another hand
A hand handing off keys to another hand
Never keeps the keys of a resource

Resources (connections, files, memory) are typically non-shared objects. Two clients cannot write in the same file or memory area at the same time or perform concurrent transactions on the same connection. This is a matter of consistency, as concurrent writes may result in lost updates, and even concurrent write vs read could lead to a loss of isolation. In all cases, you would loose atomicity as well.

To avoid those problems resources are typically acquired (more or less exclusively depending on your read or write intent), then released: you extract a connection from a pool, you lock a file for writing, you allocate memory, and so on. …


Probably the best principle to follow in software engineering, and in life in general.

Image for post
Image for post

John is your unicorn employee. He is as good at developing software as he is at selling it. So he’s responsible for both. One may find this organization simpler than having multiple people to manage, but changes can have a detrimental impact to John’s activities:

  • If you assign a new task (sales or development) to John, you need to make sure that it doesn’t interfere with his other planned tasks. Does he have a proper time slot to do it? Could he confuse a API contract with a sales contract? …


Should it be global or local?

Image for post
Image for post
Each of those 25 microns-wide facets (ommatidium) of a noctuid moth’s eye is pretty simple, but their composition performs a very complex vision feature [Dartmouth Electron Microscope Facility/Dartmouth College]

There is no such thing as universal characteristics for simplicity: some think this is related to size (the number of code lines — but you can write too complex things on a few lines — or the number of concepts involved — but reducing that number mechanically increases the complexity of the remaining concepts) while others believe it is related to the nature of concepts themselves (privileging a programming paradigm over another).

Actually simplicity is relative to both the task to do and the people who does it. As software development is most often a team effort however, it is important to grasp what are the most shareable traits of simplicity in software development. …


Appearances can be deceptive

The “Unix” 3D file system featured in Jurassik Park (1993) dumfounded many developers as a beautiful but impracticable one.
The “Unix” 3D file system featured in Jurassik Park (1993) dumfounded many developers as a beautiful but impracticable one.
The “Unix” 3D file system featured in Jurassik Park (1993) dumfounded many developers as a beautiful but impracticable one. It was a real (demo) SGI software though, known as FSN or “Fusion”.

Some years ago I stepped in my manager’s office to tell him I decided to leave the company to do frontend development: I lacked real experience in that field and I wanted to be better at it. He replied to me that frontend development was not “real development” and that comforted me in my decision: frontend deserved to be better known.

It is not about aesthetics

If you’re building UI/UX based on what is considered “beautiful” or not, you’re in trouble. Someone will “like” it, someone else will not, and you might never be able to understand why, because all these terms are subjective. …


When third-party should be a second choice?

A pile of big “modern” dependencies depend itself on a small module written years ago by random person.
A pile of big “modern” dependencies depend itself on a small module written years ago by random person.
Beware of the dependencies of your dependencies (XKCD drawing).

More and more reusable packages are emphasizing that they are “lightweight”, often because they don’t embed other reusable packages.

This seems paradoxical, as promoting reusability (“use my package”) and refusing to apply it (“I don’t use other packages”) at the same time. So is it some sort of “Not Invented Here” (NIH) syndrome or just a more rational, sparse choice of dependencies?

When to use them

There are several reasons to use third-party software:

  • lack of competency: you don’t know how to do it ;
  • lack of resources: you don’t have the time or the workforce to do it ;
  • reusability common sense: somebody seems to have the solution to your problem, so why not using it? This will save you time (which is critical in professional environments) and will probably warrant some good quality provided it has already been tested by many users. …

Ambiguity is a complexity

Two direction panels: one saying “Optional”, pointing left, the other saying “Mandatory”, pointing right.
Two direction panels: one saying “Optional”, pointing left, the other saying “Mandatory”, pointing right.
Do the right thing.

Suppose you are signing a contract with optional clauses. Would you care about them? Most of us would probably even bother reading them.

A contract is meant to enforce, to provide a guarantee. So by definition anything that is optional in it is irrelevant, and should just not be part of it.

Software programming is about writing contracts between clients calling code with required inputs and resulting service and output. Anything that is optional in those makes things fuzzy, complex to understand and to test.

Unspoken magic values

Actually optionality is about assigning values by default, when no explicit ones are provided. That way, it can be viewed as prototyping: you implicitly create the required set of values from a default one, and explicitly override some of the properties. …

About

Jérôme Beau

Software engineer for three decades, I would like to share my memory. Also author of https://rr0.medium.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store