We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies.

We use cookies and other tracking technologies to improve your browsing experience on our site, analyze site traffic, and understand where our audience is coming from. To find out more, please read our privacy policy.

By choosing 'I Accept', you consent to our use of cookies and other tracking technologies. Less

We use cookies and other tracking technologies... More

Login or register
to apply for this job!

Login or register to start contributing with an article!

Login or register
to see more jobs from this company!

Login or register
to boost this post!

Show some love to the author of this blog by giving their post some rocket fuel 🚀.

Login or register to search for your ideal job!

Login or register to start working on this issue!

Engineers who find a new job through Golang Works average a 15% increase in salary 🚀

Blog hero image

How refactoring my C++ app into a Go library made it better in every way

Brendan Le Glaunec 26 April, 2018 (4 min read)

1*Uy1i5ZbvY0OWPWCrmjMxQg.png

This is my own experience, and these results were mainly achieved because Golang is a perfect language for my specific project, while C++ is not.

I began working on the Cameradar project in March 2016. The idea started out in an internal meeting at work as a quick shell script intended to automatically discover cameras in order to reduce the time it takes to configure our video management system in new data centers. I decided to make it in C++ since that was the language we used primarily in our tech stack and it was the language I had the most experience in.

The original version had many features:

  • Camera discovery
  • Dictionary attacks
  • Stream preview generation
  • Stream quality checking
  • Runtime loading of cache managers (using dynamic libraries)

My former team leader told me that I could make it open source and let other people use it, which was really exciting for me as an intern at that time. I became the maintainer of my first open source project!

As time went by, the project shifted more and more from a developer tool to a user-friendly command line tool due to my focus on making it easy for anyone to use. Integrating it into a micro-service at work came with technical debt because of the tool’s flawed design. It was good as a docker image to use for quick penetration testing or to discover the credentials of your brand-new undocumented Chinese camera, but bad for its original intent.

We then decided making it a library, which would make it much easier to integrate into our micro-service, and was compatible with keeping a user-friendly tool for the current users.

I decided to strip out the features that were initially part of Cameradar in order to fit the internal business needs of the tool but were useless for most users. The thumbnail generation, stream checks and the possibility to connect Cameradar to a database were no longer needed if it became a library. Our internal micro-service or even another tool could now handle this part of the logic, that had nothing to do with the discovery and access of camera streams.

I got to work. I was extremely surprised to have a working library and binary after only 2 and a half hours of work, despite my very basic knowledge of Go! There were bugs around and improvements to be done, but it was discovering and accessing cameras successfully. The binary basically replaces the old application and also provides an example of how to use the library’s features.

A few statistics of the code base at that time:

  • Reduced the number of lines of code by 95% // Without some features
  • Reduced the docker image size by 95%
  • Added unit tests in under 2 hours
  • Made the CI much simpler and 90% faster

As well as other interesting facts:

  • Documentation is now automatically generated via godoc
  • The dependency management provided by glide makes my life easier
  • The user experience is much better than before thanks to a few awesome libraries
  • Adding new features to Cameradar has never been so simple and fast

1*x58UbQPEnwvezho4gSfRLQ.gif

the output of the app is now simple and clean

Of course it would have been possible to code unit tests for the C++ version, and also possible to give it a nice output like showed in the image at the bottom of the article, but it would have taken much more maintenance and time than in Go, and in the case of my project it would have been for no benefit at all.

It’s been only a few weeks since the 2.0.0 version is out, but I found again the early excitement I had for working on this project, and many more people are now using it, so I’m really happy about this decision. I can’t wait to refactor the C++ micro-service that I made a year ago using the C++ Cameradar, into a Go micro-service.

I’m not the only one to report such results:

“I have reimplemented a networking project from Scala to Go. Scala code is 6000 lines. Go is about 3000. Even though Go does not have the power of abbreviation, the flexible type system seems to out-run Scala when the programs start getting longer. Hence, Go produces much shorter code asymptotically.” — Petar Maymounko

And not only is it shorter to write than most languages, but it’s also often easier to code and to test:

“I’ve spent more time coding than debugging and it’s so simple, fast and funny…” — Roberto Costumero

A final argument that made this code refactoring worthwhile in my opinion, is that the Go community has been very supportive and is actively encouraging people of every level to contribute, which is wonderful.

To conclude, I would recommend to anyone who struggles to maintain a repository that feels like legacy and is full of technical debt, to give Go a try if it seems to fit your needs. You’d be surprised by how fast you would see results.

1*bTQ0JCjSXCr7VDaaxlZ2ng.png

the CI took between 20 and 26 minutes to build and test the C++ version of the code

1*XhqecGm88PZfA-47i6NoCQ.png

It now takes between 2 and 3 minutes only —even though the CI still simulates an attack on a fake camera to make sure it works properly

Also, the size of the docker image for Cameradar went from 379MB to 14MB.

I hope you enjoyed this article, feel free to contact me if you want to discuss the content of this article, or if you’re considering refactoring your project, I would be happy to talk about it with you.

Originally published on medium.com