a coding nagger's blog

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

Tag Archives: poq


Greek Goddess Gamble: Slowing down the writing

Reading Time: 2 minutes

Hi everyone, it’s been exactly a month since my last post and I have a good excuse for it. As it turns out I was pretty busy between a wedding, a holiday and the beginning of a personal project. Yep, another one! From now I will refer to it as my Greek goddess gamble until I reveal what it is all about.

The phase 1 of that gamble started a few weeks ago, hopefully I’ll make enough progress by December. Time is key here so it is more than likely that I post even less until then which makes it an even bigger gamble. Not posting for a month slowed down the growth of the number of views by 8%. Still I am lucky enough to see the number of readers slightly increasing week after week and hope it will last until December. Hopefully, the break will allow me to fully focus through my weekends and evenings to deliver on that crazy move.

Before you ask, no, I am not gonna retire to a corn field to raise my chicken anytime soon. Anything chicken related I leave to KFC (not sponsored, but can be :wink wink:). Here I am digressing again because I don’t want to risk revealing too much. Back to the main topic, that Greek goddess gamble does involve a fair amount of coding along with research. I originally wanted to kind of serialize and post every week about it or even vlog my progress. But eventually I realised that it will be more meaningful if there is a clear narrative through the posts. It is much easier to tell a story when you know the end.

To conclude, if the phase 1 of that gamble goes well, I will start to post on a weekly basis and/or vlog through phase 2. In case of failure, well I’ll just present over a couple posts what it was about and what went wrong. Stay tuned!

P.S. If you feel craving for my personal posts you can check out my recent poetry or my techier stuff. You may even want to keep an eye on Poq’s blog within the next few weeks, just don’t tell anyone I told you.

My Musketeers for DotNet Test driven development

Reading Time: 5 minutes

Test, four letters, one meaning and for some people a struggle. Getting people around you to write tests is easy only when everyone already agrees with you. As often, there are instances where some people show resistance to writing tests. Here are the stuff I hear the most from them:

D: I don’t have time to write tests.

A: I don’t need to test this.

B: I can’t write a test for this.

Not writing tests will always lead to hours of tears and blood. Tears and blood from debugging something you let slip through. Something that broke your super edgy software. I am not saying that writing tests will lead you to a bug free software but at least you know exactly how your code behaves. There, you know what you can reasonably expect from it. Despite having a great code coverage your code will eventually break and it’s perfectly fine. This is where your tests become useful as they will help you ensure you don’t break your existing code while refactoring or fixing a bug. Then you can simply add a new test to cover that unexpected scenario.

Per example, yesterday a colleague had some weird data mix up on a development deployment of an API I created a few months ago which revealed a case I didn’t think of. That API had 95% coverage and still a bug showed up because it is how software works. Although the bug was generated from a virtually impossible case, so what I did was replicate it, write a test for it, fix it and get it through review and released it all within 30 minutes. That project coverage is now at 98% (highest we have now, of course I’m gonna show off about it) and yet I know that one day or the other another bug will pop. When that day comes, it may not be fixed as quickly as yesterday but it will be as easy to refactor parts of it safely.

Yes it takes some time to write tests but on the long run it is more than worth it. For a long time I thought that the only reason for one not to cover his code would be laziness. Not the good laziness that makes you want to save time by writing tests and not spend hours debugging and testing a whole bunch of non covered features. Still, over time I came to learn that no developer walks to his desk everyday to write buggy code on purpose. A lot of factors come into play such as clients and project managers pressuring you with tight deadlines. Tighter and tighter deadlines, day after day. Then ensues a drop of quality in favour of faster delivery that in the long run can hurt a business.

In that kind of situation, blaming a developer for not writing tests will not help anyone. However, what can help is providing tools to help that developer to move faster. This is where today’s post is supposed to help you. Help you to accelerate your development. Today, I am using this post to present three tools that help me everyday to deliver code faster without sacrificing quality. Although nothing is magic, I hope these will help you in a personal or professional context as they help me every single day.

It doesn’t matter whether you have access to continuous integration or not. However, what will matter is your ability to write decent tests. Even if you write only very simple happy path tests, as long as you write those properly you will be fine. Here we go!

Moq

Moq is awesome for unit testing. What is unit testing? Well, I don’t have a proper definition in mind and there are tons of different versions online. The version I learned mostly over experience and you are free not to believe the same thing. To me, a unit test is a piece of software written to test a component regardless of the dependencies it has to make sure that a defined input will provide an expected output. Basically, unit tests allow you to validate your software’s behaviour in a way that prevents you or a potential collaborator from breaking it your software later on.

How does Moq works? The premise is that you can mock any interface which allows you to define how your software behaves based on a dependency input. Which is great in an inversion of control context. This also extends to class virtual and abstract methods so that you can create tests defining how a class behaves based on what a method could return. Another cool feature of Moq is the possibility to verify the methods of a mocked interface/class got called with a specific input. That will allow you to make sure that the method under test is calling its dependencies methods with the parameters you expect.

For more information on Moq you can check out their documentation on Github

AutoFixture

