DEV Community: goobar

Kotlin vs Java for Android Development FAQ

Nate Ebel — Mon, 26 Apr 2021 12:00:00 +0000

Kotlin vs Java? Which language is best for Android development in 2021?

New Android developers want to know which language they should learn for building modern Android applications. Development teams want to be sure that Kotlin will not have a negative impact on their app’s performance, their ability to hire qualified engineers, or on their overall developer productivity.

To help inform your decisions, we’ve curated a list of some of the most frequently asked questions regarding Kotlin vs Java for Android development.

Frequently Asked Questions About Kotlin vs Java for Android Development

Which is better for Android development – Java or Kotlin?

Kotlin is the preferred language for Android development in 2021. Both Java and Kotlin can be used to build performant, useful applications, but Google’s libraries, tooling, documentation, and learning resources continue to embrace a Kotlin-first approach; making it the better language for Android today.

Does Google recommend Kotlin for Android development?

Yes. Google recommends developers start building Android applications with Kotlin, and has taken an increasingly Kotlin-first approach to modern Android development. Many Android Jetpack libraries have been either written completely in Kotlin, or support Kotlin language features such as coroutines.

When did Google start supporting Kotlin for Android?

Google announced official Android support for Kotlin at Google I/O in 2017.

When did Android become Kotlin-first?

Google adopted their current Kotlin-first approach to Android at Google I/O in 2019.

Is Java still used for Android development?

Yes. Absolutely. Java is still 100% supported by Google for Android development. The majority of Android apps today have some mix of both Java and Kotlin code. Developers can build the same functionality with Java as they can with Kotlin.

Will Android stop supporting Java?

It’s unlikely that Android will stop supporting Java any time soon. The Android SDK is still mostly written in Java. The majority of Android apps still include Java. The Android OS is built upon a Java Virtual Machine. To move away from Java completely would represent a monumental shift in the Android ecosystem.

Is Kotlin replacing Java?

No. Java will not be replaced completely by Kotlin. Java will likely continue to lose some marketshare to Kotlin within the Android ecosystem, but Java will remain one of the most used programming languages in the world.

While Java for Android continues to be constrained to Java version 8, beyond Android, Java is evolving quickly and adopting many features from other modern programming languages; including Kotlin.

Is Kotlin enough for Android development?

Yes. You can build Android applications using only Kotlin, and as documentation, tooling, and libraries become more Kotlin-focused, building apps exclusively with Kotlin will become even easier.

Should I learn Java or Kotlin for Android?

You should learn Kotlin first. If you have to pick between learning Java or Kotlin to start developing Android apps, you will have an easier time using current tools and learning resources if you know Kotlin.

If you already know Java, and want to focus on learning Android, then you could defer learning Kotlin in favor of focusing on the Android SDK.

Can I learn Kotlin without Knowing Java?

Yes. While knowing Java, or any programming language, will make it easier, Kotlin is a great first language thanks to things like static typing, type inference, and abundance of learning resources, and strong IDE support.

Is Kotlin easier than Java?

Many will find Kotlin easier to learn and write than Java. A number of things factor into this experience including Kotlin’s concise syntax, type inference, explicit nullability, and extensive standard library.

Can I get a job as an Android developer without knowing Kotlin?

Yes, but Kotlin is becoming an increasingly desirable skill for hiring managers looking for qualified developers. A LinkedIn search for “kotlin android developer” jobs turns up ~7,700 job postings while a search for “java android developer” returns ~7,800 results in the US. The relative number of postings is similaraly balanced in India with ~11,100 results for “java android developer” and ~11,000 for “kotlin android developer.“

As codebases, teams, libraries, and Google continue to move more towards Kotlin, expect Kotlin to become an even more important skillset for Android developer jobs.

Is Kotlin faster than Java?

No; although the true answer depends on what performance metrics you are interested in. At runtime, the performance of the languages is very similar. At compile time however, Kotlin is measurably slower than Java. The extent of the slowdown depends on a number of factors such as the usage of annotation processors, and the presence of mixed Java + Kotlin source sets

Where Can You Learn More About Kotlin and Android Development?

Check out our other posts on Kotlin and Android development here on goobar.

And you can find courses and tutorials on our YouTube channel.

The post Kotlin vs Java for Android Development appeared first on goobar.

Non-Coding Tips for Coding Interview Assignments

Nate Ebel — Tue, 20 Apr 2021 01:04:51 +0000

Unsurprisingly, when discussing take-home assignments for coding interviews, much of the focus is put on code. Can you code? Are you using “best practices?” What tools are you using?. There’s lots of code-related things that people think about, or even stress about.

Unfortunately, non-coding tips for coding interview assignments don’t get talked about nearly as much. And, in my experience, there are a lot of non-coding things we can do to put our best foot forward and impress a hiring committee with our take-home assignment.

Telling Your Story

What are these non-coding tips? If we’re completing a programming assignment, what else should we pay attention to?

Put yourself in the mindset of a reviewing engineer.

How will they experience your project?
How can you guide their experience?

How can you tell your story?

What do you want a reviewer to know about you after they review your code?
What interests, skillsets, workflows, or values do you want to highlight?

We want to help a reviewer get to know us – to understand what we can do. We want to think about giving reviewers reasons to be impressed by our projects and we want to do our best to limit head scratching moments.

Take-home assignments provide a unique opportunity to tell these stories because they are done asynchronously. During a take-home assignment, engineers are not typically under the watchful gaze of the hiring committee. We have a chance to be more natural; to think more clearly; and to take greater ownership of the impression we make.

Make a good first impression

Take-home assignments, as with many things, can really benefit from a positive first impression. If a reviewer starts exploring your assignment on a positive note, the rest of the review is likely to go better.

Using Project Metadata To Give Additional Context

If your project is using GitHub, git, or some other form of version control, then you have a great opportunity to showcase project information through various forms of “metadata” available to you.

If using git, your git history is a great way to highlight how you work.

If your project lives in GitHub, add relevant attribution. Give it a useful description. Add relevant topcis such as “android” or “kotlin” to give a quick overview of what the project is about. You might leverage GitHub Issues, PRs, and Milestones to give reviewers a sense of how you like to work and manage your tasks.

What can you add to your project to give helpful context to a reviewer? Don’t spend a lot of time here, but often a little bit of investment here can help give your project a more professional look.

Highlighting Information Using A Project README

Having a helpful project README in the root directory of your assignment submission is a terrific idea. A README the perfect place to document assumptions, outline your tasks, or add screenshots or video of the project.

Imagine yourself sitting down to present your project to a reviewer. Where would you start? What information would you want to highlight right away? Think of your README as this overview.

Use the README to guide the efforts of a reviewer. Call out interesting functionality. Call out tools and libraries that were used.

Use it to tell your story; whatever that may be.

Guiding Reviewers With Clear Project Organization

The last item to a great first impression is clear project organization. In most cases, I suggest you organize your project by “feature”, or by “layer”. You want your reviewer to be able to navigate your project easily.

You also want to demonstrate that your organization would scale to real-world, production projects. Putting all your files in a single directory might work for a small take-home assignment, but wouldn’t be a great choice for a large application.

Not sure if your project will be easy to navigate? Try navigating the project without your IDE. You might explore the project in GitHub or from your file browser. If it’s easy to navigate without an IDE’s search and class-lookup functions, then you should be good to go.

First Time User Experience

At some point, a reviewer is most likely going to run your code. What will that first-time-user experience be? A focus on two main things can really have a large impact on how a reviewer feels about your project.

Ensuring A Functional Experience

Make sure your app doesn’t crash when a reviewer installs it. You don’t want your app to crash at all, but it’s especially important that it doesn’t crash on startup. A crash on startup means a reviewer may not be able to evaluate the functionality – this does not usually lead to a great assignment review.

If you have the time, test your app startup across a few different device configurations. Maybe 2-3 different OS versions, and a couple of different screen sizes. If your app starts up, and is functional, across these configurations there’s a good chance your assignment reviewers will also be able to successfully start using your app.

Impressing With UI Polish

Once your app is started, what is the first thing a reviewer sees? If your main screen leaves a positive first impression, it can go a long way towards creating a positive feeling towards the project as a whole.

