Category Archives: Reviews

Finding Wakelocks in Android 7 using Google’s Battery Historian

One of my favorite apps prior to my upgrade to Android 7 (Nougat) was GSam Battery Monitor (the paid version is fully worth it). Unfortunately, Android 7 no longer allows apps like GSam Battery Monitor to track individual application battery usage, CPU usage, or wakelocks. That sucks*.

In Android 7 with Doze, you should see periods of marginal battery usage. The more apps you have, the more background services/sync operations/location broadcasts are running and you’ll see plateaus in battery usage be more slanted. Up until a few weeks ago, battery usage would basically flatline between screen time. I set out to figure out what was causing this. I found a thread on Reddit discussing Battery Historian, so I decided to check it out. This post is somewhat of a review of this tool.

Battery Historian analyzes bug report files and presents the information in an interactive graph with categorized breakdowns of battery usage. Battery Historian is a web application written in Go, and doesn’t appear to have an official release (binary or hosted). This means it’s basically limited to power users to evaluate. Since it’s licensed under Apache 2.0, I compiled and hosted this for my own use at Before using my hosted instance of Battery Historian, please heed Google’s warning about bug report files:

Bug reports contain data from the system’s various log files, including personal and private information. Only share bug reports with apps and people you trust.

Running Battery Historian locally isn’t too difficult. I definitely recommend going this route if you’re more of a power user; you don’t need programming experience, only comfort on the command line.

Once you’ve taken a bug report on your device and uploaded it to Battery Historian, you’re presented with a graph of all activity found in the bug report.


The declining black line is the same battery usage visualization you’d see in your Battery Usage application or widget. Other groups of battery draining events are presented as horizontal time-oriented lines; some are either on or off (screen), some show gradients for battery draining in the category (temperature), while others display different colors for different states of the event (Mobile signal strength).

Scroll below the graph and you’ll find a breakdown of system statistics. After a little sorting and investigation, I found that JuiceSSH had locked WiFi for 1.5 hours when I hadn’t used the application for over a week:


After selecting the JuiceSSH app in the left dropdown, this takes you to the App Stats tab which presents some interesting battery usage statistics:

Wakelock Name      | Full Time | Full Count | Partial Time | Partial Count | Window Time | Window Count
JuiceSSH CloudSync |           | 0          | 8m 0s 50ms   | 1             |             | 0           
*alarm*            |           | 0          | 684ms        | 1             |             | 0           
Service Name                            | Time spent started | # starts | # launches | 2h 28m 15s 789ms   | 1        | 1         
Process info:
Time spent running actively in the foreground       | 0ms             
Time spent with a service running in the foreground | 0ms             
Time spent on top                                   | 0ms             
Time spent on top while the device was sleeping     | 0ms             
Time spent running actively in the background       | 1h 33m 10s 343ms
Time spent cached                                   | 38ms            

Looks like, in my case, JuiceSSH Cloud Sync had 8 minutes worth of wakelocks, 2.5 hours of a service running in which 1.5 hours of that was actively running in the background. JuiceSSH unfortunately doesn’t have configuration options for Cloud Sync, so I’ve disabled it. I’ve noticed an improvement since disabling JuiceSSH Cloud Sync.

Although I was a little miffed that the Android 7 update borked GSam’s ability to report on per-application usage, I found Battery Historian to be a really insightful tool. From and Android Development perspective it would be a nice utility to evaluate your application’s effect on the system through normal use. It may be a little overkill from a user or power user’s perspective, though. My Nexus 5X was getting about 18 hours of pretty heavy usage (including my son watching YouTube videos). After disabling JuiceSSH Cloud Sync, I’m seeing about 20 hours of battery out of the same usage. Does that really matter if you’re like me and you charge your phone every night? 👻

* I’ve read that GSam Battery Monitor with root still works as expected on Nougat.

Review: Core Java for the Impatient

I’ve just finished reading Core Java for the Impatient by Cay S. Horstmann. I also own Scala for the Impatient by the same author, and I really loved that book. Having had previous experience with Scala, I was excited to read up on the newer features introduced in Java 8. Maybe it’s because I’m a C# developer professionally, but I’m really impressed with the new Java 8 features.

Horstmann’s books are excellently written for existing developers to quickly become familiar with newer languages and technologies. This book isn’t meant for a beginning programmer to dive right into software development using Java 8, but if you have C#, Java, Scala, or other C-style experience you’ll be set. The pace is excellent and the book flows really well.

