T-Mobile is now the only national carrier that doesn’t have the iPhone.

According to Apple’s listed specs, the iPhone 4S doesn’t do the 1700MHz band that TMo needs to do 3G, but it does mention that it can send and receive on the 2100MHz band, which TMo does use. Technically the chip they’re using can do the 1700MHz band, but I am not sure if the 4S antenna can work with that frequency, even if some form of software workaround can be had. This makes me upset, and after all these years with Tmo, I may have to jump ship. My 1st gen iPhone is on its last legs, and it’s time for me to seriously consider options. I’ve speculated before as to why Tmo didn’t get the iPhone, and I’ve narrowed it down to two possibilities: either all parties involved thought that Tmo would be swallowed by AT&T, rendering the idea of Tmo as an iPhone partner moot, or Tmo and Apple were in talks, but they somehow broke down. We may never know.

The new camera is slick!

A 5-element, ƒ2.4 wide angle lens, 8 megapixels, and a backside-illuminated sensor won’t give my 5DmkII a run for its money, but it’ll be a hell of an improvement over any other phone, possibly including Nokia’s. Not only will it take a good pic, but it will also record 1080p video at 30fps (can I have a 24fps option please?), with built-in image stabilisation. I’ll reserve judgement on the quality of the camera’s IS until I get to play with it, but it’s undoubtedly going to be a huge improvement over the iPhone 4. Oh, and one more thing… it’s got built-in noise reduction. Tiny sensors suck — it’s just a fact of life. A good built-in noise reduction algorithm will go far in enhancing the quality of the photos and video taken, more than the increase in megapixels. The built-in software has also improved, allowing a much faster time-to-picture, and picture-to-picture performance. They also added the ability to crop and rotate within the camera app. I’ve been waiting ages for this. Finally, they added a hardware shutter (the volume button). I’d prefer a dedicated button, but I’ll probably get over that pretty quickly.

Personal Digital Assistant

Siri, if it works with my funny accent, and the processing time isn’t too long, will be amazingly useful to me. The artificial intelligence used reminds me of the Newton “Assist” feature, which simply knew what you wanted to do, and did it. This time, it’s voice activated. “Lunch with Bob tomorrow” will set up a calendar event for lunch, tomorrow with Bob. Do you have several Bobs in your address book? Siri is smart enough to ask which Bob you are talking about. If it needs clarification, it will simply ask. It’s also proactive. If “I want tacos nearby”, it’ll find all the mexican places near my location, then ask if I want to make a reservation. I hope it works as good as it demos.

Messaging

The new messaging features are nice, but really, they’re merely fixing what was horribly broken since the original iPhone. In this modern age, a modal dialog box that vanishes when you unlock the screen, with no way to retrieve the information is dumb. In IOS 5, we get something closer to what Android has had shortly after they decided to become an iPhone ripoff rather than a Blackberry ripoff. There’s still a lot I prefer in the Android, WebOS, or even the Windows Phone 7 notifications system, but at least the iPhone is no longer a total joke in that regard. iMessage is good, but I’d like to see more integration with the desktop, and I’d like more control over the destination. A ‘merged message inbox’ is a lovely thing, but sometimes you want your outgoing message to a person to go on a different system than the original.

iCloud

I’m not going to touch upon too much, as that’s a totally separate article. Suffice to say, if they can pull it off, I’ll be ecstatic. My experience with prior efforts though, is that Apple’s cloud services become unavailable for long periods of time. iCloud promises seamless integration between devices. If it doesn’t work 100% of the time, I can’t rely on it, and it won’t change my current behaviour.

So what excited you? Anything disappointing? Let me know in the comments.

The Mac mini may very well be overkill for what I am trying to do. It’s got a Sandy Bridge Intel Core i5, a good (not great) dedicated mobile GPU, and 4GB of RAM for what is ostensibly a streaming server. However, if you look past the basics of what a streaming server can offer, having a ‘real’ computer allows me to do some things that could never be done on a Roku, or AppleTV. I have access to the desktop version of Safari/Chrome/Firefox and the Flash plug-in. Most streaming video is still Flash, and HTML5 video isn’t quite as good an alternative as I had hoped.