How can you leave a good impression? A little bit of design polish goes a long way. A few design items that are not time consuming, but really help the look/feel of your app:

A unique, visually appealing, color palette.
- The Material Design Color Tools is a great resource for this
Consistent spacing
- Using the Material Design 8dp grid is a great way to go
- Define a couple of dimension resources and use them throughout your layouts for a more professional look
Touch feedback
- Add a ripple effect when touching views is a nice UI addition
- This can be accomplished with very little effort and again goes a long way towards a more professional look
Don’t reinvent the wheel
- If you’re not sure how to structure the UI/Navigation in your app, look to existing apps for inspiration
- If your “weather app” assignment behaves like an existing app, it’ll likely make it easier to use for a reviewer, and that can often lead to a better overview impression
Adaptive design
- Ideally, your app’s UI would adapt to different screen sizes/configurations
- If your app doesn’t work well on small screens, or in horizontal layouts, call that out in your README or elsewhere.

What does your code say about you?

The way in which you write your code, whether it’s functional or not, can say a lot about how you operate as an engineer.

Leveraging Consistency To Improve The Review Experience

A big part of being a professional software developer is reviewing code. Code is easier to read and review if it uses consistent styling and conventions. This is true whether in a produciton codebase, or a take-home assignment.

Before you submit you project, run a code formatter on the code to ensure you are using a consistent style.

Building On A Solid Foundation

It’s great to highlight fancy libraries, or to build flashy features into your project. However, if they come at the expense of the fundamentals, they might actually hurt you more than help.

For example, if building an Android app, it’s considered best practice to define user-facing strings as String resources in a strings.xml file. Hardcoding all of your strings might be a red flag to reviewers.

If your project requires special permissions, and you don’t build a permissions workflow into the app, it could reflect poorly on your submission. Or if you place all of your code into a single, large class – it might reflect poorly on your submission.

The moral here is that well organize, well structured code that doesn’t miss on the basics is likely going to be better off than a project that uses the “new shiny” library but is built on a shaky foundation.

Documentation

Software developers often joke about their lack of documentation, or argue about whether good code even needs documentation. However, in an interview situation, good documentation is without a doubt a helpful tool.

Take home assignments are often about tradeoffs. You usually have a set number of tasks to complete with a limited amount of time in which to carry out the assignment. Tradeoffs must be made to balance completing the assignment with writing our ideal solutions.

Use documentation to detail those tradeoffs and to simulate the discussions that would come up during a typical work situation.

Documenting Your Decision Making

What assumptions did you make about the specified requirements? What questions did you have, and how did you answer them?

Why did you choose Library X over Library Y? Why did you choose Architecture A rather than Architecture B?

All of these types of decisions are opportunities do document and share your thinking.

You can go further than that as well. You could include more narrative documentation about areas you chose to focus on, and why? Why did you add unit tests? Why did you add a CI workflow? How did you come up with your custom color palette? These are all interesting notes that you can document and share with reviewer to give a sense of how you work.

And lastly, be sure to document anything that isn’t work – or isn’t working as specified.

Was your weather app supposed to show precipitation, but the api you chose only offers that data if you pay? Document that limitation so its absence doesn’t seem like an oversight.

Does your app crash when rotated? Call that out in the notes so it’s clear that you found and understand the issue. You might even get bonus points for including a suggested fix.

With most reviewers, you’re not going to lose points for transparency. Being upfront about what is, and isn’t, working builds trust – and trust is a very important part of choosing to work with someone.

Choosing Documentation Formats

Your documentation can come in a variety of forms. You might find that a mix of documentation formats is ideal for you, or you might focus on one above the rest. While I do highly suggest having a README, choose the documentation option(s) that work best for you.

A few documentation examples include:

A README in your project’s root directory
Code comments
GitHub Issues, Pull Requests, Milestones
A wiki in your repository
Architectural Decision Records
A recorded video of you walking through the project

Make It Your Own

Take-home assignments typically have a concrete set of requirements; usually a set of tasks to complete and specific functionally that must be present. That doesn’t mean that those tasks are the only things we can work on.

Telling Your Story By Customizing Your Submission

As mentioned earlier in this post, think about the story you want to tell to a reviewer. What do you enjoy working on? What is your “genius zone?” And how can you highlight those things in your submission?

Do you enjoy working with CI infrastructure? You could setup a simple CI workflow for your project and maybe include a small writeup on your preferred CI architecture.

Maybe you really enjoy bringing to life beautiful designs? You could add a unique animation or user interaction. A custom loading indicator or “empty state” screen are great opportunities for this.

Do you really believe in Test Driven Development? Write some tests for the project and include a summary of your testing philosophy.

These additions don’t have to be massive time investments, and honestly they probably shouldn’t be because we need to make sure the core functionality is there. But, an additional feature, test, or other custom element can be a really valuable way to highlight how you would be a uniquely valuable asset to any team.

Leveraging Non-Coding Tips For Your Next Coding Interview Assignment

Next time you have a coding interview assignment, don’t forget about these non-coding tips. Remember to put your best foot forward by:

Making a positive first impression
Ensuring a stable and pleasing first-time-user experience
Writing consistent, readable code
Documenting your code and decision making process
Making the project your own

If you can do these things, and complete the required assignment tasks, you will have gone a long ways towards helping yourself get that next job!

Where To Learn More?

Watch on our YouTube channel.

The post Non-Coding Tips for Coding Interview Assignments appeared first on goobar.

Benchmarking Gradle Builds Using Gradle-Profiler

Nate Ebel — Thu, 12 Nov 2020 17:38:59 +0000

In this post, we’re going to take an introductory look at benchmarking Gradle build performance using the gradle-profiler tool.

By the end, you should have a basic understanding of how to use gradle-profiler to gain better insights into the performance of your Gradle build and how you might use those insights to improve Gradle build performance for your project.

What is the Gradle-Profiler Tool?

The gradle-profiler project describes itself in the following way:

“A tool to automate the gathering of profiling and benchmarking information for Gradle builds.”

What does that mean to you and your project?

Imagine you want to get a sense of how fast your Gradle build is.

You might run your target Gradle task, wait for the build to complete, and take that build time as your result.

Now, because build times are often variable, you may want to run your Gradle task multiple times and average the execution times. So, you kick off your build, wait for it to finish, write down the total execution time, and repeat the process.

This process of manually benchmarking your Gradle build will likely take a while. Depending on how long your build takes to complete, and how many interactions you want to run, you could find yourself repeatedly coming back to your computer to check whether it’s time to start the next build or not. Even if you stay busy with other things, this is still a drawn out, tedious process that relies on you, as the developer, manually recording build statistics for each iteration.

It’s this process that gradle-profiler aims to automate for you.

Rather than you having to manually kick off each build and recording the resulting build statistics, gradle-profiler allows devs to start a single command which will repeatedly run a specified Gradle task and record all the build stats in an easy to examine output format.

This takes Gradle build benchmarking from a tedious, manual task to something that can be highly automated with little need for human interaction or monitoring.

I’ve been using gradle-profiler recently in an effort to keep my primary project’s build times low, and to examine the build impact of proposed changes. In this post, we’re going to walk through how you can start using gradle-profiler to gather benchmark data for your Gradle build, and how you may start using that data to understand the impact of changes on your project.

Installing Gradle-Profiler

Before you can start benchmarking Gradle build performance, you’ll need to install gradle-profiler to your development machine.

You can do this in one of several ways

Install From Source

You could clone the git repository to your local machine, and build the project from source.

→ git clone git@github.com:gradle/gradle-profiler.git
→ cd gradle-profiler
→ ./gradlew installDist

You would likely then want to add gradle-profiler/build/install/gradle-profiler/bin to your path or create some kind of alias that enables you to invoke the tool by executing the gradle-profiler command.

Install With Homebrew

If you are using Homebrew on your machine, installation is quite simple.

→ brew install gradle-profiler

Other Installation Options

If building from source, or installing using Homebrew, aren’t good options for you, you could try either of the following installation methods:

Examples On GitHub

You can find example commands and example benchmark scenarios in my sample repo on GitHub.

Find The Code

Benchmarking Your Gradle Build

Now that gradle-profiler is installed, and the gradle-profiler command is available to us, let’s start benchmarking Gradle build performance for your project.

