It’s giving me more opportunities to drink tea, sit with things, think, and hopefully the pickelball court when the weather is nicer and I’m recovered from an ankle injury.

In my last role, I spent a lot of time exploring AI assisted development, especially spec driven workflows, and had the opportunity to give a talk on “Context Engineering.”

I haven’t had a lot of time to spend on blogging. But I’ve been busy. Hopefully in this time, I can get back to writing.

What’s Coming Next:

I’m planning a series of posts ranging from a reflection of personal projects to the deep/technical/educational:

• Vibe-coding Chronicles: I build an E-Ink Transit/Train Tracker. I also had a vibe coded Movie Night Planner completely fall apart.
• A Full Guide on LLMs: I found it surprisingly hard to get started and learn about LLMs. A lot of the resources made massive assumptions, they overstated the capiblities, or they failed to explain why the technology solves a problem I may have. I’m hoping to write a series that will take the reader from getting a sense of what LLMs are and move all the way to Agent Orchestration. (Other topics include: Model definitions, comparisons of models, Heretic/Uncensored Models, AI Coding tools, and should move to building agents)
• Self-Hosting and Local AI: I plan on sharing how I got an Ollama hosted service up and running. I also plan on sharing how I moved from Ollama to llama.cpp.
• My Experience with GraphineOS: What is it like from day to day, and what is it like depending on OSS software.
• Contributor License Agreements and How They’re Hostile to the OSS World
• Book Review:“Vibe Coding: Building Production-Grade Software With GenAI, Chat, Agents, and Beyond” I’m nearly done with this book, but it felt like a better started than many of the other AI books I’ve tried to get into.

Yuck, more AI? … Seriously?!

I know how you feel. There’s too much noise, too much marketing and way too much fearmongering. I have no interest in hyping up this tool. What I remain interested in is communicating about what works well and acknowledging where it fails.

How Can I Use your Help?

I’m currently exploring what comes next professionally. I’m focused on Staff+ backend roles (Chicago or Remote), particularly around:

• JVM/Scala/Functional Programming
• Distributed Systems and Data engineering
• AI- Assisted Systems and Agents
• Go and/Rust. (I’m excited to learn Rust).

If you’re working in those spaces, or think I could help your team build something meaningful. I’d love to connect at Linkedin

Fast-forward a month, and you’ll notice that your account is still being billed. What’s up? You’re not running actions anymore yet there still claims to be billing. It was about $4 a month, for nothing running. It’s not a lot, but it’s still a surprise.

How do you check that you’re getting charged?

View your billing usage at: https://github.com/settings/billing

In the billing summary, look for the ‘Repositories’ section to identify which projects are incurring charges.

That tells me that my issue is showing up in the “mill” repository.

How do you fix this?

Go to each of the projects you’re still getting billed for and modify the retention setting.

Navigate to the ‘Actions’ settings for each project and reduce the ‘Artifact and Logging’ retention period.

It’s a bit crazy that this is set to 90 days. For a lot of runs or having a lot of large build artifacts, that can get quite costly in a short period of time.

Also while you’re at it

Disable Action Runs for any forks without approval. There’s no reason you should be billed for others that forked your code.

Select the option:

Approval for running fork pull request workflows from contributors

Now that I’ve finished reading it, here’s a quick review of “gRPC Up and Running” (2020) by Kasun Indrasiri and Danesh Kuruppu.

TL;DR: It does what it says it does on the tin. Would use to learn gRPC again.

Book Summary

This book provides an introduction to gRPC, covering the underlying technologies and offering a broad overview of the surrounding ecosystem. Once the basics of gRPC are established, the authors delve into the protocol’s inner workings, its features, and important considerations for implementation.

What did I enjoy?

I particularly appreciated the in-depth, visual examples that explained how gRPC functions over the network. The challenges of network communication – such as avoiding packet fragmentation and ensuring speedy, ordered delivery – are complex, and the authors’ visual approach made these concepts much easier to grasp.

I also appreciated the inclusion of health check instructions. While common practice for REST services, health checks are often the first concern when deploying a new service, and it’s great to see them addressed in this context.

he final chapter effectively extended the discussion beyond the core technology, exploring how gRPC is used and extended in real-world deployments.

The book’s structure and pacing were excellent. It introduces the technology clearly, allows you to experiment with a simple example early on, and then progressively deepens the discussion, anticipating the questions you’ll likely have during implementation. To the authors: Great work! There are many technical books that suffer on this front.

What could have been better?

An updated edition would be valuable. There have been many large scale changes with Protobufs and gRPC since the book was written. Granted, this book was written in 2020, so the state of the book is completely understandable.

A more balanced perspective would have included a discussion of gRPC’s drawbacks and potential pain points. While a detailed resolution isn’t necessary, pointing readers towards relevant discussions on these topics would be helpful.

It would have been interesting to see a discussion of experiences converting existing REST/SOAP services to gRPC, and the resulting benefits or challenges.

Given the differences between gRPC and common RESTful APIs, a section on best practices for gRPC API design would have been beneficial.

It would be helpful to understand any language-specific limitations or weaknesses in gRPC implementations. Even though the content is older, this would give context to the history and language affinity for this language. I think the first thought a person may have with this book is: Will a Go based gRPC server integrate against an Elixir based client.

Some of the code examples, while functional, felt a bit lengthy and could have benefited from more contextual explanation to better illustrate their purpose.

Would recommend this book:

Yes.

If you’re looking to learn gRPC, I recommend this book. As the title suggests, it will help you get up and running quickly. For those working through Chapter 2, you might find my previous post helpful for addressing a specific issue.

Resources

• Book link: “gRPC Up and Running” (2020) by Danesh Kuruppu
• My rewrite of the first gRPC server and client example.
• Explanation of the changes on the sample code.
• Great reference mentioned in the book: Awesome-gRPC

No one should be writing interface code/domain models

I’ve been thinking about this for years. Adapting to frameworks like DropWizard, Spring REST, Akka HTTP, and Play has been a constant pain point. Much of the work done on the interface definition layer is repetitive rather than unique to the business logic. I anticipate you might object: “What if my file upload spec requires a GET request?” These deviations create unnecessary complexity, hinder documentation, and often lead to replacement with more maintainable solutions after a few years. Many attempts to simplify this process have resulted in even more complicated and specialized solutions, such as AWS AppSync. We once seemed to be moving towards more generic and consistent approaches, but I’m not sure what happened. (See JAX-RS). Another example is Taplir. I’m still waiting to see if it gains traction, though I’m very supportive of the project.

What should happen? Despite its imperfections, I believe gRPC offers a strong foundation as a generic definition language that can be compiled into interface and domain generation libraries. With its extensions, it can support integrations requiring REST-based communications.

OpenAPI is effective, but its generators lack consistency. This is a key weakness that could be addressed with more robust testing and validation. Establishing a common language would allow us to verify and benchmark OpenAPI generator outputs against the libraries they are intended to support.

Splitting Boundaries in Large Systems Should be Automated/Data Driven

Over the last 10+ years we’ve seen microservices being split apart and communication between them become incredibly complex. In some cases, it’s been overkill, with overly fragmented services that shouldn’t have been split. We’ve also seen a resurgence of monoliths in recent years.

What I believe will happen:

Decisions regarding service boundaries will be automated, identifying where splitting provides value and where it doesn’t. Rather than deploying utilities as separate services, we may increasingly see them embedded directly into dependent services. Reliable and consistent automation of this process requires a tool that leverages observable metrics and service endpoint generation.

Code is focused on building and transformation rather than formal modeling against things

Since the 1980s, with the rise of C++, object-oriented programming has emphasized modeling domain objects (which is valuable) and assigning them inherent behaviors (deceptively limiting). More recent languages have demonstrated a gradual shift away from strict OOP towards a functional style. As a fan of functional programming in Scala, I hope this trend gains momentum.

Functional programming separates domain structure from behavior and transformation logic.

Where have we seen progress in this?

• Golang: Models domain objects through structures, and adding friction to attaching behvaior against them. Although, the error model for Golang functions limits the ability to work with code in a functional manner.
• Java The Oracle/Java Language Specification has embraced functional paradigms from Scala with features like the Streams API, default methods, record classes (similar to case classes), and tools for writing more declarative concurrent code (parallel streams).
• JavaScript: Its lack of class-based inheritance encourages functional approaches.
• Rust: Natively supports higher-order functions and is attracting engineers from the Scala community.

The challenge lies in overcoming varying definitions and resistance to adopting new approaches. Many developers remain attached to the traditional pattern of embedding behavior within domain objects.

We get back to structured testing

Giving LLMs ambitious tasks for large projects has been problematic. I think this will lead us in two directions:

Firstly, we may move to writing tests and letting the LLM generate the implementation code. This would give AI coding systems the ability to validate, verify, and restructure the code. For this to be realized, the test/specification code needs to become easier to humanly write. Given the current state of QA related technologies, frameworks, and systems, I believe that will require a new language.

Secondly: Strongly structured testing techniques will be needed to verify AI code. AI can generate a lot of code, but it isn’t always what you want. In a way, it’s like having an untrusted “gremlin” in your codebase. Testing will be needed to verify on many levels for regression, acceptance, and reliability.

We Finally Give up on the idea of forcing “Real time decisions” On Services

Creating services that handle complex rules and data is expensive, and that expense increases when demanding real-time performance. This gets worse every time a feature is added or the service is reused in a different context. What does this mean? The push toward using queuing systems, asynchronous processing, and large-scale streaming platforms.

I anticipate two key shifts:

1. A clearer understanding of the appropriate roles and limitations of microservices and realistic performance expectations
2. A greater acceptance of communicating a longer processing status to users through the UI to build trust. This shift is supported by the ongoing development of resources like the second edition of “Designing Data Intensive Applications.”

Additionally, this way of solving a problem ends up being cheaper to run with the right infrastructure (FaaS), and it’s cheaper to maintain.

Libraries become comprehensive

I think this may be the most uncertain prediction here. Javascript and Python introduced a wave of self-promotion of libraries that either riffed on other libraries, were forked for self-interest, or were overly specialized. We may move back to a more established, reputable, and confirmed process of publishing reusable dependencies. Or not. Golang, a popular language, has a completely decentralized, disorganized, and loose definition of dependency management: it’s based on actual repositories of raw source code.

AI Models

I don’t think AI models will get much better. I believe that they may become more space, memory, and parameter efficient, and I believe they may get updated. The big next thing here is qualifying and validating the training data. That’s going to be a murky and difficult path for LLMs. Additionally, it’s going to be worse if the data that the LLM is trained on is Generated AI content.

People become more withdrawn from spaces where bot based content exists

We’re currently seeing spaces where large amounts of people gather being invaded by organizations and malicious individuals to promote products and scams. Email and text messaging are being inundated with nonconsensual messages from vendors we use. I would imagine this creates distrust by the customer and may cause more withdrawing and quiet disconnects.

I’ve seen this with email and text marketing mostly through Square marketplace connected shops. I’ve never asked for marketing from those companies and there seems to be no way to opt out of it from Square. Also, my understanding with Facebook, it’s filled with distracting and non-asked for AI generated “content.”

AI Slows down and gets better focused on single tasks

AI is currently overhyped. There’s a lot of buzz around its potential to revolutionize everything and eliminate human labor. We are starting to see the limitations of General AI and the practical constraints imposed by current models and hardware. Hopefully, for software engineers, we’ll see better tools, integration, and ways to identify flaws in languages, improvements in processes, and better ways to deliver more trustworthy solutions. I think that’s the best-case scenario. Given the more likely scenario of: adapt or die, buy over build, and deny failure, I suspect we’ll see a lot of turbulence and further large-scale technical disasters.

