Category Archives: FOSS

No More Relics!

Gonna be completely honest: I’m freaking out right now.

The semester is winding down, and it’s go-time for Fortune Hunter.  My team has been working for weeks on refreshing this old game for the OLPC  laptops.  I’m the artist, which is a welcome change of pace and an awesome way to increase my game designer well-roundedness, but I’ve come to a horrible realization.

You see, when you write code, you may have your own style.  However, code is code.  You don’t perceive it in the same way as art.  If it works, it works.

Art is different.  Style is hard to imitate.  You can get close, but the point is that it’s difficult.  I would hate to leave this overhaul incomplete.  It would be a tremendous disservice to whoever decides to pick the project up in the future.  In fact, it would be worse than doing nothing at all.  It’s discouraging.  It’s taunting.  I hate finding art relics, and I refuse to perpetuate this nonsense.  It’s the least I can do.

So, tl’dr: I’m going to finish this art overhaul even if it kills me.

Feel free to peruse the repo too.  Some of my stuff is already up. 😀

Tagged , , , , , , ,

RocPy 11/19/13: The Day My Brain Melted

I thought I could program.  After a few years of studying games and writing code, I assumed a bit of competency on my part.  Call it pride if you want, but it is what it is.  Yesterday, I went to the Rochester Python user’s group meeting: RocPy.  Python isn’t my forte, but on that day it really wasn’t my forte.  The topic was database management in Python.  I’m not particularly good at database anything, so it was already difficult.  Throw on an explanation of ORM’s and my head starts to hurt.  Finish it off with a comparison between SQLAlchemy and Django and you can consider me humbled.

I needed this.  I was too big for my britches.  The true programming masters are the ones who know what they don’t know, and I learned exactly what I don’t know: a lot.

Tagged , , , , , ,

Thoughts on Evgeny Morozov’s “The Meme Hustler”

Here it is, if you’re interested:

Published 2013

This article is entitled “The Meme Hustler,” and it’s all about Tim O’Reilly, founder and CEO of O’Reilly Media.  The articles serves to analyze O’Reilly through the lens of his published work.  Morozov tears deep into O’Reilly, as he attempts to show that O’Reilly is actually a bit of a self-perpetuating monster with flawed ideals and too much power.

The Good

  • Clear and consistent voice, an easy read.  Not super-academic or dry.
  • Stays focused on picking apart O’Reilly’s actual words instead of simply attacking him out of opinion
  • Provides context by mentioning the people around O’Reilly (friends, foes, and influences), like Richard Stallman and Alfred Korzybski

The Bad

  • Progresses chronologically and conceptually, which can be confusing
  • Ends abruptly
  • Not a clear indication of a specific point to be made other than “This guy is kind of awful”

I’m still wondering…

  1. What does Tim O’Reilly think of this article?
  2. Just how much influence does he realistically have in government and politics?
  3. Who is O’Reilly’s main, current opposition?  Is there an anti-O’Reilly with a similar amount of power?

What I think…

I liked this article.  It stuck to the facts, and Morozov is clear about exactly what he doesn’t like.  Every section of paragraphs serves to show something clear and focused, with plenty of quotations from the man himself.  Morozov thinks that O’Reilly is a bit of a madman, but in Morozov’s defense, O’Reilly isn’t doing himself any favors.

Morozov attacks his topic from multiple angles, and while I would have love a better organizational scheme for these angles, they are there nonetheless.  I learned about O’Reilly’s philosophical roots, his vast self-marketing resources, and examples of self-contradiction abound.  Clearly, this author has done his homework.  Actually, he does talk about that a bit in the author’s notes at the bottom of the page.

Anyway, I wouldn’t take this article as the definitive guide to Tim O’Reilly.  Everyone has bias of course.  What I will say is that Evgeny Morozov has done a wonderful job of saying his piece without sounding like an angry, bitter old man with a grudge.  Even if you disagree, and you totally love Tim O’Reilly, give it a read first and be salty later.

5/5 for doing your homework and delivering an enjoyable read.  Good job, Mr. Morozov.

Tagged , , , , , , , , , , , , ,

Solarus: Open Source Re-Arting Without Pissing People Off

