Your awesome title

Testing the new JetPack Compose Pt2

Thu, 25 Feb 2021 00:00:00 +0000

Part 1

Look here for Part 1 where I talk about testing loading data and UI updates from it

JetPack Compose

In case you hadn’t noticed there’s yet another UI framework/toolkit, JetPack Compose! On the surface it has a lot more in common with Google’s Flutter than the default Android View, it’s written in code (by default Kotlin) and as such is able to generate previews a lot simpler than when you have the XML, you don’t have to bind your ViewModels to the xml, you can just pass them into the functions!

Testing Android compose

I want to test some basic UI interactions, we have a list in a ViewModel, clicking a fab add an item to the list and the UI updates to show the list, I won’t go through setting up the activity etc, but essentially the activity grabs the viewmodel, call setContent with the theme>surface>initial composable. The initial composeable collects the players list as state and passes it and the addPlayer function to the PlayerList composable.

Some code

class viewModel : ViewModel() {
    private val _players = MutableStateFlow(listOf<Player>())
    val players: StateFlow<List<Player>>
        get() = _players

    fun addPlayer(name: String) {
        _players.value = _players.value + Player(name)
    }
}

and our composable looks quite simple for this

@Composable
fun PlayerList(players: List<Player>, addPlayer: (String) -> Unit) {
    Scaffold(floatingActionButton = {
        FloatingActionButton(
            onClick = { addPlayer("Player #${players.size}") },
            content = { Icon(Icons.Filled.Add,    "Add new player") },
        )
    }) {
        ScrollableColumn(modifier = Modifier.fillMaxWidth()) {
            players.map { PlayerDisplay(player = it) }
        }
    }
}

@Composable
fun PlayerDisplay(player: Player) {
    Row() {
        Text(text = player.name, softWrap = false)
    }
}

and then in our composable test we mock the viewmodel and alter the return of the property

class PlayerScreensTest {
    @get:Rule
    val composeTestRule = createAndroidComposeRule<MainActivity>()

    @Test
    fun PlayerListTest() {
        composeTestRule.setContent {
            MyTheme {
                val players by composeTestRule.activity.viewModel.players.collectAsState()
                PlayerList(players, composeTestRule.activity.viewModel::addPlayer)
            }
        }

        composeTestRule.onNodeWithText("Player #0").assertDoesNotExist()
        composeTestRule.onNodeWithContentDescription("Add new player").performClick()
        composeTestRule.onNodeWithText("Player #0").assertIsDisplayed()
        composeTestRule.onNodeWithText("Player #1").assertDoesNotExist()
        composeTestRule.onNodeWithContentDescription("Add new player").performClick()
        composeTestRule.onNodeWithText("Player #0").assertIsDisplayed()
        composeTestRule.onNodeWithText("Player #1").assertIsDisplayed()
    }
}

this all looks good, but when running this throws an error

2 files found with path 'META-INF/AL2.0' from inputs

So now we need to update our apps build.gradle file

android {
    // Added to avoid this error -
    // Execution failed for task ':app:mergeDebugAndroidTestJavaResource'.
    // > A failure occurred while executing com.android.build.gradle.internal.tasks.MergeJavaResWorkAction
    // > 2 files found with path 'META-INF/AL2.0' from inputs:
    packagingOptions {
        exclude 'META-INF/AL2.0'
        exclude 'META-INF/LGPL2.1'
    }
}

we can then run our tests successfully!

Testing the new JetPack Compose

Tue, 10 Nov 2020 00:00:00 +0000

JetPack Compose

Testing Android compose

There are a few good resources out there for testing JetPack’s new Compose functionality

but the scenario I was struggling to test was passing ViewModel into an upper composeable, I was mocking the ViewModel but I kept getting an error

Some code

open class ImageListViewModel : ViewModel() {
	private val _isLoading = MutableStateFlow(false)
	val isLoading: StateFlow<Boolean>
		get() = _isLoading
}

and our composable looks quite simple for this

@Composable
fun ImageListScreen(viewModel: ImageListViewModel) {
	val isLoading by viewModel.isLoading.collectAsState()
	val imageItems by viewModel.imageItems.collectAsState()

	if (!isLoading && imageItems.isEmpty()) {
		Text(text = "No data available")
	} else {
		Text(text = "I have data")
  }
}

and then in our composable test we mock the viewmodel and alter the return of the property

@RunWith(MockitoJUnitRunner::class)
class ImageListTest {
	@get:Rule
	val rule = createAndroidComposeRule<MainActivity>()

	@Mock
	lateinit var viewModel: ImageListViewModel

	@Test
	fun imageListScreen() {
		val isLoading = MutableStateFlow(false)
		val imageItems = MutableStateFlow(listOf<ImageItem>())

		`when`(viewModel.isLoading).thenReturn(isLoading)
		`when`(viewModel.imageItems).thenReturn(imageItems)

		rule.setContent {
			MinderaTheme(darkTheme = false) {
				ImageListScreen(viewModel = viewModel)
			}
		}

		rule.onNodeWithText(text = "No data available").assertIsDisplayed()
	}
}

but as I say, this throws an error

org.mockito.exceptions.misusing.MissingMethodInvocationException: 
when() requires an argument which has to be 'a method call on a mock'.

This is when using androidTestImplementation "org.mockito:mockito-android:3.5.10"

But the catch is that the tests for compose run on a device, not on the jvm, so when we boot the emulator and try to run the test mockito can’t work correctly as mockito uses CGLib or ByteBuddy, both of which generate .class files. When running on an Android device or emulator we need .dex files instead.

We do have a couple of options, there are other mocking frameworks out there, personally I like mockito, so we go with the other option, helping mockito to run on instrumented tests.

dexmaker

We can change our dependencies a bit to make mockito work with instrumented tests

-- androidTestImplementation "org.mockito:mockito-android:3.5.10"
++ androidTestImplementation "org.mockito:mockito-core:3.5.10"
++ androidTestImplementation "com.linkedin.dexmaker:dexmaker-mockito-inline:2.28.0"

