George MacRorie
@georgemac.bsky.social
Maker of internet things. Currently deploying ClickHouse all over the place. Previously flipt.io, InfluxDB, Codeship, and more lost to time.
https://george.macro.re
https://george.macro.re
Morty doesn’t know when you took this photo of him. But he approves all the same. That’s a good pack 🐾
July 25, 2025 at 10:00 PM
Morty doesn’t know when you took this photo of him. But he approves all the same. That’s a good pack 🐾
Trump administration is giving the Lettuce a run for its money.
April 9, 2025 at 6:52 AM
Trump administration is giving the Lettuce a run for its money.
Currently enjoying a little bit of mountain peace before starting the next role.
My legs are zapped and it’s only day three.
#grandmassif
My legs are zapped and it’s only day three.
#grandmassif
March 2, 2025 at 2:40 PM
Currently enjoying a little bit of mountain peace before starting the next role.
My legs are zapped and it’s only day three.
#grandmassif
My legs are zapped and it’s only day three.
#grandmassif
This photo of Morty from this week on walks in the snow was just too good not to share.
January 17, 2025 at 7:58 PM
This photo of Morty from this week on walks in the snow was just too good not to share.
December 20, 2024 at 9:34 AM
This new, fine grained history can be leveraged to reverse just the operations necessary to rollback the particular pipelines relevant changes.
It also means, that the history view per phase, only contains the points in Git history that effected our particular application.
It also means, that the history view per phase, only contains the points in Git history that effected our particular application.
December 7, 2024 at 12:49 PM
This new, fine grained history can be leveraged to reverse just the operations necessary to rollback the particular pipelines relevant changes.
It also means, that the history view per phase, only contains the points in Git history that effected our particular application.
It also means, that the history view per phase, only contains the points in Git history that effected our particular application.
So Glu goes a step further and builds per phase history using your code. When you implement a Glu pipeline, you explain (in Go) how to marshall what changes to and from the filesystem per phase.
When commits come in, Glu runs this code per phase to extract the relevant changes and log them itself.
When commits come in, Glu runs this code per phase to extract the relevant changes and log them itself.
December 7, 2024 at 12:49 PM
So Glu goes a step further and builds per phase history using your code. When you implement a Glu pipeline, you explain (in Go) how to marshall what changes to and from the filesystem per phase.
When commits come in, Glu runs this code per phase to extract the relevant changes and log them itself.
When commits come in, Glu runs this code per phase to extract the relevant changes and log them itself.
But this is just Git history right? That's the point of putting it in Git in the first place.
True, and Git and it's commits remain the source of truth for Glu. However, Git's history contains entries for all my applications, and a single commit could touch multiple of them in our pipeline.
True, and Git and it's commits remain the source of truth for Glu. However, Git's history contains entries for all my applications, and a single commit could touch multiple of them in our pipeline.
December 7, 2024 at 12:49 PM
But this is just Git history right? That's the point of putting it in Git in the first place.
True, and Git and it's commits remain the source of truth for Glu. However, Git's history contains entries for all my applications, and a single commit could touch multiple of them in our pipeline.
True, and Git and it's commits remain the source of truth for Glu. However, Git's history contains entries for all my applications, and a single commit could touch multiple of them in our pipeline.
Yesterday @markphelps.github.io and I finished our first MVP of history and rollback capabilities in Glu.
Now each phase in Glu has its own relevant and isolated history of versions that can be explored and when needed, rolled back to.
#buildinpublic #golang #gitops
🧵
Now each phase in Glu has its own relevant and isolated history of versions that can be explored and when needed, rolled back to.
#buildinpublic #golang #gitops
🧵
December 7, 2024 at 12:49 PM
Yesterday @markphelps.github.io and I finished our first MVP of history and rollback capabilities in Glu.
Now each phase in Glu has its own relevant and isolated history of versions that can be explored and when needed, rolled back to.
#buildinpublic #golang #gitops
🧵
Now each phase in Glu has its own relevant and isolated history of versions that can be explored and when needed, rolled back to.
#buildinpublic #golang #gitops
🧵
Also, notice that our iterator does a range on our channel of entries. This will run until this channel is closed.
We close this channel in a defer in the goroutine which calls ascend/descend.
This ensures both conditions "btree is exhausted" and "iterator returned early" coordinate and cleanup.
We close this channel in a defer in the goroutine which calls ascend/descend.
This ensures both conditions "btree is exhausted" and "iterator returned early" coordinate and cleanup.
December 6, 2024 at 12:02 PM
Also, notice that our iterator does a range on our channel of entries. This will run until this channel is closed.
We close this channel in a defer in the goroutine which calls ascend/descend.
This ensures both conditions "btree is exhausted" and "iterator returned early" coordinate and cleanup.
We close this channel in a defer in the goroutine which calls ascend/descend.
This ensures both conditions "btree is exhausted" and "iterator returned early" coordinate and cleanup.
The stop channel is going to allow our iterator to signal an early exit when the new style iterator recieves a false when calling yield. This happens when a for range over the iterator returns early (e.g. in a break or return).
Notice we close this channel in a defer in our iterator sequence.
Notice we close this channel in a defer in our iterator sequence.
December 6, 2024 at 12:02 PM
The stop channel is going to allow our iterator to signal an early exit when the new style iterator recieves a false when calling yield. This happens when a for range over the iterator returns early (e.g. in a break or return).
Notice we close this channel in a defer in our iterator sequence.
Notice we close this channel in a defer in our iterator sequence.
Now we can start our Ascend / Descend old style iterator in a goroutine. Remember these take a function which operates on each entry in the tree. So, we're going to use this opportunity to send on our channel.
We use select in our function to switch between our send operation or a receive on stop.
We use select in our function to switch between our send operation or a receive on stop.
December 6, 2024 at 12:02 PM
Now we can start our Ascend / Descend old style iterator in a goroutine. Remember these take a function which operates on each entry in the tree. So, we're going to use this opportunity to send on our channel.
We use select in our function to switch between our send operation or a receive on stop.
We use select in our function to switch between our send operation or a receive on stop.
We're going to call Ascend / Descend in their own goroutine as we dont want to block returning an iterator.
We're going to use a channel (well two, we will come to that) for passing our entries from old iterator to the new one.
A buffer of zero ensures we synchronize our sender and receiver.
We're going to use a channel (well two, we will come to that) for passing our entries from old iterator to the new one.
A buffer of zero ensures we synchronize our sender and receiver.
December 6, 2024 at 12:02 PM
We're going to call Ascend / Descend in their own goroutine as we dont want to block returning an iterator.
We're going to use a channel (well two, we will come to that) for passing our entries from old iterator to the new one.
A buffer of zero ensures we synchronize our sender and receiver.
We're going to use a channel (well two, we will come to that) for passing our entries from old iterator to the new one.
A buffer of zero ensures we synchronize our sender and receiver.
We need to be able to control iteration, yielding to range at our own discretion with the iter package. However, btree's style of iteration enters a feeding loop when we call Ascend or Descend.
So how can we go about coordinating these two styles together?
Enter goroutines and unbuffered channels.
So how can we go about coordinating these two styles together?
Enter goroutines and unbuffered channels.
December 6, 2024 at 12:02 PM
We need to be able to control iteration, yielding to range at our own discretion with the iter package. However, btree's style of iteration enters a feeding loop when we call Ascend or Descend.
So how can we go about coordinating these two styles together?
Enter goroutines and unbuffered channels.
So how can we go about coordinating these two styles together?
Enter goroutines and unbuffered channels.
On initial glance, this looks a looks a lot like the new iterator style in Go, which also involves a function for handling individual entries in the collection.
However, the contract is actually the inverse. With the iterator package in Go, we are given a function to yield to.
However, the contract is actually the inverse. With the iterator package in Go, we are given a function to yield to.
December 6, 2024 at 12:02 PM
On initial glance, this looks a looks a lot like the new iterator style in Go, which also involves a function for handling individual entries in the collection.
However, the contract is actually the inverse. With the iterator package in Go, we are given a function to yield to.
However, the contract is actually the inverse. With the iterator package in Go, we are given a function to yield to.
The package in question is Google's BTree implementation.
pkg.go.dev/github.com/g...
This package long predates the new iterator style and exposes its own methods Ascend and Descend for iteration in a particular direction.
These methods take a function returning a boolean to signal when to stop.
pkg.go.dev/github.com/g...
This package long predates the new iterator style and exposes its own methods Ascend and Descend for iteration in a particular direction.
These methods take a function returning a boolean to signal when to stop.
December 6, 2024 at 12:02 PM
The package in question is Google's BTree implementation.
pkg.go.dev/github.com/g...
This package long predates the new iterator style and exposes its own methods Ascend and Descend for iteration in a particular direction.
These methods take a function returning a boolean to signal when to stop.
pkg.go.dev/github.com/g...
This package long predates the new iterator style and exposes its own methods Ascend and Descend for iteration in a particular direction.
These methods take a function returning a boolean to signal when to stop.
I am doing silly things with #golang iterators again. So thought I would share in the hope it is helpful, or maybe someone will show me a better way.
This time I have a collection type, which exposes its own abstraction for iterating over its contents. Instead, I want it to use the iter package.
🧵
This time I have a collection type, which exposes its own abstraction for iterating over its contents. Instead, I want it to use the iter package.
🧵
December 6, 2024 at 12:02 PM
I am doing silly things with #golang iterators again. So thought I would share in the hope it is helpful, or maybe someone will show me a better way.
This time I have a collection type, which exposes its own abstraction for iterating over its contents. Instead, I want it to use the iter package.
🧵
This time I have a collection type, which exposes its own abstraction for iterating over its contents. Instead, I want it to use the iter package.
🧵
December 5, 2024 at 5:47 PM
Today in Glu world we added support for built-in history. History is tracked on a per pipeline and phase basis and available in the UI on main.
We also added API support for rollbacks (UI is under development):
github.com/get-glu/glu/...
Tomorrow I will have a video!
#buildinpublic #golang
We also added API support for rollbacks (UI is under development):
github.com/get-glu/glu/...
Tomorrow I will have a video!
#buildinpublic #golang
December 4, 2024 at 5:16 PM
Today in Glu world we added support for built-in history. History is tracked on a per pipeline and phase basis and available in the UI on main.
We also added API support for rollbacks (UI is under development):
github.com/get-glu/glu/...
Tomorrow I will have a video!
#buildinpublic #golang
We also added API support for rollbacks (UI is under development):
github.com/get-glu/glu/...
Tomorrow I will have a video!
#buildinpublic #golang
Big change going into Glu today with only minor face value.
A lot of the core types are moving around. The biggest being the move from phases and sources, to phases and edges.
The concept of promotion in Glu is a now a concern for edges.
#buildinpublic #golang
github.com/get-glu/glu/...
A lot of the core types are moving around. The biggest being the move from phases and sources, to phases and edges.
The concept of promotion in Glu is a now a concern for edges.
#buildinpublic #golang
github.com/get-glu/glu/...
December 3, 2024 at 3:30 PM
Big change going into Glu today with only minor face value.
A lot of the core types are moving around. The biggest being the move from phases and sources, to phases and edges.
The concept of promotion in Glu is a now a concern for edges.
#buildinpublic #golang
github.com/get-glu/glu/...
A lot of the core types are moving around. The biggest being the move from phases and sources, to phases and edges.
The concept of promotion in Glu is a now a concern for edges.
#buildinpublic #golang
github.com/get-glu/glu/...
I spent today building per pipeline+phase history feature into github.com/get-glu/glu.
It allows for tracking meaningful history per app + per env described in a config repo.
For reasons (I just love it), I am starting with bbolt as a backend (shoutout @benbjohnson.bsky.social).
#golang #gitops
It allows for tracking meaningful history per app + per env described in a config repo.
For reasons (I just love it), I am starting with bbolt as a backend (shoutout @benbjohnson.bsky.social).
#golang #gitops
November 29, 2024 at 5:50 PM
I spent today building per pipeline+phase history feature into github.com/get-glu/glu.
It allows for tracking meaningful history per app + per env described in a config repo.
For reasons (I just love it), I am starting with bbolt as a backend (shoutout @benbjohnson.bsky.social).
#golang #gitops
It allows for tracking meaningful history per app + per env described in a config repo.
For reasons (I just love it), I am starting with bbolt as a backend (shoutout @benbjohnson.bsky.social).
#golang #gitops
Been working on some small touches to the feedback in the UI for github.com/get-glu/glu today.
Now it little success toast will link you to any generated PRs (if you have proposals enabled).
#gitops #deployments #cicd #golang #buildinpublic
Now it little success toast will link you to any generated PRs (if you have proposals enabled).
#gitops #deployments #cicd #golang #buildinpublic
November 28, 2024 at 3:52 PM
Been working on some small touches to the feedback in the UI for github.com/get-glu/glu today.
Now it little success toast will link you to any generated PRs (if you have proposals enabled).
#gitops #deployments #cicd #golang #buildinpublic
Now it little success toast will link you to any generated PRs (if you have proposals enabled).
#gitops #deployments #cicd #golang #buildinpublic
Oh yeah and this is Stu. He is just happy he didn't become Glu.
No horses were harmed in the making of this Glu factory.
No horses were harmed in the making of this Glu factory.
November 23, 2024 at 1:04 PM
Oh yeah and this is Stu. He is just happy he didn't become Glu.
No horses were harmed in the making of this Glu factory.
No horses were harmed in the making of this Glu factory.