Running the Benchmarking Tool

To generate benchmarking results for our project, we need two things:

The path to the project directory containing the Gradle project
A Gradle task to run

With these, we can start benchmarking our build like this:

→ cd <project directory>→ gradle-profiler --benchmark --project-dir . assemble

Let’s break down this command into its individual parts.

gradle-profiler – invokes the gradle-profiler tool
--benchmark – indicates that we want to benchmark our build
--project-dir . – indicates that the Gradle project is located within the current working directory
assemble – this is the Gradle task to benchmark

When this command is run, the benchmarking tool will begin. You should see output in your console indicating that warm-up and measured builds are running.

When all the builds are completed, two benchmarking artifacts should be created for you:

benchmark.csv – provides benchmarking data in a simple .csv format
benchmark.html – provides an interactive webpage report based on the .csv data

The output paths should look something like this:

Results written to /Users/n8ebel/Projects/GradleProfilerSandbox/profile-out
/Users/n8ebel/Projects/GradleProfilerSandbox/profile-out/benchmark.csv
/Users/n8ebel/Projects/GradleProfilerSandbox/profile-out/benchmark.html

Understanding Benchmarking Results

Once your outputs are generated, you can use them to explore the benchmarking results.

Interpreting .csv results

Here’s a sample benchmark.csv output generated by benchmarking the assemble task for a new Android Studio project.

CSV benchmark results for assemble task

This report is very streamlined and highlights only a few things. The most interesting data points are likely:

Which version of Gradle was used
Which Gradle tasks were run
The task execution time, in milliseconds, for the warm-up and measured builds

Notice that the first warm-up build took significantly longer than every other build? Is this a problem? Is something wrong with your project’s configuration?

By default, gradle-profiler uses a warm Gradle daemon when measuring build times. If you’re not familiar, the Gradle daemon runs in the background to avoid repeatedly paying JVM startup costs. It can drastically improve the performance of your Gradle builds.

So, for this first warm-up build, task execution time is much longer as the daemon is started. After that, you can see that subsequent builds are much faster.

If we ignore the warm-up builds, and look only at the set of measured builds, we see that the build times are consistently fast as one might expect for a new project.

Interpreting HTML results

In addition to being an interactive webpage, the benchmarking.html results provide more data than the .csv file. By viewing the results this way, you’ll have access to:

Mean, Median, StdDev, and other statistics from the measured build results
Gradle argument details
JVM argument details
And more…

HTML benchmark results for assemble task

The HTML results provide a graph of each warm-up and measured build to help you visually understand performance over time.

If you aren’t interested in automating the analysis of your benchmarking results, then viewing the HTML results is often the most convenient way to quickly understand how long your build takes, and to quickly see if there are any outlier executions to examine.

This HTML view becomes even more useful when benchmarking multiple scenarios at the same time as we’ll see later on.

Detecting Gradle Performance Issues

Now that we have some understanding of the output generated by gradle-profiler benchmarking, let’s explore how we might begin to use that benchmark data to compare the performance of our Gradle builds.

The simplest approach is generally as follows:

Collect benchmarking data for your current/default Gradle configuration
Change your Gradle configuration
Collect benchmarking data for updated configuration
Compare the results

We could use this approach to compare the impact of caching on a build. We might compare the performance of clean builds versus incremental builds.

Any tweak to our build settings or project structure could be examined through this type of comparison.

Comparing clean and up-to-date build performance

Let’s walk through a quick example of this kind of analysis using gradle-profiler. We’re going to compare the impact of an up-to-date build over a clean build.

First we’ll benchmark up-to-date builds of our assemble task and collect the results.

→ gradle-profiler --benchmark --project-dir . assemble

We’re referring this as the up-to-date scenario because after the first execution of the assmble task, each task should be up-to-date and subsequent builds should be extremely fast as there is nothing to rebuild.

Next, we’ll benchmark our clean build.

→ gradle-profiler --benchmark --project-dir . clean assemble

In the clean build scenario, we are discarded previous outputs before executing our assemble task, so we should expect the clean build to take longer than the up-to-date build.

Once we’ve generated both sets of output, we can compare the benchmarked performance. I’ve taken the .csv results from each of those benchmarking executions and combined them into the following table for comparison.

With this, we can see that our up-to-date build takes ~1 second while our clean build is taking ~7 seconds. This seems in line with expectations about the relative performance of these two build types.

Comparing caching impact

We’ve seen the performance of an up-to-date build. We’ve seen the impact of doing a clean build.

Let’s expand on our example by now benchmarking the impact of enabling Gradle’s local build cache.

First, we’ll once again benchmark a clean build without enabling the build cache.

→ gradle-profiler --benchmark --project-dir . clean assemble

Next, we’ll enable Gradle’s local build cache by adding the following to our gradle.properties file:

_org.gradle.caching_=true

Now, we can re-run our clean build benchmark scenario; this time with the cache enabled.

→ gradle-profiler --benchmark --project-dir . clean assemble

Once again, we can compare results to get a sense of how enabling the local Gradle build cache can benefit build performance.

No Caching		Caching
scenario	default	scenario	default
version	Gradle 6.7	version	Gradle 6.7
tasks	clean assemble	tasks	clean assemble
value	execution	value	execution
warm-up build #1	26492	warm-up build #1	24568
warm-up build #2	10345	warm-up build #2	6838
warm-up build #3	9853	warm-up build #3	4901
warm-up build #4	8757	warm-up build #4	5145
warm-up build #5	8705	warm-up build #5	4382
warm-up build #6	7377	warm-up build #6	5309
measured build #1	7268	measured build #1	4825
measured build #2	7378	measured build #2	4674
measured build #3	7750	measured build #3	4428
measured build #4	6707	measured build #4	4577
measured build #5	6635	measured build #5	4053
measured build #6	7542	measured build #6	4236
measured build #7	7066	measured build #7	4388
measured build #8	6398	measured build #8	4131
measured build #9	6341	measured build #9	5818
measured build #10	7416	measured build #10	4016

Merged CSV results comparing the build speed impact of enabling the Gradle build cache

From these results, we see that enabling local caching seems to improve the performance of clean builds from ~7 seconds to ~4.5 seconds.

Now, these build times are artificially fast as it’s a simple project.

However, this approach is applicable to your real-world projects, and these general results are what one might expect from a well-configured project; up-to-date < clean with caching < clean w/out caching.

Configuring Benchmarking Behavior

When running these benchmarking tasks, you may find yourself wanting greater control over how benchmarking is carried out. A few of the common configuration properties you may find yourself needing to change include

changing the project directory
modifying the output directory
updating the number of build iterations

We’re going to quickly examine how you can update these properties when executing your benchmarking task.

Changing Project Directory

Throughout these examples, we’ve been operating as if we are running gradle-profiler from within the project directory.

Here, we see that after the --project-dir flag, we pass . to signify the current directory.

→ gradle-profiler --benchmark --project-dir . assemble

If we want to run gradle-profiler from any other directory, we are free to do that. We just need to update the path to the project directory.

In this updated example, we change directories into our user directory, and pass Projects/GradleProfilerSandbox as the path to our project directory.

→ cd
→ gradle-profiler --benchmark --project-dir Projects/GradleProfilerSandbox/ clean assemble

Changing Output Directory

When gradle-profiler is run, by default, it will store output artifacts in the current directory. If you would prefer to specify a different output directory, you can do so using --output-dir.

gradle-profiler --benchmark --project-dir Projects/GradleProfilerSandbox/ --output-dir Projects/benchmarking/ clean assemble

This may come in handy if you want to automate the running of benchmarking tasks and would like to keep all your outputs collected within a specific working directory.

Controlling Build Warm-Ups and Iterations

Another pair of useful configuration options are --warmups and --iterations. These two flags allow you to control how many warm-up builds and measured builds to run.

This might be useful to you if you want to receive your results more quickly, or if you want more data points, and hopefully greater confidence, if your benchmarking results.

If we wanted to have 10 warm-up builds and 15 measured builds, we can start our benchmarking task like this.

→ gradle-profiler --benchmark --project-dir . --warmups 10 --iterations 15 assemble

Benchmarking Complex Gradle Builds

We’ve really only scratched the surface of what gradle-profiler is capable of. Real world build scenarios are varied, and often quite complex. Ideally, we’d be able to capture these complexities, and benchmark Gradle build performance for these real-world conditions.

Let’s take a look at how we can define benchmark scenarios that give greater control and flexibility into what is benchmarked.

Defining a Benchmark Scenario

As our command line inputs become more complex, it may become difficult to manage.

Look at the following command.

gradle-profiler --benchmark --project-dir Projects/GradleProfilerSandbox/ --output-dir Projects/benchmarking/ --warmups10 --iterations 15 clean assemble

This command is still executing a fairly simple benchmarking task, but has already become quite long and unwieldily to execute from the command line every time.

This is especially true if we want to start benchmarking multiple build types, or want to simulate complex incremental build changes.

To help define complex build scenarios, the gradle-profiler tool provides a mechanism for encapsulating all of the configuration for a build scenario into a .scenarios file. This helps us organize our scenarios in a single place and makes it easier to benchmarking multiple scenarios.

To define a simple .scenarios file, we’ll do the following.

First, we’ll create a new file named benchmarking.scenarios.
Next, we’ll define a scenario for our up-to-date assemble task.

assemble_no_op {
  tasks = ["assemble"]
}

In this small configuration block, we’ve defined a scenario named assemble_no_op that will run the assemble task when executed. We’ve used the “no op” suffix on the scenario name because this will test our up-to-date build in which tasks shouldn’t have to be re-run each time.

Benchmarking With a Scenarios File

With our scenario file defined, we can benchmark this scenario by using the --scenario-file flag.

gradle-profiler --benchmark --project-dir . --scenario-file benchmarking.scenarios

From this, we get an HTML output similar to this.

HTML output from running the assemble_no_op benchmark scenario

We can see that the assemble_no_op name used to define our scenario is automatically used as the scenario name in the output.

In the next sections, we’ll see how to changes this to something more human-readable and why this can be important.

Configuring Build Scenarios

Within our .scenarios file, there are quite a few configuration options we can use to control our benchmarked scenarios.

We can provide a human-readable title for our scenario:

assemble_no_op {
  title = "Up-To-Date Assemble"
  tasks = ["assemble"]
}

We can provide multiple Gradle tasks to run:

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
}

You could pass in different Gradle build flags such as for parallel execution or for the build cache:

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
  gradle-args = ["--parallel"]
}

We can also explicitly define the number of warm-ups and iterations so they don’t have to be passed from the command line:

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
  gradle-args = ["--parallel"]
  warm-ups = 3
  iterations = 5
}

This is not an exhaustive list of scenario configurations. You can find more examples in the gradle-profiler documentation.

Benchmarking Multiple Build Scenarios

One of the primary benefits of using a .scenarios file is that we can define multiple scenarios within a single file, and benchmark multiple scenarios at the same time.

For example, we could compare our up-to-date, clean, clean w/caching builds from a single benchmarking execution, and receive a single set of output reports comparing all of them.

To do this, we first define each of our unique build scenarios within our benchmarking.scenarios file.

assemble_clean {
  title = "Clean Assemble"
  tasks = ["clean", "assemble"]
}

assemble_clean_caching {
  title = "Clean Assemble w/ Caching"
  tasks = ["clean", "assemble"]
  gradle-args = ["--build-cache"]
}

assemble_no_op {
  title = "Up-To-Date Assemble"
  tasks = ["assemble"]
}

Then we continue to invoke gradle-profiler in the same way; by specifying the single .scenarios file.

gradle-profiler --benchmark --project-dir . --scenario-file benchmarking.scenarios

From this, we will receive a merge report that compares the performance of each scenario.

HTML output for multiple build scenarios

Scenarios will be run in alphabetical order based on the name used in the scenario definition; not the human-readable title.

When viewing a report with multiple scenarios, you can select a scenario as the baseline. This will update the report to display a +/-% on each build metric where the +/-% is the statistical difference between the current scenario and the baseline scenario.

What does that look like in practice?

In this example, we’ve selected the clean build w/out caching scenario as our baseline.

HTML output for multiple build scenarios with a selected baseline

With the baseline set, we see that the mean build time was reduced ~4% for the clean build with caching scenario and ~80% for the up-to-date build scenario.

By setting a baseline, you let the tool do all the statistical analysis for you leaving you free to interpret and share the results.

Benchmarking Incremental Gradle Builds

The last concept we’re going to touch on is that of benchmarking incremental builds. These are builds in which we need to re-execute a subset of tasks because of file changes. These files could change due to source file changes, resource updates, etc.

Incremental scenarios can be very important for real-world benchmarking of Gradle build performance, because in our day-to-day work, we’re often performing incremental builds as we make a small code change, and redeploy for testing.

When using gradle-profiler we have quite a few options available to us for defining and benchmarking incremental build scenarios.

If building with Kotlin or Java, we might be interested in:

apply-abi-change-to
apply-non-abi-change-to

If building an Android application, we might use:

apply-android-resource-change-to
apply-android-resource-value-change-to
apply-android-manifest-change-to
apply-android-layout-change-to

With these options, and others, we can simulate different types of changes to our projects to benchmark real world scenarios.

Here, we’ve defined a new incremental scenario in our benchmarking.scenarios file.

incremental_build {
  title = "Incremental Assemble w/ Caching"
  tasks = ["assemble"]

  apply-abi-change-to = "app/src/main/java/com/goobar/gradleprofilersandbox/MainActivity.kt"
  apply-android-resource-change-to = "app/src/main/res/values/strings.xml"
  apply-android-resource-value-change-to = "app/src/main/res/values/strings.xml"
}

This scenario will measure the impact of changing one Kotlin file, and of adding and modifying string resource values.

The resulting benchmark results look something like this.

HTML benchmark results including incremental build scenario

As expected, the incremental build was measured to be faster than a clean build, but slower than an up-to-date build.

This is a very simple example. For your production project, you might define multiple different incremental build scenarios.

If you’re working in a multi-module project, you might want to measure the incremental build impact of changing a single module versus multiple modules. You might want to measure the impact of changing a public api versus changing implementation details of a module. There are many things you may want to measure in order to improve the real world performance of your build.

What’s Next?

At this point, hopefully you have a better understanding of benchmarking Gradle build performance using gradle-profiler, and how to start using gradle-profiler to improve the performance of your Gradle builds.

There’s still more that can be done with gradle-profiler to make it more effective for detecting build regressions and to make it easier to use for everyone on your team.

I’ll be exploring those ideas in upcoming posts.

If you’d like to start learning more today, be sure to check out gradle-profiler on GitHub and Tony Robalik’s post on Benchmarking builds with Gradle-Profiler.

You can find more Gradle-related posts here on my blog.

The post Benchmarking Gradle Builds Using Gradle-Profiler appeared first on goobar.

Understanding, Profiling, and Optimizing Gradle In Android Builds

Nate Ebel — Mon, 26 Oct 2020 16:05:46 +0000

If you’ve spent any time as an Android developer you’ve probably experienced some level of frustration with Gradle in Android builds.

I’m no exception to this rule. I’ve often enjoyed a laugh at Gradle’s expense, or laughed and nodded along as coworkers shared their own harrowing stories of lengthy or broken builds.

However, I also think much of this frustration and complaint is unwarranted, or at the very least, misplaced. The Android build toolchain has a number of unique components and I often find others, and myself, blaming Gradle for something that might not actually be Gradle’s fault at all.

So this week, I want to pull back the curtain, and share a bit about Gradle and how it relates to our Android builds.

How Does Gradle Relate To Your Android Project?

Let’s start at beginning.

What is Gradle?

Gradle is a build tool capable of building software projects across a variety of different languages and domains.

Gradle projects are configured using a Groovy-based DSL (Domain Specific Language). Groovy, itself, is a multi-purpose programming language for the Java Virtual Machine (JVM).

How then do these both work together to build our Android apps?

What Are The Individual Components Of An Android Build?

To build our Android apps using Gradle, we rely on another important component; the Android Gradle Plugin.

The Android Gradle Plugin builds upon the generic concept of Gradle plugins to support the Android build requirements. Custom Gradle tasks, and build configuration options are provided by the Android Gradle Plugin to control how an Android application is built.

Android Gradle Plugin (AGP) is not directly tied to Android Studio, though they do often have a close connection. As new features are added to the plugin, Android Studio is generally updated to take advantage of those features to provide a better developer experience.

How Is Your Android Gradle Project Structured?

A Gradle project is comprised of one, or many, modules. A module may consist of any combination of source code, resources, assets, and build configuration.

Your Android project configuration is comprised of several different files:

a top-level settings.gradle file to indicates which individual Gradle modules should be loaded
a top-level build.gradle file that can be used to declare project-level dependencies, plugins, and other configuration
one, or many, module-level build.gradle files that define how each individual module and built and how they relate to one another

If you create a new project in Android Studio, you generally have a single :app module created.

How do these build components work to build your app?

How do all of these pieces work together to actually build your Android app?

Your project, and each module, use the Groovy language and Gradle DSL to control how they should be built.

Any of these projects that need to know about the Android framework will use the Android Gradle Plugin to configure Android-specific build options such as minSdk, buildTypes, lintOptions, etc.

This is easily recognized by applying the plugin to a build.gradle file

plugins {
  id 'com.android.application'
}

and by modifying the Android configuration block

android {
  compileSdkVersion 30
  buildToolsVersion "30.0.1"
  ...
}

All of these build.gradle files will work together to define which tasks should be generated and run. Each Gradle task is responsible for one small piece of the project compilation and packaging process.

To see a list of all Gradle tasks available for your Project, you have two options:

Run ./gradlew tasks from the command line
Open the Gradle tool window within Android Studio or IntelliJ

Once all tasks are defined and configured, the general Gradle build tool will process the build files, generate any needed tasks, and ultimately execute each task.

Most Gradle plugins use enhanced tasks which means they contain all the behavior needed to perform their desired action. Enhanced tasks also are responsible for declaring needed inputs and outputs.

You can think of a Gradle task as a function that takes in a set of inputs, and generates a specific output. The work executed could be processing a file, merging resources, uploading an .apk to Firebase, or any number of other actions.

Once these tasks finish executing, the Gradle build is complete.

What Are The Pain Points Of Gradle In Android Builds?

I hear, and have experienced, several common complaints about different parts of this build process.

Defining build logic

Many people feel it’s too difficult to define, or customize, build logic. Gradle often gets blamed for this, when in reality, it’s like Groovy that developers are unfamiliar with.

Because Groovy can be both dynamically, and statically, typed, it can feel very foreign if you’re not expecting dynamic typing. How do I define a variable to determine whether we’re building on CI or not? How to I loop over a collection of build variants? Lack of robust auto-completion can leave developers feeling lost when trying to define custom build logic.

To help with this, you may benefit from learning more about Groovy as a language. The language syntax guide may be a good starting point for you.

Additionally, improvements to Gradle and Android Studio have made it possible to define your Gradle build logic using statically typed Kotlin, rather than Groovy. If you miss static typing and Kotlin language features when defining your build logic, read more about how to start using the Gradle Kotlin DSL.

Exploring the Android Gradle Plugin

Another big Gradle-related frustration for Android devs is that they don’t know what configuration options are available. What flags are available to control how a project is built? How do you work with Android-specific facets of the build during the Gradle build process.

To help answer these questions, it be be useful to read through api reference docs for the Android Gradle Plugin. This gives detailed documentation on what configuration blocks, and types can be used to control your build.

For example, if you were looking for more information on how to control Android Lint tasks, you could reference the lintOptions { } configuration block.

Other configuration blocks include

Working with annotation processors

One of the most common, and serious, build issues Android developers may face is that of slow builds.

There are lots of reasons your build may be slow; and we’ll look at some tools for detecting and fixing these issues. One of the most common culprits of a slow build are annotation processors. Tools like Dagger or Android DataBinding rely on annotation processors to generate code at compile time. This saves code and the cost of slower builds. This issue is particularly bad when using annotation processors in Kotlin projects.

To help with this, take a look at the Annotation Processing with Kotlin guide. In it, you’ll find several tips for ensuring your build is better optimized for annotation processing.

Profiling Gradle In Android Builds

As you start to further understand your Gradle build, you’ll likely want to profile it to really dig in and see which parts of your build are taking the most time.

The go-to tool for this are Gradle build scans. A build scan provides deep insights into your gradle build including, which tasks were executed, which tasks were pulled from local and remote caches, and which tasks are taking the most time.

To generate a build scan for any Gradle build, you can add the –scan build flag after the invocation.

Once the task finishes, you’re receive a link to a report like the following.

A sample build scan

Open the report into a web browser, and you’ll be able to explore every facet of your build, and can use this information to start optimizing your build.

If your team is using Gradle Enterprise, you’re likely already familiar with using Gradle build scans. To get the most out of these scans, it’s helpful to make them easily discoverable for everyone on your team. I recently shared about how we surfaced Gradle build scans within our GitHub Actions workflows.

For more on Gradle build scans, you can follow this guide.

Benchmarking Gradle In Android Builds

As you start profiling your build, you may identify avenues of possible improvement. When making changes to your build. it can be useful to benchmark current, and updated, build performance to know whether your changes are actually impacting your build.

To do this, you can turn to the gradle-profiler tool.

Gradle-profiler helps you automate the repeated testing, and data collection, needed to really understand build performance.

Imagine running 10 Gradle builds in a row, collecting the build times, and performing statistical analysis on those build times. That’s effectively what gradle-profiler provides.

With gradle-profiler you can benchmark a single simple task, a complex build scenario, or even a suite of build scenarios.

These benchmarks can also be run against different branches of your app. This can allow you to compare the benchmark performance of any given branch to that of your default branch; ideally detecting build regressions before they’re ever checked in.

For a great overview of using gradle-profiler check this post from Tony Robalik.

Optimizing Your Gradle Build

Finally, once you’ve profiled your build, and once you know how to benchmark the impact of any build changes, you’re going to want to start optimizing performance to have the fastest, most efficient build possible. This can save your team both time and money.

Enabling performance settings

There are several build properties that can be set to help provide quick build performance wins:

org.gradle.parallel=true
org.gradle.vfs.watch=true
org.gradle.caching=true

By setting the parallel flag, you enable your project to build multiple tasks at the same time, as long as they are in different modules. If you have a multi-module setup, this can be a great performance win.

The vfs.watch flag enables the new filesystem watching feature of Gradle which monitors information about which files are changing to improve incremental build times.

Gradle build cache

The caching flag is one of the biggest performance changes you can make. Gradle has two different build cache types: local and remote.

Setting the caching flag will enable the local build cache.

With caching enabled, the outputs of Gradle tasks are saved to the cache and reused for future builds. This can dramatically speed up clean and incremental builds.

Similarly, you can enable a remove build cache that moves this concept to a remote server. You might configure your CI server to push task outputs to the remote cache which can then be reused by everyone on your team, and by future CI builds.

Browse the Gradle Build Cache guide for more information on enabling caching for you project. Additionally, there’s a great webinar from Gradle on how to get the most out of the Gradle build cache. I highly recommend watching that to learn more on profiling and optimizing your Gradle build.

JVM memory settings

You may also want to update your JVM memory settings to provide Gradle/JVM more memory when building your app.

org.gradle.jvmargs=Xmx2g

Build performance plugins

There are also two really useful plugins I can recommend for helping you fix and monitor Gradle build issues.

First, the Gradle-Doctor plugin helps you diagnose common issues such as mismatched JDK versions and negative remote build cache savings. If building an Android app, gradle-doctor can also help you understand how much time is spent by Dagger annotation processing.

Second is the Android Cache Fix Gradle Plugin. This is a must-try plugin for Android projects.

It provides workarounds for Gradle build issues present in the Android Gradle Plugin. Most noticeably, it helps fix cache misses due to these issues with AGP. In a well configured Gradle build, fixing cache misses can have a massive positive impact on your build times.

Integrate this plugin, re-run your benchmark scenarios, and you’ll hopefully see nice positive improvements to your build times.

Android builds are complex, with multiple languages, tools, and plugins to consider. As we spend so much of our time waiting for code to compile, or CI builds to run, it’s in the best interest of ourselves, our teams, and our organizations if our builds are fast and efficient.

