sebastiandaschner news

thursday, april 18, 2019

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.

 

What’s new

 

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 git diff. The 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 git apply. 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.