dpix

This has THE MOST satisfying sounds of any game I've ever played

Been a few years now since I've worked much in C# but these all seem like things that should be linting rules.

Can these be added as warnings to the compiler? Can you have custom lint/compiler warnings from the community like eslint?

I wonder how fault tolerant maglev systems are. The tracks must have to be incredible straight and precise to have a train hovering over it at 600km/hr over those kinds of distances.

With traditional rail it's relatively simple to fix up parts of a track or have areas where trains need to slow down to accommodate tricky sections of track. Must be a lot more difficult to repair a maglev track section?

Congrats on the launch, looks great! Couple of questions:

1. Do you support localization?

2. Do you think there is a benefit to using this in addition to a headless CMS that is already managing authored content?

At my previous company we did a lot of AB testing around product copy in our signup funnel which was surprisingly effective. This could be a really useful feature to include in the future

I don't think the author is trying to call out SQLite as somehow better than others database tech - just that most people perceive SQLite to be a tool for development or exploration when in fact it much more powerful than most believe

Love this idea, the site would make for a great place to buy high quality second hand goods that you know would last too.

I'm a developer and would love to help out building the site if you are interested, email is in my profile

This seems quite subjective - I have worked with services like these and would probably call that SOA where you need to split code concerns along domain boundaries.

In the example above, I would probably use cloud functions or a distributed actor system.

Perfect, a microservice (perhaps just service?) can be whatever you want it to be, and I don't see any reason why you shouldn't split code along technical boundaries if it somehow improves your software

Totally agree, I find a lot of tech is like fashion - leaving and returning again later with a new cooler name.

  just doing it because it made sense.

This ^^. Call it what you like - if it works, it works

You are right! Sorry typo fixed

This is a great article - One thing I always try and vouch for is that you don't need to go "all-in" on microservices. There is nothing wrong with having a main monolithic application with a few parts separated out into microservices that are necessary for performance or team management.

The author hits the nail on the head at the end:

  If I could go back and redo our early microservice attempts, I would 100% start by focusing on all the "CPU bound" functionality first: image processing and resizing, thumbnail generation, PDF exporting, PDF importing, file versioning with rdiff, ZIP archive generation. I would have broken teams out along those boundaries, and have them create "pure" services that dealt with nothing but Inputs and Outputs (ie, no "integration databases", no "shared file systems") such that every other service could consume them while maintaining loose-coupling.

Seems like the major win for this chip is having Memory so close to the CPU - on the same chip.

This would also be a massive win for cloud computing too, does Amazon/Azure/GCP have anything in the works for introducing ARM chips with Memory on the same chip?

Maybe it's just me, but I'd rather all these tech companies that implemented dark mode over the last year or so had worked on new features or bugs instead...

The author talks about how many other sources of bug there might be outside of your code like integration, assumptions, compilers etc that e2e tests will help catch.

Well at least a large portion of those bugs might be able to be caught by unit tests! No reason to write less of those, having good unit and integration tests still make you more confident about your application. And because they are faster to run the feedback loop when they break is also faster

Am I agreeing with you then? You didn't make your position very clear. I'm just stating what I think about wage inequality and class gaps.

If you're asking for an actual number of the price of a Cheeseburger and a Shake? I don't know, but it may be a number that's ultimately better for society?

As much as it costs for employees to be paid sufficiently.

It seems awfully dangerous to think that we should pay people less because otherwise things would be expensive.

This is exactly why/how wealth is moving up and up to a smaller proportion of people at the top

Doesn't this just encourage more plastic dumping into waterways? Now you can write it off because "it wont harm fish anymore"

Lets create systems where we don't need to dump plastic in waterways at all.

Isn't there some amount of trust in backers using kickstarter that the funds are returned if they don't reach their targets?

While this looks great, it seems like you are donating directly to the creators. Are people willing to hand over their money that easily?

Yep! that is exactly what our system also does. QA sign off and automated tests run against our preview env. We aren't pushing PRs to prod.

It's just hard to justify the validity of a preview env if the deployment is different to that of prod, the deployment and infra is part of what you test IMO.

   The reality is that if you want fast builds an experience that makes it easy to compare different commits, etc.. there is a tradeoff.

What makes you say there needs to be a tradeoff? If you can deploy these preview environments so easily why can it not be the same for production too?

I actually think this is a great sounding product. I've pushed in almost every company I've worked at in the past to have per PR environments but never actually had it working for real until my current workplace and it is fantastic. It's for sure made easier with the use of serverless and/or container

Looks interesting but seems like it mainly fits with a docker style deployment? Does this also work with serverless tech?

At my current company we have a CI/CD setup that also deploys a per-PR environment - uses terraform and gitlab pipelines to manage everything including our production deployments.

I'd use this for side projects to get things visible but not for a real production app as I'd want the deployment system to be the same between PR environments and production

Discussion during the outage: https://news.ycombinator.com/item?id=23161623

One problem I have with that hype cycle diagram is that it appears to show that all technologies that get a lot of hype will eventually even out and get good adoption once they go through some growing pains.

Realistically though a lot of new tech will get into the hype stage and then everyone will realise that is in fact no good or just disappear for some other reason.

People see that diagram and think it doesn't matter if you jump in at the hype stage because eventually this tech will become mainstream, when a lot of the time that graph just drops to zero after the hype stage.

This is awesome? Can anyone explain why all the notes are strung together with glissando? (like a slide on a guitar). I assume it somehow cannot react fast enough to produce the notes separately without sliding between them

Reminds me of this great piece by the late Aaron Schwartz - http://www.aaronsw.com/weblog/hatethenews

News (particularly in the US) is so caught up in Politics that no one ever knows what anyone's policies are any more.

My favourite part of this article is:

There is voting, of course, but to become an informed voter all one needs to do is read a short guide about the candidates and issues before the election. There’s no need to have to suffer through the daily back-and-forth of allegations and counter-allegations, of scurrilous lies and their refutations. Indeed, reading a voter’s guide is much better: there’s no recency bias (where you only remember the crimes reported in the past couple months), you get to hear both sides of the story after the investigation has died down, you can actually think about the issues instead of worrying about the politics.

I agree, I don't think it's malicious and Slack did the right thing here.

My comment was more of a dig at Github specifically. Recently things haven't been working for me (from my perspective an outage) and when you go to their status page it just says "Degraded performance". When your performance has degraded to the point of failure it's time to acknowledge that is in fact an outage...

I hope they change the status page from "Incident" to "Outage". Too often lately have I seen status pages (mainly Github) reporting incidents when a feature or site is down completely. Seems like their SLAs are influencing the reporting of their uptime...

Sure, you can own your own data but if you're serving a public website does it make any difference?

I didn't mean it as a completely blanket statement, hence why I said "generally". In my experience it's a lot harder to manage a contract between a db schema and multiple codebases over managing versioned contracts between APIs.

"It's better to just solve whatever problem you're facing in the simplest possible way."

I completely agree with this, but I dont beleive that syncronizing deployments across multiple services is ever simple - have been in this situation at a past company where it would take an entire week every 3 months to do a deployment

This is actually a similar approach to how next.js deployed to vercel (previously zeit) works by default. Each page or api endpoint is served by an individual lambda function so they can scale up or down independently

https://nextjs.org/docs/deployment#optimized-for-nextjs

The same argument can be made for building separate services too. Could become very difficult to merge data between two services after you had redundant information being saved across the two because of a bad design up-front.

Sharing databases across services (micro or not) is generally a pretty bad idea exactly for reasons around versioning.

Versioning APIs is a pretty standard way to get around this.

If your deployment relies on synchronized service deployments you really dont have independent services at all.