jamestenglish

The currently headline makes it sound like it just click sell on $3.6B shares, the article makes clear that they have been selling over the year and this is just the final report that they are fully divested.

No, web designers need to do their best to balance cost/value of changes. While this might be a hot button topic here, I doubt the general public knows or cares much. Silly and self centered to DEMAND everyone needs to change to fit a niche group of users

Stuff Made Here: https://www.youtube.com/channel/UCj1VqrHhDte54oLgPG4xpuQ

https://news.ycombinator.com/item?id=25376346

Uber is a global app, so the other 9/10s of the code is for all the features and functionality you'll never see outside your region since there is currently no way to split up binaries by region.

Preferences -> General -> Applications

Content Type: slack

Action: Use Slack

Do you have that setting?

The penalty here isn't because your equipment fell apart, it is if you keep playing with broken equipment then that is a penalty. If your stick breaks and you drop it on the ice then you are fine.

Broken sticks are sharp so playing with one is a safety hazard.

Uh, what is it? Do I want it to work? I tentatively click "YES COOKIES"

Big cookie plea is now replaced with a big "Sign in with Google/Slack"

Hold up! What the hell is this thing? I am not just going to potentially link you to my slack or gmail!

There is a sandbox mode button? What is this thing, why would I need to run it in a sandbox?!?!

The only way to know what this is or will do without actually trying it is to watch a youtube video and the explanation doesn't even come until 20 seconds into the video!

I imagine this would have gotten more traction on HN if your page contained even a single line of text explaining what this is: an interactive sound board. Rather than forcing users to watch a video or try out some unknown thing first.

If you are going to introduce a new tool into an already crowded ecosystem the least you can do is describe why anyone should use it.

>They also trained the model with non-blackhole images. Since the output of the model was approximately the same, this indicates that the resulting output picture doesnt look like what we think a black hole looks like just because it was trained with black hole images. It likely really looks like that.

If you are feeding non-blackhole images in and getting blackhole results out, wouldn't that be indicative of an over-trained model? Her other analogy was we can't rule out that there is an elephant at the center of the galaxy, but it sounds like if you feed a picture of an elephant in you'll get a picture of a blackhole out?

As a society we do want to protect people from exploitation, but a game developer is significantly different from the other 2 examples you used: amazon (I assume you meant warehouse) worker and uber driver. Those are low skill jobs so employers have all the leverage, I don't think many of them want to be an uber driver or warehouse worker.

Contrast that with a game dev, which is a very high skill job. They can take those skills into many other fields and make money, but they don't want to. Is that exploitation? I don't know, but it doesn't feel like it is to me.

In my opinion Slack does something that is often very undervalues and easily overlooked, it is like the opposite of a death my a thousand cuts - superiority by a thousand minor improvements.

When taken individually or even in handfuls none of the features are that impressive, but cumulatively it creates a much better product. This was very apparent to me at least when I switched from HipChat to Slack. Just reading features or looking at screenshots they are nearly identical, yet with actual use Slack seems like a significant step up.

So yes IRC is to Slack, as the Ford Model T is to a Mercedes S-Class.

Instead I meant to use Kubernetes as an example of the work being done to standardize and abstract these sorts of microservice issues. Kubernetes solves a lot of orchestration issues and I expect there will be greater work with other projects into solving other problems like distributed transactions in the future.

The current thoughts on microservices is that you should really re-evaluate how critical strong transnational guarantees really are to your application.

As with everything its about the right tool for the job and a lot of organizations are more than happy to trade network overhead for the other bullet points microservices offer.

A lot of the SOA work I did was putting REST/SOAP interfaces on various monolithic APIs. This was generally a good step forward and decoupled things (especially the front-end) but it was far from perfect. You still had the monolith and a lot of the code-smell that gets built into a monolith of spaghetti dependencies making it hard to write new features and move forward.

Now the argument is always "well if you and your team were just better coders and more disciplined that wouldn't happen" but in the real world it is shown to be incredibly difficult to actually have a team that is that disciplined and microservices give a real hard barrier to enforce that discipline.

I very rarely see things that are truly reinvented, and I think that is some serious ego bias essentially saying: back in my day we did it right and you dummies are just figuring it out.

Instead I see every new generation of developers refining good ideas over and over again which improves our industry and products.

> Fallacy #1: Cleaner Code

> “You don’t need to introduce a network boundary as an excuse to write better code.”

I see this all the time as the argument against microservices: "but if you are just disciplined you don't need them". It seems pretty clear to me that a large body of programming history has shown that it is incredibly difficult for a whole team to be disciplined all the time. If everyone was perfect drivers we wouldn't need seat belts. Some artificial "barriers" can be very helpful to tackle people working in the real world.

> Fallacy #2: It’s Easier

> “Distributed transactions are never easy.”

This argument I'll buy, but there is a lot of really good work going into orchestration like kubernetes which makes a lot of these concerns much lower.

> Fallacy #3: It’s Faster

> “You could gain a lot of performance in a monolith by simply applying a little extra discipline.”

Again with the discipline... But another point he makes really misses the mark:

> Additionally, many of these stories about performance gains are actually touting the benefits of a new language or technology stack entirely

When you have microservices it allows you to use the best tool for the job for each individual service. If you have a Java monolith and you want to add new functionality that say GoLang would be better suited for, chances are you are still going to develop it in Java because it has to fit with the rest of the monolith. His example counters his claim.

> Fallacy #4: Simple for Engineers

> “A bunch of engineers working in isolated codebases leads to ‘not my problem’ syndrome.”

This is pretty subjective and I really think depends on culture and buy-in. Almost all these same things could be said about a well architected SOA monolith.

> Fallacy #5: Better for Scalability

> “You can scale a microservice outward just as easily as you can scale a monolith.”

Again his example, seems to counter his claim. Yes you could segregate the API calls to your monolith but you are still going to have the overhead of those un-used APIs. Unless you are doing some really clever dynamic loading that code is still going to be loaded into your executable package at the very least redundantly increasing RAM load, making for wasted resource utilization (which converts to real dollar and cents in the VM world). Additionally the author completely ignores any potential start-up costs of needing to load a larger monolith over a smaller microservice.

In looking around at the certificates that they support, I was not surprised to find that they accepted no other certificates as valid – only their own. That means it would be trivial to man in the middle any outbound HTTPS connection, so even if they do allow outbound access to Google’s JSON location API it wouldn’t help, because the connection and contents can be monitored by them.

It is hard to say for sure, because the author doesn't give any specifics but wording like:

"You therefore are more reluctant to make large-scale changes that will lead to the failure of lots of tests. Psychologically, you become conservative to avoid breaking lots of tests."

make me think the author wasn't actually making unit tests, instead they were likely end-to-end tests, or partial ETE tests that were running inside a unit test framework. I have had many disagreements with other developers that just because your test runs inside a unit testing framework doesn't actually make your test a "unit" test.

SOA mostly refers to "Enterprise SOA" now and Enterprise SOA has skewed many of the decoupled principles of SOA.

For example Enterprise SOA heavily focuses on middleware, of course all these middlewares are vender specific and create vender lock-in. Microservices mostly focus on just HTTP for their middleware.

Another example of Enterprise SOA is using SOAP and most people configure their SOAP services to have very rigid contracts. So if you update your SOAP service schema to add a field, even if none of your consumers need that field they all need to update their consuming schemas which is very tightly coupled. Microservices should focus on consumer-driven contracts for services.

Language evolves and I would say a lot of people now consider SOA to mean heavy middleware and SOAP with strong contracts creating the new term "microservices" help to differentiate.