IJHDev Blog

More Android Gradle tips

Fri, 26 May 2023 00:00:00 GMT

Going over some lesser known configuring tools for Gradle on an Android project

In part one we talked about how Android Gradle is a powerful build tool that allows developers to easily manage dependencies, build multiple variants of an app, and customise build settings. However, many developers may not be aware of some of the lesser-known features and options that Android Gradle provides. In this blog post, we’ll take a look at some tips and tricks for using Android Gradle that may not be as well-known, but can greatly improve your Android development process.

1. Using the lintGradle task

The lintGradle task is a built-in task that is used to run lint checks on your project’s Gradle files. This can be extremely useful for detecting and fixing issues with your build files, such as unresolved dependencies or misconfigured tasks. To run the lintGradle task, simply navigate to the root of your project in the command line and run the command

./gradlew lintGradle.

2. Using the dependencyInsight task

The dependencyInsight task is a built-in task that is used to show detailed information about a specific dependency in your project. This can be useful for understanding the transitive dependencies of a specific library and how they are being used in your project. To run the dependencyInsight task, simply navigate to the root of your project in the command line and run the command

./gradlew dependencyInsight --configuration <configuration> --dependency <dependency>.

3. Using the dependencyUpdates task

The dependencyUpdates task is a built-in task that is used to check for updates to the dependencies in your project. This can be useful for keeping your project up-to-date with the latest versions of libraries, and for identifying potential security vulnerabilities. To run the dependencyUpdates task, simply navigate to the root of your project in the command line and run the command

./gradlew dependencyUpdates.

4. Using the dependencyCheck plugin

The dependencyCheck plugin is a third-party plugin that can be used to check for known vulnerabilities in the dependencies of your project. This can be a useful tool for identifying and addressing potential security issues in your project. To use the dependencyCheck plugin, simply add the following to your build.gradle file:

dependencies {
    dependencyCheck gradlePlugin
}

5. Using the maven-publish plugin

The maven-publish plugin is a built-in plugin that allows you to publish your project to a Maven repository. This can be useful for sharing your project with others or for distributing your project as a library. To use the maven-publish plugin, simply add the following to your build.gradle file:

apply plugin: 'maven-publish'

6. Using the signing plugin

The signing plugin is a built-in plugin that allows you to sign your apk files with a private key. This is a necessary step for publishing your app to the Google Play Store, and for creating a release version of your app. To use the signing plugin, simply add the following to your build.gradle file:

apply plugin: 'signing'

7. Using the com.jfrog.bintray plugin

The com.jfrog.bintray plugin is a third-party plugin that allows you to easily publish your project to the Bintray package repository. This can be useful for distributing your project as a library, and for publishing to the JCenter repository, which is used by default in many Android projects. To use the com.jfrog.bintray plugin, you need to add the following to your build.gradle file:

apply plugin: 'com.jfrog.bintray'

and then configure the bintray credentials and package details in the build.gradle file.

8. Using the com.github.dcendents.android-maven plugin

The com.github.dcendents.android-maven plugin is a third-party plugin that allows you to easily publish your android library to Maven Central Repository. This can be useful for distributing your android library widely and make it easier for other developers to use it. To use the com.github.dcendents.android-maven plugin, you need to add the following to your build.gradle file:

apply plugin: 'com.github.dcendents.android-maven'

and then configure the Maven Central Repository details in the build.gradle file.

Android Gradle tips

Fri, 14 Apr 2023 00:00:00 GMT

Going over the basics for configuring Gradle on an Android project

Android Gradle is a powerful build tool that allows developers to easily manage dependencies, build multiple variants of an app, and customise build settings. In this blog post, we’ll take a look at some tips and tricks for using Android Gradle to streamline your Android development process.

1. Using the compile vs implementation configuration

When adding dependencies to your build.gradle file, you may have noticed two different configuration options: compile and implementation. Both options serve the same purpose, but implementation is the recommended configuration for new projects. The difference between the two is that compile also includes transitive dependencies, while implementation only includes the specified dependency. This can lead to version conflicts and unexpected behaviour if not managed properly.

2. Managing dependencies with the dependencies block

The dependencies block in the build.gradle file is where you specify all of the dependencies for your project. When adding a new dependency, you can use the compile or implementation configuration and specify the library name, version, and any additional configuration options.

dependencies {
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation 'com.google.firebase:firebase-core:16.0.8'
}

3. Using the exclude configuration

If you find yourself in a situation where a transitive dependency is causing conflicts or unexpected behavior, you can use the exclude configuration to remove it. The exclude configuration allows you to specify specific dependencies to be excluded from a transitive dependency.

dependencies {
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation ('com.google.firebase:firebase-core:16.0.8') {
        exclude group: 'com.android.support', module: 'support-v4'
    }
}

4. Using the configurations block

The configurations block allows you to configure various aspects of your build, such as the Java version, packaging options, and signing settings. For example, you can use the configurations block to specify the minimum and target SDK version for your app.

android {
    compileSdkVersion 28
    defaultConfig {
        minSdkVersion 21
        targetSdkVersion 28
    }
}

5. Using the buildTypes block

The buildTypes block allows you to configure different build types for your project, such as debug and release. This is useful for building different versions of your app with different settings, such as signing and obfuscation.

