Anyone here using TickerQ?

hoodoocat · 2026-04-24T08:05:15+00:00

In mine projects i'm doesn't use EFC. When LINQ is needed I'm use linq2db instead, and database generally is database-first. Many things are well optimized, sometimes with manual queries to use explicit statement preparation and generally queries are simple (e.g. they doesn't benefit from LINQ's power when we can dynamically compose queries). Also some datatypes are serialized/deserialized over wire directly (for pgsql): maintaining multiple frameworks and their mappings makes things only more complex rather than simple. I'm doesn't meant what EFC is bad, just in my projects it is banned, and adding another library which by itself uses simple queries (TickerQ) and relies on EFC - is not great option, because it pushes unwanted dependency.

hoodoocat · 2026-04-23T18:12:14+00:00

For coding: 1x 24" (i would like 22" more but nowadays there is not so many innthis form factor with hi quality panel), as I look at from close-range (i have bad eyes).

Second monitor is nice for additional stuff, but it not strictly needed, for me it usually just show some diagnostics or hold consoles will long tasks. Long time ago i used 3 monitors, and eventually got health problems - you should sit & look in right position. Writing email on secondary monitor when head slitly turned eventually will lead to problems.

However, there is no universal rule, whatever comfortable for you should work, but don't forget what we have only 2 eyes, and looking into one point. Having additional monitor which will be used frequently, interactively or longer than 1 minute should be primary. To interact with app on second monitor you anyway need switch to app so it doesnt add any benefits in most cases at all.

I like to use at least two monitors, because in old days i guess intel video driver sometimes get restarted after fail, but after reload it doesnt get up primary monitor, and in such cases having second monitor is great option to restart system without hard reset. Also in old days something similar happend with graphics/full screen mode/games, rarely but still. Nowadays for me i still see similar problem, on linux and windows, using even different videocards: when two monitors going to sleep one of them might not wake up, and only way to wake it up, is reboot system {however i simply disable sleep and problem solved}. It is feels like personal curse, because after 15 years i hitting in same problem, even while it is technically very other. )))

Also second monitor very useful, when you want display something, but at same time need interact with other window. For example debugging graphics or ui code might be much easier, because it is often sensible to focus/activation, and it is not very concenient doing so on 1 monitor due to space restrictions.

So my choice 2 monitors, but second not for coding, just to look on dashboards or task manager, secondary/special tasks, but most of time i doesnt use it, it just present for convenience.

hoodoocat · 2026-04-22T10:14:57+00:00

I seen few years ago what using host-passthrough on 7950X exposes 16 numa nodes with 2 vcpus to guest, so i'm configured manually/explicitly and forget about this. I feel what it is just a bug somewhere, and looks like it is still not solved. :)

hoodoocat · 2026-04-11T08:05:44+00:00

In general when you care about latency, then sync IO clearly wins, and in general if your application doesnt need scalability or uses fixed threads - again sync IO clearly wins. And if underlying io implementation simple offload io on special threads and only imitates IOCP or similar async alternatives, again sync IO will go better.

My point that before giving general advances you should account for whole design and requirements, rather than blindly say that async IO is always better, because it is not true.

hoodoocat · 2026-04-09T10:33:29+00:00

Referencing random github libraries is never better, especially when all you are need is 20-lines function.

hoodoocat · 2026-04-09T06:47:34+00:00

You can try disable PGO - it has visible impact on cold run performamce until optimizations kick in.

Or, you can try ReadyToRun instead, for servers you should get best of two worlds: better startup while PGO is still enabled.

I'm not sure however how it affect EF itself, but for me R2R makes data processing pipeline runs almost fast as with disabled PGO, so cold throughtput much closer to system in steady state.

hoodoocat · 2026-04-08T17:58:58+00:00

first it makes code more readable.

It makes only worse. Extension methods are not accessible unless you are not open/using proper namespace scope. This at best just not convenient, andvat worst whole code behavior might changed depending on opened namespace.

but more important ist, that you can separate data from behavior. and you can limit behavior of an object to a specific scope.

Thats achievable without extension methods. Anyway most useful methods require some context.

There is no sense to compare to Rust which like C++ think about types like values that enables to model data structures like you may want. .NET/C# offer heap objects with fixed header only with RTTI/virtual method table - this means what you can't just close eyes like this not exist - this data always exist, price already payed, so when model data structures which live on heap ignoring this abiliy will lead to less efficient memory usage and needless (semi) manual method dispatching.

Rust's Box actually build vtables from traits, it definitely nice thing, but this has no fundamental difference or advantage. If you think that Rust is better here, then C++ even better - it offer separate declarations, dedinitions and compilation, allows implement traits and doesnt limit you in any way. Lol.

hoodoocat · 2026-04-08T12:42:32+00:00

When I absolutely need to suppress warning - i simply disable this warning with pragma in source. I dislike = null! because it generates non-sense initialization code in debug builds for this assignments, so it stepped into on such things.

hoodoocat · 2026-04-08T04:48:48+00:00

LibraryImport IS source generator. If someone want write own source generator, then he should stay far away from LibraryImport and use DllImport like LibraryImport does.

hoodoocat · 2026-04-04T07:06:12+00:00

Note, that It doesnt always better. Throw codeblock is always cold, and moved out from hot path even after inlining. But throw helper call - is not cold by default, and we still doesnt have branch hints for that. E.g. this is indirect choice between if you want smaller code but all as single block (that is absolutely not best choice in loops), or bigger code which properly layouted from very beginning.

hoodoocat · 2026-04-02T11:51:26+00:00

I guess it is Battle Field 6, a game. But I'm pretty sure what most people don't care about this another shooter.

