This track is by an amazing, long-standing musician that goes by the name watson and I listened to their entire catalogue and made a playlist of my favourites to be able to easily select a piece that fits any game I'm working on. Their umbrella website MusMus is https://musmus.main.jp and whilst you'll need to run browser translation on the site you will see all their music sorted across many categories. That said, it is definitely easier to listen to their music through the albums they've released on streaming platforms: Spotify and Apple Music for certain, and probably others. They're also on YouTube.
Of course, there are many more Japanese services and people writing great royalty free music. Another of my games used royalty free music by a young Japanese musician named YuyakeMonster, again picked specifically to fit a particular game: https://soundcloud.com/mac-vogelsang/sets/sparrow-solitaire
It would be nice if I stopped needing to update the fsproj file for imports and hierarchy. If this could be dynamically built using a topological graph approach that would be a huge improvement. I don't use a heavy IDE so it's kinda tedious to need to update the fsproj file when i want to add a new file.
Personally I strongly prefer F#'s way, and I always enable it manually in C# by setting `<EnableDefaultCompileItems>` to `false`. It's so much easier to debug e.g. compiler deficiencies/bugs when you can just binary chop to find the file that's causing a problem, and the reason you can do this is the linear ordering of explicitly listed files. (In C# I generally just give up and hope that someone else will do it, because it takes so much longer; in F# it's trivial.)
What are you using as your development environment? Personally I don't find the overhead in Vim to be too onerous (`yypf"ci"NewFile.fs`), and even in Rider I routinely edit fsproj files manually. (I even create new projects mostly by hand.)
QUIC requires the initial handshake packets to be at least 1200 bytes, and sets the anti-amplification limit of 3x [0]. This means that the server can typically send up to 3600 bytes in response (unless the client's handshake message exceeds one packet, which usually only happens if there is a post-quantum key share in it). 3600 bytes is usually enough, unless your certificate chain is too large, in which case you'd need to compress it. [1] is a nice overview of the problem.
QUIC explicitly mentions that it is vulnerable to amplification attacks in the RFC. It suggests sending an extra packet to mitigate, at which point I believe the advantage of QUIC is lost as far as establishing connections is concerned.
I believe you're referring to the stateless retry mechanism? It's designed to be used only when the server is actually under attack (either as an amplification vector or exhaustion of its own connection capacity). The idea is that the server establishes some threshold for pending QUIC connections, and only if that is exceeded does it start requiring clients to complete the extra stateless, SYN-cookie style roundtrip to validate their source address. So it maintains the advantage of one less roundtrip than TCP+TLS unless the server is receiving large amounts of connections that are not progressing in a timely manner.
If the startup is tiny (less than 10) then I would give the benefit of the doubt to the company. At that size, it’s mostly tapping your network and not having any full time recruiters who can prioritize things other than “I need somebody, anybody! Help!”
> The only group not benefitting from RTO are the actual workers.
That depends on the worker’s goals. If your goal is to have work/life balance or “personal” productivity then, yeah, I empathize. But there is more investment I put back into my team when I’m in person. It’s not just my code output. I find it very hard to mentor young engineers remotely.
Also, if you are a stockholder, like many engineers, and if teams do in fact have more “synergy” (bleh) then it’s also good for the workers via stock based comp.
When I was young and learning my trade I had a group of older co-workers who decided they liked me enough to invite me to join their lunch group. It was a very informal mentorship, they showed me the ropes, provided guidance and generally made me better at my job. This was all because they knew me enough and liked me enough to put in the effort, they got little out of it other than enjoying watching another guy come up in our field. Now I'm a grey beard with less than a decade left and I'd like to return the favor but to whom? I don't work in an office and I have no relationship with most of my co-workers, I do my job and they do theirs. Management could force me to mentor one or more of the engineers but that probably wouldn't work out very well for anyone. There's no relationship with my co-workers anymore because we never see each other and while slack and zoom is great for a 20 something it just doesn't work for me and in the end I'm the one with the institutional knowledge that I won't be passing along to the loss of both the employee and the company.
If the worker's goals aren't pro-worker then the business certainly won't be. Your goal of training others is admirable, but that can be often be remote and won't stop them from getting rid of you the moment it is convenient.
Call me lazy, but tryping the latter took me 20 times longer. I totally would use it for internal state, but I would not store it like that or expose that to users ever.
But you're talking about JSON, not a concise string that is exposed to users, and not a data format optimized for size. If you want more than a basic type you give it structure - and durations are not trivial types nor common enough to deserve their own representation.
Durations optimized for storage without ambiguity would be the tuple (u64, u32, u8) where the first value is seconds, second value is nanoseconds (if precision is needed) and final value is epoch.
Durations displayed to a user wouldn't ever be stored so the point is kind of moot.
Optimizing for "time it takes someone to write it once" is kind of dumb since it happens once while reading it happens often, and parsing even more likely.
It just depends on how you are using the JSON and where it fits in an application. If I'm using a static language, it is common for me to have a TimeSpan (or similar) type and standard rules for how it can be serialized (e.g. toString, toJson, etc). In this scenario, I don't care how it is represented in JSON, I just want convenient (de)serialization.
With your example, I would need to create custom parsing logic, and handle a dynamic number of JSON fields. But if a TimeSpan class had JSON deserialization built in based on the ISO8601 format, then I wouldn't need to do anything special. That's the benefit of using the standards. Same if I wanted to convert the JSON stringified format into a postgres time span there isn't any special parsing logic I need to do.
Yes, it's just a string in JSON, so it's not semantically special. But other languages that have a TimeSpan type could take advantage of the standard serialized format.
Here is an example of what it could look like in F#, no special logic for deserializing into a custom type:
type MyEvent = {
myDuration: TimeSpan;
createdAt: DateTimeOffset;
eventId: string;
}
let rawJson =
"""
{
"myDuration":"P15DT5H0M20S",
"createdAt": "2023-08-24T20:30:00Z",
"eventId": "e_1234"
}
"""
let myEvent = JsonSerializer.Deserialize<MyEvent>(json = rawJson)
I see your point, but I guess I don't see the difference between it being structured as a string with a second deserialization step after JSON deserialization. I see the convenience of a standard way to deserialize the time stamp.
But either way you need multiple pieces of data for the duration to be correct and useful. Without the created-at time in your example the duration will be invalid in the presence of leap years/seconds.
If you want to unambiguously encode a duration of time, it needs to be in the smallest unambiguous unit that is meaningful (usually seconds/nano seconds). That will allow your duration to be correctly used without any additional logic/metadata packed along with it.
Like what? I’d like to hear what royalty free Japanese music sounds like.