Thursday, December 4, 2014

HFOSS Quiz 2

0) Expand the following acronyms:

  • a) FOSS
    Free and Open Source Software

  • b) OLPC
    Stands for One Laptop Per Child, could also refer to the actual devices distributed (XOs)

  • c) tl;dr
    Too Long; Didn't Read

  • g) LGTM
    Looks Good To Me

  • h) RTFM
    Read The Freaking Manual
  • i) PEBKAC
    Problem Exists Between Keyboard And Chair (User Error)
  • f) LOL
    Lots Of Ligaments

1) Define the following instructional theories:

  • a) Didactic
    Focuses on engaging the student in a consistent scientific and educational style

  • b) Dialectic
    Also known as the Socratic Method it engages the student by asking questions and having the student deduce the answer on their own

  • c) Constructivist
    A system of learning that focuses on real world applications and hands on learning

  • d) Multiple Intelligences
    The idea that there is not one general intelligence on its own but rather human intelligence is derived from different intelligences that focus on different skills. For example someone may have a high level of linguistic intelligence that gives them a proficieny in language and writing but may have a lower logical intelligence and have a harder time with logic problems.

2) Describe the role of the instructor in each theory.

  • a) Didactic
    This is a traditional teaching style popularized by the old schools of Europe wherein the teacher is the one with the knowledge who imparts it onto the students. Teachers simply lecture to engage the students who must then engage themselves in what the teacher is saying to absorb the knowledge

  • b) Dialectic
    This style of teaching is more about leading a student to a conclusion of their own rather than telling them what the answer is to one problem and having them deduce the answer to another. Herein the teacher's goal is not to impart knowledge but to facilitate learning by administering questions.

  • c) Constructivist
    Similar to Dialectic learning where the teacher is again more of a moderator than an authority figure in this theory the teacher would be providing a "playground" for the students to work in to derive their own answers to more physical problems. A teacher following this style of learning may impart a concept to the students and then follow that up with a hands on demo to extrapolate the concept.

  • d) Multiple Intelligences
    Under this instructional theroy a teacher would be concerned more with which intelligence they are targeting with their curriculum. The teacher would also be concerned with which other instructional theory would best fit that type of intelligence they are trying to foster. A teacher of physics may feel that the intelligence that are concerned with is Logical-Mathematical intelligence and follow a more Dialectic or even Constructivist method of teaching while a teacher of rhetoric would be using a strictly Dialectic method to target a more Linguistic Intelligence.

3) What are the three key aspects of a lesson plan?

A Basic Lesson Plan's three elements are:
  • Objectives
  • Methods
  • Evaluation

4) How does Sugar integrate and implement constructivist learning theory?

The Sugar interface is based around the concept of "doing" things. Programs are "Activities" and the interface is designed to be explored. It's not holding your hand telling you what to look at, it's providing resources and paths to additional resources. On top of that I'd argue that the internet can do much of what a teacher would be doing in a perfectly Constructivist environment; the vast amount of information provided is a great asset when learning anything new and since the OLPCs can connect to the internet that already makes them a great facilitator of information. The internet however does not provide any sort of moderation.

Bonus: Where can new Sugar users and contributors go to find out more information, ask questions, and get involved?

The Sugar Labs wiki
Any IRC channel friendly to Sugar such as:
  • #rit-foss @ irc.freenode.net
  • #olpc-help @ irc.freenode.net

Tuesday, December 2, 2014

Lit Review 2: Hacking Politics TL:DR

Who
    Aaron Swartz, Alexis Ohanian, Andrew McDiarmid, Brad Burnham, Casey Rae-Hunter, Cory Doctorow, Dave Dayen, David Moon, David Segal, Edward J. Black, Elizabeth Stark, Erin McKeown, Ernesto Falcon, Gabriel Levitt, Huffington Post, John Perry Barlow, Jonny 5, Josh Levy, Joshua Bauchner, Julia O’Dwyer, Kim Dotcom, Larry Downes, Lawrence Lessig, Mark Zuckerberg, Mike Masnick, Nicole Powers, Open Congress, Patrick Ruffini, Ron Paul, The WGAW, Tiffiniy Cheng, Victoria A. Espinel, and Zoe Lofgren.

What
    Hacking Politics: TL:DR

Where
    Hosted on the RIT HFOSS class site here: http://hfoss-fossrit.rhcloud.com/static/books/hackingpolitics_txtwithcvfb.pdf

When
    Published in 2013

