I’ve received some good feedback on Slideshow JS, and some people have even emailed me with contributions and/or ideas. I’ve got a list of small fixes and features that I hope to eventually implement, but it may be a while before that happens as I’m busy with a couple of other things.

If you’ve used it and have a feature request or have discovered a bug, please email me at tom at tommcfarlin dot com and let me know!

I’m currently working on a web application and am trying to take advantage of the ASP.NET AJAX framework (which I think is kinda weak is comparison to some other frameworks, but I digress).

I was attempting to use the modal pop-up control, but the framework is apparently manipulating a node in the DOM before it has been closed. If you check out Microsoft’s support page, you’ll notice that they don’t have any real solutions - only workarounds. Lame.

Unfortunately, none of these workarounds are feasible given the current environment in which I’m working so I’m having to essentially create my own modal pop-up. If you’ve got experience with this issue and have come up with a solution (versus a work-around), please leave a comment.

Edit June 5, 2008: Commenter tbela99 suggested verifying that all of your existing XHTML is well-formed (with no closing tags). This is always a step that should be done prior to releasing; however, it’s a difficult thing to do whenever you’re adding functionality to a project that has already been released. tbela99 made a couple of additional suggestions that are more JavaScript oriented, as well - check out the comments.

Recently, I purchased an LG Voyager. Since my previous phone was a smart phone, I did a massive amount of reading and debating before purchasing the Voyager - I actually wanted to downgrade my phone, but not lose a lot of functionality that I was used to having. The Voyager is not a smart phone, but it has a lot of features that allow me to maintain the same features, which is what I want, and it does so for less than half the cost. After using it for a few weeks and finding that I do not miss my smart phone at all, I figured I’d share my thoughts of my experience with some of the features of the Voyager that allow me to maintain all of the same functionality as a smart phone (for much cheaper).

A note about Outlook and Google services
It’s important to note that if you’re looking to know if the Voyager will sync with Microsoft Outlook for email and calendar, then this review is not going to cover that topic. I sync everything with Google services and Google provides a lot of functionality that makes it easy to push their services to cell phones via SMS. I also want to add that the Voyager comes with a full HTML browser so it is possible to check your Outlook email via the web interface, but that’s not the focus of this post.

What I wanted out of a phone
As previously mentioned, aside from making calls and sending/receiving text messages, I want my phone to provide access to my email, my calendar, and to have the functionality that will allow me to casually browse the internet to, say, read my RSS feeds. In addition to access to these services, I’d like my phone to ping me when I’ve received a new email and whenever I’ve got a calendar event about to occur.

Additionally, as much as I love having the full QWERTY keyboard, I found that I actually missed sending quick text messages using the numeric keypad. Smart phones are wide enough such that it basically requires two hands to type any type of message and that frustrated me at times. Luckily, the Voyager has both.

Lastly, I ended up disliking Windows Mobile - I probably should have seen that coming, but either way, I digress as that isn’t the point of this post. Basically, I wanted to “de-grade” to a dumb phone from a smart phone in order to save money, but maintain smart phone functionality all the while.

HTML Browser
The first thing I want to point out is the quality of the browser on the LG Voyager. It’s a full HTML browser (versus the usual WAP browser found on most dumb phones), so, excluding things such as JavaScript, the phone renders pages almost exactly the same as you’d see on your desktop. Matched with the speed of the Verizon EV-DO network, you get a really solid browsing experience. The browser was one of the selling points of the phone for me - with this browser, the touch screen, and the EV-DO network, I have web access to almost all of the usual pages that I use. Most major sites also have mobile version available, such as YouTube, Facebook, Flickr, and Google, if the standard version doesn’t load.

Getting Email
Because I maintain everything using my Gmail account (with the exception of work email), I had been syncing my previous phone’s email client using IMAP with Gmail. This proved to be nice, but, seeing as how I’m at a computer most of the day, the benefits of IMAP weren’t as strong as I could basically just respond to the email from my machine. The phone ended up, more often than not, notifying me of whenever I had received a new email. In the rare case that I wasn’t near a computer, it was nice to be able to send an email from my phone.

Since the Voyager is not a smart phone, it has no true email client that most phones like the Treo or the Blackjack have; however, Gmail offers the ability to automatically forward emails as they are received. Since you can send a text message to any phone on the Verizon network at [phone-number]–>