Dexmaker here works with mockito to generate .dex files, and since mockito inline can work with private/closed/final classes/functions we can remove the open from the ViewModel.

We then need to update our test file slightly, we want to use the default AndroidJUnit runner, and now we need to initialise mockito annotations manually

@RunWith(AndroidJUnit4::class)
class ImageListScreenKtTest {
	@get:Rule
	val rule = createAndroidComposeRule<MainActivity>()

	@get:Rule
	val initRule: MockitoRule = MockitoJUnit.rule()
	...
}

we can then run our test successfully!

Securely inject API keys into your Android app during the build process

Tue, 20 Oct 2020 00:00:00 +0000

A bit of preamble, my gradle files are in kotlin, so my example code is similarly in kotlin rather than groovy

Pre-post Security Rant

When trying to figure out how to add api keys etc into an Android application I came across a lot of posts that used this as an example:

getByName("release") {
  buildConfigField("String", "SECURE_API_KEY", "\"SOMETHINGTHATSHOULDBESECUREPROD\"")
}
getByName("staging") {
  buildConfigField("String", "SECURE_API_KEY", "\"SOMETHINGTHATSHOULDBESECURESTAGE\"")
}
getByName("debug") {
  buildConfigField("String", "SECURE_API_KEY", "\"SOMETHINGTHATSHOULDBESECUREDEV\"")
}

Coming from a web dev fe/be background this makes me shake, you should never have these keys in your repositories, always inject them during build time. OK? OK.

Injecting api keys from environment variables

This actually took me a while to figure out, especially since I didn’t want to have to deal with environment variables when doing local development, it comes down to a few simple lines. During most builds we want to get it from the environment so we can simply do:

android {
	compileSdkVersion(TARGET_SDK_VERSION)

	defaultConfig {
		minSdkVersion(MIN_SDK_VERSION)
		targetSdkVersion(TARGET_SDK_VERSION)

		testInstrumentationRunner("androidx.test.runner.AndroidJUnitRunner")
		consumerProguardFiles("consumer-rules.pro")
		buildConfigField("String", "SECURE_API_KEY", "\"$System.getenv("SECURE_API_KEY")\"")
	}
}

Then during build time these buildConfigField are built into a java class with static final’s in, this file also contains a few other things, here’s an example of what it’ll look like:

package co.g403.android.apikeyblog;

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("false");
  public static final String APPLICATION_ID = "co.g403.android.apikeyblog";
  public static final String BUILD_TYPE = "release";
  public static final String SECURE_API_KEY = "SOMETHINGTHATSHOULDBESECUREPROD";
}

However for dev we want to do something slightly different. We don’t really want to mess around with environment variables.

gradle.properties

We can create a global gradle friendly file which can be read during build time too, if we create and save nano ~/.gradle/gradle.properties this will then also appear in our android projects and obviously wont be checked into version control, this will allow us to have different keys that a dev can use, and can be edited if we need to build different types without fear of accidentally checking the key into version control.

myApiKey=SOMETHINGTHATSHOULDBESECUREDEV

we can then read this in our build.gradle(.kts)

buildTypes {
  getByName("debug") {
    val myApiKey: String by project
    buildConfigField("SECURE_API_KEY", myApiKey)
  }
}

and then when built our BuildConfig.java is updated

package co.g403.android.apikeyblog;

public final class BuildConfig {
  public static final boolean DEBUG = Boolean.parseBoolean("true");
  public static final String APPLICATION_ID = "co.g403.android.apikeyblog";
  public static final String BUILD_TYPE = "debug";
  // Field from build type: debug
  public static final String SECURE_API_KEY = "SOMETHINGTHATSHOULDBESECUREDEV";
}

and that’s it! You now securely have API keys being injected during builds, with one that can easily be changed during development

Testing a Retrofit/RxJava Android library using Mockito

Tue, 15 Sep 2020 00:00:00 +0000

Tests in Android, say what?

There’s lots of blog posts out there with great examples on how to do certain things in Kotlin/Android, take this one for example. What there seems to be a lack of, in general, is how to write tests. There’s some simple explanations about for classic “addition” unit testing, you know, you send 2 numbers into a function and get the sum of them out, about as trivial and far from the real world as possible (unless you’re writing node modules, then there’s probably already one for it). There are a few examples of tests for full apps, tapping buttons and things like that, but what I wanted to test was a simple library, something reusable.

What I’ve been writing is a simple library for doing some network activity, going to flickr, fetching some images, all that jazz. We have a service interface that uses Retrofit 2 annotations and produces RxJava observables. We have a repository that takes the service as a constructor arg and uses the service to request some images, watches the observable and updates a Mutable/LiveData that an app/viewmodel/etc can observe for changes. This will get more complicated later involving pagination and updating etc, but this is the state of the library as I want to test it.

Repository testing and mocked network calls

Initially I want to test the repository, so that a known response from the api call produces consistent results to the client, the repository involves some transformation of the response, parsing/transforming it as needed, so sounds like a good candidate for our first set of tests. When writing js apps it’s most common to use axios for network traffic, and there’re many options for mocking that traffic during testing. Officially there’s moxios, mock adapter and unofficially network intercept apps like nock. Looking around Retrofit it has Retrofit-mock and so I started there. There wasn’t a lot of information out there, so I dove straight in and tried to see what I could make out, I ended up with a mockservice that produced network delegates and a brain that was streaming out through my ears, there had to be something better. I started to look at mockito to see if we could use that instead to mock our network traffic. This made the code a lot simpler, but I was still getting problems

Expected :<[SizedImage(id=1)]>
Actual   :null

Google was not helping with this, as I said there was not many posts about testing and only a tiny subset of them had testing Retrofit and RxJava. Don’t get me wrong, millions of posts about Retrofit and RxJava, but who wants to write about testing in a blog post…

Immediate Executor and Immediate Scheduler

So I turned to my trusty source for all things Android, my sister Maja. Her response: “Immediate executor for tests, Google it”, and doing so led me to this led me to this blog it seemed a bit out of date but was enough to get me to the end result I wanted. I added

@Rule
@JvmField
var rule = InstantTaskExecutorRule()

