noobiemcfoob

The only feature keeping me on Chrome is web bluetooth.

You'll have dumped it into a strict database, giving yourself a false sense of order and organization. But later when you need to query that amorphous data, you might be able to use OPENJSON or something else, but a NoSQL solution will have been built to handle this type of query specifically with utilities like key exists and better handling for keys missing or only sometimes being present.

Then argue honestly and work to steelman other's arguments. To address your point, I'd hardly consider IoT platforms to be a "narrow" usecase. Smaller than the whole of computing, surely, but it's a growing field. The reality is that more and more devices will become available that generate all sorts of hard to predict data. Being able to handle those easily will be a large strength for platforms going forward. Dropping this hard to predict data as JSON into a RDMS will certainly come back to haunt you in 5 years.

What's wrong is that you asked for any usecase and then critique one because it's not broad enough for you.

It's hyperbole. A lot like systems that require hard type declarations for each and every function. The advantage of type systems is performance. Any correctness guarantees that come along with it are nice sugar but hardly the point and often misleading.

I've built IoT platforms where data from any device must be accepted. This is largely where my preference for NoSQL comes from. A device created tomorrow will not have a schema I can predict or control. NoSQL allows the easy integration of that device while a traditional database will at worst require a migration for each new device you want to support.

>use Elasticsearch

Found your problem.

“Why didn’t we use an RDBMS in the first place? “

Because initial application specifications are sparse and definitely wrong. If your application is still up and running 5 years later and your data definition hasn't changed much in the past 3, then maybe refactor around an RDBMS. Designing around rigid structures during your first pass is costly. This is why there's been a rise in NoSQL and dynamic languages.

But as soon as you're using "Maybe", you're impeding much of a type systems strengths, as the article outlined.

It's better to assume all code could throw an error. No statement is safe. This becomes particularly important in distributed computing as resources may be offline at any given moment. It's from this perspective that type systems afford a false sense of security and appear to be scratching the itches of overactive Type As.

It throws an error. Errors are a type of behavior. Some of those error behaviors you can cope with. You catch those. Others you can't. You raise those and either the system can cope or it can't and you crash. What part is nonsensical?

I like the concept of encoding properties, like a boolean of non-empty, in an object.

Beyond that, this article further convinced me type systems are for the pedantic. A given function signature is impossible? Seems like just another strength of a dynamic language.

It was both language and database theory, all focused on Oracle. IIRC, it was titled "Database Administration", but I remember having to draw out schema diagrams and learn all the particular arrow types (one-to-one, one-to-many, etc) and what different block shapes meant in the diagram. All that only to get into industry 5 years later and find no one goes beyond basic squares and maybe double-ended arrows in practice >.>

A Data Analyst is a Data Scientist who can't prove Bayes Theorem.

I learned SQL in high school as my first "programming" class, though that's more of a quirk of how I moved through the curriculum. This was prior to learning C++ and then transitioning to Python some years later.

Perception is important. A lot of these decisions aren't made by people who sat down and wrote down the numbers to arrive at the rational choice. But if I think I have utility for a pick up often because I like to think I'm that rugged, diy type of person, I'll think it's rational to own a pickup and assume the relative prices get massaged away.

/I drove a pick-up for a number of years for this reason until hybrid crossovers became viable.

I believe some research out of Duke had already done similar things with chimps, but bringing it to humans is major. Each of these studies becomes a proof of concept for what "should" be true of the brain, but theories fall flat all the time. Each lays a brick in the foundation for building a true BCI.

I'm most excited that this was done with only an 8-channel OpenBCI headset, 16-bit, for the "Receiver". The "Senders" had a much stronger/better headset, but seeing open hardware show up in this is awesomely inspiring!

An update, Revenue Analytics will support immigration sponsorship for qualified candidates.

Revenue Analytics | Software Engineer | Full-time | ONSITE Atlanta, GA

Revenue Analytics is a SaaS company that helps big companies make big revenue decisions in pricing, products and promotions. Our analytics solutions drive millions in revenue uplift and eliminate wasted time.

We're hiring software engineers of all levels to build out a catalog of analytics products. Our software stack is primarily Python and orchestrated containers in AWS.

Unfortunately, we DO NOT offer visa sponsorship.

Apply at https://www.revenueanalytics.com/careers or email me with a cover letter and resume at lblackwood[at]revenueanalytics[dot]com

The problem this is addressing is a code being impenetrable by a human. If your solution is adding a second (human readable) code beneath the machine readable code...you haven't addressed the problem. The user must still trust their reader to parse the code.

QR codes' reconstructability is a major strength that this lacks, but I'd bet there's a way to expand this to include ECC around it, much as QR codes can.

BUT...OCR is quickly advancing, so the need for a specialized code a specialized machine can read will diminish over time anyway.

My experience echoes yours. We had 2 senior devs and 1 junior. We had one major event in 3 years -- a long weekend where things were on fire with code being updated on the half hour. But afterwards, we had so many indicators of when things were even approaching that level the job got almost boringly simple afterwards.

Graphviz and pygraphviz

I can't echo this sentiment enough. Forgetting is just as important as remembering. Past experience has only marginal value to the present and future and can just as often lead you into stray directions. The number of times having a pinpoint memory of some obscure fact has helped is a handful across decades? A bit of obvious bias: I can't really know all the times knowing something I didn't would have been helpful. But I can recall a substantially large number of times I -- in effect -- remembered too much and it was a hindrance.

Conflating of Chelsea Manning and Assange with Snowden's efforts is the crux of a very successful campaign to bury him behind claims of treason.

Yeah, I do. If a manager is terrible and I get the sense the waitstaff is stressed or mistreated, they've lost a customer. I feel bad enough driving past the homeless on the way to work. I'm not going to incentivize mistreating workers by paying for a service I can get elsewhere without the guilt.

Really nice tool! I often develop in a similar pattern (though not quite as functional) using IPython and it's %autoreload magic. This looks a lot cleaner.

If society could admit that this networking has value, instead of trying to awkwardly access it without naming it, I think we would all be a little saner. A person's social network -- particularly when they know billionaires -- is inherently valuable in and of itself. Even in more meritocratic engineering firms, being able to refer competent engineers is often financially rewarded.

So let the elite monetize their social networks and let us stop having to not point out they are blatantly bad at their proclaimed job.

There's a difference between handing new engineers ownership of maintenance tasks and training them to maintain an existing system. The age of a system isn't the problem. It's the baked in processes that are critical to the business that a new engineer could not have learned from outside of the company. Management sees that baked in knowledge as "some light configuration" when it is often far more complicated than whatever system it was built on.

Oh, this hurts so hard. I'm going to go cry now.

New devs almost certainly shouldn't be given maintenance and repair tasks. How can someone know all of the business logic and needs a given solution provides within a month of starting?

This problem is because the old guard wants to move on from the problems they created. They want to play with new toys. So they hire new devs to do the work they don't want and "free" themselves for greenfield development (i.e. the exact opposite of how it should be managed).