For anyone who’s done any serious poking around with skins and seamless substitution, you’ve probably noticed that the AJAX modal windows aren’t included in seamless substitution.  Many moons ago when that decision was made, there was a reason, but thinking back on it, I couldn’t recall the reason, so I’ve changed the AJAX modal windows to be included in the seamless substitution process.  Like pages, Javascript and images, you can override the system default for the modal windows now.  The user guide is being changed and the updates will be uploaded to the user guide in time for the December development build.

Version control is probably one of the most important things about Nova and SMS that no one ever sees or knows anything about.  Since November of 2007, Anodyne has stored our source code, be it SMS or Nova, in Subversion repositories hosted by Google Code.  These have been fantastic because it allows us to keep our code updated in a central place and then pull from there to various computers.  SVN is also great in the event of a hard drive failure or some other catastrophe.  The last thing we want is to lose all of our hard work.

Admittedly though, there’s a learning curve to version control and for me, it was pretty steep for SVN.  It took a solid month or two before I was comfortable doing tasks in SVN like tagging and branching (committing and updating is pretty easy).  In the summer of 2008, as Nova development was ramping up, a company called Made By Sofa released an SVN tool for OS X called Versions which took the command line work out of it and gave a gorgeous graphical interface for working with SVN.  For over a year, I’ve used Versions to manage the repositories of SMS and Nova, but recently, I’ve gotten more and more fed up with SVN and wanted to find an alternative.

For starters, SVN is slow.  Even a fast commit takes 30 seconds to run.  Second, you need an active Internet connection to use SVN.  You can make all the changes to the source code you want, but you have to be connected in order to commit the changes to the remote repository.  Third, it’s a space hog.  Early on in the process, I zipped up the SMS archive and threw it up on the server for people to download only to realize the archive was over 7MB instead of it’s normal 3.  SVN stores hidden folders in every single directory of the repository, so it’s a hog on drive space as your project gets larger.  Add to that gripes with merging branches into the trunk and having to learn a specific workflow (trunk, tags, branches) for projects and it was time to start looking for something else.

Recently, Google has started offering Mercurial as an alternative to SVN and I thought that’d be a great way to go since it wouldn’t require moving the repositories anywhere, just changing the protocol used.  There was also Bazaar to consider, though I hadn’t heard much about it.  But really, the five hundred pound gorilla in the room was a tech buzz word of late: Git.

So the research began and the more I looked at Git, the more I fell in love with it.  Git stores everything locally, so it’s incredibly fast (a commit takes about 3-5 seconds on my Mac) and doesn’t require an active internet connection to commit, only to push to a remote server.  Git doesn’t crap up your directories with hidden files, just a single hidden index in the root directory.  Even better.  Git doesn’t force you into a certain workflow structure and it’s just a more flexible option on all fronts.  Because Git is distributed and open source, in the future, Anodyne could easily get a server and install our own instance of Git for storing our repositories privately if we wanted to, which is a huge advantage.  (Yes, I realize you can install SVN on a server, but from what I’ve read, setting up Git on a server is easier.)  The final straw was remote hosting by GitHub that was easy to use and free.  Really, it was a no brainer.

The decision was made, it was time to move SMS and Nova over to Git.  Of course, there’s a lot of trepidation over such a move.  Instead of keeping the history, I decided that a simple SVN export of the repositories and a commit to an empty Git repository was the way to go.  All in all, the whole process took no time at all and before I knew it, I was pushing changes up to GitHub for both SMS and Nova.

The beauty about using GitHub is the potential for user interaction.  To date, Anodyne has always kept its source code closed up until release and put extreme limitations on what users can do with the source code.  Moving forward, the Nova license is more relaxed and combining that with GitHub gives the potential for users to fork Nova and add features or fix bugs or translate Nova then request a pull.  If it’s something we think would be good in the Nova core, we can simply merge those changes in; if not, then that person can simply point people to their GitHub page for access to their Nova MOD.

I’m really excited for the possibilities and flexibility that Git offers us for SMS, Nova and any other projects moving forward!

Now that M7 has officially begun, I’ve finally started to build Thresher, Nova’s integrated mini wiki.  A system like this is actually kind of old hat for me since I’ve spent the last year and a half building a similar type of system at work with drafting and what not (not quite a wiki, but arguably drafts are a big part of a wiki).  When building something like a wiki, it was important to figure out the best way to format text, because it’s different from everything else on the site.  That meant rich text editing wasn’t an option, it was a requirement.  So the question became, what format should it use?  There are a handful to choose from: HTML, BBCode, WikiCode, Markdown and Textile.  All of them are unique and have their own advantages, but which would be best for Nova to use?

From the start, HTML seemed like the no-brainer.  It’s widely used and there are lots of rich text editors out there that support outputting HTML.  But there are those who no doubt would love to see WikiCode used so they can migrate their stuff from a wiki to Nova.  Certainly the idea was incredibly appealing.  Then I stumbled across markItUp!, a jQuery plugin that allows not only HTML and Wiki formatting, but also BBCode, Markdown and Textile.  Then it hit me: why do we have to choose?  All this time I’ve been talking about how Nova gets out of your way and let’s you play the game, so shouldn’t the wiki be the same way?  Absolutely.  So out of the box, Thresher will allow admins to select either HTML, BBCode, Markdown or Textile for the format used.  But wait, what about WikiCode?

In the course of researching parsers for the different formats, it was clear that BBCode, Textile and Markdown were the easy ones to find and use.  In fact, in a matter of an hour, I had those 3 formats working like a charm.  The WikiCode parser was another story.  I spent two days researching parsers for WikiCode and found several, but they were either incomplete, had crazy requirements, or required the full MediaWiki core in order to work properly.  It just wasn’t worth the overhead it was causing, so I dumped WikiCode from the options.  If you know of a lightweight, PHP 4 and 5 WikiCode parser for Anodyne to look at, please leave a comment, because it’s one of those things I’d love to have in Thresher.

Thresher is going to ship with HTML as the default because it’s the fastest and most efficient way to display wiki pages.  Why?  Because there’s nothing to parse.  Since browsers understand HTML, the content can be output directly to the browser without having to go through a function or class to be translated into HTML.  The BBCode, Markdown and Textile content has to go through a parser, which while it may not take long, is still more intensive of a process than outputting straight to the browser.  Still, if you’re more comfortable writing code for one of those styles, knock yourself out.  Thresher is there to (hopefully) make life as a CO a little easier.