I think the best way to start improving the efficiency of our builds is to better understand our build tools and the overall build process.

Hopefully, this has helped you better understand some of these individual build components, and helped point you to resources to help you further your understanding of the Android build process.

The post Understanding, Profiling, and Optimizing Gradle In Android Builds appeared first on goobar.

Remote Work in 2020 is Not Normal – Will We Evaluate It Fairly?

Nate Ebel — Mon, 19 Oct 2020 12:30:00 +0000

How are you feeling about working from home right now?

As I look around the internet, it appears to me that results are mixed. Many are loving the new remote work lifestyle. Many others are stressed, working more hours, and feeling pressure to maintain productivity while working from home.

I don’t believe either of these groups are right or wrong. Everyone’s situation is unique.

One thing I do believe strongly though;

Working from home right now, during a global pandemic, is NOT the same thing as “remote work”.

I feel that this is getting lost in too many discussions lately.

This is not a normal year

With large companies like Google, Facebook, and Microsoft continuing to adopt more permanent remote-work policies, it looks as if remote work is poised to stick around for a while.

I don’t think remote work is right from everyone. It’s not, and it doesn’t need to be.

But I also don’t think the current realities of working from home are an accurate, or fair, representation of what a remote work culture can be.

According to Buffer’s State of Remote Survey, remote employees largely want to stay remote. However, if 2020 is your first foray into remote work, I wonder if that is still the case.

We’re extra stressed right now.

There are more distractions throughout the day; kids learning from home; extra deliveries; partners also working from home; etc

We can’t really get out of the house to work.

We can’t meet up with others to work, chat, brainstorm, collaborate.

On top of all of that, it seems many companies haven’t actually shifted to a remote-first mindset.

All-day meetings are even more draining right now. Employees are feeling pushed to work nights and weekends. Defaulting to real-time communication adds to the pressure of being always at a keyboard; even when that’s at odds with the realities of being at home.

In short, translating the on-site work experience to the home is challenging, and in many ways, just doesn’t really work. This leaves employees feeling overwhelmed, less creative, more isolated, and longing for a return to work-normalcy.

All in all, there are currently many things which are very atypical of enjoyable, and successful, remote work.

I worry that during this big initial push into remote work, let’s call it v1, that the evaluation by organizations/managers/individuals will fail to take into account everything else going on right now. I fear that this will keep many from getting to remote work v2 in which there are hopefully fewer abnormal circumstances and more of the traditional benefits of a remote work culture.

What does remote work usually look like?

Are you getting your first taste or remote work here in 2020, and it’s not what you thought it would be?

I can relate.

I’ve been remote for 4+ years now, and this year has still been unusual. It has not been the same remote work situation that I’m accustomed to, or that I enjoy so much.

How does remote work usually look?

For me, remote work has generally been filled with far more connection, flexibility, and variety than it has here in 2020.

I miss getting out of my home to work from a coffee shop, or library, or a co-working space.

I miss being able to change locations when the home is too loud; or too distracting.

I miss meeting with local co-workers or friends to chat, work, brainstorm, plan, organize, etc…

The lack of 1 on 1 chats, meetups, and conferences has me feeling disconnected, isolated, and uninspired.

In the past, I’ve been able to travel and meet my remote team in person. This builds trust, improves communication, and leads to a better working relationship. In 2020, I haven’t even been able to meet remote teammates living in the same city; let alone the ones from all over the world.

Speaking of travel, it’s difficult right now to get away and recharge in the same way we used to. Even just going outside for a relaxing walk is not as simple or relaxing as it used to be. This has accumulated over the year; myself and others are starting to feel the fatigue of our current situations.

None of these things matches my previous experiences with remote work.

What’s the future of remote work?

I don’t expect all companies to shift to remote-first work; not all can or should. And I know that my experience with remote work may be very different than yours.

If you don’t want to work remotely, there’s absolutely nothing wrong with that.

But if you thought you might like remote work, and aren’t enjoying it here in 2020, I hope some of this resonates with you and maybe gives you hope that your remote work dreams are still possible under different circumstances.

I do worry that the efficacy of remote work will be unfairly judged during this period, and I’m also encouraged by the number of people that find themselves adapting to remote, acknowledging the realities of 2020, and still finding themselves wanting to make a more permanent shift in remote work.

I hope the increase in remote work stays around. Not because we’re forced into, but because more teams find themselves adapting to it favorably, and in a way that emphasizes outcomes, trust, and the human being. As discussed in this recent CNBC article, these changes in leadership are needed to make the effective shift into remote work. It seems like this may be the case, but only time will tell.

In my experience, effective remote work has enabled me to work around life, rather than living around work. That’s what I wish for all of us, and I see increased remote work opportunity as a powerful tool in realizing that for more people; not because everyone should be remote, but because I hope those that wish to be remote can find healthy, thriving remote teams in the future.

The post Remote Work in 2020 is Not Normal – Will We Evaluate It Fairly? appeared first on goobar.

GitHub CLI – GitHub From The Command Line

Nate Ebel — Fri, 01 May 2020 16:30:01 +0000

GitHub recently announced GitHub CLI; a first-party command line tool for interfacing with GitHub from the command line.

With GitHub CLI, developers can check the status of GitHub issues and pull requests, search for a specific issue or PR, create/fork a repo, or create new issues and pull requests right from the command line.

In this post, we’ll walk through some common daily developer workflows. As we do, we’ll focus in on how we might manage our issues and pull requests using GitHub CLI.

What Is GitHub CLI?

So we’re all on the same page, we’ll start with a short overview of GitHub CLI. If you’re already familiar with it, jump ahead to the next section.

GitHub CLI is best described as “GitHub from the command line.”

Currently, GitHub CLI is at version v0.6.3 and consists of a focused set of functionality around three GitHub artifacts:

Issues
Pull Requests
Repositories

With GitHub CLI, developers can perform the following commands in relation to this different artifacts:

create
list
status
view
checkout (pull requests only)
clone (repo only)
fork (repo only)

As mentioned previously, in this post, we’re only going to focus on commands related to issues and pull requests.

How to Install GitHub CLI?

To install GitHub CLI on your development machine, check out the installation guide found on GitHub. You can also follow along with the tutorial on my YouTube channel.

GitHub CLI is available across MacOS, Windows, and various Linux distros, so you shouldn’t have a problem getting the tool up and running on your machine.

Using GitHub CLI To Manage GitHub Issues

If working with GitHub Issues is a regular part of your development flows then GitHub CLI likely has several helpful commands for you. Let’s walk through what a typical work day might look like and highlight some examples of using GitHub CLI to work with issues on GitHub.

List Issues With GitHub CLI

Let’s imagine we are just sitting down at our computer for the day, and we want to list out the open GitHub Issues for our project.

gh issue list

If we want to list out ALL of the issues we could use the “state” flag

gh issue list --state "all"gh issue list -s "all"

Now, maybe we’ve realized that is too many issues to sort through, so we decide we only want to list out your currently assigned issues.

gh issue list --assignee "n8ebel"

Or, you can use the short form

gh issue list -a "n8ebel"

Check Issue Status With GitHub CLI

Next, we want to check in on the status of a couple of the issues we created yesterday. Maybe we don’t remember their exact numbers, but since we created them, we can use the status command to list them at the terminal

gh issue status

This will give us a list of issues that are assigned to us, mentioning us, or that were opened by us.

After checking in on these issues, we still can’t find the issue we’re looking for, so we might want to check whether it was closed or not.

gh issue list --state "closed"gh issue list -s "closed"

That’s great! Our issue has been closed, so now we’re ready to find our next task. We could start looking for new tasks by listing out issuses filtered by different labels.

To list out all of our open bugs, we could filter by the “bug” label defined in our GitHub repo

gh issue list --label "bug"gh issue list -l "bug"

If you’re unsure of what labels are available for the open issues, you could first check by listing all the open issues again

gh issue list

Now, we can see there is also an enhancement label we can search for

gh issue list -l "enhancement"

View Issues With GitHub CLI

Once we’ve found an issue we want to fix, we might want to assign that issue to ourselves. Currently, we can’t do that directly from the command line, but we can quickly open the issue from the command line using the “view” command.

gh issue view "15"

