FOSS

I was talking to my brother-in-law, Jamie, the other day about Free and Open Source Software (FOSS). It got me to thinking about how much FOSS I use on a regular basis. Here is a list of all the software I have come into contact with recently. If you realize I am forgetting something, please leave a comment.

Software Used on a Daily Basis:

• Ubuntu (Operating System)
• Open Office (Documents)
• Mozilla Firefox (Web Browser)
• Mozilla Thunderbird (Email Client)
• Pidgin (Instant Messaging)
• Eclipse (IDE)
• Spaz (Twitter Client)
• Apache HTTP Server (Web Server)
• MySQL (Database)
• PHPMyAdmin (MySQL Web Interface)
  
• Simple Machines Forums (Web Forums)
• Mediawiki (Wiki)
• Tomato (Router Firmware)
  

Software Being Investigated:

• Trac (Project Management Tool)
• Zabbix (Network Monitoring Tool)
• Wordpress (Content Management System)
• SVN (Version Control System)
• Elgg (Social Networking Software)
  

Software Used in the Past:

• CVS (Version Control System)
• Joomla (Content Management System)
• phpBB (Web Forums)
  

Trac Review

I spent some time at the end of April playing around a little bit with a project management tool known as Trac. Then a friend asked me my thoughts on it. So I told him I would write blog about it. A month later, I am finally getting it actually done! Let me first qualify that I was looking at the tool to manage software development projects.

The Cool Things about Trac:

• Lets you create milestones in the development process. It seems to be common to use these to represent version releases. My initial thought was to use them for various key components of the software.
• Has a great ticket system for reporting bugs found in the software. These can be setup to allow your users to fill out tickets when they discover a bug. The tickets can also be attached to milestones to allow you to manage fixing them as well.
• Integrates a wiki as well to allow you to document the software and its development process.

The Disappointing Things about Trac:

• Installation is a series of commands that call Perl scripts if I am not mistaken. This made me sad. I wanted a pretty web interface to ask me the questions because it would make a lot easier for installing on my web host. I can survive, but I think it would be a big step in the right direction.
• Along the same lines as the installation web gui, administration tasks need to be pushed completely into a web interface. Some things can be done in the web gui, but not enough. I was still having to run some commands from a terminal for very basic setup and user administration needs.
  
• No concept of submilestones. I see milestones as tasks needing done. Tickets as bugs. From all the reading I did from the Trac community and developers, this does not appear to be the future idea of Trac. Right now, people create milestones and attach tickets to milestones. Tickets are being used to represent tasks. Rather than implementing sub-milestones, the direction is to implement sub-tickets. Personally, I just don't like this system, but I can roll with it if needed.
• No forum integration as I recall, but I could be very easily be wrong on this one. It would allow your user community to talk with each other and help each other. This would be useful for all those cases that do not make it to the wiki or when a user simply does not use the wiki or find what they need on the wiki. It could also be used for communication between developers.

After all of this, I will likely still use Trac. I spent some time looking at other project management software, and this was the closest one to really handling what I needed. I did have the requirement that the software was free and preferably open source. I do not intend for this to be a large implementation so the unpolished aspects are not as big of a problem. Things were still easy to figure out so I did not have to spend much time trouble-shooting or pushing through a learning curve. Ultimately, if you are looking for something like this, feel free to give it a solid look and see if it will work for you.

Stored Procedures vs. Prepared Statements

At work the last few weeks, I have been doing a lot with SQL in a web application. I will not say I am an expert in the matter, but I do feel I have a pretty good understanding of the two options. Ultimately, a stored procedure seems to be rather annoying than useful. The problem I have is that the languages RDBMS provide for stored procedures tend to be pretty bad as far as programming languages go. So there is a reason you have chosen to write your application in a particular language. Chances are it is the best for the situation and provides a lot more power than the meager implementation offered by the RDBMS. That means you need to get some advantage out of using stored procedures to make it worth your while.