The Gist
        The TL:DR of Hacking Politics is a collection of quotes and anecdotes from a variety of hacktivists and politicians who were active in the fight against SOPA/PIPA and COICA. The various contributors talk about the causes, concerns, emotions and issues that surrounded the bills and the campaigns for and against them.

The Good
  1. Did a good job of drawing the reader in; it's just a collection of quotes, but it is by no means boring
  2. Even if you don't know the names of everyone in the book, their words have no less impact
  3. It does what a TL:DR is supposed to, and it does it well. By the end of it you know about the various issues surrounding SOPA/PIPA and what the bills would have actually done
 The Bad

  1.  Suffers slightly from obviously preaching to the choir
  2. Nothing in the TL:DR is cited or sourced; they're just quotes from prominent figures
  3. Felt a bit like it almost wasn't supposed to be read all at once; there was so much jumping around between voices it was a bit confusing.
The Questions
  1. The Writers Guild strike is mentioned briefly, I'm curious as to how much that impacted public opinion of SOPA/PIPA
  2. How much of the SOPA/PIPA bills were actually drafted/demanded by the entertainment industry's lobbyists?
  3. Was the goal of the bills aimed at curbing the 1st amendment or simply to turn a higher profit by attempting to shut down piracy sites.
Your Review
        If you weren't interested in SOPA/PIPA before, you will be now. If the TL;DR of Hacking Politics doesn't suck you into the book then nothing will. An excellent collection of quotes from many of the prominent figures in the fight for free speech and net neutrality. 9/10 Wombats.

Monday, November 24, 2014

Component Based Programmin'

Like every good Game Dev student interested in low level graphics I started writing a small game engine for my Data Structures and Algorithms for Games and Simulations class. I've learned a lot but what I wanted to write about was the magic of writing a component based system.

There's a reason Unity uses a component system for it's engine. It's elegant and modular; intuitive and powerful. It's a really great programming paradigm whether you're writing something simple or complex. Needless to say that actually writing a system like Unity is far from easy, but it's also really rewarding.

The way my engine is structured is that there are GameObjects and Components. GameObjects store Components, and Components store a reference to their parent GameObject. This creates the first architectural problem I ran into; making sure that there's no recursive header includes can be a bit tricky when the GameObject needs to include every derivation of Component.

From there I can have all the logic of the game modularized into core components and drastically cut down on the complexity of the architecture. Each GameObject just runs the Start, Update and Draw functions of its components. As an end user all I'm really doing is changing the core values of these core components and I can make some neat stuff appear on screen.

The big upside to all of this is that it makes it really easy to add scripting to a system like this. After some more core functionality gets sorted out an the game loop is modernized a bit I'm hoping to add Lua or Python scripting support.


Meetup 3: RocPY

Roc Py happened again. What even happened. I can't really remember all that well because I pretty much fell asleep. Not really, that would have been rude but the talks were far from engaging.

First up was the talk on the python module itertools. A neat little module that seems to double up most of the basic functionality of python with an iterable return value. I guess that's useful and flexible but I feel like that just adds an added layer of complexity on top of the possible Python Programming Paradigms. It's just another thing that you have to decide to use when writing something in Python. Are we using classes? are we doing a more functional style? are we using tabs or spaces?  are we using default or itertools? There are so many questions I ask myself whenever I write something in Python and I end up just getting confused.

Next were the lightning talks. Franky I can't really remember what they were about. I know that Ross Dylan gave a nice talk on distributed systems but as a game dev student it largely went over my head. Deployment isn't really a thing I ever have to worry about, or at least not yet.

The main talk was completely beyond me. I could not pay attention to it in the slightest. Something about using python to script advanced camera equipment? I feel like what took over an hour could have been summed up in 20 minutes. I get that not everyone is a great presenter but it was a tad ridiculous how long it took to reinforce the point that Python is a useful scripting language. There were very few useful code examples and the slide deck was just kind of a mess. I'd much rather have preferred a shorter talk with more hands on demo which I didn't even have time to look at.

Maybe it would have been much more enthralling if I enjoyed using Python but as it stands I was thoroughly unimpressed.

Thursday, October 30, 2014

Vid Review 2: Simple Made Easy

Who
    Rich Hickey

What
    Simple Made Easy

Where
    It's on Infoq over here: http://www.infoq.com/presentations/Simple-Made-Easy

When
    Date Published: Oct 20, 2011

The Gist
        It's a talk detailing a big problem with production level code which is the extreme level of complexity that software today is written with. Hickey details the sorts of programming paradigms that are inherently complex and goes into detail about the alternative programming styles that can help lower complexity of your software.

