Forem: Christian Dewein

Signing React Native Android APKs on Microsoft App Center

Christian Dewein — Thu, 17 May 2018 20:51:04 +0000

TL;DR , how I want my APK signing to work:

No credentials/keystore in the repository.
Build and sign it locally using the keystore (not checked into version control) with configuration using environment variables as part of the general build process.
Build it on MS App Center using their Branch Configuration for keystore upload and configuration.

I followed the official React Native instructions to create a keystore file.

However, I did not want to manage a global gradle config in my home directory and rather go with usual environment variables.

What will happen?

Uploading sensitive data to the repository is out of the question, so the only possibility is to use the upload feature of the Branch Configuration.

This setup will enable you to build signed APKs locally using

./gradlew assembleRelease.

It will not try to sign the APK if no keystore path is set in the environment variables but print a warning instead. This is important, because MS App Center will sign the APK in a second step, after the build, using the keystore and credentials you set in the branch configuration.

I really did not get the documentation that describes the different ways how to sign an APK on App Center and it took me a while to figure out how this works.

Setting environment variables

Assume your keystore file is located in your React Native project at:

android/app/myapp-dev.keystore

You need to set the following environment variables:

ORG_GRADLE_PROJECT_MYAPP_RELEASE_STORE_FILE=myapp-dev.keystore
ORG_GRADLE_PROJECT_MYAPP_RELEASE_KEY_ALIAS=myapp-alias
ORG_GRADLE_PROJECT_MYAPP_RELEASE_STORE_PASSWORD=your-password
ORG_GRADLE_PROJECT_MYAPP_RELEASE_KEY_PASSWORD=your-password

I usually use direnv to do this.

ORG_GRADLE_PROJECT_ is a prefix that will tell grade to include these environment variables as properties, the prefix will be stripped in this process.

Configure Gradle

Edit android/app/build.gradle to include the signing in this way:

signingConfigs {
    release {
      if (project.hasProperty('MYAPP_RELEASE_STORE_FILE')) {
        storeFile rootProject.file("app/" + project.findProperty('MYAPP_RELEASE_STORE_FILE') ?: "ANDROID_STORE_FILE_NOT_SET")
        storePassword project.findProperty('MYAPP_RELEASE_STORE_PASSWORD') ?: "ANDROID_STORE_PASSWORD_NOT_SET"
        keyAlias project.findProperty('MYAPP_RELEASE_KEY_ALIAS') ?: "ANDROID_KEY_ALIAS_NOT_SET"
        keyPassword project.findProperty('MYAPP_RELEASE_KEY_PASSWORD') ?: "ANDROID_KEY_PASSWORD_NOT_SET"
      }
    }
}

And also the call in the release buildType:

buildTypes {
    release {
        //...

        if (project.hasProperty('MYAPP_RELEASE_STORE_FILE')) {
          signingConfig signingConfigs.release
        } else {
          println '-------------------------------------------------'
          println 'The MYAPP_RELEASE_STORE_FILE property was not set!'
          println 'This release will not be signed by gradle!'
          println '-------------------------------------------------'
        }
    }
}

Configure App Center

Upload your keystore and store credentials

That’s it!

Build succeeded at last!

Many thanks to: Gustav, Muneeb and the nice tech support from Microsoft support for their hints and patience! 🙏

My Productivity Boosters — A random collection of tricks and tools — What are yours?

Christian Dewein — Tue, 10 Apr 2018 16:21:59 +0000

I love working on projects. I’ve been working on all kinds of projects for 12 years now and over time, some patterns emerged.

Here are some of my non-technical workflows that work very well for me and that I want to share.

Hint: Make sure to check the comments for even more tricks and share your own!

Special Keybindings

Most of the time I work with the keyboard. And as I am a keyboard enthusiast in general I’ve spent some time experimenting with my keyboard setup. I use two tools to customise my key bindings.

Karabiner Elements

The one and only key remapping tool for MacOS. If you are not sure what could make sense, have a look at the gallery of customisations for inspiration.

CapsLock to Ctrl/Esc

I use SpaceMacs in evil mode, so I have a lot of use for Ctrl as well as Esc. This custom modification allows me to use the CapsLock key for both. When pressed alone it acts as Escape, when pressed together with another key it registers as Ctrl.

Almost all common modifier actions in my controller can be triggered with my pinky now, without leaving home row and without bending it too much.

Tab/Numeric Keypad

I mostly work with 65%-keyboards or laptop keyboards, but sometimes I miss my num pad, which I used very heavily back in the days.

