Where are you talking from?

A tiger labelled “danger zebra”
A tiger labelled “danger zebra”
This is what happens when you replace abstractions with descriptions. But you must make sure that “Snow tiger” is well defined in you project’s dictionary.

Naming is one of the most important aspects of programming. It is also one of the most overseen aspect of it (i.e. “let’s make it work with a ‘x’ variable, we’ll choose a better name later”). Maybe this is because there is a distorted conception of programming.

What is programming?

A common definition of programming is speaking to the machine. This is misleading for a couple of reasons.

Unless you’re writing machine code alone, the recipients of your code are:

  • a compiler that will translate your instructions into lower-level code. The aim of compilation here is to provide you some abstraction through a…


You don’t want to do that

I should make clear that I made all those mistakes myself at least once, and still do a few of them every once in a while. Not because I am a developer, but because I am human: nobody likes to do some tedious things, nobody likes problems to fix, nobody wants to handle others’ problems, everybody… is lazy when it comes to this kind of tasks. But, on the long run, not handling them will worsen the situation.

Here is a list of things we should try to avoid, as good developers.

Copy & Paste

Yeah, your work would be hard without cut…


Even developers can’t understand it

This is a too common pattern among developers. Why is that?

A few months ago I wrote an article mentioning the sad rejection of CSS by developers. There are several reasons for that, such as the difficulty to find good tutorials for beginners, but let’s face it: the primary reason for all that is the difficulty to understand the language itself.

Let’s look at the major blockers and how we could fix them.

Containers and contents

Let’s start by one of the most common source of confusions: the display property:

  • block defines a box whose space (size and position) can be controlled. By default, it allocates all the available width (the width of its…


A few years ago, I started prototyping UFO@home, a visual testimony tool inspired by works of Roger Shepard, Richard Haines and motivated by Pierre Lagrange with the aim of improving UFO reporting. As I explained in another post, the benefit of such a tool was also, to me, to allow simulating known phenomena hypothesis (astronomical, balloons, meteors, planes, birds…) in order to validate or exclude them, along with agreement of the witness. Once the prototype done, I needed to produce the most realistic sky rendering as possible. This required re-writing (then, later, extend with ufology features) the state-of-the-art planetarium software, known as Stellarium. Then Stellarium for Java (S4J) was born.

This post was initially written in french, on February 16th, 2008

This is done now as a first version is available through the Java Web Start system (to install before, which allows to start a Java application that can be downloaded from the Internet) on SourceForge or Java.net. This version is not a final one yet nor without any bugs, but it is usable at least.

Stellarium for Java, windowed on MacOS

Furthermore, it has been selected for the JavaOne event, where I will showcase it next May with my co-developer.


At JavaOne, all sessions were subject to evaluations by the audience. Java Cards hanging on the neck of every people entering the conference room implicitly identified and counted them, while staff members at the entrance were giving evaluation forms to be fillled. The goal: evaluate our presentation, us as speakers, the quality of our slides, of the demos, etc. So how did it went for S4J?

This post was initially written in french, on June 6th 2008

I just received the evaluations results, and it is quite satisfying: among the 117 people who attended the S4J session, 57 agreed to evaluate it, as among the first best quarter of JavaOne sessions (4,35–4,95) with a global score of 4,39 out of 5. This evaluation is also above the average for this kind of session (4,13 for technical sessions). …


Back from San Francisco where I was invited to the JavaOne 2008 event, I am still suffering a bit from the jet lag (8 hours is a thing). While being already a fun time for any Java developers (dozens of sessions about a wire range of topics, from detection chip to 3D on mobile phones, including Mars cartography, but also products of course — WorldWind, GlassFish, OpenSolaris… — APIs — OSGi, WebBeans, DarkStar, etc. —and other more general sessions), this was a much more important event to me, as I was expected to showcase Stellarium for Java with my co-developer, Frederic Simon. The result have been beyond all of our expectations. But, speaking of it, how does a “speaker” week look like at JavaOne?

This post was initially written in french, on May 13th 2008

Sunday

12:30 AM (local time): After 10 long hours of flight, the place is about to land on a foggy San Francisco but the airport rejects landing: too much traffic, too low visibility. We are redirected toward Oakland, where we refill before arriving to our destination, finally. At the customs, I stand behind 3 young french guys who come to attend the event. There seem to be many of others. A jump at the hotel, and I struggle to keep my eyes open to quickly register at the Moscone Center


Understanding recruiters habits

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


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…


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

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?

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…

Jérôme Beau

Software engineer for three decades, I would like to share my memory. https://javarome.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