IMO there's quite a surprising amount of stuff you can do on GitHub that's highly undiscoverable. You only think of it when you see someone else on the site doing it, and then you don't necessarily know what it's called so you don't know how to research it.
Yeah, obviously this is literally what something like Jekyll or Hugo does. It's just (at least to me) a simpler version of that where you can fully see what's happening. Also I didn't want all the theme-ing overhead that comes with those - just something I could inject into my existing site.
>Also I didn't want all the theme-ing overhead that comes with those - just something I could inject into my existing site.
I didn't like how complex that stuff is with Nikola - I didn't have an obvious entry point for making the kinds of customizations I really wanted, and yet there was still so much to look at in order to understand the system. But at the same time I really didn't want to spend hours re-learning CSS more or less from scratch, when I could actually use the examples already in the existing themes.
I did something really awful: instead of trying to make yet another layer of theme "extension", I copied everything locally and have been condensing it as I go.
This had the benefit that I didn't have to decide on a bunch of CSS classes up front in order to have anything look passable. There may be tons of unused stuff, but I'm cleaning that up as I implement my own things - and bit by bit, I get something smaller and more comprehensible that fits my mental models. This conversion process might not be any faster, but I'm certainly enjoying myself more.
At some point in the future I'm considering doing a simple templating engine and converting these templates (originally Mako) to it. It just irritates me that I still have to deal with close tags - both in HTML and in template directives - when I'm doing everything in Python. I have a vague memory of a 2010-era JavaScript templating system - I think it was called Express or something like that? - which used indent-based syntax without closing tags. So I'm inspired by my recollection of that.
Man this is sad … I think I’ve been visiting this site for its entire lifetime. AnandTech has always been the best place for unbiased, deeply technical looks at hardware and it will be greatly missed
As a long time C# dev, I feel like I’m missing something about this proposal. The use case for this doesn’t seem well defined to me. Could someone give me a real world example?
I’m pretty sure you can implement the example in this proposal by declaring an empty interface and having some record classes that “implement” it. Does that lose something that I’m not seeing?
That type of hierarchy is “open” in the sense that when you handle them you can’t know whether you handled all of them. Anyone can make a new implementation of your interface, potentially in code that isn’t yours.
Also, the options may not share any surface area at all, so the “interface” for all the types may be empty which is a bit unnatural in OO.
But under the hood, it’s just this: a type hierarchy. But the hierarchy is closed for extension, and (this is the key part you’d not get if doing this “manually” as you describe) when code uses the cases, failing to account for a case will cause an error at compile time.
I think the most down to earth example is the AST or data protocol examples. Take Jason for example. Instead of having a JsonValue class to hold the data you would have a Union type that is either string, bool, number, array of your union type or map type which uses a string as key and the same union type as value.
It would also allow to implement result types like rust has them. So you could define an API that returns a value or an error. I didn’t see in the proposal if they talked about generics though.
In functional programming world this is mainly known as algebraic data types. I can say that if you get used to model types like this you really start to miss it in languages that don’t support it.
This[0] lib implements F#-style discriminated unions. The way I've used it is to make my outer layers return "Result" types that wrap the DTO, error, etc. under one umbrella. It allows for pattern matching your results which makes error handling easier and also allows your models to evolve over time without changing your function signatures at the edge.
We have been using empty interfaces to simulate F# discriminated unions for the last 5+ years. It works like a charm. The problem "not all cases are handled in the switch" occurs very rarely (once per 50k lines of code) and, usually, we fix it after the first run of a smoke test. So, it's not a problem at all.
I think,.net team haven't added discriminited unions yet because it can be effectively simulated with interfaces.
A simple example is the Result<T> which could have either Ok(T value) or Error(string message). In order to get the value you need to switch over both cases, forcing you to handle the error case locally.
> No, this doesn't violate our policy of "no paid development", because donations are just that - donations. We will still not honour bug bounties or similar, and still not use our collective finance here for paid development.
IMO, there's nothing worse than paying people too little money. Well, other than unevenly paying everyone money.
"But it's $100 a month they wouldn't have had!" Sure, but now there's something to value your time and effort against, and it will not stack up favorably.
> IMO, there's nothing worse than paying people too little money.
In a for-profit project, I'd agree. Jellyfin isn't though, and they're pretty up-front about that, so "paying too little" doesn't really apply to the people who end up contributing.
You do not want your volunteers looking at the effort they put in and the money they get back for it. It's going to create negative feelings, and at the very least performance will suffer for a while. It's more likely that it'll cause a permanent problem instead, possibly even driving away volunteers.
> You do not want your volunteers looking at the effort they put in and the money they get back for it.
Why not? I think it's good for everyone to evaluate what you're spending your time on, and if that time is time well spent.
What do you mean with "the money they get back for it"? It's a FOSS project that doesn't pay for engineering hours from volunteers or anyone. It's literally $0, and everyone contributes to Jellyfin with the expectation of getting back exactly $0.
Location: Munich, Germany
Remote: Slight preference for hybrid/remote over in-office
Willing to relocate: Yes, EU, UK, or US
Technologies: C#/.NET, Ruby, Java, Python, Typescript
Resume: https://1drv.ms/b/s!Ag3bkT52WvfvgaxnCZ0ScxTPv80dBQ?e=ht35XQ
Personal website: https://www.vijayp.dev
Email: me@vijayp.dev
I've been a backend engineer for 14+ years at some of the best companies in the world. I love to solve hard problems and I'm passionate about quality, be that writing quality code or establishing good engineering practices. I have worked professionally in over 5 languages and personally in over 10 so I feel extremely comfortable spinning up on new languages and frameworks. I'm looking for an environment where I can learn and grow and feel challenged by the work.
