I think the general problem with "No code" as you describe it is that if you want to only offer the lego building blocks then you can't support corner cases. If you want to eliminate all of the corner cases you often times end up creating something as complicated as code but without the nice tooling or information density.
Or, as happens a lot in no/low code but also in code-heavy (normal) development is that this 'corner case' feature is just taken out of scope. That eliminates it too as well as a technical solution does.
Basically; you can run a rather medium sized company on google docs or ms office or a bunch of trivial crud apps hacked in php/AD; I know rather a scary amount of companies that do work like that. They are not the biggest companies (I know of at least one that has well over 150m revenue/year for the past 20 years; most others are smaller) but they also spend almost nothing on (that kind of) IT and it works. The corner cases are removed from the business process instead of hacked into the IT flow.
To shine a different light here in these comments, I think the recent resurgence of jazz is interesting and very special. A lot of different forces combined to make this happen, the most obvious being the trend of popular music towards hip hop and people discovering their roots. But I think the resurrection of vinyl had a large role to play here as well. Vinyl has blown up in the past few years and many young people are quickly realizing that some of the best recorded/mastered LPs were classic Jazz and Soul albums from the past century. This is a gateway drug into modern Jazz and also blends nicely with music nerds interested in obscure samples from their favorite modern artists. Also, I dont see the point in being pedantic about genre labels, but hey, its hacker news.
I'd imagine that a competent company would keep access to user audio recordings tightly locked down, either because they actually care about privacy or because they care about the bad PR of recordings getting leaked.
But if the GDPR requires them to send the recordings to users upon request, they need to have a way to do that -- either by exposing a service on the web, or by providing access to customer service employees to handle the request. Not sure how I feel about that.
I would assume that if they made a voice print for you personally it would be fine. It should be still recognized as your own personal data, and underly the same laws
Nothing in the article suggests they were linked to any kind of user identifier, all we know is that each recording is linked to the transcription alexa made of it (which makes sense, training and log wise).
The user were easy to identify because if I listen to the last twenty queries you made to alexa between what you ask, what other people say in the background, what you talk about and what noise is in the background that gives me a lot of information; that's exactly how they were able to identify some of the users from their recordings.
> Nothing in the article suggests they were linked to any kind of user identifier
They were able to provide the customer a bundle of his recordings upon request so they must've maintained such a lookup mapping.
Of course that led to the mix up reported here. But I'd argue it's safer if on Amazons side they simply can't fulfill such request themselves due to anonymization.
I suppose that does raise a question of where you draw the line on a company's obligation to anonymize information. Is disassociating a user ID from the data enough? What about data that makes the user identifiable through patterns?
If I say "Alexa, my name is Bob Jones and I have chlamydia," they're not really helping me out by just not associating that audio clip with my username.
Did you read the about page of the website? "Despite these amazing gains, women still only receive 2-6% of venture capital funding"
I feel like that makes it pretty clear why this website is normal and why "iFundMen" would be odd. This stuff is really not as complex as people are making it out to be. Also, ifundwomen != ionlyfundwomen.
Infinite setup time: In the vacuum of space, as t -> infinity, eventually random quantum fluctuations will spontaneously create a 747 full of ping pong balls.
The origins of Silicon Valley being a technological hub go back all the way to WWII and the economy of the early computer industry. So, I feel the USA being an economic and military superpower is a pretty easy explanation for why 'Silicon Valley' exists in the bay area today and not somewhere else. Obviously, there have been many years and many technological revolutions since those early days but there are pretty clear trails of people, and money leading all the way back.
As far as trying to answer why so many other countries consistently beat America in math and technology I think a small answer can be gleaned from your statement: "we were encouraged to pursue whatever we wanted to pursue." That is not all that common in many countries and cultures in the world. I think a lot of it has to do with economic or political desperation. I have worked with people who learned how to code because they didn't even have running water in their village in India and programming was a way out. Or more relevant to this story, they lived in a Russian town and got a PhD in engineering so they could come to America and be an engineer. These types of stories are very, very common in the Bay Area. Looking at the education systems is helpful, but I think you need a real driving force to get most people motivated to learn difficult things.
I'm not sure I could attribute the technology hub we see to WWII. Most technology advancement in America was happening in Bell Labs during WWII (The lab was located in New Jersey).
I don't follow TDD strictly, but I still think testing is important. I mostly see tests as help for future programmers (which includes the original authors), kind of like documentation. It's a rigid description of how the system should operate and therefore is usually helpful for refactoring or extending old code. I also don't doubt that many people go years without seeing utility in writing lots of tests. From my experience there's a lot of factors that go into how many tests you write before getting diminishing returns. Some off the top of my head: static v dynamically compiled lang, functional v procedural lang, age of project, etc.
Sadly, ever since Java 8 added default methods to interfaces this distinction is even murkier. I'll add the reasons why I prefer interfaces though.
1. Interfaces can be used by any class no matter where they live in their class hierarchy. You can only extend a single (abstract) class in Java because the language designers saw the special rules and overrides other OOP languages like C++ used to avoid the 'diamond problem' and decided against it entirely. Note that in pre-Java 8 implementing multiple interfaces cannot lead to the diamond problem because if more than one interface exposes the same method signature then the compiler doesn't care because it doesnt have actual functionality that could be conflicting. So, because you are limited to only extending one superclass it is easier to bundle functionality in multiple smaller interfaces that can be implemented no matter where your implementing class lies in the class hierarchy.
2. Interfaces provide only a contract of functionality which in practice means they are easier to reason about and use. If you are implementing an interface you dont have to worry about calling a super constructor or any other garbage. Just implement the method signature. Of course you could ask "What if you only had abstract methods with no implementation in an abstract class", in which case I would refer you to point 1. A class that already has some existing superclass could not extend that abstract class.
I hope that clears some stuff up. Just in case you read that and thought the Java language designers were stupid for adding default methods in Java8 they had really good reasons to (mostly to support backwards compatibility with a large change called Lambdas). But having some functionality in interfaces could be argued for as well. In practice there are companion classes in the Java API that are just there to provide some base functionality that they could not do because of the previous limitations of interfaces. Also, the Java8 rules for fixing 'the diamond problem' with conflicting default methods in interfaces is pretty straightforward and rarely encountered.
How do you account for low end pizza delivery chains? I assume the pizza hut and dominoes market would overlap heavily with a McDonald's ordering market.