What can we expect from this? Hopefully, we’ll see specialized research involved in optimization and better definition of tasks that are best fit for it.

Rust Continue to Grow

2026 may be the year for Rust. Who knows. It looks like a great language, and I’m learning it. Coincidence? With the economic downturn, there may be an increased desire to make systems more efficient to reduce cloud spend, and this may be the answer. Who knows, I just hope it isn’t Go. (Go is currently experiencing turbulence and is deviating on its original claims of “easy language” due to growing pains.)

In conclusion,

Do I believe all of this will come to pass in 2026? No. However, I believe these considerations are worthwhile. Software engineering is cyclical, and while past performance isn’t indicative of future results, I hope we can move towards more communication, efficiency, and the creation of truly great software.

Why Consider gRPC?

gRPC is a high-performance, efficient protocol and interface definition language that enables you to generate server, client, and data model components. While the protocol definition is strict (requiring careful ordering), this contributes to its robustness and performance. Recent additions like “unknown fields” are beginning to address some of the flexibility concerns.

There are several key benefits to using gRPC:

• Flexible Connection Models: Unlike REST, gRPC supports a wider range of connection options (unary, server streaming, client streaming, and bidirectional streaming).
• Code Generation: The Interface Definition Language (IDL) allows you to generate client and server code from a single definition, reducing boilerplate and ensuring consistency. In 2020+ no one should be writing server side or client side code from hand.
• Tooling and Language Support Protobuffers (The underlying IDL) has a large ecosystem of support, usage, and language support.
• Performance: gRPC utilizes Protocol Buffers for serialization, resulting in a compact, binary format that’s faster to transmit and parse compared to text-based formats like JSON.]**
• REST Support If your client absolutely had to communicate with JSON, there’s a GRPC proxy that can do the translation from a gRPC service to an REST compatible communication.

Encountering Outdated Code

The second chapter of “gRPC Up and Running” introduces a sample product service that demonstrates adding and querying products. Unfortunately, I found the provided code and tooling to be significantly outdated and difficult to compile. Dependency issues and incompatibilities required substantial updates and distractions to get the example running.

To help others avoid these hurdles, I’ve created an updated and working version of the sample code, available at: monksy/getting-started-with-grpc.

The original sample code can be found here: grpc-up-and-running/samples

Key Updates to the Sample Code:

• Automated The Code Generation: Added a Makefile to streamline the protocol buffer code generation process.
• go vet Integration: Incorporated go vet to improve code quality and catch potential errors. Fixing the line status.Errorf(codes.Internal, "Error while generating Product ID:", err) with the formatter code %v at the end of the message.
• Local Module References: Configured go.mod files to reference local modules, simplifying setup and removing the need to publish to GitHub.
• Updated Dependencies: Updated gRPC dependencies to the latest versions.
• go_package Definition In the Protobufs: Added a go_package declaration to the product_info.proto file, required for newer protobuf definitions.
• Revised Protobuf Command: Updated the protoc command in the Makefile to reflect the newer expectations of the protobuf compiler.
• grpccurl Instructions: Added instructions to the README demonstrating how to verify the server is running using grpccurl.
• Created an output folder for the binaries The Makefile outputs all the binaries to target/server|client/
• GitLab CI Integration: Included a GitLab CI script for automated building and testing.

While “gRPC Up and Running” provides a good conceptual overview, the code examples are somewhat dated. I hope this updated repository helps you get started quickly with gRPC. Feel free to contribute and share your feedback!

Travel

International

As of writing this (January 1st, 2026), last year took me to Latvia, Taiwan, and Indonesia (Bali). By far, Taiwan was my favorite.

