Hi from sunny Vienna and welcome to newsletter issue #37!
The conferences I spoke at since the last newsletter were DevNexus (Atlanta), ConFoo Montreal, Java Day Istanbul, JavaLand (Germany), DevOps Pro (Lithuania), Voxxed Days Bucharest, CodeMotion Amsterdam, and JPoint (Russia). I enjoyed attending all of these events. The weather in these places sometime heavily varied, and now it’s nice to see that spring and summer seems to slowly arriving in Europe which comes with a bit more sunshine :-)
What’s up next for me is probably more sunshine in Mexico, another country I’ve never been to before, where I’m going to give presentations in Guadalajara and Mexico City… in Spanish. I started to learn that language two or three years ago and I thought it’s a nice challenge to bring my language skills to the next level. In almost all my presentations I’ve presented in English, which is also not my mother tongue, but due to work, colleagues, and software in general, I speak and also think in English a lot. Let’s see how it goes :-)
Now, let’s have a look at the Java side of things.
Thoughts on Quarkus
During the DevNexus conference, Red Hat announced a new “supersonic, subatomic” Enterprise Java technology: Quarkus. It’s ideas of adapting an enterprise runtime to better address the demands of cloud native applications and it’s implementation are very interesting. I had a chance to interview our friends at Red Hat, Burr Sutter and Justin Lee, during the DevNexus conference, on the day when Quarkus was announced.
Also, I’ve put together my thoughts on Quarkus, based on my experience in projects and after giving it a try. While it looks very interesting, I also wanted to point out that today you can achieve a similar developer experience with regards to turnaround time, if you use a modern fast application runtime, and some tooling, similar to what I’m describing in the following video.
Quickly create Git patches
Git patches are an easy way to apply changes to a project if you don’t want to go through the regular commit-pull-request flow. Patches are files that contain equivalent diff of a Git commit.
You can create a patch of your modified working state using
diff output is in the correct patch format.
$> git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: hello.txt no changes added to commit (use "git add" and/or "git commit -a") $> git diff > ~/important-changes.patch
This will create a simple patch file that can be applied to a different repo and will create the same file changes in the working directory:
$> git status On branch master nothing to commit, working tree clean $> git apply ~/important-changes.patch $> git status On branch master Changes not staged for commit: [...] modified: hello.txt
What’s also possible is to create a formatted patch from commits which includes the commit metadata. These patches were created to be sent via email.
You can use
git format-patch <since> to create a patch from all commits since a certain point, or within a range, respectively.
$> git format-patch origin/master --output ~/ /home/sebastian/0001-changed-file.patch /home/sebastian/0002-changed-file-again.patch # or into a single file $> git format-patch origin/master --stdout > ~/important-commits.patch
Again, these changes can be applied using
Now, we can also use
git am to apply all commits including their metadata:
$> git am ~/important-commits.patch Applying: changed file Applying: changed file again
These patches can be helpful for local workaround that you need to apply to codebases every now and then.
Thanks a lot for reading and see you next time!
Did you like the content? You can subscribe to the newsletter for free:
All opinions are my own and do not reflect those of my employer or colleagues.