Step-by-step instructions on setting up an API endpoint running on AWS Lambda, storing data in DynamoDB, with a React static site hosted on S3.
45 karma · joined October 29, 2016
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.
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.
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.