I chose PLEX, as it seemed to be the most mature of the 10′ interfaces available for the Mac. The interface is quite nice, but if you don’t find it to your liking, you can swap out the theme for something that works for you. The interaction using a simple button-based remote or keyboard is a bit clunky, but it works. If you have a large library, be prepared to hold down the button awhile as your library scrolls by. The current versions of PLEX have a client/server architecture and allow multiple clients to receive streams from a single PLEX server. This is fantastic, as I can then stream to any computer in my house, or over the Internet. Suddenly my hotel movie selection doesn’t suck.

They also have a sophisticated IOS (and Android) app, which I purchased for $5. While I was delighted to see that PLEX would stream to my device, I was upset that the touted Remote functionality doesn’t seem to work with PLEX Servers running on Lion. Indeed, this was the only reason I wanted to buy the app. The PLEX Forum wasn’t very helpful, and questions from multiple users about the topic went unanswered by the developers. I’m still using the wireless keyboard to move through the PLEX interface. Grrr. 

Overall, despite the deficiencies in PLEX, with my set-up, I really dig my new toy. It’s dead simple to set up and maintain, and I am hopeful that the problems with the IOS app will be resolved soon enough. Alternatively, I could check out one of the VNC apps for the iPad and control the interface without the keyboard/mouse combination. 

I’m taking a slightly different route: I’m not going to build a micro PC, I’m going to buy one of the new Mac minis which use very little power, and almost no power when sleeping. The form factor is perfect, and it has HDMI-out. In the past, people have hacked earlier minis to be media servers, but with varied success (they were underpowered, and they didn’t have HDMI, so getting it to the TV was a pain, and they often couldn’t decode a proper 1080p/24 file without stuttering).

Why not an Apple TV? They’re great toys, but they’re closed devices. They don’t do 1080p, and they only do a limited subset of H264 decoding (luckily it’s done in hardware). With the mini, I can read any file any mac can read, which includes the ubiquitous .MKV files the kids get off the interwebs, and with the new multi-core i5/i7 processors, and dedicated GPU, I’ll always be able to send 1080p content to my TV.

So over the week-end, I started ripping my DVD collection. It’s small by some standards, but it’s not inconsequential. I have a mix of old, unrestored films, B&W films, foreign films, some modern digital transfers, and both old and new animation. Logically, this means I had to do some homework to figure out what settings were best for the source material. Finding proper encode settings however, was like pulling teeth — painful, messy, and occasionally, inaccurate ;-). I rip all my DVDs to the hard drive prior to transcoding to H264, then batch transcode overnight. Here are some insights:

• Ripping (transferring but not transcoding data from the DVD to the hard drive) is far slower than merely copying bit-for-bit. This is due to the bullshit copy protection where they purposely corrupt sectors in the DVD, making the read-head dance from track to track trying to follow the programme material. Nothing can speed this up, as the DVD drive is the bottleneck, and you can’t have a read-head move much faster.
• Transcoding is resource intensive. You’re CPU bound, and potentially memory/disk IO bound, but there are workarounds…
• Rip to one disk, transcode to another. All disks should be fast. Don’t use anything USB, unless it’s USB3 (even then, just don’t). Use Firewire 800 (minimum), or SATA/eSATA, or in my case, Fibre Channel (FC, fuck yeah!). This will have a massive impact on how many frames per second you can transcode. Nothing sucks more than having to read from one area of the drive, and write to another area of the same drive.
• Use fast, 64bit apps. Transcoding is a lot of very scary maths. In 64bit mode, not only can you twiddle giant numbers without rounding/truncating (or being forced to use double cycles to perform the operation), you also get access to way more registers, which means more efficient use of the CPU (32bit mode uses the legacy register system from the old 8088 days which is crippling in a modern compute environment). If your transcoding apps aren’t multicore aware, get new ones.
• If your primary target device is IOS-based, amp up the bits-per-second, as each IOS device seems to be able to understand different bits of the various H264 profiles, and they’re not merely additive (ie, AppleTV2 isn’t ‘everything the iPhone4 can do, plus some’). Throwing more bits-per-frame will always give you a better picture. All those fancy features are ways to achieve higher quality at a lower bitrate. Give yourself a big bitrate, and you don’t need to rely on the fancy bits that will make your file unreadable on your target device.
• Check your audio tracks! Sometimes the 0 track is not the main audio track. If you’re not encoding all the audio tracks, double check that you’re bringing in the correct one. Personally, I encode a number of audio tracks, including an AC3 passthrough of the original audio. For commentary tracks, and down-mixed main audio, I use AAC at 256kbit/sec.
• Check your subtitles! For the love of Pete, don’t burn them into your video. Keep the subtitles as a proper separate track. They’ll look really bad, and it’ll screw up the encoding quality. Do however, ‘force’ them if needed. From what I understand, ‘force’ will bring up the subtitles on the main audio track when there is a foreign language being spoken. Helpful in those films that are primarily English, but suddenly there is dialogue in French or German, and you want to know what they’re saying. This trick obviously only works if the original source was tagged to do so.

