This. High level OKRs should be set by the company to steer the ship, and engineering OKRs should align with the company OKRs. Thus, the roadmap is defined by the OKRs - I believe that's the whole point.
Personally I think that anyone who believes that they're going to die before climate change kicks them in the nuts are in for an almighty shock (unless you're 80).
My prediction is that we have at best 10 years of anything resembling BAU before systematic failure.
Really? You're looking at the graph, showing a clear and frankly ominous anomaly, especially in the context of the clear wording around "the oceans should be warmest in March, not August", and this is your response? Well done.
Agree! I am in the UK and have an electric bike, but I only use it for trips where I know I can safely store the bike and where I know the roads intimately. The UK needs to solve this, in addition to improving the safety of roads. There's too many pot holes, poor visibility due to people being allow to park pretty much anywhere, and not enough dedicated bike lanes.
- The use of AI will become mainstream with your average person using it directly - it becomes the first truly revolutionary technology change since smart phones were invented. Serious social questions start being raised.
- The war in Ukraine will continue on but not conclude, with many more casualties on both sides. Consequentially, the stock price of principal US defence contractors such as Lockheed Martin and Northrop Grumman will continue their significant upward trend.
- Once again, CO2 emissions will continue increasing globally. There will likely be some significant food shortages in part of the world.
- The UK will continue its economic descent, with more significant energy price increases and continued inflation.
"4. WHEN AND WITH WHOM DO WE SHARE YOUR PERSONAL INFORMATION?
Affiliates. We may share your information with our affiliates, in which case we will require those affiliates to honor this privacy notice. Affiliates include our parent company and any subsidiaries, joint venture partners, or other companies that we control or that are under common control with us."
I would much prefer that this simply read: We do not share your information with anyone.
What I love about computing and programming is the ability to create something that really helps people, or that they find fun and enjoyable.
The problem is that over time, the opportunities to do this have become harder and harder to find. All the low hanging fruit has gone and more and more people are relying on social media instead of websites to communicate and run their businesses anyway.
Additionally, I'm just not interested in privacy violation, spyware, big data, ML etc.. so that frontier holds no appeal for me.
Ironically it seems like it was easier to innovate in the mobile space and find a market in the days of Palm PDAs than it is today.
Just wanted to add that Eleven (VR table tennis) is absolutely brilliant for exercise. After an hour of eTT and you will be sweating and have increased your step count a lot. Moreover, the better you get at it, the more energy you can put into it.
* If you're wanting to have some change of skill transference into real world table tennis, get an adapter for your dominant hand paddle so your bat has the right weight, position and feel. Also, never forget that the table isn't real.
Don't get me wrong, I'm no DDD expert by any stretch.
I think the main topic and real difficultly of DDD is figuring out specifically where and how to separate out different contexts (the so-called 'bounded context' in DDD parlance).
Creating microservices is a good example. Where should the responsibility for a single microservice start and finish? What might the implications for scalability and extensibility be? What does this mean for data storage? What data will be shared or replicated between microservices and how will this be done?
Answering these kinds of questions is hard and has big implications for your teams and for your business.
DDD doesn't prescribe any structure really, other than saying you should separate out different contexts and use unified terminology throughout the business, which I don't think anyone would argue against.
Are you talking about design patterns by any chance? Maybe things like repositories, adapters, small and focused service classes and the like?
Something I'd like to know, if you're moving off AWS and using your own raspberry pi cluster, what would you do to provide a performant MySQL DB for example? I can't imagine that trying to run a high performance mysql instance on a PI makes sense. So would you still want an old-school rack server with RAID and all the rest to be your DB server?