and created a custom scheduler rule

// Test rule for making the RxJava run synchronously in unit tests
companion object {
    @ClassRule
    @JvmField
    val schedulers = RxImmediateSchedulerRule()
}

and then we were all working perfectly, I was able to assert against the responses as expected and get passing tests! Amazing!

You can view the code and tests as is in a very incomplete git repo

AWS API Gateway part 2 - CORS 😱

Sun, 19 Apr 2020 00:00:00 +0000

After my last blog post we can start to make requests via axios to my API gateway. Hitting the gateway directly via postman or the browser worked fine, but with axios we were running into CORS issues. This is a super short blog detailing what we need to do to deal with these CORS issues. I’m not going to get into a big description about CORS because there’s a whole bunch of stuff about OPTIONS requests, origin headers and other boring stuff you can read elsewhere. We just want to know what to do to start making those axios requests right?

A request can either be simple, or not simple, simple right? If a request is non-simple, you need to enable CORS.
A request is simple if all of these are true:

The API you’re accessing only allows GET, HEAD, and POST requests.
If it is a POST request, it must include an Origin header.
Content-type can only be text/plain, multipart/form-data, or application/x-www-form-urlencoded.
No contain custom headers. See the AWS documention
Most API requests are going to be non-simple because we’re going to be making requests for application/json content, so we need to enable CORS.

There are 3 settings for this, all starting with Access-Control-Allow-, Headers, Methods and Origin. For developement we can just set all these to * and get on with poking some code around.
These go where we put the apigateway integration:

x-amazon-apigateway-integration:
  credentials: !GetAtt [ApiGatewayRole, Arn]
  uri:
    'Fn::Sub': 'arn:aws:apigateway:${AWS::Region}:dynamodb:action/Scan'
  responses:
    default:
      statusCode: '200'
      responseParameters:
        method.response.header.Access-Control-Allow-Headers: "'*'"
        method.response.header.Access-Control-Allow-Methods: "'*'"
        method.response.header.Access-Control-Allow-Origin: "'*'"

This will allow us to get up and running straight away, now to be more strict we want to specify what headers, methods and origins we’re allowing, what this actually does I think is set the response headers from the OPTIONS request which tells the client what it can do on this API. So at a minimum I think this should get us up and running, we want to allow the content-type header, we want to allow options and get requests, and for now the traffic will come from our local dev

        method.response.header.Access-Control-Allow-Headers: "'Content-Type'"
        method.response.header.Access-Control-Allow-Methods: "'OPTIONS,GET'"
        method.response.header.Access-Control-Allow-Origin: "'http://localhost:3000'"

Here’s an updated cloudformation-template.yml

And that should be it! Enjoy!

Using AWS to create a dynamodb driven API

Tue, 14 Apr 2020 00:00:00 +0000

In the previous post we created an Android app that displays some json data as a swipeable ViewPager, we stubbed the data for this app at the time. This time we’re going to be creating a dynamodb table driven API in AWS, cheap, simple and easy to maintain.

This is going to be a very brief run through on setting up a cloudformation stack, I’m not going to cover setting up aws or aws-cli, in another blog post I’ll do this same project but with AWS CDK.

The basic pattern is we have an API gateway, and a dynamodb table, we keep the data we want in the table and the api directly fetches the data from the table.

SAM CLI

We’re using SAM CLI for transforming our cloudformation template, so we need to ensure we have a line in the cloudformation template to make the transformation

Transform: AWS::Serverless-2016-10-31

API Role

We need to create a role with appropriate policies to fetch the data from the table.

  ApiGatewayRole:
    Type: AWS::IAM::Role
    Properties:
      ManagedPolicyArns:
        - 'arn:aws:iam::aws:policy/service-role/AmazonAPIGatewayPushToCloudWatchLogs'
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              Service: ['apigateway.amazonaws.com']
            Action: 'sts:AssumeRole'
      Path: '/'
      Policies:
        - PolicyName: DynamoApiPolicy
          PolicyDocument:
            Version: '2012-10-17'
            Statement:
              - Effect: 'Allow'
                Action:
                  - 'logs:*'
                Resource: '*'
              - Effect: 'Allow'
                Action:
                  - 'dynamodb:Scan'
                  - 'dynamodb:Query'
                Resource:
                  'Fn::Sub': 'arn:aws:dynamodb:${AWS::Region}:${AWS::AccountId}:table/*'

DynamoDB Table

We create the table with an id we intend to use as a uuid, and then a secondary sorting id, and obviously we don’t need to specify the structure of the table.

  DynamoDBTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: !Ref TableName
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
        - AttributeName: order_id
          AttributeType: N
      KeySchema:
        - AttributeName: id
          KeyType: HASH
        - AttributeName: order_id
          KeyType: RANGE
      ProvisionedThroughput:
        ReadCapacityUnits: '5'
        WriteCapacityUnits: '5'

API Gateway

And then we create the API gateway to fetch the data from the table

  ApiGatewayApi:
    Type: AWS::Serverless::Api
    DependsOn: DynamoDBTable
    Properties:
      Name: 'ServicesGateway'
      StageName: prod
      MethodSettings:
        - ResourcePath: '/*'
          HttpMethod: '*'
      DefinitionBody:
        openapi: '3.0.1'
        paths:
          /:
            get:
              responses:
                '200':
                  content:
                    application/json:
                      schema:
                        $ref: '#/components/schemas/Empty'
              x-amazon-apigateway-integration:
                credentials: !GetAtt [ApiGatewayRole, Arn]
                uri:
                  'Fn::Sub': 'arn:aws:apigateway:${AWS::Region}:dynamodb:action/Scan'
                responses:
                  default:
                    statusCode: '200'
                requestTemplates:
                  application/json:
                    { 'Fn::Sub': "{\n  \"TableName\": \"${TableName}\"\n}" }
                passthroughBehavior: 'when_no_templates'
                httpMethod: 'POST'
                type: 'aws'

We use the scan action on the table to fetch all the data in a single request, this will cause problems if the dataset is large but will do just fine for the small datasets we’ll be using in the example.

