I am Nguele

My name is Jean-Dominique Nguele and this is my blog. FLVCTVAT NEC MERGITVR

Tag Archives: collaboration

Mister Ozymandie: A song of dice and dire

Reading Time: 2 minutes

Tick, tick, tick look at me it’s Mister Ozymandie,
Once more bringing, no, inflicting my opinion upon thee.
Whatever the effort, the time you put in your source,
My remarks, of your good day will disrupt the course.

No matter how close you were to a merge
It is time for me to compare with yours my verge.
I am the biggest, the best, better than the rest
The victim you will be of my self-esteem quest.

Whether right or wrong my assurance won’t fail
Poker facing you, hoping your knowledge frail.
Always trumping around like there is no tomorrow
Still making up shit when my mastery is shallow.

Even if you manage to see through my gambling
All day, every day, I will keep them dices rolling.
Although you call it perversion, it is my perfection
I know you see me as a pain, worse, a diversion.

It doesn’t matter what you think, it is my ship,
None shall questions my conduct, like dictatorship.
Become one for all, always know that all is for me,
Your personal judgement here has no place to be.

Line after line, block after block, thought after thought,
I shall erase your experience, everything you brought.
Indeed, I will not stop until all aspects of my glorious vision,
Sink deep in your mind, make the past you aversion.

For that I am the star on the hailed Christmas tree,
For that others forced the same behaviour on me.
Even though this might be to your growth toxic,
Above all, my ego, my satisfaction is what I pick.

Even if you’re right and I am turning value to churn
And someday for my crimes one makes me burn.
I just want one thing, that you dance on my symphony
Myself throning in development pantheons for eternity.

Because it’s me Mister Ozymandie. All! Look at me!
On the humanity commit history, my mark will be.

Thanks for reading, hope you enjoyed reading it as much as I enjoyed writing. I guess that now writing poems on that blog is a thing now. If you haven’t read the previous one you can check it out clicking here.

HttpResponseSimulator: A simple tool born over an afternoon

Reading Time: 2 minutes

What is the HttpResponseSimulator? Apart from being the least original name. Well, it is tool that allows simulating the behaviour you want from an endpoint to test an http client and/or wrapper. I built it over an afternoon so that I could write a timeout test for an http client wrapper. I had to get familiar with Node.js and Express again, which I previously used to create HappyPostman. Despite the slow start, it took me about a couple of hours to implement and deploy.

Like every small projects written with a simplistic goal the first version was not great. If you follow that link you will notice a lot of coupling and no tests whatsoever. The first couple of commits are still good enough to deploy and serve the HttpResponseSimulator original purpose. However, I wanted to push it further and live up to my whole being “future-proof” thing and make it robust. To make it robust I need it to be testable and cover as much logic as possible. This is where I started googling to figure how I to write tests and get coverage feedback with Node.js.

Due to the high coupling of my code my only option was to write http assertions related tests. The kind of tests where I hit the endpoints directly and validate the output based on the given input. In order to write these tests, I had two options that would later allow me to refactor that code to clean it up. The easy option was to follow my own tutorial on Postman and remain in a known territory.

However, I chose to try something new and stumbled into supertest that can implemented in tests that can be ran using Mocha. It seemed like the best option since I can write all my other tests post-decoupling using that Mocha too. Also, Mocha can be used along tools like Istanbul to generate coverage metrics that can be uploaded to coveralls. In that case, my choices were all driven by what I wanted to achieve which is very important in software development. Eventually after a few days of test writing and refactoring, I was finally happy with myself you can see the test coverage result below:

HttpResponseSimulator coverage results

Now that it is robust, I feel like it is time to share it with the world. It is time to make it open-source, it may just die out in a few months or grow and become something bigger. It currently serves a few more purposes than just waiting a few seconds before responding. You can now get your response from any freely available url or pastebin id among other things. If you have any improvement suggestions feel free to hit me up through Github. Actually while you’re at it, if you have any coding notion and want to try your hand at open-source development you can fork the project and open pull requests to improve it. Also, if you have a better name than HttpResponseSimulator you can google around to hit me up.



Trying to provide helpful pull request reviews

Reading Time: 3 minutes

How I unblocked a frozen pull request

A few weeks ago, I saw a pull request to modify one of our webjobs which codebase is pretty old and had no tests. The pull request had no tests either. The thing is that we decided to make unit testing mandatory for any pull requests a couple weeks before.

