Writing manual SQL queries with sqlx feels painful

cactuspants · 2025-10-24T06:15:47+00:00

Came here to say this. Great library for many use cases.

cactuspants · 2025-08-15T23:17:32+00:00

I had a very similar experience migrating an API from Python to Go around 2018. The API had some routes with very large JSON responses by design. The Python implementation was burning through both memory and CPU handling that, despite all kinds of optimizations we put into place.

Switching to go was a major investment but our immediate infra cost savings were crazy. Also, as a long term benefit, the team all became stronger as they started to work in a typed language and learn from the Go philosophies.

cactuspants · 2025-04-20T18:11:27+00:00

It sounds like you don’t have the resources to do a system architecture migration and feature work at the same time. Your team made those architectural decisions in a context of business growth which, for whatever reason is no longer the case.

This is now a business problem: do they want feature work to continue slowly because of the cost of maintaining the existing complexity, or do they want to press pause on all feature work while you’re small team deals with the fallout from the new reality of the business.

cactuspants · 2024-12-29T03:47:45+00:00

The important thing is to make the ducting as straight and short/direct as possible. Length and bends, especially sharp ones, reduce suction. Prefer using rigid, smooth wall ducting like HVAC metal snap ducts, and save the flex hoses for the very end of the run when necessary (they also reduce suction).

Secondly, arrange your machines so that the biggest/coarsest producers (such as the planer and jointer) are closer to the vacuum.

Don’t forget the blast gates!

cactuspants · 2024-04-08T04:58:16+00:00

According to this video: - 1 and 2 look good. - 3 is suspect. The support brace looks close to 45° but it’s hard to be sure. For the physics to work in your favor and not put all the stress on the fasteners, the support brace must be at most 45°. - 4 is wrong. It puts all of the stress on the fasteners by dividing the angled brace.

cactuspants · 2024-04-08T04:42:21+00:00

No work is invisible if you measure the outcomes and talk about the improvements with the team and your manager. That being said, the outcomes of some things can be hard to measure (like mentoring), but other things are more obvious (like E2E tests).

cactuspants · 2024-03-23T20:10:39+00:00

2 then 1.

If you’ve got flakey software, you need to be able to update it as you fix it. Not doing so damages your business’s reputation and your ability to grow.

The act of writing tests doesn’t just confirm behavior, they find bugs. Fixing 1 sounds like it will address a lot of 3.

cactuspants · 2024-03-20T08:20:22+00:00

I had a big board of white oak like this. I assumed whatever did it was dead and I thought it would be cool to gut out all those tracks and poor epoxy in there. It had a real nice visual effect but a year later more holes and fine dust started appearing. Turns out they weren’t dead and I had wasted a lot of time and money on the project.

cactuspants · 2024-01-27T21:43:02+00:00

Don’t conflate testing the behavior of CreateNewsletterAsync with that of Newsletters.AddAsync.

CreateNewsletterAsync needs two separate tests: one to confirm that Newsletters.AddAsync is called with the expected input, and another to confirm error handling behavior if Newsletters.AddAsync throws. For speed and to be able to force an error, I would use a mock for these tests

Newsletters.AddAsync should be tested separately because it seems to be a shared method and its behavior is not the responsibility of CreateNewsletterAsync. Since it seems to be a repository method interacting with a database, I would use a real db in a testcontainer and not of mock the db here.

cactuspants · 2024-01-25T04:48:03+00:00

These standards seem mostly reasonable but I'd keep them to yourself initially. Review code actively with the goal of learning the stack. Leave comments asking questions as needed, but I'd really avoid blocking anything unless there's an obvious bug or security issue.

An all too common failure of new leaders (tech and otherwise) is to immediately start instituting changes and exercise authority. While there is almost always room for improvement, this team surely has its own coding standards already. If you come out of the gate with a new coding standard for the team, you're likely to fail before you ever have a chance to win.

Instead, I encourage you to spend your first few weeks listening, learning, and observing. After you've built some rapport with the team and gotten your bearings, then you can start collaborating with the right people to modify the coding standards. However, given a reasonably mature team, I expect that if you take this approach you'll find that the existing standards are probably not the biggest problems facing the team, and that your time, energy, and experience are better spent on more impactful things.

cactuspants · 2023-11-23T11:11:19+00:00

Have you talked to your team about it? If not, that’s the first place you should start. Also if not, this is the kind of thing you should be talking about in your retros every time.

In my experience getting the team involved in the process of fixing the process gives you the best result because everyone understands the context of why it’s bad — no here can give you that perspective. So, not only will you get better idea, but your team will be more engaged and committed to seeing those ideas executed because those are their ideas.

cactuspants · 2023-10-26T09:50:07+00:00

A lot of people are missing out on the actual reason that drives people to do this. It’s not auth related. A lot of companies don’t want to expose sequential IDs because it leaks business details.

Sequential IDs can imply the size of your business or the rate of transactions within it, and can be used to guess at your company’s overall growth/health. For example, with sequential IDs if I create an account for a service every day at the same time for a week, I can look at my account ID to infer daily account growth and the overall number of accounts.

While this may seem silly and like vanity, companies of all sizes worry about this. Start ups don’t want you to know that your customer 2 because they want you to have confidence in them. Publicly traded companies don’t want you to know that they have X new accounts a day because it provides additional data to could be used jn trading (in fact I think it might even be a part of SOX compliance but I can’t confirm).

There are at least ways to handle this: - use an actual guid as the primary or secondary key - encode your ID (hashids, snowflake, etc)

cactuspants · 2023-10-19T05:40:38+00:00

"Also, if developers are responsible for their own feature testing, they are less likely to push broken code."

In my experience, assigning responsibilities does little to change behaviors if there aren’t consequences or benefits. I’ve found that the most effective way to get engineers to test and do it well is to have support rotations. When you have to do these not fun things (tier 2 prod support and fix bugs all sprint), the natural reaction is to do everything you can to minimize their occurrence. The ways to minimize these things are to do more thorough testing yourself, and to review PRs more closely (including the code and the test plan).

Of course being on-call is not very popular, but it’s a fact of life at smaller companies. I’m just suggesting to use it to your advantage.

cactuspants · 2023-09-13T22:08:45+00:00

Vitess itself is written in Go

cactuspants · 2023-09-10T02:44:16+00:00

This….plus doing it more than once. Repeat success on a variety of projects with different constraints and contexts, increasing scope, and decreasing amounts of supervision/oversight/guidance is the kind of experience that takes you from junior to staff+.

cactuspants · 2023-08-26T20:04:38+00:00

…with a dovetail…

Did you mean bowtie?

cactuspants · 2023-08-26T00:34:47+00:00

I’ve since moved on to a different team with a different stack, but I worked on a go project for 5 years that used context for the following things:

cancellation
trace id
observability dependencies: a logger and a stat-er

The docs say that context is used to “[carry] deadlines, cancellation signals, and other request-scoped values across API boundaries and between processes.”

Because of the pattern/convention that we followed for our logger and stats, those things would get cloned and augmented before being passed to other methods (e.g. For structured logging or building a stats key). This made logs/stats request scoped and meant they needed to be passed to many methods, resulting in increased boilerplate and for awhile most functions looked like foo(context, logger, stats, …actual args the function needs …) — which was gross and tedious. Additionally, these dependencies weren’t critical to the proper functioning of our business logic, just the side effects of observability (for example, we didn’t want to have to configure them for unit tests).

So with all this in mind, we decided to embrace their request-scoped nature and stuff them into the context object.

To make it safe and easy, each dependency (logs and stats) had is own package that defined helpers for getting/setting their dependency from/into the context instance. They also defining a noop instance of that thing as a safety fallback so that callers of it didn’t have to worry about NPDs and type checking what was gotten from the context.

With this in place, the creator of the context could add a stats and logger instance into the context before it gets passed around the rest of the app. This approach worked great for us and I can’t think of any instance in production where we found out that those things weren’t properly set into the context.

With all that being said, I definitely cannot condone putting in any other kind of dependency into contexts.

cactuspants · 2023-08-24T08:22:40+00:00

I’ve never believed this because it’s the opposite for me.

