sebastiandaschner news
Hi from snowy Siberia and welcome to newsletter issue #41!
Speaking in conference terms, we’re in the middle of what would be considered the crazy Java conference phase. Well, at least that would be the case if the civilized world not be in the middle of a exponentially-growing world-wide pandemic. There are a few more events planned in the next weeks (see my previous newsletter), of which a few ones have already been canceled. As a speaker, event organizer, and programm committee member, I know how much efforts flow into creating the best possible experience for conference attendees, and I feel for everybody who now will be affected in their conference plans due to COVID-19.
But, as always, we have the choice to make the best out of every situation. Conference speakers and organizers care about delivering value and spreading knowledge to software developers out there and hence we might find other ways, not only to do that, but to ensure that the valuable conversations and discussions conferences provide can still be kept up. Online webinars, smaller meetup events, or virtual conferences; there are ways beyond meeting up together with thousands of people at the same time.
Thus, enjoy reading this virus-free newsletter :-)
What’s new
Productivity reminder: Shell aliases
As I wrote a few times before: if you’re using the command line, and as developers we all arguably do so at some point, you should maximize your typing efficiency and use alias for your frequently used commands.
The zsh shell and especially the oh-my-zsh plugin already define a lot of aliases out-of-the-box.
Instead of typing git commit, git push, or git status manually, gc, gp, and gst are much faster.
You can and should also go ahead and define your own, custom aliases.
You can take a step back once in a while and see which commands you keep typing all over again.
Maybe mvn package|verify|install, gradle build, or kubectl get pods is among them?
Another good starting point is to use your .*_history file (e.g. .zsh_history) and sort by the frequency of usage, for example using the following way which works for the zsh format:
# displays the 20 most used commands
sed 's/^[^;]\+;//g' ~/.zsh_history | sort | uniq -c | sort -nr | head -n 20For an inspiration, here are my most used aliases:
jj='java -jar'
mp='mvn package'
kcgp='kubectl get pods'
kca='kubectl apply -f'
dkp='docker ps'
dkb='docker build -t'
md='mkdir -p'
p9='ping 9.9.9.9'
Git switch and restore
If you’ve been using Git for a while you’re probably used to the ubiquitous git checkout command, which is somewhat overloaded in what it’s doing.
You can use checkout to switch branches, create branches, update the working tree to a past commit, wiping working tree changes, and a few more things.
Put simply, this command has too many responsibilities, and should be refactored.
This is what happened in Git 2.23.0: We can now use two other, more specialized commands, git switch and git restore.
git switch is used to managed branches, that is creating a branch or switching to a branch.
It is complementary with git branch, which lists, deletes, and (also) creates branches.
You use git switch as follows:
# switches to master branch
git switch master
# switches to branch feature-123
git switch feature-123
# switches to last branch, here master
git switch -
# creates a new branch feature-234
git switch -c feature-234
git restore is used to restore working tree files, in the same way you would have used git checkout to checkout or restore a certain working tree state.
Here are some examples for git restore:
echo "modified" >> file.txt
# restores all files in the current directory
git restore .
# working tree clean
echo "modified" >> file.txt
git add file.txt
git restore .
# no changes
# restores staged changes from the index
git restore --staged .
# working tree modified
git restore .
# working tree clean
# checks out a single file from a previous commit
git restore -s a0b1c2d file.txtFor more information have a look at the documentation online or by executing git help <command>.
Productivity reminder: IDE live templates
IDE live templates are a huge time saver.
Instead of typing out boilerplate code yourself, you just type an alias, or in IntelliJ called live template, and with hitting <Tab> this expands into the desired code.
Java examples are psvm<Tab> for a main method or sout<Tab> for System.out.println();.
But again: besides the built-in shortcuts you can, of course, also define own ones.
Depending on the technology and frameworks you’re using there is always room to improve and type less.
For instance, I’ve added live templates to enhance ijt<Tab> to @Inject including the correct import to javax.inject.Inject, which is a statement you’ll have to type rather often in Java EE applications.
Depending on the frameworks and technologies you’re using, there is probably a lot of room for live templates.
Other examples I’ve defined (all including the corresponding import):
ijt -> @Inject
ijtc -> @Inject @ConfigProperty(name = "")
asd -> @ApplicationScoped
ph -> @Path("")
pct -> @PostConstruct method
vt -> @Test method (JUnit5)
vb -> @BeforeEach method (JUnit5)
I encourage everybody to reflect every now an then which statements they are typing regularly.
Thanks a lot for reading and see you next time!
Did you like the content? You can subscribe to the newsletter for free: