a journal sharing my experiences and growth
home // facebook // instagram

Thursday, 20 March 2014

Productivity


Lately I've been working on a project with two of my classmates. We are working with iPython and implementing functionality to allow the user to manipulate a small turtle with simple commands. It is meant to be a tool to learn/teach programming (as mentioned in my last blog post). 

I found that the last two weeks have been the most productive. Our professor (or "client", if this were a work situation) clarified some steps we need to take and this speeded up our progress a lot. We had made some wrong assumptions about some of the features and there was some confusion in what we were expected to make and this had caused some stalls in development. Previous to this, even though some significant time was spent on the project, I feel our productivity was really lacking (unfortunately, time does not equal progress). 

As for comparing specific productivity per session. I found nearly all sessions to be really productive lately (both pair programming and individually working on the project). We have three ways of working on the code lately. 

One is pair programming, where we both try to figure out how to solve a problem (it may fixing a particular bug, or implementing a new feature). I find this to be a good way to program in some situations, such as delving into a new part of the code (writing a python file for the first time), as well as when two people have the same problem fresh in their head and they both have ideas to implement/fix the problem. Working together can get the problem fixed more quickly. It's also much quicker for us to spot little syntax mistakes.

Another thing we have done is when we had a a bug that both were interested in fixing was open two computers and both work on the bug trying different things to fix it. I found this interesting, as we are both able to implement our own solution, and make comments to each other about what is working and what is not. 

We have also split up the tasks and had two people working on two different tasks in the same room and at home at the same time (communicating via Skype). When we are in the same room and have a problem it is easy to show the problem to the other person and get their input and it may help solve the problem more quickly, this is double edged. It get's the problem solved more quickly, but it also may derail the other person from the task they are on, and they can lose focus and become immersed in the other task. This is the plus side of working at home, we are able to work separately on two tasks/files without the huge chance of being brought out of focus by the other person (although we do share our problems via Skype still). At the same time, it is easy to lose communication and be on the same page. At one point two of us were working on two different files, one was in python, and it was supposed to print some commands certain format. The other file (javascript) was to read the commands printed from the python script and do certain things with it. There was some miscommunication and the person writing the python script was doing the print as one big string (as they expected the javascript to be accepting on one string), while the javascript person thought the print command would come as many printed strings (rather than one) and the javascript person ended up working on getting the javascript to merge the many strings it was expecting into one. Had we both been in the same room we would have explicitly said what each were expecting to do, rather than have it get "lost in translation" through texting or Skype. 

All in all I found every coding session to be productive for separate reasons. Lately we have clear(er) goals in site, so we are making progress into implementing those goals. Previously I felt like we were just swimming in code that we did not understand.

Friday, 7 March 2014

IPython Development

Currently I am working (with two others) on an open source piece of software, IPython. IPython is an interactive shell (which you can run on your browser) used for interactive computing. It allows you to code in Python, in a quick and easy way.

The project we are working on is created a way for IPython to recognize a set of "turtle" commands and, using these commands, draw a turtle on the screen. It is meant to be a tool for learning simple programming.

One of the first tasks given to us was meant to give us a "leg up" later in the project. Doing it the expected way would have helped with what followed. Unfortunately for us we did it another way. I find this to be a funny thing about self-directed work and being "productively lost." We were able to do the task described, but in a completely different way than others did it, and than we were supposed to do it.

The task itself was to count and display the number of lines in the output. We did that. We found a function that edited the data outputted, split it into an array of lines, counted those lines, and appended that to the data.

The next task given to us involved outputting some html in the same area (where the line count feature is). Naturally we tried adding some html to the same area of code that we had previously edited.
We tried various things to get html in this area (manipulating this particular function), before finally going to our instructor for help. This is where we (my team and our instructor) discovered that we had done the original task (line count feature) in a different way (basically, we had manipulated the wrong function). Our task remained the same, get something other than just the text to output on the screen. In our case, we wanted to get an html canvas in the output area.



I believe that if we had gone back and did this line count feature the right/expected way, the coming tasks would have been be easier (in fact, I do eventually go back and re-do the first task, as a learning tool).

We were not sure where to go at this point (to get the html displayed) so we tried to implement our own mime type, a disaster. I'm not going to get too detailed but we spent many fruitless hours looking at how we could implement our own mime type, and eventually get a turtle showing on the screen using this method. We stared at many different files that use mime types, and took steps to code our own mime type, but eventually we scrapped all this after talked to both our professor and project leader.

To be continued...