DEV Community: Jordan Tryon

Dave - Debt Tracking CLI

Jordan Tryon — Sat, 20 Dec 2025 15:59:59 +0000

One thing I genuinely enjoy about “vibe coding” with tools like Claude Code is the ability to finally ship ideas that have been sitting on the back burner.

I’ve wanted to turn a debt-tracking spreadsheet I've had into a simple CLI application ever since I first used it many years ago. However, time always got in the way. I knew how to code it; I just never had the bandwidth.

With Claude, I was able to get it working in about two hours without manually writing the code at all. Is it perfect or production quality? No. But it works, mirrors the spreadsheet accurately, and does exactly what I need.

Does something already exist? Probably, but I made it exactly how I wanted it, and read all the lines of code that went into it as built.

Best part: one less bloated app to open just to manage something simple.

Have a few more tools I've been itching to build, so probably will see some more soon!

Check it out: dave

(fake debts in screenshot below)

Announcing SolveSum: A Testament to the Power of Starting Small

Jordan Tryon — Fri, 04 Aug 2023 23:19:39 +0000

Hello fellow App Developers!

I'm thrilled to announce that my debut mobile game, SolveSum, is now live on both Apple App Store and Google Play!

A journey that began with a simple idea has now culminated into a fully functional game – thanks in large part to React Native and Expo. These tools not only simplified the development process but also eased the publication of this enticing puzzle game.

For those of you embarking on the journey of app development, especially for the Apple App Store and Google Play, I have a piece of advice: Start simple. SolveSum was my sandbox, allowing me to navigate the intricacies of the approval and submission process. By commencing with a smaller project, I was able to avoid the daunting fear of rejection that might have loomed over a project involving hundreds of hours of native coding.

The lessons I've acquired along the way have been invaluable. Not only have I learned the ropes of app stores, but I've also garnered the confidence to dive into more complex projects. To me, that's where the real fun begins!

About SolveSum:

SolveSum is more than just a puzzle game. It blends the intellectual challenge of Sudoku with the engaging mechanics of tile swapping games. As players, you're tasked with manipulating tiles to achieve the stipulated total for each row and column. And for every sum you get right? You score points!

Do take a moment to explore SolveSum and experience the result of my learnings firsthand.

Happy Coding and Gaming! 🎮📱

Believer, User, and Friend - The roles as a Coder

Jordan Tryon — Wed, 18 Aug 2021 03:55:00 +0000

In this article I want to discuss the importance of the relationship you have with your software, the user’s and why when we build big and put the developers further from the customer or the problem, we get broken ever changing software.

Everyone at some point in their lives has dealt with software that they wished worked better for what they wanted it to do. We have even all bought software that is marketed as being developed for our niche, but when we opened it we wondered if the software vendor could pick our niche out of a lineup of niches.

We open the software and begin to use it, but find it so cumbersome that we either quickly give up on it, spend hours trying to learn it, or simply complain about how bad it is and begin the search for new software.

So can this problem be avoided? Somewhat. Could software creators produce flawless software that fits everyone’s needs?

ABSOLUTELY NOT!

Does that mean we give up and don’t even try? Do we look at our Business Analysts, UI Designers, Architects and scold them for doing a terrible job?

No! In my experience it is a simple case of a lack of relationship between the coder and either the customer or the niche. You could throw the best UI Designers and Business Analyst you want at a problem, but if the developer still doesn’t know the pains and problems they are solving, then they will struggle to create software that the user absolutely loves!

You see this in the open source world a lot. If you are say a python developer and you pull down some open source tool that a python developer wrote to make their job easier. You bet it is going to be an amazing tool for you as a python developer. The developer understands the problem, the pains, the issues that the common python developer faces on a daily basis with their toolset. However if that same python developer builds a word processor and rarely types up anything more than a few blurbs here and there, then their product will most likely flounder and just cause frustration or lack of adoption. What is unfortunate is this fictional python coder might be AMAZING, the best there ever was, a developer that writes flawless code. But, if that dev never captured the needs of the customer, then what they have coded will die a slow painful death and their code will be butchered and used in other products that better understood the customer.

Now this fictional python developer could have worked with some architects, business analysts, UI Designers etc, and they probably should. But, again not even the best of the best cannot relay to someone who never experienced something how it is. It’s similar to how when parents get frustrated when non-parents give them advice on how to raise their kids. Yes some of the advice is helpful and good, but a good chunk of it probably is garbage for you raising your kid, and if those people decide to have kids, they will quickly realize they are individual beasts all their own with their own requirements and quirks. Software is the same way.

The developer again, could be great, but unless they either Believe in their cause, are a part of their user base, or have deep customer relationships. They will have a harder time structuring a program in a way that makes sense to the people who are actually using it.

So let’s go though those 3 name tags a developer could wear: a Believer, a User, or the Friend.

Believer:

This developer may or may not use the software they write, but oh, does this developer believe in their software. The developer who believes, is a developer who spends their free time and is consumed by the market or niche that their product is serving. They are evangelicals of their tool to save the masses, their tool solves the problem. The developer believes in their tool and the cause they are supporting. They pour so much of themselves into it, they might as well be a user of it. They believe in the dream and they know how to achieve it.

User:

This developer is an actual user of the software they are creating. They know first hand the pain points and what they need their software to do. They understand the problems it solves as they are living those problems. They have a passion for the product, because they themselves use it. When they write the code, they think of themselves and how it would work for them.