JSON Data

There’s a bit more setup but this is essentially it, we insert the data we want to use.

{
  "id": "12340d21-5843-4935-92a7-d4c26fff1b21",
  "order_id": 1,
  "authorText": "Pawełek Grzybek — Junior Developer",
  "companyText": "Mindera",
  "testimonialText": "Gabriel is an amazing developer and I'm so appreciative to have him as my Tech Lead, he's pretty too."
}

JSON Response & Transformation

When we make a request to fetch this we do get the dynamodb structure back in the response

{
  "Count": 1,
  "Items": [
    {
      "order_id": {
        "N": "1"
      },
      "testimonialText": {
        "S": "Gabriel is an amazing developer and I'm so appreciative to have him as my Tech Lead, he's pretty too."
      },
      "id": {
        "S": "12340d21-5843-4935-92a7-d4c26fff1b21"
      },
      "companyText": {
        "S": "Mindera"
      },
      "authorText": {
        "S": "Pawełek Grzybek — Junior Developer"
      }
    }
  ],
  "ScannedCount": 1
}

We can either transform this in the client calling this or we can add a response mapping transformation

#set($inputRoot = $input.path('$'))
{
    "testimonials": [
        #foreach($elem in $inputRoot.Items) {
            "testimonialText": "$elem.testimonialText.S",
            "companyText": "$elem.companyText.S",
            "authorText": "$elem.authorText.S"
        }#if($foreach.hasNext),#end
	#end
    ]
}

This turns our template file from fairly generic into something very specific, but makes our client a lot cleaner.

There’s some extra bits we can add in for a custom domain name, redundancy etc, otherwise we can access our api through the stand aws gateway address.

The cloudformation template for this is suprisingly simple, barely a hundred lines of yaml, a bit too much to display in-line so here’s the final file cloudformation-template.yaml

Deploying Stack

We can run it with

aws cloudformation deploy --template-file template.yaml --stack-name api-db-testimonals-stack --capabilities CAPABILITY_IAM --region eu-west-2 --profile gabriel403 --parameter-overrides TableName=TestimonalsTable

And that’s it! The API for our testimonial data is all setup!

Implementing ViewPager2 in a basic Android app

Mon, 30 Mar 2020 00:00:00 +0000

I’ve only been learning Android for the last 6 months or so, in my spare time, so this is 1st in a series of quick blog posts on implementing some features in an Android app. These will be fairly basic for most experienced people, but helped me and maybe help other new devs with getting to grips with these things.

You can find the code in a GitHub repo

ViewPager2

ViewPager allows us have a horizontal (and vertical) swiping component that populates from a series/list of various kinds, either Views, Fragements or data sources. ViewPager2 is built on RecyclerView, which gives us some improvements around performance, rtl support, and it means when we’re familiar with one, we’re mostly familar with the other. We can also add fancy animations as we swipe.

This is what we’ll be building

Basics & intro

This is not by any means comprehensive, but is from my perspective, ViewModels retrieve data from repositories, fragments observe the ViewModel’s data and apply an adapter against them, an Adapter converts the data from the ViewModel into something that can be bound to the individual ViewHolders, and this is what updates the UI when we swipe. We use databinding to to do a lot of the heavy lifting for us.

Getting started

We’re using the latest Android studio beta, but the latest stable Android studio should work fine. We create a new project with an empty activity to get started.

First we want to enable data binding in the app

Add this into the gradle file of your app module

buildFeatures {
  dataBinding = true
}

and we need to apply kapt plugin for databinding

apply plugin: "kotlin-kapt"

and then further down we add a dependency on the viewpager2 module, we also include lifecycle-extensions to remove a few deprecated statements

implementation "androidx.viewpager2:viewpager2:1.0.0"
implementation "androidx.lifecycle:lifecycle-extensions:2.2.0"

We then create a package to represent the data we want to use, in my example case testimonials, within that package a kotlin class called TestimonialAdapter, this will extend a ListAdapter inorder to bind a testimonial data object to the layout, we’ll fill this out a bit more later.
Alongside this we create a package called datasource and inside this a Testimonial class and a TestimonialRespository class, these are fairly simple, and in the repository we’ll just return some pre-defined objects rather than getting bogged down in network or databse requests.

Data data data

data class Testimonial(
  val authorText: String,
  val testimonialText: String,
  val companyText: String
)

class TestimonialRepository {
  private val testimonials = MutableLiveData<List<Testimonial>>()

  fun getTestimonials(): LiveData<List<Testimonial>> {
    testimonials.value = listOf(
      Testimonial(
        testimonialText = "Gabriel is an amazing developer and I'm so appreciative to have him as my Tech Lead, he's pretty too",
        authorText = "Pawełek Grzybek — Junior Developer",
        companyText = "Mindera"
      ),
      Testimonial(
        testimonialText = "Gabs is one of the best at what he does, always available for a job, clean, methodical",
        authorText = "Maja T — Przyjaciółka",
        companyText = "Trzebiatowska Crime Family"
      ),
      Testimonial(
        testimonialText =
        "Gabriel is such a mediocre game player he makes me look good, I appreciate that he holds back so much for me",
        authorText = "Ben R — bff",
        companyText = "Loser@Games Co."
      )
    )
    return testimonials
  }
}

Infrastructure

Next we’re going to create a view to represent the testimonial and a fragement/viewmodel to hold them and give them some context.

Create a new toplevel package ui, and within that a package home, and then create a new fragment (with viewmodel) within that.

app/
- testimonials/
  - TestimonialAdapter
  - datasource/
    - Testimonial
    - TestimonialRepository
- ui/
  - home/
    - HomeFragment
    - HomeViewModel

And then within out layouts folder we want

layout
- home_fragment
- testimonials_layout
- testimonial_layout
- activity_main

So far we’ve covered the Testimonial data class and TestimonialRepository class, we’re going to switch focus for a bit and look at our layout files.

Layout files

