Back

Coding & Development

  • Sarah Klinefelter
  • Posted by Sarah Klinefelter
October 10, 2016

As a mobile app developer, it’s imperative to be able to troubleshoot and find the root cause of an issue in a timely and efficient manner.  I’ve found working with more junior developers that the steps for effective debugging are much simpler than most would think.  The key is in taking a logical and step-by-step strategy to find the problem. Here are some tips and ways that have been proven to help pinpoint trouble:

Having Enough Data Or Reproducible Steps

This one is probably the toughest.  If there’s a sporadic or hard to reproduce issue, you may have to go back to the well multiple times to ask questions.  The important part is to know what kind of questions to ask.  Steps the user took, how often the issue occurs, what screen they were on, what operating system, what kind of device, and what version of the app are all good baseline details to have.  When working with forms, a sample of data the user input is a wonderful idea.  Since IoT is becoming more and more popular, you may need to inquire about the kind of network (3g, 4g, 2.4gHZ wifi, 5gHZ wifi, etc).  My best advice is to make sure you have enough data that’s actionable to investigate before continuing.

Last Point Of Success

So there you are investigating a reported issue.  You have the details provided by the client or end user, and you’ve been able to reproduce it. Of course, never seeing this in development, you are not sure as to why you are hitting this newly discovered failure path.  Maybe there was a missed edge, maybe a regression was introduced, or maybe a library was updated and there’s some compatibility issue afoot.  Morale of the story is now it’s time to figure out what is going wrong and why. To accomplish this, look how far back the issue goes (is it also in the last release? was it always there?) is helpful.  You can use source control to figure out when the breaking change occurred and then look to see what the breaking change is. You can also apply this methodology to logs.  Let's say you see “normal” logs but then suddenly during the issue you see a part that is missing or incorrect.  Starting at that last point of success in the logs and walking forward can be very insightful.

Tracers

Tracers are not a bad idea for time sensitive issues that attaching a debugger may cause to not be present.  I’ve dealt with multi-threaded systems, and to pinpoint any rogue thread behavior, I have found that throwing as many log messages into the system during the debug phase can be helpful.  One you determine something like the system dies at spot x or thread b overlaps thread a at this point, you know what’s wrong.

Process Of Elimination / Isolationism

When I speak of process of elimination, I simply mean boiling down the system to the smallest working variety.  If that’s not possible, you have to start thinking about your last success point and then eliminating pieces of the puzzle.  If the mobile app is supposed to talk to the server but that communication is not happening correctly, is the mobile app not sending the message or is the server not receiving or processing it? With logs you can determine which side is not acting accordingly. I’ve even had to use tools like POSTMAN to verify latency and that the server was processing correctly, isolating the issue to the hardware.

Metrics

Over recent months I have become quite fond of big data and the patterns you can spot from having a large set of users, devices, etc. reporting.  There can be strange one off errors, but when scaling a system and having it report details, it can be incredibly powerful to spot all users in case y have this happen.  

Remote Logging

Cases where it makes sense to do  this are to see remote events that otherwise you would not have knowledge of an issue. A good instance is adding remote logging to know if the user is triggering retry logic excessively so the system can be improved.  Alarms and timed events are another bit you can add remote logging for so I know they are in fact getting triggered. Be wary about overusing remote logging as reporting too much can make users uneasy. Gather what information you can, examine the differences from the last time you know it worked, and add various checks to your project. It’s rare that an issue doesn’t require some sort of sleuthing to uncover a solution. Having some ideas and processes prepared in your toolbelt will make finding the solution to your next coding problem easier. What are your favorite tips for troubleshooting?

Read More
  • Jennifer Pike
  • Posted by Jennifer Pike
September 13, 2016

Today's the day. Apple is releasing iOS 10. Here are a handful of new features  you can look forward to!

Read More
  • Drew Pitchford
  • Posted by Drew Pitchford
September 7, 2016

Apple's yearly fall event where new hardware is announced occurred Wedesday. As expected, there were announcements on the Apple Watch, iPhone 7, and new wireless earbuds.

Read More
  • Sarah Klinefelter
  • Posted by Sarah Klinefelter
August 10, 2016

Having a clean codebase is a good practice to get into. It makes your code easier to read as well as run more smoothly. One way to have a cleaner codebase is to use the DRY (Don’t Repeat Yourself) programming principle. It is aimed at reducing repetition of information of all kinds, and is especially useful in multi-tier architectures. If you don’t use these principles, think of your work as WET. It Wastes Everyone’s Time when you Write Everything Twice. There are several ways to keep your code DRY.

Read More

  • Jennifer Pike
  • Posted by Jennifer Pike
August 8, 2016

What is Reverse Engineering?

It is human nature to be curious about the world and how things work and then how to manipulate them. Imagine a growing baby. “What’s this thing attached to my body? Oh, an arm! I can move it! Hey, that shiny object sure looks interesting. Maybe I can use this arm thing to get it closer. There we go, now to just pick it up and taste it...”

Read More
  • Tony Robalik
  • Posted by Tony Robalik
July 13, 2016

Gradle Summit 2016

Gradle is the most popular build tool in the world -- or so said Hans Dokter, CEO and Founder of Gradle Inc., in his keynote address at the 2016 Gradle Summit in Palo Alto, CA, last month. I was fortunate enough to be able to attend this year, and learned a lot from some of the world’s most accomplished build masters. Let’s jump right in and see what’s happening in the world of Gradle right now. 

Read More
  • Metova
  • Posted by Metova
July 8, 2016

New Office to Provide Hands-on Opportunities for the Next-Generation Skilled Technology Workforce – Right on UCA Campus

Read More
  • Ben Coulston
  • Posted by Ben Coulston
July 6, 2016

Common Motivations for Using a Hybrid App Framework

Generally speaking, clients should reflect on their motivation for using Hybrid frameworks instead of native development. Below, I've outlined some typical motivations I've seen with potential clients and cleared up some common misconceptions. All of these sentiments are very valid and should be explored before making a final decision.

Read More
  • Coburn Berry
  • Posted by Coburn Berry
June 20, 2016

Examine a for loop in JavaScript: 

function lameLoopingCountdown (times) {
  for (var i = times; i > 0; i = i - 1 ){
    console.log(i)
  }
  console.log("boom")
} 
 

This loop makes two assumptions about mutability:

Read More
  • Drew Pitchford
  • Posted by Drew Pitchford
June 14, 2016

WWDC 2016 was a software centric show that introduced lots of new user facing features as well as provided developers with many new APIs to plug directly into system apps. All four of Apple’s major platforms received updates, which will be publicly available this fall. Check out what’s new!

 

Read More