About Us

[hallister]

Prior to breaking into teams, I think it would be a good idea to get a little background information. This is key, since we do not want a sub-team of folks who have never used Python :smiling_imp:.

Furthermore, it would be a good idea to garner everyone's interest. But let's keep this super simple and reduce interests to the follow (large) topics: GUI, Servers, Databases and Testing. Let's list two of the aforementioned topics to avoid getting 12 people in one topic area and 4 in another.

Name: Justin Python: 10+ years Interests: Servers, Databases

[cawaltrip]

Name: Chris Python: 1 year Interests: Networking

I should also note that I'm interested in testing and test driven development as well, but I feel like that is more incorporated into whatever team I am in.

[bcumber]

Name: Ben Python: No experience. Interests: Servers, Databases. Computers are fun.

[SamuelFoster]

Name: Sam Python: No experience (1 month) Interests: Servers, Databases

[andyleejordan]

Name: Andy Python: 2+ years Interests: Servers, Testing

Experience: devops/automated testing, message communication, databases, AI

[rangera]

Name: Ranger Python: A couple weeks Interests: All of them (including GUI, you slackers)

GUI note: actually already working on it and have a star system mostly drawn, I could probably do most or all of it myself, unless others actually want to do GUI.

[hallister]

It should be noted that GUI isn't just drawing, GUI's must be both state-aware, and state-responsive. In other words there has a be a layer between the GUi and the Communication protocol that translates the state object into actions that the GUI must perform.

Perhaps I should have been more encompassing with Client rather than GUI but I didn't want to cause confusion... and I did anyway.

And the Testing category shouldn't (just) be thought of as TDD. A test developers workflow may be: Try to break something Find out why it broke Write a Unit Test for the particular set of circumstances that will cause it to break Send it back to Developers to fix it

That's a basic workflow for a Software Engineer in Test.

[rangera]

I would suggest that client and GUI be separate, unless what I'm thinking of as client would be communications. In my mind client would be the process that is running, possibly tracking the state (though not strictly necessary, the whole state could be on the server, depending on our architecture) and would be responsible for decoding the communication protocol (json or other wise) into what it means and what functions need to be called to change the state and graphics (or, architecturally it might be that the state tracker calls the graphics change).

As far as my interpretation of the requirements of the GUI. I am basically building it as a library that the main module would call such as SetDiplomatic( planet=143, newvalue=1). This "library" would be defined so that client/communication programmers would be able to use it and know what they need to pass it.

[hallister]

@rangera the GUI and Client would be separate (in the sense that they aren't the same thing) but the Client and GUI would directly communicate with each other, whereas the server and client would communicate over a network layer. Thus, the Client/GUI implementations need to be closely related, whereas Client/Server is less intertwined.

[thom5468]

Emeth Thompson Python: I've done one project in python and don't remember it. Interest: undecided

[Greg-Donaldson]

Greg Donaldson Python: A year and a half Interest: Undecided

[harr6176]

Sean Python: I've dabbled a bit Interest: Undecided

[cawaltrip]

I'm going to go ahead and close this, just because we've got the Group Experience issue open and the Sub-Teams issue open.