Hubesco's Blog

Inside a software engineer mind

Update Linux Kernel on OVH VPS SSD

Rédigé par Pao 1 commentaire

It's been a while since I wanted to upgrade my linux kernel on my OVH VPS SSD. But for some reason I couldn't manage to do it. I was stuck understanding why I couldn't figure it out while I have been able to do so for other servers and Linux distribs. 

Here what I found after two evenings and a backup (using OVH snapshot option). Never forget to backup before messing with configuration.


  • Provider : OVH
  • Server : VPS SSD 2016
  • OS : Debian 9 Stretch
  • Bootloader : extlinux (<= this is where I struggled)
  • Current Linux kernel : linux-image-3.16.0-4-amd64
  • Wanna be Linux kernel : linux-image-4.9.0-8-amd64

Step 1 - Install the new Linux kernel

Find the Linux kernel to install :

apt-cache search linux-image
linux-image-amd64 - Linux pour les ordinateurs 64 bits (métapaquet)
linux-image-rt-amd64 - Linux pour les ordinateurs 64 bits (métapaquet) avec PREEMPT_RT
linux-headers-4.9.0-8-amd64 - Header files for Linux 4.9.0-8-amd64
linux-headers-4.9.0-8-rt-amd64 - Header files for Linux 4.9.0-8-rt-amd64
linux-image-4.9.0-8-amd64 - Linux 4.9 for 64-bit PCs
linux-image-4.9.0-8-amd64-dbg - Debug symbols for linux-image-4.9.0-8-amd64
linux-image-4.9.0-8-rt-amd64 - Linux 4.9 for 64-bit PCs, PREEMPT_RT
... // more here 

Install the kernel

apt-get install linux-image-4.9.0-8-amd64


Step 2 - Update the bootlader

This is where I struggled. All the posts I found on Internet mention GRUB or syslinux. But nothing on extlinux even on the official Debian wiki.
Until when I found that extlinux is a variant of syslinux and OVH uses extlinux.

So I proceed to update the configuration as mentionned in the official extlinux wiki with :

extlinux --install /boot

But still no luck until then I found this serverfault answer that says :

I had the same issue, also on OVH after the last update. After looking in the boot folder, I had two different versions: vmlinuz-3.16.0-4-amd64 & vmlinuz-3.16.0-5-amd64 I changed in both extlinux.conf files the version and it worked.

Ah ! So I searched for this second config file :

locate extlinux.conf

Here you are !!! 
All what remains is then to update both files, reboot the server and TADA ! I have my new linux kernel.

Happy Ending <3

Google Design Sprint revisited

Rédigé par Pao 2 commentaires

This blog post is part of the "Revisited" series.

I just finished the book Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days - Jake Knapp, John Zeratsky, Braden Kowitz. It describes the Google Design Sprint and how to run one.

The Design Sprint

The sprint gives teams a shortcut to learning without building and launching.


The sprint is a five-day process for answering critical business questions through design, prototyping, and testing ideas with customers. Developed at GV, it’s a “greatest hits” of business strategy, innovation, behavior science, design thinking, and more—packaged into a battle-tested process that any team can use.

Working together in a sprint, you can shortcut the endless-debate cycle and compress months of time into a single week. Instead of waiting to launch a minimal product to understand if an idea is any good, you’ll get clear data from a realistic prototype. The sprint gives you a superpower: You can fast-forward into the future to see your finished product and customer reactions, before making any expensive commitments.

This page is a DIY guide for running your own sprint.


Overview of the process

On Monday, you’ll map out the problem and pick an important place to focus.

On Tuesday, you’ll sketch competing solutions on paper.

On Wednesday, you’ll make difficult decisions and turn your ideas into a testable hypothesis.

On Thursday, you’ll hammer out a high-fidelity prototype.

And on Friday, you’ll test it with real live humans.

Full process can be found here.



Be prepared 

"Michael Margolis and Alex Ingram had interviewed staff at cancer clinics, and with help from Amy, they told us how trial enrollment worked" - page 62


