Driscoll Web Development Blog

Get information, tools, news, tips, and more from the expert web developers at Driscoll Web Development.


Monday, February 23, 2009

Driscoll Web Development Launches iamguiltyof.com: the social confessional

On February 19, 2009, we launched iamguiltyof.com: the social confessional. As the name of the site might imply, the purpose of iamguiltyof.com is to allow people to make anonymous confessions of guilt and follow others' confessions in real-time.

We're very happy with how our first weekend went: iamguiltyof.com drew over 1,000 visits from over 700 unique visitors in just 4 days. In order to keep the momentum going we've added a Twitter bot into the mix so that users can tweet their confessions and see them posted on iamguiltyof.com AND get updates on their confessions and others' confessions via the bot's timeline (for more information on the iamguiltyof.com Twitter bot, read this).

Some of our users have drawn comparisons between iamguiltyof.com and similar sites, but most (if not all) have cited that iamguiltyof.com offers a distinct advantage with its real-time delivery of confessions to users. That, we believe, along with multiple points of entry to the application and a clean and simple interface not unlike that of Twitter, makes iamguiltyof.com a leader in the social confession / gossip space.

But, don't take our word for it: we strongly encourage all readers to go to iamguiltyof.com and check it out for themselves. Furthermore, we'd love to hear your feedback on the site, either via comments to this post or via the feedback form that is available on iamguiltyof.com

Labels: , , , ,

Thursday, January 29, 2009

Why Use the BitlyXAPI?

As you most likely saw in my last post, I've just released the BitlyXAPI .NET Library. I created this library for two reasons: first, it is my entry to the bit.ly API Contest; second, I wanted to have some fun with my .NET chops while at the same time doing something helpful for the web development community. The BitlyXAPI .NET Library is free under the terms of the GNU GPL, so clearly I'm not looking to make a profit off this nor am I attempting to prevent other developers from deriving their own libraries from it.

So, if you're a .NET developer and you're reading this, you're most likely wondering what the BitlyXAPI Library can do for you - which is not a topic that I've previously addressed in-depth. I wanted to spend some time highlighting what I believe to be the key advantages to using this library in a project that implements the bit.ly API.

The BitlyXAPI Library is Fast
Due in no small part to the fact that the bit.ly API itself is quite speedy, I've done my best to keep the BitlyXAPI Library's overhead low so that there is little (if any) perceptible difference between using the Library and calling the bit.ly API directly.

The BitlyXAPI Library is Open and Adaptable
I'm not a huge fan of most API wrappers because they often limit what you can do, so I purposefully set out to write a library that would allow developers to leverage the bit.ly API without necessarily being put into lock-step with the API's implementation. Rather, developers can use the BitlyXAPI Library as it fits into their applications rather than build applications that strictly adhere to the functionality of the library (which is, unfortunately, the case with most API wrappers). Granted, this level of adaptability does have its drawbacks; for instance, one might notice that none of the bit.ly API methods are defined in the BitlyXAPI Library - meaning that one would have to write one's own Shorten() method in their application should they choose to do so. However, I feel that the aforementioned example highlights why the BitlyXAPI Library is so great, because it potentially allows developers to easily write complex methods with the BitlyXAPI Library.

The BitlyXAPI Library is Event-based
I took an asynchronous, or event-based, model into account when I wrote the BitlyXAPI Library. It allowed me to write lean, granular, and easily maintained code in the Library itself. However, it also gives developers the advantage of writing lean, granular, and easily maintained code in their own applications. And, the event-based model gives developers the assurance that their application won't hang if a method call doesn't return a result.

The BitlyXAPI Library Handles Menial Tasks
For most, creating an application that imports data from an external resource is excruciating because so many lines of code must be dedicated to checking that the application has network access, then checking that the application can access the specified resource, then cleaning up when the resource is no longer needed, etc. Internally the BitlyXAPI checks with every call to the bit.ly API that the API is accessible to the application, and throws a BitlyException if the service is unavailable for any reason. The BitlyXAPI also performs its own garbage collection on the resources that it uses. Therefore, the developer can focus more on developing a solid application and spend less time writing code to perform menial tasks.

