That’s silly. Luckily, I don’t think this was the same situation. This was at a university and they had classes with other languages. The beginner classes were split into two variants, where some students (mostly CS students) learned C, and other students (economy, etc.) learned Python. I suppose they figured it was more useful to them or something.
I was a teacher’s assistant in beginner’s programming at university for a bit. I expected them to learn C, which I knew enough of, but I got assigned to a group that learned Python instead. I had never used Python at the time. I ended up having to speed learn it while trying to teach it, to not be completely useless.
That’s definitely part of “the deal” with MIT and Apache. The other end of it is that they shouldn’t really expect to get anything more than what the authors are willing to give.
The rabbit hole goes deep if you really feel like going spelunking. A basic understanding of RGB, HSV and HSL takes you very far and lets you do a lot of things already. It’s good enough as long as it looks good, after all. 🙂
You really don’t need to read all of it to get started!
This depends a bit on what you are looking for. The library documentation is supposed to guide you to a practical starting point, but it’s still quite light on the theoretical parts. I haven’t really collected any specific beginner material, so this may still be a bit technical. There’s a ton of info about the basics, with varying levels of detail.
Assuming you are starting from almost nothing, I would recommend getting familiar with what RGB is and how its components relate. This is the format most images are encoded in and most devices and software use. The Wikipedia page is quite thorough, so no need to read all of it: https://en.wikipedia.org/wiki/RGB_color_model
Next, it’s good to know there are other models. HSV and HSL tend to be used in color pickers (a bit more intuitive than RGB), so you have probably interacted with them at some point. Again, the Wikipedia page may be a good source: https://en.wikipedia.org/wiki/HSL_and_HSV
That’s often good enough for producing colors and reading or writing images. If you want to go more into editing, it’s good to know that you will need to massage the values you get from the images. They usually don’t represent the actual light intensities, so they have to be made linear. Palette offers functions for it and represents it in the type system. This video is a slightly simplified explanation of the problem (when it mentions the square root, it’s an approximation): https://youtu.be/LKnqECcg6Gw
At some point, you will realize that neither linear nor non-linear RGB is the universal answer to good looking colors. They are used in different situations. There is another category of color models/spaces that are called “perceptually uniform”, meaning that they try to simulate or predict how we actually experience the colors and relate it to the numbers in the computer. This page shows the problem and introduces one of those models: https://bottosson.github.io/posts/colorwrong
I can probably provide more sources if you have any specific things you want to read about, but this is a start.
A “mantra” more programmers should have is to fix the cause of the issue, and not just the symptoms. You have to understand what the problem is to be able to fix it.
Simple features are often complex to make, and complex features are often way too simple to make.
It may be possible to use the Any trait to “launder” the value by first casting it to &Any and then downcasting it to the generic type.
let any_value = match tmp_value {
serde_json::Value::Number(x) => x as &Any,
// ...
};
let maybe_value = any_value.downcast_ref::< T >();
I haven’t tested it, so I may have missed something.
Edit: to be clear, this will not actually let you return multiple types, but let the caller decide which type to expect. I assumed this was your goal.
I considered the smaller one at first, but decided to take the larger one and use the compression straps to keep it tight when packing a smaller volume. It doesn’t feel as bulky as I thought it would at first.
Got myself a proper hiking backpack. An Osprey Exos 58L. Shifting much of the weight to the hips makes a massive difference and my back was very happy!
Absolutely, I didn’t mean to suggest otherwise. :) I’m just giving a bit of context and perspective from someone who has used it for a while.
Static types aside, the file system has a lot of failure cases, which every language is affected by, and Rust makes them very visible. This can indeed feel like a lot, but it’s an intentional feature and makes more sense in larger projects. I guess the feeling may get amplified by the author’s style of long form posts with a lot of details.
Error handling in practice contains a lot of “let the caller deal with it”, using the ? operator to pass errors up the call stack. The more verbose options are for when you need to actually handle it.
I’m of course only one single anecdotal sample, but the release cadence has probably been the least of my problems. My experience is that it’s fine to not update for quite some time. I have a crate with 1.60 (released about one and a half years ago) as MSRV, which means I run unit tests with that version, as well as stable, beta and nightly. The only pressure to upgrade is that some dependencies are starting to move on. Not that the newer compilers reject my code, not even anything deprecated.
Also, small, frequent releases usually takes away a lot of the drama around upgrading, in my experience. Not the opposite. A handful of changes are easier to deal with than a whole boatload. Both for the one releasing and for the users.
Do you want the background to have looped back to the start after one cycle? If so, you probably have to make it repeat N times more than the foreground, and move by a factor of 1/N in comparison to the foreground. Or put another way, have 1/N times the length. That means that after one cycle, the background has moved a distance of 1/N, but also repeated exactly once.
I hope this makes sense…
I liked this talk on the subject: https://www.deconstructconf.com/2019/dan-abramov-the-wet-codebase
It’s a nice explanation of how it’s less about code that looks the same or currently performs the same operations, and more about what it means.
The HTC color system? I have been looking at it and was planning to give it a try after CAM16 support is in. HTC is partially based on CAM16, after all. CAM16 is kind of complicated to get right, so it’s taking a while…
Alright, but nice that it turned out to be what they were looking for 😁
That’s awesome to see! 👀 I actually found one or two of your repositories back when I was looking around at how people were using Palette (to not develop it in too much of a vacuum). I’m happy that you’re finding it useful! Do you remember if there was any specific feature, when picking the crate, that you found particularly nice or helpful?
Also, don’t hesitate to let me know if anything is missing or can be improved for your needs. 🙂 I try to keep the scope somewhat focused, but I’m always open to ideas and feedback.
Reject C, return to assembly. Structured programming is the true oppression our generation never talks about.