The bigger the challenge, the better the sprint - page 26

"Here are three challenging situations where sprints can help :

  • High Stakes (before committing to any big changes and projects, the sprint will help to find the right direction),
  • Not Enough Time (there is a deadline and the project requires good solutions fast),
  • Just Plain Stuck (important projects are hard to start and a fresh approach to problem solving can help to find a way to start)."


The Decider must be involved in the sprint and below are some argument if the Decider is reluctant to spend 5 full days - page 31

  • Rapid Progress, emphasize the amount of progress you'll make in your sprint: in just one week, you'll have a realistic prototype. Some Deciders are not excited about customer tests.
  • It's an Experiment, consider your first sprint an experiment. When it's over, the Decider can help evaluate how effective it was.
  • Explain the Tradeoffs, show the Decider a list of big meetings and work items you and your team will muss during the spring week. Tell her which items you will skip and which you will postpone, and why.
  • It's About Focus, be honest about your motivations. If the quality of your work is suffering because your team's regular work schedule is too scattered, say so. Tell the Decider that instead of doing an okay job on everything, you'll do an excellent jon on one thing.


Recruit a team of seven (or fewer) - page 34

Who What Examples
Decider Who makes decisions for your team ? CEO, founder, product manager, head of design
Finance expert Who can explain where the money comes from and where it goes ? CEO, CFO, business development manager
Marketing expert Who crafts your company's messages ? CMO, marketer, PR, community manager
Customer expert Who regularly talks to your customers one-on-one ? Researcher, sales, customer support
Tech/logistics expert Who best understands what your company can build and deliver ? CTO, engineer
Design expert Who designs the products your company makes ? Designer, product manager


Nobody knows everything (Ask the experts) - page 70

"Instead, the information is distributed asymmetrically across the team and across the company. In the sprint, you've got to gather it and make sense of it, and asking the experts is the best and fastest way to do that"

  • Strategy : start by talking to the Decider
  • Voice of the Customer : who talks yo your customers more than anyone else? Who can explain the world from their perspective?
  • How Things Work : Who understands the mechanics of your product?
  • Previous Efforts : Often, someone on the team has already thought about the problem in detail. That person might have an idea about the solution, a failed experiment, or maybe even some work in progress.


Find Customers for Friday - page 119

"Recruit customers with Craiglist [...] The secret is to post a generic ad that will attract a broad audience, then link to a screener survey to narrow down to your target customers [...] We offer a small stipend or token of appreciation - usually a $100 gift card [...]".


Make honest decisions - page 139

"Sometimes when people work together in groups, they start to worry about consensus and try to make decisions that everybody will approve."

"During the sprint, Oscar had succumbed to camaraderie. He wanted to let the team make the decision. But the idea the team chose wasn't the idea Oscar was most excited about. Later, after the prototyping and testing were over, he reverted to his normal method of decision-making [...]."


Fake it - page 168

"But perhaps the biggest problem is that the longer you spend working on something - whether it's a prototype or a real product - the more attached you'll become, and the less likely you'll be to take negative test results to heart. After one day, you're receptive to feedback. After three months, you're committed".


Pick the right tools (Prototype) - page 186

  • If it's on a screen, use Keynote, PowerPoint, or a website-building tool like Squarespace.
  • If it's on paper, use Keynote, PowerPoint, or word processing software like Microsoft Word.
  • If it's a service, write a script and use your sprint team as actors.
  • If it's a physical space, modify an existing space.
  • If it's an object, modify an existing object, 3D print a prototype, or prototype the marketing using Keynote or PowerPoint and photos or renderings of the object.


Small Data (Interview, Friday) - page 195

"Newton didn't read the sample pages that evening. Instead, he handed them over to his eight-year-old daughter, Alice. Alice read them. About an hour later, she returned from her room, her face glowing with excitement [...]".

"Alice didn't analyze Harry Potter's potential. She didn't think about cover art, distribution, movie rights, or a theme park. She just reacted to what she read. Those grown-ups tried to predict what children would think, and they were wrong. Alice got it right because she actually was a kid. And her father was smart enough to listen."