The Good
  1. I like how he explained how things fit in the mind and how we can only focus on so many things at a time
  2. In conjunction to the above I think the point he made about needing to bring in the understanding of any dependencies of your code into your mind as well and this can lead to a large amount of things required to understand an originally small piece of code.
  3. Did a good job at giving alternatives to the common complex programming paradigms he described
 The Bad
  1. His opening explanations of easy and hard, simple and complex falls pretty flat
  2. The video didn't show his graphs and slides :(
  3. I think he overstates the importance of the need for simplicity just because the end user wants it to be easy, not necessarily simple and that need of ease inherently leads to a higher level of complexity; you can't expect a client to relearn things just because you made them simple.
The Questions
  1. Does he actually expect people to write code with minimal complexity?
  2. Why is syntax inferior to data and is there anything we can do about that anyway?
  3. Variables are complex, does that mean we shouldn't use variables?
Your Review
        A nice video if you're interested in complexity in code and the state of the software industry. It's a bit trimmed down from the original talk because the slides aren't part of the video but it is interesting. If you're a higher level programmer writing corporate level code this would be interesting, if not it may go over your head. 6/10 levels of complexity.

Tuesday, October 28, 2014

XO Smoke Test

Well smoke testing my XO went mostly fine.

Everything worked except for running external bundles. When I put the Sudoku activity on either one of my flash drives, copying it to the XO didn't end up with a running activity. What happened was that the XO would recognize the files, let me launch the bundle from my flash drive, but it would fail to run. I tried copying it to the XO's memory and got the same result. This happened with two flash drives.

Then when I tried to install the StarChart activity from sugar labs I got an even worse result. The download completed surprisingly quickly but when I opened the journal there was no Icon, unlike the bundle copied from the flash drive. Also telling this downloaded bundle to open yielded... nothing. No error, nothing. The device just acted like nothing happened.

Everything else worked as planned. Audio plays, books can download, connections work everything besides side-loading bundles works fine.

Another thing I noticed was that there was a strange issue where if the laptop was nudged a little bit the wrong way, or if it was having some sort of hissy fit, the mouse would move around like crazy and just kind of click all over the place. Not sure what caused that, it would just seem to happen but I did notice it particularly after accidentally nudging the computer a bit.

Only idea for what could have caused the issues was that I left the XO on battery for a week or so with no charging, and then moved from the Gnome desktop to Sugar with no reboots. A full power cycle may fix some things.

Thursday, October 23, 2014

Meetup 2: ROC Py

I went to ROC Py, the Rochester Area Python users group again this Tuesday. The talk this month was mainly focused around Bridging Python with other languages. The speaker outlined and demoed the use of python with languages such as C, Fortran, .Net and even Java. Overall I liked the talk, it was well delivered, gave a good walkthrough of the procedures of extending python and for the most part I was interested throughout the whole thing. Where I draw issue is with the concept of bridging libraries.

In my opinion, you should never bridge languages for anything other than a library. If you need to do some very fast computational procedures and you're considering writing CPython, your best bet is to just write it in C or C++. I don't care how familiar you are with Python and how much you love it, there's a rule with programming. You choose the right language for the right job. Python is good for simple scripts and other lightweight applications. Many people choose Python over C for simple programs because of its ease and readability. You sacrifice both of those when you start bridging Python with C. If you need to do things very fast, just use C or C++, please.

The exception to the rule here is libraries. Why? because sometimes you need to do something that's just not exposed to your language without going deeper. For example I had to write a native plugin to Unity and I used C++. I've also written android plugins and for that I used Java. Why did I do this? Because Unity C# simply can't access DirectX and OpenGL the way I needed to. This was a plugin to be distributed next to Unity, not as a core part of a project. If you wanted to write an OpenGL layer into Python (for whatever reason) fine, use CPython, but even in that case I see C being a better option overall.

Something like Jython or IronPython (Python in Java and C# .Net respectively ) I understand a little bit better. Jython compiles down to java classes which should make it about as fast as Java on the bytecode level, but I doubt that the compiler is really doing a good job of optimizing that Python so the speed may not be actually as fast as Java in practice. IronPython is pretty much the same but .Net compiles down to machine code. Again the compiler optimizations are going to matter here so you may not quite get the speeds you'd expect from C# or VB. At least with Jython you keep the portability of Java but IronPython I don't really get. I don't really trust the Mono compiler all that much and Mono runs in a VM outside of Windows so you'll be taking a performance hit even further.

At the end of the day it doesn't seem like speed is going to be a big enough gain to offset the complexity of bridging Python to another language. I think it's a better idea overall to use Python to what it does well.