App Review: Wishlistr

It's time again for another app review. Last time, I reviewed Sobees (a social network aggregator that makes life easier for eSocial butterflies). This time I thought that with the Christmas season upon us, it would be appropriate to review Wishlistr (www.wishlistr.com).

Wishlistr's website describes it fairly well:

Wishlistr is an easy to use web-based application that will help you collect, organize and keep track of the things you want. It also lets you share those things with friends and family.

As with most of my favorite apps, this one is free. And it's simple, non-intrusive design makes it idyllic for keeping your list of Christmas wishes. For those who are more tech-savvy: Wishlistr even includes an RSS feed, which could be helpful if you want to subscribe to someone's list.

Try out Wishlistr this Christmas and avoid getting another tie or calendar this year.

PS - If this article was just super-helpful, feel free to peruse my wishlist at wishlistr.com/joshuacarroll/ and send me something cool!

The start of a series / Sobees app review

After having a couple of people ask me for my favorite web-app that does _______, I've decided to review several of my overall favorite web apps right here. These apps will range from unique utilities to sites that may only interest a certain demographic - but in each site I think there is a lot to learn: design, application layout, typography, etc. Starting right here I'll review one app at a time in a blog-style format. If this sounds interesting to you, then follow me down this primrose path and let's begin...

Of all the online tools I use, the oldest in my repertoire is Sobees (sobees.com). Sobees touts itself as a "social desktop aggregator". This tool will be extremely interesting to all of the social [media] butterflies out there.

