« March 2007 | Main | June 2007 »
PSIG 102 | QTKit: 1990s Multimedia Wrapped in 1980s Objects
Monday, April 9, 2007
(What is PSIG? | PSIG 102 announcement)
PSIG last week! I stayed for the whole thing this time, which means I was there till hotel security kicked us all out around 2 AM :). I've decided life is way too short to worry about leaving PSIG at a sane hour. It's just that good of a group.
Books, demos, notable tidbits
- Blake C. informs me that the "interesting feature" I mentioned in my last PSIG post regarding Dave's device browser is actually a significant exploit, and that by blogging about it, I am thereby responsible for releasing it into the wild. Eheh, oops? ^^;;
- I talk about why I
hateam mildly critical of Twitter. Half the group's never heard of this hot new Web sensation, so Wolf helps out by demonstrating the app and executing a few tweets up on the big screen. After much drama and debate we eventually come to the agreement that Twitter can be both good and evil, depending on how you use it :) - Ben Gottlieb demoed his winning Ironcoder app -- a screensaver that tiles Wikipedia pages!
- OpenGL SuperBible
- Jason demoes the FizzBuzz program he wrote in Erlang, as well as a version of the program he created in Quartz Composer for all our rainbow-colored FizzBuzz needs.
- Paul tells us he succeeded in booting OS 10.4.6 on his G4 off of a Lacie USB/Firewire thumb drive.
- Essential PHP security, Professional PHP 5
- It is stated that "it's too hard to find Rails jobs." I suggest the checking out of jobs.rubynow.com, rubyrockstars.com, and jobs.37signals.com. Tom says he does not recommend Craigstlist ;)
- Game Physics: Engine Development, In Search of the Ultimate Building Blocks, Facts and Mysteries in Elementary Particle Physics. Love the comment on that last one: "It was written for the intelligent layman, which is what I am."
- Mastering Cmake
- Dave mentions that his King's Quest game for Windows actually runs using DOSBox, so apparently it was really easy to thingagummy the whatsit and... something. Way over my head ^^;;.
- Later Dave demos an amusing new feature to his MAME OS X emulator -- Quartz Composer integration! For all our rainbow-colored copyright-violating video game needs!
- The transferring of a wheresgeorge.com dollar occurs at some point.
- "Now why did that die?" "Cuz you're plugged into the projector, doing a demo."
- (On Parallels) "I like to see this as the right place for Windows -- in total subservience to OS X."
Iden.tify.us
Tom gave a great presentation on his Crazy New Web 2.0 Startup Site, iden.tify.us. It's a community site where users can upload music files or add video links and get their songs identified by other users. By Web 2.0, we're talking features like an embedded player for your site, tag clouds, RSS feeds with podcast enclosures, and "no business model. (YET!)" Looks promising :).
QTKit: 1990s Multimedia Wrapped in 1980s Objects
Wolf gave an very informative talk on QTKit, the Cocoa framework for QuickTime. He walked us through QuickTime's history and explained the .MOV file format. Basically, QuickTime files are organized in hierarchically nesting data units called atoms. There are classic atoms as well as the more powerful QuickTime atoms, which can tell you whether or not they contain other atoms. This container format has been made a digital media standard, and is the basis for formats like MPEG-4. You can use Apple's Dumpster tool to examine and edit atoms.
You can also examine the different tracks on unmuxed video files using QuickTime Pro. Besides the audio and image tracks, we find that Cocoacast episodes include a disabled text track which contains all the chapter titles, and another text track which holds the hyperlinks.
Apple's first attempt to provide a QuickTime interface was in the easy to use but very basic NSMovie and NSMovieView, members of the AppKit framework. These were deprecated in OS X 10.3 with the arrival of QTKit, which replaced them with QTMovie and QTMovieView. QTKit also comes with support for user media editing -- the same stuff that makes up QuickTime Pro 7. QTKit provides read-access to slight majority of the data model, but much has not been Cocoa-fied yet.
In addition to QTMovie (subclass of NSObject) and QTMovieView (subclass of NSView), QTKit provides 3 other NSObject subclasses: QTTrack, QTMedia, and QTDataReference. There are also two data structures: QTTime and QTTimeRange.
A warning: Apple's website contains a lot of old QuickTime information that doesn't apply anymore, and unfortunately, a lot of the new stuff isn't documented anywhere. The nice thing about the "language barrier" between old C and Obj-C is that you can tell it's the new stuff if it's in Obj-C. (I've also noticed that the old pages are styled differently, with Apple's old serif font for the title and smaller body text which shows up non-anti-aliased on my box. Of course, when you have screenshots like what you find on this page, that's a good clue as well ^^.)
See Apple's QTKitPlayer sample code for a demonstration of QTKit's capabilities. It comes with basic control graphics, but you can totally poach the big shiny QuickTime buttons from your Mac using Spotlight. An important point is that QTKit does not show up by default in Interface Builder. It's an optional palette which you have to enable in IB preferences. All of the optional palettes are located at /Developer/Extra/Palettes/.
Hopefully, says Wolf, the QTKit API will be fleshed out soon. The FAQ for QTKit seems to suggest that some of this will happen in OS X 10.5.
Chirb, April 2007
Wednesday, April 4, 2007
I went to the Chicago Area Ruby Group on Monday for Andy Lester's talk on project management. No crazy story this time because I took the train, although I did have to jog most of my way to the Thoughtworks building, which always seems to be my lot with the Metra schedule no matter where I'm going or when I need to get there. Note to self: If the appearance of composure is any priority, take cab ^^;;.
Half of Andy's presentation was about his alternative to the agile methods of project management. The other half was on technical debt, which I found rather interesting and fairly applicable to IBLP's IT operations. Here's a loose summary of his presentation (slides available at Andy's site).
Project Estimation and Tracking
1. Write it down. The project should be started with some sort of written document. Programmers like to begin coding right away because they think they know what the customer wants, but that's often not the case. A written agreement will help you avoid misunderstandings and will get any immediately obvious questions answered right in the beginning. Wikis are a good medium for these documents because of their collaborative and malleable nature. "It's not like in the 90's where one guy was Master of the Document."
2. Estimate. Give a rough idea of the time/money cost up front. This helps the customer to prioritize and prune, as well as feel in control of the project. Make sure they know that it's not a rigid commitment, because the next step will adjust your estimate.
3. Refine. Break up your estimate, perhaps into outline form for each task. You're doing design as you go, so keep notes. No subtask should be longer than 4 hours, because you can't estimate accurately above half a day. Doing it this way helps to distribute risk: Estimates are usually off by 100%, not 10%. You may need to take a day to sit and think about what you're getting into. You're paying up front in time to be able to know where the end point is. Remember that typing is not programming -- thinking and breaking down tasks is programming.
4. Plan and track your tasks. Write out your task plans Friday afternoon so everyone knows exactly what to do when they come in Monday morning. Try to finish each task before going on to the next one. Track your tasks so you always know what your status is, even in the middle of the week.
5. Adjust as necessary. Sometimes you'll need to shuffle the order, re-estimate, or break up tasks further. When handling new requests, say, "I can do it, but I'll need a day to tell you how long it will take." Customers need to know that nothing is free and that even the estimation of new features will take time. "Do you want the 30 second, half-hour, half-day, or half-week answer? That's what it'll be worth."
Always be aware of the status of your project. If you know you're not going to make a deadline, you should tell your boss or customer as soon as possible. Be honest with everyone, including with yourself.
Getting Out of Technical Debt
"Try to think of Peter Francis Geraci's face looming over you as we talk about this."
Identify your debts:
- Clutter -- disorganization and confusion
- Failing tests, unfixed bugs, unpatched security holes
- Fragile or ugly code -- this often means the code is not read, maintained, or understood
- Code without comments or outdated comments (an amiable audience member adds: Strive to write the kind of code that doesn't need comments, but do maintain your documentation.)
- Truck-sensitive knowledge (the truck-factor: How many people can get run over before your company collapses?)
- Code ownership -- this makes the code truck-sensitive, and a bottleneck
- No coding standards -- standards help minimize the arguments and the time wasted worrying about or fixing differing code styles
- Missing infrastructure -- do you have version control, bug tracking, backups, cron jobs to do your dirty work?
- Jerks on the team -- they may be a negative productivity factor
- Jerks in management -- well, that's beyond your control
- Not realizing you have tech debt, or ignoring it
Determine the cost of paying the debt. Think in terms of time, money, and risk. Create the justification to sell your boss/customer on your changes in corporate language. Quantify everything: What exactly is the improved turnaround, extra quality, and decreased risk worth? All cost assessments must include opportunity costs: What could be done if this change wasn't made?
"Land one plane at a time." Watch the corners and the center will take care of itself. Automate your corner-watching.
Avoid future debt by not incurring more debt. Take notes when you incur debt anyway.
"However," Andy concludes, "Sometimes you just have to do what the customer wants."