While it’s expected that you’re already a proficient programmer, I didn’t get the feeling that it was expected for the reader to understand functional programming. Java 8 introduces a lot of functional style which I’ve seen existing Java developers complain about. I’ve also seen C# developers complain about Java verbosity. While I can’t help people who dislike functional programming, I can say as a C# developer that Java 8 really helps reduce the verbosity of the language.

Before Java 8 you’d have to construct a whole new class that implemented a single method if you wanted to create a Runnable (I have limited experience with pre-Java 8, so forgive me if that’s incorrect). In Java 8, you can assign a runnable to a lambda expression. The compiled code will still contain a one-off class but you as a developer don’t have to worry about those details. This kind of syntactic sugar really makes for more readable and more maintainable code. This is the first material I’ve read which covers Java 8, so I assume Horstmann has covered everything. I actually don’t think Java could have packed anything else into Java 8 that wasn’t covered in this book. It’s hard to believe so much great content was presented in less than 500 pages.

The book is written to appeal to the applications programmer, so Horstmann offers a lot of material such as functional concepts in the Collections and Streams chapters, annotations support, date/time improvements, and internationalization. He doesn’t walk you through creating a parser or an actor system like he does in Scala for the Impatient, but he does give you the necessary information to create a maintainable application in Java. The fact that you’ll learn how to create and process annotations as well as to perform runtime compilation of classes opens a world of possibilities (these sections obviously only touch the surface).

The book also covers Nashorn, a JavaScript REPL that provides access to Java types. I have node.js experience, so this really interests me. I’ll need to investigate the performance implications of running Java code from within this JavaScript environment, but this also opens a lot to an applications developer. For example, if you want to play around with a type in Java’s core library, you can fire up a REPL and instantiate the type rather than going through the rigamarole of creating a throw away project. As a C# developer, I use LinqPad regularly on Windows and Mono’s `csharp` interactive shell on OSX.

Again, I love how concisely the content is delivered. The code that accompanies the book is well structured, allowing the reader to quickly jump between text and the full implementations of the code in the book.

Another thing I enjoyed about this book is how information with short examples are presented in the chapter’s text and exercises are presented at chapter end to give a more hands-on experience. If you skip over the exercises, you’ll still get all of the important material of the chapter.

I would recommend this book to any non-beginner who wants to learn about Java 8.

Rating: ★★★★★ (5 stars)

Review “Learning 2D Game Development with Unity: A Hands-On Guide to Game Creation”

