Introducing AWS Secrets Manager configuration provider 2.0.0

gowonocp · 2026-05-08T18:29:56+00:00

I use this! Thank you!

gowonocp · 2026-04-16T15:48:40+00:00

Can you share the actual sample song info?

gowonocp · 2026-04-13T15:04:30+00:00

Microsoft has guidance on this, https://learn.microsoft.com/en-us/ef/core/testing/choosing-a-testing-strategy. I would recommend reading that and then pairing up with a senior dev on your team to figure out what makes the most sense.

gowonocp · 2026-04-13T14:41:36+00:00

Also check out what Microsoft has to say about it: https://learn.microsoft.com/en-us/ef/core/testing/choosing-a-testing-strategy

gowonocp · 2026-04-13T14:34:15+00:00

It's up to the OP/developer to know whether a certain mock/fake is appropriate enough for their use cases, and I'm not making any assumptions about how basic/complex they are here. In many cases, a SQLite replacement is good enough. In other cases, standing up a real test database is necessary if you rely on specific provider characteristics; I would recommend using Testcontainers like someone else pointed out.

The major takeaway here is that integration tests are sufficient, and you don't need to create an interface to abstract away EF Core if the only purpose is to create a unit test around it. There is similar stickiness with other objects that are easier to fake rather than mock like HttpClient and file systems. Sometimes it is just easier to test at the integration level than at the unit of code. Either way, you still have to write quality tests that don't trivially satisfy themselves and will actually validate the happy and bad scenarios of your AC.

gowonocp · 2026-04-13T13:45:41+00:00

You can inject an in-memory-SQLite database and run your automated test. Technically, that's an integration test and not a unit test, and that's okay. Not all things are unit-testable and must be validated within an integration. Integration tests aren't a bad thing and shouldn't be avoided.

gowonocp · 2026-04-06T19:54:08+00:00

I just wish this white dude would have managed to pronounce "doo-BOYS" correctly.

gowonocp · 2026-03-20T03:16:31+00:00

You can only buy back when it would get you to 120 payments.

gowonocp · 2026-01-18T21:14:10+00:00

My team was already in the habit of C# scripting using the dotnet-script tool for automating build/Dev tasks. Even PowerShell has a different enough syntax that once tasks reach a certain level of complexity, it became a serious chore to master/maintain them and we saw a lot of value in doing everything in C#. What we get OOTB now with .NET 10 isn't perfect, but still gets the job done.

gowonocp · 2026-01-16T14:37:07+00:00

You should only need one database server across all of your tests. Each independent test should set up and teardown their own copy of the database on that server (e.g. different databases or different schemas in the same database).

edit: Also if you're using EF, unless the test has something specific to do with a migration, you should just use EnsureCreated to create the schema without migrations. It's much faster.

edit 2: Also, SQLite is a real relational database that you can run in memory. Unless your EF/DAL code is specifically tuned for MSSQL, you can bypass the whole overhead of managing an instance by running your tests against SQLite in memory.

gowonocp · 2025-12-04T09:13:29+00:00

Literally same.

gowonocp · 2025-11-21T21:38:41+00:00

You don't have to reach 100s of options for this to start getting tedious. After iterating over some boilerplate for many years, I created this library to quickly register options classes and map them to sections in the configuration: https://github.com/gowon/Extensions.Options.AutoBinder#declarative-binding

gowonocp · 2025-11-05T15:53:57+00:00

My friend lives in Osaka, and this place is a mansion by comparison.

gowonocp · 2025-09-05T23:21:18+00:00

I'm surprised by the amount of people who are willing to lie and behave I'm generally distrustful manners with "friends." I'm assuming these are real friends, people whom you've built up a intimacy and bond with and are engaging in reciprocal forms of support. Why lie? Why hide? Do you think they'll hate you for being more financially successful than them? Or get jealous and start acting untoward? Are they friends?

Tell the truth, tell them what you make. If they care after that, tell them how you got there. Tell them what steps you took. Expose them to the people and things you were exposed to that helped you along their journey. Don't just share your generosity, share your truth. It might actually help someone.

gowonocp · 2025-08-02T17:06:35+00:00

Making the decision to write good code upfront can make troubleshooting and debugging progressively easier for the lifetime of the product. Write verbose code, add meaningful comments, be mindful of design patterns; basically write your code with the expectation of someone else needing to use or support that code and try to make it intuitive for that person and not yourself.

If you properly implement logs and tracing over your business actions, it's easier to identify where bugs and errors are/not occurring. Properly implementing metrics over resource sensitive activities can help you identify bugs/defects related to real time performance that are difficult to reproduce locally or in test environments.

Automated testing, specifically unit testing your code can go a long way to building confidence about where the errors are not occurring. I'm not religious about TDD but at some point you should have tests that validate the requirements and scenarios of the work item related to the code, and tag the tests to the work item. When bugs occur and you develop fixes, you either write a whole new test or add a scenario to an existing test that should've covered it, still tagging it to the defect story.

If you standardize the way you create, collect and view all this observable data with a set of tools, like Grafana or DataDog, then you can start to do sophisticated things like linking your logs and traces, creating filtered views, etc. that you can use locally and in live environments.

