Weekly Blog Post

So this is part two of my two-part HFOSS class reflection and I’ll focus on talking about contributions to FOSS projects, getting used to a FOSS OS and some of my experiences with working with the XO laptops this semester.

I left off the last blog post at around the time we started to transition from just learning about FOSS culture to actually contributing and doing in-depth analysis. I contributed code to the course website after filing an issue with link colors. I had to do some really odd workarounds to make my contributions on a windows environment (plus I couldn’t test my changes on my machine!) but I eventually got through it with the help of ryansb and got my fix in. It got accepted, and pushed to the master branch of the repo and the change is now live! After that bugfix, I participated in a group project to analyze the Tahrir project (Fedora’s badges) and we did a great deal of analysis on their git repo. We mainly focused on which contributors were the most active, who contributed the most, and how the project developed from it’s initial commit to it’s “completed” state (I use quotes for the word completed because it’s an ever-evolving thing, but it’s fully functional at the moment).

A few weeks later I started looking into Fedora spins and eventually got a Cinnamon spin of Fedora installed on my desktop as my default environment. I’m still getting used to it, but it’s definitely a nice change! More currently, as a class we’re just starting to wrap up our activities for the XOs. The laptop hardware has presented us with some optimization issues, and it’s pretty difficult to get our vision to run on the hardware but we’re working on it. We also ran into some issues with the goals of our project. It appears that the intention of the game that was presented in the design document didn’t line up with the goals of the 4th grade Common Core curriculum, so we’re going to have to do some retroactive work to get it up to snuff.

Overall the class has been a super positive experience, but the majority of the “value” I’ll be getting out of this class will probably become much more apparent once I graduate and start working at my full time job!

Weekly Blog Post

HFOSS Weekly Blog post!

Since I don’t think I’ll have a whole lot of useful information to post this week or next regarding the in-class discussions (besides maybe a detail or two) I think it would be grand for me to do a two-part blog post with a brief reflection back on the semester in HFOSS.

So I came into this class with basically no open source experience. I had heard a lot about it, and I was active on some projects hosted on GitHub, but besides using Fedora when I was on co-op (but only as a Window’s clone, not as a contributor) I had basically no FOSS experience. I wanted to join this class because I know that having FOSS experience under my belt, especially in a supportive academic environment would be spectacularly helpful going forwards. I was (rightfully) very intimidated by the class, and even though it was advertised as an intro level course, there was still a lot of sink-or-swim to the class. The first few weeks were a lot of getting myself accustomed to the terminology and practices of FOSS development, and how they differed from my experiences with private software engineering, or class projects. I attended BrickHack as a part of fulfilling my meetups requirement, and that was a really great opportunity to meet with Remy Decausemaker, a RedHat employee. He gave me a lot of great info about what I can expect culture-wise when working at RedHat, and did a great job of making the intimidating culture of FOSS seem a little more personable. Overall my first few weeks of HFOSS involved getting over my initial disinclination for FOSS culture, and getting accustomed to the lingo and practices. It’s a spectacularly different method of software development that deviates heavily from a traditional corporate structure (achievement-based rather than employment level-based) so it’s very cool to see the alternate approach.

Next week I’ll talk a bit more on the contributions I made to FOSS repositories, my experience with acclimating myself to Fedora, and I might touch on my frustrations with the usage of the XOs in this course!

HFOSS Weekly Blog post!

HFOSS Weekly Blog Post

This week my team is focusing on making progress on our Sugar Activity. With only a month to go before graduation, this is one of many big projects I have on my hands, but I’m doing my best to allocate the necessary time to keep up with the project. My primary contributions at this point are getting together the art assets we need to have our visual elements to our activity. Wilfred is working on getting some base functionality to our activity, and Justin is focusing on our documentation (our sugar wiki and github page presentations for the most part). Once I have all our necessary art assets illustrated and digitized, I’ll be adding them to our github repo so that Wilfred can pull them into the game project and we can start to work on improving our visual interface!

A few weeks ago I finally got Fedora up and running on my PC at my apartment and I’ve been having a lot of fun working with the new operating system and tuning the environment to my liking. I’ve still got a long way to go before it’s just as I like it, but I’m getting happier and happier with Fedora as an OS every day. In the interest of helping to make this post useful to any new Fedora users who may stumble across it, I think I can speak a little bit on the functionality of DNF.