android {
    buildTypes {
        debug {
            signingConfig signingConfigs.debug
        }
        release {
            signingConfig signingConfigs.release
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
}

6. Using the productFlavors block

The productFlavors block allows you to configure different product flavors for your project, such as free and paid. This is useful for building different versions of your app with different features, such as in-app purchases or ads.

android {
    productFlavors {
        free {
            applicationId "com.example.app.free"
        }
        paid {
            applicationId "com.example.app.paid"
        }
    }
}

7. Using the com.android.application plugin

The com.android.application plugin is the main plugin for building Android applications. It provides a number of tasks for building, testing, and deploying your app. It also provides access to the Android SDK and other dependencies needed for building your app.

apply plugin: 'com.android.application'

8. Using the com.android.library plugin

The com.android.library plugin is used for building Android libraries. It provides a number of tasks for building, testing, and deploying your library. It also provides access to the Android SDK and other dependencies needed for building your library.

apply plugin: 'com.android.library'

9. Using the com.android.test plugin

The com.android.test plugin is used for building and running Android instrumentation tests. It provides a number of tasks for building and running tests, as well as configuring test options such as test runner and test instrumentation.

apply plugin: 'com.android.test'

10. Using the com.android.support library

The com.android.support library is a set of libraries that provide backwards compatibility for older versions of Android. It includes support for various UI components, as well as other features such as appcompat, design, and cardview.

dependencies {
    implementation 'com.android.support:appcompat-v7:28.0.0'
    implementation 'com.android.support:design:28.0.0'
    implementation 'com.android.support:cardview-v7:28.0.0'
}

In conclusion, Android Gradle is a powerful build tool that provides a number of features and options for building, testing, and deploying Android apps and libraries. By using the tips and tricks outlined in this post, you can streamline your Android development process and make the most out of the powerful capabilities of Android Gradle.

OKRs

Fri, 24 Mar 2023 00:00:00 GMT

Objectives and Key Results (OKRs) are a goal-setting framework that has been adopted by companies like Google to drive growth and focus.

The idea behind OKRs is simple: set clear, measurable objectives and track progress through key results. But OKRs are more than just a set of goals – they are a way of thinking and working that can transform an organization. In this article, we’ll explore what OKRs are, the advantages they offer over other goal-setting processes, and some examples of how they have been used in practice.

What are OKRs?

OKRs were first developed by Andy Grove, the former CEO of Intel, in the 1970s. The basic idea behind OKRs is to set clear, measurable objectives that are aligned with the organization’s overall goals and track progress through key results. OKRs are typically set on a quarterly or annual basis and involve all levels of the organization, from the CEO to individual team members.

Here’s an example of how OKRs might work in practice:

Objective: Increase customer satisfaction

Key results:

Increase Net Promoter Score (NPS) from 50 to 60
Reduce customer churn rate by 10%
Increase customer satisfaction survey scores by 5%

In this example, the objective is to increase customer satisfaction, and the key results are specific, measurable targets that will help the organization achieve this goal. By tracking progress towards these key results, the organization can see how well they are doing in terms of meeting their objective.

Advantages of OKRs

OKRs offer several advantages over other goal-setting processes:

Focus and alignment: OKRs help organizations stay focused on their most important goals by setting clear objectives and key results. This ensures that everyone in the organization is working towards the same priorities and that resources are being directed towards high-impact projects.
Transparency and accountability: OKRs are typically shared with the entire organization, which promotes transparency and accountability. By making progress visible to everyone, OKRs encourage team members to work towards their goals and celebrate their achievements.
Flexibility: OKRs are designed to be flexible and adaptable, which allows organizations to pivot and respond to changing circumstances. This can be especially important in fast-moving industries where the landscape is constantly shifting.
Motivation: OKRs can be a powerful motivator for employees because they provide a sense of purpose and direction. When team members understand how their work fits into the bigger picture, they are more likely to be engaged and motivated.

Examples of OKRs in action

OKRs have been used by a wide range of organizations, from startups to Fortune 500 companies. Here are a few examples of how OKRs have been used in practice:

Google: OKRs have been central to Google’s growth and success since the company’s early days. Google sets OKRs on a quarterly basis, with each team responsible for setting their own objectives and key results. This decentralized approach allows teams to focus on their own priorities while still being aligned with the overall goals of the organization.
LinkedIn: LinkedIn has used OKRs to drive innovation and growth since the company’s early days. In 2012, LinkedIn CEO Jeff Weiner implemented a company-wide OKR program, which has helped the company stay focused on its most important goals and drive growth.
Asana: Asana, a project management software company, has used OKRs to drive growth and focus since the company’s founding in 2008. Asana sets OKRs on a quarterly basis and has found that the process helps the company stay focused and aligned while also allowing for flexibility and adaptability.

Challenges of OKRs

While OKRs offer many benefits, they are not without their challenges. Here are a few potential drawbacks to consider:

Time and effort: Implementing OKRs requires time and effort, particularly in the beginning as teams get used to the process. There is a learning curve involved in setting clear objectives and key results, and it can take time to get everyone on board.
Risk of over-optimization: By focusing on a few key objectives, organizations risk neglecting other important areas. It’s important to strike a balance and ensure that OKRs are not overly narrow or short-sighted.
Culture fit: OKRs work best in organizations with a culture of transparency, collaboration, and continuous improvement. If your company doesn’t have these values, it may be difficult to implement OKRs successfully.
Resistance to change: Like any new process, OKRs can be met with resistance, especially if employees are used to working in a different way. It’s important to communicate the benefits of OKRs and get buy-in from team members before implementing them.

Conclusion

OKRs are a powerful goal-setting framework that can help organizations stay focused and drive growth. While there are potential challenges to implementing OKRs, the benefits often outweigh the cons. If your company values transparency, collaboration, and continuous improvement, OKRs may be worth considering.

To make the most of OKRs, it’s important to set clear objectives and key results, track progress regularly, and be open to adapting and adjusting as needed. With the right approach, OKRs can help your organization stay focused, aligned, and motivated as you work towards your most important goals.

Android Jetpack Compose

Fri, 10 Feb 2023 00:00:00 GMT

Jetpack Compose is a modern toolkit for building native Android UI

It was created by Google as a response to the increasing complexity of designing user interfaces for Android apps. With Jetpack Compose, developers can use a declarative and reactive approach to building UI, which makes it easier to create visually stunning and intuitive layouts.

In this blog post, we will cover the following topics:

What is Jetpack Compose?
Why was Jetpack Compose created?
How to set up Jetpack Compose in your Android project
Coding examples with Jetpack Compose

What is Jetpack Compose?

Jetpack Compose is a declarative and reactive UI toolkit for Android. It allows developers to create UI elements using Kotlin code, rather than XML layout files. This means that developers can write UI code that is more concise, easier to read, and easier to understand.

One of the key benefits of Jetpack Compose is that it follows a declarative programming model. This means that developers specify what they want their UI to look like, rather than specifying how to build it. This makes it easier to create and modify UI elements, as developers only need to worry about the end result, rather than the individual steps needed to achieve it.

Jetpack Compose also follows a reactive programming model, which means that the UI is automatically updated whenever the underlying data changes. This makes it easier to build dynamic and interactive UI, as developers don’t need to manually update the UI when data changes.

Why was Jetpack Compose created?

Jetpack Compose was created as a response to the increasing complexity of designing user interfaces for Android apps. In the past, Android developers had to use a combination of XML layout files and Java/Kotlin code to create their UI. This approach was prone to errors, and it made it difficult to create complex UI layouts.

With Jetpack Compose, Google aims to simplify the process of building UI for Android apps. By using a declarative and reactive programming model, Jetpack Compose makes it easier for developers to create visually stunning and intuitive layouts. It also allows developers to write UI code that is more concise and easier to understand, which makes it easier to maintain and update the UI over time.

How to set up Jetpack Compose in your Android project

To use Jetpack Compose in your Android project, you will need to install the latest version of Android Studio (4.1 or higher). Once you have Android Studio installed, you can follow these steps to set up Jetpack Compose in your project:

Open your Android project in Android Studio. In the build.gradle file for your project, add the following line to the dependencies block:

implementation 'androidx.ui:ui-tooling:0.1.0-dev02'

In the build.gradle file for your app module, add the following lines to the android block:

compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
}

In the AndroidManifest.xml file for your app, add the following attribute to the application element:

android:usesCleartextTraffic="true"

In your app’s main activity, import the following packages:

import androidx.compose.ui.platform.setContent
import androidx.ui.core.Text
import androidx.ui.core.setContent
import androidx.ui.graphics.Color
import androidx.ui.layout.Column
import androidx.ui.layout.Spacing
import androidx.ui.material.MaterialTheme
import androidx.ui.tooling.preview.Preview

In the onCreate method of your main activity, set the content view to a Jetpack Compose UI component:

setContent {
    MaterialTheme {
        // Your Jetpack Compose UI goes here
    }
}

This sets the content view of your activity to a Jetpack Compose UI, which will be rendered in the app when it is run.

Coding examples with Jetpack Compose

Now that you have Jetpack Compose set up in your Android project, let’s look at some coding examples to see how it works in practice.

Example 1: Creating a simple text view The following code creates a simple text view using Jetpack Compose:

Text(text = "Hello, world!")

This will create a text view with the text “Hello, world!” displayed on the screen.

Example 2: Creating a column layout The following code creates a column layout with three text views:

Column {
    Text(text = "Text view 1")
    Text(text = "Text view 2")
    Text(text = "Text view 3")
}

This will create a column layout with three text views, one below the other.

Example 3: Adding styling to a text view The following code creates a text view with custom styling:

Text(
    text = "Hello, world!",
    color = Color.Red,
    style = TextStyle(fontSize = 24.sp)
)

This will create a text view with the text “Hello, world!” displayed in red and with a font size of 24sp.

Example 4: Using a preview function Jetpack Compose includes a preview function that allows you to see a live preview of your UI while you are coding. To use the preview function, add the following code to your file:

@Preview
@Composable
fun Preview() {
    // Your Jetpack Compose UI goes here
}

This will create a preview function that you can use to see a live preview of your UI while you are coding.

I hope this has helped you understand what Jetpack Compose is and how to use it to build native Android UI. With Jetpack Compose, you can use a declarative and reactive approach to building UI, which makes it easier to create visually stunning and intuitive layouts.

Jumping into a new team as a manager

Thu, 05 Jan 2023 00:00:00 GMT

Pointers on the daunting task of becoming the manager of an existing team.

Starting a new job as a manager can be exciting, but it can also be overwhelming, especially if you are joining a new team. Whether you are moving to a new company or a new department within your organization, there are a few key steps you can take to make the transition smoother and get up to speed more quickly. In this article, we’ll break down what you can do in the first 30, 60, and 90 days on the job to determine and improve your team’s ways of working.

30 days:

Get to know your team: Your first priority should be to get to know your new team members. Take the time to introduce yourself, learn about their roles and responsibilities, and find out how they prefer to work. This will help you build rapport and understand how your team operates.

Observe and ask questions: Pay attention to how your team works and ask questions to get a better understanding of their processes and tools. Ask about the team’s goals, challenges, and successes, and try to get a sense of their work culture.

Find out who the key players are: Determine who the key players are on your team and try to get to know them. These may be subject matter experts, team leads, or other influential team members. Building relationships with these individuals will help you get up to speed more quickly and navigate your new team more effectively.

Communicate your vision and goals: As a manager, it’s important to communicate your vision and goals for the team. Share your expectations and make sure that your team understands how their work fits into the bigger picture.

60 days:

Start contributing: After you have had a chance to observe and learn, it’s time to start contributing to your team. This might mean taking on small tasks or projects, or offering to help out with ongoing work. The goal is to demonstrate your value and start building your reputation within the team.

Identify areas for improvement: As you get more comfortable with your team and their ways of working, start looking for areas where you can add value. This might be by suggesting new tools or processes, or by finding ways to streamline existing workflows.

Seek feedback: Don’t be afraid to ask for feedback from your team members. This can help you understand how you are perceived and where you can improve. Use this feedback to adjust your approach and better understand your team’s needs and expectations.

Define roles and responsibilities: Make sure that your team understands their roles and responsibilities clearly. This will help them know what is expected of them and ensure that everyone is working towards the same goals.

90 days:

Take on more responsibility: As you gain more experience and build your reputation within the team, start taking on more responsibility. This might involve leading small projects or taking on additional tasks and responsibilities.

Make your mark: By now, you should have a good understanding of your team’s goals and ways of working. Use this knowledge to make a positive impact and contribute to your team’s success.

Build relationships outside of your team: In addition to building relationships within your team, start networking and building relationships with other teams and departments. This can help you better understand the broader organization and find opportunities for collaboration.

Set performance goals: As a manager, it’s important to set performance goals for your team and track progress towards these goals. This will help you measure the team’s performance and identify areas for improvement.

Beyond 90 days:

Continue learning: No matter how long you have been with your team, there is always more to learn. Keep an open mind and be willing to learn from your team members and other colleagues.

Foster a culture of continuous improvement: Encourage your team to regularly review and assess their ways of working and look for opportunities to improve. This might involve experimenting with new tools or processes, or seeking feedback from other teams.

Develop your team: As a manager, it’s your responsibility to help your team grow and develop. This might involve providing training and development opportunities, setting performance goals, or offering feedback and support.

Lead by example: As a manager, your team looks to you for guidance and direction. Make sure that you are setting a good example by being reliable, respectful, and proactive.

In conclusion, moving into a new team as a manager can be challenging, but with the right approach, you can quickly get up to speed and make a positive impact. By getting to know your team, observing and asking questions, and communicating your vision and goals, you can build relationships and understand your team’s ways of working. As you gain more experience and build your reputation, you can take on more responsibility, make your mark, and foster a culture of continuous improvement. With the right approach, you can be a successful leader and help your team succeed.

Android Fastlane CICD Image

Mon, 01 Nov 2021 00:00:00 GMT

Easy to use CI/CD Image for Android builds

What is it

A maintained Android Image for CI pipelines. Can be used for any CICD that uses Docker hub, works with standard Android or Fastlane. Use the image as is or pull the code yourself and make it work for your specific needs.

Latest version

image: ijhdev/gitlab-ci-fastlane-android

How to use it

Example Gitlab .Yaml

image: ijhdev/gitlab-ci-fastlane-android

variables:
 ANDROID_COMPILE_SDK: "31"
 ANDROID_BUILD_TOOLS: "30.0.3"
 ANDROID_SDK_TOOLS:   "7583922"
 LC_ALL: "en_US.UTF-8"
 LANG: "en_US.UTF-8"
 GIT_STRATEGY: clone

before_script:
 - export GRADLE_USER_HOME=$(pwd)/.gradle
 - chmod +x ./gradlew

cache:
 key: ${CI_PROJECT_ID}
 paths:
   - .gradle/

stages:
 - unit_test
 - debug_build

unit_test:
 tags:
   - your_build_runner
 dependencies: []
 stage: unit_test
 artifacts:
   paths:
     - fastlane/screenshots
     - fastlane/logs
   expire_in: 1 hour
 script:
   - fastlane tests

debug_build:
 tags:
   - your_build_runner
 dependencies: []
 stage: debug_build
 artifacts:
   paths:
     - app/build/outputs/
   expire_in: 1 week
 script:
   - bash ./version_updater.sh
   - fastlane yourDebug

Example Bitrise

Open up bitrise and the project you want to change the image for

From here click on Workflow

Once in Workflow navigate to Stack

Here you will see default Stack and Workflow Specific Stasks. If you want to change the build image for all steps then use default but if there is just one area failing for you then use the Workflow specific stacks

But wait

Also included in the Github codebase is an Android auto version updater. The version updater takes your Google Play store listing and checks it against your Gradle version. If your Gradle version number is higher than the app store it will stick with it, if it’s equal or lower that the store version then it will take that, +1 to the end, then change the Gradle version for that one.

All you need to do is take the version_updater.sh file from the Github and put it in the root folder of your app and edit this line to have your bundle ID

curl -O playstorepage https://play.google.com/store/apps/details\?id\=<YourBundleID>

Check out the Image and Code here

https://hub.docker.com/repository/docker/ijhdev/gitlab-ci-fastlane-android/general

https://github.com/seperot/AndroidFastlaneCICD_Image

Simple Reusable Dialog for Android

Wed, 08 Apr 2020 00:00:00 GMT

A small native Android/Kotlin library that helps build dialogs with however many buttons in however many styles you want.

What is it

Android dialogs can be a bit of a faffy affair, this small lib gives you a range of customizability while staying native so a lower risk of compatibility issues down the road.

Latest version for gradle

implementation ‘com.github.seperot:SimpleReusableDialog:1.5’

How to use it

Example button

       registerButton(
           getString(
               R.string.dialog_one_button_one),
               R.color.colorPrimary,
               android.R.color.white,
               object : ReusableDialogListener {
                   override fun onDialogButtonClick
                   dialogFragment: DialogFragment, index: Int) {
                       dialogFragment.dismiss()
                   }})

           ReusableDialog.dialogCancelable(false)

           ReusableDialog.createDialogInstance(
               getString(R.string.dialog_one), 
               getString(R.string.dialog_one_text), 
               null).show(
               supportFragmentManager, null
           )
       }

