Mystery Hunt Software Meeting on February 2, 2008 Attendance: Adam Rosenfield, Anders Kaseorg, Adam Seering, Evan Broder, Eric Price, John Hawksley, Nelhage Elhage, Gregory Price, Rishi Gupta, Tim Abbott, Will Throwe, Allen Peterson, Jeff Jakubowski, Matt Sakai Notes taken by Matt Sakai. *** Demonstrations of existing solving applications The meeting started with demos and descriptions from various teams of their current applications. CODEX (including Acme) originally used wiki combined with AOL chatrooms, which turned out to be hard to manage for a large team. In the current system, LSTs (?) are used to pull information off of the official hunt pages to automatically populate headers for the wiki pages. Jabber chatrooms are created for each puzzle, which are monitered by a bot. The bot logs chat traffic into a SQL database. A VBscript frontend displays chat logs from a particular time, and allows text searching as well. Servers were base on VMWare. Codex also inherited a sophisticated chatbot from ACME which was not well utilized because not many team members were familiar with it. It creates a table of puzzles with status and solution. Google spreadsheets are a popular tool for solving puzzles. Problems included some uncooperative Jabber clients (such as Meebo and Adium). VMWare net did not work very well. SMALLISH MOMENTA (from Simmons) presented at application allowing solvers to place virtual sticky notes onto webpages. The notes could be placed anywhere, contain arbitrary text, and would be visible to any user looking at the same page. This was mplemented in Javascript with a PHP backend to maintain state. Currently only works with Firefox. In previous years they uses a wiki and AIM chatrooms logged by a bot. (No details on the bot.) They also liked Google spreadsheets. They also used Google chat, but founf that it did not work very well for them. LEFT OUT presented czar.ofb.net, a server application which showed a table of puzzles with links to the original puzzle, a wiki page, a Google spreadsheet, and freeform notes for each puzzle. Information for each puzzle is entered manually. Spreadsheets must also be created manually, but are then automatically linked from the table. DFA comprises about 90 members, approximately 30 of them remote solvers. They used MediaWiki to collate information. A central coordinator was responsible for coordinating with remotes solvers, calling in answers, and creating the wiki pages from a template. The wiki was hosted on the SIPB Scripts service (scripts.mit.edu). They also presented a separate puzzle checkout application to keep track of who was working on a given puzzle. It had a table of puzzles with links to the puzzle page and wiki page but no answers. (Because there was no authentication on the app, answers were considered a security risk.) Because there were two separate applications, they had some difficulty keeping information in sync, which led to the wiki being underutilized. Remote communication was handled via several protocols (including Gtalk, AIM, and Skype), requiring the central coordinator to cross-post information frequently. IIF comprises about 50 solvers with a few small groups of remote solvers. They presented a server application providing a table of puzzles with links to the puzzle page, wiki page, chat room, solution and freeform notes for each puzzle. Puzzle information is entered manually, but wiki pages and chat rooms are automatically created. Puzzles could be manually rearranged and regrouped without recoding. Frontend Javascript talked to a J2EE (Java) server using Struts on Apache Tomcat. Chat used Jabber this year, Yahoo last year. Data was stored in text files instead of in a database, which also allowed file uploading. They also had a webcam on headquarters, which was very useful, and a TeamSpeak server, which was poorly utilized. Jabber chats were password-protected, which caused problems with many chat clients. SUEZ presented an application with a table of puzzles built from a database. The table included priority, puzzle group, and freeform notes for each puzzle. Individual puzzle pages included a version controlled solving grid widget, a discussion board widget, and a widget to create and link a Google spreadsheet automatically. Uploaded files were also linked in. The application includes the capability of adding more specialized widgets like a crossword widget. Implemented in Haskell with Javascript frontend. Remote sover communication was largely handled by a separate zephyr/IRC system. METAPHYSICAL PLANT presented a slight variation on the SUEZ system, which concentrated on developing the Google spreadsheet widget (managing access control through with the team roster). They also used Growl for broadcast messaging. GROOVYTRON presented a stripped down version of an application developed by MAYHEM (who were not represented). Groovytron had about 40 mmembers, mostly in one location, so they did not need much of the remote sover functionality. A table of puzzles listed the sovling captain, priority, and freeform notes for each puzzle. Individual puzzle pages included a wiki section and a sortable comments section, as well as regions for global announcements and status updates. An IRC server monitors chats and puts IRC logs on the pages as well. The page background color reflected puzzle status. Unauthenticated user accounts tracked solver names and locations. There are other application feature that were not described because Groovytron didn't use them. They also had a private domain set up with Google docs. Google docs produced severe performance issues for many solvers, leading it to be poorly utilized. MANIC SAGES comprises over 120 solvers, many of whom and high school students from around the country. They primarily used Semantic MediaWiki to coordinate. Top-level table of puzzles is created automatically from information in individual puzzle pages. Each puzzle had a wiki page including a chat section updated dynamically. Puzzle information is entered manually. A combination of high traffic and intensive processing led to performance problems on the server, which may have been fixed by using more powerful hardware. *** General issues to be addressed: If there are multiple repositories of information, the repositories must be kept in sync with each other. Within a single repository, we have to deal with the issue of simultaneous edits, merging data, and conflict resolution. Administrative overhead should be minimized, especially for general solvers. If overhead is high, solvers won't use the system. Thus, tasks should be automated wherever possible. There should be a facility for using specialized widgets for solving various types of puzzles. *** Specific requirements: Deployable on scripts.mit.edu. Deployable outside at MIT environment. Use distributed version control development. Covered under AGPL (Affero General Public License). Documentation should exist. Automation of tasks included where possible. Information should be presented on a single page, where possible. User-testing should include non-programmers. *** Design considerations: Structure should be flexible and customizable. The default view of the information should be useful for non-technical users. However, sophisticated users should be able to easily custom their own view. The pplication should be useful no matter what structure future hunts use, so be wary of assumptions. Non-technical puzzlers should be able to understand and use the system quickly, with a minimum of training. Some facility should exist for storing information about the structure of the hunt as a whole. The system should be able to priorize puzzles in some way. A live chat updating widget seems useful, but will it require too much bandwidth? Puzzle-solving issues are separate from Hunt organization issues, and should probably be addressed at a separate time. *** Specific implementation suggestions: The application should be platform independent if possible. It should also be browser independent, although no particular effort will be made to ensure IE compliance. A common development platform should be chosen to control library dependencies. Distributed version control seems popular, with Mercurial and Git being mentioned specifically. Subversion is also mentioned, but is not distributed. Comet should be investigated as a messaging protocol to handle communication between browsers and servers, and possibly control bandwidth usage. Front-end work will probably be handled with Javascript. Server-side work should be a unified project. Python is a popular language (and will have a large following among Course VI students), but others were discussed (Haskell, Java). Data storage will probably be handled with a SQL database, probably MySQL since it is hosted on scripts.mit.edu. Mercurial, or Git) *** Action items: A mailing list exists (puzzle-software@mit.edu). Those not on it should add themselves or write to Tim Abbott so that he can add them. Tim says a locker exists on Athena (mystery) and he will set up access rights. Further coordination will take place over e-mail; in-person meetings will be called as necessary.