DEV Community: Dani Meier

How we enable our developers to attend conferences

Dani Meier — Tue, 06 Apr 2021 10:46:13 +0000

Photo by Austin Distel on Unsplash

I love conferences. It's a wonderful thing to attend one. To spend a couple of days with some buddies, meet new people, learn something new, be nerdy, and get inspired.

Unfortunately, in my experience, attending conferences always led to discussions:

Devs want to attend them because they get energized and inspired about it. They want to hear about the latest shit in their tech stack.
Bosses think their devs are only looking for a good time (what is bad about that anyway?)

So I am a developer - with all my heart. I am also the owner of a small Software Shop, so I'm also kind of a boss. Most discussions about conferences arise because they are misunderstood and create false expectations.

A conference is not training. You will learn something for sure. But much more you will learn about new ideas, new ways of thinking.
Most of what you see and learn at a conference is not directly applicable to your job, at least not immediately and without any effort. But it will inspire you. It will make you even more open-minded. You will profit from it in the long run, and so will your employer.
It's not a waste of money to send more than one person to the same conference. There's no value in it to give your co-workers a summary of all the sessions you've attended. Because they lack the whole around, it's perfectly ok, to sit in the same session as your co-workers do or to enjoy a beer after the conference with them. Even better, you can exchange ideas, and maybe you can find some opportunities to introduce some of the topics to your daily work!
Attending a conference is fun. But it's also hard work. I cannot tell you how exhausted you are after a full day at the conference venue: so many people, so many impressions.

Bottom line, we should lower the expectations we have on conferences. It's about having a good time and getting different perspectives.

This article will show you how we handle conferences in a very self-organized way, and we are so happy about it!

The Principles

Of course, there are always strings attached - but only two here:

there is a 💸-budget
there is a ⌚️-budget

Beyond that, there was no framework. So we defined some principles that represented our values and ideas:

Every developer who wants to attend a conference should be able to do so at least once a year.

Why? Because we love conferences and appreciate their value to our organization and our employees.

The whole process is fully transparent and predictable. No feelings or individual decisions are involved. It's just math.

Why? Because it's not right otherwise.

Individual recognitions are always tricky and tend to be unfair. Is employee A better than B, or is A just working on more visible and more thankful tasks? While it's a good thing to appreciate high performers' work, it's crucial to invest in average developers' motivation and inspiration.

Private participation is assumed.

Why? We think attending a conference is a privilege. It is a privilege we want to make possible for those who see its value.

How much should this be? Well, this depends on your concrete situation and budget. In our case, it's 10% of the financial costs and 50% of the time. But honestly, it's not so important. Just make sure not to exclude anyone. It should not be a question of money if someone can attend a conference or not. It's less about the amount and more about the involvement itself.

Do you have enough budget to cover everything? Nice, but still, demand private participation and instead invest some of it in drinks and food after work.

The choice of the conference is up to the participant and doesn't get evaluated.

Why? First and foremost, our employees participate in a conference to advance themselves. We encourage them and ourselves to think outside the box all the time. A conference is a superb opportunity to get in touch with technologies, people, and ideas outside your daily work.

So is it ok to attend a React conference as an Angular developer? Of course!
Is it ok to attend a conference about software testing for a project leader? Sure, have fun!
Is it ok to join a florist convention as a Scrum Master? Well, I don't get it, and I'm interested in your thoughts about it. But I trust you. So if you think this is valuable for you as a member of our company, then we're good.

We are all grown up, and we trust each other every day to do the right thing.

Modus Operandi

It's always good to have some good-sounding principles defined. You can print them with lovely big letters and hang them on the wall. But the hard part is actually to live those principles. To recognize what works well and what does not work at all. To reflect whether our actions still correspond to our principles, our values.

So let's be specific, this is how we are doing this:

Everyone who wants to attend a conference enters its information, like price and duration, into a sheet until the end of January. It's excellent to apply to more than one conference, but one must prioritize each entry.
At the end of January, there is always someone who can hardly wait to see the results. So this is the one who makes the calculation. There is no decision-making or evaluations involved.
We check if we have enough budget to fulfill all the entries. If yes, we're good to go, and all applications get granted automatically.
If the budget is not enough, we cut entries based on their priority. But we never cut the entries with the highest priority. Suppose the budget is then sufficient, all good. Otherwise, we distribute the amount (time and money) above budget over the remaining entries.
After attending the conference, the attendees will create a short (internal) blogpost about their experience to overview the conference to their colleagues. For example, they highlight some sessions, convey the inspiring mood at the venue or rave about the excellent food. But they explicitly don't have to share the contents of the session. If it makes sense to do so, this will happen automatically.