Working parts

registerButton

RegisterButton adds a button to the next time you call createDialogInstance it has four parts

buttonTitle: The text the button shows
buttonBackground: The button background color, things like R.color or android.R.color work
textColor: The button text color, again things like R.color or android.R.color work
dialogButtonListener: The button onClickListener, this has to be called in the following format currently until I can figure out how to make it look nicer

dialogCancelable

A simple boolean that turns on or off the users ability to cancel out of the dialog without choosing an option. This also needs to be done before you call createDialogInstance and will reset after use true = they can cancel, false = they cannot cancel This also works for the back button

createDialogInstance

Calls the dialog and shows it to the user, grabs any registered buttons and checks if the dialog is cancelable or not then displays. Has three fields

title: The dialog title
infoText: The dialog content
topIcon: The icon at the top of the Dialog, set as null to remove from Dialog

Finally be sure to add “.show(supportFragmentManager, null)” At the end to display the dialog

As you can see in this second example, you can expand this to as many buttons as you like

            registerButton(
                getString(R.string.dialog_two_button_one),
                R.color.colorPrimary,
                android.R.color.black,
                object: ReusableDialogListener {
                    override fun onDialogButtonClick(
                        dialogFragment: DialogFragment, 
                        index: Int) {
                    dialogFragment.dismiss()
                    Toast.makeText(
                        applicationContext, 
                        getString(R.string.toast_one), 
                        Toast.LENGTH_LONG).show()
                }})

            registerButton(
                getString(R.string.dialog_two_button_two),
                R.color.colorPrimaryDark,
                android.R.color.white,
               object: ReusableDialogListener {
                   override fun onDialogButtonClick(
                       dialogFragment: DialogFragment, 
                       index: Int) {
                       dialogFragment.dismiss()
                       Toast.makeText(
                           applicationContext,
                           getString(R.string.toast_two),
                           Toast.LENGTH_LONG
                       ).show()
                   }})

            ReusableDialog.createDialogInstance(
                getString(R.string.dialog_two),
                getString(R.string.dialog_two_text),
                R.drawable.pupcat
            ).show(
                supportFragmentManager, null
            )
        }

Planned features

Add a setting for custom button margin
Add a setting for custom button padding
Add set dialog size and scroll

Check out the library here

https://github.com/seperot/SimpleReusableDialog

Setting up a Golden Path Document

Tue, 04 Feb 2020 00:00:00 GMT

A golden path document is the best way for new starters to come in strong and help those that come after them

What is a golden path document

A Golden path, when talking about software is the ideal route for a user to take. In the case of a shopping app, the golden path would see the user log in, find the item they are looking for easily, go to checkout, and pay all without any issue. A golden path document in this instance is showing the ideal path for a new member of the team to get up and running with the project quickly and easily. The document shouldn’t assume much as you don’t know where someone’s starting point or gaps in their knowledge will be. For someone, it may be they have never used the CI software your team uses but for someone else it could be they have no idea what to install as their previous company had strict installation rules.

How to structure it

Start with the basics

The first thing is for them to check they have all the hardware they will need.

Is their workstation the minimum spec?
Do they need peripherals or cables?
Do they need access to devices they need for debugging?
Are there any accessability items they don’t know they can ask for?

Next is software, same deal as hardware but this time what they need to get the job done. This also included pulling down the codebase they will be working on.

Finally make sure all their access and permissions needed are sorted as well, any cloud platforms or tools like Jira they need logins for are ready for them to use.

