Would-be developer in need of orientation
Posted: 21 Jan 2015, 02:39
My background: I've taught computer science in college (visiting prof at Princeton, tenured at NYU Poly), left academia to pursue software at Bloomberg for a few years (maintained their version of the C++ Standard Library there), participated in some C++Boost and C++14 standardization committees, and for the past five years been working in Java for the financial industry. I'm new with Magic (started playing back in September because of my son), but I've fell in love with the game... I've benefited immensely in my game by playing against the forge AI in booster draft and sealed deck.
This is a great project and I'd love to contribute. One problem is that the code base is a bit too large to grasp all at once, and as a new player I don't know much about various formats like EDH, or cube, or quest mode, or gauntlet, etc. Nevertheless, I feel I could and would love to contribute.
What I feel I could easily contribute that would help the most players get started is to document the code. I'm not speaking about the method documentation (many times, there's no need for it except to document a contract's boundary cases). I'm speaking about module/package documentation of the style: "This section of the code does this. It interacts with that other package via these classes. If you're looking for this, you'll find it here (or there...)" For instance, it took me a while to find the .txt file that documents cards, and who reads it, and how they parse that info. Finding the class that loads the HQ and LQ pictures and patching it to only load, say, M15 and KTK because I don't play the other formats. A lot of the .txt files I've read are not self-describing - when it would be so easy to make it so. Etc. That kind of high-level information seems to be missing in the Forge SVN repo. When confronted with a new project, that's what most developers look for.
I haven't found (yet, and I've not read most of the code by far) anything resembling this. There's also no unit test. I'm really good at both those things and would love to start beefing up the code and helping out. I find it a great way to learn code for myself too, which is ultimately my objective.
So is anybody willing to share a bit of that knowledge with me and give me a boost on the path of Forge enlightenment? Of course, as any dev worth his or her salt, I can probably do that by myself by simply reading the code (it's a medium-size project). But it takes time and I don't have that much, so it would speed me up, and would also help write down info that's not readily knowable from the code (for instance, how the code evolved, or why some class is written in a certain way, or why functionality is split in classes/packages the way it is - usually for reusability with some part that I may not be aware of).
I'm turning on notifications for replies to this post, so just reply here or message me privately. Thanks.
This is a great project and I'd love to contribute. One problem is that the code base is a bit too large to grasp all at once, and as a new player I don't know much about various formats like EDH, or cube, or quest mode, or gauntlet, etc. Nevertheless, I feel I could and would love to contribute.
What I feel I could easily contribute that would help the most players get started is to document the code. I'm not speaking about the method documentation (many times, there's no need for it except to document a contract's boundary cases). I'm speaking about module/package documentation of the style: "This section of the code does this. It interacts with that other package via these classes. If you're looking for this, you'll find it here (or there...)" For instance, it took me a while to find the .txt file that documents cards, and who reads it, and how they parse that info. Finding the class that loads the HQ and LQ pictures and patching it to only load, say, M15 and KTK because I don't play the other formats. A lot of the .txt files I've read are not self-describing - when it would be so easy to make it so. Etc. That kind of high-level information seems to be missing in the Forge SVN repo. When confronted with a new project, that's what most developers look for.
I haven't found (yet, and I've not read most of the code by far) anything resembling this. There's also no unit test. I'm really good at both those things and would love to start beefing up the code and helping out. I find it a great way to learn code for myself too, which is ultimately my objective.
So is anybody willing to share a bit of that knowledge with me and give me a boost on the path of Forge enlightenment? Of course, as any dev worth his or her salt, I can probably do that by myself by simply reading the code (it's a medium-size project). But it takes time and I don't have that much, so it would speed me up, and would also help write down info that's not readily knowable from the code (for instance, how the code evolved, or why some class is written in a certain way, or why functionality is split in classes/packages the way it is - usually for reusability with some part that I may not be aware of).
I'm turning on notifications for replies to this post, so just reply here or message me privately. Thanks.