I’ve just finished reading Learning 2D Game Development with Unity: A Hands-On Guide to Game Creation, and I really enjoyed it despite many issues with the actual text (I’ll try to cover everything here). I’m just starting to learn Unity3D for 2D game development, so I’ve only watched a few of the official videos and followed a few tutorials online (the best so far being from After reading this book, I felt way more competent at creating my own game than with tutorials I’ve done elsewhere.

That’s not to say there aren’t some problems with the actual book contents. Quite a few people also have had problems with the book based on the Amazon reviews. I think the greatest comment, and a sentiment I share, is that the book could benefit from a technical edit. I’m a professional software developer, and I struggled to follow what was going on at one point.

This leads me to a major issue I had with the book, dropping a star from my review: Chapter 7 (Setting up Player Physics and Colliders) belongs before Chapter 5 (The Basics of Movement and Player Control). I don’t know how something like this could have been missed, but there’s no excuse for a ‘follow along’ book to be anything but sequential in its content. I’ve self-published a programming book, so I know getting things in the correct order while writing and editing is difficult. I also know that it’s unlikely for an editor or even a technical reviewer to catch this (you literally have to be ‘following along’ to encounter this problem). I toyed with giving the book 4 stars because I loved the content so much, then I thought about how well presented other books I’ve given 4 star reviews are and this book isn’t presented at the same level. If you take my advice and read Chapter 7 before Chapter 5, you’ll have almost no problem with this book. I went through the entire book in about two weeks using Unity 5.

This leads me to another problem which reduced my review by a ½ star: Chapter 14 is incomplete. Chapter 14 covers a then-beta feature of UGUI control layout and interaction. Unfortunately, there is only a single page between adding your first element (a Mask) to the canvas and the end of the book. Had the book just ended there, I would have thought, “OK, that was very high level,” and probably shrugged off the last chapter. The summary of Chapter 14 says “We gave a brief overview of building a simple Options menu with some text elements, buttons, and graphics” and almost none of this was even covered in the chapter (possibly because I’m reading the ebook?). Again, this seems like it would have been caught with a good technical or even a copy edit.

Another 1½ stars get deducted for what others have emphasized as a general feeling of being ‘all over the place’ with the instructions. There are a few times where numbered lists go from selecting a GameObject and doing nothing to modifying some other GameObject and selecting the first GameObject, which then gets modified. I actually found some humor in this, because it reminds me of peer programming with an extremely caffeinated coworker. I couldn’t ignore this in the review, though, because it happened more than once. For another example, the ‘Creating Components’ section of Chapter 2 explains the steps for creating components in what read like commands (but are statements) and the following section defines the actual steps. If someone was to follow the command-like steps (not in list form) of the one section, then the actual command steps (in list form) of the following section, this would become very confusing.

I experienced a general feeling of the book being ‘all over the place’ through Chapter 4. This was where I realized that the end-of-chapter ‘Exercises’ were actually continuations of the chapter content. I’ve literally never read a book where an ‘Exercises’ section wasn’t supplemental content to further your understanding of the material within the chapter. Rather than an ‘Exercises’ section, this book really should have just labeled the section appropriately. DON’T SKIP EXERCISES or you’ll be skipping part of the content.

I will say that other reviewers on Amazon have had unnecessary problems with downloading companion code. The code is very clearly linked on the book’s preface and from the InformIT product page. Even if you were to purchase the book from Amazon or somewhere else, I don’t know where else you’d look for companion content than in the preface.

Please don’t read my review as negative, I’m only trying to point out the issues I’ve found with the book. If you follow all of the exercises, read Chapter 7 before Chapter 5, and pay attention to what you’re reading (some of the examples in the book have incorrect code which have been fixed in the companion content’s project files for the chapter), you’ll really enjoy this book. I enjoyed making the example 2D platformer throughout the book. I didn’t hate or dislike the book, but I also don’t think beginners should have to piece together the contents of a book just to ‘follow along’. All of this stuff could easily be resolved with an updated (and well edited) copy of the book.

One of the things I really enjoyed about this book is how options are explained concisely in a single place. This made me feel way more familiar with the Unity editor and the options for game components. While watching some of the official videos on Unity’s site, I felt like the speaker was moving way too quickly for most people to follow along in the editor while explaining very little about what every option meant. Many tutorials I’ve seen online explain the steps to make a simple game (often lacking sound effects, particle effects, or even most of Physics2D). This book does an excellent job of explaining the basics of everything used to make a 2D platformer game. In fact, if it wasn’t for the editing issues I mentioned earlier, I would have given this book 4.5 or 5 stars. It’s meant for beginners, and I feel like non-programmers and programmers can all easily digest the material.

I made a list of many mistakes I found while reading this book. I’ll be emailing the authors the list, so hopefully the addenda will be updated. I’d love to see the book updated for Unity 5.

Ratings Summary

Overall: ★★★☆☆ (3 stars)

Editing: ★★★☆☆ (3 stars)
Not ‘poorly’ edited, but very close. A lot of the mistakes could have easily been caught by having any non-technical reader proofread the contents.
Presentation: ★★★☆☆ (3 stars)
I gave three stars for presentation because there are some code snippets in the book that just won’t work. I’m not talking about issues like Unity 5 doesn’t have this.rigidbody2D anymore, so you need to create a private variable and gain a reference in the Start or Awake function. I’m talking about things like the EnemyController’s Flip method flipping the instance and invoking flip on a colliding enemy instance, causing the two operations to cancel out. Then, there’s the issue of at least one image, Physics2D configuration, not matching the text in which the text says Player-Player is unchecked while the image shows Player-Enemy unchecked (using image settings makes your player invincible).
Material: ★★★★☆ (4 stars)
I enjoyed the material. Best of many tutorials I’ve followed. I give 4 stars because the book is very basic (it’s for beginners), yet doesn’t exactly introduce best practices. For example, the basic platformer developed in this game creates a single level in which 1×1 components are used for the scene’s map. There’s no mention of performant alternatives like using Tiled and Tiled2Unity to create a single mesh map. This *could* be because Tiled2Unity wasn’t out at the time of the writing, but I’d expect at least the acknowledgement of the performance limitations.
Enjoyment: ★★★★☆ (4 stars)
I thoroughly enjoyed the book. With my notes about following exercises and reading Chapter 7 before Chapter 5, I would recommend for beginners to read this book. One last caveat: if code in the book doesn’t seem to ‘work right’, try the code on the author’s companion site.


Review: Swift for the Really Impatient

I’ve recently finished reading Swift for the Really Impatient. It was a really good book; I’d give it 4 out of 5 stars.

I had previously read Scala for the Impatient by Cay S. Horstmann. I’d like to note that, despite the similarity in title, Swift for the Really Impatient is not written by Cay S. Horstmann. I found the writing style to be noticeably different, but in neither a good nor a bad way. I just wanted to mention that Swift for the Really Impatient is written by Matt Henderson and Dave Wood, in case you’re a Horstmann devotee.

I’d like to make one thing clear for future readers. This book will not teach you to write your first functional OS X or iOS application; it assumes you’re an experienced Objective-C developer wanting to learn Swift’s syntax quickly. It differs in this way from Horstmann’s books, the style of which the authors have attempted to mimic. For example, after reading Scala for the Impatient the reader will be be able to write parsers, perform file and network functionality, as well as design and implement a minimal (yet powerful) distributed event bus using actors. Swift for the Really Impatient won’t teach you any of these types of things. Again, it’s related to Horstmann’s books only by similarity in title.

The book flows very well and very quickly. I read the entire book in my spare time, spanning only a few days. At only about 140 pages, compared to The Swift Programming Language book written by Apple (~600 pages), Swift for the Really Impatient is by far the easiest and quickest book to digest if you want to gain an understanding of Swift. If you’re familiar with Scala, you’ll breeze through this book.

One thing that kept throwing me off in the book was how it really feels targeted toward developers who were previously familiar with Objective-C. This isn’t a bad thing, considering you’ll need to at least understand Objective-C to really dig into OS X and iOS development using Swift. It’s also not a prerequisite for reading and understanding this book. The reason it threw me off is because the book doesn’t really ever explicitly define the target audience as having prior Objective-C knowledge, so sections explaining that “…the syntax of Swift should look familiar to Objective-C developers…” offer very little to developers without Objective-C backgrounds. It is fair to mention that the description on the Amazon product page for the book does clearly define the target audience as experienced Objective-C developers. If you pick this book up having had no prior experience on Apple’s platform, you’ll probably see some of the Objective-C code and think “what the…?!” Good news, though! You should be able to easily glance over the Objective-C parts and still fully understand the syntax of Swift.

I would actually take the authors’ references to Objective-C and expand them a little. Much of the Swift syntax would be familiar to someone with Java, C#, Groovy, or even JavaScript experience. The only places I think some developers may have a hard time are with the sections on Optionals and pattern matching. I felt like the authors excellently explained these concepts, but I’ve experienced first-hand in Scala how Java developers have struggled with these concepts. If you find yourself struggling one these sections, take your time and maybe reread the section (be less ‘Really Impatient’).

I loved how well the authors explained closures. If you have a JavaScript background, the section on closures will make a lot of sense. A book I previously read on Swift application development using Cocoa did a comparatively terrible job explaining closures, so it was refreshing to see the subject clearly and concisely presented in Swift for the Really Impatient.

The book definitely delivers the material you need to quickly understand the capabilities and syntax of Swift. The reason I’ve given it 4 stars instead of 5 is because it doesn’t explain how to execute Swift code. There’s no mention that XCode 6 is required to build and compile Swift. XCode is mentioned only on one page, less than 20 pages from the end of the book. The section mentioned XCode explains how to bridge Swift and Objective-C code which took me a couple of tries to figure out when I attempted this while following Apple’s official documentation. I’d imagine that a truly ‘Really Impatient’ developer would get frustrated with the short explanation of the process.

Swift for the Really Impatient should absolutely be the starting point for any developer hoping to code for Apple products. It is quick, concise, and (most importantly) accurate. I may even go so far as to suggest the book to any engineers who are interested in learning the syntax of different languages.

Review: Microsoft .NET – Architecting Applications for the Enterprise, 2nd Edition

I’ve recently finished reading Microsoft .NET – Architecting Applications for the Enterprise, 2nd Edition by Dino Esposito and Andrea Saltarello. This book caught my attention for two reasons. First, I really enjoy software architecture. Second, I’ve read lots of work by Dino and always found them enjoyable.

The book gives examples of a few architectural patterns like Domain Driven Design (DDD), Command Query Responsibility Segregation (CQRS), and Event Sourcing. It starts with a pretty heavy focus on DDD and seems to assume that you’ve read *The* Domain Driven Design book by Eric Evans. I’ve only skimmed through that book, but it was enough to get many of the references. This book does cover the high level definitions of DDD in a way that the reader can jump right in. The accompanying source code even provides the same example in DDD and CQRS (the two main architectures being discussed).

There were two major things I liked about this book. I really enjoyed how the book isn’t presented as ‘this is the best software architecture, so you should use it.’ Things are presented in a way that clearly states the authors’ position on each architecture. For example, DDD is discussed as a the typical go-to architecture for enterprise systems. It’s a proven pattern that ‘just works’ in many cases. The discussion of CQRS clearly identifies some weaknesses in DDD and supplies an alternative with the explicit caveat that a CQRS-based architecture will change how you think about data.

The other main point I liked about the book is how real-world the discussions are. I usually get that feeling from Microsoft Press books. Early on the authors say, “To design a system that solves a problem, you must fully understand the problem and its domain.” In one of my previous positions, one of the first things I asked when joining the team was, “How have you documented what we’re trying to build?” I received a weird non-answer from the team’s senior developer. I went to the team’s manager and asked the same thing so I could understand the requirements gathering and technical design analysis that went into the product. He said, “We don’t have any of that — we’re Agile.” I thought he was joking, but he wasn’t. Obviously it would strike a chord with me when the authors said, “Agile architecture is sometimes presented as an oxymoron, like saying that if you’re agile you don’t do any architecture analysis, you just start coding…” Elsewhere they described the businessman-developer disconnect that occurs when requirements are incomplete, which is exactly what happened on the previous team I mentioned. It’s like I always say, “If you don’t know where you’re going, how will you get there?”

Another aspect of the book that I think can get buried in reading is the point about developing for a task-based user experience. Too often do developers start coding at the database and work their ways up to the user interface. Without a clean architecture, this can lead to situations where a column in your relational database has to change all the way to the UI. That’s silly. With a good architecture that clearly identifies boundaries in code, you inherently create more reusable and more maintainable code. I think this should be everyone’s main goal while writing code.

I also thought it was cool how the book and accompanying example code demonstrate using a NoSQL database (RavenDB) for an event sourcing application. While I don’t know where I’d ever use Event Sourcing over a more common architecture (mainly because I have to account for the expertise of other developers), I really like the Event Sourcing pattern. Now that Akka.NET is gaining traction, I wonder if Event Sourcing will become the way of the future.

One minor issue I had with the companion content was that it didn’t run as-is. There was a problem with the NuGet packages and MVC5 for which I found a solution at

I would definitely recommend this book for senior developers and engineers. It provides concrete examples and guidance from experienced architects toward more solid enterprise application design.

You can download the companion code for the book at

Review: From Mathematics to Generic Programming


(This is a repost of my Amazon review) I’ve been out of college for a while. I did well in math classes in high school and college, but I’ve been recently feeling rusty. I wanted to read this book to combine something I love (generic programming) with something I feel is missing in my daily life (mathematics). I wasn’t at all disappointed.

The book covers a lot of interesting historical stories of advancements, discoveries, and progressions in mathematics. It starts with the cravings of the Greeks to learn and how the study of the world around them incorporated arithmetic, geometry, astrology and other teachings. The book presents many different abstractions via axioms, theories, and proofs. These are then seamlessly related to generic programming.

Although the programming pieces of the book don’t stress this enough, the examples are a guidance toward functional programming concepts. Stepanov covers monoids, groups, semigroups, rings, etc. I was surprised by the amount of ground covered in this book. He even discusses how mathematics can be applied to social networks to do something like find friends of friends of friends (graphs).

The code examples in the book are written in C++. This may be intimidating for some developers. Don’t worry, the code isn’t overly advanced. If you’ve worked with another language that has generics, traits, mixins, or macros, you should be fine. These are the level of abstractions you’ll encounter in this book. There’s an appendix to introduce the C++ concepts, if needed.

There are plenty of exercises in the book. These are actually the only the only negative thing I have to say about the book. There are no solutions, no hints, and no companion code for the book’s exercises. Maybe when the book has been around for a while, you may be able to find a github repo where someone has worked through the tasks. I was sad to see nothing like this existed.

I would highly recommend this book to anyone with an interest in mathematics and an interest in generic programming. I felt like the book was a little heavier on mathematics than generic programming. However, I also feel like most developers I’ve met don’t feel comfortable with the application of mathematics concepts.