Google is making developing devices and apps for the Internet of Things simple with their Android Things operating system. This is actually an updated and rebranded version of Brillo, which was announced at Google I/O in 2015.
Read More2016 is shaping up to be the year of Virtual Reality. We’ve seen the release of 3 major high-end virtual reality (VR) headsets - the Oculus Rift, the HTC Vive, and Playstation VR. We are also seeing some advancements in the mobile VR world as well, with Samsung releasing a new version of their Gear VR headset, and Google releasing its new Daydream platform- unique for mobile VR in part thanks to its motion controller - to complement its existing Cardboard efforts.
Much of the focus with virtual reality has been around gaming. However, as the hardware and platforms mature, it is becoming evident that VR has many applications outside of gaming. The ability to see depth and to have real movements translated into virtual space provides an immersive feeling that is convincing enough to make your brain feel like you are in a different place. This is known as presence (see my previous post for information about presence).
This ability to create presence lends itself to a variety of applications. For example, it could be used for…
When you see something like the below, what do you do?
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 MoreToday's the day. Apple is releasing iOS 10. Here are a handful of new features you can look forward to!
Read MoreApple'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 MoreHaving 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
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 MoreGradle 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 MoreNew Office to Provide Hands-on Opportunities for the Next-Generation Skilled Technology Workforce – Right on UCA Campus
Read More