Open source software is great.  Well, great for programmers.  As a new artist (I volunteered to do art for my current FOSS project with my team), I’ve found the environment to be strange for artists.  Are patches really welcome?  Isn’t that like ambushing someone and giving their child a makeover?  Isn’t that insulting?

Well, I’m gonna give it a shot.  Meet Solarus.  It’s an open source Zelda game.  I’m gonna re-skin the thing, and more importantly, I’ll document the experience to help future open source artists.   There’s gotta be some methodology for creating “texture packs” or re-imagining a project in your own eyes..

Tagged ,

RocPy Again!

Last week I went to the Rochester Python Meetup again with my FOSS class.  This time, we were on a mission.  We were pitching our One Laptop Per Child game projects to the group (which was like 90% us but whatever).  The meeting was weird because most of the projects were only related in that they are going to be coded in Python, keywords here being “going to be.”

Awkwardness aside, the other projects were pretty cool.  I was in a weird position as the artist of my group, but there were still things worth saying.  Fortune Hunter needs a visual update badly.  Balance issues abound.  There’s tons to do and very little in the way of upstream mentors.

Talking about it made Fortune Hunter feel real, it was inspiring.  Now we just need to get it to run on the XO…

Tagged , , ,

The Tandem Bike Theory: Guild Wars 2 X Mathematics

Train boarding

Aaaaaall aboooooooooard!

Have you ever been on a long train ride?  If so, what about it do you recall?  What were you doing?  Perhaps you were talking to a friend, reading a book, or eating a sandwich.  Maybe, after those options were exhausted, you briefly looked out the window because there was nothing left to do.  Were you concerned at all with the intricacies of the train?  Did your glances outside provide you with meaningful information about your location?  Did you speak to any other passengers?  For me, train rides are passive experiences.  I just find it hard to care.  You get on, try desperately to amuse yourself, make a transfer or two, then you’re done.  All the while, you follow the instructions of some disembodied conductor who you probably never see.

So, why all the train talk?  Well, to understand where I’m going, let’s talk about MMORPG’s.  I’m not being specific, so just think of the most generic one you know.  In my experience, these games are boring.  No matter what role you choose, group play boils down to a chore.  If you heal, you spend your days staring at bars and trying to keep them full.  As a DPS-er, you spam hotkeys for damaging skills.  For such a seemingly team-oriented activity, it ends up lacking interpersonal interaction and more importantly, fun.  These types of games are trains.  You hop on, do your menial task, and somehow end up at the end.  Continue reading

Tagged , , , , , , , , , , ,

Easiest Bugfix Ever?

Why do we not fix bugs?

Before you spout out your answer, focus on what I didn’t say.  I didn’t say “Why do we not find bugs.”  I specifically asked about fixing them.  Yes, there is a story for this one.

I was semi-frantically looking around the cramped, crowded alleyways of GitHub for a small bug to fix.  I’m no code-vigilante, it was an assignment for my Free and Open-Source Software class.  Intentions aside, I stumbled upon the strangest phenomenon.

In the Issues section was a bug observation that actually contained the solution.  Now, I’m not simply applauding my own luck for finding a fixed-but-not-actually-fixed bug to easily complete my assignment.  Rather, I’m quite puzzled.  This person seemed quite competent, so why didn’t he fix it?  It was literally a single line of code.  That was all it took to fix this issue.  In fact, to even notice the problem, he had to have been looking at the code.  I didn’t see a pull request.  Was he waiting for the core team to fix it?  Do a lot of people do that?

If not for FOSS, would I have done that?  Hmm…

Tagged ,

Reflections of My First RocPy Meetup

RocPy was interesting, but don’t take that statement at face value.  It wasn’t the subject matter, although it helps to know how getters and setters work in Python.  Still, that wasn’t what was magical to me.  See, this was my first programming-related meetup.  If you’re a seasoned meeter-upper, pardon my ignorance.

For me, there was something about meeting up with people who are passionate about programming.  Something about the meeting’s existence itself transformed it from a group of nerds talking about descriptors and servers to a room full of craftsmen.  I think this speaks volumes about programmers.  We are not simply the lone code monkey in a corporate cage.  When we choose to, we can band together and teach ourselves.  We can be a force for good or evil.  That’s what meetups are all about.