The Five-Act Interview - page 202

  • A friendly welcome to start the interview
  • A series of general, open-ended context questions about the customer
  • Introduction to the prototype(s)
  • Detailed tasks to get the customer reacting to the prototype
  • A quick debrief to capture the customer's overarching thoughts and impressions


Checklists - page 232

"In the following pages, you'll find checklists for every part of your sprint. (You can also find these lists at"




Classé dans : book Mots clés : aucun

Clean Code revisited

Rédigé par Pao 1 commentaire

Another blog post on the "Revisited" series.

This time it's Clean Code written by Robert C. Martin. I highly recommend this book because as an experienced programmer, it describes exactly what I have in mind when I write software or when I read code. Martin expresses clearly what I generally admit and sometimes difficult to explain what is clean code (interestingly, I wrote "good code" as a first intention. But here we talk about clean code. Craftsmanship. Not just "good enough"). He gives a lot of arguments for each of his points.
There is also a comprehensive list of what the author thinks what bad code is ("smells"). These "smells" are the same thing as code rule checkers (PMD, Checkstyle, Findbugs, ...) that are run automatically within a continuous integration system.

You will find a word on the author, a synopsis of the book and the tips that are the most important to me.


About the Author

Robert Cecil Martin (colloquially known as Uncle Bob) is an American software engineer and author. He is a co-author of the Agile Manifesto. He now runs a consulting firm called Uncle Bob Consulting LLC and Clean Coders which hosts videos based on his experiences and books.




Even bad code can function. But if code isn’t clean, it can bring a development organization to its knees. Every year, countless hours and significant resources are lost because of poorly written code. But it doesn’t have to be that way. Noted software expert Robert C. Martin presents a revolutionary paradigm with Clean Code: A Handbook of Agile Software Craftsmanship . Martin has teamed up with his colleagues from Object Mentor to distill their best agile practice of cleaning code “on the fly” into a book that will instill within you the values of a software craftsman and make you a better programmer—but only if you work at it. What kind of work will you be doing? You’ll be reading code—lots of code. And you will be challenged to think about what’s right about that code, and what’s wrong with it. More importantly, you will be challenged to reassess your professional values and your commitment to your craft. Clean Code is divided into three parts. The first describes the principles, patterns, and practices of writing clean code. The second part consists of several case studies of increasing complexity. Each case study is an exercise in cleaning up code—of transforming a code base that has some problems into one that is sound and efficient. The third part is the payoff: a single chapter containing a list of heuristics and “smells” gathered while creating the case studies. The result is a knowledge base that describes the way we think when we write, read, and clean code. Readers will come away from this book understanding How to tell the difference between good and bad code How to write good code and how to transform bad code into good code How to create good names, good functions, good objects, and good classes How to format code for maximum readability How to implement complete error handling without obscuring code logic How to unit test and practice test-driven development This book is a must for any developer, software engineer, project manager, team lead, or systems analyst with an interest in producing better code.

Amazon UK



Data Abstraction and Objects 1 (Objects and Data Structures)

"The beautiful thing about [...] is that there is no way you can tell wether the implementation is in rectangular or polar coordinates."
"There is a reason that we keep our variables private. We don't want anyone else to depend on them. We want to keep the freedom to change their type or implementation on a whim or an impulse."
"Hiding implementation is not just a matter of putting a leayer of functions between the variables. Hiding implementation is about abstractions! [...] Rather it exposes abstract interfaces that allow its users to manipulate the *essence* of the data, without having to know its implementation."

Data Abstraction and Objects 2 (Objects and Data Structures)

"Objects expose behavior and hide data. This makes it easy to add new kinds of objects without changing existing behaviors."
"Data structures expose data and have no significant behavior."

Use Unchecked Exceptions

"The debate is over."
"However, it is clear now that [unchecked exceptions] aren't necessary for the production of robust software."
C#, C++. Python, Ruby don't have checked exceptions and yet it is possible to write robust software in all of these languages.
"The price of checked exceptions is an Open/Closed Principle violation."

