Wordpess released today their new native app for the iPhone!

It let’s you publish new posts and manage existing posts of your wordpress blog (both wordpress.com as well as self hosted blogs). It looks pretty good, and I’m actually using it now to create this post. Having an easy to use way to blog in my pocket may actually get me to blog more often (mobile safari is great but trying to use the wordpress admin pages in it is just too painful IMHO).

Naturally you can post photos you have taken on your iPhone (or that you have syncd to your iPhone) so that makes mobile photoblogging pretty nice (now of there were just an official flickr app for the iPhone).

Check it out at: http://iphone.wordpress.org

Bloggers, podcasters, and videobloggers often live and die by their syndication feeds. Syndication feeds such as RSS feeds are just URLs where the recently posted entries/episodes are listed. “Subscribers” enter these URLs into applications like Google Reader, Bloglines, or iTunes in order to get all the latest and greatest content out there without having to actually browse to scores of websites and download each manually.

So, its a good idea for publishers to make sure their Syndication Feed URL is easy to find on their website.

Sometimes a publisher gets lucky enough to have more than himself and his best friend as a subscriber, and watches with glee as he gets more and more and more subscribers over time.

But what happens if the publisher wants to start using a different blogging software, or changes some 3rd party services, or perhaps even just starts using a different set of core-plug-ins and in doing so ends up changing his syndication feed URLs? Does he lose all of those original subscribers? Do all of his original subscribers have to unsubscribe from the old URL and then resubscribe to the new one?

Thankfully, no. With a little planning the publisher can make sure he never has to lose or inconvenience a subscriber just because his source syndication feed URL has changed.

I was recently asked how a publisher might move subscribers from one subscription feed to another without actually asking them to unsubscribe from one URL and then resubscribe at another. The following are my tips on how to set up “publisher friendly” feed URLs. By “publisher friendly” I mean the publisher is now free to do whatever he wants with his blogging software or source feed …. secure in the knowledge he wont lose or inconvenience his subscribers.

This post is a bit long and may be a bit scary, but don’t worry … there are only six steps. I’ve tried to include alot of explanation behind the steps so that you can really understand what is happening, but don’t let the added words here scare you away …. it’s pretty simple.

1. Give your subscribers a feed URL that never changes – no matter what you do on the back-end of your site.
2. Move any existing subscribers over to this “permanent” URL, transparently – no inconvenience to your subscribers.

To accomplish the first goal you have two choices.

1. Use a service like feedburner and just publish the feedburner URL.
2. Create a URL at your own domain such as http://mydomain.com/feed

Option 1 is easier because it doesn’t require that you have the ability to edit your .htaccess file, but it does require you always use feedburner. (i.e. you can’t later switch services without having to readdress this issue again) …. So if you have the ability to edit your .htaccess file, option 2 is ideal. Lets assume you want to use option 2.

Step 1) Find your BLOG-GENERATED FEED URL.

Step 2) Decide if you want to use feedburner (or similar service), and if so use the BLOG-GENERATED FEED URL when creating the FEEDBURNER URL.

NOTE: From now on, when I mention “SOURCE FEED” I mean either a) the FEEDBURNER URL (if you are using feedburner or a similar service) or b) your BLOG-GENERATED FEED URL (if you aren’t using Feedburner or a similar service).

So with that in mind, lets assume for the sake of these instructions that your SOURCE FEED is http://feeds.feedburner.com/MYSOURCEFEED (Be sure to replace this URL with your actual SOURCE FEED URL in any of the instructions below)

Step 3) Now lets pick the FEED URL that you will actually publish to your visitors/subscribers. Pick a URL at your own domain that doesn’t already exist. This is the URL you will publish as your FEED URL, and its only purpose is to redirect (behind the scenes) subscribers to the SOURCE FEED where all the data actually is. Lets assume the FEED URL you chose is http://www.mydomain.com/feed. (It’s the /feed portion that we want our server to redirect to the SOURCE FEED, and we’ll use that portion in our examples/code below.)