Maybe it’s something in the air that’s got me all introspective.  Maybe it was threebean’s epic beard.  Who knows.

Also, meta-classes hurt my brain.

Extra Random Thoughts on Weber’s Open Source ch3

So, Weber has these 8 Principles…

  1. Make it interesting and make sure it happens
  2. Scratch an itch
  3. Minimize how many times you have to reinvent the wheel
  4. Solve problems through parallel work processes whenever possible
  5. Leverage the law of large numbers
  6. Document what you do
  7. Release early and often
  8. Talk a lot

And has these 5 Pillars…

  1. Open exchange
  2. Participation
  3. Rapid Prototyping
  4. Meritocracy
  5. Community

Weber’s principles are functional. They deal with the “how” of FOSS.  In contrast, the pillars are descriptive and explain the “what.”  As such, the principles can be seen as demonstrations of the pillars.

  • Principle 1 demonstrates pillars 1 and 5, as communities form around making cool stuff and talking about it.
  • Principle 2 deals with pillars 2 and 5, as people come together naturally to solve problems that they encounter themselves.
  • Principle 3 is best viewed through the lens of pillar 5, as one should rely on the community’s efforts to avoid doing that which has been done already.
  • Principle 4 is pillar 3 in motion, but draws on the advantage of pillar 2. With enough prototypes and branches, progress is made in an evolutionary way.
  • Principle 5 to me is purely an expression of pillar 2. The law of large numbers is basically used here to show that when a lot of people work on a project, more bugs are found and more progress is made. Pretty simple.
  • Principle 6 may be hard to relate to the pillars for some, but I’ve found it to be closely related to pillar 5. Documentation is like the constitution of an open-source project. The understanding granted by it is a unifying factor in its community.
  • Principle 7 is the pure form of pillar 3 and is a strange phenomenon, akin to a carefully moderated, intelligently designed evolutionary process. Basically, it’s iterative development. Fail a lot, then profit.
  • Principle 8 is the fuel for the community (pillar 5). Communication is the lifeblood of a community (hence the same root). If developers didn’t talk, nobody would be able to get a feel for what is going on or what needs to be done.

Steven Weber drew heavily upon the analysis of Eric Raymond, specifically his essay “The Cathedral and the Bazaar” which is closely related to Fred Brooks’s “Conceptual Integrity.”

Tagged ,

Thoughts on Steven Weber’s “The Success of Open Source” (chap 3)

If you’re interested in the part that I’m talking about…

Published 2005

The chapter is called “What is Open Source and How Does it Work?” and that basically describes it. It breaks down the process of open-source development as well as the problem it tries to solve.  Basically, it’s a primer for open-source, explaining its inner-workings in a functional manner.

The Good

  • Focuses on process, not product
  • Points out misconceptions about open-source development
  • Provides modern-ish examples of open-source communities and sites

The Bad

  • Spends a long time mulling over graphs of estimated numbers of Linux users
  • Spends a bit too much time on software-development in general (not open-source specific all the time)
  • Generally a bit too verbose at times

I’m still wondering…

  1. What does a failed open-source project look like and how does it work?
  2. How does a project transition into open-source development?
  3. What do current open-source trends say about where the movement is going?

What I think…

This chapter is pretty well-written. If you’re curious about open-source development, read it now. Seriously, stop reading this review and read the chapter.  It starts chronologically, getting into the history of Linux and continues to reference Torvalds periodically throughout the chapter.  This works well, as he set a fine precedent for open-source developers in both practice and temperament.

After that, Weber starts knocking out topics one-by-one.  He covers the fundamental problem that open-source sets out to solve, and does a good job of providing examples and principles to simplify his explanation.  He can get a bit caught up in explaining software development as a whole, which may bore those already familiar with that.  However, that’s better than not explaining enough.

Another good title would be “The Open Source Process Explained.”  He frequently answers the question of “How does an open-source team deal with/do _____?” which is very helpful no matter what type of software you’re willing to develop.

Overall, this is a great entry point to learning about open-source development.  Read this if you’re curious at all about it.

In short: 5/5 (Awesome)

Tagged ,