(saying something more realistic like “2015” or whatever your inexperience or AI told you to)
User input is probably the big one where this API is gonna get stress-tested…
(saying something more realistic like “2015” or whatever your inexperience or AI told you to)
User input is probably the big one where this API is gonna get stress-tested…
Hmm, I can believe that it was based on java.util.Date
, but I don’t remember that being as unpredictable. I guess, a different API to begin with, would have avoided a lot of problems, though…
I mean, for what it’s worth, I’m a seasoned dev and just did a run where I tried to answer everything as it makes sense to me (which is “throws an error” or “invalid date” for all of them) and I also got a score of 4/28.
…and two of those points were given to me, because the quiz interpreted my answer differently than I meant it.
In other words, this quiz exists to highlight that JavaScript’s Date functions make no sense.
I am not sure, but in Nix I declare the desired state of installed packages and configurations in an obscure language and the package manger takes care of that, right?
The package manager is only one (very important) component of the system that applies your configuration, but otherwise this is a good description, yeah.
Now the module declare reasonable default configurations? Like http server starts on system start and serves on port 80?
Obviously, it depends on each individual module, but so far, I’ve mostly been fine with the defaults. Typically, it doesn’t modify the configuration, unless you explicitly specify a configuration value, therefore using the defaults that the software normally uses.
Now you lost me at the Home-Manger. I can declare stuff in my home folder. OK, so for user-wide configuration? For packages and configuration in the user space? Or what?
It’s for user-wide configuration, so what would generally be stored in dotfiles. For example, you can configure the search engines in Firefox. Or the panel layout in KDE.
Home-Manager can also install packages, which is useful, because it can also be used standalone on other distributions. And in particular, you usually want to declare that a package should be installed and what user configuration it should use, all in one place…
Yeah, it’s easy to underestimate how big of a leap it is from a toy application to real-world usability. Not just in terms of security, but also:
This adds a lot of complexity, so you’ll need to learn additional complexity to be able to deal with it at all:
Learning about all this stuff takes years, especially if no one in your surroundings has much experience with any of it either. Professors don’t have the time to gain or retain this experience, since they already have a different full-time job.
My advice would be to get students to do internships or to take a job as a working student in a company/organization. Sometimes, these can be shitty for the students, but they can often provide significantly more real-world context than college ever could.
It’s a Google Docs link…
KDE Discover and GNOME Software can install from FlatHub (or other Flatpak repos, if you add those).
The last one seems to be mostly like Brainfuck, just with different capitalizations of “moo”: https://esolangs.org/wiki/COW
Yeah, you understood my comment entirely the wrong way around. When I say “dotfiles”, I mean the non-Nix way of managing application configurations. Nix Home-Manager happens to write to these dotfiles, but that means I don’t have to deal with the dotfiles myself.
I feel like setting up a new machine is just the easiest to explain.
Personally, I find dotfiles messy, as you often just want to change one or two settings, but you always carry along the whole file with all kinds of irrelevant other settings. This also makes it impractical to diff two versions of those dotfiles, especially when programs write semi-permanent settings into there.
I guess, your mileage will vary depending on what programs or desktop environment you use.
For example, I love KDE, but they really don’t do a good job keeping the config files clean. Nix Plasma-Manager generally fixes that, and for example allows defining the contents of the panel in a readable form.
Personally, the stepping stone I needed to know about is Nix Home-Manager, which basically allows you to manage your dotfiles independent of the distro. From what I understand, if I do switch to NixOS, I’ll continue using this code with just some minor tweaks.
But yeah, I agree with the verdict in the post. I like it a lot, but I would not have made it past the initial learning curve, if I didn’t happen to be a software engineer. Sysadmins will probably be able to figure out how to put it to use, too. But it’s just not for non-technical Linux users.
It looks like a guitar pick to me. 🙃
On KDE, I’d recommend getting a KWin Script for tiling. Krohnkite is what people use currently.
It’s not as buttery smooth as dedicated tiling window managers and it can be a bit glitchy at times, but it is better than one might expect and significantly easier (and likely less glitchy) than trying to get bspwm to work in Plasma.
Yeah, after writing that comment, I was thinking, if I do promote it, that means there’s a certain expectation that I’ll integrate or implement functionality that others want. At that point, it becomes less of an egoistic thing. And I’ll be doing more communication and whatnot, therefore less programming.
Maybe that’s the puzzle piece that OP is missing? If you don’t promote it, you have practically no extra work compared to developing it under a proprietary license. In fact, it often reduces the workload, if you can just post it publicly without having to secure the repo.
And you don’t incur costs from giving it away either. So, if you make sure to only put in the work that you want to put in in the first place, you have no disadvantage from publishing it with an open-source license.
Incidentally, you can also play !dcss@lemmy.ml to train Vim navigation with HJKL keys.
I mean, DCSS does also have diagonal movement keys, which are most definitely not a thing in real Vim, but uh, you can probably just ignore those. So long as you’re not trying to win the game, anyways…
Many people enjoy programming, you know. I’ve got like ten reasonably-sized projects and I haven’t posted about them anywhere. Because I built them to scratch my own itch, both in terms of functionality I could use and the itch to build something, no matter what it is. I’m not wasting my time, because I’m doing something I enjoy.
Ah, neat. My phone speakers are far too silent, so I’ll have to fiddle with this in the other direction.
It’s the same thing as ternary, just without the ? :
syntax.
Oh yeah, I’m in favor of using type hints. People here are also saying that Pyright is more useful, which I haven’t used yet.
I was involved as the unlucky bastard supposed to sprinkle software engineering on top of a Python project 2+ years ago, and I just remember how much I understood right then and there why Python devs thought static typing was cumbersome. Felt like I had to write Java again, except it also didn’t work half the time.
It’s mainly horrid, because it means you have to code extremely defensively (or I guess, use a different API).
You can’t rely on
new Date("not a date")
aborting execution of your function by throwing an error. Instead, you have to know that it can produce anInvalid Date
object and check for that. Otherwise a randomNaN
shows up during execution, which is gonna be extremely fun to try to find the source of.I understand that it’s implemented like that partially for historical reasons, partially because it’s often better to display “NaN” rather than nothing, but it’s still the sort of behavior that puts me in a cold sweat, because I should be memorizing all kinds of Best Practices™ before trying to code JavaScript.