Code rules and opinions

With the basics out the way, the next thing to do is write as much as you can down on the coding standards your team uses.

Camel case, Delimiter space, Hungarian notation or whatever naming style the team uses
If you use multiple languages then anything unique to each of them
Where you set strings, colours, and sizes
2 spaces, 4 spaces or tabs
Class and folder structure
If you do TDD, or what the test coverage percentage needs to be

How the work process… works

So now they have the tools to do the job and know what the standards look like, it’s time for them to take on a task. Breaking down this section based on them working through the workflow.

Where to go to get work
What system does your teamwork with like Kanban or Scrum.
How they let everyone know they are taking on the task and when it’s ready
Is there a QA process they need to take the work through
What CI/CD pipeline process are working in the background at the various stages.
Do the git branches have a lifespan before being deleted?

You also need to make clear when their work is ready for review

When do they open a pull request
Is there a limit to the size of the pull request
How commenting on the PR works and when to take it to a conversation
How to write good descriptions on a PR

Getting their work live

Finally once they have done all the work and been through the process, they will no doubt want to see their work live. Here you just need to explain the release process and if they need to make release notes.

Make it living

An important part of a golden path document being effective is to keep it as a living document. As the new member of the team works through the document encourage them to edit anything they find as a pain point, something outdated that you had to explain to them or just something they feel like needs more detail. This helps keep the document up to date and makes the new starter have a hand making the process better for the next new starter. Keep the document in an area where you can rollback if something is changed incorrectly but everyone in the team has access, Confluence being a good example.

Golang automated pipeline

Mon, 09 Dec 2019 00:00:00 GMT

A guide to building a simple pipeline from PR to deploy with a scalable solution. (TurtleWare 2.0 pt3)

This is part 3 of a 3 part blog post about making v2 of turtle wear watch face. You can check out part 1 here and you can check out part 2 here

This post will also be covering everything from PR to releasing on a Kubernetes cluster. We will be skipping some of the basics of CI/CD pipelines and what they are, if you are not sure what that is check out this blog post on a mobile CI/CD here.

Git, pull requests and pipeline starting point

A theme with this guide will be getting free stuff wherever able, the cool thing about open source projects is there is a lot of options. For a good solid Git repo with a good pull request system and plugins to use all these free tools, you can’t go wrong with GitHub. Trunk based development for git is still the preferred method for having something easy to admin but fast to release. For setting that kind of environment up on GitHub as well as protecting your open source project, make sure you have the following settings:

In options:

In Data services, turn on “Security Alerts” to find out if any third-party libraries have a vulnerability and need you to update
In Merge button, turn “Allow squash merging” and “Automatically delete head branches” on and the others off. This will keep your Trunk/Master branch readable on what went out and when. This goes hand in hand with good pull request descriptions.

In branches:

Set your default branch to your Trunk/Master branch
Create a new branch protection rule for the Trunk/Master

Inside the branch protection rule:

Turn on “Require pull request reviews before merging” with at least 1 approval needed. This will stop anyone from pushing code right into the master branch and instead need a code review before merging.
With “Require pull request reviews before merging” the option to turn on “Dismiss stale pull request approval when new commits are pushed” appears. This will help if someone has already had their code reviewed but then adds the dreaded “just one more quick fix” to their PR from being able to merge the code without at least 1 reviewer re-checking the PR.
Turn on “Require status checks to pass before merging”. This won’t have much of an effect yet but as we get further down we can come back to this rule and set up plugins to prevent PR’s from being merged before checks are complete.

There are other things you can set up here for to depending on what you need such as Wikis and Social Preview images but you can play around there for whatever suits your project best.

SonarCloud

One important thing to add to your pipeline is static code analysis. This doesn’t replace the need for other engineers reviewing code, rather it acts as an extra reviewer who is obsessed with code rules. The tool we are going to use in this setup is SonarCloud as it’s free for open-source code and easily plugs into GitHub. You can sign up for a SonarCloud account by using your GitHub auth, this way you can point it to your project so it can analyze it in just a couple of steps. You can set the code analyser to fire every time you trigger a build and it will comment on the pull request. It will cover a range of rules from code duplication, vulnerabilities including OWASP Top 10 bugs, and Unit test coverage. Going back to GitHub as well, we can now set the “Require status checks to pass before merging” to require SonarCloud to pass before allowing merging.

DockerHub

So while there are more feature-rich automated building tools available, if your plan is to containerise your program using Docker then there is a simple automated builder in Docker called DockerHub. Before you sign up for that it’s better if you set up a working docker file for your Go program.

So for Turtle Wear the docker image is quite simple and looks like this:

FROM golang:alpine AS builder

RUN apk update && apk add --no-cache git ca-certificates 
&& update-ca-certificates
RUN adduser -D -g '' appuser

WORKDIR $GOPATH/src/turtle-wear-api

COPY . .

RUN go mod download && go mod verify
RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go test -cover ./...
RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=0 
go build -o /go/bin/turtle-wear-api ./cmd/turtle-functions/main.go

FROM scratch
COPY --from=builder /etc/ssl/certs /etc/ssl/certs
COPY --from=builder /etc/passwd /etc/passwd
COPY --from=builder /go/bin/turtle-wear-api /go/bin/turtle-wear-api
USER appuser
ENTRYPOINT ["/go/bin/turtle-wear-api"]

Credit to Nathan Dane for showing me his implementation and working with me on modifying it for the project needs.

With Golang you can get your unit tests running right inside the docker image as well. The line “RUN GOOS=linux GOARCH=amd64 CGO_ENABLED=0 go test -cover ./…” is what runs all the unit tests in the app and will fail the build if one doesn’t pass. Also the line “RUN apk update && apk add —no-cache git ca-certificates && update-ca-certificates” was needed otherwise the container couldn’t make external requests.

Once you have a docker file setup and working, Login to DockerHub and click “Create repository”. Add a name and a description, select public and then connect up your GitHub account and point it to your Golang build with the docker file. From here DockerHub will take the first build and if it’s all working put the image up ready from use. In the same way we did with SonarCloud we can go back to GitHub and set the “Require status checks to pass before merging” to require DockerHub to pass before allowing merging.

Kubernetes in Google Cloud Platform

“Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery.” Is the business talk way of explaining what they are. In very layman’s terms, it’s a way to deploy containers that are self-sustaining, update automatically, and can grow and shrink as demand requires.

There are a few different services to get Kubernetes up and running easily enough, AWS has EKS, Azure has AKS, IBM has… IBM Kubernetes, and Google have GKE. GKE is what we will be using for this guide as it’s the right balance between giving you control and doing things for you. Plus they give you $300 free credit to use in your first year so you can learn the system safely.

To start with, create a new project on the Google Cloud Platform. To do this, first go to the sidebar, click “IAM & admin” then “Manage resources”. On this page click Create Project, then in the new project window that appears, enter a project name and other applicable details, then click create.

With that setup, you can now navigate to the Kubernetes Engine in the same left sidebar and click on clusters. Click on create cluster and you should be brought to a new screen with a lot of options. First pay attention to the very left-hand side, here are some templates with descriptions to make choosing the right cluster easier. For the purpose of this guide, we will be using “Your first cluster” as it’s the cheapest and what we are looking for. If you are building something that has higher requirements then feel free to select a different template.

After selecting your template you can move over to the next section to the right. Starting from the top we have Name which is simple enough. deally, remember to name it with “cluster” at the end as you will be naming a few things when setting this up and it’s good to keep a naming convention for clarity later on. Next is Location type, choose zonal unless you really need always-on coverage assurance. Zone or Region just allows you to select where your cluster is hosted. Everything else here is fine as standard for whatever template you’ve chosen, click create when you’re ready. Once that’s done you will be back on the Clusters screen, give your new cluster a few minutes to finish setting up before continuing on.

Not ready yet

Green tick is good to go

Next, we need to deploy our container, so click Deploy at the top of the clusters screen. The screen shows Container first, we can take the image path from our DockerHub build, press done then continue. It then moves on to Configuration, here you can name the Application and Namespace, again name them “app” and “namespace” at the end to keep that clarity. At the bottom, it allows you to select your newly created cluster then click Deploy.

More loading times

This will bring you inside the deployment details page, the next thing to do here is on a prompt near the top of the page which mentions exposing the service. If you click that you will go to another screen where you can map the port for inside the container and the outside world. I highly recommend keeping the port to 80 but using whatever port you have set up inside your code for the target port. Click Expose here and it will start opening up the port.

With that all done you now have an External endpoint IP address. Use this to run tests on your code to make sure in the container is working correctly before moving on.

DNS Setup

