Yesterday saw the sixth major release to the SMS 2 finally hit the streets.  There were some incredibly anxious individuals (who will remain nameless … for now) who were basically camped out in IRC all day on Saturday as I prepped things left and right, constantly asking me if it was time and refreshing the Anodyne site repeatedly.  (Thanks guys, you’ve officially skewed our traffic reports.  )  But as the dust settles from this final SMS 2 release, I can’t help but look back (a whole 24 hours, I know).

In terms of a catastrophe, this release looked like it was going to be a bad one when the first few bug reports came in.  It wasn’t just one or two things going wrong, it seemed like 6 to 8 things were failing and it was never consistent.  It made my head hurt just thinking about it.  It took a while, but I did track the bug down.  Turns out, it wasn’t a failure on QA’s part, nor was it failure on my part, it was just a bug.  (For those interested, the next paragraph is the technical explanation of what was going on; if you’re not interested, just skip over.)

Turns out that we were testing for the system version in the URL from the update script.  To protect against someone doing anything malicious, we tested to make sure the variable existed in the URL and that it was numeric (since there would never be a valid non-numeric version number).  The else statement in that logic set the version variable to FALSE.  Then, later on, we were checking to see if the version variable was set, and if it wasn’t, go into the database to figure out what version they were running.  Sounds pretty simple.  Only problem is that in the event that the version wasn’t passed in the URL, the version variable was set to FALSE, meaning it was in fact set.  Had it been set to NULL, then everything would have evaluated fine, but instead, the update page was seeing that it was a set variable and ignoring the whole check for version code, and since it didn’t have a version, it never called the update script.  But, the database was updated so it appeared that both the files and database were running 2.6 when the files were 2.6 and the database was 2.5.6.  You see the problem: people were trying to use 2.6 with a 2.5 database.  Doesn’t work so well.  Needless to say, the issue has been resolved and will be in the 2.6.1 update.

After that bug was solved, suddenly issues were dropping off our radar like flies.  It was a good feeling and definitely took this release down from catastrophe to just about an average major new product launch.  There are still some annoying little bugs to fix, but this time around, we’re not dealing with the massive data corruption stuff we were seeing with SMS 2.5, which is a huge relief.

I suspect that 2.6.1 will drop later this week with the potential for 2.6.2 in the coming weeks to solve some issues that have been created by Mozilla with their updates to the Gecko rendering engine in Firefox 3.  (For those reading who have noticed the issues, it’s not supposed to look like that, but our focus at the time was testing for Firefox 2.  We know those issues exist and we’ll be working to remedy them in the near future.)

All in all, I’m very pleased with how this release has gone and I’m looking forward to talking a lot more about SMS 3 in the coming months as we really hit the ground running!

A few months back I posted a blog entry about the possibility that SMS 3 may be able to run on more than just MySQL.  Since the first released version of SMS (1.2), Anodyne has catered exclusively to MySQL, and why not, it’s one of the most popular database system and is free.  On top of that, most hosts trust MySQL because of its price tag and the fact that more people know about it than, say, PostgreSQL or SQLite.  For some of these low cost hosts, it’s just absurd to think about using Oracle because the costs can be so prohibitive.  Still, there are hosts out there that offer more than just MySQL.  A host with Windows servers would probably off MS SQL as an option, and since PostgreSQL is free, that’s also a possibility if a host chose to go that route.  Which brings us back to the question, why does SMS only support MySQL?

That question got to bugging me about a year ago, but given the SMS 2 setup, it wasn’t plausible to even attempt to address (not to mention my complete lack of understanding what would go into some type of database abstraction layer).  This is another one of those great places where CodeIgniter comes in so handy, because they’ve already thought of that.  Frameworks like CakePHP and symfony have full-blown ORM (object relational mapping) to make jumping between database drivers easy, but CI doesn’t have that.  Instead, they’ve opted to go with something called Active Record which is based off the Active Record of Ruby fame.  It’s really straightforward and makes building queries a helluva lot easier than I’ve done it in the past.  For instance, in SMS 2, there might be a query that looks like:

$query = “SELECT * FROM sms_messages WHERE message_id = 1″;
$result = mysql_query($query);

That’s a very simple query and too tough to write.  CI makes it a tad easier:

$query = $this->db->get_where(’sms_messages’, array(‘message_id’ => 1));
return $query;

That example may not seem like it’s a lot more efficient, but as the queries get bigger and bigger, the Active Record code doesn’t get that much bigger.  Take another query for example:

$query = “SELECT a,b,c FROM table WHERE var1 = ’something’ AND var2 = ’something else’ AND var3 = ’something completely different’ ORDER BY d ASC”;
$result = mysql_query($query);

