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
1. At the moment, we've seen teams use Ditto to localize if they already localize their mockups (i.e. have mockups in different languages). However, we're releasing the ability to create variants of text (i.e. for translations, user states, etc.) not mocked up in the design in the upcoming week. It's been in development for a while (and to be honest we were hoping to release it before today), but still requires a bit more testing.
2. We built Ditto to specifically tackle product copy, whereas existing CMSs (including headless CMSs) are much more geared for marketing copy (longer form, clear H1/H2/body structure, authorship, etc.) -- which we think are pretty different use cases. With product copy and microcopy, teams have to think a lot more about how that fits into the UI/design/implementation; we're also excited about how our CLI can fit into teams' dev processes (like CI/CD) to streamline workflows!
3. Yup, we're super excited about all the potential extensions of Ditto, A/B testing included.
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
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.
It was called modular design. I think the main difference with micro services is the accessibility on the network. I would like to be corrected if I am wrong.
My question was rhetorical, to be honest :) point being that the only new thing, if any, with microservices is that they should be micro and you should have a lot of them.
People have been running >1 services for a long time. Sometimes calling it SOA and sometimes calling it nothing, just doing it because it made sense.
Microservices are indepently deployable modules. Thus the same principles of modular design in a monolith apply. So, yes, you're correct with the network part.
In my experience, this will result in a ton of unneeded extra complexity. Microservices are very heavy and should be cut along domain boundaries and not technical boundaries so that they are as independent as possible and you reduce the need for synchronous communication. In the example above, I would probably use cloud functions or a distributed actor system.
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
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