With the IP address from GKE all setup the pipeline is complete, but there is some quality of life things we can do before we call it a full success. Firstly having a raw IP address isn’t the nicest looking way to connect up an endpoint, you can very easily use a web domain you have to be your new endpoint name. If you go to your DNS records for that domain and do the following:

Record type : A
Name : Your domain name but with “api. before it
Value : This is your GKE ip address

If you give it 5-10 mins for the DNS to propagate then give the same tests you were running on the IP address to the name in your DNS record you will find that everything works just the same but looks a lot nicer now.

Swagger docs

Allowing anyone to understand how your endpoints work and allow them to test them out is a great way to help people on board and save you a lot of time explaining how it works. Swagger Hub offers a pretty good free hosted setup so long as again it’s open source. The site has an editor and a coding mode so you can set up the page, I would recommend looking at one of their demo pages to understand the layout properly. You can check out the one I made for Turtle Wear API here

Wrapping up

There you go, you now have a pipeline so when you deploy new code to your Golang project it will check for code issues, run the unit tests, build into a container and then deploy to a scalable solution. This also wraps up the Turtle Wear trilogy of blog posts about my journey of doing a v2 of the app, hopefully it’s of some help to you!

Building a WearOS Watch face

Mon, 18 Nov 2019 00:00:00 GMT

Making a wearOS watch face and avoiding some of the faff. (TurtleWare 2.0 pt2)

This is part 2 of a 3 part blog post about making v2 of turtle wear watch face. You can check out part 1 here

Starting the project off

Starting off, WearOS is the same as Android for 99% of things. Meaning you can write the app Kotlin (or Java if you love some boilerplate) and use all the same Android libraries. So for folder structures and initializing the project can be done in Android Studio just like you would a phone app. For Turtle Wear 2.0, there are two important entry points. The CanvasWatchFaceService and the MainActivity.

CanvasWatchFaceService

The CanvasWatchFaceService is the place where you run all the watch face visuals. You set an inner class that contains a CanvasWatchFaceService.Engine() which deals with refresh speeds, ambient and active visuals, and custom tap commands. The CanvasWatchFaceService is pretty standard and should look something like the below:

class TurtleFace : CanvasWatchFaceService() {

  var specW: Int = 0
  var specH: Int = 0
  private val displaySize = Point()

  companion object {
    private const val INTERACTIVE_UPDATE_RATE_MS = 1000
    private const val MSG_UPDATE_TIME = 0
  }

  override fun onCreateEngine(): Engine {
    return Engine()
  }

  private class EngineHandler(reference: Engine) : Handler() {
    private val mWeakReference: WeakReference<Engine> = WeakReference(reference)

    override fun handleMessage(msg: Message) {
      val engine = mWeakReference.get()
      if (engine != null) {
        when (msg.what) {
          MSG_UPDATE_TIME -> engine.handleUpdateTimeMessage()
        }
      }
    }
  }

The inner class Engine has a lot more moving parts, but some bits to consider are:

Standard Android lifecycle events - So you can deal with the watch face starting, going into the background and being stopped when changed
onAmbientModeChanged - This is where you can control what you show and hide when the user is actively looking at the watch or not.
onTapCommand - This controls any custom action you want your watch face to perform, like a double tap to refresh the view
onDraw - The main visuals for your view go here rather than OnCreate
onApplyWindowInsets - This helps with different screen sizes (Round, flat tire, square) so your watch face fits all of them

MainActivity

This should be familiar to anyone who has made an Android app, this is where your android.intent.action.MAIN and android.intent.category.LAUNCHER is set to on the manifest. In this case, it will be the launch point for the settings app.

Setting up the simulator

There are a few catches with working on wearOS apps when it comes to debugging, especially with a watch face. The first being the standard configuration. This will always finish building with the settings app open, which if you are working on watch face changes is a bit annoying. It’s better to have this as the configuration settings.

This way the app will build but nothing will change on the device or simulator. Next is setting up devices to debug the build on. There are two options here:

Simulator

Open up the Android Virtual Device Manager for this and select “create a new virtual device” at the bottom. Choose WearOS as your hardware, Select Pie as the system image but don’t select the Chinese version unless you specifically want that, everything else is fine on default so you can click finish.

Device

For this method, you should have an Android phone or tablet connected to your workstation already. Make sure it’s got developer settings enabled and has allowed your workstation access. You also need the Wear OS app installed on that device and Bluetooth connected to the wearable.

Open the WearOS app on the Android device and scroll to the bottom where advanced settings are, at the bottom here is “Debugging over Bluetooth”. Turn that on and you should get “Host: Disconnected Target: Connected”. Once that’s done go into terminal and enter the following commands:

adb forward tcp:4444 localabstract:/adb-hub
adb connect 127.0.0.1:4444

Now your wearable should be fully connected and ready to debug

Manifest settings

When making a wearable app and specifically a watch face, there are some permissions you need to have set in the manifest. They are:

Required for any of this to work on a wearable.

<uses-feature android:name="android.hardware.type.watch" />

Required to act as a custom watch face.

<uses-permission android:name="android.permission.WAKE_LOCK" />

Required for complications to receive complication data and open the provider chooser.

<uses-permission 
android:name="com.google.android.wearable.permission.RECEIVE_COMPLICATION_DATA"
/>

Another set most apps will likely need is internet access, you will likely also need Bluetooth access as part of this if you want to communicate with the connected device.

<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.BLUETOOTH" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.FOREGROUND_SERVICE" />

Slightly less important is location services, Turtle wear needs this information to get weather data for your location.

<uses-permission android:name="android.permission.ACCESS_COARSE_LOCATION" />
<uses-permission android:name="android.permission.ACCESS_FINE_LOCATION" />

For the CanvasWatchFaceService, it need to be declared specifically as a watch face. So we start by flagging it as a service and giving it the Bind Wallpaper permission.

<service
android:name=".watchface"
android:label="@string/my_name"
android:permission="android.permission.BIND_WALLPAPER">

Next, we set up the metadata for the watch face and what the watch face example screen looks like on a square and circular screen type. The examples are used when the user selects the watch face from the selection screen.

<meta-data
android:name="android.service.wallpaper"
android:resource="@xml/watch_face" />
<meta-data
android:name="com.google.android.wearable.watchface.preview"
android:resource="@drawable/preview_digital" />
<meta-data
android:name="com.google.android.wearable.watchface.preview_circular"
android:resource="@drawable/preview_digital_circular" />

The last part is identifying it as a watch face.

<intent-filter>
<action android:name="android.service.wallpaper.WallpaperService" />
<category 
android:name="com.google.android.wearable.watchface.category.WATCH_FACE" 
/>
</intent-filter>
</service>

The main activity manifest setup is thankfully very default android.

<activity
android:label="@string/app_name"
android:name=".MainActivity">
<intent-filter>
<action android:name="android.intent.action.MAIN"/>
<action android:name="android.intent.action.VIEW"/>
<category android:name="android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>

Important

Without this inside the application area of the manifest, you will not be able to make any API calls out from the phone on newer devices. The error messaging on this is vague so it took ages for me to find this.

android:usesCleartextTraffic="true”

Drawing the watch face

If you check most places for how to draw the watch face, you will generally see very large OnDraw functions that require canvas drawing. I instead prefer to use xml layouts in the same way you would with an android application. This is a little less efficient but a lot more readable code in my opinion. To set this up first have a lateinit View outside the engine. Then on the OnCreate you inflate it like this:

val inflater: LayoutInflater = 
getSystemService(Context.LAYOUT_INFLATER_SERVICE) as LayoutInflater
watchLayout = inflater.inflate(R.layout.watchface, null)

With the view now inflated, you can set it up with the screen dimensions on the OnDraw like below.

watchLayout.measure(specW, specH)
watchLayout.layout(0, 0, watchLayout.measuredWidth, watchLayout.measuredHeight)
canvas.save()
canvas.translate(mXOffset, mYOffset - 40)
watchLayout.draw(canvas)
canvas.restore()

With that done, you now call any element you need to update wherever you need. For example, this is called on the OnDraw elsewhere for showing the current time.

private fun setTimeandDate() {
      val now = System.currentTimeMillis()
      mCalendar.timeInMillis = now
      val date: TextView = watchLayout.findViewById(R.id.date_number)
      date.text = String.format("%02d/%02d", 
      mCalendar.get(Calendar.DAY_OF_MONTH), 
      mCalendar.get(Calendar.MONTH) + 1)
      val hour: TextView = watchLayout.findViewById(R.id.hourtime)
      hour.text = String.format("%02d", mCalendar.get(Calendar.HOUR_OF_DAY))
      val min: TextView = watchLayout.findViewById(R.id.mintime)
      min.text = String.format("%02d", mCalendar.get(Calendar.MINUTE))
    }

Finishing it up and launching

That’s mostly in terms of the tricky bits of getting the Turtle wear v2 up and running. The Google play store takes submissions to it just the same as it would an Android app.

You can check the github repo here
You can download the watch face here
If your interested in taking your build further with a CI/CD pipeline, I’ve got a blog post all about how to set one up here

Making a Smart Mirror

Thu, 10 Oct 2019 00:00:00 GMT

A smart mirror build with spotify added in

So for a challenge, I wanted to try and make a Smart Mirror. I wanted to make it functional as a mirror but also cool and with handy extras like USB charge ports and music.

Things needed

A screen: I pulled the one I am working with from an old Samsung laptop. You can find controller units on Amazon or Ebay that turn it into standard monitor with ports and controls. Or you can take out the screen from any monitor really.

A raspberry Pi: Pretty standard, the one in this build is a Raspberry Pi 3 Model B+ but I think you can get away with older models, just don’t select a Raspberry Pi Zero as it’s not got enough power to run everything.

A Speaker: If your going to play music from it you need to have at least a passable speaker connected.

A USB Hub: This helps power your Pi and Speakers so you won’t need a million cables coming out the back of the mirror.

A Mirror: The mirror I’m working with is a dressing table mirror but you can use just about anything.

Tools and Materials to put it together: For this build I used wood to build a backing area where I could place everything nicely but you can do whatever is best for your setup. For the front I got a 2 way plastic mirror on Amazon that was close enough to the right size it just needed a bit of a trim on the edges

Cables to connect everything together: HDMI Cable, USB to micro usb cables, male to male audio cable, power cable for the monitor all needed.

Setting up the Pie

We will be using MagicMirror² for this build, make sure to read up on how to auto start the mirror too here.

Initially, I had planned on using Google assistant but as the build started Google deprecated the usage so instead to make sure we can have music we can use Raspotify for music, this had a bit of an issue with the HDMI so make sure you check out this if you have the same problem HDMI boost config

Honestly once they are working it was smooth sailing!

Installation

First I made sure the screen fit into the wood I had cut out. Made sure to use tape to seal any extra light from things like the pie showing up mirror side.

Also useful for securing it in place

Next I made sure everything was going to fit and cut holes for all the items to be accessible from the back

Finally I turned it all on without the new glass in to make sure it was working.

All Done

Making a middleware API layer in GO

Sat, 21 Sep 2019 00:00:00 GMT

How to teach yourself a new language and the advantages of a middleware API (TurtleWare 2.0 pt1)

History time

A couple of years ago, I knocked together a little watch app for the guys at Turtlecoin. I wanted to understand both Wear OS and Kotlin better, so a simple watch face that pulls data from a few exchanges for a price seemed easy enough.

An issue I had at the time was the watch face needed to be able to deal with all the API calls, parsing, sorting the value out, reacting to user settings and displaying. The version of Wear OS at the time didn’t even let you make API calls, which ended up forcing me down a companion app route on Android. This move, unfortunately, made all iOS or Wear only users unable to use the watch face. This was something that always bothered me, but I was working on other projects so I didn’t have time to really come back to it.

Move ahead to the present, with WearOS now allowing Http requests, most of the exchanges I used for grabbing the price of the coin had vanished, and Google had started depreciating their weather API, the watch face needed a lot of work to be usable.

Middleware

History lesson aside, why build a middleware API?

No need to redeploy the app - In the time my app was out, almost every API it accessed was either gone or under threat of deprecation. This requires me to make a new version of the app, release it as an update to the app store, and the whole userbase to update or else their watch face will continue to not work. With a middleware, all I would need to do is update the API it with a new source, deploy, and all the watch faces instantly get back in action.

Improve readability of app - A good 50% of the watch face app was JSON parsing and working out the price. When you move all that parsing and logic to the middleware, all the watch face needs to do is receive the API info and display it. With all that code removed, what’s left is far easier to read.

Get Go(lang)ing

The best way I find for learning new languages is just trying things out based on how I think it will work, getting it wrong, looking up how to make it work, and finally fixing it. It’s a great feeling as you go through your project and you notice you are getting more and more right first time.

So for example when I first built this handler for listening and serving Http. I had set it up like this:

func serveCoinValue(w http.ResponseWriter, r *http.Request) {
        Usd: "$" + priceCalculator.PriceCalc("USD", 
        priceCalculator.ExchangeOgre), 
		coinval := coinValue{"$" + priceCalculator.PriceCalc("USD", 
		priceCalculator.ExchangeOgre),
        Btc: "₿" + priceCalculator.PriceCalc("BTC", 
        priceCalculator.ExchangeOgre), "₿" + 
        priceCalculator.PriceCalc("BTC", priceCalculator.ExchangeOgre)}

	js, err := json.Marshal(coinval)
	if err != nil {
		http.Error(w, err.Error(), http.StatusInternalServerError)
		return
	}		}
	return bk, nil	
	w.WriteHeader(http.StatusOK)
	w.Header().Set("Content-Type", "application/json")
	w.Write(js)
    }