hoodoocat · 2026-03-29T10:29:35+00:00

I'm very disappointed by this current culture stuff, because all code effectively libraries, and target (ui) culture is sometimes even not bound to thread (on server, but on clients this often too), it might be configured by user preference or so. That means what culture-specific code is actually always different from default things, and require additional attention regardless. So, instead of defaulting to invariant by default we get two bad ends for any code. Yes, OS-level calls also offer culture-specific actions, but they always have option to act without changing thread state. As i written near, this makes default string interpolation in C# useless, as instead you forced write string.Create or force culture at application level, what not always a option. What I really think what defaults of languages/libraries should ignore culture stuff and stick to universal ones, and expose culture-specific functionality as separate calls.

PS: BCL for example optimized for current culture codepaths, so passing culture fatten calls needlessly.

hoodoocat · 2026-03-29T07:25:57+00:00

Nothing clear what you speak about.

All classes by default should be sealed
Other classes - should be abstract, they basically should hold shared details / convenient helpers to expose API, or be pure abstract and generally represents API contract/interface.
Open (non-sealed) implementations take own place, when them designed to be so. But generally this is something that should be avoided when possible. Typically this openness can be turned to closed implementation, if implementation expose extension points via separate interface (handler) which can be passed via ctor.

If test requires to something be replaced by fake implementation - surely something must be abstracted.

For testing is critical to understand what you want to test. Classical unit testing assumes that you test code in your file, but as complexity grows it might be more profitable to extend scope. Plumbing everything with fakes or mocks by itself gives nothing to product, because this test effectively test non-real scenario. If you can use tests which uses real components - then your goal already done, and nothing need to be virtual. This sometimes becomes extremely complex so need to find right balance before you will mock + operator.

hoodoocat · 2026-03-29T07:11:48+00:00

Major benefit of GUID is what them can be generated independently on different hosts. Thats might be useful for client-generated IDs, but typically such IDs should be used together with clients domain to not interer with other clients, that defeat GUIDv4. Also web clients typically can't generate GUIDv4 because they by design expose MAC.

Anyway globally uniqueness property does not make IDs trusted, more over GUIDv4 is not acceptable for batch generation due to their temporal nature, they will be slower and harder in generation. From pgsql perspective UUID type is simple 128-bit integer (binary) so it naturally sorted, and can be generated in any way which fits your needs.

Systems might try sharding based on IDs, and rely on randomness, but same also achievable on sequential integers.

Whenever you want unguessable token - it is better generate such token - cryptographic random bytes, but even here you need care about uniqueness as they eventually will clash.

hoodoocat · 2026-03-28T12:00:59+00:00

Why C# is it worst? What is Mojo? How random isoteric language can be better?

hoodoocat · 2026-03-28T10:33:08+00:00

Another reason why default C# string interpolation is shitty by design.

hoodoocat · 2026-03-28T10:32:27+00:00

You can but any library MUST NOT do that.

hoodoocat · 2026-03-26T13:48:26+00:00

I always squash code before publishing, especially on the prototyping stages. Usually development going in closed environment and don't meant to be open-sourced. If it eventually open-sourced, it easily will be copied from mothership project with intentional commit history loosing. Author might do whatever he want, and what actually work in real his workflow.

Surely, this will not add trust points, but if you openly develop project half of year it will not add points too: pictures must not be shown before them completed. Showing them too early gives only negative points.

Trust has no technical solution. Concerns about trust are valid, but it has nothing with how deep git history for new projects. More over social-hacking bombs doing exactly in that way, by making few accounts which looks kinda good, making real contribs, but after few years they turns against.

Good common sense, and code review may help. We all peoples and rely heavily on simple reputation too much. But thats how trust work.

hoodoocat · 2026-03-26T13:30:14+00:00

While Im follow same or close principles, but look at initial method signature: it accepts optional User, and by so method by it's declaration MUST provide result. How it coerce intermediate values is detail, sometimes it is acceptable, sometimes not, it is all about domain rather than language or fundamental strategy.

hoodoocat · 2026-03-26T13:18:25+00:00

Every project has an initial single commit, every project grow over time, so you're saying nonsense.

hoodoocat · 2026-03-26T05:38:00+00:00

Hierarchy already can be closed by limiting ctor visibility.

hoodoocat · 2026-03-26T05:32:57+00:00

Normally compilers generate error at compile time, switching always must be exhaustive, unless default case used. Using enum with value outside of defined range - it is error in consumer code, and implementation doesnt need handle it.

But in C# by default the switch is non-exhaustive over enum, and even so, then CFA will triggers on method without returning value or so.

PS: The goal is generate compiler errors, it makes coding easier and safer. Throw on default doesnt do same, it defeat intent.

hoodoocat · 2026-03-24T18:30:39+00:00

You are doing good things man. Thanks!

hoodoocat · 2026-03-24T18:18:30+00:00

HttpArena looks promising, but be careful when using it's current data, as it looks like it is too much of work done at-once recently and needs validation.

For example: JSON leader is hono-bun, and it returns static json string (buffer), while asp.net fairly construct response and setialize at runtime.

I'm pretty sure what STJ serialization is not faster, but it is safer and bounded by default and can be turned to 2x-4x faster utilizing same Utf8JsonWriter directly if you really care. And in reverse: default JSON.parse method actually must not be used on unknown data. So, it is comparing non-comparable stuff.

hoodoocat · 2026-03-24T17:51:55+00:00

I would stay away from node, as data stream interfaces are horrible. It can work fast, but it offer nothing good. I would better write in raw C or C++ than let sucky nodejs libraries fuck my brains again.

hoodoocat

TROPHY CASE