Our testimonial_layout is a simple file that binds with the Testimonial object uses TextViews to output the data contained within the individual Testimonial, this is the layout that the ViewPager uses, and to which we bind the individual Testimonial objects

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools">
  <data>
    <variable
      name="item"
      type="co.g403.android.viewpager2demo.testimonials.datasource.Testimonial" />
  </data>

  <LinearLayout
    android:id="@+id/testimonials_view_pager_container"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    android:orientation="vertical"
    android:paddingStart="16dp"
    android:paddingTop="40dp"
    android:paddingEnd="16dp"
    android:paddingBottom="40dp"
    tools:showIn="@layout/home_fragment">

    <TextView
      android:id="@+id/testimonial_text"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"
      android:textAlignment="center"
      android:textColor="#222222"
      android:textSize="20sp"
      android:text="@{item.testimonialText}"
      tools:text="Gabriel is cool" />

    <Space
      android:layout_width="match_parent"
      android:layout_height="20dp" />

    <TextView
      android:id="@+id/testimonial_author"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"
      android:textAlignment="center"
      android:textColor="#222222"
      android:textSize="18sp"
      android:text="@{item.authorText}"
      tools:text="Ben R — bff" />

    <Space
      android:layout_width="match_parent"
      android:layout_height="20dp" />

    <TextView
      android:id="@+id/testimonial_company"
      android:layout_width="match_parent"
      android:layout_height="wrap_content"
      android:textAlignment="center"
      android:textColor="#444"
      android:textSize="16sp"
      android:text="@{item.companyText}"
      tools:text="Loser@Games Co." />

  </LinearLayout>
</layout>

and the testimonials_layout is the container for our ViewPager2

<?xml version="1.0" encoding="utf-8"?>
<LinearLayout xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools"
  android:layout_width="match_parent"
  android:layout_height="match_parent"
  android:orientation="vertical"
  android:background="#f5f5f5"
  android:id="@+id/testimonials_layout"
  tools:showIn="@layout/home_fragment">

  <TextView
    android:id="@+id/textView24"
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    android:alpha="0.9"
    android:text="People love me"
    android:textAlignment="center"
    android:textSize="24sp"
    tools:text="People love me" />

  <androidx.viewpager2.widget.ViewPager2
    android:id="@+id/testimonials_view_pager"
    android:layout_width="match_parent"
    android:layout_height="0dp"
    android:layout_weight="1" />
</LinearLayout>

Our home_fragement is a lot smaller and is just there as a wrapper around the testimonials_layout

<?xml version="1.0" encoding="utf-8"?>
<layout xmlns:android="http://schemas.android.com/apk/res/android"
  xmlns:tools="http://schemas.android.com/tools">
  <ScrollView
    android:layout_width="match_parent"
    android:layout_height="wrap_content"
    tools:context="co.g403.android.viewpager2demo.MainActivity">

    <include layout="@layout/testimonials_layout" />
  </ScrollView>
</layout>

and we also need to update our activity_main layout to render our fragment, normally we’d be using the navigation or something, but this is just a simple app so we can do it like this

<fragment
  android:id="@+id/home_fragment"
  android:name="co.g403.android.viewpager2demo.ui.home.HomeFragment"
  android:layout_width="0dp"
  android:layout_height="match_parent"
  android:layout_weight="2"
  app:layout_constraintEnd_toEndOf="parent"
  app:layout_constraintStart_toStartOf="parent" />

So we’ve covered the layouts, the Testimonial data class and the TestimonialRepository

app/
- testimonials/
  - TestimonialAdapter
  - datasource/
    - Testimonial ✅
    - TestimonialRepository ✅
- ui/
  - home/
    - HomeFragment
    - HomeViewModel
layout
- home_fragment ✅
- testimonials_layout ✅
- testimonial_layout ✅
- activity_main ✅

Now to wrap up the rest of the binding of the data to the layout, starting with the HomeViewModel, this just gets the repository of testimonials and stores them to be used in the layout

class HomeViewModel : ViewModel() {
  private val testimonialRepository = TestimonialRepository()
  val testimonials = testimonialRepository.getTestimonials()
}

Now we’re down to the couple of classes that do most of the heavy lifting, the adapter and the fragment

class TestimonialAdapter : ListAdapter<Testimonial, TestimonialViewHolder>(TestimonialItemDiffCallback()) {
  override fun onCreateViewHolder(parent: ViewGroup, viewType: Int): TestimonialViewHolder {
    val layoutInflater = LayoutInflater.from(parent.context)
    val binding = DataBindingUtil.inflate<ViewDataBinding>(layoutInflater, viewType, parent, false)
    return TestimonialViewHolder(binding)
  }

  override fun onBindViewHolder(holder: TestimonialViewHolder, position: Int) = holder.bind(getItem(position))
  override fun getItemViewType(position: Int) = R.layout.testimonial_layout
}

class TestimonialItemDiffCallback : DiffUtil.ItemCallback<Testimonial>() {
  override fun areItemsTheSame(oldItem: Testimonial, newItem: Testimonial): Boolean = oldItem == newItem
  override fun areContentsTheSame(oldItem: Testimonial, newItem: Testimonial): Boolean = oldItem == newItem
}

class TestimonialViewHolder(private val binding: ViewDataBinding) : RecyclerView.ViewHolder(binding.root) {
  fun bind(testimonial: Testimonial) {
    binding.setVariable(BR.item, testimonial)
    binding.executePendingBindings()
  }
}

We create TestimonialAdapter that extends the ListAdapter, this already gives us a few things to make development easier, but we do have to implement our own DiffUtil.ItemCallback for it. The override of onCreateViewHolder is so we can use databinding to bind the the data into the viewholder, our override of onBindViewHolder is so we can bind the correct testimonial to the viewholder and we override getItemViewType so that list/viewholder knows what layout is needed to inflate/populate.
The TestimonialViewHolder takes in the data binding and when the adapter passes the testimonial to the viewholder we trigger the binding to update the variable in the layout.

class HomeFragment : Fragment() {
  private val viewModel: HomeViewModel = HomeViewModel()
  private val testimonialsAdapter: TestimonialAdapter = TestimonialAdapter()