Of course, there are some possible glitches and some rough edge cases - but it does not have to be bulletproof. It just has to work for us.

Is it working?

Hell yeah! These conference visits are highlights each year. In these Covid times, we have chosen beautiful places to create our own conference locations for attending the virtual events.

Are there discussions and glitches about the rules? They are rare - because we are in absolute agreement about them and share their ideas and values. Why? Because we defined them for ourselves. That's the power of self-organizing.

And if it does not work well? We improve. That's the power of "inspect and adapt".

I'm happy to read about your opinion and experiences in the comments.

Configure Git for Work and Personal stuff

Dani Meier — Fri, 06 Nov 2020 19:24:56 +0000

Photo by Maddy Baker on Unsplash

If you are like me and work for different companies, have several side hustles and fun projects, you will probably have the same problem as I have:
You want to use different configurations, like E-Mail Addresses, for those repositories.
Of course, you can always apply a local configuration to each repository or even use some scripts or aliases to help you out. But again, if you are like me, you won’t be happy with it, because you will forget to apply it over and over again.

Conditional Configuration

Git allows you to include external configuration-files based on conditions, like the current directory. With this in mind, the problem above is actually easily solvable.

First use different base-directories for each “area”, like your different work-places and personal stuff:

/home/me/
    dev-work-a/
    dev-work-b/
    dev-personal/

Then create a .gitconfig-file for each of those areas:

/home/me/
    .gitconfig (your main configuration)
    .gitconfig-work-a (specific configuration for work a)
    .gitconfig-work-b (specific configuration for work b)
    .gitconfig-personal (specific configuration for personal projects)

In your main .gitconfig-File, instead of the actual values, you conditionally include the other files:

# ~/.gitconfig
[includeIf "gitdir:~/dev-work-a/"]
    path = .gitconfig-work-a
[includeIf "gitdir:~/dev-work-b/"]
    path = .gitconfig-work-b
[includeIf "gitdir:~/dev-personal/"]
    path = .gitconfig-personal

and in the specific files, you just define the specific configuration values:

# ~/.gitconfig-work-a
[user]
    name = Scooby Doo
    email = scooby@worka.com

# ~/.gitconfig-work-b
[user]
    name = Scooby Doo, Food-Department
    email = scooby@workb.com

# ~/.gitconfig-personal
[user]
    name = Scooby
    email = me@scoobydoo.com

That’s basically it. So now, when you are for example in ~/dev-personal/bigbang-side-hustle Git will get your user-configuration from .gitconfig-personal.

One more thing

Well, of course, you cannot use conditional configuration for user-configurations like name and e-mail only, it’s just a very common use case. But in fact, you can use it for whatever configuration you like.

There are also two more conditions like gitdir:

onbranch lets you apply configurations based on the branch you are on
gitdir/i like gitdir, but case-insensitive

It's worth mentioning that this works on all platforms and is very Dotfiles-friendly.
Also see documentation for more information.

Have fun!

Data-driven Unit Tests with Jest

Dani Meier — Mon, 09 Sep 2019 19:02:31 +0000

Photo by Markus Spiske on Unsplash

Data-driven Unit Tests are an easy and efficient way to run a test with a range of input data. That can be useful in situations like

testing against a broader range of values
testing for null and undefined values
testing against edge cases, e.g., for dates (beginning of the month, end of the month, …)
or to tweak your unit test stats - because each input row counts as a separate test. Your manager will be impressed. 😉

Simple sample

Let’s define a simple test to check if a number is even:

it('should be even', () => {
    expect(2 % 2).toBe(0);
});

 ✓ is even

To check a series of numbers, we can use Jest’s it.each (or test.each, since it is just an alias of test). We pass the input data as an array, each item is then tested individually (n).

it.each([2,4,6])('should be even', (n) => {
    expect(n % 2).toBe(0);
});

✓ should be even
✓ should be even
✓ should be even

We can use several predefined tokens to improve the name of the test, which makes it easier to locate a failing test:

it.each([2,4,5,6])('%i should be even', (n) => {
    expect(n % 2).toBe(0);
});

✓ 2 should be even
✓ 4 should be even
✕ 5 should be even
✓ 6 should be even

Multiple parameters

You can pass multiple parameters to your test as well. In the next sample, we pass the expected value to the test as well:

it.each([[2,4], [6,36], [8,64]])('can square %i to %s', (n, expected) => {
    expect(n*n).toBe(expected);
});

✓ can square 2 to 4
✓ can square 6 to 36
✓ can square 8 to 64

The input table is defined as an array of arrays. Each inner array is one row of the input table.

I like tests to be well readable, understandable and clear in their intention. The focus should be on the actual test and not on the implementation. Jest provides a syntax that supports exactly that:

it.each`
      n     | expected
      ${1}  | ${1}
      ${2}  | ${4}
      ${4}  | ${16}
      ${12} | ${144}
    `('can square $n to $expected', ({ n, expected }) => {
            expect(n*n).toBe(expected);
});

✓ can square 1 to 1
✓ can square 2 to 4
✓ can square 4 to 16
✓ can square 12 to 144

The input table now looks like an actual table. It is defined as a template string, in which the first row contains the variables names separated by a pipe |. Each subsequent row is one combination of input data to run the test against, defined as a template literal expression.
You can reference the variable names inside the test name with $variable.

Run multiple tests

.each is also available for describe-Blocks, which makes it easy to run multiple tests or even a whole test suite against a set of input data.

describe.each`
    x     | y
    ${10} | ${2}
    ${9}  | ${3}
    ${8}  | ${4}
`('With x=$x and y=$y', ({x, y}) => {
    it('x should be larger then y', () => {
        expect(x).toBeGreaterThan(y);
    });

    it('should x should by dividable by y without rest', () => {
        expect(x % y).toBe(0);
    });
});

With x=10 and y=2
    ✓ x should be larger then y
    ✓ should x should by dividable by y without rest
With x=9 and y=3
    ✓ x should be larger then y (1ms)
    ✓ should x should by dividable by y without rest
With x=8 and y=4
    ✓ x should be larger then y
    ✓ should x should by dividable by y without rest (1ms)

You can even combine describe.each and it.each, but keep an eye on comprehensibility.

Angular and RxJS: How to actually avoid subscriptions

Dani Meier — Mon, 08 Apr 2019 21:06:29 +0000

We all know it - we shouldn’t subscribe to observables directly. Instead, we should use the async pipe. It all totally makes sense, but then we leave our comfy reading chair, sit at our desk again, start coding… and subscribing. There are situations that aren’t just that obvious.

Our example

We’re displaying a list of customers.

export class CustomerComponent implements OnInit {
    customers: Observable<Customer[]>;

    constructor(private customerService: CustomerService) {
    }

    ngOnInit() {
        this.customers = this.customerService.getAll();
    }
}

and in the template

<li *ngFor="let customer of customers | async">{{ customer.name }}</li>

Well, that was easy. No subscribe here, yay! Angular is handling the subscription for us with its async pipe.

Ok now let’s move on. We want to add new customers to the list. So we introduce a little form-component and emit an event to our CustomerComponent when a new entry gets submitted. We save the new entry and after that, we’re reloading the whole list. Shouldn’t be that hard.

onCustomerCreated(customer: Customer) {
    this.customerService.create(customer).subscribe(() => 
        this.customers = this.customerService.getAll());
}

Ok, one subscribe, but that seems reasonable since we want to wait until the create-action completes. But mh… that’s not working because we’re replacing the reference on customers. Ok, every problem can be fixed with a subject:

export class CustomerComponent implements OnInit {
    customers = new BehaviorSubject<Customer[]>([]);

    constructor(private customerService: CustomerService) {
    }

    ngOnInit() {
        this.loadCustomers()
    }

    onCustomerCreated(customer: Customer) {
        this.customerService.create(customer)
            .subscribe(() => this.loadCustomers());
    }

    private loadCustomers() {
        this.customerService.getAll().subscribe(
            loadedCustomers => this.customers.next(loadedCustomers));
    }
}

This seems fine. But - we’re subscribing to the load action again, which is feeling wrong. And it is wrong. But in one thing we were right, we can fix it with a subject:

export class CustomerComponent implements OnInit {
    customers: Observable<Customer[]>;
    private readonly refreshTrigger = new BehaviorSubject({});

    constructor(private customerService: CustomerService) {
    }

    ngOnInit(): void {
        this.customers = this.refreshTrigger.pipe(
            switchMap(() => this.customerService.getAll()));
    }

    onCustomerCreated(customer: Customer): void {
        this.customerService.create(customer)
            .subscribe(() => this.refreshTrigger.next({}));
    }
}