(Has Step 3 confused you? Check out this clarification of Step 3)

Goal #1: Give your subscribers a feed URL that never changes.

Step 4) Now all you have to do in order to accomplish Goal #1 is redirect your FEED URL to your SOURCE FEED. The advantage to doing this is that if the location of your SOURCE FEED ever changes, you can just update the redirect, and your subscribers are none-the-wiser. To accomplish the redirect, you’ll need to edit the .htaccess file for your website. (If you’re having problems finding the .htaccess file, try a different FTP / File manager program – the .htaccess may be ‘invisible’ in the listing your application provides)

Add the following lines to your .htaccess file (above any other redirect rules or <IfModule> blocks that are already in the file):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^feed/?$ http://feeds.feedburner.com/MYSOURCEFEED [QSA,L]
</IfModule>

Goal #1 is now accomplished!

That was easy wasn’t it!? You can now send any new subscribers to your newly created FEED URL (http://www.mydomain.com/feed) and they will actually be subscribing to your SOURCE FEED (http://feeds.feedburner.com/MYSOURCEFEED). As described before, you can alter the redirect at anytime in the future should your SOURCE FEED URL change … and your subscribers will automatically move with you. Nice.

Goal #2: Moving existing subscribers from an old feed URL to the new one you just set up.

Step 5) First things first, determine what your OLD FEED URL is. Lets suppose it was something like http://mydomain.com/archives/feed.xml. Notice it’s the “archives/feed.xml” part of the OLD FEED URL that defines the file we want to redirect … so lets call this last part the OLD FEED PATH. We’ll only need to reference the OLD FEED PATH (archives/feed.xml) in the .htaccess rule we’re about to write.

Step 6) Now, lets provide a redirect for your OLD FEED to your new FEED URL. We do this just like we did with the last redirect we wrote – by modifying the .htaccess file.

We’re going to use a slightly modified rewrite rule this time however because we want this redirect to report a “permanent” redirect so that smart feed readers will automatically move over to the new url from now on (don’t worry the dumb feed readers will just keep asking for the old one and just keep getting redirected to the new one each time).

To accomplish this redirect, add the following line to the code you just added to the .htaccess file – just above the </IfModule> line.

RewriteRule ^archives/feed.xml$ /feed [R=301,L]

Done and Done! Goals 1 and 2 have now been accomplished.

The overall changes to your .htaccess file should look like this:

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^feed/?$ http://feeds.feedburner.com/MYSOURCEFEED [QSA,L]
RewriteRule ^archives/feed.xml$ /feed [R=301,L]
</IfModule>

And you’ll want to put these lines above any other rewrite rules or <IfModule> blocks you already have in the .htaccess file.

