Final Post - Thoughts

So, class is over and I've got a few thoughts to give on the class as a whole. I feel like I learned a lot about the software engineering process. The class was tough, but fair. Other than the hiccups with mid-semester evaluations, everything seemed to be designed to help us get a finished product out the door.

I'm really impressed with how much work my teammates did, I feel like I under performed, but it was difficult to find anything that needed to be done that wasn't already being worked on. Great work ethic from everyone, and great quality of work.

The other projects were all amazing. I continue to be amazed at how fun Automaton looks, and I think with a decent soundtrack it would do well on the App Store and Google Play. I found myself checking back on it once it went online and playing a few levels. UNM Visual scheduler was, of course, incredible, and absolutely deserving of first place. It's a headache reducer when signing up for classes, and I would not be surprised if it got bought out by the university and wound up being the new system in a year or two. The other three unfortunately don't really appeal to me much, as I am neither a skier or own a vehicle, but they are solid, marketable products.

Demigod, I feel like we could have done more with it, but we were especially careful to stay on spec and not let feature creep ruin us in the end. Matt Smith's leadership and experience in development were a great help at this, making sure we didn't go overboard and got everything done on time.

All in all, this was a great experience. I learned a lot about group dynamics and actually saw a project through to completion. Even as far back as writing our proposals gave me the tools I needed to make my own projects a reality.

Thanks to everyone in this class, and a big thanks to my teammates and professor Ackley.

If it codes like a duck and compiles like a duck, it's probably a duck.

Something I've always known Ruby could do, but never knew there was a word for: duck-typing. In short, duck-typing is object-oriented hierarchy without explicitly defining two things as being of the same family. Basically, where Java would throw a compile error if you were to use a "Person" class when you asked for a "Duck" class, Ruby would compile just fine, and even run it if the "Person" class has a "Quack" method that you call.

I didn't really use it too much in the assignment, but I do like the naming for it. It's very evocative of it's function and a decent little joke. Programmers tend to have a strange sense of humor.

Redmine

So, my rails experience in this class is actually getting me more work at my job due to how awesome rails is. I've been tasked with re-doing our ticketing and point of sale system in Ruby on Rails over the summer. I've spent some time actually researching gems and services, and come across a program called Redmine.

Redmine is a issue and project tracking system, similar to the tracker on Bitbucket that we're using for Demigod. It's built in Ruby on Rails and is open-source, so I'm planning on integrating it into my project at work in the coming weeks. We already use a similar system in OpenERP to keep track of repair orders, so using Redmine in a much more customizable format would be a great help to our organization.

Some linux-ey goodness

So, I know it's not particularly related to the class, but lately I've been working on setting up a Network Boot. The idea is, customers at the shop can bring in a computer, connect it to the network, and boot up the proper OS.

This was easier than I was expecting. My boss did most of the heavy lifting, setting up the DHCP and TFTPBoot, but I managed to get my first experience with Linux menuconfig. It's a very simple scripting language, really, and it's actually fairly similar to rails, or at least the way it handles partials and html. Menuconfig files reference each other with one line, effectively putting the entire contents of one file in its place. Menuconfig even writes a bit like HTML, with just about everything wrapped in begin and end tags, and nests to create a form. What's surprising is how much customization you can do in it. You can effectively lay out the text anywhere, you can insert images, and capture all sorts of inputs. That got me thinking, is menuconfig turing complete? It would be pretty interesting using menuconfig like a programming language. You could make simple programs that boot and run without even loading an OS. With the network boot thing, it might be possible to do a menuconfig on PXElinux that will, for example, image the drive over the network before selecting the reinstall option to automatically back up the data before going through with the reinstall.

It won't be done any time during this semester, but it'll be fun to work on over the summer.