The BitlyXAPI Library is Well-documented
Another one of my pet peeves about many (but not all) API wrappers out there is their lack of documentation and/or working samples. Upon decompressing the BitlyXAPI Library archive a developer will notice the ReadMe.txt file along with a small sample class and console application. The ReadMe.txt file provides full documentation for the BitlyXAPI Library, while the sample class and console application allows the developer to see the BitlyXAPI Library at work - right out of the box.

The BitlyXAPI Library is Free
By "free" I don't mean "no-cost", although the BitlyXAPI Library is provided at no-cost as well. Rather, I mean that because the BitlyXAPI Library is licensed under the GNU GPL, developers are free to request and obtain the Library's source code so that they may alter it to better meet their needs, or to create an extended library from it. The only thing I request is that out of respect developers acknowledge Driscoll Web Development and/or Brian Driscoll (me) in their applications - and that they provide a link to the original BitlyXAPI Library somewhere in their application's documentation.

Now that you've read this (and assuming you're a .NET developer who's interested in the bit.ly API), I hope that you'll consider using the BitlyXAPI Library in your project. If you create an application with the BitlyXAPI Library I invite you to comment on this post with a link to your work.

The library is available for download here.

Labels: , , , , , ,

Tuesday, January 27, 2009

Now Available: The BitlyXAPI Library for .NET Development

Introducing: the BitlyXAPI library for .NET development!

This library allows .NET developers who wish to leverage the Bitly API in their applications a way of quickly implementing the Bitly API in their libraries/apps without having to worry about the plumbing, constructing calls, etc.

The zip file includes the BitlyXAPI DLL, a sample application (with source code), and documentation.

Download the BitlyXAPI package here:

Labels: , , , , , , ,

Friday, January 16, 2009

Creating a Read-Only Numeric Stepper Component in Flash/Actionscript 2.0

While working on a project recently I spent some time getting to know the Numeric Stepper component. Anyone who has worked with the component most likely knows about its most obvious shortcoming: the text field within the component is read/write! Of course, the actual value associated with the component only changes in response to events fired by the Mouse or Key (up/down arrow) objects, but nonetheless our client wasn't happy with the fact that a user could type in the text field.

So, I set about trying to make the text field read only. Based on my research I gathered quickly that this has been attempted before with varying results. One of the key issues that makes the proposition of "tweaking" a component difficult is the fact that a component class cannot be subclassed; otherwise, it would be fairly straightforward to create a new class that inherits from NumericStepper and simply add the necessary properties and methods to support read/write and read only modes for instances derived from the subclass.

With subclassing out of the question most of the developers' blogs I encountered suggested overriding methods of the mx.core.mx_internal namespace (from which the enabled property of the NumericStepper.inputField object is derived), however that's a bit cumbersome and a complex solution to what seems to be a relatively straight-forward problem.

Luckily for me, I've been playing around a bit with coding ActionScript Communication scripts, which are (more or less) ActionScript 1.0 scripts. In these scripts, the "easy" way to add properties and methods to a built-in class is to use the prototype object (i.e.: ClassName.prototype.someNewFunction = function(){...}). With that concept in mind I tried to see if I could use the prototype object to extend the capabilities of my NumericStepper component... and it worked! What follows is the code that allows you to do this for yourself:

1. Create a new Flash document.
2. Open the Components panel and drag two instances of the NumericStepper component onto the stage. Give the two steppers instance names of "myStepper1" and "myStepper2", respectively.
3. Add the following code to the Main Timeline of your document:

So, what does this code do, exactly? Well, the draw() method overrides the draw() method of the NumericStepper class. The only "new" functionality we've added is within the if-block; we test the instance's editable property, and if that property has a value of "false" then the component's text field is disabled. Otherwise, the text field is enabled (which is the default). All of the code that follows the if-block is the same as the NumericStepper's native draw() method.

The next two functions, setEditStatus and getEditStatus are simply getter/setter functions for the editable property.

