Wednesday, November 5, 2014

HackProp 2: Paint Partners

Hack Prop Title: Paint Partners



Description:

A collaborative drawing tool made in Python using PyGame as the GUI, and homemade networking code borrowed from Hack1. Ideally would be able to be used as a teaching tool, by limiting the teacher to be the only one able to draw.

Libraries:

The only library we need to be using is PyGame.

Upstream Repository:


Hardware:

The only hardware we need is the Raspberry Pi, Display, Input Devices

Team:

I will be working with mstubinis for the project

Project Milestones:

  1. Develop non-server side code to modify and display an image, load config data, and prepare text fields
  2. Develop server side and networking code to send and process information: pixel data, chat messages, client connecting and disconnecting from server, admin issuing commands through console
  3. Finish development tasks, build documentation, distribute upstream.

License:

GNU GPL2.0

Upstream Mentor:

Currently none, but the project isn't really different from our last one in terms of what needs to be done.

Final Thoughts:

This project should be an interesting build off of the work that was done on Hack 1 and should serve as a cool project providing a service.

Tuesday, November 4, 2014

Adventures in being a Teaching Assistant

This is probably the first in a short series on my perception on being a Teaching assistant. Hopefully this will be a good place to give my thoughts for a few different thoughts I have from being on both sides of taking a class.

I am a teaching assistant for an intro level programming course at RIT. I have been one for almost a year now and I have become accustomed to the way the teacher I help teaches, the kinds of questions the people come up with, and certain pitfalls from of early level programming. That said, the most difficult thing is remembering what a person should be expected to know and what they probably don't know yet. For example, I had a student ask me a question, which I had to stop and think of the answer for a minute or two, because my normal go to method hadn't been covered by the course. I feel like that is probably the biggest issue in teaching in general, and one of the biggest to overcome in becoming a good teacher.

Another interesting thing is seeing the difference in proficiency that you run into across multiple people doing the same thing. I have a few students that I never need to say anything to because they already either know everything or just catch on quickly enough that they don't need help. On the other hand, there are students who don't quite seem to understand anything that the professor just went over and ask questions about everything. Of course there are also plenty that fall in between.

I think the biggest thing I have noticed is the different ways that students attend class. What I am meaning is, how are they handling class time. I can see in every student is different ways that I have been a part of class at one point or another. It really is eye-opening seeing yourself in the people you are working with and realizing that you were there at one point. Overall, I am enjoying my time and I have several students that are fun to interact with from day to day. I hope this continues for a while more.

Tic-Tac-Pi - Final Thoughts

This was the second project that myself and mstubinis did for the ADVFoss class. This one was overall a much simpler project, mostly because it was doing something that we both thought would be fairly simple from the get go. I personally didn't have an overwhelming amount to do since mstubinis took charge right away and knocked out the game code itself in fairly short order. That left me pretty exclusively in charge of getting everything packaged. I originally had the same issues that I did in when it came to packaging up PyTalk, but more on that in a minute.

What I'm most surprised by was the expediency with which mstubinis actually got everything together. He had me write some very simple resolution code and had me do the testing to make sure it was working, but otherwise, he pushed out everything else in the time between classes in the first week. After that, it was fairly slow until we had to package it up because we had already had everything finished.

For some reason, my laptop finds it impossible to build python eggs. This happens to be a fairly large problem when trying to push things up to PyPi. Naturally this means I needed to go elsewhere for my uploading needs, which the first instinct is to go to a lab machine. Problem is that the lab machines are fairly finicky when it comes to actually using python on them. I finally managed to find a work around using my roommates laptop because he has a linix partition on his drive. After moving over the files, the upload and registration was extremely quick.

Overall, I found this project to be a little lackluster since I personally didn't have a lot to do for the project and I hope that changes as we move forward into the third hack for the class.

Tuesday, October 28, 2014

A little behind on posts

This blog has been rather inactive, partly because of the lack of Community contributions that I have done, and partly because I just haven't been doing a blog post for every week. The real issue that I have with getting one put up every week is mostly not having anything to talk about. I am hoping to change out that paradigm for the future as my workload gets a little more involved. I will be adding discussion about what the class I am teaching assistant for as well as work that is going on with the current projects. This should make things a little more lively. I thank you for reading

RocPy Meet-up - October edition

