rbenv vs. RVMChoosing a Ruby version management tool often comes down to two players: rbenv and RVM. The latter was widely accepted as the norm, greatly due to its wide toolkit. However, rbenv has become a strong contender with its lightweight approach. Read More
As an iOS mobile developer, you may think you don't need to manage Ruby versions in your project. Many iOS projects use CocoaPods which is a Ruby gem. Some projects may even use other Ruby gems such as fastlane for automating your deployment pipeline, or slather for reporting code coverage results. Here at Metova, we use bundler to manage our gem versions, but it's also important to manage your Ruby version as well. Sometimes some of the gems used for your project may have known bugs with specific Ruby versions that haven't been fixed yet or they only support specific Ruby versions. When you manage your Ruby version, you can take more control over your environment. By doing this, you'll know that if everything works on your machine, it will work on other machines too. Specifically:Read More
Prelude to Swift 3 MigrationIf you didn’t migrate to Swift 3 in September like the rest of us, do it now and start next year off right. If you’ve been holding off on making the update, here is some advice and guidance to ensure a safe and swift transition to the next version. Migrating to Swift 3 can seem a bit daunting depending on the size of the project, but with the proper steps and procedures you should be able to get through it much sooner than later. Xcode 8.2 will be the last version to support Swift 2.3, and that in itself is an incentive to start the migration as soon as possible. Read More
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 More
2016 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?
is newer than
, the highest major version supported by
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 StepsThis 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 SuccessSo 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.
TracersTracers 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 / IsolationismWhen 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.
MetricsOver 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 LoggingCases 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
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.