  override fun onCreateView(
    inflater: LayoutInflater,
    container: ViewGroup?,
    savedInstanceState: Bundle?
  ): View? = inflater.inflate(R.layout.home_fragment, container, false)

  override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    super.onViewCreated(view, savedInstanceState)
    view.testimonials_view_pager.adapter = testimonialsAdapter
  }

  override fun onActivityCreated(savedInstanceState: Bundle?) {
    super.onActivityCreated(savedInstanceState)
    viewModel.testimonials.observe(viewLifecycleOwner, Observer { list ->
      testimonialsAdapter.submitList(list)
    })
  }
}

Here we have the final piece of the app, the HomeFragment, here we hold the HomeViewModel and the TestimonialAdapter, when we create the view (onViewCreated) we set up all our binding mechanics.
Then in onActivityCreated we observe the LiveData List of Testimonials that’s in the ViewModel and when it changes we apply the TestimonialAdapter to it, so that it’s able to bind correctly to our view

app/
- testimonials/
  - TestimonialAdapter ✅
  - datasource/
    - Testimonial ✅
    - TestimonialRepository ✅
- ui/
  - home/
    - HomeFragment ✅
    - HomeViewModel ✅
layout
- home_fragment ✅
- testimonials_layout ✅
- testimonial_layout ✅
- activity_main ✅

Now that it’s complete, once we build and run this we’ll get an app with a swipeable section as you can see in the gif below!
You can find the code in a GitHub repo

I’m very concsious that we’ve skipped any form of testing for this, I don’t know much about testing in Android, but I have the creepy feeling of my bestie, Maja, breathing down my neck at the lack of them.

Next I’ll be writing:

writing tests for ViewPager
a quick post about repositories
maybe one on different animations in ViewPager
Annotations and BindingAdapaters (glide, extra formatting or styling)

Using GitHub actions to deploy branch builds to a s3 bucket

Sun, 01 Mar 2020 00:00:00 +0000

My first blog post in FIVE YEARS :open_mouth:

One of the problems you get with working on side projects with a group of people is the choices you have to make around tooling. You can use one of the awesome hosting providers like netlify or now.sh, but you’re normally limited in the number of people that can join the project to contribute and/or the number of “build minutes” your project can do each month.

For one of the projects I’m involved in we’re using a private GitHub repo (which will become public when we’re ready) and Netlify for the initial hosting. Netlify on the free tier limits you to 200 build minutes/month and 2 collaborators. I decided to investigate how we could use GitHub actions (limited to 2k minutes/month) and an s3 bucket for which the pricing is pretty trivial, to see if this is a viable alternative. And for something to blog about.

GitHub actions

Like many code hosting apps GitHub now offers the ability to run a pipeline for linting/building/testing/deploying code. These actions can be filtered based on pushing to branch, opening pull requests, making a comment etc, and there are many publicly available pre-built actions that we can use, but we also have the option to write/run our own.

Website hosting with S3

I’m not going to go over the instructions for setting this up, for once the AWS documentation has pretty good coverage for this AWS Docs

For one of the GitHub actions we use for this we do need to do some more manual setup, for the IAM user needed for pushing to the bucket, this is specifically for Gatsby which our project is in jonelantha/gatsby-s3-action

Putting it all together

For putting it together I created a new GH repo, created a new bucket in S3 and setup the website hosting and IAM user as detailed above.

I then added Gatsby to the repo and pushed that up, and finally started work on the GH actions

lights, cameras, … git branch name?

I was quite easily able to get the repo building and syncing to s3:

name: Deploy to S3

on: [push]