Obviously, this doesn’t allow me to respond to an email, and the email is truncated because of space limitations of cell phones, but it provides notification that I do have an email so I can respond whenever I get back to a computer, or I can open up the browser on the phone to respond if I absolutely need to respond at that time.

Calendar Notifications
The second major point that I want out of my phone is the ability to have my schedule available with me, and to have the ability to add, remove, and update items on the go. With my previous phone, I was able to do this; however, I’d then have to run the synchronization application in order to have both calendars updated. With Google Calendar, I can keep all of my data centralized, and, by using Google Calendar sync, I can sync my work calendar with my Google Calendar automatically.

Similarly with email, I’ve setup SMS calendar notifications to be sent to my phone 15 minutes prior to an event starting. This works much in the same way that Outlook notifies me on my desktop at work, and also the way that Windows Mobile’s calendar works. If I need to see a more detailed schedule, I can again launch the browser to view and/or modify my events without having to initiate a syncing process.

Miscellaneous
The phone also has other good features, but the primary thing I wanted to show was the ability of using the Voyager as a smart phone though it lacks features that most smart phones have. In addition, Verizon’s BroadbandAccess plan for smart phones cost $50 a month whereas dumb phones have unlimited web access for $15 month. With this phone, I’ve been able to save money without losing any features of a smart phone.

Until later,
Tom

Recently, I’ve been working on a project that will ultimately require new users of the system to create their accounts with stronger passwords than the application has typically allowed. Existing users will be required to update their accounts with stricter passwords. The software is a distributed web application, and the code that I am working is a the application layer.

I’ve used a couple of design patterns to essentially build a framework that allows us to setup a password object and add and remove policies to it at runtime via XML flags. Policies are nothing more than rules that will evaluate the password against a single requirement, such as its length or whether or not it contains a specified number of digits and/or symbols. For every policy that the password is evaluated against, the framework will generate a set of error messages as well as a password strength rating and will return them once the rating process has completed.

Ultimately, this will all be bound to the front-end when the overall project is completed; however, for now, there’s no UI against which to test the framework’s performance. Since testing is arguably one of the most important phases of software development and since there’s no true UI to provide any level of feedback from this framework, I chose to take a true test-driven development approach to the password and its policies.

Write Test Cases First
Because we designed the software upfront, we new how the system should behave before we actually began building it. This made it relatively easy to write test cases first - we new what our inputs were going to be and we new exactly what outputs to expect for each case. After writing these cases, I found myself to be more conscientious of the code I was writing for the actual system.

Although it’s wrong, it’s not uncommon for developers to first build their application and then right the test cases (numerous articles are available online about this). This is incorrect for a number reasons primarily because you’re basically writing tests for a system you’ve already built - in the same way that writing code after the test cases made me more aware of what I was writing, writing your test cases after building the components will likely result in writing cases that fit the existing system. This completely misses the mark on the purpose of Test Driven Development. Writing test cases to fit the software is backwards - write your software to fit your test cases.

How long did it take?
This took a little bit longer to do for several reasons. First off, writing a test suite to cover branches, statements, outputs, etc. of your system adds to the amount of time to complete the project (or phase of the project). Couple that with updating various components and then developing new test cases for those changes, you’ve got a pretty full plate of things to maintain. Ultimately, it may result in a slightly longer period of time to complete, but if this is taken to account in project planning it shouldn’t be that big of a deal. Additionally, you’re only increasing the quality of the software, so I’d argue that it’s worth it more often than not.

Combinations and Permutations of Policies
This was the fun part. Initially, we started off with a small set of policies; however, as the project matured and we gathered more input, we had to create additional policies. This resulting in us testing possible error messages as well as the various strength ratings for each arrangement of the policies. It’s really not that big of a deal if you’ve got a couple of people working on the project, but it’s easy to see how fast something can increase in complexity by simply introducing one or two more components.

Overall Impressions
Building this framework using Test-Driven Development was great. It prevented the project and it’s various combinations of outputs from getting away from us very early in development. It also resulted in a great feedback of a system that doesn’t have an interface with which to interact. Finally, it generated a strong sense of software quality once the system was developed and all of the test cases passed.

Maybe I’ll revisit this project to show off the interface once we’ve finished it, but that’s not really something I’m planning to focus on showcasing. We’ll see.

That’s it for now,
Tom