Video blogging on the cheap – not as easy as it should be!

I just recorded two screencast videos last night that I wanted to use as video blog entries. Seems easy right? Just find a video host!

Unfortunately, “easy” is far from the way I would describe my experience, and I am somewhat exasperated by the process at the moment. So here is the detail: I have two videos, one being 9:17 long, and the other being 15:02. Both of these are recorded as OGV files, which is part of the free, open, cross-platform OGG media container format.  All I need to do is find a service to host them and stream them.  So far so good right?

I decided that I would try to look around for a video hosting solution other than YouTube, since I have posted screencasts on there before and the video degradation was horrendous.  After some googling and reading reviews, I started down a spiraling path of services leading to nowhere, beginning with….

  • Vimeo (verdict: fail) – Vimeo seemed like a great place to start.  Any time I have seen their videos, I have never noticed a degradation.  They offer HD and the service is free – kind of.  In all actuality, there were three issues for me here.
    • bad: They do not support the OGV file format, so I had to convert the OGV to an AVI before uploading it.  Of course they don’t actually tell you this until you have sat through an entire upload first! There was a degradation that occurred during that process, so even after uploading it, the quality wasn’t as good as I liked.
    • bad: Free accounts are only allowed to upload a single HD video per week.  Already in my first try I had two, so that is a show stopper.
    • good: The HD version that was uploaded was better than many of the alternatives,
    • bad:  you can’t embed the HD.  If the user wishes to see it, they have to click through the player to the site and watch it on the Vimeo site.
  • Viddler (verdict: fail) – Viddler seemed like a good alternative to Vimeo.  However, ultimately it doesn’t seem to be the direct fit either.
    • bad: Just as with Vimeo, they do not support OGV.
    • good: As opposed to Vimeo, at least they tell you about the lack of OGV support  as soon as you attempt uploading!
    • bad:  Since I had already converted one of my videos to AVI, I went ahead and tried it.  Even in full screen mode, the degradation was bad enough that I couldn’t see what I was typing in the video, which is kind of the point!
  • YouTube (verdict: fail) – After nixing Viddler,  I thought “why not at least try YouTube again?”, and I was soon reminded of exactly why not.
    • good: They support OGV!
    • bad: Even my 9:41 video was deemed “too long” and was promptly removed.
    • bad: I couldn’t even get far enough to report on degradation!

So just as I began typing this blog entry to air my dissatisfaction with things in general, I came across this post, praising the combination of using Jing to record, and Screencast.com to host the video.  The video clarity on his example was really impressive.  “Ha!” I thought, “finally!”.  So I now have one more to add to my list:

  • Screencast.com (verdict: fail)
    • good: They allow you to upload any file type whatsoever! (I think anyway)
    • bad: They only embed a few different file types into players.  OGV is again not supported.

So here I sit, still without a good solution to what initially seemed like it should be a no-brainer of a problem to solve.  The amount of time that I have wasted to still be sitting at square one is terribly aggravating.  Between upload times and service-specific encoding times, I am more hours deep into this than I care to think about.

HTML5 to the rescue?

One thing that came out of this search is that I learned that HTML5 natively supports OGG/OGV using the <video/> tag.  (more here), and based on an example that on this page, it looks very cool!  The only fundamental thing that is holding me back at the moment is that there doesn’t appear to be any option to allow your user to ‘full screen’ your video out of the player.  So close, yet… still no solution!

If anyone has any good recommendations, feel free to leave them in the comments.

How to: write the last N linux terminal commands to a file

Sometimes blog entries are for you.  Sometimes they are for me.  This one is the latter.

The other day I asked the following question on Twitter:

Anyone know a way to write out the last N commands run in the #linux terminal to a file?

 

I got a plethora of responses within minutes, but by far the most complete and tricked out response came from Joseph Lamoree @jlamoree, who gave the following solution:

 

history | tail -n 10 | sed -E 's/^ +[0-9]+ +//' | grep -vE '^history$' > cmds

 

In that command, the “10″ represents the last 10 commands, and “cmds” is the filename that the output will write to. Since there isn’t the remotest chance in hell that I would ever remember this, and Twitter is about the worst place for me to go back later to find technical information, I am putting it here on my blog for future reference. Thanks Joseph!

Open Letter: Stepping down as DFWCFUG Manager

At Tuesday night’s meeting (3/8/2011),  I announced that after 55 meetings at the helm, I am stepping down as manager of the Dallas Ft. Worth ColdFusion User Group. 

