Forem: Trevor Nemanic

12 Quick Tips From the Gradle Enterprise Workshop

Trevor Nemanic — Thu, 14 Nov 2019 15:54:56 +0000

The team at Gradle held their Enterprise Workshop to help diagnose build performance issues, shorten the feedback cycle between compiling and running code, and improve toolchain reliability. Furthermore, there was a short introduction by Airbnb about how they use Gradle Enterprise and treat developer productivity. This post will cover many of the small build performance tips presented by Airbnb and Gradle, without focusing on the offerings of Gradle Enterprise.

Airbnb's tips

Detect flakey tests and get rid of them. Airbnb uses a private tool, called Arborist, to do this, but it can be done manually too.
Build scans are incredibly important to finding slow Gradle tasks. They provide historical data which allow build performance engineers to triage the highest impact issues.
Build scans provide a convenience for diagnosing build issues. A software engineer does not need to be colocated with the build engineer to find an issue, allowing for faster turnaround time.

Gradle's tips

Toolchain efficiency importance grows as team size grows. More developers lead to a larger code size, number of libraries, and complexity of modules.
Developer happiness is directly related to developer productivity. A developer does not want to wait for code to compile, and even worse does not want to see build times increase over time.
Build performance improvements are difficult to pitch to those in product since it does not directly tie in with metrics like user revenue or new user growth. However, wasted developer time is much easier to pitch as it controls how much can be completed in a development cycle.
To calculate build performance improvement, a simple equation such as build time * num local builds = total loss can help convince those in product. A team of five people can gain ten to twenty hours per week of valuable programming time with a 25 percent improvement in build performance.
Build scans (./gradlew build --scan) analyze your build and suggest performance enhancements. If you use Gradle and haven't used build scans before, then I hope you try it and see the magic yourself. Even better, they're free!
An easy gain in build performance is to convert some of your eager Gradle API usages to lazy API usages. Use build scans to see the difference.
Another build performance tip is to move file system and network access out of the Gradle configuration phase and into execution.
Timestamps (System.currentTimeMillis()) generated in Gradle tasks can prevent the task from being cached, causing a huge performance hit. The Gradle build system can be told to ignore the "volatile" property.
Performance regressions easily happen over time. A developer can add a useful annotation library, unknowingly causing huge amounts of generated code to be built. The most reliable way to prevent build performance loss over time is to measure it and flag regressions.

Tips to survive a super commute (90+ minutes)

Trevor Nemanic — Sat, 23 Mar 2019 18:32:05 +0000

Super commuters commit at least 90 minutes grinding their way to and from work. The commute creates unnecessary stress and upsets work-life balance. This post is aimed at improving the lives super commuters by giving them useful day-to-day techniques. Personally, I have been super commuting for 11 months and have developed several tips out of necessity. They support me in a variety of ways, including lowering stress, improving productivity, and saving valuable time at home.

1. Focus on work while commuting to work.
I work on the train and it prepares me to be ready to hit the ground running in the office. The Harvard Business School found this practice of "pre-work" to ease mentally switching between home-life and work-life. They also found that listening to music or browsing social media may increase chances for a stressful work day. On your next commute, spend time catching up on emails and doing whatever sets you up to be successful. If you're in a car, you can use an email reader to listen to your emails out loud, and write your responses in a voice note.

2. De-stress on your way home.
This will prepare you to transition back into your home life and negate the side-effects of commuting. I have been practicing mindfulness with Headspace and it helps me de-stress in only three to ten minutes. Once practiced, it is more effective than trying to rest or zone out.

3. Have an end goal in mind.
One of the worst parts about super commuting is the feeling that you have committed the rest of your life to living in limbo. Instead, have a long term plan for reducing the distance and time between you and your job. Whether it be to increase your income so you can move closer or improve your job so it can be physically closer to you, make sure you have something in mind. Then, you can have a more positive outlook on the future.

4. Make a to-do list of things you want to do at both work and home.
This will separate the two concerns and increase productivity. I prefer to keep my personal list on my phone and work list on my laptop. Therefore, I stay focused on whichever part of my life I am presently at.