I started reviewing the code when I noticed someone else already posted a review. A pretty laconic “please add tests”. Not a bad nor a mean review but not a really helpful one. Proof of it is that it was posted about an hour before and the pull request was blocked. Indeed we do not untested logic to enter or remain in our software. Yes it is aligned with our new policy about tests. That being said, the webjob code was tightly coupled and pretty impossible to test as it was.

This is where I stepped in, I reviewed the code and found a way to make it testable. I then suggested a few minor changes in the existing codebase to make it testable. Within thirty minutes he modified the code and was pretty happy to have tests for the logic he improved. Eventually, I went on and approved his pull request then the first reviewer followed up.

What went wrong with the first review

Please add tests

In most cases “please add tests” is enough to do the trick. The code is designed properly and decoupling is applied wherever possible. “Please add tests” is enough if the tests were not written because of laziness or just got forgotten. However, in this particular case, the reviewer did not take in consideration the context of the change. Indeed, it was an update to an old project designed at a time where the backend team was a couple of guys trying to launch a company. Delivering the software was prioritised over making it easily maintainable. In order to allow a business to take off, testing and decoupling was left for another day. Taking these factors in consideration I have been able to come up with a few strategic changes that eventually allowed to add some tests.

You may have noticed the two different approaches and their effect here. On one hand, turning a change of context into a problem, on the other hand, suggesting a solution. The first one had the pull request frozen for an hour where the latter allowed the pull request to move forward and the code to be merged. As software engineers we need to help others moving forward and propose solutions not problems. Solving problems is central to what we do, whether it is designing a seamless checkout or helping a colleague to make progress on a project.

Become an enabler

We all have been that first reviewer at a moment or another, and if you currently recognized yourself there here are a few tips for you:

Leave your ego out

If you comment on a pull request because it will make you feel superior to the submitter by showing how big is your knowledge relative to theirs or how you are the best developer there is, don’t. Just don’t. Especially if it does not bring any value to what he is trying to accomplish through the pull request. Always leave your ego out of anything if you want to be productive.

Ask questions

Close to the previous one even though one may happen without the other. Please do not assume one’s coding or design choices are wrong because they do not match what you would do. Ask questions and if there is a real issue try to provide comments that drive the submitter towards a solution.


When you request changes, depending on the system you are using you may be blocking a pull request and preventing someone from working. Make sure you follow-up whenever you can, between two of your own pull request submissions, during a coffee break or anytime you come back to your desk. Time is precious and when you request changes on a pull request you become responsible for the additional time spent on it for every developer involved.

Bring a positive value

Ask yourself about the impact you have on a project or a colleague. Does your comment make your colleague’s day better or worse? If it makes it worse, does it actually help solving the problem at hand and bring a positive value? Because at the end of the day, all that matters is the value you can create. Value to a business, value to people. Making a positive impact on your environment will encourage others to do the same. Eventually it will help you and the people around you to thrive and yearn for improvement every day.

Special thanks to Joshua Dooms who did make a positive impact on my vision of how reviews should go.

Monster release, you’re welcome – Poetry time

Reading Time: 2 minutes

I like to write poems sometimes, even though I didn’t in ages. Also, I think I never posted any here. I hope you enjoy it,  please note that any resemblance to real persons, living or dead is purely coincidental.

Once upon a time a project manager
Decided to venture in a zone of danger
Little did he know was going to trigger a monster
Due to choices that none should ever foster
Because planning is not his comfort zone
He had to come deal with me like Al’ Capone
So that I deploy things with care for the ram,
And have them all set and done before 12 am
So there I went after eating some sweet and sour
With no idea on how the hell I’ll save the hour
Simply diving in the project “à la bite et au couteau”
Hoping we were careful with our tests and big O.

Let DJ Khaled provide beats for my theme music
Keyboard clacking, things working, it’s almost magic
Configuring this, merging that, surprise, here’s Murphy
Go away, I don’t have time for such a lack of empathy
Sneaky issues jumping in like the body snatchers
I had to unleash a monster so that I can bury those naggers
But you bastard insist on providing me company
Of rage, the monstrous herald you made me, oh irony
Behold people! For that the animal I have become
Will send you straight to the skirts of your mom
Then you will get confused and wonder “what have I done?”
Too late, the end is near, for now my lock is gone.

Murphy tried to reign like the Lord of Castamere.
But now the rains weep on his walls, and not a soul to hear.
It did take quite long to dispose of that rude enemy
Still I wiped out issues and bugs at once with a fierce envy
Oh manager, you didn’t have to summon that vanguard
Hear me out, planning ahead cannot be this hard
So that next time we can work with quiet and ease
And not wreak havoc next time there is a release
Hope you will survive that monster’s next rampage
When looking for heroes again we open the cage
Let God preserves us or its return shall be gruesome
But now I locked it back, sit down, you’re welcome