The people were exceptionally friendly, public transportation, TRA, and HSR were outstanding, and nearly every meal was incredible. More than anything, Taiwan felt easy to exist in. It felt like you could participate in their culture, events, activities, without having to fully buy into their commerces or communities. Want to go to a baseball game ( that’s big there), it’s cheap compared to an MLB game. Need to escape to the mountains for a day off, you’ve got buses to Wulai. Unlike in the US and other countries, I didn’t feel like I was locked in to some forced smartphone app to do everything. I could reserve what I wanted to do online, and go in person to pick up my tickets. I felt free to explore, interact, wander, and simply enjoy where I was.

Across two trips, I visited Tainan, Taipei, Alishan National Scenic Area, and Taitung. My first trip was a solo visit in April, and later in July I managed to squeeze in a short three-day stopover. Even that brief return trip I was still able to enjoy my time there.

Taiwan has officially earned a permanent spot on my “return often” list. Even compared to Japan.

Domestic

I usually avoid domestic travel — the cost-to-experience ratio often just isn’t there — but I did have two standout trips this year.

Amtrak: Seattle → Chicago (Empire Builder, Eastbound)

I rode the reverse route of the Empire Builder primarily to finally see Glacier National Park, which I missed on my first ride in 2021. While the trip wasn’t quite as an adventure as my original westbound run, Glacier national park was good to see. Additioanlly it was good to see the border between Minnesota and Wisconsin. (Also missed on the westbound route due to it being dark) Some of the diminished experience likely had to do with the government shutdown at the time but even so, it was still worth it.

Lake Wisconsin

This trip ended up being quietly recharging because it introduced me to kayaking. I didn’t expect it to stick, but it really did — and once the weather warms up, I plan to lean much harder into it.

Culture

Music

I saw a lot of shows this year — including the Oasis reunion — but three stood far above the rest:

Russian Circles — Easily the most powerful and enjoyable live performance I saw all year. It wasn’t the most energetic show I saw, but the light show and music made it enjoyable, immersive, and perfect.

Mogwai This show brings a lot of their long time fans. I didn’t have a strong feeling of the show. But it helped to appreciate their music more.

YOB Very good, but didn’t leave quite the same lasting impression as the two above.

Comedy

Three comedians really stood out:

Ian Fidance — Incredible stage presence and raw energy.

Geoffrey Asmus — Loud, belligerent, absurd — in the best way.

A Philly-based comic whose name I tragically forgot — Completely unhinged, chaotic, and hilarious. This was in the earlier months in 2025 at Zanies. The show was nearly empty, but he killed.

Interestingly, the more “industry-backed” shows — especially those tied to large brands or things like Kill Tony — consistently underperformed and disappointed. The smaller, less polished, more chaotic shows ended up being far better experiences.

Food

Two meals absolutely dominated the year:

Gajah Putih (Ubud, Bali) — Incredible food, excellent service, and a beautifully executed concept. The entire experience felt curated in the best way.

難得一面 Beef Noodles (Taipei) — 青花椒 / 大紅袍、超濃蕃茄、麻辣牛肉麵、乾拌麵、重磅蛤蜊麵 I didn’t go here for the beef noodles. But the garlic noodles they had were spicy, warming, cheap, and comforting. It’s exactly what I wanted after a hot springs soak in Wulai. I only managed to visit once while they were open, and I will seek them out the next time I’m in Taiwan.

Museums

Surprisingly, museums didn’t leave much of an impression this year. I do recall going to a modern art museum in Tainan.

I’ve also found myself increasingly discouraged by the shift toward mandatory early online ticketing, which has quietly drained a lot of spontaneity and enjoyment from city exploration.

Building an Exercise Routine

One of the biggest quality-of-life improvements I made this year was committing to a real exercise routine. It noticeably increased my strength and had a surprisingly positive impact on my overall mental well-being. Unfortunately, an injury sidelined me for a few months, which was frustrating. Tracking my activity turned out to be essential; seeing tangible progress made it far easier to stay motivated.