For transcoding, I prefer using the latest Handbrake, as it uses the very fast x264 engine for encoding to either .m4v or .mkv H264 containers. I looked around to find a good optimal encoder setting as a jumping-off point, but most sites had old information which wasn’t directly applicable to the latest version of the app. I did however, learn about some of the advanced options which did have a relevance.

I settled on starting with the “AppleTV 2″ preset for my non-animated DVD content, but that yielded an image that I found unacceptable in most of my test material. In most scenes, the entire screen seemed like it was underwater. The macroblocks would shimmer and shake, making it difficult to concentrate on the material. From this, I made some minor adjustments, and I am pretty happy with the results.

• First thing I did was raise the ‘constant quality’ slider from the default position of 20, to 18. This is actually a logarithmic slider where the smaller number indicates higher quality.
• I also ticked the “No DTC Decimation” box which helped in areas where there is large areas of a single colour (or subtle fade)
• Set the “Adaptive B-frames” to “Optimal” which gives a boost in efficiency to the Pyramidal B-Frames.
• For cel animation, I increased the number of B-frames to 6, and amped the ‘constant quality’ slider to 16
• For B&W source material, I used a variant of my cel animation settings, but brought the B-frames back down to 3, and used the Greyscale filter in the Picture Settings sub-menu. This greatly reduced macroblock collapse which often happens in B&W transcoding (large splotches of the same colour).

These settings may not be what you’re looking for in your application, but they work well for my purposes (finding a balance between file size and quality level). Perhaps you can use this information as your own jumping-off point. Experiment. Queue up several copies of the same source with different settings, and see what works best for you.

Like any tsunami, the arrival of FCPX left devastation in its wake. Dozens of video editors on Twitter immediately dismissed the product simply as iMovie with a darker UI, and otherwise totally unfit for professional work. They cited important features of their existing workflow that were entirely lacking in the new product. They also cited features that they thought weren’t there, but in fact were, had they read the manual. The Great FCPX Whinging is still going strong on Twitter and forums, and it’s entirely counter-productive.

Folks in the industry like to say “Editing is about storytelling”. I also believe that to be true. What I am witnessing however, is not this. I’m seeing my Twitter stream flooded with apoplectic editors complaining about how a just-released tool doesn’t meet their needs, and countless regurgitations of ‘facts’ that are simply untrue. If the just-released tool doesn’t meet your needs, don’t use it. It really is that simple. The products you were using last week are still running, and you know them well. If you’re in the middle of a project, you shouldn’t change tools anyway. Some worry about future support for FCP7. Yes, eventually Apple will stop supporting the product (they have already stopped selling it), but that’s in the future. In the now, you have deadlines. Worry about meeting them. Smart editors will take the time to learn this new product at the ground floor, so when it is ready for their workflow, they can integrate it. When that time comes, those editors will work faster than the competition, still learning how to make new bins (hint: keywords are the new bin).

FCPX is best thought of as a totally new product. Don’t think of it as Final Cut Pro Ten, think of it as Final Cut Pro X version 1.0. No one gave up their Avid rigs when the original Final Cut Pro hit the scene. Instead, they continued to use the tools that allowed them to tell their stories.

Let’s have less emo whinging, and more great storytelling.

When creating wireframes, there are often several objects that are repeated throughout the deck — Headers, footers, navigation, and sidebar widgets are all good candidates for Linkback. Nothing is more tedious than having to go into your document and change each instance by hand. Using a Linkback makes fast work of global changes.

Why not use Master Layers? Master Layers have their place, but they lack the flexibility of the Linkback. Master Layers are locked in location across all canvases. If you want to move an instance of a widget to another location in only one canvas using Master Layers, you’re out of luck. Linkbacks by contrast, are object-based, not layer/canvas based, so you can position them wherever you want.

Creating a Linkback is easy. Watch the video for a tutorial, or follow these steps:

