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.

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.

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.

RIP: A Remix Manifest Vid/Lit Review

Who
    This was a film Written and Directed by: Brett Gaylor

What
    RIP: A Remix Manifesto

Where
    It's on Vimeo over here: http://vimeo.com/8040182

When
    Date Published: 2009

The Gist
        It's an overview of the state of "Remix Culture," the challenges it faces and the social implications by the precedent it sets. It outlines the battle between consumers and corporations over who controls media and why you should care about who wins.

The Good

1. Did a good job outlining what copyright is and what is currently wrong with it
2. Gave good examples of the current effects of the copyright laws
3. Made you understand and sympathize with the opinion of the author

 The Bad

1. Spent a bit too much time with Girl Talk
2. A bit overly doomsday-ish to subvert your emotions 
3. It preaches to the choir a bit

The Questions

1. Where is this out of date
2. Has Girl Talk received any legal action
3. What are the current actions being taken to fix copyright law other than breaking it

Your Review
        While it may be a bit inaccessible to those unfamiliar with copyright laws or to those who don't care, if you want a good overview of the state of copyright law and you want to learn a bit more on the subject this is a good watch.

Team Proposal - Number Munchers

Members:

Honeybunch - amt3824@g.rit.edu
Faokryn - faokryn@csh.rit.edu
Susan - slunn@csh.rit.edu

Project - Number Munchers:

Our team decided to work on a Number Munchers clone. Number Munchers is a game where you need to eat all numbers that meet certain criteria (i.e. multiples of two) while avoiding nasty monsters.

Roles:

We're kind of forgoing roles at this point. We don't need a whole lot of graphics or sound so everyone's job is just going to be writing a bunch of code. 

Source Code:

Will be hosted here

Upstream Mentors:

Easy Parts:

Setting up PyGame
Getting the basic game working
Making sure that the content matches up with the NY state math requirements

Hard Parts:

Optimization
Troggle AI
Balancing random content

How to overcome obstacles:

Getting the base game done is the main goal and overall should not be that difficult. It's a game praised for its simplicity so re implementing it should not be impossible. Obviously we won't be doing the exact content from the original but will be mixing it up with Fractions, Geometry and other requirements from the common core for 4th graders. The hard parts are just going to take work. Troggle AI is going to take a decent amount of work without overloading the hardware as later levels will be having multiple AI routines. It's just going to take a lot of playtesting to make sure the game is fun yet challenging.

Super Late Roc Py

So I'm really late on this one but I decided to do it anyway. Last month I went to something called Roc PY, the Rochester area Python meetup. I'm not really one to go to Hackerspaces, they're nice for socializing but I never seem to get much out of them. Roc PY wasn't really much different for me but that was for a lot of reasons.

First off, I'm not a Python guy. It's never been my language. I appreciate it and I think it's great for small scripts, web development and as a scripting language paired with something like Blender, but it's never my go-to language for projects. It's very easy to write but it lacks decent performance and frankly I don't like the syntax.

About the meetup though. It was tucked away in a dark scary corner of one of the back rooms at the University of Rochester. Okay it wasn't dark or scary but it was tucked away where if I wasn't in a group, I would have probably gotten lost. Besides the abundance of HFOSS students there weren't really too many other people there. A few U of R students showed up but other than that it was just a few older guys who use Python a bunch.

Really throughout the meeting nothing really stood out to me except for one guy who wanted to do a lot of geometry tessellation with Python. Not CPython or something like Blender scripting, just Python. While I did mention that Blender would probably be the fastest pure Python solution he said he had already brought Blender to its knees. I feel like this was a problem of "Use the right tool for the right job." Python's forte is not speed, it's ease of use. If you need to do complex things really fast, especially something like tessellation, you use something like C or, ideally, you use GPU accelerated compute shaders. That kind of irked me more than it should have.

I honestly don't think I'd go again by myself. I don't think I could find my way back to that room on my own to be honest, and Python just really isn't my cup of tea. Heck even if I was into Python I feel like hanging out on /r/Python or /r/LearnProgramming or some other Python related board on your website of choice would be a better way to interact with the Python community.

NY and MA Math Curriculum Comparison

How are the NY and MA 4th Grade Math Curriculum Similar?:

Well since the Common core has been implemented, they are virtually the same. They both focus on:

Multi-Digit Multiplication and Division
Dealing with operations in Base 10 up to 1,000,000
Understanding Fractions
Dealing with Measurements and Data
Identifying lines and angles

I really haven't been able to find many differences. In face both seem to be line for line identical save for the following discrepancies:

In MA, students are expected to "Know multiplication facts and related division facts through 12 x 12."

One that seemed an interesting concept to explore with a game was 4.G #2:
Classify two-dimensional figures based on the presence or absence of parallel or perpendicular lines, or the presence or absence of angles of a specified size. Recognize right triangles as a category, and identify right triangles.

I thought it may be cool to make a simple matching game but with images of different angles and intersecting lines instead of generic images.

The IGM Department and Curriculum