Let’s now move onto AutoFixture that I use pretty much since it exists. AutoFixture is a library that allows generating dummy data on the fly in any context. This thing made my test writing so much faster. It also works great with Moq to quickly write test cases where the input data does not really matter. You can use it to generate data of type, from string to bool to your custom classes. One of my main use for that library is to create data on the fly without thinking too much about it and use that generated data to validate my tests.

I have not reached the limitations of what you can do with that tool yet. However, you need to be careful with types that have a recursive relationship which you often get when you work using EntityFramework. Per example, if you have a Chicken class with an property of type Egg. Imagine that Egg class has a property of type Chicken, you will end up with an exception due to some kind of infinite loop situation. You can avoid that situation by defining what properties you don’t want to set when generating your data.

For more details on AutoFixture, check out their Github.  To jump straight to code samples here is their cheat sheet.

Postman

This one is a bit more different than the others mentioned previously. Indeed, you can use Postman to document how your API works. You can use it for monitoring with a paid account or build a monitoring of your own using Newman. I wrote a couple of posts about it over the past months to get started or to build simple CI using Appveyor. What I like with Postman is that it is pretty intuitive and straightforward to use even for non-technical people. Once you get started you can  do some pretty advanced flow-based testing which is pretty useful in micro services architecture. In the end, how and where you use Postman is down to you and I love the flexibility of it. That flexibility that allows you to make it fit your needs and accelerate your development.

Thanks for reading, you can now go and write a bunch of cool software with loads of tests. Or don’t. I’m not your dad and I won’t punish you, but your code will.

 

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.

First month at Poq and Retail Week incoming

Reading Time: 2 minutes

Yesterday I completed my first month at Poq and I am quite happy with my decision to join them. It changes from prin pretty much everything. I enjoy Poq for different reasons than those I enjoyed Lodgeo at first. However the most important part is that I can express myself in terms of development. At Poq there is more room for ideas and innovation than I was used to in my previous companies. It is crazy to see that I am 25 and including internships this is already my fifth company.

I learned so much over a short period of time and I brought some of my touch to the team. The only victim so far is my Yoda programming that my coworkers wiped away after a few code reviews. I yearned to come back to C# development in a company ever since my first internship at Itop. And now I really enjoy all the improvements of C# went through since 2010. And C# 7 brings a lot in terms of making a code more concise and easier to review. Working with colleagues with a strong experience in development will impact me and lead me making it to another level.

3027105_Hackathon_VISUAL

Talking about new step, I discovered a few days ago that in two weeks from now I will participate to the Retail Week Buzz hackathon where I will represent Poq with other coworkers. It is a big deal to me as it will also be Poq’s first participation to a hackathon as a company. Actually it will also be my first hackathon which is quite exciting.

Together we will try to figure how retailers can use technology to drive online shoppers into store locations and create a truly seamless customer experience in the process. This is a big challenge considering all the things we can do using mobile and web apps not much is left for the shops. The obvious reason to go to a shop is because good that is either not available online or not working. We will prepare ourselves to bring up an idea that can make a difference in the retail world and deliver on September 15.

Until then I will slow down on my League of Legends side project that I started a few days ago. There is some progress, I have some of the key logic elements in place. Hopefully in a few months I will have a first version available.

Menorca, dawn of my Lodgegoing

Reading Time: 2 minutes

Hi everyone,

So much happened since my last post, me going in Menorca for holidays just after signing for a new company, France losing to Portugal the Euro’s final. I was watching the game with my girlfriend from a bar called Su Païssa. We were chilling and drinking, having a good time then Eder’s goal happened. I was a bit pissed by how I felt Les Bleus gave the title to Portugal but happy for Cristiano Ronaldo. This guy probably never even dreamt he would ever get a major gold with his national team, and I have the utmost respect for the hard work and dedication he puts in the game.

Hard work and dedication are values that I believe should always be rewarded or at least recognised. It does not matter that it is football or work, if values that allow moving forward are promoted a business can go forth and grow in a virtuous circle. The more recognition for one’s quality work, the more quality work will follow. It is not the only thing that matters though but it plays a big part. Those are thing that I deem essential whenever I sit behind a keyboard or stand in front of a whiteboard.

Dedication is what wakes you up every single morning and go get more and more information about the world around you so you can adapt to it and think about a way to make it better. Hard work is the application of that dedication in your work wether it is personal or commercial. Often after a lot of time offering that dedication and hard work to a party the time may come to move on to a different challenge. A challenge that may be more rewarding at multiple levels.

After a few weeks of search I was trying to find an environment that would allow me to express my skillset to the fullest. An environment where I would be able to take on challenges nobody else tackles. An environment where hardwork and dedication would be rewarded. An environment where I would be back on tracks with my planned learning curve. An environment where I would have a highly talented team to help me progress as an engineer, as a developer and as a person. I can happily announce that I found such an environment as I signed a contract with Poq last Thursday.

Now I am enjoying a well deserved holiday in Menorca with my girlfriend before going back to London for a last week at Lodgeo. Menorca, sweet little island near Majorca in Spain. Menorca where I have the best of views whenever I wake up and do not think about anything else, just clearing my head. Menorca where I am writing this article. You were free to stop reading after the Poq announcement. Bonus for the patient readers, a selfie with my girlfriend having drinks.

Menorca

Menorca