DougHughes.net

Reactor Reaches Beta Candidate 2 (BC2)!

At long last, Reactor has reached Beta Candidate 2. The API is feature complete and reasonably stable. I haven’t made any significant changes to the API in more than a month. Since the last major update I’ve been working on bug fixes and fine tuning the API to the point where it’s stable and useful.

Over the past few weeks I’ve focused on updating the existing documentation to be accurate with the current API. I’ve also spent quite a bit of time writing new documentation. It’s not nearly complete yet, but it’s coming along quite well. The XML configuration tags are all documented in detail now.

Adobe generously donated license of RoboHelp to the Reactor project and I’ve now converted all the documentation. This allows me to generate several different versions of the docs. You can see the current documentation here: http://www.alagad.com/livedocs/Reactor/Reactor_Documentation.htm.

Note, if you get the documentation from subversion you will want to look under the /Documentation/Documentation/!SSL! folder. (Why? I don’t know, ask the RoboHelp programmers.)

As a note, with each major release I plan to update the documentation online, but not in between releases.

Before I reach a 1.0 release I will be putting together a nightly build system. This nightly build system will create a zip file for each build, which will make it much easier for those who don’t want to use SVN to get the latest and greatest code.

See this link for details on what’s changed in BC2: http://trac.reactorframework.com/reactor/trac.cgi/milestone/Beta%20Candidate%202%20%28BC2%29

This release has been tagged in Subversion as 1.0BC2.

The next step from here is Beta. Before I hit beta I want to have all of the documentation written, a unit testing and nightly build framework, and a project site (which might just turn out to be my trac site at http://trac.reactorframework.com.).

Once Reactor enters Beta the API will not change until after 1.0.

Please, download BC2 of Reactor and beat on it. If you find bugs or problems please log them to the bug tracker here: http://trac.reactorframework.com/reactor/trac.cgi/newticket.

If you have questions or concerns please send them to the mailing list. Here’s a link to instructions on joining the mailing list: http://trac.reactorframework.com/reactor/trac.cgi/wiki

Reactor Volunteers Needed

As I’ve said in the past, we’re getting pretty close to a beta from Reactor. As a part of this, I’m trying to formalize the development process for reactor to make it a little less ad-hoc than it has been. To support this, I need to ask for a couple volunteers from the crowd to take ownership of specific things, listed below.

Unit Tests

I was wondering if there were any experts in unit testing out there. I’m interested in creating a set of unit tests that can easily be run on all of the supported DBMS. Essentially I want to create one set of tests that can be run on all of the DBs. The point of this is two-fold. 1) To prove that reactor behaves the same with all supported DBMS and 2) For regression testing as changes and bug fixes are added to Reactor. I plan for the unit tests to be supported and extremely important to reactor as we move forward. Reactor is getting too big and too complicated to safely make changes the way I have been.

Nightly Builds

I would like to ask a volunteer to write an ANT script (or something akin to one). What I want this to do is, on a nightly basis, check to see if there are any new commits to the Subversion repository. If there are, it would check out all of the source code and the unit tests and run all the unit tests on all of the supported DBMS. A report would be generated which included the results of the tests. Additionally it would (might?) create a zip file for that nightly build that anyone can download if they want. The purpose of this is to keep a running tab on the quality of the project and to allow easy access to the history of the project. I’m open to suggestions on this.

Test Server

Is there anyone out there in hosting who would be willing to donate an old server that we could install ColdFusion on as well as all of the supported DBMS systems? It doesn’t need to be a nice server, it just needs to work well enough. I expect that this server would not be publicly available and that it would only run the development versions of all of the software. I have licenses for windows that I can provide. (Maybe this should be a dual boot or a virtualized system so that the tests can be run on linux too? Once again – I have licenses.) Anyone willing to help with this? (Please!)
Presumably these three people would work closely together.
Thanks!

Reactor Trac Site Ready

Simeon Bateman was kind enough to offer Subversion hosting for Reactor as well as support for Trac, a popular project management tool that integrates nicely with Trac.

The Trac site can be used to learn more about Reactor as well, to track the progress of the project and to submit bug reports and feature requests.
I spent a bit of time tonight getting the site built out a bit and it’s now ready for use.  To see the site head over to http://trac.reactorframework.com.
 

Where Did Everyone Go?

As a number of people realized (and pointed out, thank you) a number of prominent ColdFusion websites disappeared from the face of the internet for several days.

Who was gone? Well, doughughes.net, clearsoftware.net, model-glue.net, boyzoid.com and more. Scott, Joe and myself all share a server.

What the heck happened? It’s a long story, but I’ll try to keep it brief. Over the weekend I decided that my server seemed awfully slow and that it needed a reboot to reset things. It’d been a while, so what the heck. Unfortunately, the server went down but never came back up. The server was hosted with Server Beach, who does not have a tech support phone line. All I could do was submit a trouble ticket.

It took forever for anything to happen and ServerBeach failed to let me know what was going on. Eventually I found out that the server was failing to boot due to a bad hard drive and that ServerBeach was rebuilding the server on a new hard drive.

This is where it gets bad. ServerBeach royally screwed up.

Let’s take a step back. The server had two hard drives, one for production data and one for backup. (I’m poor! I can’t afford hosted raid or tape backup systems!)

What happened? I’m not sure exactly, but somehow the old backup drive was repartitioned and formatted. Bye bye backups.

So now I had one bad hard drive and one toasted backup drive. Crap!! Luckily the unbootable drive was working enough that I could copy all of the most important data off of it before it finally kicked the bucket. Because of this stroke of luck I only lost one database and that was for my brother who could care less. (Phew.)

This ticked me off enough to do some research on other hosting companies. I’m not quite sure how I managed it, but HostMySite.com gave me a fantastic deal on a dedicated managed server. To save them from having people knocking down their door for the same deal, let it suffice to say that I have a better server with more of everything for less than it cost me at ServerBeach. It saved enough that I can now afford a tape backup!

The next problem was getting the server setup. HostMySite.com may have a 24 hour provisioning service level agreement, but that’s not worth a damn when there’s no RAM for the server. So I had to wait close to two days before I could even start getting things set up on the new server.

Joe and I stayed up most of last night getting things configured on the server. Unfortunately, today we ran into the next problem, DNS. Unlike ServerBeach, HostMySite.com doesn’t provide any way for users to add new domains to their DNS servers. As a result it took all day to get the DNS configuration setup. In fact, there are about 20 domains on this server that aren’t set up yet.

What a mess. I can’t wait to cut the cord with ServerBeach. I can forgive a hard drive failing. I can forgive them not discussing it with me. I can’t forgive them formatting 80 gigs of backup data.