This is hilarious because it is true. I've seen so many 'startups' spend a huge amount of money and effort trying to imitate the trappings of a startup rather than having original ideas and actually producing something. Here is a sample (more at the link above):
Hello, and welcome to our startup. We hope you’re enjoying your complimentary snifter of vaporized coconut water. Once you’re done, please place the glass into one of the blue receptacles around the office, which will send the glass to be washed and dried. Do not place it into one of the red receptacles. The red receptacles take whatever you put inside of them and launch it into space.
If you look to your left, you’ll see one of our employees using a state-of-the-art ergonomic sleeping desk. Most startups have standing desks, but we have sleeping desks, dancing desks, and even skateboarding desks. The skateboarding desks are just large skateboards you can use to skate around the office. Be careful while skating, though, because we don’t offer any sort of medical insurance, since our benefits budget all goes toward cool desks.
So
This week, Tesla saw its stock drop by around 13% percent this week. Some were quick to pin this on the Volvo EV announcement, but I think that was a small part of it. I think that the bigger part was the reduced collision rating that the Tesla S received this week as well as the market's seeming need to take down 'tall poppies' like Tesla as any/ever chance they get.
So
I think that Volvo's announcement regarding electric vehicles (EVs) has been largely misunderstood or mis-reported as them stating that they will only have EVs by 2020. Actually, they stated that they will only design and release NEW EVs after that date. The existing stable of gasoline powered vehicles will continue to live on past 2020.
So This is an interesting little project that serves two purposes. One is to introduce you to creating 'serverless' applications (in this case using lambda on AWS). The other explores the challenges of adding simple username and password protection to the same serverless project.
Researchers at Israel's Ben Gurion University have created a piece of proof-of-concept code they call “Speake(a)r,” designed to demonstrate how determined hackers could find a way to surreptitiously hijack a computer to record audio even when the device's microphones have been entirely removed or disabled. The experimental malware instead repurposes the speakers in earbuds or headphones to use them as microphones, converting the vibrations in air into electromagnetic signals to clearly capture audio from across a room.
But, as it turns out, this is less of an out-and-out hack, but just simply taking advantage of a somewhat questionable 'feature':
But the Ben Gurion researchers took that hack a step further. Their malware uses a little-known feature of RealTek audio codec chips to silently “retask” the computer's output channel as an input channel, allowing the malware to record audio even when the headphones remain connected into an output-only jack and don't even have a microphone channel on their plug. The researchers say the RealTek chips are so common that the attack works on practically any desktop computer, whether it runs Windows or MacOS, and most laptops, too. RealTek didn't immediately respond to WIRED's request for comment on the Ben Gurion researchers' work. “This is the real vulnerability,” says Guri. “It's what makes almost every computer today vulnerable to this type of attack.”
So
While not a basic introduction, this article is a valuable chronicle of some hands-on learnings from using kubernetes. The hand-drawn illustrations are a great addition.
In this article, we will look at microservices, not as a tool to scale the organization, development and release process (even though it's one of the main reasons for adopting microservices), but from an architecture and design perspective, and put it in its true context: distributed systems. In particular, we will discuss how to leverage Events-first Domain Driven Design and Reactive principles to build scalable microservices, working our way through the evolution of a scalable microservices-based system.
tl;dr: _Catastrophic system failures are remarkably common in IT-dependent environments. The reactions to such failures varies but is often some version of blame-and-train. There are a number of problems with blame-and-train but perhaps the most important is it is a form of organizational blindness that forestalls improvement. Three things:
These failures are markers of systemic brittleness, the inverse of resilience.
The blame-and-train reaction is a diversion, a red herring, and counterproductive; it increases brittleness.
There are productive reactions to failure but they are difficult to accomplish, especially when the failure has big consequences._
Serverless architecture uses a lot of services — hence why some prefer to call the architecture “service-full†instead of serverless. Those services are essentially elements of an application that are independent of your testing regime.
An external element.
A good external service will be tested for you. And that’s really important. Because you shouldn’t have to test the service itself. You only really need to test the effect of your interaction with it.
Here’s an example …
Let’s say you have a Function as a Service (e.g. Lambda function) and you utilise a database service (e.g. DynamoDB). You’ll want to test the interaction with the database service from the function to ensure your data is saved/read correctly, and that your function can deal with the responses from the service.
Now, the above scenario is relatively easy because you can utilise DynamoDB from your local machine, and run unit tests to check the values stored in the database. But have you spotted something with this scenario? It’s not the live service — it’s a copy of it. But the API is the same. So, as long as the API doesn’t change we’re ok, right?
To be honest, I’ve reached a point where I’m realising that if we use an AWS service, the likelihood is that AWS have done a much better job of testing it than I have. So we mock the majority of our interactions with AWS (and other) services in unit tests. This makes it relatively simple to develop a function of logic and unit test it — with mocks for services required.