steamer25

They didn't really do a very good job of selecting marketing examples. The only good one, that shows off creative possibilities, is the knit elephant. Everything else looks like the results of a (granted fairly advanced) search through a catalog of stock footage.

Even search, in and of itself, is incredibly amazing but fairly commoditized at this point. They should've highlighted more unique footage.

An interesting problem for those who're good at e.g., geometric packing problems and space-filling curves.

I wonder about having an optional fill mode with more of a sphere-packing approach. I.e., instead of layering long threads of filament, what if you put down a bunch of dollop-drops in a checkerboard pattern and then staggered successive layers of dollops to fill the gaps?

Not noodles vs. gourds but two different gourds:

* spaghetti squash (named for the long fibers in it's flesh)

* butternut squash

...should probably be written with some hyphens: "Spaghetti- or butternut- squash"

...or with some parens: "Squash (spaghetti or butternut)"

Rust allows for higher stakes in terms of risk/reward while guaranteeing many aspects of safety. I'm not sure for this case if the scheduler would benefit from more complex/risky structures but if it did, that'd be a valid example of Rust making things "easier".

Rust definitely makes some easy things more difficult but on the flip side it arguably makes very difficult things easier (to get right with fewer guinea pigs).

When I use the word 'Simple' in e.g., a class name, I usually mean: ~"This is meant to cover the 80% of common cases--I haven't done extensive testing or development on it. If you need to cover something in the remaining 20% of edge and corner cases, you're going to need to write your own more complex code to handle those."

I.e., my code is simple--and that might make your usage complex.

Of course, things can evolve from the original implementation--especially if the code is maintained by a team. What was once 'simple' (from any perspective) can become terribly appendaged yet never renamed.

I think one part of the trick is that you find high-functioning people but in less-overlapping domains.

In one of the more successful teams I was on back in the day, I was a JavaScript developer and was paired with some Flash developers on a project where we had a lot of back and forth calls crossing the boundary. I'd ask them to implement a way for me to call their logic and then they'd ask me for a way to call my logic. We were both super-responsive to the other because neither side had much interest in imposing our preferences in the other's very distinct domain.

On the flip side, we were both quite capable in our own right and thus able to agree on the overall architecture pretty quickly. With some people, you'd probe, "it seems like you should have a way to do X, right?" and they'd respond immediately, "that's definitely not possible, you'll have to work around that". So you'd push, "do you want to check?" but they'd decline so you'd take it upon yourself to dig in and point them to relevant documentation. With these guys, their response to the first question was, "Of course we can do that and you can do Y for us, right?".

It's not really $ > person.

It's group of people A, who are conducting a [series of] transaction(s) with group of people B. It so happens that the wares being exchanged are currency vs. software but that's really besides the point.

Group of people A ≹ Group of people B

Yep. The primary fault lies with the too-many people who abused the non-hostile system. "This is why we can't have nice things"--because trust is too costly in the societies where hostile architecture is prevalent.

It happens all the time, no tech required, any time someone is foreclosed on.

I agree it's wiser to avoid such situations but a lot of people end up delegating this kind of responsibility. If enough of them end up burning their own fingers, that could go badly for a provider. Even if frivolous lawsuits weren't a thing, a spate of ignorant but angry social media posts could be very damaging.

Again, I'm not saying I necessarily have a solution or that hardware owners should have hurdles placed in their way. I'm just pointing out that in some ways the provider may be damned in one way if they do and damned in another way if they don't.

I suppose the IoT sub-sector will end up in similar proportions to other, older tech: Some vendors, analogous to e.g., Red Hat or Linode, will specialize in catering to enthusiasts / power-users and have fairly noncommittal / at-your-own-risk / no-warranty license agreements. However, if the past is any indication, most people will end up doing a lot of business in walled-garden analogs of Apple or Facebook.

My favorite is being asked to estimate a bug fix before I've had any chance to analyze the issue.

It's like calling a mechanic over the phone and asking how much it will take to fix your car. The mechanic doesn't know if the engine just fell out of your Model T or if you're just trying to put the key in backwards. How about you bring it in first, then we'll look it over and go from there?

Sometimes you can ask some questions and get to, "Well it's probably X which would take Y but we'll need to see". Then they get Y stuck in their head and it turns out to be the one time out of twenty when the cause isn't actually X but something much more involved.

That makes sense to me but I'm not sure your average judge/juror would see it so simply--especially given that in most cases it'd be a lot easier to tell if/when a deadbolt has been modified.

I'm not saying owners should be completely barred from modifying their systems but there are security implications to bypassing their centralized / cloud-based authentication.

It'd be possible for a knows-enough-to-be-dangerous customer to modify their system in such a way that they unwittingly allow unauthenticated local access. From my point of view, Chamberlain/MyQ should be totally indemnified in such scenarios but I'm not sure how murky the legalities would be in terms of getting judges/juries to accept "caveat emptor".

EDIT: Maybe there's a way to ensure customers have signed an indemnification agreement before unlocking local API access? I guess there'd also need to be a way to ensure/promote a factory reset if/when ownership/rentalship changes.

That dovetails nicely with: “It is difficult to get a man to understand something, when his salary depends on his not understanding it.” --Upton Sinclair