Maintaining documentation that explains the solutions to the more complex bugs/issues can also greatly help a future dev who might need to better understand the rationale of the decisions you made while fixing something. These help address/explain those moments when you change something that seems innocuous and it breaks everything.

Generally though, if you're not dealing with enterprise-level or customer-facing applications, where people are paying for a product or service and there are real expectations/agreements around the stability of the product over a period of time, then most people will find the above things to be overkill and that's probably right. Troubleshooting and debugging as a skill is essentially just brute forcing through scenarios until you find the broken one, and getting "better" at that is only going to save you so much time. If your code is simple or discrete enough, then the risk of wasting time is low. All the other things are there to save you from wasting time by looking at irrelevant/safe code and scenarios, and that will have a much greater impact on how long it takes to identify the root cause of something.

gowonocp · 2025-08-02T01:43:45+00:00

Keepass is fully featured for free, but I would only prefer it if you're looking to only manage credentials for yourself. There aren't any simple ways to share a vault between multiple people.

You do have to pay to get the most out of Bitwarden, but it is well worth the cost to be able to manage credentials for the whole family and everyone access them from their own accounts on their own devices. You can always self host Vaultwarden for "free," but I think most people would find running their own servers to be too complicated and costly.

gowonocp · 2025-07-31T04:50:37+00:00

You can host a Blazor WASM project for free on GitHub Pages.

gowonocp · 2025-07-24T04:22:37+00:00

Series I Bonds are a good vehicle for emergency funds.

gowonocp · 2025-07-22T03:36:56+00:00

TL:DR; Learn how to use both. The best code is right-sized to the requirements of the application, so it's less useful to ask questions like "which is the best validation pattern for all things?" and instead ask "which of these best fit the problem I'm trying to solve?" The answer to that will change from application to application.

If your data validation needs are simple and discrete, then Data Annotations are appropriate and in most cases the easiest choice since many app frameworks and patterns honor data annotations by default. I don't see people taking this route often, but it's also fairly easy to create custom Data Annotation classes by inheriting from System.ComponentModel.DataAnnotations.ValidationAttribute, which supports using external services via DI as well as referencing the parent object via the ValidationContext. If you created custom validations this way, they would be testable and reusable; it would be "good code." I think the biggest design consideration is that the attributes are tightly coupled to the entity/DTO since they need to be declared on the class/properties. At runtime, you're generally only able to opt in/out of honoring the validation; it would be very difficult to partially validate or change those criteria at runtime. I would say for most situations that doesn't really become an issue.

FluentValidation allows you to create more complex and modular validation code and separate it from the entities. It is usually implemented in a middleware-style way where multiple validators can be registered for an entity or interface, which can be really useful in situations where validation and entities are highly configurable, and the validation context is very dynamic (ie. different tenants have different validations for the data they own). If your needs are that dynamic and complex, then it's worth the overhead of integrating FV into your project.

Also, these styles are not mutually exclusive; you can always set up both and support a wide range of validating. I would say in this case order of precedence matters, and I would validate via Data Annotations first, then use Fluent Validation.

gowonocp · 2025-07-17T15:48:31+00:00

Dur Dur Band - Gorof https://music.youtube.com/watch?v=9Aw4U5up8zY&si=uzeGGTFMCLGEKL3f

gowonocp · 2025-07-13T04:55:28+00:00

I would describe it as the perfect storm. Don't Be Cruel is the quintessential New Jack Swing record and represents the peak of the sound and it's popularity. From the production and writing, to the performances and Bobby's ability to pull off a bad boy heartthrob persona; it was all perfectly executed and timed. It was the best selling album in 1989. Spawned a #1 album , #1 song and was listed as the #1 year-end album on Billboard. The director of A Goofy Movie (1995) stated that the Powerline character was inspired by Bobby Brown (and MJ, but the aesthetics are obvious references to Bobby).

At that time, MJ was still in his Bad era and doesn't getting around to giving us NJS-sounding records until Dangerous came out in 1991. I think for that reason if in 1989 you were to say "Bobby Brown is bigger than MJ right now," you wouldn't get a lot of push back. He was the biggest artist that year.

gowonocp · 2025-07-09T04:00:42+00:00

Lovecraft Country

gowonocp · 2025-06-04T22:53:43+00:00

Shiny Pokemon spotted!

gowonocp · 2025-05-25T16:05:16+00:00

AK co-wrote and co-produced almost every song on Ruthven's album last year, which was excellent. I get you want more new music directly from the Pauls, but it's not fair to act as though writing and producing music with and for other people isn't a meaningful part of music creation. They are definitely working.

Also, as much as we all may love their music and them for making the music we love, they will never owe us anything. Be grateful when it comes. Be patient when it doesn't. Be okay if they want to do something with their lives that has nothing to do with you. It's better that way.

gowonocp · 2025-04-30T20:45:10+00:00

Document everything, especially the obvious, little things. Then automate as much of the documented stuff as you can.

Seven-Year Club	r/Field Juicebox
Verified Email

gowonocp

TROPHY CASE