1. Select the objects you wish to use as a Linkback.
2. Right-Click (or Control-Click), on the objects, and select Copy As > PDF.
3. Delete the original group of objects (not the Linkback).
4. Paste the object onto the canvas. This is now your Linkback.
5. Paste the Linkback as you wish, throughout the document.

Updating a Linkback is also fairly straightforward:

1. Double click on any instance of your Linkback. This will open a new window called “Linkback to [the name of your document]“
2. Edit as desired
3. Command-S to save your changes to the Linkback. Your changes will not be shown until you save the Linkback.
4. Close the Linkback window. You should now see all the instances with the new edits.

Yes, I am aware of the typo in the screencast :-P

If you have questions, or if there is a tutorial on Omnigraffle you’d like to see, let me know in the comments.

All application development starts with an idea. “It’d be cool if there was an app that did…” is the spark that ignites the development and design process. Along the way, more ‘cool’ ideas come up, and often included. The problem with ideas that start with “It’d be cool if…” is that the answer is always ‘yes’.

In a sense, app development is similar to writing a novel. Functions are like characters. Each is explored, and given life. They develop unique personalities, and often, the characters tell the author what they will do next. This leads to a much more robust, believable character, but it can quickly get out of hand. At some point, you lose the narrative. In a worst-case scenario, you wind up with the Homer Simpson Bubble Car — or iTunes.

Like every good writer, every good app developer needs an editor — someone who can take a look at what your app does, redline the hell out of it into a leaner, more coherant story. Nowhere is this more needed than in mobile app development. The most successful apps on a mobile platform tend toward simplicity. They often do one thing, but do it very well. Apps like Instapaper, and Readability are popular for this reason. The limited space provided on a mobile screen demands a level of simplicity and focus. You want your users to launch your app, do what they need to do quickly, and leave your app so they can get on with their lives. Applications that provide this experience are used more often, as users don’t feel the dread of getting mired in the app’s UI or panoply of choices. People use apps like Flipboard because they are delighted by the content they bring.

As an exercise, start with an idea for an app. Take everything away until you have achieved an application that is so minimal, any additional functionality removed would cause the app to do nothing at all. Build that. Ship that. Observe how your users are using the app. Continuously refine your narrative based on observed evidence. The best apps lead users with intelligent decisions made by the developer. Users don’t have time to weigh the impact of their decisions within the app. If you hand them a diner menu of options, they will opt for a black coffee.

There is a story about an architect who built a university. All the buildings were designed and built, but there were no paths to any of the buildings. People couldn’t understand why no paths were built. The architect answered “The students will show us the best paths to make.” After a few months, the grass on campus had noticable wear where the students beat a path from building to building. Shortly thereafter, cement paths were created based on the natural behavior of the students. If they attempted to solve this problem before the students came to the campus, they would have made wrong assumptions. Now, they had empirical evidence on what should be done.

Building a simple app with limited functionality is also a fantastic way to create a solid, bug-free base on which to build. I am not an advocate for no functionality. I am an advocate for smart functionality. I have a rule of thumb: I will only build in a new feature if I think at least 90% of my users will use it nearly all the time. Your users will tell you what they want in an email, in conversation, or in feedback forums. Don’t be fooled. That is the siren song.

Users will show you what they need by hacking your app to meet their goals. Twitter is a fantastic example of this. When it first started, All it allowed you to do is post a 140 character message, and receive messages from people you follow. It was simple and elegant. People flocked to it in droves. There were no @replies, no RTs, no DMs, no Lists, and of course, no Dickbars. @Replies were born out of a need to respond to tweets. It was a convention that users made up themselves, and eventually incorporated into the application. The same goes for RTs and DMs. The one ‘feature’ that wasn’t originally hacked together by users was the Dickbar, and we all know how much of a miserable failure that was.

I’ve seen (and regrettably created) far too many apps that cram far too much into a user interface. We are reaching an age of transparent computing, where content is the most important, access is easy, and the best UI is no UI at all. Build small, and allow for discoverability, serendipity, and joy.

HTML5 added the <video> tag, theoretically freeing us from using the current de facto standard for video playback, the notoriously crashy Adobe Flash. The reality is sadly, much different. Of all the major browsers, not one of them fully support the tag. Firefox and Chrome can only play HTML5 video if it uses the WebM codec, while IE and Safari will only play back H264-encoded video. This means that if you want to use only HTML 5 video, you have to encode twice. Conceptually, multiple encodings isn’t such a huge problem. There are fantastic encoders for H264. The WebM encoders in contrast, are pretty weak and difficult to insert into many existing workflows. Then there is the majority of desktop browsers in use that don’t support the tag at all.