Depending on who you talk to at the school of Interactive Games and Media at RIT you'll get very different answers to the question "How do you feel about the curriculum?" Most of us will give a general thumbs up. While I'm in the general thumbs up boat I feel like there's a disconnect between what we're taught and what we need to know.

Lets talk the intro sequence. When I was here under quarters we started with Java and moved to C#, now in semesters it's all C# with XNA & Monogame. Frankly the move to just one language was probably a smart one, however there's something C# really lacks and that's a decent Command Line Interface (CLI). Anyone who does C# will straight up laugh at you for wanting to use the Microsoft or Mono command line tools.

Many of my peers will give me hell for saying that using Visual Studio for everything is a bad idea. Everyone here loves Visual Studio, even I do, but it's not a good learning tool. It's true that you'll spend a lot of time, when doing actual development, plastered in front of an IDE like Visual Studio but IDEs will change while the Command Line is timeless. I'm not saying that CLIs don't change or that the *nix command line never changes but that being comfortable without a GUI is really important. Anyone who uses Git on a regular basis will tell you that no matter now nice SourceTree is, you will still need to know how to use the Git CLI.

This is getting to the point where I'm sure you're asking me "Well what's your alternative?" And that's a totally fair question. Frankly there is no right or wrong way to learn programming, but every programmer will need to learn to use the command line at some point. I suggest moving from C# and Monogame to Java and a library like the LightWeight Java Game Library (LWJGL) which powers Minecraft. Java's command line compiler is robust and a good set of debugging tools. Not to mention LWJGL gives a better intro to OpenGL and transformations / matrices than Processing does.

Now I don't expect students to be using Vim to write Java and manually link LWJGL for the entire intro sequence, but spending at least the first semester in the command line would be largely beneficial. The lack of auto completion would facilitate more direct learning, Java is a widely used language, especially on Android and being competent with the command line will make learning other essential tools like Git and Mercurial much easier later on.

Texture Leaks in Unity

Textures in Unity are easy. Super easy. Until you mix them with editor scripts. That's when all hell breaks looks. For you see, with C#, you cannot clean up your memory by yourself the way you can in something like C or Rust; you're at the mercy of the Mono Runtime. Now this makes games pretty easy to write, but when you work outside the game runtime and start writing editor scripts, things can get out of hand.

The short of it is, if you make a texture, and it's not passed to another texture variable, clean it up. Use DestroyImmediate or else you will be leaking dozens of megabytes every GUI update cycle. This sucks very badly. For Tyle, my tile editor, this problem was pretty nasty and the only way to see if I was making any improvements on the texture leaking was with the Unity Profiler. The profiler rocks, but is only available in Unity Pro, so I didn't always have access to it. This means that Tyle had some nasty leaks for many many commits.

The worst was with the selection texture. If you hover over a tile with the mouse, you'll get a nice transparent texture over the map texture to show you where you're selecting. Neat huh? Well turns out it wasn't so neat. because I wasn't destroying the previous texture before assigning a new one (it would change color or disappear depending on various settings), it leaked textures like no tomorrow.

If you create a texture in a script, you can still run into this problem but in an Editor script it can be much worse. It's not just about eating up memory of your game, it's about eating up memory of Unity, which can get very scary very quickly.

But Textures are just variables right, how are they leaking? You have to remember that Textures and Materials in Unity are not regular variables. They represent assets that could be on the disk, or written to the disk potentially. Not only that but caching them means that the engine can actually render them. Textures and Materials don't get cleaned up until you clean them up. Most of the time this is no problem because normally you'd just load a texture from the disk and apply it to a blank material. If that material already has a texture though, delete it before you apply the new one, or the old one will remain in memory.

Hudl Presentation

So last night (Thursday) instead of heading to the regular HFOSS class we were shuffled over to the MAGIC center at RIT for a presentation from the folks at Hudl. For those not familiar, Hudl is a service for coaches to upload and annotate footage of games and share that with their athletes to break down and analyze game performance easily. It's a pretty interesting concept and it's been doing well. They have about a third of the video traffic of YouTube which is an impressive 32 hours of minute uploaded a minute.

The presentation was done by a nice fellow named Rob, a software engineer at Hudl who has been responsible for a large deal of interaction between Hudl and the Open Source community. He gave a nice run down of why businesses do or do not use open source software. He also explained where OSS is used at Hudl and how it's been a generally positive experience and their goals to contribute even more back to the community.

Overall I really liked the presentation. It was well delivered and well thought out. He did a nice job juxtaposing different businesses that would or would not use OSS and why. He also did a great job remaining mostly agnostic when it comes to the holy war that is OSS vs Proprietary. My only real complaint was that, well, he was kind of preaching to the choir. Maybe that wouldn't have been the case for anyone there that wasn't a student in HFOSS but I think most of the people were. I think, in general, most of use want to be using OSS but I guess I'm speaking too much on the behalf of others.

I would have recommended the talk to anyone not familiar with OSS or curious about the role OSS plays in the business world.