Again, not too bad, but here it goes in CI:

$this->db->select(‘a,b,c’);
$this->db->from(‘table’);
$this->db->where(‘var1′, ’something’);
$this->db->where(‘var2′, ’something else’);
$this->db->where(‘var3′, ’something completely different’);
$this->db->order_by(‘d’, ‘asc’);

$query = $this->db->get();

return $query;

First reaction: but wait, that’s more lines of code, why would I want to do that?  Pretty simple answer actually: the first query only works in MySQL, the second one, works in MySQL, MySQLi, MS SQL, ODBC, Oracle, SQLite, and PostgreSQL … all by changing a single line of code.  CI makes it a lot easier to build applications that work across multiple platforms.

To that end, I can say that Anodyne will officially be supporting MySQL and MySQLi for SMS 3.  In addition, we’ll be providing at least experimental support for Oracle, MS SQL, and ODBC.  Finally, there will be some limited support provided for PostgreSQL as well as SQLite.  There’s a lot of testing that’ll have to be done with some of this stuff, but it’s really exciting to see SMS 3 be able to expand beyond just one database platform.

Seems like it wasn’t all that long ago that I was mentioning on the forums that SMS 2.5 was going to be switching form buttons from traditional buttons to image-based buttons.  At the time, it made a lot of sense.  Image-based buttons would give skin developers the opportunitities to make sure their skin buttons lined up perfectly with their skin.  Unfortunately, the idea never took off and there has only been one or two button sets released on the forums since SMS 2.5.  Combine that fact with accessibility and internationalization, and you can see why SMS is going back to traditional form buttons for version 3.0.

The decision wasn’t an easy one to come to, because I really like how some of the buttons look in SMS 2.6, but when it came down to it, it just wasn’t plausible for us to keep doing image-based buttons.  Why?  Well, the first issue is internationalization.  If the buttons have to be able to be translated, it’s better to have someone do all the translation from a single file and not have to go through and change all kinds of images.  That just makes it ugly.  So that was a major factor in the decision.  After that was accessibility and the fact that the images (currently) don’t have ALT tags, so screen readers would have a hard time with them.

Now, people shouldn’t be worrying that we’re gonna make buttons look ugly or anything, because we’re not.  It just means that people will need to actually style the buttons again, like they did before SMS 2.5.  There will still be the ability to set a background image on a submit button, but there will be a little more CSS involved than there is now.  Never fear though, we’ll have a full-blown tutorial on styling buttons when the time comes, plus, with the API, you’ll have plenty of time to be getting your SMS3 skinning skills up to snuff before release.

For those interested, the following is a good article on styling form buttons with CSS and PNGs.  Enjoy!

http://www.monc.se/kitchen/59/scalable-css-buttons-using-png-and-background-colors

No matter how much freedom you give a super user in SMS 2, there are still some things you really don’t want them doing.  I can think of a situation where a friend of mine runs an SMS 2 site, but he isn’t the CO, he just administers the site.  With the way players and characters are set up in SMS 2, he has to be on the manifest and have powers to update the site in the event that an update comes out.  Not ideal, but certainly better than giving someone who may abuse the power to update free reign to do just that.  An idea was floated for SMS 2.7 to have a system administrator flag and that some high-level tasks could only be done by those with system administrator status.  Since 2.7 isn’t happening any more, that got scrapped (along with maintenance mode, which is gonna come up in a minte here).

Enter SMS 3.

No timelines so far, so there’s no need to stop or remove features this early.  So a good place to start seemed like some of those features that got canned early on: the system administrator flag and maintenance mode.

With the separation of players and characters, it’ll be possible for my friend to be a player on a sim, but never be listed on the manifest.  That’s a great start so far.  On top of that, with system administrator status, his account would be protected from being deleted, so it isn’t like the CO could accidentally (or even purposefully) delete an administrator.  Then, there are just some things that only a system administrator can do.  For starters, SMS 3 includes the ability to “uninstall” the system, or in other words, remove all the database data.  Dangerous to be sure, so only someone who knows what they’re doing should have access to that.  System administrators.  SMS 3 also includes genres, but switching genres is tough too because it requires touching system files as well as updating the database structure.  Again, dangerous stuff if you don’t know what you’re doing, or worse yet, if you’re not supposed to be doing it.  System administrators.  Turn on maintenance mode, only system administrators can log in and see the system.  You get the idea, right?  System administrators have the power to do stuff that no one else should be doing.  At those screens, you’ll just be prompted for your email address and password.  If they’re correct, it’ll check to see if you’re a system administrator and if you are, it’ll let you through, otherwise, you get an error.  Pretty simple really.

