RPInventory

I gave my first presentation for the semester at RCOS today. Instead of the traditional technical project talk, I decided to look at the history of RPInventory and try to share some of the knowledge that I've learned from working on an open source project. The technical talks are a great way to judge the progress that a project is making, but I think it's refreshing to have talks about development in general. We're here at RCOS to not only become famous through developing great software, but also bridging the gap between where we all are now and fame. Since we're developing "sharable" software, we might as well share our knowledge as well. It's only fitting!

In addition to the general talk, there are a couple of slides at the end dedicated to the potential renovations of some space on the first floor of the Amos Eaton building.

Slides (pdf)

So, in the last couple of days, I've been doing a bunch of work on this custom fields stuff (see previous blog posts for explanations), and I actually have something to show for myself!

~1500 lines of code changed got me to a point where I can create a new field and have it be displayed on the main page. Granted, it's a very minuscule victory, but a victory nonetheless :).

Mostly, I wanted to write down my thoughts one where I would like to see RPInventory go in the future. First, we need to do some documentation. With 5416 lines of code just in the lib/ directory, we need to write some stuff down. My first thought was to use Doxygen, but I figured I should do my research before committing to any one thing. Obviously, I'd prefer one tool to do all the documentation, which means Doxygen would be out (as it doesn't play with Javascript, according to Wikipedia). Of course, now that I think about this, as long as we conform to the javadoc-like syntax, we should be alright.

Second, we desperately need to be running Unit Tests. I've found so many things that were mysteriously broken (sometimes due to stuff I did, sometimes not) that it's just a terrible situation. I really don't have any clue in this case what kind of software to use. Again, it'd be great for the software to interface with the PHP, Javascript, and the database, but I don't know if I'm being hopeful. I don't necessarily want to have something that's going to prevent me from committing more code while tests are broken, but having something to do some double checking of committed code would be awesome.

Third, which will definitely only come with >=RPInventory-2.0, is a re-write of the application. When we started out, one of our original developers used Smarty as a template engine. The rest of us just kind of went along with it because, well, we were noobs (shh don't tell). But it's really starting to inhibit development at this point. Colin has been working with Symfony and I've done a little tutorial work with CakePHP in the past, but I'm really just not sure. Perhaps I'm just a little hesitant to give up the amount of control we have over the system at the moment, but at the same time, I have to realize I'm giving that up due to my own ignorance of how the framework operates (and how I can do the fun advanced things I want to do).

Anyways, that really sums up where I'd like to see this project head. It's really grown out of the RPI-shoes it was initially bought, and I think, with an appropriate user-base, it could really be a nice little piece of software. So, let's just keep on hacking.

The biggest complaint about RPInventory at the moment is its rigidity in allowed data. When the project was initially created, the thought was to only have RPI Union clubs use the system, but we've found that many more in the community could benefit from such a system. So, in a nutshell, I'm going to change that.

I plan on creating an method for users to add additional fields to their inventory items, allowing them to store whatever kind of information they'd like. By whatever they'd like, I really mean a generic alphanumeric phrase, a numeric choice, or a set of options. I'm going to be limiting myself to these generic three options, but hopefully I'll be able to implement some more tricky alternatives later on.

I'll be starting with the generic alphanumeric and numeric choices right away, as they have one less layer of difficulty attached.

There was some talk about looking into options like MongoDB or CouchDB, but I believe I'd like to finish this up in MySQL. I think the better approach, if I or someone else wanted to, is to create a whole new database class that would interface with (Couch/Mongo)DB. That way, we can preserve all of the existing MySQL code, and just add to it, giving users more than just one option.

I've tried to do as much thinking through this as I can, but I'm sure I'll run into some unforeseen issues, but hey, that's half of the fun of programming!

I've spent a good bit of time in the past week working on two issues: centralization and a database abstraction class. The first allows us to have one installation of RPInventory for many different clubs. This is essential for maintenance. The second allows for more rapid development. The database class allows for sanitized queries to be written cleanly. It will also allow us to easily move to a different DBMS in the future if we should so desire.

We gave our second presentation this past Friday, 10/30/2009, at the weekly RCOS meetings. You can find out slides here (pdf).

Some topics included our design help from the Student Web Technologies Group, the completed inventory searching, the completed categories functionality, and our live servers.

The two other large goals we have at the moment are the change to a single, centralized installation and the ability to let users store items with their own customized data fields.

Cameron has gotten us access to our own little corner of the world, http://inventory.union.rpi.edu

In addition to that, I sent out some emails today to ask for interested clubs. To my surprise, five clubs have already responded to me saying that they would be interested in helping to test out our system!

So, from here, we're going to be scheduling a presentation for the interested club officers, most likely this week. Exciting times!

We gave our first presentation to the RCOS group for this semester on Friday, October 2. You can find our slides on our Wiki, or directly at this link.

Upcoming events will be contacing the Webtech group in the Union to get some help with the visual aspect of our application. We will also be contacting the Union System Administrators to get some test installations rolling so clubs can start beta testing the application.

On the development front, we are working on redesigning our database schema to allow multiple inventories to be stored in a single database.

This Wednesday 9/30, the team will be meeting up with some people from the Union System Administrators and the Web Tech Group to discuss the future of RPInventory. The project is at a point where the scope should be reevaluated and refined. So, our goals will be to discuss the actual implementation of the system for RPI clubs, while also to see where the project can go outside of RPI to better the world.

The day has finally come. We've announced our first stable version of RPInventory. The development work has paid off and we now have a version that we'd like to begin beta testing. After letting the administration in the Union here at RPI know of our status, we scheduled a meeting with two students leaders of software projects in the Union. After discussing what we've accomplished and the best way to move forward from this point, the team is going to contact a few clubs, get some installations set up on the Union servers, and (hopefully) receive some real-life feedback on how the system works. As always, the code is just a click or two away under the repository link at the top of the page; check it out!

We've just registered the domain name, 'rpinventory.com'. We'll be moving off of our current 'rpinventory.tuxygentoo.com' to this new domain name. This will also be changing the rpinventory email addresses, so make sure to update your address books.