Sobees allows you to view your LinkedIn, Facebook, and Twitter feeds all on one screen. You can even add multiple accounts from each service. So if you want to monitor your personal and business Twitter accounts... you can! They also offer a couple of iPad apps, one for Android, as well as a traditional desktop application for your PC (if you're into that sort of thing).

When you visit the site the first time, you'll notice one of my favorite features: no login. All of your settings are stored in cookies on your computer. Of course this means if you visit the site from another computer, you'll have to set everything up again. But there are options to backup and restore your settings, so you could simply backup your settings on one computer, then restore them on a second computer and… viola… you have the identical setup. The site’s design is simple, sleek and unobtrusive: what more could you ask more in a web app?

While you’re checking it out, don’t overlook the “Search feed” option. In addition to the various supported social media networks, you can also create a custom - near live - search feed. This is especially useful if you really want to stay on top of a certain trending topic. I’ve used this in the past during severe weather (#arwx) and when iOS 5 was about to be released (#ios5).

If you use multiple social networks, check out Sobees at Sobees.com.

(... and just because I realized this sounds like an advertisement, I just wanted to point out that this is an unsponsored review. However, if someone wants to pay me for it, I'm ok with that too.)

No more frames!

If you have been following the development of the HTML5 standard at all, then you're probably ahead of me on this one.  This is my first week that I'm not teaching in a while, so I'm getting caught up with a little "light reading" (pr: reading web standards and specifications).

After a rather assertive student argued with me the merits of using frames in web pages a couple of weeks ago, I found it rather pleasing to learn that it looks like the W3C will be removing the frame, frameset and noframes tags with the release of the HTML5 specification.  These elements specifically are being removed,

"because their usage affected usability and accessibility for the end user in a negative way."

Hmm.  That sounds rather familiar.

Keep in mind that HTML5 is a working draft and may (probably will) change before it is released.  You can read about these and the other currently absent elements at www.w3.org/TR/2010/WD-html5-diff-20100304/#absent-elements.

National Weather Service changes forecasting XML data

Sometime between 4:30 pm yesterday and 8:00 am this morning (central time), the National Weather Service changed the format of their XML feed for forecast data.  I don't yet know all of the details, but I know that the "time-layout" element no longer has a "period-name" attribute.  If I can find any more information, I'll follow up on this post.

Sample XML feed
Schema

Need references?

I've been working on an app at work that will update "slides" that we show on these huge LCD screens at each of the entrances to the building - things like the weather forecast, current tech news (since we're an IT training center), and where each class is located in the building.

It can be used either interactively or as a Scheduled Task (with the needed parameters passed as arguments in the command line). Until this morning, I've been running it myself from my laptop and updating the jpg's on the units manually about once a week. This really doesn't work for me. I'd much rather have the whole stupid process completely automated, but we're having some network issues that prevent the screens from communicating with our server room (UP&P is being blocked at the router). So until that is fixed (pr: circumvented), the jpg's have to be updated manually with a thumb drive.

Before I go any further, I should explain a little about what the app is actually doing. It opens a Powerpoint 2007 document, updates its content with information provided by the National Weather Server, Google News, and a web service from our local web server (for the course location information). Powerpoint really wasn't needed, but it did make it easier to design the slides.

So, like I said I've been running this from my laptop. I decided that it would be much better to try to put the executable right on the thumb drive and set it up so that anyone could use it. After copying the executable to a thumb drive I tried to run it from another computer (other than my laptop). I had already suspected that I would have some problems since the app is referencing the Powerpoint 2007 interop DLL, which is exactly what happened. Powerpoint 2007 had not been installed on this particular - I had chosen this set up on purpose to see what would happen.

So here was the question: How can I run this executable from a computer that doesn't have the Office 2007 DLL's on it, without having to acutally install this app?

Since I'm normally focused on Web apps, I haven't had to deal with this type of problem before. So after a little exploring in Visual Studio...

In Visual Studio, if you select the specific Reference in question (in this case the Office and Office.Powerpoint references), the IDE will expose several properties of the specific References in the Properties window. The one that I immediately focused on is called "Copy Local". This property indicates whether the reference will be copied to the output directory. After setting this option to "True" for both of the non-.NET DLL's, I rebuilt the app, copied the executable and both DLL's to the thumbdrive, and off to the "other" computer I went.

With the DLL's now in the startup folder of the executable, the app ran just fine. So next time you're at the ITTC, check out our new LCD screens powered by this little app.

Adding URL's to email messages

I recently received a question from a co-worker about inserting URL's into emails.  Although this isn't a normal topic of this site, I thought others might find it useful as well.

---

Josh,
I have a quick question. I am interested in how you made this a link. 
I have copied and pasted the info but never been able turn it into a link.
Can you help me?

file://P:/Information%20Technology%20Training%20Center\Public\SIAC%20Files\20
08-02-20%20Master%20Instructor%20rings.wmv

V/R,
Dana

---

Absolutely!  Take the red pill and follow me down the rabbit hole...

Outlook will automatically create a link for any valid URL (Uniform Resource
Locator) that you type into an email.  By definition, every URL must start with a protocol.  The most common example of a protocol is seen in your address bar while surfing the Internet: http.  Other examples of protocols include https, mailto, callto and file.

In regards to the last one, let's say you want to create a URL that sends people to:

P:\Information Technology Training Center\Public\SIAC Files\

Keep in mind that the example above is not yet a URL, but it is only a file path.  In order to create a URL from this path, the first thing you need to do is add a protocol at the beginning, like so:

file://P:\Information Technology Training Center\Public\SIAC Files\

Now you can see that the link was created, but it stops after the word "Information".  This is not an error.  This is because of another standard in URL's which states that there can be no spaces in a URL.  There are a couple of ways that we could remove the spaces from this URL:

1. Rename the folders and files from "SIAC Files" to "SIAC_Files", etc.
2. Encode those spaces in our URL into Unicode.

The first option could be a major pain, and probably isn't worth the time, so let's look at the second option.  While it might sound scary at first, encoding spaces into Unicode is very easy.  Simply replace all of the spaces in the URL with %20.  By doing this to our URL, it comes out looking like
this:

file://P:\Information%20Technology%20Training%20Center\Public\SIAC%20Files\

And, viola, we have a properly formatted URL!  Outlook, having realized this, has created the link for us.

The first date... ever.

I've been working on the third version of Vend-Trak for the past couple of weeks. We're going to incorporate Google Maps with directions, Google Charts (faster than the Java charts we've been using) and some other neat features. But really the biggest changes are all "behind the scenes".

Currently the application is written in ASP Classic (3.0) and is supported by a MySQL database.  These choices were great at the time, and they served us well.  But Vend-Trak has grown so much in the past few months that it's almost grown "too big for it's britches", as we say down here in Arkansas.

So that lead us to the decision that it is time for Vend-Trak to make the jump to ASP.Net.  And we figured we might as well migrate to a full fledged Microsoft SQL Server while we were at it.  This system-based relational database, along with the compiled ASP.Net application, should result in a MUCH faster application for the end-users. (I'll post the results when we're done.)

So that brings me to this blog.  I knew that migrating from MySQL to SQL Server wouldn't be easy.  But after some Googling I came across some helpful information.  First, I needed to install the MySQL ODBC driver on my SQL Server so that I could pull the information from the old server.  At that point I could create a "linked server" on the SQL Server by using a command similar to this:

EXEC master.dbo.sp_addlinkedserver @server = N'MYSQL', @srvproduct=N'MySQL', @provider=N'MSDASQL', @provstr=N'DRIVER={MySQL ODBC 3.51 Driver}; SERVER=127.0.0.1; DATABASE=ORIGINAL_DATABASE_NAME; USER=your_username; PASSWORD=your_password; OPTION=3'

Now that the MySQL server was linked from the SQL Server, I could copy each table from the original server to the new one with a single line:

Select * into newTable from openquery(MySQLServerName, 'select * from oldTable')

Up until this point it looks that maybe this won't be so bad after all. However, I hit a snag.  After importing two of the 33 tables, I received this message:

Error converting data type DBTYPE_DBTIMESTAMP to datetime.

It took me several cups of coffee and lots of research to finally discover that MySQL's datetime datatype has a minimum value of January 1, 1000, while Microsoft SQL Server's datetime datatype begins with the first day of the year after the Gregorian calendar was put into use in British and American records: January 1, 1753.  (Thanks to Peter Gulutzan and Trudy Pelzer for that tidbit of information.)

Now you might be thinking, "Josh, why is the world would you have dates in this database that are before January 1, 1753?"  Well I'll tell you: inadequate error checking.  When we provided inputs for users to be able to enter dates, we didn't consider that they would enter "8" as a year.  Of course, when the users entered such a date and they didn't see the item that they just created on the calendar, then they created it a second time using VALID dates and got the expected result.

So, while there was a valid problem occuring, the end-users probably never realized that this was indeed a valid issue that needed to be reported, and we never considered that such a scenario was taking place.

I hope that this is useful to someone else and saves them from countless hours of frustration.