Dans cette rubrique je présente 3 mots que j’aime ou déteste, que je prononce trop ou que je viens d’apprendre.
Dans cette rubrique je présente 3 mots que j’aime ou déteste, que je prononce trop ou que je viens d’apprendre. Mes 3 mots du moments concernent la conception et l’architecture logicielle. Je les utilise en programmation à deux, en séance d’architecture, avant d’entamer une fonction ou durant la mêlée quotidienne.
Souvent utilisé avec “Niveau”.
Péjoratif : “On a trop de niveaux d’indirection. Il y a trop de couches entre l’API et son implémentation. Il faut simplifier.”
Positif : “Grâce à cette façade on expose pas directement l’implémentation, on fait une indirection qui nous laisse de la souplesse.”
Dans la même veine. Un bon moyen d’ajouter une indirection.
Surtout en Objective-C, l’héritage est vraiment une solution inconfortable. Alors on use et abuse des délégués. C’est un super moyen de passer les responsabilité aux bons objets. C’est aussi une alternative aux notifications globales. Parfois seul un délégué doit être prévenu, pas besoin de diffuser un message à tous les potentiels classes intéressées.
Toujours en Objective-C, un bon moyen de ranger le code, faciliter la maintenance et pratiquer le TDD c’est d’utiliser des Category. On amende la classe pour ajouter les méthodes sur un sujet précis (aspect présentation, persistance, etc…)
Autre contexte : dans notre pratique de SCRUM, lorsqu’un bug est trouvé sur une tâche on amende le post-it pour signaler un problème (en gros on ajouter un autre post-it qui explique le bug)
If your app is for a team of users, don’t focus on the app nor the users. Focus on not impeding their interactions. Don’t forget they can talk to each other and think on their own without your app !
If your app is for a team of users, don’t focus on the app nor the user. Focus on not impeding their interactions. Don’t forget they don’t need your app to talk together. They are already doing it. Worst : don’t try to replace live interaction with electronic processes. It’s best for them and cheaper for you.
It was a shiny day of July, the meeting was 3 hours long. The goal ? Prioritizing, specifying and poker planning the next sprint. We made the mistake of scheduling it right after a 8 hour meeting with our key users (sort of day-long presentation/feedback of our latest monthly release). Now we were embarking on the next sprint. We were exhausted and really focused on details.
Examining story after story, we were fighting to make them all fit in the sprint. First mistake.
Second mistake : focusing too much on each story at a time. Loosing the big picture.
The third mistake needs a little back story.
Our application’s goal is to help people who already work closely together to do so with a tablet. They already talk to each other, they are trained to work together. They work this way since 1933 at least.
The user stories were about helping the team leader to distribute roles in his crew. Simple in appearance…
It’s was a nightmare of story dependencies, complex vague specifications, really expensive features.
Why ? We forgot the people the leader has to manage are physically in the room during the use of the feature. Hence all controls, feedback, error-prone specifications we were trying to establish were useless.
Simply by TALKING to each other, the users could work together. We forgot that since the begging. Focusing more and more on the new tool we were building, we forgot the primary human tool : talking.
We saved our velocity and the project budget. But the danger is still around. Don’t forget the most basic human skills instead of trying to replace them all in one app.
If you can’t put a name on it, you don’t know what it is. An English dictionary is your best programming friend.
If you can’t put a name on it, you don’t know what it is
Peer programming with a lead developer on an important iOS project, I discovered a plain English dictionary or a thesaurus is my best friend.
You need it to name your objects, variables, classes, services, folders, …
It’s the best way to see if you understand what you do. Concepts you will implement must have their own special vocabulary.
For example, we were looking at a name for a model object. The object had to be a pre-filling container to build a more complete report. It had to be displayed on an UI to be filled, and to be opened and transferred via an URL. So it was used both as front and backend representation.
Well, we searched a name for 2 hours.
The reason it was so difficult was that :
the concept was too close from another object, but different
the concept was vague
the concept had too many faces or too many responsibilities
We tried :
ReportExcerpt (hard to pronounce for French speakers)
We finally settled for : ReportSkeleton.
Thank you Mac OS Dictionary App 😀 (by the way it’s waaaay faster than the Internet, try it)
And it’s even more important if your are not a native english speaker. Don’t use a translator from your language to English. Search an English dictionary. You’ll win one level of vagueness and indirection of your idea.
Naver is the most used search service in Korea. Some Koreans even have a viceral repulsion for the way Google looks and works.
Naver is the most used search service in Korea. Some Koreans even have a viceral repulsion for the way Google looks and works. Here is a small comparison. [Big Thanks to my friend Dayo for making me write this small piece]
This comparison, I hope, will help answer those 3 questions and explain why Naver is beating Google in Korea :
Why is Naver so used in Korea ?
Why is Google not used in Korea ?
Why is Naver not used outside Korea ?
Naver Most Used Features (All on the same page)
Blog and blog search
Image search (better than Google’s in the User experience, not the accuracy in my opinion)
Crowd generated content
Content is mostly generated by users blogging. Koreans blog about anything. I’m amazed to see my wife looking for a restaurant in Paris, on a Naver Korean Blog ! But she is right. You have more chance to find pictures (a lot, and it matters) on a Korean blog more than in the local Google search (maybe because France is not well served on the subject)
The pitfall is that sometimes, like with Wikipedia, the content lakes objectivity. My wife experience confronting someones error on his blog. When told the owner of the blog argued that he was right because all other Naver bloggers put the same piece of information. But they were all wrong (about a movie filming location in Italy). Even the official-looking Naver equivalent of IMDB was re-using bloggers wrong information. Very dangerous in my opinion.
As you may know, Hangul is 20% more compact than latin Alphabet. Hence the amount of information that can fit on a page is higher. And because they can, they do. My wife like other Koreans prefers scrolling through a long page with a lot of info instead of having to click deeper.
For some Korean people I know : “Google is ugly and messy”, and “Naver is ordered and easy to read”
Naver is only in Korean as far as I know.
Technical / Performance
As a developer : this is kind of a mystery : the Naver site, like so many Korean websites, have to be IE6 compatible (because of a custom government certificate problem). Hence it is terribly inefficient Yet the speed of the broadband connection is so high that most Korean don’t realize. But as soon as you look at the way pages are built, you discover how much bandwidth is needed every time the page reloads. Horrifying !
On TV, no brand is putting it’s web address on screen, instead a Naver Box appears and the brand name is filled in. This is a powerful model I think. Both part are winning. Don’t know the detail of the deal between the brand and Naver.
Koreans are used to it. Hard to change for a “new” player like Google. I believe Naver was first there.
Everybody uses it. Following the trend is also a habit in Korea.
Naver is made in Korea.
And you my Korean friends ? Why do you like Naver so much ?
Some big companies have centralized development R&D. But sometimes, it’s simply not working.
Some big companies have centralized development R&D. But sometimes, it’s simply not working.
Start making developers better at choosing instead of choosing for them
Don’t misunderstand me (especialy you my dear colleagues who read this) : we need some kind of normalization in a company with a lot of different quality level developers. But if you focus on technological solutions you’ll risk to miss the point and make yourself useless. Especially on tight budget.
Do Less :
Trying to produce One-Size-Fits-All-In-One-Inegrated-Frameworks
Hiring intrusive consultants for a short term study
Producing Out-of-the-real-world POCs (Proofs of Concepts)
Listening to all exterior vendors that claim to have the best One-Tool-To-Rule-Them-All
Instead Start :
Gathering common needs from different projects already in production or in the making
Emulate innovation by offering a kind of Entreprise Github
Best : go open source and participate to the real world solutions
Organize as many education events as possible. It’s harder but cheaper than buying soon deprecated solutions.
Create an internal StackOverflow to promote help between product departments that never speak together.
Promote User Groups for both external (open source) tools and internals
Look for the best practice, not the average one. For example promote and teach TDD and Continuous Integration.
What matters is not an all in one solution that will deprecate in 2 years, what matters is making the other average developers of your company better.
It’s about education, not technology. It’s not about methodologies, it’s about state of mind.