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.
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 container, or the viewport if at root level) but its height is still governed by its contents. …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. …
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). …
Article initialement posté le 13 mai 2008
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. …
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.
Depending on how you get in touch with recruiters, their behaviors will seem more or less…
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. …
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:
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. …
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.
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. …
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?
There are several reasons to use third-party software:
About