C# dynamic interface implementation at runtime

Reading Time: 2 minutes

Some context first

How did I come to write a class allowing dynamic interface implementation in the first place? Ever had to work on a huge company project over the weekend? Because it is the weekend you pick up fixes what should be easy configuration changes. Then you think it will take you only a couple of hours then you will be off to the gym. I thought that yesterday and boy I mislead myself, much mislead indeed. Basically I had to update a couple of big projects to remove fields that are null from the json response. All of that listening to stuff like the Ding Dong Song, Purple Lamborghini and Slipknot’s Psychosocial. On the first project I had to add a little line to have that working, so the second one should be the same right? I actually thought I would grab another task before leaving that improvised hackathon.

The thought journey

It was all fun and games until, surprise surprise, the second project used a custom formatter. That was to do some processing on the response objects and update some values to match our apps implementation. Fair enough. But the magical line of configuration to ignore null fields when rendering json did not work there. The obvious solution was to get rid of that custom formatter. The obvious thing to do was get rid of that formatter and figure a way to have that object value setting logic without touching the project classes. I say obvious because there were hundreds of classes there and I did not feel like changing all of them even to simply add an interface and its implementation. I had to set properties that may exist for hundred of objects. This is how I started googling, going through StackOverflow to try and figure how to achieve that.

The much lower scale Newton moment

During that thinking process I realized I could try to do something with dynamic objects instead of adding a value during the json formatting process. Interestingly enough, a few minutes later the StackOverflow ex-machina did its thing and I found that post “How to extend class with an extra property“. The answer from unsung hero Mario Stopfer brought me light on something I did not know was possible. You guessed it: Dynamic interface implementation at runtime. Not really in the form I needed but it opened a door of possibilities to me and a new perspective on the property setting issue. And I started coding, building, testing, debugging like crazy. After a few hours, I achieved what did not know was a possibility a few hours before. Dynamic interface implementation was there working and solving my issue.

Dynamic interface implementation: Epilogue

I had a nice afternoon of coding at the office, lots of laughs and problem solving that provides me with an article I really enjoyed writing and a new class for my in progress .NET utility project that should appear when mature enough on Github. However since you have been reading all of this you will have the code in a preview gist along with sample code. The only issue is that it does not work with the new .NET Core (yet?) so I will update it at a later stage when I find the time and solution. That or add another version. Without any further ado, here is what I called the TypeMixer.

Retail week hackathon 2016 aftermath

Reading Time: 3 minutes

Retail week hackathon 2016 result

Last week at the same time I was at home playing League of Legends to break away from the frustration of losing at the Retail Week hackathon 2016. I was frustrated because I was, well I still am, convinced that our idea was good enough to win. Actually, I wanted to write a post immediately after to express the mixed feelings I felt that day. On one hand, I loved the experience and the excitement of suiting up as my schools days nerd self. On the other hand I hated losing in a way that did not feel fair. I discussed about the outcome of the hackathon around and people felt like we should have won.

I still cannot believe that a system to book an hour in-store discussing with an employee about an item you see online. An employee you whose job is to sell you the said item, especially in 2016. Nowadays we are only clicks away from users reviews from all around the world. You can even have video reviews at least on youtube. I guess it makes more sense to the judges otherwise the Retail Week hackathon 2016 winner trophy would be on Poq’s trophies shelf.

When we first got the idea of the self-checkout we thought that the hardest challenge was having a working prototype. We were so wrong. We had a working prototype 4 hours before the hackathon ended. From there, we spent the rest of the time testing and fixing bugs to ensure the presentation’s success. The presentation did not go perfectly but the idea and the product were there. To be fair, I think that pretty much all the teams had a much presentation for lesser ideas which could be what cost us the gold. When the judges are involved in retail during a fashion event I guess this is key.

The self-checkout idea

We built a self checkout app that allows customers in a store to find items they want to purchase with indoor location using estimotes and geolocation to handle both indoor and outdoor app behaviour. The most interesting part is that you can scan your items so they add to your basket and when you leave the store you get charged automatically. We even built a mini-backend displaying the last paid basket.

We built a solid proof of concept even though there is some security flows that are fixable on the operational side. For the security tags, just add a device connected to the store system against which you scan your order generated QR code  to allow you unlocking the number of items you need to remove the tags from. Even further we can use security tags that would emit the value from the item barcode to enforce that someone is not unlocking something they did not buy. It is a 24 hour hackathon and still we thought about some corner cases.