We once again set out on our way to RocPy. This time without our illustrious leader, DeCause. This meant that we had a new set of carpool leaders. The only annoying thing about the carpooling was that it had started to lightly downpour. I normally don't mind the rain, but is a little disheartening just standing around waiting in it. Regardless, we left for the University of Rochester right on time. The car I as riding in was full of complete strangers to me, so conversation was rather non-existent.

Once we got to U of R, we made the long trek up to the 4th floor corner that is the ever drab home of the meet-up. We had a surprising amount of people there, not counting the merry band that was coming from the FOSS classes. One thing that I am learning is that public speaking is not the forte of many of the organizers for the meetup, which is a little surprising as they seem to be teachers. This was most prevalent in the first portion where they were going over Python in the news.

Following that, we got a rather lengthy lecture on how to bridge Python into other languages. Despite that being the main premise of the lecture, the only thing that I really came away from it regarding bridging Python with other languages is that Python is a very slow language. The actual bridging was sort-of glossed over. It was almost like a cooking show, with all of the bridging done before hand and just showing off the results of the bridging on sample code. Ironically enough, certain examples didn't actually prove to be that much better, namely the Haskell implementation.

The thing that ended off the meeting was another of the organizers talking about His Raytracer which was being implemented in Python. What I found to be most interesting was the justification being used to use Python for the program despite being so slow. "It can be used as a teaching tool, because it is easier to read." I find that to be a remarkable sentiment. While it is true that Python can be made to look like almost psuedocode next to something like C++, a decent amount of that can be written off as the person writing the code in the first place. Programming languages are like tools, you use the tool best suited to the job, and Python is not that language for something like this thought experiment.

Overall,, RocPy was far more dull this month than it was last month. I hope that the November and December meet-ups are a little more lively.

Monday, October 6, 2014

Hack Prop 1(2): Tic-Tac-Pi?

Hack Title - Tic-Tac-Pi


Description:

This will be a Tic-Tac-Toe board game made using PyGame and meant to be played on the Raspberry Pi. Ideally we want it to be able to be played by two people on seperate Pi's using networking, but we will have a Computer player regardless.

Libraries:

We will only really be using PyGame and writing our own net code.

Upstream Repository:

We will be pushing it to PyPi

Hardware:

We will be using the Raspberry Pi, a keyboard, a mouse, and an internet connection (for the newtowrking).

Team Members:

I will be working on mstubinis for this project.

Project Milestones:

  • Get a working Server and Client application
  • Set up base game using PyGame
  • Integrate client with game
  • Package up the game

License:

We will be going with the MIT license for this project.


Final Thoughts:

Since neither of us is really all that familiar with networking in general (mostly due to the GDD program offering little inside the major itself), it will be interesting working on the subject. Even if we can't get it working, we always have the regular game to fall back on. Here's hoping!

Advanced FOSS Guest Speaker - Google

During class on Thursday, we were greeted by a very special guest that DeCause had asked to come down to talk with our class. As it turned out, Google had been at the Career Fair and doing interviews and such. While they were there, DeCause asked one of them to swing by our class and talk to us if they were able. To our good fortune, they were able to do just that. I am deeply regretful that I don't remember the man's name. It was a truly enlightening talk that helped to really put perspective on what I was doing and working towards for the past few days.

The man started off by introducing himself, telling us what he did at Google and some things that he worked on. Right away I could tell that the man far outdid anything that I even thought about doing for a job. After introducing himself he asked us if there were any questions that we specifically had for him. We chose to ask him about what it was like working at Google and what this 20% work was. As it turns out, while working at Google, you have projects that you choose to work on for a main project and a secondary project that you do sort of on your own time.

Afterwards, DeCause asked a few simple questions as it related to the Advance FOSS class. The main important questions were the use of file revision systems and the use of IRC channels for communication. While I never doubted that it was used, it was interesting to see the reasoning behind their use.

The last thing we asked about was how it was that he managed to find himself working at Google and if he would ever think about leaving. He told us about how he wasn't exactly the best student, though far above my level, and he more or less lucked into getting internships at Microsoft and Apple, which gave him the chops to be put up for consideration by Google in the first place.

Overall, I greatly enjoyed the talk. It was slightly disheartening to see just how far I am from being a competent hacker by any stretch of the imagination, but it has also given me some inspiration to try that much harder in the upcoming future.