It worked, as in it passed JSON over, but there were some issues. Firstly, if I want a handler for another call like getting the weather, I will have to make a second handler. Secondly, this call reacts to any Http request with this response, no thought about malformed requests or proper error handling. So with some googling and refactored my second pass looked like this:

func handleEvent() http.HandlerFunc {
	return func(w http.ResponseWriter, 
	r *http.Request) {
		var (
			js []byte
			err error
		)

		switch r.URL.Path {
		case "/coin":
			js, err = json.Marshal(price.Calc(price.TradeOgre, 
			price.BtcFiatPrice, 
			getjson.Map))
		case "/weather":
			lat := r.Header.Get("lat")
			lon := r.Header.Get("lon")
			if len(lat) <= 0 || len(lon) <= 0{
				http.Error(w, 
				"Missing Lat Lon Headers", 
				http.StatusInternalServerError)
			} else {
				js, err = json.Marshal(weather.Getter(lat, lon, 
				weather.OpenWeather, getjson.Map))
			}
		default:
			w.WriteHeader(http.StatusNotFound)
			_ , err = w.Write([]byte(`{"error": "nothing found"}`))
		}

		switch r.Method {
		case "GET":
			w.WriteHeader(http.StatusOK)
			w.Header().Set("Content-Type", "application/json")
			_ , err = w.Write(js)
		default:
			w.WriteHeader(http.StatusNotFound)
			_ , err = w.Write([]byte(`{"error": "nothing found"}`))
		}

		if err != nil {
			http.Error(w, err.Error(), http.StatusInternalServerError)
		}
	}
}

This allows to have a single error handler that handles different calls and gives the correct response and is easy to call or mock out for tests.

Another important thing when learning a language is to avoid 3rd party libraries where possible. While Gorilla Mux makes complicated handlers and routers easier and setting everything to work as a AWS lambda function is really cool, you won’t really understand the problem they fix if you use them from the very beginning.

Test all the things

Writing and covering your project in tests is another great way to refine your knowledge and improve your code. While TDD/BDD is great for languages you are comfortable in, when learning a new language, building your unit tests after you’ve built your project works better. Writing tests for something you can’t even conceptualize is really hard and could triple the time before you get that first “it works!” moment. If you write the tests after you have that moment then you can refactor that code down to work with the tests and learn mistakes you made earlier on. As an added bonus, I think doing it this way when learning really gives you an appreciation of how unit tests can help you write better code and make sure it’s working before it goes to production.

Writing tests in go is also super simple, by passing functions in your code you can create mock versions easily in your tests, like below:

func TestOpenWeather(t *testing.T) {
result, result2 := OpenWeather("12", "12", testJsonRetriever)
if result != "test" || result2 != "47" {
	t.Error("OH NO")
}
}

func testJsonRetriever(fullUrl string, 
client *http.Client) map[string]interface{} {
	stubbedResponse := []byte(`{"weather": [{"main": "test"}, 
	{"main": "fail"}],
	"main": {"temp": 47}}`)
	var result map[string]interface{}
	jsonErr := json.Unmarshal(stubbedResponse, &result)
	if jsonErr != nil {
		log.Fatal(jsonErr)
	}
	return result
}

Finishing up

The end result for me was a nice little 350ish line Golang project. Which you can check out the code for here or if your interested in seeing it working you can use the swagger doc here. I would love to get feedback on ways to improve what’s here or why I’m wrong.

This is part 1 of a 3 part blog talking about making version 2 of the watch app. In part 2, I will be going into the WearOS and Kotlin work of the watch app. Part 3 will be about containerizing, automating and deploying everything.

Making a simple crypto trade bot

Sun, 26 May 2019 00:00:00 GMT