Now we aren’t using the subject as the source. Instead, we are using it as a trigger to load the customer-data. Like this, we can use the same observable-instance as source and push new data in it, if a refresh gets triggered. And we still can rely on the async-pipe to manage our subscription.

Blue-Green deployment with Cloud Foundry

Dani Meier — Fri, 29 Mar 2019 09:44:22 +0000

You have a fully automated deployment process which gets automatically triggered by your commits. Downtime? No there’s not, just a few seconds when you replace your application. But that few seconds can be critically and let’s face it, how cool would it be to deploy without any downtime at all.

What is blue-green deployment?

Blue-green deployment is a straightforward way to achieve deployments without any downtime, especially in those fancy, cloudy times we’re living in.

In this example, the blue instance is productive now. You deploy your new application-instance (green) besides the actual running one, wait until it is up and running, execute some automated tests on it, and if everything is fine, switch the route to the new instance, and we’re done.

I highly recommend this article about Blue-Green Deployment by Martin Fowler.

Step by step

Ok, let’s do this step by step. We assume, there’s already one application-instance running (the blue one :-)). Let’s push our new fancy update out to the world:

cf login -a https://super.cloud -u me -p my-password
cf push myapp-green -p "myapp_publish" -u http --endpoint /healthcheck --hostname "myapp-green"

The important parts here are:

Implement a useful naming-scheme for the blue/green containers. The name shouldn’t be generated. It should be a predictable name, and it makes it much easier to work with it during your CI/CD pipeline.
With -u http --endpoint /healthcheck we can tell Cloud Foundry how to check if our app is ready. The health check endpoint is part of your application so that you can define your logic in there (e.g. check if some initial jobs are done). There are more options to implement a health check, see the Cloud Foundry docs for more information. So now our application is pushed and reachable through the “myapp-green”-route (as defined with the hostname-parameter), but it’s not yet productive, because you’re using the “green-route”.

Now you can execute some verifications against the green container:

Execute some Smoke Tests on UI and API Level
Measure some performance KPI’s

If everything is ok, you’re ready to take the green container to production. Basically, we are just telling the CF Router to map the production route to the green-container now.

# map the production route to the new green container
cf map-route myapp-green --hostname myapp
# unmap the green route from the green container
cf unmap-route myapp-green --hostname myapp-green
# unmap the production route from the original outdated container
cf unmap-route myapp --hostname myapp

Last but not least, we’re doing some housekeeping. We rename the green-container to match our production naming convention and then clean up everything that is not needed anymore.

cf rename myapp myapp-tmp
cf rename myapp-green myapp
cf delete myapp-tmp -r -f

That’s it. The described scenario is relatively simple. Of course, we can think of far more complex ones, for example, we could run the (new) green and the old (blue) container in parallel and do some verifications in production, like check performance KPI’s, monitor logging-events, etc.

And what about user sessions?

Of course, you cannot use InProc-Sessions in such a setup because you would just kill them by taking the production container down. You definitely should use a distributed solution to store user sessions, like Redis.

Git Magic 1: Undo git amend

Dani Meier — Mon, 04 Mar 2019 16:03:47 +0000

Git allows you to build up your history in a way so that it has an actual value instead of just being a bunch of hashes with meaningless descriptions.

One of the easier possibilities to keep your history clean is by using git commit —amend.

touch a.txt
git add a.txt
git commit -m 'Add files'
git log
> 175ec0b 4 seconds ago Dani (HEAD -> master) Add files

touch b.txt
git add b.txt
git commit --amend
git log
> d5538f2 48 seconds ago Dani (HEAD -> master) Add files

So here we’re amending our previous commit with the added file. But, what if we made a mistake while changing our commit by adding stuff that shouldn’t be added or amended to the last commit?

Shadow world

The hashes in the example above made very clear, that our amend did not actually change the commit, instead it created a new one (175ec0b and d5538f2).
You won’t lose anything in Git that you’ve committed once. So also the first commit from above (175ec0b).

Our graph for the example now looks like this:

The commit 175ec0b is still around, but it is not reachable through the graph. With this information, it’s pretty easy and obvious how we can undo our amend.:

git reset 175ec0b --soft
git status
> (...)
> Untracked files:
>   b.txt

Or without using the hash explicitly with offsets on the head pointer:

git reset 'HEAD@{1}' --soft

So we’re resetting to one commit before the current HEAD. The changes are now unstaged again and you can commit them again.

Of course, you can also use git reflog to locate the commit.

Now the graph looks the opposite:

Again: the commit which was the result from the amend operation is still existing. So the falsely amended commit is still present but orphaned.