jobs:
  deploy:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Use Node.js 12
        uses: actions/setup-node@v1
        with:
          node-version: 12.x
      - name: Build
        run: |
          yarn
          yarn build
      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${ { secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${ { secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: eu-west-1
      - name: Deploy
        uses: jonelantha/gatsby-s3-action@v1
        with:
          dest-s3-bucket: gh-actions-branch-builds

But all this was doing was pushing the code into the root of the bucket, so everytime a new commit was pushed on any branch it would overwrite what was currently deployed. What I needed to do was push code to a subdir based on the branch name.

GitHub actions provide various environment variables that can be used in scripts, one of these GITHUB_REF in branches will contain the branch name, so we’re able to extract the branch name from this ref, there are various caveats to this, but for this simple case Stack Overflow has my back

We can plug in a couple of extra steps to get the branch name and add it to the gatsby config and then update the gatsby-s3-action to include the branch name and update the gatsby build step to include prefix path

      - name: Extract branch name
        shell: bash
        run: echo "##[set-output name=branch_name;]$(echo ${GITHUB_REF#refs/heads/})"
        id: extract_branch
      - name: Find and Replace
        uses: jacobtomlinson/gha-find-replace@master
        with:
          find: 'PATH_PREFIX'
          replace: ${ { steps.extract_branch.outputs.branch_name } }
          include: gatsby-config.js
...
      - name: Build
        run: |
          yarn
          yarn build --prefix-paths
...
      - name: Deploy
        uses: jonelantha/gatsby-s3-action@v1
        with:
          dest-s3-bucket: gh-actions-branch-builds/${ { steps.extract_branch.outputs.branch_name }}

Now whenever we push a new branch with changes in this will create a subdirectory in our bucket and the whole thing works amazingly well! :tada:

I’ve put together a repo for the demo:
https://github.com/gabriel403/branch-builds-into-s3

And setup a couple of branch builds as examples:
http://gh-actions-branch-builds.s3-website-eu-west-1.amazonaws.com/master/
http://gh-actions-branch-builds.s3-website-eu-west-1.amazonaws.com/haxing-update/

And there we have it! I haven’t had a chance to look into deleting directories when PRs are merged, and I know opening a PR will put GITHUB_REF into a weird state, but there are different env vars we can use.

Hope this helps some folks!

Much love :heart:

Converting Rails Apps From Heroku To Docker

Wed, 16 Sep 2015 00:00:00 +0000

We recently had to move a rails app from heroku+postgres to our own servers, since heroku free is now enforcing nap times (but I don’t wanna nap!). We don’t want to have to manage the rails dependencies ourselves, as they can be a pita. Docker to the rescue!

We need to run 2 containers for this, a postgres container for data storage and the actual rails app. We need to persist our postgres data so we mount a local dir into the postgres container and then link from the app container to the postgres container.

We have a structure similar to:

-magicapp
--repo
--postgres

##RoR docker container As recommended by the rails docker page we build our own Dockerfile based on their onbuild Dockerfile.

The onbuild Dockerfile builds in some weird places, so it’s customised a bit to build in the more traditional (from docker perspective) /app folder as a mount point.

FROM ruby:2.1

# throw errors if Gemfile has been modified since Gemfile.lock
RUN bundle config --global frozen 1

RUN apt-get update && apt-get install -y nodejs --no-install-recommends && rm -rf /var/lib/apt/lists/*
RUN apt-get update && apt-get install -y mysql-client postgresql-client sqlite3 --no-install-recommends && rm -rf /var/lib/apt/lists/*

ENV RAILS_ENV production

RUN mkdir /app
VOLUME /app
WORKDIR /app
COPY Gemfile /app/
COPY Gemfile.lock /app/
RUN bundle install

EXPOSE 3000
CMD ["rails", "server", "-b", "0.0.0.0"]

We use the normal rails server at this point but can easily be replaced with unicorn or whatever. Now we can build the docker image (and push to docker hub if wanted).

docker build -t "gabriel403/magicapp"
docker push "gabriel403/magicapp"

##Postgres docker container So now we have a workable docker image for out rails app (with gems pre-bundled thanks to building it!) we want to get a working postgres running for us to store data in! We supply a couple of env variables to create a db/user and password. This one’s fairly simple thanks to the existing postgres image:

docker run --name magicapp-postgres -d -e POSTGRES_USER=magicapp_prod_user -e POSTGRES_DB=magicapp_prod_db -e POSTGRES_PASSWORD=magicapp_prod_pword -v /var/www/vhosts/magicapp/postgres:/var/lib/postgresql/data postgres

When we come to launch our app container the env variables from our postgres container are exposed inside the app container, POSTGRES_USER becomes POSTGRES_ENV_POSTGRES_USER, but they don’t exist outside of the containers, making it awkward to pass in indirectly. We can alter our app so the database.yml references the new env vars:

production:
  <<: *default
  adapter: postgresql
  database: <%= ENV['POSTGRES_ENV_POSTGRES_DB'] %>
  username: <%= ENV['POSTGRES_ENV_POSTGRES_USER'] %>
  password: <%= ENV['POSTGRES_ENV_POSTGRES_PASSWORD'] %>
  host: <%= ENV['POSTGRES_PORT_5432_TCP_ADDR'] %>
  port: <%= ENV['POSTGRES_PORT_5432_TCP_PORT'] %>

or we can manually pass the details to more standard env vars:

-e POSTGRES_USER=magicapp_prod_user -e POSTGRES_DB=magicapp_prod_db -e POSTGRES_PASSWORD=magicapp_prod_pword

it’s up to you to chose which approach you prefer, but we do pass a couple of env vars in for basic rails operation:

docker run --link magicapp-postgres:postgres --name magicapp -d -e LANG=en_GB.UTF-8 -e RAIL_ENV=production -e SECRET_KEY_BASE=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab -v /var/www/vhosts/magicapp/repo:/app gabriel403/magicapp

And there we have it, we have a rails app working on docker connecting to another docker container which is running postgres.

##Import postgres backup Nah that’s not it don’t worry. You’re probably sat there thinking that’s no good, what about the years of data we’ve already got in the heroku db? What about proxying from http[s] to the rails app? Don’t worry I got you covered.

If you’re using heroku’s postgres you should be able to make a backup of the current db and then download it, we can then transfer that to the docker host and import to our postgres db.

Now we can download the backup we’ve just made. When downloaded it’ll have a name like 46213451-51f0-490a-311d-22c24ea1e4f5, we rename it to magicapp-dump.dump and then upload it to a temporary directory on the docker host /var/www/vhosts/magicapp/tmp in our case.

Now we can use the default postgres docker image to import the dump into our existing postgres db, we’ll be prompted on the command line to enter the password for the user:

docker run --rm -it --link magicapp-postgres:postgres -v /var/www/vhosts/magicapp/tmp:/tmp postgres sh -c 'exec pg_restore --verbose --clean --no-acl --no-owner -h "$POSTGRES_PORT_5432_TCP_ADDR" -p "$POSTGRES_PORT_5432_TCP_PORT" -U "$POSTGRES_ENV_POSTGRES_USER" -d "$POSTGRES_ENV_POSTGRES_DB" /tmp/magicapp-dump.dump'

Now you’ve got your data restored to your new postgres container!

You’ll probably see something like WARNING: errors ignored on restore: 20 these are normally todo with the dump attempting to drop tables that don’t yet exist.

##http proxy container So we’ve now got an app running with a db with our restored data in, time for some http[s] proxy magic. We’re not using one of the docker special images for this, but a rather awesome image from jwilder called nginx-proxy.

One of the beauties about docker is it it’s easy to see what the user has done to the image before we use it, just by looking at the Dockerfile. One of the things that’s great about this docker image is that it can handle most of your proxying without fuss, you don’t need new containers for each url you wish to proxy. We want to proxy both http as well as https traffic (the rails app will redirect to https for us) we need to tell it where our ssl certificates are, and to forward the appropriate ports, but other than that it’s fairly simple to get running.

docker run -d --name nginx-proxy -p 80:80 -p 443:443 -v /var/www/vhosts/ssl/g403.co:/etc/nginx/certs -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy

When we’re using this we actually need to start our rails app with a few more env vars that the proxy container uses to channel.

So instead of

docker run --link magicapp-postgres:postgres --name magicapp -d -e LANG=en_GB.UTF-8 -e RAIL_ENV=production -e SECRET_KEY_BASE=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab -v /var/www/vhosts/magicapp/repo:/app gabriel403/magicapp

We now need

docker run --link magicapp-postgres:postgres --name magicapp -d -e CERT_NAME=g403.co -e VIRTUAL_HOST=magicapp.g403.co -e VIRTUAL_PORT=3000 -e LANG=en_GB.UTF-8 -e RAIL_ENV=production -e SECRET_KEY_BASE=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab -v /var/www/vhosts/magicapp/repo:/app gabriel403/magicapp

So now we have a running RoR container, a running Postgres container with data restored from heroku and finally an nginx proxy to forward traffic from normal http/s ports to our app.

##systemd configuration Whilst docker is happy to run on boot, our container’s won’t boot or restart by themselves. These are a basic set of systemd files to get all 3 containers to run. Simply put them in /etc/systemd/system/ and then run sudo systemctl enable docker-nginx-proxy.service etc to enable them and get them to start on boot/restart on error etc.

docker-nginx-proxy.service

[Unit]
Description=Nginx Proxy Container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStartPre=service docker restart
ExecStart=/usr/bin/docker run --name nginx-proxy -p 80:80 -p 443:443 -v /var/www/vhosts/ssl/g403.co:/etc/nginx/certs -v /var/run/docker.sock:/tmp/docker.sock:ro jwilder/nginx-proxy
ExecStop=/usr/bin/docker stop -t 2 nginx-proxy ; /usr/bin/docker rm -f nginx-proxy

[Install]
WantedBy=multi-user.target

docker-magicapp.service

[Unit]
Description=Magicapp Container
Requires=docker.service
After=docker.service
Requires=docker-magicapp-postgres.service
After=docker-magicapp-postgres.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run --name magicapp --link magicapp-postgres:postgres -e CERT_NAME=g403.co -e VIRTUAL_HOST=magicapp.g403.co -e VIRTUAL_PORT=3000 -e LANG=en_GB.UTF-8 -e RAIL_ENV=production -e SECRET_KEY_BASE=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaab -v /var/www/vhosts/magicapp/repo:/app gabriel403/magicapp
ExecStop=/usr/bin/docker stop -t 2 magicapp ; /usr/bin/docker rm -f magicapp

[Install]
WantedBy=multi-user.target

docker-magicapp-postgres.service

[Unit]
Description=Magicapp Postgres Container
Requires=docker.service
After=docker.service

[Service]
Restart=always
ExecStart=/usr/bin/docker run --name magicapp-postgres -e POSTGRES_USER=magicapp_prod_user -e POSTGRES_DB=magicapp_prod_db -e POSTGRES_PASSWORD=magicapp_prod_pword -v /var/www/vhosts/magicapp/postgres:/var/lib/postgresql/data postgres

[Install]
WantedBy=multi-user.target

Note that we don’t pass the -d flag in the run commands, we don’t want to background the running, as this would cause systemd to continuously restart.

A Howto on Converting SVN repos to Git

Sun, 22 Sep 2013 00:00:00 +0000

One of our major projects at GoMAD Tech is currently stored in SVN but is soon moving to git.

It really consists of multiple smaller projects, however they’re all stored in a single SVN repository. With SVN’s subdirectory access this was never a problem, but when parsed into Git these need to be seperate repositories.

We also need to remove unnecessary branches, we have a standard layout of trunk, branches/development and branches/hotfix branches with trunk becoming the master branch. As well as a whole bunch of tags in the tags directory, these need to become normal git tags.

One of the things we need to remember is to adjust the author names and emails for commit messages. So we need to pull the commit authors out of svn and tweak them.

svn log --xml https://svn.gomadtech.com/svn/project/subdir/projectdir | grep -P "^<author" | sort -u | perl -pe 's/<author>(.*?)<\\\/author>/$1 = /' > users.txt we can then edit this file to make the entries look like this  

gabriel.baker = Gabriel Baker <gabriel.baker@gomadtech.com>
shabbir.hassanally = Shabbir Hassanally <shabbir.hassanally@gomadtech.com>

After fixing the authors we can start reading out the svn commits and parsing them into git ones, lucky git has this built in (remember to install git and git svn)

git-svn clone https://svn.gomadtech.com/svn/project/subdir/projectdir --authors-file=users.txt --no-metadata -s ProjectInGit

So now we have a local repo with history still intact, but we’re missing proper gittags and branches.

gabriel@svn:~/ProjectInGit$ git status
# On branch master
nothing to commit (working directory clean)
gabriel@svn:~/ProjectInGit$ git branch
* master
gabriel@svn:~/ProjectInGit$ git tag
gabriel@svn:~/ProjectInGit$ So we need to parse those out and create first our tags:

git for-each-ref refs/remotes/tags | cut -d / -f 4- | grep -v @ | while read tagname; do git tag "$tagname" "tags/$tagname"; git branch -r -d "tags/$tagname"; done

And we have:

Deleted remote branch tags/2.0.0 (was 7dea8c7).
Deleted remote branch tags/2.1.0 (was 5b7a0cc).
Deleted remote branch tags/2.1.1 (was a1f7702).
gabriel@svn:~/ProjectInGit$ git branch
* master
gabriel@svn:~/ProjectInGit$ git tag
2.0.0
2.1.0
2.1.1

And then we create our branches:

git for-each-ref refs/remotes | cut -d / -f 3- | grep -v @ | while read branchname; do git branch "$branchname" "refs/remotes/$branchname"; git branch -r -d "$branchname"; done

Deleted remote branch development (was 28cd707).
Deleted remote branch hotfixes (was 81b7b4b).
Deleted remote branch trunk (was fe2b690).
gabriel@svn:~/ProjectInGit$ git branch
  development
  hotfixes
* master
  trunk

No point keeping the trunk branch now we have master

gabriel@svn:~/ProjectInGit$ git branch -D trunk
Deleted branch trunk (was fe2b690).
gabriel@svn:~/ProjectInGit$ git branch
  development
  hotfixes
* master

Then we can add our new remote and push our branches and tags to it

git remote add origin git@github.com:GoMADTech/Project.git
git push origin --all
git push origin --tags

And now we have you repo, converted from SVN to Git and hosted on Github. Enjoy!