• Your old/existing subscribers will be seamlessly redirected to your new FEED URL (http://mydomain.com/feed) the next time they request the OLD FEED URL (http://mydomain.com/archives/feed.xml)
• New subscribers will start off requesting your new FEED URL (http://mydomain.com/feed)
• So, now ALL of them are asking for your new FEED URL (http://mydomain.com/feed) … which is redirected to your SOURCE FEED

Now, you can change just about anything you like. You can change the source of feedburner, or even drop feedburner all together in the future and your subscribers never have to change their FEED URL. You just simply alter the redirection in your .htaccess file to what you want – and your users wont know the difference.

As an added bonus, you’ve just cheaply and easily ‘branded’ your feed URL with your domain name (instead of feedburners).

Extra Credit:
For extra credit you may want to update your blogs theme or styles to publish your new FEED URL both in the content of your pages as well as in the auto-discovery links in the page headers.

Click image to play Video, or choose a format via links below.

Formats available: Flash Video (.flv) Quicktime/iPod (.mp4)

I started to write a comment to Colin Devroe’s post “Giving into community pressure” and while I was writing said comment I realized two things. 1) Man I should just blog about this, and 2) No, seriously, I really SHOULD just blog about this and send him a pingback as a comment. So here it is …

In Colin’s post he points out how often we seem to jump on a bandwagon for a given web site or service not because it’s the best one out there, or even just because it’s our inexplicable favorite … but rather just because that site or service is where it seems everyone else is going.

I’m somewhere in the middle.

In some ways I do tend to use what “everyone else” is using. Twitter and facebook for exmaple. There are alternatives to each. I use these because they are the ones that everyone else is using.

However in other areas I laugh in the face of convention. I’ve been videoblogging since before YouTube was … YouTube (not that you could tell recently). Despite YouTube coming on the scene and the great exposure it can offer, I don’t plan on using it routinely anytime soon. Granted I don’t really care about exposure, but mainly I avoid YouTube because I’m geekish enough that I want far more control over my presentation, alternate formats, syndication feeds, etc than most walled gardens like YouTube allow for. Also I like the terms and conditions at Blip.tv way more than I do the ones at YouTube. So in this case, despite it being one of those “everybody else in the world is using it” sort of things, I’ll stubbornly post and syndicate from my own site thank you very much.

Honestly, I’m also rather fatigued of constantly trying to get in on the next big thing that may not even be any better at all than the things we’re using today. I dislike ning (even though it’s cool) because I’m sick and freaking tired of signing up for yet another social network. Ning makes this fairly painless I guess, but thats assuming you want the same profile info etc. I may hire someone to shoot me if I have to sign up for one more freakin social network.

This all reminds me of the great IM wars … really preferring service A, but trying to get all your buddies on the same contact list while trying to make sure you are signed into service B often enough to be available to someone who wasn’t on service A … UHG. In the end, we all started using clients that tried to hack together all of them into one place even though such clients had half (or fewer) of the features which made us prefer service A in the first place.

Maybe the interwebs move too fast sometimes. I think that’s the bottom line: there are too many new things every single day to constantly be jumping camps … so, some services (like Pownce) don’t get the use/credit they deserve because … well dang it we just don’t want to reinvent this wheel yet … we just got here. Colin points out that being first is a huge advantage and he’s right … the later the entry the better the service will have to be to convince me to switch.

Through all of this, I’ve become a big fan of the idea that we can and should create distributed social networks and services that are open an cross-compatible. There’s alot of work to be done on that front, but it has already begun (check out http://diso-project.org/ ). It’s one of the reasons I liked Colin’s “The-Diet” page so much – it basically formed up a simple and loose distributed social network.

Someday I’ll be able to enter into my single authorative profile (openID maybe?) my standard profile/avatar info as well as things like:

• My Friends/Buddies are: <url to FOAF/XFN info here>
• My photos feed is: <flikr url here> (or maybe picasa if I use that instead)
• My Updates feed is: <twitter url here> (or maybe pownce if I use that instead)
• My blog feed is: <rss feed here>
• My IM service is: <service>/<screenname>
• etc etc etc etc etc

Social networks could be distributed and dynamically updated. Imagine: you signup at SocialNetwork-A and it automatically gets your buddie info from your authorative profile and knows that I’m one of your friends. (We are friends, right?) It could then check my friends info the same way it checked yours to confirm that I count you as a friend as well. SocialNetwork-A could include for you in your social network view things like my twitter updates, my photo feeds, my blog updates, etc all without my having to enter all that info AGAIN into YET ANOTHER social network. I could do the same for you at SocialNetwork-B. We could chit-chat accross networks via blogs/posts/tags/feeds etc (if you dont have a blog then your socialNetwork-A can provide that feed) … ah it would be so wonderful.

Maybe it sounds too geeky and confusing, but trust me it could be done in a way that is very simple and transparent to the non-geek-user. I guess it will depend on someone figuring out a way to make such a system profitable.

I long for the day I can have one profile and list of services that others can consume without my having to redo it all 150 times every 6 months.

• I use twitter because that’s where everyone else is.
• I don’t use pownce (but I do have an account) because I don’t want to have to do ad-hoc spontaneous updates at two places.
• I use gtalk becuase its awesome, not littered with adds and plugins, and is open.
• I use YahooIM because I have a huge list of contacts that use the service.
• I use MSN because my xBox360 signs me into it.
• I use AIM only because I can now do so through gtalk.
• I use facebook because the dang thing wont stop spamming me with vampire bites and cocktails.
• I use flickr because it both rocks and is where everyone is.
• I use blip.tv because they allow me far more granual control over how/when/where my work is presented, distributed, and discussed than any other service I’ve tried.
• I dont use YouTube because I want/need a video hoster that allows for multiple file formats.
• I use MeFeedia because I can watch sources from all over the net at one site.
• I don’t use GoogleVideo because it sucks.
• I use Seesmic … well I don’t really use it actually, but I do have an account, and look forward to where the service might go.
• I use ning … as rarely as possible.
• … there are others … oh, there are others …

Watch the video

Tags: iPhone

(Click the image above to watch the video!)

It’s Videoblogging Week 2007! The week where all sorts of people all over the world crank out one new video every single day … just to do it. Witness the maddness at MeFeedia.

Tags: videobloggingweek2007

In this Post:
Second Life Location (Slurl): http://slurl.com/secondlife/Gyeongju/113/158/74
Media URL: http://www.slackspace.net/dynamic-media/smil.mov

(Click the image above to watch the video!)

It’s Videoblogging Week 2007! The week where all sorts of people all over the world crank out one new video every single day … just to do it. Witness the maddness at MeFeedia.

Tags: videobloggingweek2007

I’ve been using BlueHost to host DavidMeade.com (and several other websites) for some time now. I’ve brought friends and family to BlueHost and championed BlueHost in the videoblogger community. I liked them because they had decent support.

I’m sorry to say recent events have changed my opinion of BlueHost. I will no longer recommend them, or offer them as an alternative when hosting options are discussed in the videoblogger community. As I doubt anyone at BlueHost is going to concern themselves with my issues, I expect that overtime I will move all of my domains to some other hosting provider. After seeing their sympathetic shock and anger upon hearing my story, I expect my friends and family that I regrettably introduced to BlueHost will take their business elsewhere too. While losing 10 or so accounts and whatever referrals might have been had will probably not cause any real concern for BlueHost, I can assure you that their profound ignorance on how to provide hosting and address even the simplest of user issues will lose them far far more.

If anything is more shocking that their complete inability to respond to support requests in a timely manner, it is there AMAZINGLY inept and arrogant response when they finally bother to offer one.

If you’re shopping for a hosting provider, take note …

Not so long ago the president of BlueHost (Matt Heaton) sent out a whole series of emails letting his customers know that they were aware of the serious performance issues on their servers and were actively working on it. These emails were soon followed by emails that essentially said ‘things should be much better now’.

Unfortunately for me, you, and this site … DavidMeade.com was still suffering from debilitating server issues. So, i sent an email to BlueHost support. I got an auto-response saying we can’t email support anymore and had to use the web ticketing system. Frustrating but so far no big deal, I copy and pasted my email into their web form for them:

Two days later my site was still nearly unusable and nobody at BlueHost had even been assigned to read my ticket. Concerned I added an entry to my ticket.

Two days later still, constant timeouts and server CPU errors had made accessing my administration pages impossible, corrupted one file, and made uploading a fix impossible. It was now 4 days since my support request and still nobody at BlueHost had been assigned to the ticket. I added the following to my ticket:

Two days later, now 6 days out, the server issues were now a little more intermittent but definitely still present … and nobody at BlueHost had responded … nobody was even assigned. Desperate to be able to ftp to the server reliably again I added the following to my ticket.

Another 2 days passed and the server issues were now much more intermittent … but were of course still causing problems. To ftp up a simple page would require half a day of retries. I was pretty angry at this point. More than a week of suffering and I just knew that if they ever bothered to respond at all they’d likely load my page during one of its now more frequent good moments and conclude nothing was wrong.

Now I wanted them to address the server issues and their inability to provide any support whatsoever for over a week of SERIOUS server issues. (I mean I could get hosting far cheaper if i was willing to put up with that level of support). I added the following to my ticket (not really thinking anyone would ever bother to read it).

A few days later I actually got a response from BlueHost support. After apologizing for the delay, they told me that slow sites are often caused by links to things like pictures on flickr, and that before they could work with me they suggested I remove any and all links to pages not local to my site.

!?

I was dumbfounded. After a week … They were seriously telling me that they as a web hosting company can only provide support for those sites which don’t link anywhere?!?!?!

In the interest of full disclosure here is their exact response:

I just couldn’t believe what i was reading … I added the following to my support ticket:

A few days later (after finding several other hosting options in case the worst happened) I got a response from BlueHost … and the worst happened:

I sat horrified and amazed at the response. An entirely new “support” agent had responded and endorsed the idea that BlueHost could only support performance issues for sites that did not link to pages elsewhere on the internet.

Naturally I’ve no intention of conforming a webpage to this bizarre 1985 style of offline content.

The true irony in all of this is that the president of BlueHost had throughout this nonsense a post on his blog pondering why some companies seem to go out of their way to frustrate their customers … there are those in his own backyard who could provide some valuable insight on this.

Hi all.

Sorry for the lack of postings lately. I’m kinda going through a “uhg I just don’t want to blog” phase. I get these phases every now and again but the good news is that they pass … and when they do I usually come back with vengeance.

One thing I wanted to share with you is a new feature I’m working on for DavidMeade.com: The Episode Archive. This page is still considered in BETA, but I’m pretty happy with it so far.

The Episode Archive dynamically generates a thumbnail view of all videoblog/podcasts here at DavidMeade.com. For those who are techie enough to care (or other videobloggers/podcasters) here are some things about the Episode Archive I really like:

• It is dynamic so it automatically updates as I add episodes to the site. (Naturally, it is the 21st century after all)
• If there isn’t a thumbnail for an episode when the page is called, it will actually go and create a thumbnail for such an episode. (It of course doesn’t bother if a thumbnail already exists for an episode.)
• It uses the poster image that was used in the actual posting as the source for the thumbnail it creates. (Rather than grabbing a random frame from the video … I pick the poster image for an episode very carefully and want that care to work for the thumbnail as well)
• The thumbnails it creates are named based on the episode name and the md5 hash of the enclosure file. (This ensures unique and predictable names for the thumbnails, and thus doesn’t require any additional storage to a database)
• If it has to create a thumbnail but fails to find a poster image to use as a source it uses a default thumbnail image. (But so far it’s be really really good at finding the poster frame.)
• It has a cool Ajax hover effect to give episode info for whatever thumbnail you’re mouse is hovering over.

As I still consider this in BETA you can expect the current features to be polished up a bit and perhaps a few more features before I push it live (give it it’s own link on the toolbar).

I may even decide to make a wordpress plugin out of this, but I haven’t decided yet.

Anyway, I’m still alive and I’m still playing around with the website some … I’m just not blogging alot lately.

Thanks for your continued viewing of DavidMeade.com. If you haven’t already subscribed to DavidMeade.com, this would be a great time to do so! Subscribing to the DavidMeade.com RSS feed lets you sit back and relax and automatically receive the latest from DavidMeade.com whenever there is new stuff to see … without having to check the site all the time … and without having to join some email newsletter.

Also … be watching for some changes at DougMeade.com. Doug and I have been working behind the scenes there as well. Kevin also has an interesting blog at HicksFamilyOnline.com khicks.com where you can contribute! You can find a quick summary of each site on the right hand side sidebar here at DavidMeade.com.