DEV Community: Sebastian

Two hacks for a seamless Zoom experience

Sebastian — Wed, 13 May 2020 06:58:50 +0000

Hack #1 - Open Zoom without prompt

The Issue

You know the pain.
For every new Zoom call you have to confirm a prompt in order to join it.
No matter what kind of calendar or meeting reminder you're using, you can't avoid to open chrome and submit the prompt.

The Solution

Using an older chrome version to get the checkbox back?
No, not really an option.

Luckily this feature is not gone, just hidden.
Follow this simple steps to get it back:

Have Chrome version > 79
Run the following command in terminal defaults write com.google.Chrome ExternalProtocolDialogShowAlwaysOpenCheckbox -bool true
Restart Chrome

After restarting chrome you're able to tick the checkbox to always open Zoom directly without prompting.

Hack #2 - Zoom Closer for Google Chrome

The Issue

You're pretty busy and hopping from call to call.
Every new call is a new tab in Chrome and you end up like this...

The Solution

Some smart people came up with Chrome plugins for this issue.
Every new tab is just temporarily open and will be closed automatically.

Just search for "Zoom Tab Closer" in the chrome web store and install one.
I linked the Zoom Closer which works pretty fine for me.

Credits

[1] https://superuser.com/questions/1498967/how-to-always-open-certain-app-links-in-chrome-without-prompt
[2] https://chrome.google.com/webstore/detail/zoom-closer/appjbedfhcmpknanmbndpojcllfaemal

Do you know Project Lombok?

Sebastian — Fri, 21 Apr 2017 20:57:28 +0000

I've been using and appreciating Lombok for some time. It's one of the first dependencies I drop into my Java projects. This article is just about making you curious writing less, more clean code and of course save some time.

â³

What kind of problem solves Project Lombok? ðŸ‘€

Well I think this quote is nailing it.

"Boilerplate" is a term used to describe code that is repeated in many parts of an application with little alteration. One of the most frequently voiced criticisms of the Java language is the volume of this type of code that is found in most projects. This problem is frequently a result of design decisions in various libraries, but is exacerbated by limitations in the language itself. Project Lombok aims to reduce the prevalence of some of the worst offenders by replacing them with a simple set of annotations.

Michael Kimberlin

Show me some code! ðŸ™

package com.codebud7.example;

import lombok.Builder;
import lombok.Getter;
import lombok.ToString;
import lombok.extern.java.Log;

@Log // or: @Slf4j @CommonsLog @Log4j @Log4j2 @XSlf4j
public class LombokDemoApplication
{
    public static void main(String[] args)
    {
        Article article = Article.builder()
            .title("Project Lombok")
            .published(false)
            .description("It's magic!")
            .build();

        log.info(article.toString());
    }
}

@Getter
@Builder // or: @Setter
@ToString
class Article
{
    private String title;
    private Boolean published;
    private String description;
}

This is just a small example of some powerful Lombok features.

On top of the LombokDemoApplication class you can see the @Log annotation. Instead of declaring an instance of a logger framework of your choice Project Lombok is doing this for you to save common declarations.

Let's have a look at the Article class. Use @Getter and you never will write
public int getFoo() {return foo;} again. The @Builder annotation produces complex builder APIs for your classes and @ToString is printing your class name, along with each field, in order, separated by commas by default.

Next steps ðŸŽ“

So if you're curious and want to know some more details about Project Lombok you should visit the following sites:

ðŸ‘‰ The official project Lombok docs
ðŸ‘‰ Nice introduction to more Lombok features by baeldung

About Maven version ranges

Sebastian — Wed, 29 Mar 2017 18:13:18 +0000

Hey folks

this week I stumbled across problems with maven dependency version ranges.

So here we are - a short article about maven dependency version ranges and possible advantages/disadvantages based on my experience.

What are version ranges?

Maven allows you to define a range of version numbers (In a specific format) to resolve automatically the latest version of a defined dependency by the next build execution.

What version ranges am I able to specify?

Range	Meaning
1.0	x >= 1.0 * The default Maven meaning for 1.0 is everything (,) but with 1.0 recommended. Obviously this doesn't work for enforcing versions here, so it has been redefined as a minimum version.
(,1.0]	x <= 1.0
(,1.0)	x < 1.0
[1.0]	x == 1.0
[1.0,)	x >= 1.0
(1.0,)	x > 1.0
(1.0,2.0)	1.0 < x < 2.0
[1.0,2.0]	1.0 <= x <= 2.0
(,1.0],[1.2,)	x <= 1.0 or x >= 1.2. Multiple sets are comma-separated
(,1.1),(1.1,)	x != 1.1

For example:

<dependency>
    <groupId>com.example</groupId>
    <artifactId>healthcheck</artifactId>
    <version>[0.0.5,0.3.0)</version>
</dependency>

