Hello from sunny Munich and welcome to newsletter issue 25!
It’s more than a year ago that I started to write these newsletters. I managed to publish two issues per month, on average. Now, I would love to hear your feedback on these issues. Do you like the overall format? Did you find the tips useful? How’s the mixture of technologies and news? You can simply send a mail to firstname.lastname@example.org, I’d appreciate it.
Since the last newsletter issues, I’ve spent almost the whole time in India: Hyderabad and Bengaluru for two Oracle Code events. This was my second time in this country and again it was interesting to spend a bit more time and get various impressions. I think that the humbling part of such an experience is that it reminds us how grateful we, as in most Europeans, can be to have access to clean tap water and other things, that for most of us are a “matter of course”. However, I really enjoyed the two events and the overall time and I hope that I could share some knowledge about developer productivity and effective enterprise testing.
The next days are less full of traveling; my next conference engagements will be in Japan again: we’re going to be on another motorcycle tour! “We” will be Steve Chin, other Java Champions, Oracle Dev Champions and friends from around the world, to spread some Java enthusiasm. I’m already looking forward to see our friends in Japan again.
Embrace command line aliases
One important takeaway of my productivity presentation is to embrace aliases when you’re working in the command line. I try to maximize my CLI usage in general — for now I don’t even use a file explorer, I’d just move file around in my ZSH. Aliases are of enormous help for spending more time in the command line.
The zsh shell and especially the oh-my-zsh plugin already define a lot of aliases out-of-the-box.
How many times do you type
git push or
git status manually?
gst are much faster.
Have a look at your currently defined aliases with the
What’s important is that you take a step back once in a while and see which commands you keep typing all over again (*cough*
mvn clean install,
kubectl get pods, …).
To ease your command line experience you should consider defining custom aliases, depending on the tools you’re using.
For an inspiration, here are my most used aliases.
jj='java -jar' mcp='mvn clean package' kcgp='kubectl get pods' kca='kubectl apply -f' dkp='docker ps' dkb='docker build -t' acd='asciidoctor' md='mkdir -p' p9='ping 22.214.171.124'
These are just an excerpt; for now I defined almost 200 aliases, for all kinds of tools and parameter combinations :-)
Managing multiple Java installations
With more and more Java releases coming up, it’ll be more interesting to manage multiple Java installations on your local environment. Different projects may require different Java versions.
The jenv project is a convenient way how to manage Java installations. It can setup local Java installations on global, directory and shell level and uses easy-to-remember Java version identifiers:
$> jenv versions 10 * 1.8 126.96.36.199 9.0 9.0.4 oracle64-10 oracle64-188.8.131.52 oracle64-9.0.4 # switch to JDK 10 globally $> jenv global 10 $> cd project/ $> jenv local 9 $> java -version java version "9.0.4" Java(TM) SE Runtime Environment (build 9.0.4+11) Java HotSpot(TM) 64-Bit Server VM (build 9.0.4+11, mixed mode) $> cd .. && java -version java version "10" 2018-03-20 Java(TM) SE Runtime Environment 18.3 (build 10+46) Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10+46, mixed mode)
Jenv stores the local Java version in a
Jenvs works by declaring wrapper
java binaries that direct to the corresponding installation based on the context.
Shell scripts can also set a specific version via the
JENV_VERSION environment variable:
#!/bin/bash JENV_VERSION='10' # will use JDK 10 java -version
Thanks a lot for reading and see you next time!
Did you like the content? You can subscribe to the newsletter for free: