And the improvements keep coming along:
So the flow is as follows:
The GUI is now needed - a web-based approach so I can access it from around the world.
It will now generate the 5 levels of verbosity. Now to integrate that with the "fitness" of the job description.
Right now, just testing out my ollama instance with llama3.1 and seeing if it can match fitness between an existing job description and my .yaml file resume.
Today was a success - the format is now in. The template .tex file is good to go, and the renderer.py script is generating the proper output to be converted to a PDF.
It looks clean and lovely.
It is checked into git and ready to be experimented with to add the levels of verbosity.
This is key to a successful venture.
The renderer.py script was missing my "education" and "personal projects" section from the resume. I fixed that, and with some other tweaking, the resume is looking much better.
I would like to add the final layer of verbosity:
For each skill under a task, there should be an explanation as to why it was used, and notes about the implementation.
It's a bit of overkill, but I think it's worth it for ultra-verbose resumes.
- task1: >-
Client 1: Developed test automation of a large robotic
thermal/pressure industrial system. Wrote automated
test cases for this system.
skills:
- Python
- pytest
- uiautomate
- Selenium
- Equipment Interfacing
- C/C++
- task1: >-
Client 1: Developed test automation of a large robotic
thermal/pressure industrial system. Wrote automated
test cases for this system.
skills:
- name: Python
level: 8/10
reasons:
- existing culture
- rich ecosystem
challenges:
- first time working with Python and Windows
benefits:
- rapid development
...
Yesterday I made progress with the resume conversion, cleanup, and the initial bundling up of some work with the LLM, and rendering the output of my resume.
Today's work will require some cleanup of the code, tweaks to the resume_template.tex, and then testing!!!
Why testing? Because that's what I do.
Ever have one of those moments where something rogue was eating up drive space such to the point that your browser acted strange and eventually you had to close it down, not knowing that everything wasn't being cached?
That was this morning. This seems like problem.
Emails are mostly back up and running, linkedin account salvaged...
The resume rebuild is going well - fixing up references, wording, and all placed into a yaml file. I expanded some new fields:
This is a short description of my role at a company. It allows for a simple level of verbosity when generating resumes.
This one I like - it highlights what I was proud of when working there.
- company: "<company name>"
position: "<last job title>"
location: "<city, province>"
start_date: ""
end_date: ""
highlights:
- tldr: >-
What did I do there in an executive summary.
- proudof: >-
What did I do that I was most excited about or proud of.
- task1: >-
A bullet point of what was done while limiting skills/technologies
specifically out for another level of verbosity.
skills:
A deeper level of verbosity - specific skills/technologies used.
In particular, languages, management, protocols...
- task2: >-
...
skills:
...
I have contemplated putting another level of description for the skills. This can round out my thinking at the time, implementation problems, etc...
Time for a shower and lunch!
Take that yaml file and a job description and then throw those at my local LLM and do some parsing magic. Okay - there will be some playing around with the prompt so that the system believes that it's an expert technical career coach and resume writer.
Done
The output is a json format. Time to take that out and pass it through a Jinja2 formatter - it's a great formatter - so I can output a LaTeX file. Yes, I said LaTeX. It can be easily dumped into a pdf file for laters with pdflatex. Now is time to work on the formatter.
Yesterday's work was good - I built a much better understanding of MCP-based systems with empirical applications.
Now, I have enough knowledge to understand that it's a lot of hard work to really coordinate things to create something akin to OpenClaw but not.
Back to MCP work for the pursuit of another position.
Back in the old days (11 or so years ago), it was simple enough to provide some credentials to your running application, and google was happy with that. Agreed, an increase in security is important, but I will have to remind myself to regenerate the token.json file in my system every week.
MCP is 'the bomb' these days with the cool kids. So I had looked into this previously but I have decided to warm it up and work on it, my own solution system, and of course continue with the gtest, unified reporting for jenkins, and a personal project.
Done - running llama3.1:latest. Apparently the .json stuff for ollama and llama3.1 is a match made in heaven.
This is a perfect solution for an on-premises solution such as my own.
I had some code running from about 6 months ago to do the whole OAuth shenanigans and jumping about.
I needed to upgrade the version of python being used since in another week or so, the older versions won't be supported.
I love "pyenv local <version>". This is such an incredible tool.
pip freeze > requirements.txt
deactivate
rm -rf venv
pyenv local 3.14
python -m venv venv
python -m pip install -r requirements.txt
python calendars.py
(error regarding token)
python get-credentials.py
(credentials retrieved!)
python calendars.py
(expected output!)
ollama-first.py is written so I can communicate with ollama directly. This works!
Sample ollama-mcp.py client code is present.
Now need the mcp server to begin this m-f'ng giggle fest.
This is now working for proving in the communication with ollama and mcp to google calendar.
...
* September 23:
+ Reach out, breathe, collect.
+ Hunting
+ House Chores
+ Lunch
+ Personal Projects
* September 24:
+ Black bin, green bin, and yard trimmings
+ Reach out, breathe, collect.
+ Hunting
+ House Chores
+ Lunch
+ Personal Projects
+ TON of Demos
...
read in email_list from a magic fileuse calendar credential -> calendar.email.token.json
for each email in email_list:
use email credential -> gmail.email.token.json
set up mcp client and server with all .json files
have the server also read in the .todo files and put a watch on them for updates
then, if all goes well, the llm can be queried for things
So it is back to post I-Day - a response at noon. This is the plan. Keep busy, do stuff, and wait for a response.
Moving forward:
Continue working with gtest, openCV and try to move it into a Jenkins build setup as well.
For fun, I'm working on a web-scraping tool for the lulz.
Well there were two paths:
1) good
2) bad
If you're reading this, congratulations, we are in the universe that sucks.
It's I-day.
I am naturally nervous, but I know what I know, and what I don't know, I can learn.
I can do this.
Today's activities involve setting up a docker container for isolating the opencv environment, g++, gtest, git, and cmake for developing my code and writing tests in gtest.
I set up the Dockerfile in a folder to start off the work:
FROM ubuntu:22.04
# Prevent interactive prompts during package installation
ENV DEBIAN_FRONTEND=noninteractive
# Update and install build essentials, CMake, Git, and OpenCV dev packages
RUN apt-get update && apt-get install -y \
build-essential \
cmake \
git \
pkg-config \
emacs \
libopencv-dev \
&& rm -rf /var/lib/apt/lists/*
# Set the default working directory inside the container
WORKDIR /workspace
$ docker run -it cpp-opencv-env:latest /bin/bash
root@37d1f68990fd:/workspace# ls
root@37d1f68990fd:/workspace# git clone http://xxx.xxx.xxx.xxx:3001/paul/openCVandgtest.git
Cloning into 'openCVandgtest'...
remote: Enumerating objects: 4, done.
remote: Counting objects: 100% (4/4), done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 4 (delta 0), reused 0 (delta 0), pack-reused 0 (from 0)
Receiving objects: 100% (4/4), 5.28 KiB | 5.28 MiB/s, done.
root@37d1f68990fd:/workspace#
./tests/unit_tests --gtest_output=xml:gtest_report.xml
Running main() from /workspace/openCVandgtest/build/_deps/googletest-src/googletest/src/gtest_main.cc
[==========] Running 3 tests from 2 test suites.
[----------] Global test environment set-up.
[----------] 2 tests from FrameProcessorTest
[ RUN ] FrameProcessorTest.HandlesEmptyMatrix
[ OK ] FrameProcessorTest.HandlesEmptyMatrix (0 ms)
[ RUN ] FrameProcessorTest.ConvertsColorToGrayscaleCorrectly
[ OK ] FrameProcessorTest.ConvertsColorToGrayscaleCorrectly (0 ms)
[----------] 2 tests from FrameProcessorTest (0 ms total)
[----------] 1 test from GMockOpenCVTest
[ RUN ] GMockOpenCVTest.MockPipelineAcceptsAndReturnsMatrix
[ OK ] GMockOpenCVTest.MockPipelineAcceptsAndReturnsMatrix (0 ms)
[----------] 1 test from GMockOpenCVTest (0 ms total)
[----------] Global test environment tear-down
[==========] 3 tests from 2 test suites ran. (0 ms total)
[ PASSED ] 3 tests.
Today I put together the start of a common reporting library for groovy scripts in Jenkins. The scripts are all checked into my gitea repository according to a plan.
I created the file structures, but hadn't populated any groovy scripts and that was perfect because it was reflected when I pressed the "build now" option in Jenkins.
This was very telling! Yup - I hadn't populated any .groovy files.
I fixed that and performed another "build now".
@Library('jenkinslib@main') _
pipeline {
agent any
stages {
stage('Build') {
steps {
// Call your custom global variable step directly
// buildApp(env: 'production')
echo "performing a build."
}
}
}
}
The immediate fix was as simple as adding an "echo". It just needed to do something.
Groovy is a popular object-oriented programming language for the Java platform.
In my case, groovy is used as a pipeline scripting language in Jenkins.
A Jenkins Declarative Pipeline script is structured as a hierarchical block-based Groovy Domain Specific Language (DSL).
pipeline { ... }
The mandatory root block that encapsulates the entire definition of the CI/CD workflow.
agent
Defines where the pipeline or specific stage will execute. It specifies whether the job runs on any available executor (agent any), a specific node label (agent { label 'linux' }), or inside a container (agent { docker { image 'python:3.11' } }).
In my case, right now, I have the agent defined as "any".
environment
Declares key-value pairs for environment variables that remain accessible across all stages, useful for paths, credentials IDs, or build flags.
This is often tailored specific to projects and their needs.
stages and stage
The sequential layout of the workflow. The plural stages container holds multiple individual stage blocks (e.g., Checkout, Build, Test, Deploy), each labeled with a human-readable name shown in the Jenkins UI.
In one case of my setup, a stage is labeled 'Checkout Code'. This is where the script performs the git branch checkout for building.
steps
The imperative block inside a stage containing the actual commands and functions executed sequentially (e.g., executing shell scripts via sh, running unit tests, or calling custom shared library functions like publishTestResults).
Example:
steps {
script {
try {
sh '''
. venv/bin/activate
pytest --junitxml=test-results.xml
'''
// If pytest succeeds completely
if (currentBuild.result == null) {
currentBuild.result = 'SUCCESS'
}
...
post
Conditional execution blocks evaluated after the stages complete. It contains conditions such as always, success, failure, or unstable, making it the standard location for archiving artifacts, sending notifications, or publishing test telemetry to InfluxDB.
Because it's a script, it can be imported, and "libraries" should be able to be added. This means that a unifying reporting system can be written to filter the results from pytest, gtest, and robotframework in one system. This simplifies reporting data to the influxDB and then displaying in grafana.
A unified reporting structure for any organization can result in consistent data reporting.
Beyond that, output can be tailored for consumption at all levels in an organization on exposed dashboards based on the needs of the views:
The plan now is to write unifying code that can be shared across build projects and report consistent SUCCESS, FAILURE, UNSTABLE results as well as test case results.
It's Thursday - an important phone call at 10:00, and then back to the reporting.
groovy is a language that is employed in the jenkins workflow. What I find interesting is that build results and testing results need to be modified to fit the situation.
In one case, I'm using pytest and I need to extract specific information from that to feed to my influxDB system. Then, that data is taken in by a grafana dashboard to display the status of builds.
Although I have managed to get the reporting data for robotframework results, I will finish up the edits to report in a consistent fashion.
A future client will dictate their needs for reporting output. In my previous work, each layer of management from lab tech to CEO require different data. The key is to find a satisfactory view for all parties. At times, this will require different view dashboards for each party.
Ideally, a consensus can be reached and only one dashboard is required.
Today's activity is to unify the reporting to align to one standard set of results to view for each of my projects.
This unification will involve:
This way, a consistent report can be produced.
Going forward, a third project will be added in (gtest) and fortunately, this process should go much smoother.
Today is Wednesday, normally a Hump Day but also a special Hump Day on a shortened week. Because of this special day, I declare it Quasimodo Day.
Back to robotframework, docker, and headless testing for today as well as a call with a recruiter!
The docker instance of jenkins needed to be running with an image that permitted the creation of their own docker systems. Done and done.
bash:
docker compose up -d --build
This did the trick. Having a docker-compose.yml and the Dockerfile for the system to perform the browser tests was perfect.
More interesting results:
So obviously, these results need to be fed to the influxDB system and then visualized on my grafana dashboard.
And so, after wrangling with queries, duplicated data (my jenkins build had an extra publish because I wasn't being careful), I got the results that I wanted:
And so now, I can rest easier.
Lessons learned:
Time to make dinner and contemplate the other problem that I was working on. That one will require me to change out the docker instance for jenkins to allow for docker spin-ups from its own docker instance.
Today is another focus day with the following objectives:
A flask-based application is written to display a webpage with a text-entry section and a button. Pressing the button will take the input from the text-entry and display it, inverting the case.
Examples:
| Input | Output |
|---|---|
| hello | HELLO |
| HELLO | hello |
| Hello | hELLO |
| 1234 Hello world | 1234 hELLO WORLD |
Additionally, there will be a REST API endpoint (/time) that will return the system time.
This should be simple enough to write some tests in robotframework later on.
The installation was easy but I was slowly reminded of some of the oddities of building the testcases. Not a huge deal in my world, just a different mindset is required.
Some gotchas (some I didn't know, others I forgot):
Thus far, I am declaring this as a good success.
Next is including it in my jenkins setup, reporting, etc...
This started off promising - I was having fun with the side-by-side view of two browser tabs in Firefox. Quite a bit of fun for sure. However, I got stung with some interesting limitations.
I will need to do some additional thinking to create a docker instance from jenkins in order to install the browser stuff. Eventually I will want to expand my tests to use other browsers so it only makes sense.
Currently putting a pin in this.
Back to grafana!
It turns out that my groovy script had a double submission of results and that led down a rabbit hole of debugging. I finally got some traction with the output but it's the end of the day. Time to call it quits. Overall, a good time.
Today is all about following up with the recruiter's wishes and dusting off my old robotframework test systems.
To those who are getting excited that I'm getting back into robotics, I am sorry to disappoint you. It's just a software test environment and really doesn't have anything to do with robots.
As per the site:
Robot Framework is an open source automation framework for test automation and robotic process automation (RPA). It is supported by the Robot Framework Foundation and widely used in the industry.
Its human-friendly and versatile syntax uses keywords and supports extending through libraries in Python, Java, and other languages.
It integrates with other tools for comprehensive automation without licensing fees, bolstered by a rich community with hundreds of 3rd party libraries.
So the plan is to write a simple system that uses both a web interface as well as some sort of REST API to then enable me to write tests for it.
Again, I'll throw it into my CI/CD system and continue from there.
I will also return to my grafana set up to monitor the build data from the influxDB and display it.
Because I need a break from things, I'll be back to blues guitar playing. I'm beginning to feel it. I will just keep practicing fills, and turnarounds.
So people have asked me to do something as mundane as setting up a podcast or such. I did a run of a few youtube videos back in the day: (My Youtube Channel)
Today I launched my first podcast on: My podcast
I will probably read stories, news stuff that I find interesting, and excerpts from my blog.
Perhaps this will help people who can't sleep very well because they need to "breathe".
Grrr...
.
Seriously? Sigh.
Oh well, the hunt continues with a call at 10:15 from another recruiter.
I am not against compiled language unit tests in code. In fact, it's necessary to complete the job to truly test the source code of the product. It's interesting as I have been up until now, testing white and black box systems using external systems.
So, as with kubernetes, gtest has entered the fray.
This is going well - docker instantiation is up, talking with my influxDB system that contains my CI/CD results from the gRPC-learning project. Time to make it pretty and then slice some time for expanding the gRPC work as well as opening up the gtest project.
Trust me - this is good. I can work with this. So I'll still keep gtest in the process queue but also, robotframework (again). So much fun!!! Seriously, I did robot stuff back at Windriver. Meh. Same stuff.
Tuesday has happened - got up slowly but working on stuff.
My black filament is problematic - going to abandon it and using RED. The script works like a charm for simple presentation of my name and a QR code. I'm sticking with it. Measuring this as a success.
Thus far, working good - found the problem with influxDB wasn't with the storage, but how the data was being presented. Solution: Grafana - building up the queries. The emails are working now - failures and success are being reported properly to my local server.
The resume-builder software is doing great. I can expand on it, but it allowed me to cover off a few new skills as well as keeping old ones...