This will open the issue in a web browser where you can then assign it to yourself.

After assigning any issues to yourself, you can double check your assignments from the command line by listing out open bugs assigned to you.

gh issue list -a "n8bel" -l "bug"

Create Issues With GitHub CLI

Now, we just have one last command to explore.

As we’re working on our assigned issues, imagine we find an additional bug we need to report.

We can use the gh issue create command to create a new GitHub Issue directly from the command line.

gh issue create

Using this command as is will kick off an interactive terminal workflow to select any available GitHub Issue template, and then fill in the title and issue description. You’ll finally then have the option to submit the issue, open it the browser, or cancel.

If you’d like to simplify things a bit, you can specify the issue with the command using additional flags

 gh issue create -t "Sample Issue Title" -b "Sample issue description"

If you still prefer to create your issue from the web, you could use the following command to open up a browser window and jump right into the issue creation workflow in your repo

gh issue create --web

Helpful GitHub CLI Aliases

So with these various command and flag variation, we have quite a few options for creating, listing, and viewing our GitHub Issues.

We can make these commands even easier to work with by creating some command line aliases for them.

For example, when listing out all bugs, instead of using this full command

gh issue list --label "bug"

We could create an alias like so

alias listbugs='gh issue list --label "bug"'

That way, when we want to list all bugs we can simply type:

listbugs

Another example would be to use the following alias to list all bugs assigned to you.

alias listmybugs='gh issue list -a "<your username>" -l "bug"'

With this alias in place, we can search for all bugs assigned to you like this:

listmybugs

Managing Pull Requests With GitHub CLI

Now, let’s explore the use of GitHub CLI for managing pull requests. Again, let’s walk through an imaginary workday and see where this tool make help us.

List Pull Requests

Once again, we sit down at our computer for the day, and we want to list the open pull requests for our project.

gh pr list

If we want to list out ALL of the pull requests, both open and closed, we could use the “state” flag

gh pr list --state "all"gh pr list -s "all"

Now, maybe we’ve realized that is too many PRs to sort through, so we decide we only want to list out your currently assigned issues.

gh pr list --assignee "n8ebel"

Or, you can use the short form

gh pr list -a "n8ebel"

Check Pull Request Status

Next, we want to check in on the status of a couple of the PRs we created yesterday. Maybe we don’t remember their exact numbers, but since we created them, we can use the status command to list them at the terminal

gh pr status

This will give us a list of PRs that are assigned to us, mentioning us, or that were opened by us.

After checking in on these PRs, we still can’t find the pull request we’re looking for, so we might want to check whether it was closed or not.

gh pr list --state "closed"gh pr list -s "closed"

That’s great! Our PR has been closed, so now we’re ready to find our next task. We could start looking for new tasks by listing out pull requests filtered by different labels.

To list out all of our open bug fix PRs, we could filter by the “bug” label defined in our GitHub repo

gh pr list --label "bug"gh pr list -l "bug"

If you’re unsure of what labels are available for the open issues, you could first check by listing all the open PRs again

gh pr list

Now, we can see there is also an enhancement label we can search for

gh pr list -l "enhancement"

View Pull Request

Once we’ve found a PR we want to review, we might want to assign that PR to ourself. Currently, we can’t do that directly from the command line, but we can quickly open the PR from the command line using the view command.

gh pr view "14"

This will open the pull request in a web browser where you can then assign it to yourself, review it, etc.

You can double check your assigned pull requests from the command line by listing out PRs assigned to you.

gh pr list -a "n8bel" -l "bug"

Create Pull Request

As we’re working on our assigned issue, at some point, we’re going to want to create a new pull request based on our local changes.

We can use the gh pr create command to create a new pull request directly from the command line.

gh pr create

Using this command as is will kick off an interactive terminal workflow to fill in the title and issue description. You’ll finally then have the option to submit the PR, open it the browser, or cancel.

If you’d like to simpify things a bit, you can specificy the PR info with the command using additional flags

gh pr create -t "Sample Issue Title" -b "Sample issue description"

If you still prefer to create your PR from the web, you could use the following command to open up a browser window and jump right into the PR creation workflow in your repo

gh pr create --web

At some point, we’re going to want to test a PR locally. This generaly requires looking up the PR, checking the branch it’s on, then checking it out locally.

Using GitHub CLI we can streamline this process using the pr checkout command

gh pr checkout "14"

This will checkout the branch associated with PR 14 so you’re ready to start testing.So with these various command and flag variation, we have quite a few options for creating, listing, and viewing our GitHub pull requests.

We can make these commands even easier to work with by creating some command line aliases for them.

For example, when listing out all PRs, instead of using this full command

gh pr list --label "bug"

We could create an alias like so

alias listprs='gh pr list --label "bug"'

That way, when we want to list all bug related PRs we can simply type

listprs

Another example would be to use the following alias to list all PRs assigned to you

alias listmyprs='gh pr list -a "<your username>"'

With this alias in place, we can search for all PRs assigned to you like so

listmyprs

More GitHub Resources

Check out the follow articles for more ways to leverage GitHub in your development workflows.

Subscribe for more software development posts, videos, and resources

The post GitHub CLI – GitHub From The Command Line appeared first on goobar.io.

Android Developer Career Paths

Nate Ebel — Tue, 14 Jan 2020 01:32:16 +0000

What Android developer career paths are available and viable in 2020?

The beginning of a new year offers a fresh start for us all. A chance to consider where we’ve been, and where we’re going. For me, this typically includes time to examine my career and to think about where I’d like that career to go.

I’m pretty sure I’m not alone in this either. Developers are constantly asking questions like “Should I learn framework X or framework Y?” and “Should I be a specialist or a generalist?”. These questions largely stem from a desire to smartly invest in our careers to set us up for long term success.

In this week’s issue, I wanted to explore this idea within the context of Android development. I want to throw out and examine a few general questions like “What languages should I learn?” and “How can I get my name out there?” and then unpack some specific questions to shed light on the different ways in which you might consider building a career as an Android developer, and really just as a developer in general.

You ready? Let’s dive in.

Common Android Development Career Path Questions?

Is Android development still a viable career option?

Of all the questions I see about Android development career paths, this is the most common; and I believe the answer is Yes. Do a quick search for “Android” jobs on LinkedIn, and you’re presented with over 268,000 results.

While Android has been around for over a decade, and the operating system does seem to have reached some level of maturity, the job market doesn’t appear to be slowing down. There are still many many companies out there looking for skill Android developers.

So, if you want to build apps that run on Android devices, I think you’ll be able to find a job for at least a few more years.

Is Native Android development still a viable career path?

This is probably a close second in terms of popular Android career path questions, and is honestly a lot more interesting to me. Companies are clearly still looking to build apps and tools that work for Android, but are they moving away from native Android development in favor of cross-platform solutions like Flutter or React Native?

Again, looking at job postings is, I think, a reasonable metric to gauge the market interest in these different skillsets.

Let’s compare the job posting results for a few different searches:

“flutter” – 2,583 results
“react native” – 13,927 results
“android java” – 33,487 results
“android kotlin” – 9,542 results
“android c++” – 10,159 results

By these results, we can see that building Android apps natively with Java, Kotlin, or C++ seems to still be what most employers are looking for. So I think it’s safe to say that native Android development, and probably native iOS development are both perfectly viable career paths for the coming years.

Conversely, there’s also clearly demand for cross-platform developers as well, and we’ll explore that more as we continue on.

What languages should you learn?

What programming languages should you learn to build a career in Android development? If going the native Android development route, then you have three options: Java, Kotlin, and C++.

If doing typical Android app development, you’ll likely be considering between Java and Kotlin, and with Google’s “Kotlin First” approach to modern Android, I think Kotlin is a good investment of your time and learning effort.

If you’re going to be doing lower level SDK work or building high-performance games, you may need to work with C++

If you’re more interested in building for multiple platforms at the same time using frameworks like Flutter or React Native, your options are a bit more clear. When building with Flutter, you’ll use Dart, and when building with React Native you’ll most likely use Javascript.

Now, are these the only languages you need to know? Maybe to get started, yes. However, having familiarity with multiple languages can improve the way you think about code and how you write code. As you become familiar with new language features and paradigms, you’ll see how you can apply those to other languages and challenges as well.