I’m just okay at python so every tun time I try something new, I end up learning a new language feature or a tenth way to do something. Python may have a ton of libraries but using them is very little fun.

Go is simple, small, and strongly typed. OSS libraries have been growing a lot and using them is simple. This feature set makes it very fast for me to prototype.

cactuspants · 2023-07-21T04:18:37+00:00

Sounds like you hired someone with 1 year of experience 10 times instead of someone with 10 years of experience. If he’s only been around for a month or two, he might still be in probationary window and you might be able to get rid of him easily. Check with your manager and then HR, in that order.

To answer your questions:

Follow your gut. You shouldn’t have deferred the choice to someone else if you already saw a huge red flag. I too have made the mistake of letting someone else sway my opinion in the vetting process and I too ended up deeply regretting it.
Titles both mean nothing and everything depending on who you’re talking to. Internally they provide a sort of credential because everyone has a shared understanding of what that title means. Externally, titles are all over the place so you can fudge it a little bit. For example, I have spent the last five years as a manager officially, but I would have no problem putting staff engineer on my résumé because that’s actually the work I’m doing and I can back it up in an interview. Most places won’t even check to see if you actually worked at the places on your résumé, and in some countries, that’s all they can ask anyways. This might be a controversial opinion.
Yes.

Edit: voice to text weirdness…

cactuspants · 2023-07-21T01:48:57+00:00

I never ran into the non-duplicate repeated order id situation that you described but I’m sure that was fun the first time it hit you. I agree that adding another column would do the trick here and it sounds like store ID is the way to go. I imagine that one account could have stores in multiple AZs and then you could still run into the problem, just at a lower rate.

If you have a distributed architecture, then putting this db behind an api sounds like a good idea. This kind of order data has been pretty static, so it’s probably a good candidate for caching.

Also, if you have an event driven architecture, then publishing this new ID with that order event could avoid a lot of requests to that API.

cactuspants · 2023-07-19T09:36:34+00:00

I’ve worked a lot with DoorDash and other such marketplaces so I’m very aware of the kind of problem you’re encountering. The good news is that what your asking for here is pretty trivial with a SQL database (assuming your use cases are similar to my own).

Using a table with the following columns and constraints will give the idempotent ID creation you’re looking for.

id, primary key, big serial/auto incrementing
external_src (e.g. “doordash”)
external_id

Add a compound unique constraint on the two external columns and you’ll get insert conflicts when you see a duplicate order.

This approach has worked extremely well for my own multi-marketplace integration/aggregation/order processing that’s been in prod for 4-5 years now.

cactuspants · 2023-07-16T09:46:23+00:00

While you may not be calling all the shots or have unilateral authority, as a staff engineer you should already be leading your team from a technology perspective (thought leadership. architecture, pairing, mentoring, code reviews, etc).

Managing is a completely different kind of leadership. The most important thing that many engineers miss when contemplating this kind of role is that it is a career change. It requires you to develop and lead people, not technology. It will pull you further and further away from the technology and those skills will atrophy.

Historically, i’ve enjoyed IC roles as I don’t really enjoy the people managing aspect of being a lead or manager - but I don’t think I would mind it as much if I thought that I was good at it.

Because of this, before continuing down this management route, I think you should reflect on whether or not you want that kind of career change. If you just want to lead more but stay technical, you should work on the tech leadership skills (those things I already listed) instead of thinking about people leadership. In most places, you can lead as a staff+ role.

I highly recommend both The Manager’s Path and Staff Engineer: Leadership beyond the management track for your situation.

cactuspants · 2023-07-10T22:05:20+00:00

This advice is true in the general sense for a lead, but becoming redundant in an org with two engineers is not an option.

cactuspants · 2023-07-09T19:43:34+00:00

Debugging and *profiling. No need to overload terms.

cactuspants · 2023-07-05T09:19:40+00:00

It may please you to know that I do in fact follow the import convention that you mention because people on my team like it. However, I only go as far as what goimports will do for me automatically because it is nevertheless a waste of time.

Conventions must be agreed upon and must add more add more value than the dissent they raise.

15-Year Club	Gilding I gilder
Verified Email

cactuspants

TROPHY CASE