|
One of the better rants I've come across.
I think in general you are ranting about :
Design Versus Defaults!
In other words, why do people supposedly design devices that are not actually designed at all but are just knee-jerk reactions to a problem.
Someone recently told me they he "Finally got my garage door set up on wifi. It took me a long time though.".
I shivered a bit as I imagined his garage door being opened by random hackers on the Internet.
It makes no sense to create a garage door opener that uses wifi and connects to the Internet.
He also mentioned that it takes a bit for his phone to connect to his wifi anyways so it takes a while to use it each time.
But many manufacturers just default to wifi when they should just use local wireless like bluetooth.
I created such a device and it was really quite easy and very inexpensive (Never Buy A Garage Door Remote Again: Open Your Door With Your Android Phone (via Bluetooth)[^]).
Also, even if you want to know if your garage door is up or down from a remote location that is still possible without forcing the user to connect his garage door to the Internet.
Well, that is design by default instead of design through thinking and choosing the proper devices and services.
|
|
|
|
|
Oh, the whole home automation thing, as it has become in recent years, is just a security nightmare, no doubt. All these small doo-dads from China that people just plop inside their local network and they are connecting to who knows what, or being infected and used in massive DOS attacks and such.
The thing is, a lot of these newbies will shat on serial connections as old fashioned, but they are inherently safe, point to point connections between the automation system and the device. As long as the bandwidth is sufficient and the devices relatively close (and often they are) then it's an excellent connection type to use (and very cheap for the manufacturer.)
But of course most of these newer companies are not interested in that, they are interested in tying customers to their cloud-based services so that they can collect data and monthly fees. And many of them don't look beyond their own phone based app control interfaces, so we end up going back to the start except that now there are a bunch of virtual remote controls on a phone instead of a bunch of real remote controls on a coffee table.
Explorans limites defectum
|
|
|
|
|
raddevus wrote: One of the better rants I've come across.
PFFFFT!!! He ain't serious unless he's said "f*ck" at least once.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Gosh darn the blankety heck.
Explorans limites defectum
|
|
|
|
|
|
|
We go through that sort of thing occasionally, as we build commercial ink-jet printing systems. I can't imagine anyone using some godforsaken web protocol for command/status in any kind of process control environment. All of our peripheral systems use TCP/IP socket communications, usually over a gigabit private Ethernet.
Given that we're running paper at up to 17 feet per second, half-second latency turns into a lot of paper.
Software Zen: delete this;
|
|
|
|
|
In the so-called 'internet of things' world, which is basically what has become of automation in the popular press and hence in the great unwashed masses for the most part, it's way too common. And of course it's even worse in that half the time it's a cloud based API, so not only REST but you have to talk to a server half-way around the world to talk to a device 20 feet from the computer.
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: you have to talk to a server half-way around the world to talk to a device 20 feet from the computer
Same deal where I work. They removed (or refused to replace) all of our attached desktop printers. We now have department printers, all managed from the home office. When I print a code fragment to mark up by hand(*), the data goes 800 miles to a server and then comes back 800 miles to the printer 30 feet away from me. This process typically takes 3-5 minutes.
(*) Yes, I'm an old fart. I still do this occasionally. Don't worry, though - my annual stack of recycled paper is around one inch tall.
Software Zen: delete this;
|
|
|
|
|
I find REST to be carp... but i'm in the minority... so i have to use it 
I once wrote something, but did not focus on latency. Its a good point that i had not considered.
GitHub - maxsnts/TARAPI-An-API-Rant: “TARAPI” An API Rant![^]
(I end up not finish the Rant because by that point i had released some steam.
There's even lots of spelling mistakes)
|
|
|
|
|
<sarcasm>
Well duh, you need to use npm to install AngularJS so you can use Node.js for your WebSockets that you should connect using Webpack.
If you're not using at least 100 libraries you're not putting in enough effort and YOU're the problem 
</sarcasm>
|
|
|
|
|
Does one of those libraries use the Retroflexive, Inter-secular Fractal Pipe Massage pattern?
Explorans limites defectum
|
|
|
|
|
Is your problem with REST per se, or is it just a problem with slow devices transferring too much state?
|
|
|
|
|
The problem is as I originally outlined. It's a completely synchronous call/response system being used in a situation where 99.9999% of the time there's nothing to respond with. But, when there is, it needs to be seen very quickly. So it's just the completely wrong tool for the job.
On the automation system side, you could be dealing with hundreds of devices, so it's doing huge amounts of I/O and network traffic for essentially no reason, and it has to parse all that data, convert to binary, and check it against what it saw last time to see if it has changed, and each of those devices might have quite a few values to deal with. If the device can only transfer a single big chunk of state, it just makes it that much worse.
If multiple clients needs to do the same on those devices, it compounds, and sometimes overwhelms the device.
Explorans limites defectum
|
|
|
|
|
Sorry, I had my HTML backward. Your computer should be the server and all the IoT thingamabobs should be clients. Then they could PUT or POST asynchronously. If that's not the way the world works, get another world.
|
|
|
|
|
That's generally not desirable for security reasons. The automation system should be the one making connections, as configured by the administrator. In some cases it's unavailable but typically it's something that's not done unless really necessary.
Explorans limites defectum
|
|
|
|
|
Dean Roddey wrote: Why don't people get that REST sucks for a wide variety of applications
Or from my point of view why don't people get that Agile doesn't work for architecture?
Dean Roddey wrote: People make a device, and probably make no effort to ask anyone like me what are needs are,
They decide that they can deliver the API in 6 weeks or worse 2 weeks, and the "product owner" is more interested in delivery than usability. Not to mention of course that when the implementation phase starts there is in fact no actual requirements beyond "make an API" but certainly no willingness to back off on the delivery.
Dean Roddey wrote: So now you have a a bunch of devices out that that you just have to pound relentlessly with GET commands ...make it 'easy' by only allowing the transfer of the entire state of the device
It was designed based on what info the implementer had. They didn't have time to make 120 different routines, and QA certainly would not have had time to test it. And probably when asked they asserted they were not even sure anyone would use the API. So you get one API call.
Dean Roddey wrote: It's like so many people just don't even think beyond a REST API or HTTP, and throw it into everything, whether it's remotely appropriate or not.
Its like people think that 2 week sprints are more than sufficient to plan for an architecture that is supposed to be robust and last for years. An an off hand comment in a meeting several weeks ago leads to a requirement that must be implemented right now. And it certainly doesn't have anything to do with actually determining how it will be used and very definitely there is no time to actually figure that out.
|
|
|
|
|
Do cows have hooves because they lactose?
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Are all bulls horny?
"If we don't change direction, we'll end up where we're going"
|
|
|
|
|
I'll have to ruminate on that.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
How cud ewe? Udder nonsense! Being milked for all it's worth is the whey this will end up.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
|
That's probably a moot point.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
I hate cows - does that make me lactose intolerant?
Socialism is the Axe Body Spray of political ideologies: It never does what it claims to do, but people too young to know better keep buying it anyway. (Glenn Reynolds)
|
|
|
|
|
Police from Oklahoma called and asked if they'd seen my ex-wife, and I said, "No. Maybe she's migrating north with the rest of her pod."
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
