My name is Alexander Kalankhodzhaev, MSc in Computer Science. I work as a TechLead of the blockchain lab of the largest Russian oil company. I am a developer, a big fan of computer technologies, an amateur racer and a father of two kids.
MSc in Business informatics, 2009
Higher School of Economics
BSc in Business informatics, 2007
Higher School of Economics
This time I want to show how to solve a game using a perfect play which means being able to predict the outcome of the game from any position. The perfect play is the strategy that leads to the best possible outcome for that player regardless of the response by the opponent. For the illustration I have selected two children’s games with stones. The rules are very simple. There is a pile of 99 stones. Two player take n stones out of the pile in turn. The one who takes the last stone is the winner. In each game n is different:
Let’s find out how to always win these kind of games.
Storing data in MongoDB with the official C# driver sooner or later you might run into the following exception:
System.IO.FileFormatException: Size 22327168 is larger than MaxDocumentSize 16777216.
This is happening because of the limitation of a single document size that exists in MongoDB by design.
The maximum BSON document size is 16 megabytes. The maximum document size helps ensure that a single document cannot use excessive amount of RAM or, during transmission, excessive amount of bandwidth.
Though there is a JIRA ticket called Increase max document size to at least 64mb, it doesn’t seem likely to be done in the near future. Geert Bosch, senior software engineer at MongoDB, wrote the following comment:
In order to support much larger documents, such as the 64Mb documents suggested, assumptions such as that we can easily allocate copies of documents for modification will no longer hold. Transactions could grow extremely large (just think of a 64Mb array of elements to index). We would need to significantly throttle the number of concurrent operations, or raise the memory requirements for mongod.
But, if you find yourself stuck in such a situation, don’t get frustrated – there is a solution.
About a month ago we welcomed a new developer to our go-linq maintainers team cleitonmarx (Cleiton Marques) who introduced an interesting pattern for emulating generics in Go and became the main show-maker of the third version of the library. Here is a small story of how the generics behavior was emulated in go-linq.
Not long ago my team moved a legacy version of our application from a different branch out into a new repository. The problem was that they had forgotten to copy tags there, so we lived without tags for quite a time, until I decided to deal with the problem and made a utility that copies matching tags from one git repository to another.