When you throw mobile browsers into the mix, things get even more confusing. Most mobile browsers use Webkit, the open source browser platform on which Apple’s Safari and Google’s Chrome is based. This would be great, but different mobile devices support different profiles and aspects of the highly complex H264 codec, which means potentially more encoding for those devices.

Once you have all this encoding stuff worked out, you’re still faced with the reality of the browser implementation. From what I’ve observed, all the major browsers fail to properly buffer content. Inevitably, the buffer stops filling, and the video stops playing, with no way to force it to continue. Often, the playhead continues to move forward, even though the video is not playing. Full screen playback is also a problem, in that it often doesn’t work, or it has strange interface anomalies.

Some browsers don’t even properly follow the parameters passed in the <video> tag. Safari, for example, will automatically download the entire video when the web page is loaded, even if you explicitly set auto-buffering to ‘false’. That will cost both content providers and users for exceeding their data transfer caps.

It all falls back to Flash. The Flash plugin ships standard with most browsers, and has an installed base that is something in the high-ninty-percentile of desktop systems. The more recent versions of the Flash plugin can understand H264 encoded video, when called through the Flash interface. While the plugin is becoming more well behaved, it’s still crash-prone, and notoriously resource intensive. On mobile devices, Flash is still far from ubiquitous, and still unreliable.

So where does that leave us? Unfortunately, for content creators, it means a lot of extra work doing multiple encodings for each permutation of browser, and a huge chunk of HTML, Javascript, and CSS coding to get all of it to work. Luckily, there are some emerging solutions that help get all of this in order.

Video for Everybody is a simple chunk of HTML that will properly cascade a variety of video options based on the browser. It even properly substitutes an image for those browsers that don’t support the <video> tag, and it even works for those who have disabled javascript. It doesn’t however, offer any options like skinning, or fixes for the various browser deficiencies.

VideoJS takes Video for Everybody, and adds the ability to skin the HTML5 player and javascript to fix browser deficiencies such as the auto-buffering bug in Safari. It also incorporates Flow Player, the freely available Flash video player which references the H264 video as a fallback. There are other HTML5 drop-in solutions, but VideoJS seems to be the least buggy.

So this is what I’m doing: I’m using a VideoJS Pro plugin for WordPress, but I am only encoding H264 video, as I can’t find a WebM encoder that will fit into my current workflow. Right now, I am only encoding a single video profile which works on the iPad, IE9, and Safari on the desktop, while the Flash fallback will be shown in Firefox, and Chrome. In the future, I will create reference movies in H264, so iPhones, and those with lower bandwidth will still be able to play back the video. I don’t foresee encoding into WebM until the codec can be integrated into my workflow. By then, I expect to see H265 to be in common use.

So how does it work? To quote Arthur C. Clarke, “Any technology sufficiently advanced is indistinguishable from magic”. It sure seems like magic to me, although I am going to make some purely speculative guesses solely based on the video above. The tracking points seem to be added in areas near contrast edges. The actual location of the point is possibly derived from the distance from several of these contrast edges, and their change in position from prior and future frames. While we’re seeing tracking points, what may be calculated are tracking ‘blobs’ with the centre point marked. As stated, copious amounts of frame blending are used in order to smooth out movement. I’m pretty sure it’s only blending areas of the frame where needed, otherwise different areas of the frame with different warp characteristics would not be able to be corrected.

[Update]: Here’s the white paper describing the technology

We’ve seen hints of this technology before in other Adobe applications. Specifically, I see bits of this in the extensive warping tools now available in Photoshop, as well as the automatic lens distortion correction in Lightroom. The Warp Stablizer is the logical next generation of these tools. The CS5.5 suite should be out in June. I’m looking forward to testing this with real-world video.

[Update]: I originally wrote this during NAB. As it turns out, Adobe released CS5.5 yesterday (5/3/11)!

So what happened? Apple unveiled a totally new application with the title “Final Cut Pro X”. Aside from the fact that the old FCP and the new FCPX are both video editors and share a name, very little is similar.

