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.
I have come across an interesting problem. A customer is standing at the checkout of a grocery store with his purchases and is asked to pay the exact amount without creating any change. There are notes of various denominations in his pockets in random order (note denomination is not tied to a real bank notes, the only boundary is that it is an integer greater than 0). The objective is to pick up the necessary sum or indicate that it is not possible. If several solutions are possible then any of them is acceptable. So, let's solve it using C# language.
Several months ago I started learning Go language and came across an interesting library go-linq which is an implementation of Microsoft’s LINQ technology in Go. And while it is a good library I find its performance to be really weak because of its design. Trying to improve the situation resulted in a complete rewrite using iterators in a lightweight and simple manner.