I actually worked on an App for a company that made home appliances. Originally they made everything local, so direct App to Washing machine communication. They had a really hard time with that approach for a number of reasons.
The first, and most obvious, reason is that getting your phone and (all) your appliances on the same network is non-trivial. Especially for a novice user. Sometimes the washing machine is in the basement and can't connect to your WiFi. Or maybe you're simply outside your house in your car and can't connect to your local network. The cloud approach solves this.
The other, not so obvious reason, is that the manufacturer made a ton of devices. Some of them a decade old, with very rudimentary interfaces. Originally the App had to handle special cases and workarounds for dozens of devices. This became a problem once they tried to port it to multiple platforms. For Android and iPhone they started with a shared C++ library. But that quickly became a problem, once they wanted to interface with popular home network and automation solutions.
To solve all this they decided to build a cloud API that would resolve all these problems in one go. A single, unified API with a modern HTTP interface and available via the internet. That solves the workaround and compatability issues by having a single abstraction layer (instead of one per app). It solves the "on the go" problem when you're not in you local wifi. It enables you to control devices outside your home network in a true IoT sense.
I totally agree with you that, if you're not in an urban environment with good internet and cell coverage, the advantages dwindle away. Also, of course, there is the privacy concern that is very real. At the end of the day the cloud solution is selected for the same reason companies select Electron. It saves development time and is very easy for the average end user to use. At the expense of performance and privacy.
Not judging, but you represent such a small fraction of the market that companies simply don’t deem it worth it when looking at the cost of supporting LAN-only. Just imagine the support tickets they’ll get.
Oh yeah, I'm fully aware of that. Somewhat ironically, the one device (garage door opener) that I did allow to do its cloud thing works so poorly that I gave up on trying to make it work and turned off the WiFi. The remote open never worked, the "notify me when the door is open after 9pm" alerts would arrive days later, etc. And, of course, the user interface looked and felt like one developed by an industry where the existing UX was a single button.
> The first, and most obvious, reason is that getting your phone and (all) your appliances on the same network is non-trivial.
What other networks do homes have? Every WiFi ISP router I have used provides a single network and DHCP server. Perhaps some routers provide both a public and private WiFi and the consumer doesn't understand which one they should pick but that is the fault of the ISP.
> Sometimes the washing machine is in the basement and can't connect to your WiFi. Or maybe you're simply outside your house in your car and can't connect to your local network. The cloud approach solves this.
How does the cloud fix poor/no WiFi signals? This is pure ignorance. Perhaps you are confusing cloud with "stick a SIM in everything" 5g marketing which isn't really a thing yet. I stopped reading the rest of your post at that point.
Many cases I knew, people would have several repeaters and extra routers to extend coverage in big houses, and not set it up correctly in PA/Bridge mode, so peripheral network devices would be locked behind in a separate NAT’ed subnet.
I've dealt with this a ton trying to help troubleshoot people's home network problems during the early days of COVID WFH. [1] Some of the absolute messes I'd see were astounding, and they thought everything worked fine because all their phones and Apple TVs and kids PCs running Steam could all get to their cloud stuff fine, so why couldn't their company laptop talk to the printer they brought home and plugged into the "router" in the basement?
[1] Not something we'd /normally/ do, but when that was going on... You just had to get people working.
We can consider it, but Miele won’t. Their problem is connecting your washer to your phone and going through the cloud has other side benefits for them as well, such as telemetry, so here we are and will be.
> Every WiFi ISP router I have used provides a single network
Actually, many provide multiple SSIDs (5GHz and 2.4GHz). While you’d think these would be interoperable, it’s a massive pain in the ass. IoT devices only have the 2.4GHz antenna. And you want your main devices on 5GHz for speed. If you combine the 2.4 and 5 networks into a single said and let band steering work, IoT devices often don’t place nicely. If they’re separate, then you have to rely on the custom local app to see a server running on the other ssid. Another issue on top of that is apps on iOS will be required to use SSL for HTTP connections, and making sure your washing machine has always up-to-date certificates is also not simple.
> What other networks do homes have? Every WiFi ISP router I have used provides a single network and DHCP server. Perhaps some routers provide both a public and private WiFi and the consumer doesn't understand which one they should pick but that is the fault of the ISP.
Think of times when your phone might not have connected to WiFi because you just got home, or are in some random dead spot. Or it just... isn't for a moment.
From the perspective of many consumers, without that always-available-via-cloud central point, it's then "broken".
Put it all in the cloud and so long as the phone and the device can get to "the internet" it'll be working.
What if the person has two networks at home? Or ends up on the neighbor's that they sometime use? Or their saved guest network? The user could well think "I am..." whether they are or aren't.
How would the phone know the /right/ network? All it can really know is it can't find the appliance.
They clearly stated that getting devices on the same network is non-trivial. Obviously, at a place where no network access exists anyways, neither local nor cloud solutions will work.
If somebody required WiFi in an area of the home where it wasn't already, why not just use a repeater/mesh node? If someone wants their smart appliance online, a few extra dollars on top of a likely three-to-four digit purchase appliance is nothing.
Many things in this article, especially about the problems with the Data Science role, resonate with me (low value work with low expectations for quality). Funny thing is I have never worked in Data Science. Rather I've worked in Software Development. The summary at the bottom about Data engineering seems like the dream job to me. But I don't think it's because I'm interested in doing Data engineering specifically. I think it's because doing things that actually have an impact day to day is fullfilling. The last job I had totally lost me after ignoring security problems in favor of surface level things like updating CTA labels or similar. Have other Software Devs had this experience?
Sadly there are a number of functions in the PHP standard library that literally never can return true. Often they return a resource or false, for example. In those cases the `false` type is more accurate than boolean. That's the reason for the distinction.
I don't think the argument is against unit types. I think the argument is against calling one "false", and I agree. If you're going to have a reserved keyword "false", have "true" and "false" as Boolean. If you want a unit type to mean "failed", "failure", "incomplete", or something, use one of those words.
It actually makes a bit of sense if you think of Bool as a class instead of a primitive type, and True and False as subclasses of Bool. So a function can either declare its return type as "bool", or as the more specific "false". True is simply not implemented.
PHP isn't exacly an "everything is an object" language, but it's been slowly moving in that direction for years, replacing most callables, resources, etc. with corresponding objects. I wouldn't be surprised if the designers are approaching this issue with an object-oriented mindset, though it still feels wrong to make an exception for only one half of a boolean pair.
This works fine in TypeScript. You can specify a type as boolean, true, or false, and it works exactly as you’d expect. I don’t see an issue with doing the same in PHP
Introducing `false` as a standalone type but not `true` is what makes this weird. Generic, literal returns are fine. Python is another language that has it [1].
The introduction of the RFC [2] also still mentions `false` is of type bool:
> null corresponds to PHP's unit type, i.e. the type which holds a single value. false is a literal type of type bool.
But why call it bool if `true` is not a standalone type too?
It would not surprise me any to have a Boolean type and have both true and false as restricted subtypes of that. However, in this case of it being used primarily as a return type for failure in a function call, I think they're conflating the tradition from C-style languages of returning a false-ish value in-bound rather than creating a type specific to the error condition.
> I think they're conflating the tradition from C-style languages of returning a false-ish value in-bound
It’s not really conflation when php has been doing that since forever as it originally was little more than a thin shim over C (you can see that in lots of older APIs e.g. the mysql_ stuff is straight transcribed from the C library).
Oh, it makes sense. It would just make more sense to me if the unit type for an error or failure was called "error" or "failure". They're sort of overloading the idea of true/false here with the historical baggage of returning a value that evaluates to false-ish for failure, then codifying that in a new type rather than taking the chance to make the new type a clean break from that in-band concept.
What else do you expect, PHP has its roots in a bunch of wrappers around C functions with in-band error signaling. Those functions are like grandpa's old watch that you just can't bring yourself to throw away even though it doesn't match any of your new outfits. Mama WordPress would be mad. :)
On a little more serious note, Perl is an earlier language and even more closely tied to C tradition. Many (but not all) of its built-ins and library functions and methods return undef rather than 0 for failure.
PHP functions don't return 0, either. They return `false` which is easy to distinguish from other false-ish values using the `===` operator. They're still overloading `false` with failure, of course, but it would be unfair to say that PHP conflates all the false-ish values.
It’s really an announcement about the formalisation of existing API patterns: returning FALSE on failure (regardless of the “success” type) is part of many old php apis, this change allows properly typing those.
I tell my clients all the time why I can't just make a "quick change" and I have to manually review the data sometimes and go through a ton of code review. I tell them...
> As a human I can only mess up one or two orders a minute. Computers are uniquely qualified to mess up thousands of orders in seconds.
I've thought for a while that this kind of change for the sake of change is fuelled by the number of employees in the companies involved. The ratio of developers you need to build an application vs maintaining one is huge. That creates an incentive for companies to keep building.
Out of the perspective of Agencies (Outsourcing) each working developers generates revenue. Product companies can choose to either keep their employees and keep building, or simply let a huge chunk of them go. Letting a huge number of people go (mass layoffs) is generally seen as a bad thing. So they go the other route. Keep the employees around and have them working - building new stuff.
In general estimates are risk assessments. With that in mind, I think the way to go about estimates depends on the experience level of the indivual or team. The best estimates are not only a number (or a t-shirt size), they also include a list of possible things that can go wrong (either as an internal dialog or, in the best case, written down as part of the estimation).
There are many methods to get this assessment. These are the ones I have used:
* Basic level: Write down everything that needs to be done and assign a time estimate (in hours, otherwise break down further)
* Intermediate level: Write down everything that needs to be done and assign a range of time in days (from best to worst case scenario)
* Expert level: Use an abstract scale (like the fibonacci sequence, T-shirt sizes, etc)
* "We've been doing this together for 20 years" level: Can it be done in XY time? Yes or No answers only.
In each of these levels the specific time it will take to complete the task becomes less and less specific. The reasons to keep it specific, are a) to learn how to estimate well and b) to keep people accountable. Reasons to keep it unspecific are that a) it's impossible to get a correct number for a task you've never done before, thus b) it's a waste of time to try and make an estimate accurate.
The value of all these estimation techniques is to find out where the most risk lies (usually there where the most unknowns / complexity lies). If you then don't follow up on those risks by checking in with the team, the estimation becomes useless. If you manage these risks well, you should at the very least have consistent estimates. Even if their real-time equivilant is off, it should be off by a consistent amount.
Most important of all though: Estimatation is a learned skill and not inherent to anybody (developers or managers). It takes time and practice to get going accurately.
From my experience as participant in these kind of systems, this is what I think:
These systems have the goal to create buy-in from the employee to perform at a certain level. Since you create these goals yourself there are little excuses why you can't reach them. It creates an incentive for the employee to work hard all year long and lessens the burden on the company to continuously check if you're being productive.
I guess another way of saying it is: You define what you're getting paid for year over year. What value you're providing for the company.
Think of it this way: It's a social contract between the company and the employee that you will spend your time on something valuable to both the company and you. In larger organisations it can also help to answer the question "What is your team working on?".
I have in fact experienced employees (peers) that will simply slack off and say they "weren't told what to do" when asked. It's infuriating to work with those kind of people. Those have been exceptions though.
I might argue then that your company does a bad job at hiring :) Also, do you also ask yourself: what is my manager doing? I do and in good, healthy companies I can see that.
> It's been proven that employees don't normally do that?
I have no idea, but I think the psych literature (and common experience) does show that people will take stronger ownership of stuff they defined themselves in the first place (well, duh). If HR think they can get more buy-in for free then why would they not go for it.
SEEKING WORK | Switzerland | Remote
Technical Project Manager
Seeking part-time or contract work as project manager, project consultant or agile coach.
I am a technical project manager with 15+ years experience of building applications. During that time I was a pm, as well as a developer. That lets me unterstand and communicate where other managers might fall short.
My experience covers Agile Projects (not only scrum), classic waterfall projects and maintenance of existing applications.
I am looking to support projects as a facilitator, consultant or traditional project manager.
An extra fascination of mine is personal time management and efficiency. If you're interested in that kind if thing, feel free to contact me. Even if it doesn't directly have anything to do with a job :-)
The first, and most obvious, reason is that getting your phone and (all) your appliances on the same network is non-trivial. Especially for a novice user. Sometimes the washing machine is in the basement and can't connect to your WiFi. Or maybe you're simply outside your house in your car and can't connect to your local network. The cloud approach solves this.
The other, not so obvious reason, is that the manufacturer made a ton of devices. Some of them a decade old, with very rudimentary interfaces. Originally the App had to handle special cases and workarounds for dozens of devices. This became a problem once they tried to port it to multiple platforms. For Android and iPhone they started with a shared C++ library. But that quickly became a problem, once they wanted to interface with popular home network and automation solutions.
To solve all this they decided to build a cloud API that would resolve all these problems in one go. A single, unified API with a modern HTTP interface and available via the internet. That solves the workaround and compatability issues by having a single abstraction layer (instead of one per app). It solves the "on the go" problem when you're not in you local wifi. It enables you to control devices outside your home network in a true IoT sense.
I totally agree with you that, if you're not in an urban environment with good internet and cell coverage, the advantages dwindle away. Also, of course, there is the privacy concern that is very real. At the end of the day the cloud solution is selected for the same reason companies select Electron. It saves development time and is very easy for the average end user to use. At the expense of performance and privacy.