5. Set reminders in your phone to help you switch focus.
Super commuting eats away your free time, so it is important to judiciously utilize your commute time. When I have a stressful day at work, I will set a calendar appointment to use Headspace right when I get to my train. Then, I will feel refreshed and can focus the remaining hour and 15 minutes on productive home tasks (planning the next vacation, what I'm doing for dinner, etc).

I hope these tips are as beneficial to you as they are to me. Did I miss something which makes your super commute effective? Let me know in the comments! You can also follow me on Twitter

The Most Exciting Features Coming to Android Q

Trevor Nemanic — Fri, 15 Mar 2019 00:25:57 +0000

Google has publicly released Android Q Beta, the newest version of Android. With it comes many nice-to-have improvements for users. Google has largely focused on privacy, security, and performance, while preparing for the latest trends like foldables. Without further ado, let's dive into the best features in Android Q.

Foldables

Foldable phones have made their great debut in 2019. Whether you love them or hate them, expect to see a lot of news about companies, developers, and users trying out this new form factor. Developers won't be able to test foldables on the existing Android emulator yet (Google is working on that).

Granular Control for Location Permissions

Google has responded to the outcry of users to protect their privacy. So long to the creepiness of giving away your location at all times. Now, the location permission option will have an additional option to only give location when the app is in use.

WiFI Performance Modes

Mobile gaming has emerged as a powerhouse in the app landscape. However, latency has remained an issue since many gamers rely on WiFi. Android Q will ship with the ability for apps to tell the device to use low-latency or high-performance modes. This will greatly improve the experience of mobile gamers everywhere.

Dynamic Depth Format

Android phones have come a very, very long ways in terms of camera quality. Android Q will usher in another significant advancement: Dynamic Depth Format. This new format will allow apps to provide improvements to blur and similar features. Dynamic Depth Format will give app developers with the tools to actually see depth, something they have been simulating to various degrees of success. Expect to see much greater Augmented Reality and 3D images too.

Interested in trying these features out on your own? Sign up for the beta!

Further reading
Official Post by Google: https://android-developers.googleblog.com/2019/03/introducing-android-q-beta.html

Beginner Kotlin Runtime Check Tutorial: Require, Check, Assert

Trevor Nemanic — Wed, 13 Mar 2019 14:51:55 +0000

We often assume the state of our program is acceptable when our functions are called. Sometimes we assume the state or input can be invalid, so we do something like the following:

fun doThing(foo: Bar?) {
    if (foo == null) {
        return
    }
    .... // what you meant to do
}

Both these assumptions can lead to hard-to-find errors and unreadable code. Fortunately, the Kotlin standard library provides three basic functions for ensuring everything is in order:

Require: My function needs parameters to be valid in this way. Throw an IllegalArgumentException when false.
Check: My function's dependency is in the correct state to be called. Throw an IllegalStateException when false.
Assert: My function's result is valid. Throw an AssertionError when false. Also, runtime assertions have to be enabled on the JVM with -ea or enabled with Native.

In addition to validation of a condition, each one of these functions has an optional lazy argument for an error message if evaluated to false. All three runtime check APIs are the same. Here is an example from require.

fun require(value: Boolean)
inline fun require(value: Boolean, lazyMessage: () -> Any)

Let's take a look at each runtime check in depth, then write code to fire a laser cannon

Require

Require is used for parameter validation. It ensures its parameter is in a valid state.

fun fireLaser(cannonNumber: Int) {
    require(cannonNumber >= 0) { "Must pass a valid cannon number: $cannonNumber < 0" }
    .... // fire laser beams!!!
}

Check

Check makes sure our function's dependencies can be called safely. It is used to verify everything is ready to go.

fun fireLaser() {
    // setup above
    check(laserCannonManager.isReadyToFire) { "You must arm the lasers before firing!" }
    .... // fire laser beams!!!
}

Assert

Assert does the last bit of validation before a function is done or returns. It is your last chance before handing control to another part of the program.

fun fireLaser() {
    // setup above
    val fired = laserCannon.fire()
    assert(fired == true) { "cannon did not fire successfully" }
}

Why runtime checks?

They provide runtime assurance which can be useful in addition to unit tests. The checks force the program to fail fast and give the developer more info than a stacktrace from a distant failed component.

Obviously, these checks shouldn't be everywhere and should be added judiciously. Crucial functions which exist in a complicated space would benefit the most. See below how all three runtime checks ensure proper usage of our core laser cannon functionality.

fun fireLaser(cannonNumber: Int) {

    // first, validate parameters
    require(cannonNumber >= 0) { "Must pass a valid cannon number"}

    // then, verify working dependencies
    check(laserCannonManager.isReadyToFire) { "You must arm the lasers before firing!" }
    check(guidanceSystem.canLockOn()) { "Cannot lock on target" }

    // call laser code safely
    laserCannonManager.charge(cannonNumber)
    guidanceSystem.lockOn()
    val laserCannon = laserCannonManager.cannons[cannonNumber]
    val fired = laserCannon.fire() // fire laser beams!!!

    // lastly, make sure our cannon fired flawlessly
    assert(fired == true) { "cannon did not fire successfully" }

}

Hopefully you have a comfortable understanding of these runtime conditions. Feel free to post any questions you have in the comments!
Did you like what you read? You can also follow me on Twitter for Kotlin and Android content.

Learn Kotlin Inline Functions in 3 Minutes

Trevor Nemanic — Mon, 25 Feb 2019 16:23:19 +0000

Kotlin allows functions to be passed and returned from other functions. This feature is called "first class" support for functions and brings in advantages of functional programming. To learn about inline, we will go over the hidden costs of functional programming, see how inline can help reduce those costs, then wrap up with places where it should not be used.

A higher-order function comes with run-time penalties. First, memory is allocated for lambdas as function parameters. They are compiled to either Function classes or anonymous classes, and both cost memory. Additionally, anonymous classes are slower than Function classes and used only when local variables are captured. Lastly, virtual calls add unnecessary cost.

The inline keyword was added to Kotlin to reduce the associated costs of higher-order functions. It modifies the Java bytecode by injecting the function and its parameters directly where the function is called, the call site. Using it is easy, just add inline before your function:

To see how inline impacts bytecode, consider two functionally equivalent higher-order functions, filter and filterNotInline. The former is part of the Kotlin standard library and the latter is a copy of it with inline removed.

Decompiling this code will show how inlining works under-the-hood. Also, it was compiled to JVM bytecode and decompiled to Java for readability. Since filter is inlined, its code is copied directly. Here's the call site at the first println statement.

The less efficient version requires overhead via a function call to filterNotInline, which contains code similar to the above.

Inlining is usually great for performance, but there are good reasons why functions are not inlined by default:

Using an inlined function increases code length because the function is copied to every call site. This is especially true for long functions.
Inlining applies to all lambda parameters of the inlined function. So, an inlined function with three lambdas as parameters will copy them all. You can use noinline on individual parameters to prevent copying.
Regular return statements are not allowed. You must use a label if you wish to return from your inlined function.
Inline functions do not have access to data less visible than themselves.

In addition to functions, properties can be inlined too! This can be done at the individual getter and setter or the entire property.

By now you should have an understanding of the benefits and tradeoffs of inline. Feel free to post any questions you have in the comments!
Did you like what you read? You can also follow me on Twitter for more Android content.