What's the current version?

You're able to get the actual version by running mvn dependency:list |grep healthcheck

The result will provide the actual version number. It could look like this: [INFO] com.example:healthcheck:jar:0.0.7:compile

Why should I use it?

It's magic. An update to newer dependencies within the defined ranges without hitting the keyboard. So less work to keep an eye for any updates and "magic" gain of possible new features/fixes of the dependency.

Why not?

You never can't be sure that newer versions are compatible to your code and are unbroken. So it could be possible that you're build/compilation will magically be broke caused of newer dependencies.

Conclusion

Well in my opinion the usage of version ranges is a matter of taste and also depends of the used technology. For example in the JavaScript ðŸŒŽ version ranges are more recommended and popular.

For Maven especially I like to avoid version ranges to keep my dependency list clean and short to have a better overview about used versions, certain sub-dependencies and avoid possible site effect of magic updates.

Hints

You can resolve newer dependency versions by using mvn versions:display-dependency-updates

Replace version ranges automatically by run mvn versions:resolve-ranges or based on specific groupId's mvn versions:resolve-ranges -Dincludes=com.example:* (',' separation possible)

Be careful resolving SNAPSHOT dependencies by version ranges. They could be under construction and manipulate your expected behavior.

Official apache maven docs

How to customise your git commit message

Sebastian — Sat, 25 Mar 2017 15:34:43 +0000

1. Add default template directory

git config --global init.templatedir '~/.git-templates'

Files and directories in the default template directory (~/.git-templates) whose name do not start with a dot will be copied to the specific $GitDir after it is created.

See git-init

2. Add default hook directory

mkdir -p ~/.git-templates/hooks

The hooks are stored in the hooks subdirectory of the default template directory.

See git-hooks

3. Add your first hook (e.g. prepare-commit-msg)

vi ~/.git-templates/hooks/prepare-commit-msg

Add a custom hook that puts your branch name to the top of your commit message. (Excluding master, develop)

#!/bin/sh

if [ -z "$BRANCHES_TO_SKIP" ]; then
  BRANCHES_TO_SKIP=(master develop test)
fi

BRANCH_NAME=$(git symbolic-ref --short HEAD)
BRANCH_NAME="${BRANCH_NAME##*/}"

BRANCH_EXCLUDED=$(printf "%s\n" "${BRANCHES_TO_SKIP[@]}" | grep -c "^$BRANCH_NAME$")
BRANCH_IN_COMMIT=$(grep -c "\[$BRANCH_NAME\]" $1)

if [ -n "$BRANCH_NAME" ] && ! [[ $BRANCH_EXCLUDED -eq 1 ]] && ! [[ $BRANCH_IN_COMMIT -ge 1 ]]; then 
  sed -i.bak -e "1s/^/$BRANCH_NAME /" $1
fi

See git-hooks

4. Make the hook executable

chmod +x ~/.git-templates/hooks/*

Git hooks are not made executable by default.

5. Re-initialize git in each existing repository

git init

To use your new hook you have to re-initialize git.

See git-init

6. Commit

git commit -v

How does it look like?

7. Automation
If you'd like to add the same commit message for every git project you could configure something like this:

First create your template file. (For example ~/.gitmessage)

Why:
*

After that you can simply add this file to your ~/.gitconfig

[commit]
    template = ~/.gitmessage

Hints

ðŸ‘‰ If a hook is already defined in your local git repository the new hook won't overwrite it.
ðŸ‘‰ You might have to set the permissions on your new hook. (sudo chmod 775 .git/hooks/prepare-commit-msg)

Chris Beams about git commit messages

DEV Community: Sebastian

Two hacks for a seamless Zoom experience

Hack #1 - Open Zoom without prompt

The Issue

The Solution

Hack #2 - Zoom Closer for Google Chrome

The Issue

The Solution

Credits

Do you know Project Lombok?

What kind of problem solves Project Lombok? ðŸ‘€

Show me some code! ðŸ™

Next steps ðŸŽ“

About Maven version ranges

What are version ranges?

What version ranges am I able to specify?

What's the current version?

Why should I use it?

Why not?

Conclusion

Hints

RELATED:

How to customise your git commit message

Hints

RELATED:

DEV Community: Sebastian

Two hacks for a seamless Zoom experience

Hack #1 - Open Zoom without prompt

The Issue

The Solution

Hack #2 - Zoom Closer for Google Chrome

The Issue

The Solution

Credits

Do you know Project Lombok?

What kind of problem solves Project Lombok? ðŸ‘€

Show me some code! ðŸ™

Next steps ðŸŽ“

About Maven version ranges

What are version ranges?

What version ranges am I able to specify?

What's the current version?

Why should I use it?

Why not?

Conclusion

Hints

RELATED:

How to customise your git commit message

Hints

RELATED:

Show me some code! ðŸ™