Being a relatively mature two-person group, we have been helped greatly by Pair Programming. Since Alan and I know each other well and have worked together on a number of different projects in the past, we are able to communicate effectively and are not afraid to voice our opinions. Working together to solve problems has also led to more eyes on code and finding bugs that we might normally have glanced over, which could have come back to haunt us in future development.
That being said, pair programming may not be as effective as it is for our group when used with newbie student groups. We think that comfort and group interactions play the largest role in successfuly pair programming. When pairing new students together in an introductory lab, their comfort level may not be high enough to facilitate a high level of productivity.
Another major factor in pair programming is the environment, and how that shapes development. In our case, we're working in my room with dual monitors that can easily be seen by both team members. Often students may be working from one laptop or a single monitor, which can make it difficult for team members to have eyes constantly on code. Additional monitors, we feel, are necessary for pair programming to be successful.
One quote I came up with during one of our meetings was: "Incompetency can be alleviated through communication and comfort." This doesn't necessarily hold true for all projects, but I think that those two concepts (communication and comfort) can set projects on the right track. Of course there are other factors that can determine the success of a project; primarily, enthusiasm for the work. I won't delve into it too much, but if pair programming inspires the group to come together and solve problems than it certainly is a boon to productivity.
I posit that a pair of programmers is only as good as its weakest link. That is, if oen member expresses low interest, both members suffer. With a group of programmers that express high interest, their productivity is also high and could be multiplied.
There are some stumbling blocks to pair programming. I've highlighted a few of them: personality, comfort, work ethic, and interest. Another is the maturify level of the students or members undertaking the project. I posit that higher maturity levels will naturally increase productivity. The question is mainly how to inspire maturity in younger students, especially when they may or may not have met each other. Thoughts on this would be good.
Moving on to collective code ownership! Collective ownership essentially drives all programmers to contribute to all facets of the project. This is essential to many projects but is crucial for student projects. In the professional world, developers may have specialties and thus may be better suited prioritizing their work towards certain areas, reducing the need for collective ownership. Student projects may or may not have group members that have special talents, and thus collective ownership can result in an overall better project.
This is demonstrated to a good degree with Trivioid. While Alan and I do have different areas of expertise, we are certainly not discouraged from making changes to or improving each other's work. Unit testing can be a huge boon to collective code ownership. If developers create effective unit tests, a suite can be created that can make sure code changes still allow for proper building. Continuous integration can also be an essential tool, which, when used in conjunction with collective ownership, can make development more efficient.
Monday, April 18, 2011
Wednesday, April 13, 2011
Moving forward
Just some notes for the upcoming iteration:
We are currently at the stage where all of the clients are waiting in the lobby for the host to start the game.
When a host player presses the "start game" button:
1. the host must stop broadcasting its game information via UDP to requesting clients
2. the host send a TCP notification to all of the clients that the game will start.
3. the host closes current activity and opens a new activity for the actual game.
While a player is in a lobby, he/she is updated with the player list. Trivioid is waiting for a TCP packet from the host player that the game will begin. When that TCP packet is received, the lobby activity is closed and a game activity is opened containing class ClientGameController. ClientGameController is a wrapper class for the client end of the game. It contains information like (1) the name of the game (2) the host of the game (3) the type of game (4) number of players (5) team information (6) score information (7) the open TCP connection over which game information is exchanged. ClientGameController contains several methods including parseGamePacket(), sendGamePacket(string data), etc. When the lobby is exited and the new game activity starts, a new ClientGameController is created. Upon creation, it attempts to establish a TCP connection with the host and stores that connection information. In the activity, methods are called like ClientGameController.sendGamePacket("C"). The ClientGameController then sends the following string down the TCP connection to the host "TRIVIOID - ANSWER STRING - |!|playerIP|@|timeDifference|#|C|@@|"
When the host exits the lobby, it opens a new activity to manage the new game. A new class is created by this activity; HostGameController. HostGameController is a wrapper for an arrayList of HostClientConnection. A HostClientConnection is a THREAD managing the TCP connection between the host and a particular client. So, the host activity contains a HostGameController with various functions like openPolling(time T), closePolling(time T), endGame(). HostGameController contains the game information, see above, along with the list of HostClientConnection, one for each of the clients connected with the host. For example, the host's game activity will call HostGameController.openPolling(time 19:34:21). This would run a for-each loop over the arrayList of HostClientConnection:
forEach(HostClientConnection conn : connectionsList) {
conn.openPoll(19:34:21);
conn.startListening();
}
openPoll(Time theTimeOpen) in HostClientConnection pushes the following string down the TCP connection "TRIVIOID - POLL OPENING - theTimeOpen"
startListening() in HostClientConnection waits on a response from the client or closes when the closePolling() method is called.
hope this makes some sense, Derek.
We are currently at the stage where all of the clients are waiting in the lobby for the host to start the game.
When a host player presses the "start game" button:
1. the host must stop broadcasting its game information via UDP to requesting clients
2. the host send a TCP notification to all of the clients that the game will start.
3. the host closes current activity and opens a new activity for the actual game.
While a player is in a lobby, he/she is updated with the player list. Trivioid is waiting for a TCP packet from the host player that the game will begin. When that TCP packet is received, the lobby activity is closed and a game activity is opened containing class ClientGameController. ClientGameController is a wrapper class for the client end of the game. It contains information like (1) the name of the game (2) the host of the game (3) the type of game (4) number of players (5) team information (6) score information (7) the open TCP connection over which game information is exchanged. ClientGameController contains several methods including parseGamePacket(), sendGamePacket(string data), etc. When the lobby is exited and the new game activity starts, a new ClientGameController is created. Upon creation, it attempts to establish a TCP connection with the host and stores that connection information. In the activity, methods are called like ClientGameController.sendGamePacket("C"). The ClientGameController then sends the following string down the TCP connection to the host "TRIVIOID - ANSWER STRING - |!|playerIP|@|timeDifference|#|C|@@|"
When the host exits the lobby, it opens a new activity to manage the new game. A new class is created by this activity; HostGameController. HostGameController is a wrapper for an arrayList of HostClientConnection. A HostClientConnection is a THREAD managing the TCP connection between the host and a particular client. So, the host activity contains a HostGameController with various functions like openPolling(time T), closePolling(time T), endGame(). HostGameController contains the game information, see above, along with the list of HostClientConnection, one for each of the clients connected with the host. For example, the host's game activity will call HostGameController.openPolling(time 19:34:21). This would run a for-each loop over the arrayList of HostClientConnection:
forEach(HostClientConnection conn : connectionsList) {
conn.openPoll(19:34:21);
conn.startListening();
}
openPoll(Time theTimeOpen) in HostClientConnection pushes the following string down the TCP connection "TRIVIOID - POLL OPENING - theTimeOpen"
startListening() in HostClientConnection waits on a response from the client or closes when the closePolling() method is called.
hope this makes some sense, Derek.
Wednesday Scrum and Pair Programming
The biggest changes we decided to make today are a switch from UDP for game joining to TCP. This will make the server joining code more robust. However, it is more difficult to code. Instead of broadcasting UDP packets willy-nilly, we need to coordinate between the host and client some handshaking.
However, this will help in the long run as the games themselves will rely on TCP connections for communication. We are using the same TCP approach that our previous project, IRLHvZ, used.
Currently, we can host a game with and without passwords. This opens a lobby for the host that lists the players in the game. Clients can refresh the list of current open game lobbies. They can see if they are password protected or not. They can select which lobby to enter and are prompted to enter a user name (and password when applicable). When a player enters a lobby, the host of the lobby is notified and the player list is updated. The player is presented a lobby screen showing the current players in the lobby and the general game information. The clients can also choose to leave the lobby. This brings the client back to the main menu. It also updates the host about the client leaving, updating the list of players. The other players in the lobby are also notified of this change.
What we need to do in the next sprint is implement an actual game.
We did not complete as much as we wanted to this sprint. This was due partially to traveling by both Derek and myself. However, a good portion of this setback was that I was bedridden for all of last week. Since this sprint was primarily pair programming, little work was done while I was sick.
Today's work was done from 7:00pm to 9:00pm in Derek's room. He was driving and I was navigating. Again, this works because he knows the ins and outs of Android programming and I am more familiar with network programming. I can tell him what to type, and he knows where to type it. As a result, I am getting better at android programming and Derek is getting better at network programming.
However, this will help in the long run as the games themselves will rely on TCP connections for communication. We are using the same TCP approach that our previous project, IRLHvZ, used.
Currently, we can host a game with and without passwords. This opens a lobby for the host that lists the players in the game. Clients can refresh the list of current open game lobbies. They can see if they are password protected or not. They can select which lobby to enter and are prompted to enter a user name (and password when applicable). When a player enters a lobby, the host of the lobby is notified and the player list is updated. The player is presented a lobby screen showing the current players in the lobby and the general game information. The clients can also choose to leave the lobby. This brings the client back to the main menu. It also updates the host about the client leaving, updating the list of players. The other players in the lobby are also notified of this change.
What we need to do in the next sprint is implement an actual game.
We did not complete as much as we wanted to this sprint. This was due partially to traveling by both Derek and myself. However, a good portion of this setback was that I was bedridden for all of last week. Since this sprint was primarily pair programming, little work was done while I was sick.
Today's work was done from 7:00pm to 9:00pm in Derek's room. He was driving and I was navigating. Again, this works because he knows the ins and outs of Android programming and I am more familiar with network programming. I can tell him what to type, and he knows where to type it. As a result, I am getting better at android programming and Derek is getting better at network programming.
Tuesday, April 12, 2011
Some minor changes today
Messed with the layout a bit and added some nifty images and button work. Nothing too fancy, just did a little bit of work while bored in ECE.
Tomorrow we'll hopefully have some big stuff...
Tomorrow we'll hopefully have some big stuff...
Sunday, April 10, 2011
Looking Forward to This Week
We'll be finishing up pair programming for this sprint. I hope we can devote anywhere from 4-8 hours before Thursday's meeting. I would like to get full TCP communication implemented for the joining of a game instead of UDP to make the application more robust.
In terms of how the project is shaped by techniques used, it's very tough to gauge student work because (at least in our case) there aren't many set times where we can both meet to work. That being said, in larger groups or more structured projects, a time could be set aside once or twice a week to effectively get the group together and complete tasks.
Pair programming is working incredibly well for us and has made us the most effective. I think that for many student projects, using pair programming with small tasks is a more effective development technique. It makes sense because it combines student experience and allows two people to look at the same code and share ideas.
In terms of how the project is shaped by techniques used, it's very tough to gauge student work because (at least in our case) there aren't many set times where we can both meet to work. That being said, in larger groups or more structured projects, a time could be set aside once or twice a week to effectively get the group together and complete tasks.
Pair programming is working incredibly well for us and has made us the most effective. I think that for many student projects, using pair programming with small tasks is a more effective development technique. It makes sense because it combines student experience and allows two people to look at the same code and share ideas.
Sunday, April 3, 2011
Pair Programming Results
We have finished the client/host discovery. Name and password checks are implemented. Simple connections for the client and host are established like would be in a game. The system seem very robust, we have yet to see any force closes due to the socket programming. We have been having some issues with the display layout, but these are aesthetic problems, not functional.
The host can start a game along with a password and player limit.
The client can refresh and display a list of games running on a subnet. Upon clicking a game, the user is prompted for a username (and password if the game depends on it). After inputting both and clicking join, the client send a message to the server. The server maintains a list of clients which is updated when a client joins.
We are satisfied with the functionality we have accomplished today.
We will work on the game functionality this week.
Pair programming was both helpful at times and frustrating at times. For the client server negotiation, pair programming was very productive. I have a more clear understanding of the handshake we are using from server to client. Derek is much better at navigating the application to add in the functionality. Pair programming was frustrating when working out the aesthetic problems, mostly because I dont care and derek wants every pixel to line up.
We worked from the previous blog update to the posting of this blog update. It was done in Derek's room using three PCs. Derek drove using dual monitors. I navigated using my laptop to look up things. Derek's desktop was used occasionally for reference.
The host can start a game along with a password and player limit.
The client can refresh and display a list of games running on a subnet. Upon clicking a game, the user is prompted for a username (and password if the game depends on it). After inputting both and clicking join, the client send a message to the server. The server maintains a list of clients which is updated when a client joins.
We are satisfied with the functionality we have accomplished today.
We will work on the game functionality this week.
Pair programming was both helpful at times and frustrating at times. For the client server negotiation, pair programming was very productive. I have a more clear understanding of the handshake we are using from server to client. Derek is much better at navigating the application to add in the functionality. Pair programming was frustrating when working out the aesthetic problems, mostly because I dont care and derek wants every pixel to line up.
We worked from the previous blog update to the posting of this blog update. It was done in Derek's room using three PCs. Derek drove using dual monitors. I navigated using my laptop to look up things. Derek's desktop was used occasionally for reference.
Back Updates
Some updates that we failed to blog about:
March 30:
I scrapped the kryonet client/host approach and put together my own UDP client/host discovery method. Tests show it to be working on devices other than mine (which is one of the problems with kryonet). I only have the client code working on the phone because I only have one phone to develop on. The server code is running on my desktop. I think we will be able to save some overhead by switching from kryonet. I updated the code to subversion, derek will implement the server code in the phone project this weekend.
I worked for about 2 hours. Felt really good about working at home on my desktop. The dual monitors make a huge difference for me. I am glad we are stepping away from kryonet. While it would have been nice if it made client/server code easier, I like to avoid using other peoples libraries.
March 31:
Had a scrum before meeting with Prof Sherriff. Discussed the goals for this sprint. We should have the client/server discovery done by the end of the weekend. By the end of the sprint (next weekend), we should have implemented a playable game.
I will be traveling this weekend and will not be home until early sunday morning. We will pair program that day to finish up client/server discovery
March 30:
I scrapped the kryonet client/host approach and put together my own UDP client/host discovery method. Tests show it to be working on devices other than mine (which is one of the problems with kryonet). I only have the client code working on the phone because I only have one phone to develop on. The server code is running on my desktop. I think we will be able to save some overhead by switching from kryonet. I updated the code to subversion, derek will implement the server code in the phone project this weekend.
I worked for about 2 hours. Felt really good about working at home on my desktop. The dual monitors make a huge difference for me. I am glad we are stepping away from kryonet. While it would have been nice if it made client/server code easier, I like to avoid using other peoples libraries.
March 31:
Had a scrum before meeting with Prof Sherriff. Discussed the goals for this sprint. We should have the client/server discovery done by the end of the weekend. By the end of the sprint (next weekend), we should have implemented a playable game.
I will be traveling this weekend and will not be home until early sunday morning. We will pair program that day to finish up client/server discovery
Subscribe to:
Comments (Atom)