So what advanatages can stored procedures offer? Protection from sql injection is thrown out because you get the same benefits from prepared statements. I have heard some arguments about performance gains. The two primary factors coming from caching the SQL statements along with the round-trip-time to the database server. From what I have heard, most RDBMS these days cache prepared statements just as well as stored procedures. Besides, on today's machines, you have to write the world's most complex SQL statement before you will notice the hit on the server. Meanwhile, the round-trip-time (RTT) can be a valid argument. If you have a lengthy series of statements with some simple logic to control them, there is some potential benefit to using stored procedures. This would depend on how minute your timing issues are along with how many calls of this nature you would make along with the length of a RTT to the database server. In most environments, the time from the application server to the database server is only a few milliseconds.

Ultimately, your average web application does not have strict timing requirements. It tends to be more dependent on the speed of development along with the ease of maintenance. it never makes a large enough difference to worry about it. When I am developing applications, I intend to lean towards prepared statements and will only shift to stored procedures when I absolutely need to.

COG Developers

As some of you may remember, I wrote a blog a few weeks back about starting to work on a new website. Well, Champions of Gaming (COG) is officially under development. I am working on it with Mark Fedor (papasmurf786) and Chris Tuvera (eviltim11). They are both people I play videogames on a fairly regular basis. Mark I have only known for the last two and a half years as I recall. I grew up knowing Chris since first grade. Mark has some pretty impressive graphic skills and is starting to learn some basic programming concepts. Chris is constantly getting better and better with his graphics skills. He also has some programming skills; though, he has yet to delve too much into web development. For the moment, I am doing most of the backend development while working with Chris and Mark on the frontend.

As for how the development is going, we have officially bought the domain now. We are hoping to pick up a few similar domain names, but that is still hanging in the air at the moment. The look-and-feel is pretty much set, and I must say it looks pretty sexy. We have mapped out a few placeholders for some features we think will be cool. No real functionality has been put in place yet, but a lot of ideas are being thrown around and decided on. I do not know how much will get done before Thanksgiving as all three of us are in college at the moment. However, hopefully, we will make some significant progress over winter break.

New Website: Champions of Gaming

I've recently started working on a new website. As many of you know, I frequently participate in a videogame clan. This includes not only playing games online with them, but running a website for them. Well, a few of us have decided to expand our involvement in the videogame culture. One website we regularly compete on in amateur tournaments is Gamebattles.

We have several complaints against Gamebattles. A lot of the admins are pricks. Most of them our high schoolers on power rushes. This results in the rules being horribly thrown by the wayside and very subjective rulings coming into play. They also tend to be aggravated by teams who repeatedly submit tickets because their opponents are breaking the rules. Rather than these teams who are trying to play legitly getting wins for their efforts, they are punished for using the system put in place by Gamebattles. I don't want to say all the admins and refs are corrupt, but a lot of them are. The few good ones tend to be lost in the sway, rubbed the wrong way by corrupt superiors (as I once was), or just too few make a difference.

When things go smoothly, the competition is awesome. I know all the KOR guys love it. We feed off of it. It gets to the point that we literally scheduled practices to get prepared for upcoming matches. We plan out our strategies. We have leaders to give out quick orders in the heat of the fray. We have even worked on a means for quite literally developing our own "playbook" of sorts. This is how KOR really got off its feet in the beginning. It started as a few guys playing together for fun. Then they got involved in GB (Gamebattles) and things took off from there.

So what does all this have to do with me building a new website? Well, some of us have gotten frustrated with GB for the above mentioned reasons. Some of us enjoy getting involved in various web development projects. So what does that all add up to? We sat around talking one day and got the idea we should make our own. Now we are actually starting to put some serious effort into it. We needed a name first. Since we needed a web domain to go with our name, we started ruling out names we couldn't get a domain for easily. Finally, we came up with Champions of Gaming. I'm not providing a link here because we are still in the very early stages of development. We haven't even purchased the domain we intend to use. I suspect this will come back to seriously haunt me if someone purchases before we do...