Add SDKMAN post

Signed-off-by: Harsh Shandilya <me@msfjarvis.dev>

content/posts/tools-of-the-trade-fzf.md

@@ -18,7 +18,7 @@ On-demand, `fzf` can also be super fancy.
 
 ## Why do I use it?
 
-Becaue `fzf` is a search tool, you can use it to find files and folders. My most common use-case for it is a simple bash function that goes like this:
+Because `fzf` is a search tool, you can use it to find files and folders. My most common use-case for it is a simple bash function that goes like this:
 
 ```bash
 # find-and-open, gedit? Sorry I'll just stop.

content/posts/tools-of-the-trade-sdkman.md

@@ -0,0 +1,45 @@
++++
+categories = ["tools-of-the-trade"]
+date = 2020-08-31
+description = "Bringing this series back on popular demand, we're here to talk about SDKMAN!"
+draft = true
+slug = "tools-of-the-trade-sdkman"
+socialImage = "uploads/tools-of-the-trade-sdkman.webp"
+tags = ["sdkman", "cli-tools", "tools-of-the-trade"]
+title = "Tools of the trade: SDKMAN!"
++++
+
+In the fourth post of [this series](/categories/tools-of-the-trade/), we're talking about [SDKMAN!](https://sdkman.io).
+
+## What is SDKMAN?
+
+SDKMAN is a **SDK** **Man**ager. By employing its CLI, you can install a plethora of JVM-related tools and SDKs to your computer, without ever needing root access.
+
+## Why do I use it?
+
+Since I primarily work with [Kotlin](https://kotlinlang.org/), having an up-to-date copy of the Kotlin compiler becomes helpful for quickly testing code samples with its inbuilt REPL (**R**ead **E**valuate **P**rint **L**oop). I also use [Gradle](https://gradle.org) as my build tool of choice, and tend to stay up-to-date with their releases in my projects. Finally, to run all these Java-based tools, you're gonna need Java itself. Linux distros tend to package very outdated versions of the JDK which becomes a hindrance when building standalone JVM apps that I want to use the latest Java APIs in. SDKMAN allows you to install Java from multiple sources including AdoptOpenJDK, Azulsystems' Zulu and many more.
+
+The real kicker here is the fact that you can keep multiple versions of the same thing installed. Using Java 14 everywhere but a specific project breaks over Java 8? Just install it alongside!
+
+To make this side-by-side ability even more useful, SDKMAN let's you create a `.sdkmanrc` file in a directory, and it will switch your currently active version of any installed tool to the version specified in the file. People following the series from the beginning might recall this sounds awfully like direnv, because it is. However, SDKMAN is noticeably slow when executing these changes, presumably because its tearing down an existing symlink and creating a new one. For that reason, SDKMAN ships with the `sdk_auto_env` feature (automatically parse `.sdkmanrc` when you change directories) off by default, requiring you to manually type `sdk env` each time you enter a directory where you have a `.sdkmanrc`.
+
+Since the auto env feature matches what direnv does, I just use it directly. So, rather than doing this:
+
+```bash
+# .sdkmanrc
+java=8.0.262-zulu
+```
+
+I do:
+
+```bash
+# .envrc
+# In bash, doing `${VARIABLE/src/dest}` replaces `src` with `dest` in `${VARIABLE}`, but you still need to write it back manually (hence the `export`)
+export JAVA_HOME="${JAVA_HOME/current/8.0.262-zulu}"
+```
+
+for the same end result, but a lot faster. The difference in speed ends up coming from SDKMAN working over symlinks compared to my direnv workaround just replacing the value of a variable.
+
+And that's really it! SDKMAN's pretty neat, but for the most part it just stays out of your way and thus there's not a lot to talk about it. The next post's gonna be much more hands-on :-)
+
+This was part 4 of the [Tools of the trade](/categories/tools-of-the-trade/) series.