floating-io

You'd also have to ask when NULL came into common use in C (to which I do not know the answer). AFAIK NULL was not considered to be standard until C89. As far as I'm aware, all C compilers implement it as a #define in a standard header somewhere; it's not actually part of the core language itself.

I wonder who first added that macro? Was it there from the beginning?

Just random thoughts...

I was unclear; I bundle them per-module; each module has an asset route with attached middleware. So for a users module, there will be users/assets or some such route, to which various static-related middleware gets attached.

The link gens inherently accept relative paths (foo) and output relative links with appropriate adjustments (foo.png?v=abcdef), though they can generate fully-qualified links if circumstances warrant (eg I often have a global shared css file for theming, though that's all I can think of offhand other than "/" for back-home links). The module can then be mounted under /bar/blort, or wherever else, and the links remain relative to wherever they are mounted.

On occasion I do hardcode links for whatever reason; my rule of thumb is relative links for same level or deeper, or root-anchored if you're referencing a global resource outside the current path, but there aren't many of those in my apps. A rare exception might be something like an icon library, but I tend toward font-based icons.

To put the rule more succinctly, I never use "../foo". Going up and then over in the hierarchy strikes me as a recipe for bugs, but that's just instinct.

I also never use fully-qualified (including hostname) urls to reference my own assets. That's just madness, though I vaguely recall that WordPress loves to do crap like that; there's a reason I don't use it anymore. :)

So the main difference if I understood your link correctly, would be that I would have maybe one or two items in /static/assets by root-anchored urls, and the rest accessed as /path/to/module/assets/whatever (edit: or just assets/whatever from within the module).

Because I'm doing this in go, the module's assets live where the code does and gets embedded in a reasonably standard way. I actually tend to use git commit as my cache buster to avoid having to hash the content, but full hashing can be done as well very easily just by changing the generator functions.

I can then just import the module into an app and call its associated Route() function to register everything, and it just works. Admittedly it's very rare that I reuse modules between apps, but it's easily possible.

For background to my thought process, I originally started using the link gen paradigm long ago to make it easy to switch CDN's on and off or move between them, back before whole-site proxying was considered best-practice. The rest is just a desire for modularity/encapsulation of code. I like to be able to find stuff without having to spelunk, and keeping assets together with code in the source tree helps. :)

I tend to keep statics consolidated and slap middleware on those routes to handle expiration headers and whatnot. Versioning is handled where links are generated; an href="{{ linkfor(asset) }}" style resulting in generated urls complete with content hash tacked on. I almost never construct asset links without some form of link generator function because said functions give me a centralized place to handle things just like this.

(edit: I should clarify that I'm mostly working in Go these days, and all my assets are embedded in the binary as part of compilation. That does make some of this much easier to deal with. Javascript-style build mechanisms tend far too much toward "complex" for my tastes.)

Random developer here: in my code, yes they are common. I tend to write modules so that I can route to them from wherever, reuse them, and move them around as I please. Relative links help greatly with such things.

Besides that, they are a very basic part of the spec, and I consider anything that breaks them to be truly fundamentally broken.

I had to read that title several times to make sure that it wasn't the alcohol causing it to register as "Slime Mold."

Why someone would want to simulate a slime mold is something I don't understand, but more power to ya. =)

"Professional" is doing what they're paying you for, end of story.

Most employers have less than zero interest in paying coders to document in my experience. If they want documentation to exist, they hire a technical writer.

Sadly, I've never met an employed tech writer (and no, journalists don't count).

A business should know approximately when it will run out of money. Ethically, they should have warned their customers that their financial situation was poor and thus they might close.

They should have done that months ago... Maybe they would have been acquired without all the drama...

The catch is that even in-person interviews are no panacea. I agree that it's worth the time to filter -- I wasn't really responding to that bit -- but from what I've seen, you have to be a very good interviewer not to get a bad hire every so often.

I often wonder how many hiring managers are actually good interviewers, in-person or not, but I digress...

Seeing the truly bad hires dragged along to the detriment of the rest of the team is a sore spot for me, though. It happens way too often in my experience.

The counter argument is that firing too slowly can be a serious drag on morale. Leaving your team to carry dead weight can really suck for the team.

Ask me how I know... :)

"Vendor problems" is a red herring, IMO; you can have those in the cloud, too.

It's been my experience that those who can build good, reliable, high-quality systems, can do so either in the cloud or on-prem, generally with equal ability. It's just another platform to such people, and they will use it appropriately and as needed.

Those who can only make it work in the cloud are either building very simple systems (which is one place where the cloud can be appropriate), or are building a house of cards that will eventually collapse (or just cost them obscene amounts of money to keep on life support).

Engineering is engineering. Not everyone in the business does it, unfortunately.

Like everything, the cloud has its place -- but don't underestimate the number of decisions that get taken out of the hands of technical people by the business people who went golfing with their buddy yesterday. He just switched to Azure, and it made his accountants really happy!

The whole CapEx vs. OpEx issue drives me batty; it's the number one cause of cloud migrations in my career. For someone who feels like spent money should count as spent money regardless of the bucket it comes out of, this twists my brain in knots.

I'm clearly not a finance guy...

ESP32 is generally not a good choice for infrequently-charged battery powered devices IMO, unless they have massive batteries. Power consumption always goes up with the sophistication of the communication stack, both hardware and software, and the ESP is toward the upper end of that spectrum (unlike, say, something based on 802.15.4).