DNF is a package manager (see my older blog post here to learn about package managers) on Fedora that lets you easily download new software packages. The command to download a package is simply “dnf install <package name>” which worried me a bit, because what’s preventing someone from creating a malicious package called “foo” then advertising it as this new, hot, must-have software package? If you’re just blindly installing things with DNF you could wind up with some undesired programs. They’re easy enough to remove if they’re not intentionally malicious, BUT there’s a better way to head this problem off. DNF has two really useful commands that you can use to help determine what you’re downloading, and to help find new packages to download. “dnf info foo” will tell you a bunch of information about the software package named “foo.” This info is written and maintained by an official fedora contributor, not the package creator (to prevent a malicious coder from making the description “this package makes your computer run more good” or something that might bait someone into downloading it). Also, “dnf search <keyword>” will search for all software packages that fedora contributors have analyzed that include the keyword in the name or project description. This can be handy if you’re looking for image editing software, browser extensions, games or new desktop environment tools.

HFOSS Weekly Blog Post

HFOSS Weekly Blog Post: Week 13

So this week in class we had a lot of discussion about GPG (Gnu[Gnu’s Not Unix] Privacy Guard) Keys. GPG Keys allow a user to encrypt and sign data, making the data private, as well as acting as a method to ensure that the source of the data is legitimate. A user can generate their own unique (Note: TECHNICALLY two people could receive the same key, but the number of possible keys that can be generated is so astronomically large that it’s basically not even worth considering this possibility) key that they can use to sign their documents, and create a verifiable legitimacy on their end. GPG Keys can provide a very useful service for individuals who need these sorts of features, but isn’t a necessity for users who don’t need this formal verification.

While the digital key is useful once it’s established which key belongs to which user, the process of actually verifying a key is one of the most important steps that gives the key its “value.” This particular element of GPG keys is what I want to focus on for this blog post.

I will happily make an argument for the social aspect of computing and FLOSS collaboration whenever necessary, and in all honesty I have a handful of relevant points to make in support of that position readily available, but I don’t see this culture as a particularly social one. It’s an inherently digital practice that links people together, but the majority of the communication between collaborators is, from what I’ve seen, equivalent to the discussions I’ve had with former bosses at tech companies. It’s purely in pursuit of project completion, and not particularly personal. This, to me, isn’t what I would consider a social interaction, and it seems to make up the majority of interpersonal communication within the FLOSS community. Given this objective-oriented approach to conversation and discussion, I think the idea of a key-signing (although, no keys are being signed, just verified) event is hilariously out of place in the context of FLOSS culture. My intention isn’t to poke fun at the community as a whole, but given the lack of personal communication (as opposed to project-focused communication) I’ve seen when examining the community architecture of a project like Tahrir I find the whole key verification process kind of out of place.

I don’t have any ideas for alternate ways of verifying a user’s key(s), but I think it deserves some thought, not in the context of trying to make key verification a less social task to make it fit in with the rest of the culture as a whole, but instead I think it would be prudent to make the culture more social. There are plenty of FOSS contributors with very social, public-facing communication channels like twitter and facebook, but I think that all those channels are still very internalized to the community itself. It’s not something I had ever come across before enrolling in this class, despite doing some cursory research on FOSS projects in preparation for my future career. I think creating a more social atmosphere for the community can be accomplished in a lot of ways – local meetups that new users are welcome to come along to (most importantly to make sure these spaces are welcoming to new users) are a great example. Hosting events to onboard new users onto Linux-based operating systems and demonstrating that it’s not as intimidating as movies and popular culture makes it out to be.

Again, I’m not sure I have any time or willpower to execute on these ideas at the moment, but at the very least I think it’s a good idea to get the discussion rolling in hopes that we can make the community as a whole more open to new users, because we all benefit from a larger userbase of contributing coders.

HFOSS Weekly Blog Post: Week 13

PyCut Design Document

So this week I spent a good chunk of time making my usual worrywort contributions to a collaborative project and set up a design document for our activity to make sure all team members are on the same page. I took some structure and layout from previous design documents I’ve written for other projects, but all the content is original. I’ll include the content of that document here in this blog post. It’s still a work in progress, but the majority of it is done here.

Game Overview

Game Abstract –

For Humanitarian Free and Open Source Software Development (IGME 582) jflory7, wilfrede and spg1502 are collaborating on making a logic-based activity, called PyCut, for the One Laptop Per Child XO laptops. Our activity is designed to encourage logical thinking by presenting its users with a puzzle about meeting the criteria of a needy customer at a pizza shop. Through interacting with the game, our hope is that the audience will develop and refine their logical thinking skills in an interesting and fun environment.

Learning Objectives –

New York State’s Common Core Curriculum for the 4th grade outlines various learning goals within the realm of mathematics and we chose to focus on 4.OA (Operations & Algebraic Thinking) unit 5, Generate and Analyze Patterns. This particular section calls on 4th grade students to be able to “generate a number or pattern that follows a given rule. Identify apparent features of the pattern that were not explicit in the rule itself.” This, in short, involves extrapolating data points from a limited pool of existing information. PyCut strives to help develop and solidify these skills through pattern recognition in the context of a game.