Joining Sports Leagues

Alongside the exercise routine, I joined a few sports leagues and ended up making some genuinely great friends. It became one of my favorite ways to stay active and social at the same time. My WhirlyBall team, in particular, turned into a highlight of my week—it didn’t feel like “exercise,” it felt like fun.

Walking & Exploring Trails

I spent a good amount of time walking and exploring trails this year, mostly using AllTrails. While it helped me discover new places, its increasing number of paywalled tiers has made it feel like less of a good value. It is fairly limited on the content on the platform and the lack of users giving feedback on the platform. There are some promising open-source alternatives out there that I haven’t fully tested yet, but they’re definitely on my radar.

Still, I managed to explore trails around Chicago, Wisconsin, and even Taiwan. Getting outside, unplugging, and just being present turned out to a great way to disconnect and reset my mind.

Meditation & Tea

This might be the most meaningful habit I picked up all year. Meditation became my way to quiet the noise, slow things down, and re-center myself. Around the same time, I fell completely in love with tea. Tea was not a new thing to me, I regularly consumed black tea with meals (as is culturally normal), but it was the discovery of the high quality Oolongs and high mountain varieties I found in Taiwan. It delivers this deeply calming, almost heady relaxation that feels like a gentle reset button for your nervous system.

The Calm app played a big role in making meditation approachable and consistent. Together, meditation and tea became a small daily ritual that I genuinely look forward to.

Learning to Take Breaks

This one has been harder than I’d like to admit. I’m not naturally great at stepping away, but I’ve slowly started to build better habits around taking real breaks.

Reading

I’ve also been reading more than usual this year, largely thanks to the Meebook e-reader I picked up. Being able to access my entire library on a high-quality screen. I couldn’t imagine using a Kindle which would lock me into Amazon’s restrictive and sometimes temporary ecosystem. It’s made reading far more accessible and enjoyable. It lowered the friction enough that reading became something I actually do again, not just something I intend to do.

Audiobooks

Audiobooks ended up being a surprisingly rewarding activity. This didn’t take off until I installed and built up an Audiobookshelf server to manage audiobooks and podcasts. I made it through five or six non-technical books this year, far more than I normally would, and it opened the door to titles I probably wouldn’t have had the attention span for otherwise. Project Hail Mary and the Bobiverse series were standouts, and they made walks, chores, and downtime feel richer and more engaging.

Without further ado:

Technical

gRPC has been an interesting technology to dive into. I’ve known about it for years, and I’ve worked with technologies that it incorporates (Protobufs). But it’s great to learn about it’s features and the problems it attempts to solve. I’m hoping to publish a blog post on getting started with gRPC soon.

K6: I’ve said it many times, and I stand by the statement: JavaScript is terrible.

However, a place where it does work supprisingly well is as feature tests for HTTP based services. I’ve had an easier time writing feature tests with K6 and would consider doing this as the default way to write feature tests for services.

Gitlab Actions I’ve been reluctantly moving to an Actions-based system for my CI/CD work. They work reasonably well, although getting my GitLab runners set up and running took a fair amount of effort.

The more I work with actions, the less I rely on my Jenkins instance. (Which is good for maintance reasons)

Layering This is a technique where you can build foundation pieces using Git, GitLab/GitHub, and new libraries. I may discuss this technique in more detail in a later blog post. But this allowed me to learn new frameworks, create POCs for problems and tools.

I may discuss this in more detail in a future post, but this approach has allowed me to:

• Learn new frameworks
• Rapidly create proof-of-concepts
• Experiment with tools and architectures more safely

Artificial Intelligence with LLMs

LLMs have probably been one of the biggest contributors to my technical growth this year.

They’ve helped me:

• Summarize online research
• Troubleshoot technical and non-technical problems
• Prepare for and practice interviews
• Proofread my writing

I even built my own private LLM setup using Ollama and self-hosted models.