Don't Return Null (Error Handling)

"When we return null, we are essentially creating work for ourselves and foisting problems upon our callers. All it takes is one missing null check to send an application spinning out of control."

Don't Pass Null (Error Handling)

"In most programming languages there is no good way to deal with a *null* that is passed by a caller accidentally. Because this is the case, the rational approach is to forbid passing *null* by default. When you do, you can code with the knowledge that a *null* in an argument list is an indication of a problem, and end up with far fewer careless mistakes."

"Clean code is readble, but it must also be robust" (Error Handling)

Exploring and Learning Boundaries (Boundaries)

"Third-party code helps us get more functionality delivered in less time."
"Learning the third-party code is hard. Integrating the third-party code is hard too,. Doing both at the same time is doubly hard. What if we took a different approach? Instead of experimenting and trying out the new stuff in our production code, we could write some tests to explore our understanding of the third-party code. Jim Newkirk calls such tests *learning tests*."

Keeping Tests Clean (Unit Tests)

"From release to release, the cost of maintaining my team's test suite rose. Eventually, it became the single biggest complaint among the developers. When managers asked why their estimaes were getting so large, the developers blamed the tests. In the end they were forced to discard the test suite entirely."
"But, without a test suite, they lost the ability to make sure that changes to their code worked as expected."
"Test code is just as important as production code."

Clean tests follow F.I.R.S.T. (Unit Tests)

  • Fast: Tests should be fast.
  • Independent: Tests should not depend on each other.
  • Repeatable: Tests should be repeatable in any environment.
  • Self-Validating: The tests shoukd have a boolean output.
  • Timely: The tests need to be written in a timely fashion.

Clean Systems (Systems)

​"An optimal system architecture consists of modularized domains of concern, each of which is implemented with Plan Old Java (or other) Objects. The different domains are integrated together with minimally invasive Aspects or Aspects-like tools. This architecture can be test-driven, just like the code."

Optmize Decision Making (Systems)

"We often forget that it is also best to postpone decisions until the last possible moment. This isn't lazy or irresponsible; it lets us make informed choices with the best possible information. A premature decision is a decision made with suboptimal knowledge."

Systems Need Domain-Specific Languages (Systems)

"Building construction, like most domains, has developed a rich language with a vocabulary, idioms, and patterns that convey essentiel information clearly and concisely. In software, There has been renew interest recently in creating Domain-Specific Languages (DSLs), which are separate, small scripting languages or APIs in standard languages that permi code to be written so that it reads like a structured form of prose that a domain expert might write."

Getting Clean via Emergent Design (Emergence)

"What if there were four simple rules that you could follow that would help you create good designs as your worked?"

  • Runs all the tests
  • Contains no duplication
  • Expresses the intent of the programmer
  • Minimizes the number of classes and methods

The rules are given in order of importance.

Myths and Misconceptions (Concurrency)


  • "Concurrency always improves performance."
  • "Design does not change when writing concurrent programs."
  • "Understanding concurrency issues is not important when working with a container such as a Web or EJB container."

And so:

  • Concurrency incurs some overhead
  • Correct concurrency is complex
  • Concurrency bugs aren't usually repeatable
  • Concurrent often requires a funddamental change in design strategy

Concurrency Defense Principles (Concurrency)

  • Single Responsibility Principle
  • Limit the Scope of Data
  • Use Copies of Data
  • Threads Should Be as Independent as Possible

History of JUnit (JUnit Internals)

"JUnit has had many authors, but it began with Kent Beck and Eric Gamma together on a plane to Atlanta. Kent wanted to learn Java, and Eric wanted to learn about Kent's Smalltalk testing framework. "What could be more natural to a couple of geeks in cramped quarters than to pull out our laptops and start coding?" After three hours of high-altitude work, they had written the basics of JUnit."


Classé dans : book Mots clés : aucun
Fil RSS des articles