Game Context –

PyCut will take place in a pizza shop where a customer has placed an order for a pizza but has been very vague about the toppings they would like on it. The player has a limited number of attempts to get the pizza right before the customer gets frustrated and leaves the store.

Game Influences –

PyCut will take inspiration and logical puzzle development guidance from Logical Journey of the Zoombinis (1996) which features a puzzle entitled “Pizza Pass” in which the player must create a pizza for a hungry (and very picky) troll. We will follow a similar pattern for logical puzzle development to Pizza Pass and use it as our primary target for guiding PyCut.

Target Audience –

As an activity, PyCut will be designed for 4th grade students using an XO laptop. With this in mind, we plan to keep our visuals clear and simple to avoid providing too many distractions or unclear visual signals. In addition to this, we need to ensure that the logic and “rules” of the game are easy to understand and can be quickly picked up on.

Art Inspo –

TODO: Decide on an art style and aesthetic to follow. Collecting screengrabs of games, art, or assets we could use would be useful here.

 

Game Mechanics

Player Goals –

The player will take the role of a chef building a pizza that consists of up to five toppings for a picky customer, and aims to please the customer before they grow frustrated and leave the store. The player will have a limited number of attempts (limited by the number of available unused pizza crusts) to build a pizza that meets the customer’s requirements, and will try combinations of toppings in an attempt to please the customer.

Win Conditions –

The player will have successfully completed the challenge when the pizza they produce matches the requirements of the customer and the customer has happily left the store with their pizza.

Failure Conditions –

The player will have failed a challenge when they are unable to produce a pizza that meets the customer’s requirements in a limited number of attempts.

Player Controls –

The player will be presented with a number of buttons with icons representing various pizza toppings (mushrooms, cheese, pineapple, anchovies, pepperoni) and can toggle these individual ingredients on/off to display on the pizza before presenting the pizza to the customer by hitting a button that will say “cook.”

Gameplay Walkthrough –

An individual challenge would feature a blank pizza in front of the player, and a customer waiting to be served. They will add ingredients as they fit and cook it for the customer. Once the customer sees the pizza, they will give feedback to the player and let them know if the pizza is perfect (meets all requirements), if it has too few ingredients (all ingredients are correct, but there is at least one ingredient missing) or if the pizza is wrong (at least one ingredient doesn’t belong on the pizza). In the first case, the player will have completed the challenge. In the second case, the player must re-create the pizza, but try adding a new topping that didn’t previously exist until they get it right. In the third case, the player has to identify one or more ingredients on the pizza that the customer doesn’t like. A blank pizza (no toppings) and a fully loaded pizza (all toppings) are both possible options, as well as any combination of any number of the five ingredients.

 

Technical Process

Functional Basics –

Our first step will be developing a base-functionality version of the game. This will require a system of generating a customer’s predetermined order, allowing the player to toggle toppings on/off and submitting them for review, and comparing the player’s submission to the customer’s hidden order. Generating a customer’s order will be a simple task of randomly choosing true/false across five toppings. The pizza-creation process will involve implementing five buttons that toggle a boolean value for each topping, and the submission (cook) button will store those five boolean values and feed them into the component that will compare the user’s creation to the customer’s order. The comparison function will loop through each of the five toppings, and if it encounters a topping on the player’s pizza that isn’t present in the customer’s order, then the system will tell the customer to inform the player that they’ve used toppings they don’t like, if all elements on the player’s pizza are in the customer’s order but one or more are missing, the system will tell the customer to inform the player that they’re short on toppings, and if both the player’s pizza and the customer’s order are identical, the system will inform the user that they’ve completed the challenge.

Feature Development –

As a team, we will collaborate on all these features, and contribute to their development. It’s likely that an individual member of the team will guide the project and have a good understanding of the development objectives that need to be completed and will take on the role of guiding development for the rest of the team. Once basic feature functionality exists, we will work on expanding the project as time allows. In addition to functional features, our game will also require some art assets, which we can either generate ourselves, or pull from online resources.

Finalization –

Once our game is feature-complete, we can work on packaging the project for the XOs, as they are less powerful computers, we will be removing development features like debug output that describes game states, and ensuring all of our art assets are finalized.

Playtesting –

We have an opportunity to present our activities to actual 4th grade students later in the semester which will give us some feedback to work off of going forward, but we also have the option of presenting our game to our peers for review, bugtesting and analysis. During this period of development, we are likely to encounter bugs or unclear game mechanics that we will work to fix. This stage of development is likely to occur in conjunction with the finalization process, so we will be actively patching bugs and implementing art assets during this time.