I was very reluctant to jump on this bandwagon due to how aggressively AI tooling was forced at a former job: including stack-ranking employees and forced attrition based on GitHub Copilot training participation and token usage. That experience left a bad taste, but using LLMs on my own terms has been genuinely transformative.

Favorite models:

• Qwen3: Planning
• Gemma3: writing related tasks
• GPT5: Adapting code in respect of it’s surrounding codebase.
• Qwen2.5: Coder

Building my own router Building my own router has been both extremely educational and occasionally punishing, but ultimately very rewarding. I moved from a consumer all-in-one router to a fully featured OPNsense-based setup. I now run:

• Custom VPNs
• Advanced routing rules
• Multiple segmented networks
• Caching services
• Private DNS

And honestly? I love it.

What I’ve bought that stood out

Soundcore Earbuds (Anker)

I lost the charging case for my Sony noise-cancelling earbuds and later discovered that if you lose the case, you have to re-pair the earbuds to a replacement. On top of that, a new case costs well over $100.

Given that outrageous price and the fact that a firmware bug significantly degraded the battery life of the earbuds themselves (with no recall… thanks, Sony) I decided to try the Soundcore earbuds from Anker instead.

For earbuds, I’ve been genuinely thrilled with them and plan to stick with them going forward.

Zigbee devices

As I expanded my home automation setup, I found Zigbee devices to be fantastic to work with. I haven’t gone too deep into complex automations yet, but it’s incredibly nice to have devices that can join your network (No stupid, noisy vendor app needed), and report sensor information with ease. This has really helped in getting my smart home setup feel easier to use, and more informative.

For most users, SDKMan provides basic CRUD (Create, Read, Update, Delete) operations for SDKs on their system – listing, removing, installing, and more. You can find a full overview of its usage here: SDKMan.io: Usage

However, I recently discovered a feature that I think is particularly cool: SDKMan environment files. These files function similarly to Python virtual environments, allowing you to define and manage SDK versions on a per-project basis. When you are working with other engineers, with different development environments, this is a great way to get consistency on everyone’s development environment.

Here’s a sample environment file, including support for JDK 25 (Corretto) and SBT:

File (in your project): .sdkmanrc

java=25-amzn
sbt=1.11.6

Execute the command: sdk env install The tool will kick off downloads, if it hasn’t already, and will manage your environment in your shell.

How does this work? SDKMan downloads the SDK versions to its ~/.sdkman/candidates/ folder. It then updates your PATH to prioritize the environment contained within that folder. This ensures that when you run sbt or java in this environment, the versions defined in the environment file are preferred.

Even better, this environment persists across sessions whenever you enter the directory – if you have sdkman_auto_env set to true (this value is configured in ~/.sdkman/etc/config).

lsof -i :portnumber

For example when checking for the SSH port, you’ll get the following results:

$ lsof -i :22
COMMAND    PID   USER FD   TYPE DEVICE SIZE/OFF NODE NAME
sshd      1406   root 6u  IPv4   6746      0t0  TCP *:ssh (LISTEN)

You’ll get information on the command that’s running, the process ID, the user it’s runing as, and many other networking related details.

But lsof Returned nothing!

I had this issue after installing k3s on a local machine. The application that was using port 80 no longer responded to the port. Even restarting the application, the port still didn’t respond how I expected.

Stopping the application, the port still remained considered to be open by nmap. What happened? I pulled out the trust lsof, but that returned no results. Quite a frustrating situation.

What was the issue?

Check to see if the firewall is forwarding the port. If the firewall forwards the port to another port locally, no matter what you have listening to port :80 will bind to the port. If K3S has root access on installs, it will try to take over port 80 to forward to another port it operates on. In this situation, lsof -i is correct, theres no PID associated with that port.

I was lucky that disabling k3s reverted the rule. However, if I wanted to verify this behavior, consider the following stackoverflow answer to view the rules.