This modification will remap the alphanumeric keys of my right hand¹ to resemble a num pad. Not perfectly, because the keyboard still doesn’t have an orthogonal layout, but it comes very close.

Better Touch Tool

The Swiss army knife called Better Touch Tool is a productivity allrounder that enables you to manipulate input devices of all kinds on a higher level than Karabiner Elements. Sometimes this means more input lag, but also much more possibilities.

Double tap left shift for emoji menu

Most important for communication: If I double tap Shift I open the macOS emoji menu. It even includes a search bar, so adding emojis is super fast and easy. 👌 💯 🔥

Backticks as quotes

Especially when editing markdown documents, the backtick is semantically more of a quote for me. That is why I remapped it to Opt+’, so I have all kinds of quotes in one place.

Maximized Window

It’s a native feature of Better Touch Tool and I use it all the time. I had some problems with other window managers, but BTT works all the time!

App specific Ctrl+j/k up/down mappings

I try to avoid the arrow keys and to stay on the home row as much as possible.

For apps where it makes sense, like Slack, I remap Ctrl+j and Ctrl+k (remember CapsLock is remapped to Ctrl) to up and down.

Note-Taking

Finding a good note-taking app is the hardest of all.

I used Evernote for about eight years, but I was very dissatisfied with the mobile sync and at some point I just did not accept anymore that they don’t provide end-to-end encryption. Right now I have a semi-satisfying double approach on note-taking:

iA Writer/deft

For loose and fast note taking I use the same folder of markdown files that I either edit in deft/emacs or in iA Writer, depending on the situation.

The good thing is it can be edited easily, works mobile and I can do it with my favourite code editor. But everything beyond plain text is terrible and it is not end-to-end encrypted as I use Dropbox for sync.

DayOne

The only thing that came close to a note-taking app that I wish for is not really a note-taking app, but rather a journal. But it has a nice UI, E2E encryption and can embed multimedia files.

I use it for more sensible data and long-term notes. Searching and organising notes is not as good as in Evernote, but it works fine for most cases.

If you have a better setup (E2E and mobile access is crucial though) — please take my money!

Project Management

Every personal or professional project that grows bigger than one note becomes a Trello board.

I practiced GTD for some years and it highly influenced the way I arrange my lanes on a Trello board. These are my default lanes for most projects:

`TODO`

Everything that is actionable right now and should be done as soon as possible.

`@waitfor`

Everything that should be done but is not actionable for me right now. This idea is straight from GTD and every task management system should have something like this.

An example: I want Bob to setup a staging environment, so “Setup Staging Environment” is on my TODO lane at first, because it is actionable (ask Bob) and it should be done asap. But what after I asked Bob to do it? It is not done, I cannot forget about it, but it is also not actionable right now. That’s what I have @waitfor for.

`WIP`

Don’t forget what you are working on ;)

This makes sense if it is about a project that I only work on irregularly.

`SOON`

Actionable, not asap, but soon after.

`SOMEDAY`

Things I want to do someday. In a Scrum backlog, this would be the Icebox. 50% the task will die here, but they won’t clog the lanes I focus on right now.

`Knowledge Base/Summary`

Important lane for most of my personal projects. There are two kinds of DONE in a project:

First kind is just a chore, an obstacle that you have to get out of your way so you can proceed. This is nothing I need on my board, e.g. in a DONE lane.

The other kind is something where the outcome of the task becomes part of the project, e.g. booking a band for an event. I want to keep this knowledge in a handy manner, that’s why I usually keep an additional lane with given facts about the project. Every card is a fact and contains additional information, links, contacts, etc.

Taking Notes on Mobile

Trello is also the way I take notes with my mobile phone, using a special Email address to add cards to the TODO lane.

This may sound cumbersome, but it is indeed the fastest way I know to jot down three words to remind me later.

My use case is: Get Phone out of pocket, write down three words, put phone back in pocket. Most note taking apps will waste my time booting up, syncing or being stuck with brittle network connections. The only app that works for me on my iPhone with acceptable performance is Apple’s Mail app.

For long time I used to send the notes to myself via mail, recently I switched to sending it to Trello directly. I saved the secret mail address in my contacts as tt, so addressing the mail is only two keystrokes.

Email Workflow

I used to use Postbox for a long time and I still think it is the best mail client if you are a power user and have to compose a lot of mails.

Right now, I consume a lot of mails, but actually almost never write one on my own. That is why I switched to AirMail, which has good keybindings and is generally a lot faster, although with less features.

