[BOULDERING] Bergen, Norway KlatrekKlubb, Slab (V4-V5)
[BOULDERING] V4-V6 slab at Movement RiNo, Denver, CO
nginx server configuration for a wordpress instance served from a URL’s subdirectory
You want to serve a wordpress instance on a website’s domain url but not at the path’s root, you want it under a sub-directory, for example “blog”, the same as this blog:
Here’s how my NGINX’s server block for ‘www.gubatron.com’ looks like at the moment (https/ssl hasn’t been configured yet)
Here is the equivalent in lighttpd, too bad lighttpd has no plans for HTTP2, it’s much friendlier and flexible to configure than nginx in my humble opinion.
I used to host this website and wordpress on lighttpd, lighttpd’s config file is very powerful, it’s all based on matching server variables and applying rules, I will miss it dearly, things like having a compressed file cache and it’s flexibility, but I have to move on to nginx if I want to use http2, the lighttpd has no plans for http2 support and it’s just much faster and efficient than http 1.1.
[BOULDERING] V4s, V5s, V7 throwback from December 2018
[bash scripting] `contains_item` bash function. Check if an item is in an array
[BOULDERING] March-May 2019 Medley (V3-V5 / 6A-6C+)
Bouldering problems recorded between March and May 2019 at Movement Climbing Fitness Baker and the newly opened “The Spot Denver”
gradle/groovy: A simple way to check if a gradle task name has been invoked (e.g. “assembleRelease” for Android developers)

If you google for this question, you’ll find a bunch of crap answers about creating tasks and checking the task graph, bullshit.
All you need to do is check if a parameter has been passed to gradle.
Keep it simple and stupid:
(If you’re working with an android project, you can define that variable before the android {
section starts)
Then, if you need to do something different somewhere else down in your script, say, ask for a key alias and key password to sign your release (because they invoked ./gradlew assembleRelease
you do:
[BOULDERING] My first V6!
Solving “Received fatal alert: handshake_failure” error when performing HTTPS connections on a custom made JRE with jlink

TL; Tell me already what to do:
Add the jdk.crypto.cryptoki
module to the list of --add-modules
parameter to your jlink
command invocation
If you’re reading this you’re one of the few developers out there that wanted to distribute a java 9+ app (using either jdk 9, jdk 10, jdk 11 or jdk 12, as of this writing) with a smaller version of the jdk, to build your custom jre, you used the jlink tool.
When you run your app using the full JRE that comes with the OpenJDK, your app is working fine when it comes to making https requests, but when you run your app using your custom jre you get the following error when opening https connections
This issue occurs because your JRE is missing lots of Cipher Suites that come with the full JDK.
With your JDK, you can try to check the list of supported ciphers with this one liner using the jrunscript tool:
however that might not work for your custom JRE if you haven’t included the scripting module, so here’s a Java program I made that prints all the available Ciphers of your JRE
If you run PrintCiphers
on your OpenJDK’s full JRE, you will see almost 50 Cipher Suites available:
but if you use your custom JRE to run PrintCiphers
you will see only 23 Cipher Suites available:
To solve the problem you must add the jdk.crypto.cryptoki
module to the list of --add-modules
parameter to your jlink
command invocation, next time your run PrintCiphers
you should see the full list of Cipher Suites and your SSL handshake issues should be gone.