Am I tired of doing it?  Am I leaving the language?  NO, and NO!

As an Adobe UGM, one of my responsibilities is to endorse and evangelize the product of Adobe ColdFusion (ACF).  For numerous reasons over the past year or so, I have found myself at growing odds with this task.  As competing open source engines such as Railo and OpenBD are gaining in functionality, stability, and performance, as well as being made freely available to the CFML community, it is impossible to ignore them as true contenders in this space.  Where they were once viewed as free alternatives, they have moved to the position of driving change and driving features that I would like to see in ACF. I wholly feel that these engines are the future of our community, and should be given equal attention rather than be viewed as just an alternative.  Based on that fact, it is disingenuous for me to continue in my role as an Adobe UGM.

As of its inaugural meeting on April 5, 2011 at the Paladin Consulting office in Dallas, I am going to serve as coordinator of the DFW CFML User Group, a non-product-specific user group composed of enthusiasts of the CFML language, regardless of the engine that runs it.  Without the pressure of promoting one company’s product over another, we can focus on what is really important to us, which is the power of the CFML language and the diverse ways that it can be used across various platforms.

It is important to note that the new group will not be strictly an “open source” group, nor is this a swipe at any kind of Adobe itself.  The group is simply not going to endorse a single product as the only viable solution to writing enterprise level applications in CFML.  Our content will doubtlessly include Adobe ColdFusion, but will not be exclusive to it.

So where does this leave the DFWCFUG?  Adrian Moreno has served as co-manager of the group for several years now.  Adobe mandated this hierarchical approach to how their groups will be organized so that in the event of the departure of a manger, the group can carry on without interruption with the co-manager taking over.  I have spoken with Adrian at length on this topic, and he does not share my vision on the DFW CFML User Group, and feels that it is important to have a product-focused user group under Adobe.  As a result, he has opted to take the role of group manager effective immediately and will be leading the DFWCFUG.

I want to make it abundantly clear that this will not be an “us vs. them” scenario between the two groups.  We are in this together as one community with varying interests and it is in all of our interests to positively promote both groups.

Fortunately, I think that this leaves the DFW CFML developers with some excellent options!

I plan on sharing much more about the new DFW CFML User Group in the near future.  Please follow us on Twitter at @dfwcfml and look for upcoming announcements in the next few days.

Lastly, thanks for letting me serve as leader of the DFWCFUG all these years.  It has been an honor and a privilege to do so.

~Dave Shuck
@dshuck
daveshuck.com

Refactoring: avoiding nested conditional statements

Recently at I was given the task of adding an new validation routine to an existing validation process.  In this piece of code, the requirements mandated that a series of sequential tests would be run, but in the event of a failure of any of them, the process would kick out and set an error state, provide user feedback, and whatever other tasks needed to occur.  We have all seen processes like this before.  Essentially it looked like this:

error = true;
if ( testOne() )  {
    if ( testTwo() ) {
        if ( testThree() ) {
            if (testFour() )  {
                 error = false;
                 doAllTestsPassedStuff()
            } 
        }
    }
}
if ( error ) {
	handleErrorCondition()
}

Looking at this block of code, the intent is pretty obvious as we progressively run tests as long as the previous test returned true, eventually firing the doAllTestsPassedStuff() method.  If any of the tests failed, we would call handleErrorCondition().  While this approach is completely functional, the maintainability of it is no fun, and it just feels wrong to me.  For the task I was given, I had to add a new test davesSuperTest()  between the 2nd and 3rd conditional blocks.   If I were to follow the previous approach, I would insert it there, and tab out the previous testThree() and testFour() conditional statements further to the right.  In my opinion this is an ugly block that is getting uglier by the minute.

By altering the approach to use try/catch blocks, we can still maintain the same level of control and order or operations as dictated in the requirements, but each condition becomes insulated from the others,  like this:

try {
	if ( !testOne() )	{
		throw "fail:testOne";
	}
	if ( !testTwo() )	{
		throw "fail:testTwo";
	}
	if ( !davesSuperTest() )	{
		throw "fail:davesSuperTest";
	}
	if ( !testThree() )	{
		throw "fail:testThree";
	}
	if ( !testFour() )	{
		throw "fail:testFour";
	}
	// if we reach this point, then all of the above tests passed.
	 doAllTestsPassedStuff()
}	
catch(e)	{
	handleErrorCondition()
}

Given this approach, it is very simple to add/remove conditions without disrupting other conditions, even better, I don’t have to scroll to my second monitor on the right!