Next on the list, and mentioned briefly above, is the new maintenance mode.  This was something requested after development ended for SMS 2.5 and it was put on the list for 2.6/2.7.  When 2.7 got cut, so did maintenance mode simply because of the number of changes that would’ve had to have been made.  It’s definitely something that I wanted to visit though, because it’s a very useful feature, especially if you’re updating and/or testing the system for something.  It’s a simple thing that gets turned on or off by a system administrator and viola, everyone else is locked out until you turn it off.  It’s a little thing, but I think a lot of people are going to appreciate the feature once they start to use it.

It’s a pretty popular question these days: “when is SMS 3 gonna be ready?”  Anyone who knows me will tell you that I laugh at those kinds of questions.  The simple fact is, web development is tricky business.  Things are more complicated than you expect or things in real life creep up and you don’t have the time to work on these things, so it’s not like we can just say “oh yeah, it’ll be finished on date X.”  SMS 2.6 is a great example of that.  The original roadmap put the release of 2.6 at late October with 2.7 following 2 or 3 months later.  Obviously that didn’t happen.  Here we are moving into the middle of July and we’re just finalizing 2.6, and 2.7 has been cancelled altogether.  It’s just one of those things where I couldn’t anticipate work hitting so hard, then getting laid off, then getting a new job and having to get into the swing of things there.  You can’t plan for those things.  So, whenever someone asks me that question, I get a good chuckle.

I do realize, however, that part of it may be my own fault.  After all, SMS 2.0 was released on July 24th of 2006 and by the end of January 2007, we’d released two minor updates to 2.0, 2.1 (with 1 minor update), 2.2 (with 1 minor update), 2.3 (with 1 minor update), and 2.4 (with 5 minor updates).  Six months and we pushed out 13 updates to SMS 2.  By anyone’s standards, that’s pretty good.  There was then a decent lull of six months before 2.5 hit.  In the last year, we’ve released 7 minor updates to 2.5 to address various issues.  The next 12 months will probably be even less.  We’re anticipating only a couple of updates to 2.6 then nothing until 3.0 (which of course, will be 1.0 of a new product name).  But really, can you blame me for pumping updates out so fast?  After all, I was in college with not much too do and I spent a lot of time developing.  Now, my time is spread a bit more thin.

Still, I don’t want this to just be a post where I tell everyone to calm their jets about SMS 3.  My goal here is to make it very clear why SMS 3 is gonna take so long to develop.  First thing on the plate is, of course, my own personal time.  With a new job, simming obligations, and keeping a personal life, my free time isn’t as plentiful as it used to be.  I’m okay with that.

Second thing is the scope of the project.  For anyone following the blog, you know that we made the decision to switch over and use a 3rd party framework called CodeIgniter.  It really is a fantastic framework that I’ve been very happy with so far (more on that in another post), but the downside of moving to a new framework is that the entire application has to be re-written … from scratch.  On top of that, we’re looking to make lots of improvements to the current code, and that takes a little longer.  Something similar happened with SMS 2.  In December of 2005, I sat down with a pen and paper and started mapping out my own RPG management system.  Jon Matterson was working on SMS 2, but I wanted to go in a different direction with the whole thing, so I set out to build my own.  I got a lot of work done on it before Jon asked me to use my code and take over SMS development in March of 2006.  I busted my ass for 4 months and had the help of Nate Wharry to get it to a point where it could be released.  For anyone who remembers 2.0, you know it had a lot of bugs and a few missing features.  Essentially seven and a half months of hardcore development and it still wasn’t right.  This is a bigger project by leaps and bounds, hence, more time.

Third, and finally, there really is no rush.  Would it be nice for everyone to have it now?  Absolutely.  But, we’re not going to rush to get it done either because then we’re just gonna make mistakes.  Our goal is to put a wish list together and get every single thing off that wish list into the system.  I made the mistake with SMS 2.0 of dropping features off the list and pushing them to later releases for the sake of getting it released sooner.  In retrospect, that was a bad decision, and one that’s not going to be duplicated this time around.  We’re going to make sure that we release SMS 3 and don’t have a wish list building for the .1 release.  It’ll take a lot of work, but in the end, it’ll be worth it because it’ll be truly complete.

So when do we expect to release SMS 3?  Honestly, probably anywhere between 12 and 18 months from today.  A long time, yes, but in the end, definitely worth the wait.  It’s a cliche, but oh so true: the best things in life (or in the case, simming) are worth waiting for.