So it’s been over two weeks since I posted anything. The reasons are two-fold. At first, there just wasn’t anything worth posting about. Then I got so busy I didn’t have time to post anything. Also I was in this weird funk for a while where I just couldn’t seem to focus on anything.
Fortunately, I’ve adapted to the new term. My schedule this term is very irregular and, oddly enough, results in my having zero classes on Friday. Sounds wonderful, doesn’t it? And it would be… if it weren’t for the 8AM class I have on Mondays and Thursdays, one that’s two hours long, no less. Do you think a legal ban on 8AM classes would pass Constitutional muster?
Anyhow, this term is going to be busy for me. Engineering Economics is not exactly a walk in the park (although it might help if class didn’t meet at a time when everyone is still half asleep!) and the inquiry seminar is not going as well as I’d hoped. The fact that the seminar only meets once a week for two hours seems very unhelpful to me; it would probably be better if it met twice a week for one hour, because it’s easy to forget about it. The IS is going to culminate in a historical paper; finding time to work on it should be interesting since Matt and I are going to have to write an IQP report this term too.
As for the IQP, we’ve made some significant strides since my last post. Matt’s done a lot of work restructuring the internals of our GUI, including solving the garbage collection problem. At the same time, he reworked some of the rougher areas of the GUI that I had ported from the old system. All this means that we are now finally where I wanted to be from the beginning: a few commonly used screens (like the Dashboard) are saved and re-used rather than being discarded and then re-created, but most screens just get tossed when we’re done with them.
While Matt was doing that, I was cleaning up some smaller issues. For instance, that infernal logout button FINALLY got what was coming to it. I also did some restructuring so that screens that need to know which project to display data for “pull” the project from the ProjectData singleton rather than trying to “push” the project to the screen from whoever was calling it. The push method was creating a lot of headaches and making the code far more complex than it needed to be. I don’t know if I ever mentioned this before, but MXML components are not allowed to have custom constructors, so instead of just passing the project into the screen’s constructor, we were being forced to construct the screen and then make a separate call to set the project. This was creating a bunch of problems, not the least of which was that when we set the project, the loading box usually didn’t exist yet, which was constantly triggering NPEs. Finally, I also implemented the ability to delete projects. Our good database design pays off here, because a single statement to delete the project cascades through the rest of the database and also removes all of the project responses.
The list of unimplemented items is beginning to narrow now. I still don’t think it’s reasonable to say we’re at beta yet, because we still have plenty of buttons that don’t do anything. As someone pointed out to me, however, it’s okay if we don’t make it past beta; half of Google’s products are still in “beta” after years of development! More seriously, though, I’m still confident we’ll have produced something worth using, not to mention something that teams after us will actually be able to extend. It’s likely to be missing some of those “wishlist” features but all of the features that are implemented will work the way they are supposed to.
The next thing I’m going to work on are some of the account management features. Right now, once a user creates an account, they’re stuck with everything they entered. At the very least, users need to be able to update their e-mail address and change their password. Also, we don’t have a system for handling forgotten passwords. I think the fairly standard system of “enter your e-mail address and we’ll send you a link that lets you change your password” should do nicely, but this will require some additions to the database schema and implementing it in a secure manner could be tricky. I can’t really say how this will play out since I’ve never needed to implement a forgotten password facility before. And before someone suggests it, I am not going down the “secret question” route. I hate those infernal things; most of the time, I have even less an idea of how I answered the question than I do of what the password might be!
Finally, for anyone wondering where the Flex Sucks: Greatest Hits! compilation is, I will be posting it at some point soon, possibly even later today.
Pingback: Flex Sucks: Greatest Hits! « CaptainRichard's Blog