Friend (Relational):

This developer may not use it, and may not even care about the product or it’s use case; but this developer sure cares about the User though! This developer will bend over backwards to consume every bit of information the user provides, pouring over things such as their help desk tickets, while even offering solutions to the user while doing so. They have a love for making their users happy, and when the user is happy, they are too. This developer doesn’t sit alone in a cubicle just churning out code, they actively engage the user and gain their feedback and concerns. They want to see the product succeed because they are a true friend of the user. So the user build and seeks advice every step of the way, ensuring the product they build, is what will make the user happy. They have mastered customer service!

So what type of developer are you for the products you work on? Is this something you think is accurate and that you want to grow in to write better software?

Personally, this is why I will always struggle with Coding Farms and auto-coding tools. They are just too far away from the customer.

However.... The opposite is true too. You can be too close to the Customer or Niche. Stand-by for a Part 2!

Right Now, Precious Metals are Hot, Lets Create a Bot

Jordan Tryon — Sun, 07 Mar 2021 23:31:31 +0000

So I have always been curious of metal prices and how they fluctuate with the market.

A couple weeks ago I came across a cool API that can provide metal prices called Metals-Api. This service has a free plan for up to 50 calls per month, which was perfect for my personal use case of sending myself the prices every morning (looks like it could be a great tool for a paid platform as well). I also use telegram and recently also discovered they have a bot API That you can setup to send yourself messages in a Channel.

So I put the two together and combined it with a small node.js program and a cron job on a Digital Ocean Droplet that runs every morning. Low and Behold, metal prices daily!

See my github repo for more information!

tryonlinux / MetalBot

Bot to send metal prices daily to myself

MetalBot

Extremely Simple Telegram Bot to send metal prices daily to myself using NodeJS and Telegram/Metal-API web services.

Requirements

Axios >= 0.21.1
Metals-Api Key -- Free plan allows up to 50 hits per month
Telegram Bot and Channel

Getting Started

To run simply clone and download code.

Then run the below line to install required packages.

npm i

Place the keys you get and your channel id in a keys.json file like so:

{
"botID": "bot*Bot API Key Here*",
"chatID": "-100*Channel ID Here*,
"metalAPIKey": "*metal API Key Here*"
}

Usage

node index.js

FAQ

How do I get my channel ID for Telegram?

Check out this answer on stackoverflow

How do I set this up to send me prices automatically every morning?

I personally just use a cron job on my personal digital ocean droplet and schedule it to run everyday at 7am.

0 7 * * * node /path/to/file/index.js

Authors

…

View on GitHub

Email Readme on Change Action

Jordan Tryon — Thu, 17 Sep 2020 04:03:01 +0000

My Workflow

The Github action is called Email Readme on Change Action, and it is currently not being used anywhere as I just created it!

Figured this would be a good action to have as a readme is the first interaction someone has with your repo, best to make sure it is always in its best shape on each change by notifying the repo owners via email that contains the html version of your readme directly in the email.

Check out my post here for more info

First Github Action and First Post!

Jordan Tryon ・ Sep 17 '20

#actionshackathon

Submission Category:

Maintainer Must-Haves

Link to Code

tryonlinux / email-readme-on-change-action

Action to email you the Readme.md File on change during a push

email-readme-on-change-action

Your readme is probably the most important part of your project, it is the first thing people see when they visit your repo. You probably should check it out when someone or yourself makes changes. This action is for that, it will send an email with the readme content on a push change to an email you specify.

I created this action to learn as part of the dev.to github action hackathon. Feedback is welcomed as it was my first attempt.

Inputs

Nothing

Outputs

Nothing

Example usage

uses: tryonlinux/email-readme-on-change-action@master

Make sure you set the sendgrid api secret for the repo under Settings > Secrets > SENDGRID_API_KEY as well as REPO_EMAIL_ADDRESS

Once those are set, if you or someone else updates the readme file and pushes it to the repo, an email will be sent to the email listed in REPO_EMAIL_ADDRESS with an markdown to html conversion in the body…

View on GitHub

Additional Resources / Info

NPM Packages used:
showdown - To convert md file to html
sendgrid - To send html md file to email

Needs a SendGrid API Key, they are free (within a daily limit)

First Github Action and First Post!

Jordan Tryon — Thu, 17 Sep 2020 03:54:39 +0000

So this is my first time posting on Dev.to, been a reader and lurker...

I really love the fact that Dev.to had the hackathon as I probably would have not tried github actions for quite sometime nor would I have built one anytime in the near future, but I learned quite a bit with this hackathon and now know how powerful and useful they are and probably will use them in my personal and business projects.

I will say the learning curve was a bit to wrap my head around, but once I figured out how the whole steps in the .yml action file went, and how to set secrets in github it went way faster.

tryonlinux / email-readme-on-change-action

Action to email you the Readme.md File on change during a push

email-readme-on-change-action

I created this action to learn as part of the dev.to github action hackathon. Feedback is welcomed as it was my first attempt.

Inputs

Nothing

Outputs

Nothing

Example usage

uses: tryonlinux/email-readme-on-change-action@master

Make sure you set the sendgrid api secret for the repo under Settings > Secrets > SENDGRID_API_KEY as well as REPO_EMAIL_ADDRESS

View on GitHub

I defiantly welcome any feedback, as this was my first try and I only spent like half a day on it.