A guide on making a simple bot that can trade while you focus on the hard stuff

The Bot

The bot we are going to be setting up today is called Freqtrade. It’s a very easy to set up bot that can be controlled via Telegram . As we are not going to be using the codebase on our machine, the only file you need from their GitHub is this json file. If you copy the lines of this file and paste them into a text editor (I recommend Sublime text) and save the file as config.json.

Now lets have a look at the config file, the first important part is these two lines

“max_open_trades”: 3,
“stake_amount”: 0.05,

These lines are where you setup how much the bot is going to be using to make it’s trades, so in this example it’s making 3 trades of 0.05 BTC so in total 0.15 BTC needs to be in the account for it to trade effectively. You can change both numbers up or down as much as you like, just make sure you have at least the amount of funds inside for it to make the trades. Remember the more you put in the bigger the reward but the bigger the risk.

The next section is about setup strategy. The best thing to do here is leave it alone for your first couple of weeks, the bot learns as it trades (real transactions only) so let it go for a bit before changing something. If you do want to tweak rules later Freqtrades documentation is here

The Exchange

The next important bit is the exchange, for this we are going to be using Binance so sign up or in here https://www.binance.com/?ref=27977821 to continue. Once signed in, go to your account and press the API settings button. Name your new API ‘my trading bot’ or something to that effect so you know what the keys relate to. Binance will then take you through a series of steps on setting this up, the important thing to remember is that both Read Info and Enable Trading are checked and Enable Withdrawals is unchecked. Once it give you the keys, copy them both and keep them somewhere safe! You will never see the secret key again and will have to redo this part of the process again if you lose it. Now go back to your config.json file and change the following:

name needs changing from “bittrex” to “binance”
replace “your_exchange_key” with your API Key from Binance
replace “your_exchange_secret” with your Secret Key from Binance

Before we leave this section, now is a good time to put your BTC your trading with into Binance we talked about further up the guide, it is recommended to put a little more than the planned amount in to allow for the bot to make a couple early mistakes while it learns and improves.

The next section is the pair_whitelist and pair_blacklist The whitelist is all the currency’s you want the bot to be watching, I would recommend going for 10 to begin with. As for the blacklist, we only need to have BNB/BTC in there as the bot gets confused with Binance using BNB to discount fee’s

The Communication

The next important section of the config file for now is the Telegram section. This will allow you to get updates from your bot and send it commands like stop/start etc. Firstly on Telegram, message @BotFather with /start followed by /newbot and follow it’s instructions to get your new bot. Copy the HTTP API token it gives you and paste it to replace “your_telegram_token”. Next message @get_id_bot with /start and it will give you your chat ID copy it and paste it to replace “your_telegram_chat_id”. This means that your bot will only reply to your ID and ignore any other.

The Server

With that all done, the final step is to set this all up, Vultr is a server hosting which this referral code https://www.vultr.com/?ref=8109640-4F it gives you $50 free credit, the server we well be setting up is only $5 a month so that’s 10 months of free trading! Once you sign up and follow the instructions Vultr gives, it’s time to set up the server. Press Deploy new server and select Vultr Cloud Computing, choose the region you would prefer, select Ubuntu as the OS and 16.04 x64 as the version, selected the $5 25GB SSD as your server size. Once that’s all selected click deploy now and wait for Vultr so set it all up for you, this will take a few mins. Once it’s finished click on the server name and click on the view console icon at the top left and log in. There is going to be a series of commands here to get things setup so just type them in one at a time.

apt-get update
apt-get install docker-ce
systemctl enable docker
docker pull freqtradeorg/freqtrade:develop
docker tag freqtradeorg/freqtrade:develop freqtrade
docker build -t freqtrade .
docker build -f ./Dockerfile.develop -t freqtrade-dev .
mkdir ~/.freqtrade
cd ~/.freqtrade
mkdir user_data

Once that step is done we need to transfer the config file to the new folder. There is a few different ways to do this, the simplest for most users is to ssh move the file. To do this, open up a command line terminal, navigate to the folder you saved the config.json file and get the ip address of your Vultr server ready and enter the flooring

scp config.json root@[enter\_your\_ip\_here]:/root/.freqtrade
touch tradesv3.sqlite
scp tradesv3.sqlite root@[enter\_your\_ip\_here]:/root/.freqtrade

The Big Finale

Finally go back to your Vultr terminal, it’s time for everything to come together. Run the following command

docker run -d --name freqtrade -v /etc/localtime:/etc/localtime:ro 
-v ~/.freqtrade/config.json:/freqtrade/config.json 
-v ~/.freqtrade/user_data/:/freqtrade/user_data 
-v ~/.freqtrade/tradesv3.sqlite:/freqtrade/tradesv3.sqlite 
freqtrade --db-url sqlite:///tradesv3.sqlite

If everything was done right, you should get a message on Telegram that your bot has started. Now it will start scanning the selected currencies for movements and buy and sell as appropriate.

Congrats on your new bot!

CI/CD for Mobile Development

Sat, 13 Apr 2019 00:00:00 GMT

A guide on minimizing faff and getting a scalable team moving faster

Caveats and Preamble

Before you start on this path, a few assumptions have been made, mostly for the sake of not explaining everything. It is assumed you are comfortable with Git, Unit and UI testing, and have admin rights to any systems to want to integrating into. Also don’t take this as by the letter solution, use it as a way to try things out and explore options not mentioned.

What is CI/CD?

CI/CD stands for continuous integration / continuous delivery. The CI part is the goal of having code automatically built into an application and ran against automated tests to allow engineers to commit code more frequently and react faster to any issues. The CD part is built applications being available to different environments, exploratory testing and eventually deployment to the app stores. Both parts work together when you work with a pipeline, have good code coverage and a easy to follow process for everyone that isn’t time consuming.

CI/CD works best when you have a team of engineers working on a product together, but don’t need to be living in each others pockets knowing what they are working on. The squad model is a good example of what I mean here. It also works well for a single developer trying to save precious time normally wasted on repetitive tasks outside of improving their app. Utilizing small, fast, incremental changes will mean no one is getting stuck behind a massive pull request or finding out their code is conflicting with someone elses 2 weeks later.

Building a pipeline with Bitrise

The step towards a CI/CD workflow is getting a automated pipeline. This will listen out for certain triggers and fire a series of automated tasks out from it. There are a number of good pipeline CI/CD tools out there today. Bitbucket and Azure devops have built in solutions, Jenkins, Team City and Circle CI are great stand alone options with good integrations with most languages and systems. As this is focusing on mobile development, We will be using Bitrise.

Bitrise offers a Hobby tier which is free to use. Their limits on build times in this band are a quite lean but work if you are investigating options or just starting out a project and don’t have a lot of code down yet, other than that you have the exact same tools available to you as a larger company using the service. Once signed up you can hook your git repository of choice in with it’s step by step starting guide, at the end of that it will spit you out an app dashboard with a test build running and you on the builds tab.

From here, click on the settings tab first, review all the options in here including that your build number, default branch, app name & SSH is all correct. I would also recommend turning on ‘enable rolling builds’ here, it will help if your firing a lot of builds off quickly so you don’t end up with a giant queue of builds that don’t need to be built anymore. Next, check over the code tab and configure a web hook to your git repository, this is important as this the link bitrise needs to listen for branch changes. Once that’s sorted head into the workflow tab.

Here you will have several tabs based on your app type, the important ones to cover here are Workflows, Env Vars, and Triggers the rest are situational and are mostly not needed right now. Starting with Workflows, this is the main area of Bitrise and where you will be spending most of your time when building and improving your pipeline. Using the mindset of having reusable components, I found the best way to structure a Bitrise workflow is the following:

Step

This is the inner part of every workflow, some ones pre setup that are useful are Activate SSH key, Git Clone Repository and Bitrise.io Cache:Pull. If you click the + symbols in between the steps you can grab from a library of pre-made steps that you just need to configure and use.

Workflow step

This is your a workflow that does a single purpose. So let’s say you wanted to have a step that runs your Unit tests, you would make a workflow called STEP-UNIT-TEST, and inside you would grab all the steps you need to complete that task and configure them.

Workflow build

This is what you call with your triggers. For example, if you wanted to make a build that runs when a PR is triggered, you would make a workflow called BUILD-PR and use the ‘add workflows before/after’ to add Workflow steps for all reusable parts you’ve made and add only a couple of steps for the specific requirements of the PR

For this, lets just build a basic workflow build that has two workflow steps. First workflow step we will make is STEP-PRE-BUILD, this should have the Activate SSH key, Git Clone and Pull cache regardless of platform. For iOS add your certificate and profile installer to the end, for Android add install missing Android SDK components and a gradle runner step where in the config you just have clean in the tasks to run. Note: We’re not going into specific config settings here, but make sure you check all the steps have the right paths or names on them as we go. Next make a workflow step called STEP-POST-BUILD, with this we can add Deploy to Bitrise.io, and Bitrise.io Cache Push.