I practice Inbox Zero. If an email hits my inbox, I either act immediately or write down a Card in the according Trello or do nothing. However, the mail will be archived by the end of the day.

I have no fancy automated email rules set up. For me, setting them up always turned out as a waste of time.

10 years ago, I read a Lifehacker article saying something like “it’s 2007, just use the search feature” — I’ve been doing it this way ever since, never missed a mail, never lost a mail.

I have exactly one folder set up, it’s called “Invoices” and it contains tax-relevant stuff. The rest gets archived completely unsorted and I look it up if I need it.

Pomodoro

I try to keep myself focussed and don’t get distracted to much by the usual storm of Slack messages, notifications and emails. If I really need to concentrate I make use of the Pomodoro Technique.

My setup is the following:

* Enable Do not Disturb-Mode via Alfred

* Start Spotify, apply hoodie for extra hacker points (optional)

* Use Be Focussed Pro to set the goal of the session and start the timer.

I keep the ticking timer in my macOS menu bar to remind me to focus on this single task.

The Pomodoro technique works well for me, but I only use it if it makes sense for the task at hand. I learned quickly that it does not work well for every task, but when chosen wisely it can be a real productivity booster.

That’s it for now! 🎉 Just a quick overview of some of the tools that make my work a little bit more productive. If you know other ways to do it, or you missed something, please let me know in the comments!

When pressing tab the following keys get remapped: uio=789; jkl=456; m,.=123;<SPACE> = 0

Photo by Arthur Lambillotte on Unsplash

Actionable Core Values for your Engineering Team

Christian Dewein — Thu, 21 Sep 2017 15:15:49 +0000

If you work in a team of developers, you should talk about your shared values as a team. In this article, I will explain why this makes sense, why you should take action on these values and how we did it in our team.

This was an experiment for me. When I started it, I worked with some of my teammates professionally and full time together for over 7 years, with others for about 7 days. I knew we shared a lot of values back then, but we never actually worked them out. I wanted to change this.

Why should you define core values for your team?

When you work together with other people in a team, and they care about what the team is doing and the team is somehow successful, you probably already share some unsaid values among the members of this team.

I am lucky to work in such a very well performing and friendly team.

Sometimes this is not the case and working with the team is frustrating. But even if the collaboration is inert or exhausting, there may be a good chance that you also share some values. They are just misinterpreted or not recognized.

The point is: You will talk about values one way or the other. Everyone has personal values. They will come up at some point, in a discussion, an argument.

The more stressful the situation is, the less likely it is that you will really understand each other. Perspectives and approaches differ and it takes some time to realize which values you share. It is much easier to really get each other when you put some time aside to specify upfront what’s important to you. It will also be easier to remember the values and live by them, once they are clarified and written out.

For me, this is like the technical part of developing software. You can take your time now to think about how things should be and write some specs for it. Or you can wait until production is on fire. You will think about it one way or the other, but I am sure the former approach is much more efficient and pleasant.

Why should you tie actions to the core values?

Sometimes these kind of “core-value-finding team offsites” are primarily a way to get to know the colleagues a little bit better and create some common ground. This is fine too, but I wanted to go further.

I didn’t want us to define core values as an end in itself, but as a base for further actions to take our team to the next level. If you don’t live by a value, it’s not really a value to you. In order to live by these values, they must be actionable.

So an additional task, beyond the definition of values, would be to put some thought into actions that bring these values to live. Which daily routines, tools, processes, behaviours or events can support a value?

By reflecting about the values and how to make them actionable, we would have a much more intensive and detailed discussion about every proposed value.

Our Approach

I looked for the best way to do this and found my answer in the book Tribal Leadership. It defines two terms:

Core Values – What does the team stand for. The shared values of the team. A value can be defined by terms like “Quality”, “Courage”, or “Trust”.

Noble Cause – What does the team live for. It is meant as a credo, a short description of what the team aspires to be. The book gives some very good examples. In other words, I would define it as the mission statement of your team.

It is important to understand the difference between both.

The Core Values are the foundation, the basecamp of which the team starts off right now. The Noble Cause gives the team the right direction, reminds them of what they want to become.

Therefore it is important to look out for actionable items. They should build upon the values and support the team to move in the right direction, towards the noble cause.

Based on these ideas we did a one day offsite with the whole team. In the next section, I will describe what we did and how it went.

The Offsite Event

This was the first time I organized this kind of event for my colleagues and I was very nervous. They were all very supportive of the idea, but I know that this kind of events can get a kind of cheesy vibe, which will result in eye-rolling and snarky comments and would basically undermine the whole idea. So one of my top priorities was to get my teammates into the mood to give it a serious and honest try.

