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.

Under the hood is nice... until the hood breaks.

So, rails. It's good. Really good. I've sung its praises before, but I do still find myself having troubles on occasion. Usually, when you have a problem with your code, it's easy enough to step through it and mentally envision the state of the code, effectively becoming a human compiler. In rails, though, that's just about impossible. I've always said my biggest gripe with Rails is it's abstraction. Basically, each object can have dozens of files in the file system determining it's code. Knowing what has scope where, which function call you're using, where the offending function is even defined is all difficult. I suppose using an IDE like Aptana would make things a bit easier, but it's still a bit difficult to get a cognitive map of the file system. Right now, I'm having trouble with some database entries, and I have no idea where. I can't seed the database, the seeds file is running completely fine (debug statement ahoy!) and the database is up and running, but one specific type of model is just not loading.

I'll probably ruminate on this for about an hour or so and realize a typo or something, but until then, I'm just left here cursing the abstraction layer for not giving me more information.

Presentational Responses

So, it's our second presentation today. And again, we're feeling the sting of no prep time. Last week, we were told we were presenting again, but not informed the week before. Our group has trouble meeting during the week due to work schedules, and this Sunday was Easter, so a group meeting was out. We did all we could during the week, and I feel like we definitely made improvements, but a bit more heads up would have been appreciated.

That being said, we are certainly better off than we were last week. A few improvements that were suggested were reducing the statistical overload, fixing the Facebook trouble (my bad), and a few other minor technical problems that will definitely be ironed out by the next presentation. I'm hoping there aren't any more before the final, though...

Easily doing things the hard way, or hardly doing things the easy way

A situation came up during a group coding meeting that brought up a design principle that I feel most of us are fairly conflicted on. When attempting to solve a problem, at what point have you spent more time trying to find an easier way to do something than you would have spent doing it the hard way?

The situation was simple, we needed to do a validates_presence_of field for one specific method, not the whole object. The User's avatar did not need to be there for any user page, but it did need to be there for the page we upload the photo on. The solutions we found were large, hack-ey, and difficult to implement, and we thought there had to be another way. There probably is another way, but at the same time, if we spend more time trying to find that way, are we really saving any time? I mean, the solutions we found weren't inefficient, they didn't make unnecessary database queries, or take up a lot of space, they were just difficult to code in and make the code look uglier. In a situation like this one, especially, it's hard to make a call. In production, you might just want to get the thing working and out the door, but in academia, you want to make the cleanest looking code you can since you'll have someone poring over it to find a way to make you lose a couple more points.

I don't really have a decision here, and I don't think there is a decision, really. Different situations warrant different calls.