It's good to always have a problem in mind from that side project. It might get a little tricky trying to balance that problem in your head with your day job problems, but doing so may help keep up the steam.
On top of this, certain foods may be worse than others. Through experience I've found out that the following foods seem to increase symptoms related to acid reflux: dairy products, red meat, citric products, chocolate, alcohol, soda drinks and coffee.
that's just way to general and way too much depending on the objective thing called taste. Next to chocolate/coffee/... I also really like the taste of vegetables like carrots, broccoli, fennel, pumpkins, ... I really doubt they would fall under the category of stuff which is likely to increase reflux.
"Each player secretly writes 'orders' for each of his/her units on a slip of paper. Each player reads his/her orders while others make sure that what they hear is what is written. A legal order must be followed. An order written by mistake, if legal, must be followed. An 'illegal' or ambiguous order or an order that is given an illegal order (or given no order) must stand in place. (The unit holds.) A poorly written order that has only one meaning must be followed." [0]
Assuming the rule version is the same, the rules may not have been obeyed: the written command should have preceded the spoken command. Clearly, the players wanted England dead ;)
Yes, it's in violation of the rules. However, the enforcement of rules is at the pleasure of the tournament director. In tournament play, you typically do not read your own orders. Each round, one player reads starting with his/her own orders. If the rest of the table thinks that you cocked up your orders, no one else is going to police it for you. Walking away from the table during adjudication is egregiously bad play. It's unlikely that the TD would have done anything about it.
In a match with Edi Birsan, someone misread my orders to my advantage. Should I have proactively corrected them?
Occasionally in the chaos of play, a spare unit will make its way onto the board. This is common enough that it's called a flying dutchman[0]. I've seen it happen at least twice in tournament play.
People can get nasty when a tournament is at stake. Once someone managed to lock himself in a garage and his opponents declined to let him out until after orders were due.
Each year for the past 3-5 years me and my friends have been getting together for a weekend to play a few years of WWII. The game that we have been mostly playing is Columbia Games' Eastfront II, which covers the eastern war with Germany and Soviet Russia. It's basically a hex-based map with different terrains, rivers, weather changes, HQ-driven troop mobilization and combat - the rules are abstract but not overly so to uphold an enjoyable immersion. The game also employs fog of war with thick wooden standing unit pieces, which certainly adds to the excitement.
The game is advertised for 2 players, but we went ahead and modded the rules for 6 players + a referee. We made both sides consist of 3 field commanders plus a supreme commander. We looked at the map and divided it into 3 parts: the north, the middle and the south. For each part of the map, a German field commander and a Soviet counterpart would sit against each other and hold command of their own area. They saw only units that moved on their map. We decided that each 4 turns (a turn was a fortnight) the field commanders could all go have a meeting with their supreme commander, discuss strategy and synchronize information. We usually set these meetings to last for about 10-15 minutes.
The role of the supreme commander was to dole out repair points plus reinforcements and to send messages to their field commanders. Each turn the supreme commander could send a message to all of his subordinates, and each turn all of his field commanders could send one message to their supreme commander and one message to their fellow field commander. A message could be intercepted with a possibility of 1/6. Intercepting the message meant that the referee would toss a die and if it turned out one, he would take it to the enemy supreme commander without the sender knowing about it until the next meeting.
As an addition, the supreme commander had a map, but he had nothing in it except his own unit, which was good for moving singular units, sending paratroops and air strikes. The supreme commander would also get all the dead units brought out to him when units started dying. You would definitely know things were bad when infantry that were at the edge of Moscow 3 turns ago (or so you recall...) were handed to you by the referee!
Last year we upped the ante and tried out EuroFront II by Columbia Games. It was an epic attempt to play the final year of the war with the whole map of Europe, the winner being the one who holds the most Victory Cities (historically notable European cities) in their supply network by May 1945. With over a dozen players we anticipated problems in our message delivery system, which mainly consisted of a two guys gathering a bunch of papers from players and throwing dice for each message per turn per player side.
We opted for an easier solution and I set out to build a simple messaging system. It was a horrible PHP Slim-based Bootstrap webapp, with business rules written in postgresql functions and code structure being an implementation of pasta. I suspected it would be a maintaining nightmare (and it sure was!), but it worked without a problem during that weekend. Everyone loved it, including our refs' feet.
This year the game is Eastfront II and the messaging is modified for two player sides. We will also allow messages to pass through to their original recipient even if they are captured. With this we will experiment whether the turns will become more interesting for the players whose messages are always captured.
Based on this horrid ad-hoc prototype of mine, I'm currently working on building a more generic, a rule-based messaging system for our guys. Definitely more maintainable this time, promise.
Ps. For what it's worth, the ultimate alpha nerd war game seems to be The Campaign for North Africa. I will invite you to read the description of the game as described in Board Game Geek [0].
I'm perfectly fine with defining get and get_in ala Clojure and using them (they work on __getitem__ supporting things, so dicts, lists, strings, most random user-level containers). I go a bit further in my codebases and implement:
def get(obj, k, default=None):
""" safe __getitem__ obj[k] with a default """
def assoc(obj, k, v):
""" obj[k] = v returning obj """
def dissoc(obj, k):
""" safe del obj[k] returning obj without k"""
def get_in(obj, keys, default=None):
""" __getitem__ obj[k0][k1][kn] with a default. """
def assoc_in(obj, keys, v, default=lambda n: dict()):
""" __setitem__ obj[k0][k1][kn] = v. __getitem__ failures handled with default """
def dissoc_in(obj, keys):
""" Return obj asserting that obj[k0][k1][kn] does not exist. """
def update_in(obj, keys, update_fn=None, default=lambda n:dict()):
""" Update the value at obj[k0][k1][kn] with update_fn returning obj. __getitem__ failures handled by default. """
def merge_with(fn, **dictionaries):
""" Merge resolving node conflicts with fn """
def deep_merge_with(fn, **dictionaries):
""" Recursively merge resolving node conflicts with fn"""
as a matter of course in most of python webapp and data munging projects. They are insanely useful when working with the gobs of JSON that is common when interacting with modern web services. I really should throw the implementations into a public library at this point.
> Why though? I'm of the opinion that the error should be handled at the place that produces the first NULL/None.
Producing NULL (or whatever the languages equivalent is) isn't an error -- if there was an error, it would be throwing an exception, not returning NULL. The idea of "do this chain of operations propagating nulls encountered at any point" is reasonably useful.
I just hate NULL standing in for a boolean notion of existence, I'd rather see a separate boolean member indicating the validity of the other member (string middle_name; boolean has_middle_name;). Or in a strongly typed language an Option/Maybe type. Just assigning things NULL sometimes has the problem of people looking at the object and assuming everything will always be populated.
> But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.
Our designer would consider it, if the visible license options were not so restricting. Rather than make it "Limited to 1 commercial project", they should add a reasonable license solution that allows a team to use it for many projects.