We took a whole day for this. We were eight people and met in a creative space outside of work, to not be distracted. I brought coffee and some soft drinks. We started slow.

I wanted everyone to feel comfortable, because I think it was crucial to the success of this event that people were relaxed and open to the work we wanted to do.

Story Time

As a warm up, we sat down at a table for a face-to-face discussion. We would soon start to work a lot with Post-Its and flip charts, but I felt a more intimate, personal opener would set a better course for the rest of the day.

I started to share one of my “developer war stories”, at the risk of boring the rest of the group. But the point of the story was that I could end with “and this is when I realized X is a very important value for me in my working environment”. The others could relate and I asked them to share some stories of themselves. In the end, everyone had shared a short story and a value the team could relate with.

Collecting Ideas for Core Values

We split up in two groups and spent some time collecting and discussing personal work-related values, writing them down on Post-its. This is important, because to discuss shared values, every member needs to have some basic understanding of their own personal values and the values of others.

We came together, presented the results of the two sub-groups and I think everyone was surprised how much in common everyone had.

Normally, one would assume that we would proceed to discuss the presented values, cluster the results, discard the less-important and so on. But we didn’t do that. Not yet.

Collecting Ideas for the Noble Cause

Instead, I introduced the concept of Noble Cause and the difference between Core Values and the Noble Cause. We split up again and worked on ideas and suggestions for a noble cause.

I think it was important to do it this way, because people should realize the difference and the connection between these two terms. It was necessary to start working on the noble cause before finishing the values. Otherwise, topics of one concept always seem to creep into the other one.

Only after this round of brainstorming and discussion, we came together to talk about the results of values and cause. I created a new git repo and we started clustering, sorting out, formulating the values and the cause in a markdown file on a projector.

Defining Core Values and Noble Cause as a whole Group

This was the most laborious, but also the most important part of the offsite. We tried to settle on a handful of terms that represent our values and to write some short explanation for every term. It forced us to discuss the actual meaning of the terms more in depth, clarifying what every term meant for the single team members. Interestingly, it was much easier to agree on the topics to leave out, than on the meaning of the topics everybody wanted to include.

In the end, we agreed on five core values, each one explained by one to four short bullet points. And two very short sentences as our noble cause.

The whole team was exhausted, but also happy with the result. Everyone could find themselves in the values and cause, but would agree that it was hard work to express these. Not because we argued all the time, but because it is hard to formulate the values and cause. You realize, even when you talked about these values implicitly for years, you never tried to boil it down, as a group effort, to make it clear to everyone. It is much harder than you would think, even after years of happily working together.

Finding Actionable Items for the Core Values

After a break, we spent the rest of the afternoon by splitting up in two groups again. We were collecting ideas for actionable items to support our way as a team, based on the core values, towards the noble cause.

The idea was to find things in our workflow that would support our core values: Things that always existed, things that we should do more, or new things that would move us into the right direction.

We presented and discussed the ideas and, most importantly, we appointed people to be responsible for actionable items they cared for.

This is when this offsite ended. We were able talk about a lot of things for the present and the future of this team, but it was also clear that we needed to take care of the results to prevent them from vanishing.

One Month Later — The Aftermath

I waited one month to write up this article, because I wanted to see if the results of this offsite would last. The offsite was not meant to change the life of every team member, but I really hoped it would have a positive, sustainable impact on the way we work.

Here are some of the actionable items that we already took action on:

We created a Slack channel to discuss and remind ourselves of our core values and noble cause.
We printed the core values and noble cause on two large posters to hang it in our office.
We shared and explained the core values and noble cause to candidates and new team members during our hiring process and onboarding process.
We discussed concrete rules for better commit messages.
We settled some heated discussions by stopping for a second and reminding ourselves about our values.
We revived a company internal book club and read a book together.

A lot of different ideas were created in this initial workshop. Sometimes the scope is very broad (book club), sometimes the scope is very specific (better commit messages). But they all pay into the same values, our values. I think it is great that we have such a wide variety of small enhancements coming from this.

So… What are our Core Values and Noble Cause?

I am very proud of our core values and noble cause, so a part of me really wants to share them. But I won’t. This is something we did for us, that is important to us, and tailored for us.

Maybe someday we will decide to publish them. For now, we will keep them hidden in our little dev tribe. We just want to see where this goes.

Title Photo by Helena Lopes on Unsplash