Debugging Made Easy with Overlog – A New Tool by the Netguru Mobile Team
A huge amount of a developer’s daily work is debugging. It’s the thing that makes this job really annoying, however on the other hand, resolving an issue and making something work is such an amazing feeling that being a developer is still worth it.
Some problems might only occur under some specific circumstances, maybe only on a particular device or in a particular place on Earth, and it’s sometimes impossible to reproduce them on a simulator or with a phone plugged into the computer. We’ve decided to create an open-source tool that makes testing and debugging much easier. Meet Overlog.
How Overlog helps in the development process
Overlog is an overlay for iOS apps that makes it possible to take a look under the hood of the currently running iOS application. With Overlog you can debug an application wherever you are. It’s also useful during our standard daily debugging, since it gives us some features that are not available in Xcode debugging tools.
Developers aren’t the only group that would benefit from using Overlog. It’s a very useful tool for Quality Assurance specialists. Imagine that you are a QA and you are seeing the wrong text in an app. The first question would be: “Is this text coming from the application or from the backend?” You don’t have any way to check this, so you’ve created a ticket for the iOS developer. As you’ve probably guessed now, the text was coming from the backend, so after wasting another couple of minutes running this by the iOS developer, he is reassigning the task to the Backend developer.
Sounds familiar? Thanks to Overlog, this won’t be a case anymore! Every person will be able debug the app without plugging the phone into a computer, or even knowing the technical details. You will receive a bug report with a very detailed cause of the problem and even the steps required to fix it.
How we’ve created it
Overlog started as an internal project. At Netguru, every person can propose an idea for a project, and if it’s good enough we can spend our work time on it. You don’t even need to be the one coding it, since we have many other developers who can help you. Internal projects are our solution for filling the gaps between commercials projects - this means that the team will change with time. To be able to do this efficiently, we had to split the project into many smaller tasks. As always, we’ve been using JIRA for this but, instead of sprints, we just had many tasks waiting on a Kanban board for any free developer.
Besides keeping a well-managed project, we also needed to keep the code in good shape. We’ve accomplished this thanks to our battle-tested development flow. One part of the flow is code review. Everything we write needs to be checked by another developer. You can take a look at how it worked here by going to the Pull Requests panel and checking the closed Pull Requests. Another go-to solution for maintaining the quality are unit tests, so we didn’t forget about them here. Did I mention how important the README file is? When the team is changing so often, keeping people updated is really crucial. Thanks to that, onboarding new developers doesn’t require any consultation. They can just open the repository and start working on the next task.
Prototype driven development
Prototype, Proof of Concept, and Minimum Viable Product are very common terms in the software development world. Sometimes because of the budget, sometimes because of the time, and often because of both.
Overlog also started as a prototype. We didn’t have any designs or user flows. The only thing we had was an idea. The best way to test if the idea is good was to build a prototype. So we did.
After a couple months of coding, it was ready. We had a working tool with just black text on a white background. We could test it on a real app and check if our assumptions were right. That’s the moment when you realize that not every idea is great, and this also happened for some of the features of Overlog. Hopefully, most of the features survived the confrontation with reality. It was the time to ask our Product Design team for help. Some time later we received beautiful designs and we could translate our prototype into a really amazing tool.
We encourage you to try Overlog and see how it will fit in with your project. If there’s something missing, please let us know by opening an issue on GitHub. If you want, you can also become a contributor to Overlog by opening a pull request. We will respond and provide feedback to all of them, no matter the size.