Finally, I register the editable property with the component using the AS1-style addProperty method.

That's all there is to it! Now, to see this new property in action simply create a new layer on your main timeline and add the following code:

myStepper1.editable = true;
myStepper2.editable = false;

Go ahead and test out your movie. One instance (myStepper1) should have an editable text field, while the other (myStepper2) should not.

Happy coding!

(Download the source script for the extended NumericStepper here: http://blog.driscollwebdev.com/NumericStepperExtension.as)

Labels: , , ,

Thursday, April 10, 2008

Freshening Up

Things have certainly been busy here, so we apologize for the long delay since the last post. Here are how things are going from our end:

4 Out of 5 Stars
We're really excited that BuiltWith.com has given us 4 out of 5 stars for Technology and Site Optimization. Of course, having a standards-compliant website that plays nice with search engines doesn't guarantee visitors, but it does go a long way to ensure that our site is accessible from a multitude of different browsers and computer/monitor configurations.

Q1 Results
We finished Q1 2008 about 7% short of our revenue target. However we were able to put enough pennies in our piggy bank to write our bottom line number in black. It's pretty scary out there these days for most businesses, however we've been lucky to have steady work so far this year. We just hope we didn't jinx ourselves by saying that...

New Look
We've been looking long and hard at our analytics reports over the last few months, and the picture hasn't been great. Upon closer inspection we realized that we were putting our visitors to sleep with our rather lengthy and text-heavy homepage. So, we've reorganized our top landing page and restated our purpose to more accurately and more concisely state what it is that we do. We've also changed some other things here and there throughout the site, but it's hardly worth mentioning. You'll just have to check out the whole thing for yourself!

What We're Up To...
We're still toiling away with a rather large client, and it has been quite a lot of fun. We began working with the firm in December, and although initially we were assigned some web development projects, we've recently begun to geek out on object-oriented ActionScript code for their Flash-based content. It's really an exciting time for us, and we're thrilled to be kept on the ride.

(Sort of) New Year's Resolution
April 1 used to be the start of the New Year, so by our logic it's not too late for a resolution. Although we're busy with clients (and hope to stay that way), we're resolving to keep our site (and this blog, specifically) more up-to-date going forward. For those who read it, that is hopefully good news.

So, until next time...

Monday, February 18, 2008

Is Your Registrar's Multi-year Deal Worth It?

Almost every domain name registrar out there is offering a deal these days: pay up front to register your domain name over a multi-year period and save money. The question that my clients and colleagues alike invariably ask is whether or not these deals are worth it.

My answer: Maybe.

Realistically, whether or not a multi-year registration is worth the cost depends on a lot of variables. For instance, the first question I ask is "Will you still have a website in 5 years? What about in 10?", and, "If so, do you think your business' name will be the same as it is now?"

Usually the blank stare is enough to tell me that a 10 year deal is probably not a good investment. But let's assume for a second that my client knows for sure that her online venture will still be up and running 5 or 10 years from now. Is it still a good deal? Well, then it all comes down to finances.

Common Knowledge and Misconceptions
Of course it's your registrar's duty to make you think that you're making out like a bandit when you opt-in to a multi-year deal, which is why it likes to tell you what percentage you're saving if you take the multi-year option: "Save 50% with a 10 year plan!"

50% of what? Indeed, that is the question. By making some quick calculations it's usually pretty easy to see that you're saving when compared to 10 years at the full price (whatever that may be). What your registrar doesn't want you to know is that you may not be saving as much as you think.

Anyone who has been subjected to a collegiate finance course can tell you that $1 is worth more in the future than it is today. How is that possible? Well, imagine that you have $1 right now, and you put it into a high-yield savings account that has a 4% annual yield. A year from now your $1 will be worth $1.04. Hence, your $1 will be worth 4 cents more a year from now than it is today.

We can use a similar approach to figure out what $1 in the future is worth today. Again, let's imagine that the current annual interest rate on a high-yield savings account is 4%. We would like to know how much to deposit today in order to have $1 a year from now.

$1/1.04 = $0.96*
(*rounded to two decimal places)

So, we'd need to deposit 96 cents into our high-yield savings account in order to withdraw $1 a year from now. $0.96 is the present value of $1 in one year if the current interest rate is 4%.

Multi-year Discounts and Present Values
Now let's use what we know about present values to determine whether or not we're getting a good deal.

As of today, Register.com is offering multi-year registration of top-level domains at the following prices:

1 year: $35
2 years: $70
5 years: $149
10 years: $249

Clearly, the alternative to purchasing one of these packages is to simply pay the regular price of $35 per year. But, as we already know, $35 is worth less today than it will be in the future, so we need to know what the present value of making a $35 annual payment is over several years, keeping in mind that we'll be making our payment at the start of each annual period. The current annual yield of a business savings account with ING Direct is 3.75%, so the present value of $35 paid annually with an interest rate of 3.75% is:

1 year: $35
2 years: $68.73
5 years: $162.80
10 years: $298.23

From this we can see a few things:
  1. We will indeed save money if we opt for the 5 or 10 year plan. However, we are not saving as much as Register.com would like us to believe (for instance, we're really only saving $49.23 rather than $101 by going with the 10 year plan).
  2. We actually lose money by taking the 2-year plan.
Point #2 is important to note, as most of us would simply think that paying $70 for 2 years up-front is the same as paying $35 now and $35 a year from now, but it is not. Instead, we could pay $35 now and put $33.73 into a high-yield savings account earning 3.75% interest. In a year we'd have $35 which we could use to pay for another 1-year contract. Thus, our second year really only costs $33.73 rather than $35.

Deal or No Deal
In this case we see that the longer-term deals (5 and 10 years) with Register.com are certainly money-savers right now, but will they always be? Maybe, maybe not.

In our analysis above we assumed two things:
  1. The annual registration fee will remain constant at $35 over the next 10 years.
  2. The annual interest rate of our high-yield savings account will remain constant at 3.75% over the next 10 years.
If both of our assumptions remain true over the next 5 or 10 years, then we know that we've saved money by taking the multi-year deal. But what if we take the multi-year deal and one (or both) of our assumptions prove to be false? Let's find out what happens...

What happens if the annual registration fee changes?
If we take the multi-year deal and the registration fee changes then we may not have made a good deal. If the annual fee goes up, then clearly we'll have saved even more than we'd initially thought over the contract term. However, if the annual registration fee goes down, then it's certain that we're saving less than we initially thought, and it's possible that we're actually losing money over the course of the contract. It all depends on how much the annual fee goes down and how far into the contract term we are. Generally speaking, smaller price changes will have a greater impact earlier in the contract than they will later.

What happens if the annual savings yield changes?
Similarly, if we take the multi-year deal and the annual yield of the savings account changes, then it is possible that we've not made a good deal. Generally speaking, if the interest rate goes down then we'll have saved more money with our long-term contract than we initially thought. But, if the interest rate goes up then it's certain that we're saving less than we initially thought, and it's possible that we're actually losing money. Again, this depends on how much the interest rate goes up and how far into the contract term we are. And, just like price changes, smaller interest rate changes earlier in the contract will have a greater impact than the same changes later in the contract.

What happens if both the interest rate and the registration fee change?
Once again, the extent to which our potential savings is affected depends on how much each changes. If the interest rate goes up AND the registration fee goes down, then the two effectively compound and we'll have saved far less money than we initially thought when we signed the multi-year contract. However, if the interest rate goes up but the registration fee also goes up (or if they both go down), then it's possible that the two changes will simply cancel each other, and the net savings will be comparable to the deal we had initially.

Other Risks of Multi-year Deals
There are certainly other risks associated with multi-year domain registration contracts that go beyond interest rates and registration fees. Chief among your concerns should be the longevity of your potential registrar, however there are other things to consider as well. Be sure to read your contract carefully, as there may be additional fees incurred for certain services, and the terms of the contract might make it painfully difficult and costly for you to get out of the deal if it goes south (or if you find a better deal...).

At the end of the day, the question of whether or not you should engage in a multi-year domain name registration will depend largely on your firm's goals over the next 2 to 10 years, while the financial implications of a long-term deal may not be the first thing that comes to mind. Nonetheless, it is important to take those financial concerns into consideration! If you're unsure about it right now, stick with a yearly renewal plan. After all, you can always decide at a later date to go with a long-term commitment.

Labels: ,

Tuesday, February 12, 2008

Piping Up About Yahoo! Pipes

Syndicated content is, in my opinion, the boon of the Web 2.0 age. Both casual and power internet users incorporate feeds into their daily lives - some without even realizing it. Syndication allows us to quickly and easily get the up-to-date information that we want or need with a minimum of effort (given readily available consumption mediums such as desktop readers, mobile devices, web browsers, and email clients).

Of course, syndication does have its downsides. One problem is that of "over-subscription", meaning that a feed consumer is subscribed to more feeds than he can possibly read in a reasonable amount of time. Couple with this problem the fact that many feeds contain the same (or very similar) content, and it's easy to see why the novelty wears off for most users. Add, just for fun, the fact that most people who subscribe to syndicated content do so through different consumption media, and the world of syndicated content consumption becomes a mess rather quickly.

Take my father-in-law, a devout New England sports fan, for example. A recent inspection of his home computer revealed that he is subscribed to several different sports-related feeds, including: 1 feed for score updates, 1 feed for news, and 2 editorial blog feeds. I suspect that my father-in-law has also subscribed to these same four feeds on his computer at work. So, in total, he has loaded eight separate URLs and clicked on a "subscribe" link (or icon) eight separate times in order to get his daily sports fix, which seems like a lot of work.

Shouldn't there be an easier way?

Enter Yahoo! Pipes

If you've never heard of Yahoo! Pipes, you're probably wondering what it is exactly. Put simply, it's a way to aggregate (and/or manipulate) content from multiple sources, and output that content to a single source. Anyone with a Yahoo! account can create new Pipes, and the surprisingly intuitive drag-and-drop interface makes it as easy as can be to aggregate content from multiple sources.

For my father-in-law, I fetched the sports news feed from ESPN, scores from totallyscored.com, and his hometown team blogs from the Boston Globe. With the data in hand, I filtered the ESPN feed to include only news for his teams and sorted all of the data by date (most recent first). Then, I simply saved and published my new Pipe, and it was all ready to go. But, to make my new Pipe easy to remember, I used Yahoo's convenient pipe naming feature... so now I can always find it at http://pipes.yahoo.com/driscollwebdev/newenglandsports

So now my father-in-law only has to put one address into his feed reader in order to get caught up on his teams' news, scores, and editorials. Truthfully, though, I haven't even gotten to the part where Pipes shines.

Let's say that my father-in-law decides that he wants to add another blog and another news feed to his syndicated content. Under the old regime, he would have to subscribe to each in all of his feed readers, meaning that he would have to type the URI into his browser and then click 'Subscribe' at least twice (four times if we assume that he'll do it at work too).

But with Pipes, all he has to do is log in and add the URI to the list of feeds already aggregated in his Pipe... and that's it. There's nothing else to subscribe to because he's already subscribed to the Pipe - so the new data will just start flowing in to all of his reader applications!

From a developer's perspective, Pipes is a great shortcut for the kind of work that would normally take up quite a bit of time. Rather than spending time creating the code to filter, sort, and format syndicated content from multiple sources, we can simply retrieve our new Pipe's RSS feed and use the pre-formatted, pre-sorted, and pre-filtered data in whatever manner we choose. This allows us to focus more on building a cool application (a Boston-sports-skinned SpringWidget perhaps), and less time worrying about data cleanliness.

I've only really scratched the surface here of what Yahoo! Pipes can do - I highly recommend that you give it a try for yourself. If you want to see some examples of our Pipes, you can check them out at http://pipes.yahoo.com/driscollwebdev.


Labels: , ,