That said, were you using TLS? I'd be curious to know how that impacts power consumption during HTTP calls.

Right about the time that magic 8-balls are touted as being able to reliably provide us with every solution we need...

Not just an issue for documentation, but also for marketing materials. I can't count the number of times I've looked into some app that was referenced vaguely in a comment somewhere, only to have to dig for half an hour on that thing's web site just to figure out what the thing is supposed to even do in the first place...

Why would they do it during the off state? If they know the voltage and can measure the current that they're driving it with -- or vice versa -- they can use Ohm's law to calculate the resistance.

They'd probably have to do that anyway.

It's too late for this former user of Apple's productivity software. Killing Aperture and nerfing the iWork suite destroyed any willingness I could have ever had to go back.

I like their OS, but it would be a hard sell for me to ever choose to migrate to their productivity software again.

Or just ask Costco to slap a "Contains Milk" sticker on it?

The question I keep asking is: why? They give these patents to random people, and 5 or 10% of the proceeds if they win the suits. What do they get out of it?

If they were legit, then I don't see the need to assign the patents they own to someone else before litigating. Unless there's a gotcha, and it's a scam somehow.

Very strange, and just another reason why patents should probably be non-transferrable and "use it or lose it".

You're ignoring that this is a fixed-price contract. It will never be over-budget from NASA's perspective.

Also, for a project like HLS, you don't fail until you stop trying (or get someone killed, but SpaceX has been pretty good at not killing astronauts).

Planes are expensive due to the difficulty of certifying them and maintaining the right to sell them under various regulations, not because they're using physical switches.

It's not actually about how the ballot is interpreted by downstream hardware and software. That's a different issue.

It's about the ability for the voter to determine that their own part of the process -- the recording of their own vote -- is done correctly in every respect.

Each step of the system has to be verifiable as correct for the system to be trustworthy. As it stands right now, I cannot visually verify that my own vote produced a correct printed ballot. I have no way of doing that.

This removes one of the most critical safeguards. If something in the software (malicious or otherwise) records an incorrect barcode, I have absolutely no way of knowing.

That's a problem.

Garbage in, garbage out.

It starts with being able to tell that the information was encoded correctly when I submitted it.

Tell me this: what is the advantage of a barcode, over a scantron-esque system where I can see which item I chose because a dot is filled in?

The scantron-esque system is still efficiently machine readable; we've had scantron since I was a kid. The difference is, I can verify with my own two eyes that the information is encoded correctly on the ballot I submitted if it's done scantron-style.

I cannot do that with barcodes.

It adds another layer of safety. Do we still have to be able to trust the rest of the system? Yup. But I cannot trust anything at all if I cannot even verify that my vote was submitted correctly in the first place.

JMHO.

In my locale there is a header on the physical ballot that contains a bunch of barcodes, presumably to make your votes machine readable. It then prints the votes in text below.

I absolutely hate that fact. I am a human, I cannot read barcodes without a computer. Therefore, I cannot tell if the important part of what was recorded is correct.

Not sure if Colorado's are the same...

I love my InstantPot, but never use it for rice. The few times I've tried, I haven't liked the results. Boiled/steamed on the stove ftw. :)

Now soups, veggies, artichokes, enchiladas, ... For those things, the instant pot is awesome. =)

I learned how to cook rice properly from my Mom. Pot, 2x water, boil then turn to low, add rice, 18 minutes, done. My only gripe is that I'm still trying to find a good rice pot with the little steam vent in the lid.

The rice cookers I've seen take twice as long to make rice that is by no means twice as good.

To each, their own. My Mom loves the rice cooker I gave back to her because it took too long to cook rice. =)

Whatever works and you can find enough developers for.

The language (or the rest of the stack even) is rarely a barrier to success. What matters are a good idea, good motivation, and decent availability of competence.

JMHO.

They might be an outlier in terms of current profit metrics, but they are still the market leader in the CPU space, and not by a small margin.

I would consider it foolish to disregard the metrics of a company that holds in the neighborhood of 75% of market share in a critical tech market.

Comparing Nvidia to Intel is more difficult because Intel is comparatively a bit player in the GPU market. Adding NVDA is not the issue; it's an important market segment, and they're the leader. Deleting Intel is an issue. CPUs are and will remain a vital component of the tech market, and thus, so will Intel for the foreseeable future.

So long story short, this makes the Dow start looking like a better indicator of hype than overall market health IMHO. I don't want my market index to cherry-pick only the ones that are rising.

You are certainly free to disagree ;) Again, I'm hardly an expert investor.

Doing poorly does not make them a bad indicator of overall industry health.

And they've had bad stretches before. I myself am wondering, but I wouldn't count them out just yet.

More like a knee jerk reaction IMO. Intel is having a bad time, but they're not dead yet, and may well be a better, more reliable long term market indicator.

All this means is that the Dow is currently chasing hype.

JMHO (not an expert investor, this is not advice, ...)

That doesn't account for OpEx, though, such as power...

That is the perfect high-level overview of my previous job.

I'm semi-retired now...

(edit: I forgot to note that the "let's not" part was always overridden by "You're wrong, this will fix it. Do it!" by management. Then we would eventually find and fix the actual problem (because it didn't go away), but the cluster size -- and the cost -- would remain because "No, it was too slow with so few replicas".)