Was I the only one that found `docs.fastht.ml/llms.txt` more useful than both fastht.ml and docs.fastht.ml?
Zooming out, it's interesting how many (especially dev-focused) tools & frameworks have landing sites that are so incomprehensible to me. They look like marketing sites but don't even explain what the thing they're offering does. llms.txt almost sounds like a forcing function for someone to write something that is not just more suitable for LLMs, but humans.
This ties in to what others are saying: a good enough LLM should understand a resource that a human can understand, ideally. But also, maybe we should make the main resources more understandable to humans?
Most of the links here help with your immediate questions, but if starting with base concepts and first principles is appealing to you, I have to recommend:
- the MIT Operating Systems Engineering OCW course [^1]
- specifically, Lecture #2 [^2] which describes the bootloader for 'xv6', a reimplementation of Unix v6, which does a great job showing what a solid OS with all the basics look like
Honestly I kind of just enjoy writing. My blog has gotten tons of views and still gets a fair amount of traffic, made on HN's front page a bunch, and have some post translated to a few languages.
I haven't actively tried to monetize it (though I'd like to shift to income based on my own work rather than be tied to a company). I tried putting ads once in a while and it was ~decent but negligible, and kind of ruined the vibe. I have done a few one-off consulting things out of it and got some nice side-cash, but nothing meaningful.
What I do get is feeling engaged with the wider tech community. Seeing common questions and comments. A feeling that what I'm saying might resonate with some people. Interesting discussions on Twitter and HN. A few podcast invites, etc.
I'm glad to hear! My series, starting with "Basic Concepts in Unity for Software Engineers" [0] is exactly designed for this and borne out of a frustration in much of the existing content.
Some folks in the replies mention just starting to code and while I totally agree, it was also helpful for me to understand... at least the concepts.
TBH when I started, the main way I did this was my finding a course on Udemy and watching it at 2x speed, still being bored out of my mind for huge chunks of it.
Sorry to hear that. I write/preview on desktop first and typically like the legibility that comes from the line spacing, etc.
What would you change to make this a better desktop experience for you? Less of the full-width photos? Text that spans wider, or just lest line spacing?
I totally agree with you. I think there are two types of "Where do I start?" that folks wonder:
- Say, I know what I want to build exactly where do I start? a.k.a -- What's the equivalent to starting at the DAO / API layer and building the integration later, in the gamedev world?
- I know I'd like to make games, where do I start coding?
I focused a lot in the article about that first question (and only briefly alluded to prototyping, etc.) -- mostly because I was interested in the theoretical question of engineering practices.
Trans folks in the LGBT movement were an inextricable part of the movement since day 1. Partly because distinctions at the time between gay men who did drag and trans women did not exist, but also partly because the overarching theme of the movement (and the hate it received) has been the sense of 'disgust' by mainstream society of its subversion of heteronormative values.
Many trans men and women lead the movement vocally when many gay men and women who could survive in the closet sat and waited.
But that's the thing, the good faith discussion happened so many times, and it has been litigated many times. For many of us, trans and non-binary folks gave us many of our rights, and they did not out of a sense of solidarity, but literally because they were fighting for the same thing (really, a revolution against gender norms and expectations).
As the gp said, however, this good faith conversation happens a few times (and has been litigated to death over and over, and continues to). But the domination in the "drop the T" movement is really dehumanizing language about trans people, accusing them of an agenda, brainwashing children, etc. It's really harmful, and it is things that gay, lesbian, and bi folks have been accused of already.
How do these work? Is it like going to the tiny settings menu and swapping the source on a monitor? I know the HDMI standard includes a way for an input to "request" a source to switch to it, are monitors with multiple inputs smarter about that sort of thing?
My work device is a Chromebook unfortunately and the policy on installing some of this stuff on it (e.g. also Mouses without Borders) is no good.
Maybe part of the reason this problem is less common than I'd imagine is because companies are not typically as strict on what you install on your work machine? My last job certainly was.
- it's weird to be mistreated by your employer's own product (just the irony bend to it)
- if you want to appeal after a dead end, your choice is to make a huge public PR nightmare, or try to make an internal post/plea that gains traction. you'd be doing your own employer a service if you could have this issue resolved without a PR nightmare
Gatsby doesn't offer a syntax highlighter out of the box. It has markdown (and MDX) components that generate pages, and those in turn can have syntax highlighting plugins. AFAICT prismjs indeed is the predominant one used by Gatsby sites (at least, in mine). But thanks to SSR prismjs will typically run at compile time.
Thank you! I'll bookmark this comment as I'm trying to take stock of what would be most helpful.
There are two kind of opposing directions I see a need for:
- "Beginner Unity" take tailored for an Engineer. E.g. let's talk about the input system, frame-rate independence, overview of rendering/lighting, a high level overview of the editor, etc. And get that out of the way.
- Satisfying what I might call a thirst for idioms/best practices from a SWE perspective. E.g. separation of concerns in MonoBehaviors, using ScriptableObjects, etc. Also maybe overview of things like "Should I still use Git with Unity or look into Collaborate?" and the like.
My current sense is that I'll end up toeing the line between these two. But, regardless of this specific series, I enjoy writing about best practices and software patterns in anything I'm working on, and Unity is no exception -- so stay tuned!
I'm with you there, but (and, this is an unpopular opinion) I think it would be even better if it went the way of Go. Go will randomize iteration order of unordered collections (at least in development builds?) on purpose so you learn not depend on it. The "tricky" thing with Unity is that you might find a consistent client behavior and unknowingly depend on it.
I think with time/experience you'll learn to spot what to ignore (frame lengths, etc) and what you could count on. And just to test fully-build games often, and across clients.
* C# does something similar with hash across builds (so you don't depend on serializing/deserializing hashes and expect them to work; they want the freedom to change hash functions).
"Best guess" can be bad if it is not well-defined, but you can still make error detection obvious rather than hidden.