Xavdidtheshadow

I actually wrote about this exact thing: https://xavd.id/blog/post/my-perfect-task-app/#dependent-tas...

My hope for the perfect task tracker springs eternal.

So to that end, I'd probably start with a project-oriented book, or give them tasks that require programming to solve (e.g. tell me the distribution of words in this Shakespeare play. What are the most common ones?).

Editor wise, VSCode is great, but may be too many bells and whistles. Sublime Text may be a better place to start, since it'll do highlighting, formatting, etc without being overwhelming.

Language wise, Python, JS, and Ruby all have ample beginner resources. Depending on what else they're into, JS is probably the most widely useful (since it's on most web pages and the sandbox is built right into the browser).

Good luck! Let us know how it goes!

That's so interesting- I think I have the opposite response. I figure unless I'm doing a very specific case that doesn't fit well with the stdlib sort (for some specific reason), It's probably good enough. Those language folks usually know their stuff, who am I to try something else?

1. They supported 3rd party watch faces based on a file. There was a great little site that let you use a visual UI to build the file and, if done from your phone, upload it right to the watch. Once, when out at midnight beer launch, I made a custom face for the beer and won a little keychain from the brewery. My apple watch is nowhere near this functionality.

2. Once time in 2014, I ran into some Pebble engineers at an ice cream shop in Palo Alto, they spotted my watch, they bought my scoop! Fun, weird little Silicon Valley moment.

It's basically just text and images, but I'm proud that I did the whole thing (content, design, implementation) and the overall attention to small details.

Also, I love the domain. @xavdid is my username on basically everything that isn't an account I've had for a very long time (eg this one).

I mean, I think there's something to that. Bash has a lot of arcane rules; I personally never write an `if` statement right, what with the `[[` vs `[` and having to surround the condition with whitespace. I find that bash scripts carry a million little gotchas that will cause variables to not evaluate/expand the way you'd expect.

Say what you will about Python, but it's much easier to reason about what a script will do as compared to bash (unless the bash is _extremely_ simplistic).

If you only watch one clip, check out this segment from the training montage: https://www.youtube.com/watch?v=yCk9VAxEpD0&t=156s

Their use of visual boundaries and transitions is just so superb.

It's all about adding layers of prevention that each drop your chances of catching it (and its potential severity) by N% each. Get enough of those, and your chances start to look pretty good.

For a lot of the 20th century, _most_ people could buy a house regardless of their chosen occupation ("most" is doing a lot of work here- there's a long history of racism tied into housing acquisition, but my basic point is the same). You could be a blue collar tradesman and buy a house for your family of 4. So yes, I think that's definitely a (theoretical) possibility.

It's not outlandish either. We already have a much healthier model to copy: cars. There's no one buying up _all_ the cars and then leasing them to you at artificially high prices. There's (normally, chip shortages notwithstanding) plenty of cars and you can pick what best suits you- new / old / cheap / expensive / fancy / plain / etc. Housing could be the same way if the goal wasn't to extract profit out of those who can't afford to buy (or weren't born 60 years ago).

I think the value here _really_ depends on your usage patterns. For you, it sounds like individual discs make a ton of sense. But, many people watch more movies than that (during the height of lockdown, we were watching 1-2 movies _daily_), so streaming services made the most sense. Sure, it's annoying that movies come and go, but the price is certainly right.

Once size won't fit all here, so it's definitely great that discs are still an option. I'm glad it works for you!

I think with most things, the answer here was to have a mix of keys and buttons. With 100% TB, it's slow to change volume/brightness. With 100% keys, I've got all these extra keys I can't use (you can re-bind them with 3rd party software, but it's fairly static).

I'd personally pull like, F3-F9 in favor of a touch bar, and then be able to configure the remaining buttons. I'm a little sad reaction was so strongly against the idea on the whole, it definitely had potential.

FaceID is better for:

  * in-app auth- when an app (e.g. a financial one) has a secondary auth check, FaceID passes without extra effort- it's very slick. For TouchID, I usually had to move my phone to the button (because it wasn't already there)
  * using unmasked- It's fast enough that under normal (unmasked) circumstances, it works great
  * dirty/wet hands - especially since the phones are waterproof, it was always annoying to have to do my passcode if my hands weren't totally dry. I didn't think it would come up a lot, but it did

  * Pandemics. The Apple watch unlock works 70% of the time, but that's not 100 _and_ you have to own a separate, expensive piece of hardware. They're fixing this in the latest iOS beta (FaceID can learn your face w/ a mask on by checking details around the eyes).
  * Bed- my face is usually squished on a pillow and the phone is close to my face; it can basically never be read

So, it seems like there's no silver bullet. Both would be great, but I think I understand why they made the tradeoffs they did.

You may find the Zapier's developer platform useful. Instead of using pre-built integrations, you can develop and ship your own Node.js packages for private use. I've got a fleet of them that can do basically anything, but also play nice with the rest of the platform.

I'm not sure exactly what your pain points are here, but there's definitely an "escape hatch" for power users!

frog: https://cdn.zappy.app/f97505ba92625a0e949aebcfa4220852.png

wikipedia: https://cdn.zappy.app/3b7d5cf750066633e40aeddda926f95f.png

It's not really targeted at the HN crowd (requires an account, etc), but the app is "Zappy" if folks are interested.

- https://zapier.com/zappy

https://xavd.id/blog

I write about all sorts of things, some of which are technical. Here's a favorite Python article: https://xavd.id/blog/post/python-dataclasses-from-scratch/

> Sure, Breath of the Wild is fun; but how does it taste?

We do the same thing and have the exact same experience, unfortunately. Software is a messy business and it's hard to apply strict rules to human process.

I think ultimately SemVer can be used to to accurately communicate if you, a user, are safe to upgrade between versions if applied strictly. Whether or not your users will (or be happy about it) is another ballgame.

That strikes me as exactly the sort of guarantee that's _not_ made by semver. You can rely on that behavior, but then you have to check against every patch version, because that's exactly the sort of thing that could change out from under you. Maintainers shouldn't worry about breaking this case- they never promised to support it in the first place.

I think a lot of those cases should be a major version change, and that's totally fine. We _should_ minimize the number of breaking changes to code people depend on, but sometimes the best fix to the (totally reasonable) situations you outlined above is to make a new major version. Users will have to make changes to upgrade (instead of just bumping the versions), but it won't change out from under them. Some docs about what's changing, why, and how to migrate your code go a long way here.

I don't think that's true. I've always thought a breaking change is defined in broad terms as "the public API surface, runtime, and output". Given that, each of these would be a SemVer major:

* remove a publicly-exported function * public function changes order of arguments * drop support for an old version of the language * a function changes behavior significantly (the issue the OP wrote about)

Relying on a specific major version, you should be able to assume none of the above will happen. The following would _not_ be a major version:

* renamed/removed private versions * add extra, optional arguments to public function * add support for new version of language * the xkcd example about CPU usage

In each of these cases, if you rely on non-guaranteed behavior, you should check every version upgrade closely- package maintainers don't make any assurances about those.

I'm not sure how mongoid is developed, but this smells like a bug to me. The `or` behavior started considering a thing it didn't used to, possibly unintentionally. Unfortunately, released mistakes are the one thing SemVer doesn't cover. Testing sufficiently about your own assumptions (in this case, that the user upgraded matches the one found in the query) is the best way to CYA.

I've been kicking around an idea of selling a bushel of NFT's and then later changing all the images to the text "I spent money on a monkey but all I got was this stupid text" and then abandoning the project.