The new FCPX is rebuilt from the ground up as a 64-bit aware cocoa application with hooks into all the cutting-edge technology of MacOS X 10.6. Incorporating OpenCL and Grand Central Dispatch allow the new application to not only scale down to lower-end laptops, but also harness all the logical cores on the CPUs and GPUs of the new Mac Pros. The upside? No more render bars, and much faster performance!

They took a few cues from the latest incarnations of iMovie. The interface is decidely iMovie-like in the placement of UI elements, and there is no longer a clip and separate canvas view. Even though I learnt the traditional clip/comp/timeline way of working an editor, I always thought it sucked. This seems to be an improvement, but I withhold my judgement until I can use the application.

Organising your clips was always a pain in the arse. Automatic shot detection (ex: closeup, medium, and wide), and automatic video scrubbing of clips on mouseover both came from iMovie, and are welcome additions to the new app. The new keyword and search features also look quite promising, although I am curious how they handle missing and relinking media. In the past, Avid has been the gold standard in that area, and the sneak peek at the Supermeet was inconclusive as to Apple’s approach. Not everything is iMovie-derived however, as FCP retains its frame-accuracy, and introduces sample-accuracy on audio tracks. Many folk were worried that because the demo was so reliant on the mouse, that the keyboard jockies would be left out in the cold. During the demo, it was mentioned that everything is operable via the keyboard. That little, yet very important detail seems to have been overlooked by other blogs.

Some features we got to see will change the way we look at editing video. I actually clapped when I saw them demonstrate the elastic timeline. Instead of the old track-based timeline, new tracks are now created automatically any time there is a track collision. If you start dragging a clip near an existing clip in the timeline, the old clip will simply jump to a new track, so you can manage the conflict on your own, rather than corrupting the timeline. J and L cuts are also easily created according to what they mentioned, although we did not see this in the demo.

Another big change includes the ability to audition clips without affecting the timeline. Imagine you are editing a scene, you have a variety of clips you could insert at a particular point, and you want to see which clip feels best. It used to be that you performed some pretty scary timeline acrobatics (or even created a new project), and inserted clips one at a time. Double clicking now brings up a meta-timeline which allows you to rapidly try a variety of clips before settling on the one you want. You can always change your mind, and none of your choices will harm the real timeline. Final Cut Pro X also now offers a much better way to do precomps, aka. nested timelines. Normally these appear as a single track, but if you need to edit them, double clicking will cause the precomp to expand. There are other features that were shown, but it’s easier to show you the video.

So who was right? It’s too early to tell. The dog and pony show was quite impressive, but like any other professional app, you really need to use it for awhile before you can pass final judgement. I think the app shows great promise, but what little we saw at the Supermeet raises more questions than it answers. What of the other apps in the Final Cute Suite? What about migrating old projects? How extensive are the keyboard controls, really?

The new Final Cut Pro X will be available in June through the Mac App Store, for $299. The price has sparked controversy in the editing community. Many folks believe this price point will mean less work for editors, as clients will just attempt to do it themselves, (with the implication that they will fail horribly). Some people may indeed do that, but I say those people were never really your clients. The application is just a tool, and editing is an art, as well as a skill involving a lot of experience and talent. Those that have a budget understand that, and will still ring you up. The same thing happened in every other industry I can think of. Wrenches are cheap, as are shop manuals, but I still hire a mechanic to take care of my car.

My needs have changed. I used to be content posting small images, and having my videos re-encoded to mush. Just being able to post and have people see it was ‘good enough’. With new technologies, I no longer need to settle for ‘good enough’. I can post what I want, and have much better control over the final result within my own domain. I’ve no problem syndicating my content to other services which have stricter rules with regard to content display, as long as it’s possible to see the original work.

I considered writing my own blog software. It’s not terribly difficult to do given that my posting needs are pretty straightforward. In the end, however, I decided to go with what works, and transfer everything over to WordPress. A lot has changed since I first looked at the software over eight years ago. It’s now far easier to manage and customise to my liking. My biggest gripes with WordPress were spam, and vulnerability to cracking/hacking. The first was solved using Akismet, and Disqus as a comment engine. The second is still a problem, but made easier through WordPress’ new update features. With one click, I can upgrade my WP install without having to do a bunch of manual re-coding.

So what to expect? I’m still going to write about new technology, and culture that is of interest to me. Expect more audio and video as well. The design and functionality are still in flux, so expect things to be a bit wonky for awhile.