It's pretty cool for light work, but I imagine you would be better off doing native ES queries so when you need more complex queries, weighted searches, and optimizations, you will be in a better place to do that.
Basically when it’s the computer’s turn it evaluates every possible move and assigns an attack and defense value for each move. The attack value is based on how many in a row and whether it can win on next turn, and the defense value is how many opponent’s chips in a row and whether it will lose on opponent’s turn. And if 2 or more moves are equal, favor the move closest to the center of the board.
It's fairly difficult, but not perfect, and you can win as the second player.
Basically when it’s the computer’s turn it evaluates every possible move and assigns an attack and defense value for each move. The attack value is based on how many in a row and whether it can win on next turn, and the defense value is how many opponent’s chips in a row and whether it will lose on opponent’s turn. And if 2 or more moves are equal, favor the move closest to the center of the board.
ElasticSearch is not to be used as your primary data store. It's a search tool and you should have a process to rebuild an index from your primary data store.
Outside of that, I highly recommend using a managed service, either AWS ElasticSearch service, or Elastic.co to make recovery and management easy. AWS does a snapshot on every index every couple hours and it's relatively simple to restore a deleted index.
Also, I'm sure the author knows this now, but don't ever run any command on a live production data store without triple checking it.
I have been developing software for over 20 years and leading teams of developers for the last 10. Please allow me to give you some insight from experience.
To your first point, in my experience, the best software, including complex platforms that handle massive amounts of traffic and data, can be built and maintained by small teams. I mean less than 20 developers. The larger the number of developers working on an application or platform has an almost inverse correlation to the speed in which new features are built or bugs fixed.
Software architecture has been done visually since perhaps its inception (tools like UML). At most places I've worked, every new project or large feature is diagrammed visually to use as a guide in breaking down the project into component parts.
In my experience complexity arises, not from lack of tools or industry knowledge, but from 3 main causes:
1. Inexperienced developer asked to create project, who just starts building without planning beforehand.
2. The main one - business demands features built that were never expected or planned for, and built as fast as possible. This causes developers to take shortcuts, make inelegant and difficult to maintain design choices. And leads to often inscrutable code that becomes technical debt especially after the original developer leaves the company. This will always happen as long as software is used to make a business money.
3. High team turnover - I've seen places where developers came and went so often that there was a myriad of things half started and never finished.
How I've solved or helped alleviate these issues: Make the business case to company owners or management that technical debt will be an ever increasing impediment to development velocity and the dev team will need a percentage of work in any given sprint to tackle tech debt issues (as opposed to having everybody work 100% on new features and bug fixes all the time).
I have successfully taken a platform that was bug-ridden, difficult to maintain, and where new feature development had slowed to a crawl due to the over-complexity of the software, to a place of stability and ease of development, simply by allowing our team to chip away at tech debt over the course of several years. Tech debt issues were rated by level of complexity, risk to the business in change (regression bugs), and impact on team velocity. We worked on the highest impact, lowest risk items first and kept going until there wasn't much left on that list.
Absolutely, the main feature any ORM needs before I will consider it, is how easy is it to write raw SQL with the ORM. Because you always have to do this on every large application, and if an ORM gets in your way, it's more hindrance than helpful. Actually love Laravel's ORM Eloquent, because it works for 99% cases, and gets out of your way and lets you populate Laravel models with raw SQL queries when you want to. After using many ORMs in many languages, it's still my favorite.
Back when I did PHP, our company started using Laravel and it was amazing. The team was so much more productive with that framework and our platform was very easy to maintain. This article is bonkers. What a bizarre opinion, hopefully nobody listens to it.
I believe there was already a law stating that you couldn't park in the same place for extended periods of time. Different laws could be written to make sure obnoxious behavior is preventable without forcing people out on the street.
I honestly don't think it is a big deal. It's far preferable to having people sleeping in tents, which this law basically forces an RV dweller to do. It's a horrible law and I hope it gets repealed.
I think it is a fitting punishment for those who copy parts of the Wordpress codebase in their product that they must now maintain Wordpress code in their product.