Even developers can’t understand it
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:
blockdefines a box whose space (size and position) can be controlled. By default, it allocates all the available width (the width of its container, or the viewport if at root level) but its height is still governed by its contents. …
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
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. …
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
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
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.
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?
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
Some years ago I stepped in my manager’s office to tell him that 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?
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. …
About