With the pieces ready, let’s build a final workflow called BUILD-DEVELOP. In there, click on Add workflow before and select our STEP-PRE-BUILD, next click Add workflow after and select the STEP-POST-BUILD. With that done all you need to do is add steps to the BUILD-DEVELOP area, in Android this would be another gradle runner with the task “assemble” and in iOS you would most likely be using fastlane, so add that step in there. With all that configured, go back up a level by clicking on the project name at the top of the page, select the button Stat/Schedule a Build, scroll down to the Workflow dropdown and select your BUILD-DEVELOP step and start a build. If you have configured it correctly, it should create a build ready for you to use.

Static code analysis

One important thing to add to your pipeline is static code analysis. This doesn’t replace the need for other engineers reviewing code, rather it acts as an extra reviewer who is obsessed with code rules. There are a few different tools for the job, SonarQube is a good option if you are looking to host something locally and SonarCloud is very handy if you don’t want to host. Other options like Codacy and Teamscale offer a similar service, so find the one that supports your codebase best. Connecting it to your git repo and your pipeline, you can set the code analyser to fire every time you trigger a build and will comment on the pull request. They cover a range of rules from code duplication, vulnerabilities including OWASP Top 10, bugs, and Unit test coverage.

Unit & UI automated tests

I’m not going to go into how to write unit or UI tests here, that’s for a different post. This is more a short bit on what tests your pipeline should be looking for and what you should be doing. Unit tests should be on everything that can be tested in isolation, so don’t try and unit test a button click that uses platform logic, but do test that code that arranges strings alphabetically. Unit tests are generally cheap to run so regardless of the pipeline (Dev, Release, Test) it’s a good idea to have them run. UI tests on the other hand are far more brittle as any UI change on the app can break them as well as being very resource heavy. As such you should stick to having only a couple of them that run a happy path scenario and only run on a code merge build.

Getting past a git flow mentality

One thing that is important with when moving to a CI/CD way of working is handling git correctly. Most people are aware of git flow, and much like that “truly agile” company you always get told about, they only do it half right. However, to get the best out of CI/CD it’s better to throw git flow out completely and adopt trunk based development. Trunk based development is essentially a Master or Trunk branch that engineers will create short lived branches which contain a small amounts of work. Once the work has been done and tested by the developer, it’s put in a PR where the pipeline will run all your tests and static code checks along with a code review from others. This will give some certainty that what is going into Trunk is safe. Then to release a build live, you tag the Trunk at that point with the version and fire up a release build. You can make a release branch at this point, but I would suggest keeping it to tagging unless issues arise and Trunk has moved on already.

This, is almost guaranteed to have someone worried:

But what if someone pushes broken code up?

Well, if this is something you think your engineers will be doing often, you need to evaluate your hiring policies and interview criteria.

Seriously though, making pull requests mandatory on your Trunk branch is an easy way to help this process. Later on you will be hooking in a pipeline that will automatically build and run tests on the code that can pass or fail the PR on it’s own as well as static code analysis to really lock down any issue of a mistaken crash getting in.

How will I know what’s going into the codebase?

Another reason for Pull Requests but with the added need for concise commit messages and squashed commits. This allows a nice clean timeline on your trunk branch for any dev to read.

But how will we know when it’s time to release?

Always be releasing, if you have a Trunk with code constantly going into it and there isn’t stuff to release then you need to review the size of your tasks.

Won’t we get held up if we have to wait for code to be released with only one branch?

That’s the good part of the tagging system, you can focus the build on that release. If the build needs a fix, make a branch of that tagged version, once that branch has been released merge the release branch back to Trunk and continue on as normal.

Integrating with project management tools

A common disruption in Engineering is asking for progress updates, the usual issue is you have a varying level of interaction from dev to dev about how much they want to deal with this. One of the nicer things about automating a pipeline is you can automate some of this process. Jira ticket updating with status and build numbers, Slack messages and emails can all be sent out from the various build types to keep everyone who wants to know what the status of that important ticket in the loop.

Summary

Hopefully this has given you a good overview on setting up a basic pipeline and what you can do to make improve your process. There is a lot of tweaking and improving you can do from here. Automating version and build numbers, outputting unit test results to a webpage, even something fun like triggering a sound to play in the office every time a build goes live. Over time you should find you have to release more frequently as work ready for release it appearing faster and faster.

Sprint Planning Buckaroo

Sat, 02 Mar 2019 00:00:00 GMT

So, this sounds insane. But hear me out, it will make sense shortly

I, like many developers theses days work in a pseudo agile way. We write tickets, stick them on a board of some kind, then smash all the tickets into the QA ready column until the two weeks have passed, then release it. Couple of problems with this, one being the estimation system for what “enough work” is and the other being the fighting balance of getting the work product want, whilst also sorting tech debt.

It’s just a 5 min job right?

Time estimation is something almost all developers have to deal with, trying to convey to people who don’t exactly understand what your doing how long something they want will take. The simplest example of this is just estimating in hours or days. Other systems like sprint poker and points systems give a better idea of effort, while not giving the dev team a deadline, but they need your product team to understand what a single point is worth to really be relevant.

Don’t change that code now, it looks fine and we have all this to do!

The business must always be making new things, especially in competitive markets. But if the code has problems and is ignored by the company it will have to eventually face the dreaded re-write and we all know a horror story or two about that! Balancing this is hard, with normally one side winning out completely from the other, not exactly collaborative.

So… you said something about Buckaroo?

Yes, Sprint Planning Buckaroo.

Now you may have put most of the dots together at this point. Assign tickets to items in the game, throw them on the Bucking Donkey (Horse?) until it kicks, once he kicks that’s a full sprint. But let’s go into slightly more detail.

Firstly the important bit, all the bits of buckaroo weight different amounts. So by using that, you can pick your big wins to be the hat or the chest and your easy fixes to be the holster or the rope. There’s a list near the bottom of the weights of each item. Sometimes however it’s better to not share the exact weight out and let people add put their own notions of weight, whatever works best for your team.

Next you need your tickets. You want to make sure you have tasks broken down to their smallest parts that are safe to release to the wild. This should be pretty standard practice for most development teams but for anyone wanting to try who doesn’t normally sprint plan, this may help.

How to run a session

So now you have all your pieces, your work and more than likely your debt ready to go, how does it work? Well first you split the items by their colour, Red will be product, Blue will be debt, if you have a version with more colours then split the rest equally between the two main colours. If you have multiple disciplines of engineering (API, Web, Mobile, etc) make sure they all do their own Buckaroo’s worth of work. You don’t want three Web tasks, one API task and Mobile doing nothing all week.

Step one

Pick a ticket, go for high priority ones first and smaller ones near the tipping point. Red always goes first with the saddle so this can be the core bit or work that needs to be done, careful to make sure it’s a need not a want.

Step two

Agree upon an item to represent the ticket, the bigger task can be a hat while that smaller one shouldn’t be more than the rope for example.

Step three

Put that item on the buckaroo, carefully. There is a mulligan option if someone has an issue like sneezing or slipping while placing.

Step four

Repeat steps one - three again until it bucks, and there you have a sprint ready to go!

Cool, but why is this such a great idea then?

On the simplest level it makes it easy for everyone to understand workloads. Having something physical that will literally kick out when it’s had too much is much easier to understand than a ticket having an effort level of 5. It also makes it a system where no one is holding back work or adding too much, everyone will blame the Donkey (Horse?) for the workload being the workload. Finally, it’s fun, you literally get to play high stakes Buckaroo every time you need to plan a sprint.

So buy a copy of Buckaroo and have a go, leave me comments below on how it went over with your squad and any alterations you made, such as adding blu tak to certain items if you end up with a mega piece of work!

The Weights

Reds:

Hat - 11g
Blanket - 9g
Saddle- 7g
Dynamite- 5g
Shovel- 4g
Holster- 2g

Blues:

Chest- 11g
Lamp- 7g
Guitar- 6g
Watch- 5g
Pan- 3g
Rope- 3g

Note: I originally wrote this article on Medium in 2018, you can check it out (and give it a clap) here

Welcome to the Blog!

Fri, 15 Feb 2019 00:00:00 GMT

^An image of me making this blog

Seriously, thank you for taking the time to check out this blog. If your looking at this page then you are either someone I’ve forced into checking out the site, a robot, or someone looking for easter eggs.

All you will find here is me thanking you for checking out my site. If you are looking to help me out at all, click the links in the bar that I reference in my description blurb.