We did focus on bringing people back to store. I think that we did show creativity and innovation using the latest technology. Maybe we did not manage to pass the idea to the judges but I know that this is the future of retail. Walk in a store pick what you need and go. No more queuing hassle. Basically shoplifting without the criminal aspect.

Learning and progressing

I may go next year if we put up a team again and learn from our mistake. Technical advancement is not the focus, presentation is. Coding the whole night to get a working prototype is not the focus, sugar coat is. Still it will remain a special moment to me because I did have fun. The self-checkout will be in your hands in a few years, I will do my best for it. I went, I saw, I learned, that is probably what I do best, learning. I learned things my whole life, both at school and out of it. Even now that I worked for a few years I still try to learn as many things as possible. Learning is key to evolution, it is the key to become a better version of one self.

A great way of learning is to take part in open source development, looking at other people’s code, taking on challenges. Since a few days now I am helping other developers on community based websites such as StackOverflow and Github. I had an account on both for some time but did not do much with them. The good part is that on one hand I can learn and sharpen my skills by taking on issues and at the same time I help others. Well, there is not much downside. On Tuesday I submitted my first (non-professional) pull request and it got approved and merged pretty much instantly. It was not much but it still feels nice, you can check it here.  And yesterday I got my first upvotes on a few posts on StackOverflow showing that giving time is enough sometimes.

That’s where I will end today’s post before I start spreading on random stuff, thank you for reading.

Everybody wants to be right, worth it ?

Reading Time: 3 minutes

Be right or “be right”, getting the truth on your side or winning an argument ? We find people doing both in many domains, both in science and everyday’s life. When you are lawyer, winning an argument is the end game. For some time I wanted to be one which explains why I have been like that for a while when younger. I listened to people mostly to crush their arguments because it feels good to be right. Even though the intention was not glorious, I became a pretty good listener. It allowed me to be a bit more aware of my surroundings and pay more attention to people and their opinion as they can help my reflexion going forward.

Over time this dragged me into looking more for the truth rather than for a truth that would suit me. Actually, it made me closer the scientific mindset built during studies and allowed me to be a little more objective. Constantly trying to be right instead of searching for the truth never served science. However, objectivity allows to think better as the focus is on facts and not emotions.

I ran into that TED talk with Julia Galef about trying to be right even when wrong to win. I found it really interesting mostly because I used to have that soldier mindset at some point. Even though going through scientific studies and cultivating myself as much as possible I probably have a bit left. Grabbing a theory and trying to prove it true is not a bad thing as Science progresses from research. But it becomes terrible if you keep hanging on it even when proved wrong. Indeed, you may find reasons to keep your theory breathing but it will not make it less wrong.

I will let you have a look at the video first as she talks about it way better than I can then go back to how this can apply to Computer science.

Scout mindset. If you skipped the video, you should go back to it to figure that out. If you do not want to check it out for whatever reason, the scout mindset is what sets you to look after the truth rather than being right. Yearn for facts and proofs rather than feelings and spoofs (I am not looking at the Brexit voters at all). History taught us that being too much in that soldier mindset that she describes can be extremely damaging. Many exemples exist around the world, Nazis, Ukip, Turkey now ? But let us go back to why you are here, Computer science.

In IT the main domain where that scout mindset will be of use is basically any aspect of software development. Wether it is about picking a working methodology, building a new feature or simply bug fixing. The main issue when you build something is that you will naturally be more defensive about it wether you did good or not. And it is very hard when developing something on his own to detect flaws otherwise you have not written that code in the first place. As a way of going through that we have pair programming which works mostly when the collaborators have opposed views. You can also discuss with tech people among your friends and acquaintances as they may provide you a fresher view. Discussing with colleagues during a standup meeting or during a coffee break can help you to open your mind a little more.

I feel like I have been confusing in this article so I will try to sum up a bit. There is a couple of things to retain actually. First, yearn for facts, clues as it is what makes research progress in any domain. Second, to listen to people. Not just hearing them, but paying attention to the input they can provide even if you do not agree. Often people that you would usually ignore because you think you are better than them or whatever. Listening will save you time or open your mind with their knowledge, a knowledge you may not have. Being able to find a solution that makes you being right feels good, even if it is not the best one. Being right is like victory, it always feels good but it does not necessarily make you progress.

I hope you enjoyed the article, for more food for thought I recommend you to check out the TED Talks which contain a lot of interesting topics about everything. I personally focus on Technology, Society and Science subjects but there is a lot more than that. Who knows, maybe some day you will see me in one of those videos. On those words, have a nice evening, day, weekend or whatever this is to you. And oh yeah, get a free meme.

Being technically right