Reach Goals –

If we are lucky enough to have the spare time to continue contributing to PyCut after we have a finalized, feature complete activity, we have two options for expanding our game’s scope. We can either create multiple difficulty levels (more toppings, less room for mistakes) or look into adding additional puzzles, again taking inspiration from the Zoombinis games. While the primary reach goal should be relatively easy so long as we adhere to good development practices, the second would only be possible if we finish up far ahead of schedule and want to try more puzzles. If we find that we would like to give that a shot, we might instead chose to make a new project for a second puzzle game, but at this time we’re focusing all of our efforts into the one puzzle in PyCut.

Art Assets –

As detailed above, we have two options here. As this is an educational product and won’t be used to generate income, we are protected under educational licences to use outside assets for our activity, but we are also free to generate our own art assets to use on the XO laptops. Depending on our progress in our development cycle and the artistic talent of our team, we will make a decision as a team at a later date on which route we would like to take.

PyCut Design Document

Quiz 2

1 Expand the following acronyms

  • IRC – Internet Relay Chat
  • FOSS – Free and Open Source Software
  • OLPC – One Laptop Per Child
  • DVCS – Distributed Version Control
  • FSF – Free Software Foundation
  • PR – Pull Request

2 What is the short, two-letter name for the OLPC computers used in the final project for this class?

XO

3 Please give the one-word name for the interface used in the OLPC computers

Sugar

4 What is the grade level at which we are targeting our OLPC applications

4th graders adhering to the Common Core curriculum

5 Briefly define each of the following instructional theories, giving the role of the instructor in each

Didactic Teaching – A teacher helps a student construct a basic foundation of knowledge on an individual topic, then once those skills, concepts and objectives are met, the student should have the required knowledge to expand what has been learned to any relevant problem. The teacher has an established knowledge which they impart on the student.

Dialectic Teaching – This tends to be a more discussion-based method of learning and requires participation by both the teacher and the student. By applying critical thinking in an attempt to make attacks against an argument, both parties can build up a knowledge base of how to better defend their argument and better understand their point of view. In social psychology this is similar to a concept known as attitude inoculation. In this case, the teacher and the student both provide equal contributions to the discussion in an effort to cooperatively strengthen an argument and learn.

Constructivist Teaching – This is a more hands-on approach to learning than the other two methods. This theory is based on the idea that as a learner is actively involved in learning about a subject (as opposed to passively listening to a lecture), the learner is more likely to better understand the subjects at hand. In this case, the teacher presents an objective for the student, and as the student actively engages with the problem and works to solve it, they develop the related skills that the problem requires.

6 Several elements are combined in different ways to form the various Creative Commons Licenses. Please match each shorthand given in the numbered list next to the description of that license element below

6.1) NC – C
6.2) SA – A
6.3) ND – D
6.4) BY – B

7 The presence of which license elements make a license “non-free” in the eyes of the FSF?

ND

8 Which license element is a copyleft?

SA

9 Name two projects which distribute a body of non-software, free culture data, and briefly name or describe the kind of data

The documentation for most FOSS programs, I believe the manpages for things like dnf would qualify as non-software data that helps the user understand the usages of the program.

Secondly, the documentation for a project like Fedora would count as well! There’s plenty of that data online that helps users understand how to operate their system.

10 We’ve discussed “the four R’s” as a shorthand for the freedoms attached to software for it to be considered “free” or “open source”. list or describe each (eg. if you can remember the “r” word just give that, if you cannot remember the term, but can describe the freedom involved, that also counts). Various “r” words are roughly synonymous for some of the freedoms, but we’re counting freedoms here, not synonyms so if you give two (or more) terms for the same freedom, it only counts once. For the purposes of this quiz, “remix” does not count as describing any of them

10.1) – Reuse
10.2) – Revise
10.3) – Redistribute
10.4) – Rework

Bonus:

False – so long as the GPL license is version 2 or 3

dunno but I’ll guess True!

True – technically legal

As soon as it comes into existence!

Quiz 2

Final Project Team Proposal

What is this?

This post serves as the project proposal for me and my team’s Humanitarian Free and Open Source Software DevelopmentFinal Project“.

In this project proposal, we take a look at the game idea we are looking at completing for this project, based on the New York 4th grade math curriculum. Our game idea is based off of a minigame from Logical Journey of the Zoombinis, a puzzle-solving educational game.

HFOSS Final Project: Zoombinis Pizza Pass minigame
Screenshot from 1996’s “Logical Journey of the Zoombinis” Pizza Pass level.

Continue reading “Final Project Team Proposal”

Final Project Team Proposal