Being comfortable with at least one scripting language is a great idea as well as it’ll enable you to automate development workflows when the need arises. Options such as Python, or Unix Shell Scripts could be a great choice here.

How can you get your first job?

Breaking into an industry with your first job can be a daunting task. The process is often filled with stress, uncertainty, and lots of waiting to hear back from recruiters. A few things I found helpful when searching for my first job include:

Setting realistic expectations about where I’m going to work. Not everyone can, or should, work at the big companies like Google, Amazon, Facebook, etc. There are many many wonderful places to work out there, and exploring more options improves your chances of finding that first job.
Demonstrating job competencies. A big factor in me landing my first Android development job was the fact that I had published an app to the app store and could explain to interviewers how I had built it, what the app publishing process was like, and what the major challenges were in writing production software. Having some form of sample project, portfolio, or published work is a great way for recruiters and interviewers to see what you can do. This will hopefully then improve your chances of getting job interviews, and of doing better in those interviews.
Reach out to people you know in the industry, and ask if they have entry-level or internship opportunities available. Direct referrals can often get your resume placed at the top of the list which is a huge advantage in getting called for an interview.
Stay positive. Like I mentioned before, finding a job is stressful and challenging. It can make our imposter syndrome flare up in a major way, and make us question whether or not we have the required skills to do the job we want. Remember that not receiving a job offer does not mean you can’t do the job. There are many factors involved, and sometimes all we can do is stay positive and move on to the next opportunity.

How can you get your name out there?

Once you’ve found your first job, you might start looking for ways to add to your career beyond your job. For this, there are a number of ways you might look to become more involved in the developer community including:

Open source contributions
Event organizing
Speaking
Blogging
Video Tutorials
Mentorship
Social Media

Any of these are great ways to add your experience and ideas to the public discussions around topics your interested in. The internet makes it easier than ever to connect with people all over the world and to carve out your own niche of interests, ideas, projects, and ways of giving back.

Career Options for Developers

Now that we’ve discussed some of these higher-level questions, I want to get more specific and focus in on some more concrete comparisons of different career paths available to us as software developers.

Developer vs Educator

Do you want to get paid to write code, or would you prefer to get paid to teach others how to write code?

I included this here because it’s becoming more and more viable to make money online by teaching others how to write code and to become software developers. Whether it’s at established edTech companies like Pluralsight and Udacity or with your own courses, it’s possible to make a living by teaching others.

Your career path as a developer doesn’t have to include getting a job to build someone else’s app. If you have a passion for teaching, mentorship, and helping others, then you might consider either a full-time, or at least a part-time, job in some form of developer education.

Freelance vs Company

Do you have to go work for someone else to make money as a developer? The simple answer is, No. If you’re someone that would prefer to work alone, or to work on a variety or projects, or to have greater flexibility in when/how you work, then freelancing might be the way to go.

As a freelancer, you’re likely to find greater flexibility in your work. This may also manifest as uncertainty. You may not always know where your next project and paycheck are coming from. You may get bogged down in the more administrative side of running your own freelancing business.

You may also find that the freedom provided by freelancing is a great fit. You may really enjoy the business aspect of freelancing, and in particular, you might find freelancing enables you greater freedom to pursue other interests such as content creation or travel.

FAANG vs Startup

If you prefer to work at a company, what type of company do you want to work for? Do you want to be in the fast-paced, VC-backed startup world? Do you want to work at the major tech giants like Google, Microsoft, and Amazon? Do you want to work for a less exciting, but very stable company?

Not all companies are created equally. Similarly, different business groups, organizations, and teams may operate very differently even within the same company.

When deciding what type of company to work for there are many questions you can ask yourself and use to filter out the options:

Do you want to work at a well known company?
Do you prefer to work on a small team or a large team?
Would you rather get paid more, or work from home?
Do you prefer to know everyone you work with, or would you rather work in a large organization?
What’s more important, fun perks like snacks and ping pong, or reasonable working hours?
How much project ownership will you have?
Would you prefer to go deep or wide on a project?

I’m sure you can think of many questions of your own. What do you value in your work? What tradeoffs are you willing to make. What have you liked about past companies, and what have you disliked? Taking time to consider these things will help guide your future decisions.

IC vs Manager

When you think about your career, do you see yourself writing code forever? Do you see yourself managing others? Do you want a mix of both? These are great questions to consider as many companies have different career paths to help fit what you’re looking for. The most common split is between an Individual Contributor (IC) role and a Manager role.

The exact requirements and responsibilities of each path will differ based on company, but in general, the IC path is going to be more focused on your writing code, while the management path will be more focused on making other developers more successful.

Both have their pros and cons, and both are completely viable.

Whoa! In this short article we’ve already touched on a lot of questions, comparisons, and potential career paths.

If you’re feeling a little overwhelmed that’s perfectly okay. I think we all become a little overwhelmed, lost, or even discouraged at times when considering our careers. There’s a lot to navigate in this game of life. The great thing is, we have time and resources available to us to learn new skills, pivot in a new direction, and build a career that we love. The trick is to be intentional about it. That doesn’t mean you have to plan out your whole career, that would be impossible given the rate of technological change, but you should regularly take time to think about what’s important to you, what you enjoy doing, and to survey the landscape of the industry around you and look for those areas where your passions, values, and financial needs align.

What in the world of Android development are you interested in right now? Join in the conversation in the comments below.

The post Android Developer Career Paths appeared first on goobar.io.

Android Development Podcasts — 7 Options to Choose From

Nate Ebel — Tue, 09 Jul 2019 01:48:45 +0000

Android development podcasts to help you stay up to date

Originally published at https://goobar.io on July 9, 2019.

I’ve had a number of questions lately about which podcasts I’ve been listening to, and where to find them, so I thought I’d share a small list of relevant Android development podcasts for you to check out.

tl;dr — 7 Android Development Podcasts

Fragmented

Fragmented Podcast

This has been my go-to Android development podcast for a long time. Donn Felker and Kaushik Gopal do a terrific job of putting out consistently great episodes on all manner of Android-related topics. They generally sit down with other Android developers to discuss tools, libraries, patterns, etc.; all relevant to the world of Android development.

Android Developers Backstage

Android Developers Backstage Podcast

This podcast comes straight out of the Googlers’ mouths as it’s hosted by Chet Haase and Tor Norbye from the Android teams at Google.

I enjoy this podcast because it generally offers deep dives into Android topics usually including guests that actually work on the tools/libraries. Because of this, I think it offers a level of insight that’s difficult to replicate elsewhere.

Talking Kotlin

Talking Kotlin Podcast

Talking Kotlin with Hadi Hariri is a wonderful resource if you’re wanting to learn more about Kotlin specifically. It covers everything from the world of Kotlin include Kotlin on Android, Kotlin Multiplatform, KotlinConf, etc.

The Context

The Context Podcast

The Context is another community-driven Android development podcast hosted by the trio of Artem Zinnatullin, Hannes Dorfmann, and Artur Dryomov.

This is another great option if you are wanting to hear what other developers are working on and thinking about in the world of Android.

Bonus Android Development Podcasts

I also want to include a few other podcasts that might be worth checking out.

Android Leaks Podcast — a French Android development podcast that I recently came across. I don’t speak French, so I don’t really know a whole lot about it but it’s out there.

Andro idiots Podcast — This is a new one which someone pointed out to me recently. It’s pretty new, but has a nice backlog of episodes going and covers a variety of Android topics.

droidkast.LIVE — Antonio Levia has a small backlog of episodes consisting of interviews with other Android developers which culminate in a smaller learning presentation at the end.

Where to Listen?

For those using Android devices, I highly recommend Pocket Casts as a podcast app. I’ve been using it for years to listen to Android development podcasts (really all of my podcasts) and have been extremely happy with it.

As an alternative, I’ve used Google Play Music for podcasts in the past which does a pretty good job as well.

I haven’t been overly impressed so far with the Google Podcasts app, but it’s out there as well and might be getting more attention from Google right now than Google Play Music’s podcast support.

Other Useful Resources

I love to meet/talk/discuss and help where I can. If you want to chat or ask a question you can follow me on Twitter, YouTube, Instagram and Facebook.

Check Out My YouTube Channel