justinnichols.com

According to this article and the W3C, HTML5 will provide some great enhancements to the HTML spec. One of which is the ability to embed audio and video directly into a website using new <audio> and <video> tags.

I hear and read quite a bit where people are making the claim that HTML5 is a Flash killer. Honestly I think these people need to have their head examined, but more appropriately they need to understand the Flash platform itself. Yes, it is true that Flash is the primary platform used to distribute video content on large sites such as YouTube, Hulu, and Xfinity’s Fancast. YouTube, of course, recently announced that they are starting trials of HTML5 video in place of the Flash player. Therefore it’s quite true that for video content, HTML5 will eat into Flash’s video marketshare.

Misconception #1: HTML5 is ready for primetime. It’s not. Understand that the browser has to support these new HTML5 elements. As you can see on this layout engine chart, not every parser is currently supporting the new tags such as <video>. Most notably is Internet Explorer’s Trident engine. HTML5 isn’t even prepared to be finalized as a specification until 2012, and then not even recommended by the W3C until 2022.

Misconception #2: Flash is only used for video. Obviously not. People have been using Flash to play games going back to the Yeti hitting the penguin, Bejeweled, and more. With the advent of Adobe Flex, the world is also seeing more Rich Internet Applications being developed on the Flash platform, not just with in-house applications for corporations, but also for the everyday consumer such as photoshop.com. While Flash’s ubiquity is highly contributed by video playback, video simply isn’t the only thing the platform can do. HTML5, in and of itself, does not play any more part in stealing marketshare from Flash as an application platform than HTML4. AJAX and other low-impact client-server technologies obviously play a part, but that is independent of the HTML5 spec.

Misconception #3: HTML5 will diminish Flash because Flash crashes browsers with high memory usage, high CPU usage, and for being insecure. Wrong again. Despite what Steve Jobs may feel about Flash, Adobe, and previously Macromedia, has painstakingly worked on the Flash platform to minimize its own memory and CPU footprint as well as provide many security constraints to thwart content injections and misuse of applications. As with any other platform (OS-level or VM-level), it is up to the programmer to profile their application and determine where high CPU usage occurs and memory leaks can be found. Flash as a platform is not the reason browsers crash. Faulty programs are. This is true in almost every form of any operating system or virtual machine found today.

While I would agree that HTML5 is going to become yet another good enhancement to the HTML specification, and that it will provide an alternative to Flash concerning audio and video embedded content, it is by far never going to cause Flash to meet up with Elvis and the do-do bird. People who are employed in Flash and Flex jobs have nothing to worry about in the coming years. In fact, Flash and Flex jobs currently are a booming market. People have criticized Flash since its inception, but the platform perseveres and the new 10.1 version offers a lot to be excited about especially in the mobile market.

Thanks to my coworker Mike for showing me this 60-minutes story about the Bloombox:

Watch CBS News Videos Online

This could be the first step in cheap, clean energy. If it can power a house, it can definitely power a car.

Did you recently upgrade your hard drive, or RAM in your mac mini?  I did, and I found out that the fan constantly ran simply because I forgot to reconnect the fan control wire (thermal wire).  Below is my mac mini spec:

And here is a shot of the fan wire that needed to be plugged in.

When pulling apart the mini, that cable has to be unplugged.  It’s very easy to forget you did it.  Therefore, if you have to open the mini up again, don’t pull it apart, all you have to do is remove the frame, and then you have access to the wire to plug it in.  Hope you have small fingers

I give this one a big WTF? A browser…that…can’t…open HTML documents? Yeeeaaahhhh, so someone at Google dropped the ball on this one I think.

One day I was asked, “Do you know of anyone who knows how to extract information from a factory-restored iPhone.” I replied, “No, but I expect as long as you can get access to the hard drive bit-by-bit, you could recover information just like you would a quick-formatted hard drive in a Mac or PC.” As it turns out, I was right. Of course, this begs the question: why would one want to extract information from a restored iPhone, or even an actively used iPhone? The answer is quite simple: forensic investigation in both criminal and civil matters.

If you are interested, as I have become, in such endeavors, the best place to start is by buying Jonathan Zdziarski’s book: iPhone Forensics: Recovering Evidence, Personal Data & Corporate Assets.

Jonathan, also known as “NerveGas”, has been part of the iPhone development community and is one of the foremost experts on low-level iPhone interaction and communication. He has classes on iPhone Forensics where he discusses his methods via shell scripts to retrieve and recover information. He licenses the scripts to Law Enforcement agencies for free, but for the private sector he licenses them for $5,000 per year — which in the field of forensics is fairly cheap. Since the release of his book, he has devised methods of getting access to the iPhone’s hard drive without having to jailbreak the phone and having it take only 15-30 minutes to get a full 32GB bit-by-bit copy of the data. This is a direct contrast to his book, where not only does he describe jailbreaking, but he also describes using some nice dd and netcat commands in order to transfer the data to another computer. This process takes about 7-8 hours for a 32GB phone. So you can see the appeal of using his new methods instead of the old ones.

Given that at the moment I do not have $5,000 to license Jonathan’s scripts, I have decided to learn more about this and try to become very knowledgeable about the lower level communication of the iPhone. I will be learning certain technology such as usbmux in an effort to figure out how to transfer the data in a much shorter amount of time. Thankfully I have the ability to stand on the shoulders of giants in this regard since a large amount of the difficult work has already been done for me, but there’s still a lot to learn.

Here are some useful resources that I’ve found thus far:

• A whitepaper based on iPhone Forensics: http://viaforensics.com/wpinstall/wp-content/uploads/2009/03/iPhone-Forensics-2009.pdf
• Jonathan Zdziarski’s site: http://www.zdziarski.com/blog/
• Jonathan’s webcast at O’Reilly: http://www.oreillynet.com/pub/e/949
• A Considerably updated webcast with Jonathan’s new method: http://www.youtube.com/watch?v=h75hrOxzQj0

More to come…

One of the most difficult things I had to learn when developing an iPhone application with Objective-C is the basics around Navigation. I understood the concept of pushing a view onto the stack, but given the old-natured, procedural code required for UINavigationController, it just wasn’t as simple if you’re on one “page” and you want to navigate to another “page” that you’ve already been to.

The idea is that you want to keep these pages in memory and provide a simple mapped method to get to each one. This is where three20 comes in. three20 is a “framework” (currently just source code, not bundled as a .framework) that gives some much needed guidance concerning UI navigation and UI standard elements/event handling. three20 is the framework behind the very popular Facebook application on the iPhone.

I would go into detail on exactly how helpful this framework is for navigation, but the author of three20 does a considerable better job than I ever could: http://three20.info/ui/navigation.