Every year I'm more skeptical of movie reviews. I've been sent to more abject junk – and worse, shooed away from some true gems – so it's getting easier to brush these things off. But when someone like Salon's comics expert Douglas Wolk goes and points out, in total comic geek terms, what this movie could have been, I find it much harder to be completely in love.

Wolk's point is well taken. The best Batmans are more introspective than Bale's, and they're usually also more crafty, more intelligent. Batman isn't only upstaged by the Joker in this newest flick – he's upstaged by just about anything with a pulse. It's a one-dimensional performance. The nearly unintelligible monotone, the straight-line pursed lips, even the fight sequences feel stilted. Bale's Batman could have been so much more. I went to bed last night totally swayed.

But I think Wolk – and all the other naysayers – are missing something. This is the film where we see Batman on the verge of bowing out, acknowledging that heroes sometimes need to have a face. Hell, the movie doesn't even have the word "Batman" in the title. And all these reviews are in agreement about the Joker. He's the unquestionable center of the film. I for one have never been more skeezed out – or exhilarated, for that matter – by a hero-flick villain.

I'm not saying Christopher Nolan made an entirely conscious decision to background the film's lead character to make any kind of artistic statement. But it seems plausible that, seeing what an unbelievable performance he'd captured in Ledger's Joker, a different film began to emerge.

There's more than enough emotional weight in Nolan's film. What sets it apart from any superhero flick I've ever seen is that this is the first that's comfortable handing almost all of that weight over to its anarchistic psychopath. I'm finding it hard to believe that's really a bad thing.

What I am interested in are the little gems Apple have added to an already brilliant device. Sure, native apps are great. I've played more Reversi this weekend than any human ever should, and I'm super excited about Graffitio, a simple location-aware app that makes smart use of the iPhone's geo-locating capabilities. But for me, the real news is that Apple has left almost all of the iPhone's UI and core functionality untouched, opting instead to implement a handful of fixes and incremental improvements to the 1.x series software.

A Standalone Contacts App

The iPhone's biggest strength has always been the way it incorporates and extends the Mac's Address Book application. Nothing drove the utility of the iPhone home for me like the moment I realized that each type of address data stored on my desktop was, when downloaded to my phone, represented by a separate contextually-aware mode. Tap a contact's email address, the Mail app opens. Tap a website address, Safari appears. Tap a phone number and (logically) a phone conversation is started. Tap a street address, the Map application opens and drops a pin on the location, exposing any Google data via a tasteful link that in turn opens its own Contact-like page.

The problem: the first-gen iPhone OS hid the main contact book inside the phone app. The contact list would reveal itself at appropriate times, but if you wanted to, say, take a quick glance at all the methods available for contacting your mom, you had to first click the Phone icon on your home screen – even if you had no intention of making a call. It's a small detail, but one that proves Apple really gets what sets the iPhone apart.

Multiple Calendars

Meg and I share eight separate calendars synced over our LAN with BusySync and hooked to separate Google calendars out in the cloud. It works well everywhere – except on the old phone. The first-gen iPhone OS synced all calendar data but displayed events as if they all belonged to the same calendar. Any event added to the iPhone calendar were added to a default calendar on the desktop.

iPhone 2.0 introduces true multiple calendar support, complete with color coding and the option to view a single calendar's worth of appointments at a time. In future versions, I'd like to be able to match the colors I've assigned assigned to each calendar on my desktop instead of assigning color codes randomly. Additionally, it'd be nice to view complex calendar sets on the phone – like view "Life" and "Work," but not "Chores."

Password Entry Assistance

If you've ever had to enter the WEP key for your friend's wireless network on your iPhone, you'll know what a gift this is. All hidden password fields – that includes both the system and in Sarari – now display the last character you entered for the briefest of moments. It's just enough long enough to encourage confidence in your keyboarding abilities. My only quibble: the true security nuts should have the option to toggle this function on and off via the system panel.

I have a feeling a number of other details will reveal themselves over the coming weeks. Which ones have I missed?

Camera backpacks are cool and all…

But that mammoth SLR, I slowly stopped carrying it around. Not totally, but mostly. A quick scan through the pictures I've taken since 2005 is strange. Forty consecutive pictures of some couch cushions, followed by five sunsets, followed by an SD card's worth of pics from my Grandma's 90th birthday. I get it out when I'm so moved, but apparently only if it's An Event or something beautiful near home.

Mind you, most of my favorite pics from the last few years were taken with that camera. There's the one of Meg. The lighting in that could have only been captured by a nice lens. There's a metric frak-ton of Baby Jack pics, the peanut that finally convinced me having kids might be a nice idea. I'll no doubt take thousands more pictures with it. (Digital cameras actually do last that long, you know.)

But the best camera is the one in your hand.

It's an extraordinarily old adage, but true. And my phone, with its measly 2 megapixel lens, is the first camera I've owned that actually stays with me all the time. The picture quality is just good enough to make it worth using. The noise might be obnoxious as hell, and you better have a hell of a steady hand in anything other than open daylight, but I've seen worse. And as this site reminded me, the idea that you can take awesome pictures with crappy cameras is nothing new.

That, and I can absolutely 100% guarantee that I wouldn't have caught my cousin Ansley with a whole orange in her mouth, Tim's impossibly hot lunch-on-a-dare, or Jason in the midst of a late-night hostile takeover with any other camera, no matter how stellar the optics.

Out of a thousand useless crappy snaps you take with that Nokia, in five years, there's likely to be a few you'll wish you'd saved if you're not saving them somewhere. I'm just sayin'. 2008-07-08T02:57:24+00:00 http://www.thenestedfloat.com/articles/mixing_php_variables_with_expressionengine_template_tags/ http://www.thenestedfloat.com/articles/mixing_php_variables_with_expressionengine_template_tags/#When:17:22:56Z I'm knee deep in a project at my day job that's turning out to be a perfect example of ExpressionEngine's biggest strengths – fine-grained access control, a speedier build process, and crazy flexibility.

My task is to take a client's current site, change none of the layout or styling on existing pages, and port the whole thing to EE. Because we did the original build, the code is all standards compliant and has managed to stay pretty clean. The site's currently managed by the client with a basic WYSIWYG maintenance tool. It's actually worked quite well for them. But their organization represents 30 or so distinct sub-organizations, and giving those sub-orgs access to their own content is the biggest reason for this move. The hope is that the site will stay more current if opened up to these partners.

ExpressionEngine in the hiz-ouse!

For each of those sub-organization pages, the amount of content varies greatly. Most only have an overview page. But some have additional resources, some have conferences, some have news items – and some have all of those plus more. Each sub-org is represented by a single entry in a "Projects" weblog. Each of those additional content types are corralled in separate EE weblogs (appropriately named "News," "Resources," etc.) and related to the appropriate project by using a related entries field type and pulled into the correct project page with a call to reverse_related_entries.

The project manager I'm working with suggested tabbing these additional pages, and rather than coding the JS ourselves, our colleague suggested we go with DOMTab. Works a charm.

The problem.

Well, DOMTab, like any JS component, is pretty particular about how the code should be laid out. You've got a container div and a ul for the nav where each li represents one of the child divs, which can be named whatever you want. So something like this:

1. <div class="domtab">
2.  
3. <ul class="domtabs">
4. <li><a href="#resources">Resources</a></li>
5. <li><a href="#news">News</a></li>
6. [... and so on ...]
7. </ul>
8.  
9. <div>
10. <h2><a name="resources"id="resources">Resources</a></h2>
11. <p>Here's where the resources go.</p>
12. </div>
13.  
14. <div>
15. <h2><a name="news" id="news">News</a></h2>
16. <p>Here's where the news goes.</p>
17. </div>
18.  
19. [... and so on ...]
20.  
21. </div><!--END DOMTAB-->

Many (or most) of our sub-projects don't have any additional info, and for those cases, we want the entire DOMtab section hidden. If there are any resources, news items, etc., then we want to show the whole thing, a list item in that initial ul, and an associated div in the body.

The solution I wish worked.

We've already hit the problem, even if it's not apparent yet. The simplest, and most elegant thing to do would be to wrap the entire chunk in a conditional call to reverse_related_entries and then nest other reverse_related_entries calls within. It'd look something like this:

1. {if {reverse_related_entries weblog="resources|news"}}
2. <div class="domtab">
3.  
4. <ul class="domtabs">
5. {if {reverse_related_entries weblog="resources"}}
6. <li><a href="#resources">Resources</a></li>
7. {/if}
8. {if {reverse_related_entries weblog="news"}}
9. <li><a href="#news">News</a></li>
10. {/if}
11. [..and so on...]
12. </ul>
13.  
14. {if {reverse_related_entries weblog="resources"}}
15. <div>
16. <h3><a name="resources" id="resources">Resources</a></h3>
17. {reverse_related_entries weblog="resources"}
18. [...print our resources info here...]
19. {/reverse_related_entries}
20. </div>
21. {/if}
22.  
23. {if {reverse_related_entries weblog="news"}}
24. <div>
25. <h3><a name="news" id="news">News</a></h3>
26. {reverse_related_entries weblog="news"}
27. [...print our news info here...]
28. {/reverse_related_entries}
29. </div>
30. {/if}
31.  
32. [...and so on...]
33.  
34. </div><!--END DOMTAB-->
35. {/if}

But alas, that won't work. We're already within an initial exp:weblog:entries call, so it'd be asking a lot of EE to let us nest queries this deeply.

Halfway there.

What you could do is pull out all the nesting and wrap each item's opening and closing portions in its own conditional that checks reverse_related_entries. So, just for example's sake, the code for the entire DOMtab section would look like this:

1. {if reverse_related_entries}
2. <div class="domtab">
3. {/if}
4.  
5. [...here's where all our content goes...]
6.  
7. {if reverse_related_entries}
8. </div><!--END DOMTAB-->
9. {/if}

That's fine in theory, but when you start extrapolating out exactly how many conditionals you'll need to get the whole thing to work, stuff starts to look crazy.

What I ended up doing.

To eliminate the clutter inherent in wrapping every single conditional element in its own reverse_related_entries conditional, what I ended up doing was turning on PHP for the template and setting the parsing stage to output. That last part's important because it tells EE to run the template tags before running the PHP. That lets me do this:

1. {if reverse_related_entries}
2. <?php TRUE = $has_additional_info; ?>
3. {/if}

Now whenever I want to check to see if a chunk of code should be printed to the page, I only have to write a PHP conditional that starts with <php if ($has_additional_info) : ?> and I'm good to go. It's much more readable than the alternative, and as a bonus, uses less overhead.

Made it this far?

Wow. Look at the big brain on Brett!

If you're new to ExpressionEngine but like what you see, may I suggest Ryan Irelan's EE Screencast Series? I'm usually skeptical about any screencast that requires me to open my wallet, but I've watched all of these, and they're the nuts.

Look at that. It's the first day of a four day weekend, and I've spent two hours writing a single blog post. Time for me to do some recreatin'.

Happy futzin' everyone!

I couldn't disagree more. Sounds like there actually are some major changes coming, and I'll likely be impressed with a handful of them. For starters, I think it's great that the Muxtape team recently implemented an auto-play on direct links from the RSS feed for your tape.

But in the end, I think Muxtape is just about perfect. I'd rather not see any feature implemented that detracts from what I've come to regard as the service's greatest strength.

Muxtape Keeps You Focused On The Music

If you think about it, most of Muxtape's "missing" features force you to do one important thing: listen to the damn music. Want to read about the history of the artist you've got spinning? Too bad. How about rearrange the tracks from several muxes to create your own über-hip supermux? Not if you don't own the tracks, boyo. How about search? What if I wanna listen to that one specific track and see all the users that have muxed it in to their tapes? But you're at a music site built for listening to music, not socializing. Why not give that tape that just popped up a listen? After all, that's what you're here for – to listen to music. Right?

Khoi was right on about one thing: Muxtape is the anti-Facebook. But I'd take it a step further. It's the anti-social social network. What you can glean from a user is 100% limited to the songs they'd like you to hear. In that way, it's about as authentic to the mixtape spirit and experience as you can get. What does it mean that I'd at one point put Prince's "Strange Relationship" beside Scott Walker's "Cossacks Are?" (Answer: probably not as much as I wish it did.)

If you haven't spent much time on Muxtape, do. It's worth every minute you put in, especially if you can still remember the best way to fake a crossfade on that Sony boombox your dad gave you. While you're there, give mine a listen. And if you can glean anything from my personality from the offerings, let me know. I'm all about the insights.

What? You've already read it? That's nice. I'm sure you got everything you could out of it when you were 17. There couldn't possibly be anything left for you to take from it now, could there?

I didn't get this book less when I was younger as much as I got it different. For starters, that seventh chapter, the one that builds the backstory of protagonist Jack Burden and Anne Stanton, his mathematically exact, foxy-as-hell love interest. I know it's supposed to be high school girls and not boys that swoon, but I'm pretty sure that's exactly what I did when I first read that chapter. At 29, the whole chapter – which has way more to do with missed opportunity in general than it does with high-falutin' crap like love – comes off instead as devastatingly sad.

More importantly, though, I got exactly how much of a factory-wrapped-douche Jack Burden really is. From start to finish, one thing after another. He's a terrible son. He's a nihilist. He's a shitty husband. He's unaccountable for anything at all.

And damned if I didn't eat it up this time.

The cool thing about re-reading books from your teen and pre-teen years is that you're not just bringing a boatload of personal experience to the table. You've also got a whole arsenal of pop-culture references to fling around. Jack Burden solidified the mold for every brooding, introspective, whiny, white guy since. (I mean, his name's Burden for chrissakes.)

Which leads me to the point that inspired this post in the first place. Another thing that changed in my reading: I'm bothered by the tidyness of it all. As my wife pointed out, this is a story of its time (which, I would argue, accounts for Jack's casual racism, never addressed in the book, even when major plot points could support it), and as such, open-ended finales are hard to come by. The kind of half-way epiphanies bittersweet disappointments that close much modern fiction just didn't appear in full force until a decade or two later.

So I've got a suggestion. Can someone re-write the ending for me? My way, you'll only have to redo a few pages. It's simple (WARNING – eensy little spoiler here): let Jack tell Sugar Boy about Tiny's ploy to kill the Boss. It's a dirty little moment, the last we see of Jack's dark side, and best of all, Jack is self-aware enough to think through the consequences as he makes the decision. It'd be the perfect cynical little twist. Plus, Jack would still get the girl, and Sugar Boy would get to realize his destiny.

Huh? You've got better things to do than mangling classic American fiction? I'll just have to rewrite it myself.

So I admit it: I do, from time to time, stealth edit my posts. My last post, for example, was a late-night one-off, fueled by sleeplessness and caffeine. A three minute once-over the next day helped turn it into something I wouldn’t mind re-reading or re-linking months or years down the road.

Since the changes I make are almost always cosmetic, it seems senseless to post an update list. I mean, does anyone care that I reduced the use of passive voice in the third paragraph? (They don’t. Trust me – I already checked.)

But that’s why I’m wondering if I should bother with all this stealth editing in the first place. True, every blog is different. Perfect grammar and finely crafted turns of phrase aren’t necessarily on everyone’s list of requirements when evaluating a blog post, theirs or others. Content is king, but timeliness and originality count for something too.

Does it matter? If a tree falls in the forest and the other trees don’t give a flying flip about dangling participles, does it make a sound? I know the question itself – Is stealth editing bad? – is essentially a non-starter. A bunch of factors determine whether a post-publish editorial process is appropriate for any given article. What I’m more interested in is whether I’m the only one that’s doing this sort of thing.

Well, am I?

It’s breathtaking.

I wondered, as Rex did, if this album would be better than Gillis’s last and, further, what that even means for an artist who simply repurposes the work of others.

It’s all about raising the stakes of the game. To my ears, Gillis has done that simply by doubling down on the emotional weight.

It took me about five go-rounds to get there. Even if you’ve spent a bunch of time with Girl Talk’s last several albums, it’s hard not to be bowled over by the whole unthinkable mass of the thing. Complicating matters are Gillis’s mixing and mastering skills, which, on a strictly technical level, seem to be improving with every album. There’s just something different about the quality of tone that Gillis is squeezing from these songs.

But that soul.

Where Night Ripper had only a handful of really emotionally evocative moments – the best of which nearly became legendary – Feed The Animals is full to the brim with hair-on-end, moist-eyed revelations. Granted, we’re not talking conventional tear-jerker material. “Jessie’s Girl” has never sounded sweeter than it does here, laid against Three 6 Mafia’s “I’d Rather.” Then there’s Tone Loc and Fleetwood Mac building the base for Trina’s sweet-but-suggestive “I’ve Got A Thing For You.” “Play Your Part (pt. 1),” the album’s very first track, laces Lil’ Wayne with Sinead O’Connor’s “Nothing Compares 2 U,” Wayne slinging “Pick ‘em up? Fuck ‘em, let ‘em lay / Where I’m from, we see a fuckin’ dead body every day” just before Sinead belts out the line that made her famous. It’s the tension baked in, hope and resignation, that makes the moment. And it’s Shawnna’s refrain, “I was gettin’ some head,” that rips us back out.

But to what end? Why would someone piss on such a special moment?

Aww, hush up. Who cares? Let’s dance.

Remember when The Sopranos started the long wind-up to its finale? Tony had been shot by Uncle June and was now laid up in a hospital bed, his recovery still in question. As that unending, multi-episode dream sequence was drawing to a close, there was Tony B. beckoning to our man from the doorstep of a farm house simultaneously lovely and terrifying. The clatter of a party inside clicked and sparkled. We all knew what was inside. It was a tired conceit – Life or Death: Choose – but it felt appropriate.

For a moment there, I honestly believed the writers were about to do something momentous. Tony S. was on his way out, leaving a wealth of episodes for the writers to finally deal with questions that really mattered. They'd have already trampled all over the most mundane of plot points: "Does Tony live or die?"

We all know that David Chase ended up taking an entirely different risk with the end of his story. In retrospect, I can't imagine a better ending. But I still say a killer opportunity was missed.

Well, bully for us if Ronald Moore didn't – forgive me – roll the hard six. The critics all seem to agree that this was a top notch episode. Me, I'm thrilled that, with the most irrelevant questions already answered, we've still got at least eleven episodes left – including a rumored three hour finale to focus on the fun stuff.

My wife Meg nailed it immediately. She's not much for the SciFi channel, but she's a whip-smart English Ph.D. student and – at least on some level – appreciates the show's unorthodox narrative turns. She skipped Friday's episode, so last night, I was describing that final scene to her – how Adama, having just landed on Earth, bends down and grasps a first fist full of earth, the tittering geiger counter instantly telegraphing the extent to which humanity is fraked.

"Ha!" she said. "It's the Scorched Earth technique. Literally. Burn the whole story down and start over."

"ExACTly," I say. "Isn't that, like, totally frakin' awesome."

Meg smiled.

That's fine, Meg. I'm excited enough for the both of us.

Though skeptical of the concept at first (I kept thinking, “Isn’t this what tabs are for?), I’m now sold. I love the idea of running a dock full of applications all powered by other machines out in the cloud. The hurtle as I see it isn’t in the concept; it’s in the design of these applications. And I’d like to humbly submit one thing that all web app authors must do to fit in with current and future generations of these single-site browsers:that remain are less about flaws in the concept

Your app must not rely on the browser’s back button.

With Fluid, you have the option of turning on standard browser controls, but in Prism, you don’t. In my opinion, for the concept to hold water, you really should dispose of the browse buttons anyway.

Look at the apps you have open right now on your machine. Besides a file browser or a finder, how many of them have buttons that imitate the forward/back buttons of a web browser? One, maybe? I’m betting zero is the norm. For a web app to feel like a desktop app, it needs to at least follow the basic rules of desktop apps.

Most web apps I use pass this test handily. Netvibes does the best, with Basecamp coming in a close second. (Basecamp, unfortunately, is missing some features in Prism that I’d like to see. For instance, I wish I could switch to a project in a new tab rather than leaving the project I’m currently viewing. Also, Prism doesn’t let me refresh the page, which is crucial for fast, efficient use. And in fact, I think it’d be great if Basecamp included a refresh button on every page.)

For the most part, Google does okay, but when you start using their apps in a site-specific browser you start uncovering minor flaws in their design pretty quick. One example: Google has a habit of placing links to other services in the header of their services. These links frequently open in a new window and expose no way for you to return to your application without the use of a back button.

It’s not even worth arguing whether the use of web apps will ever eclipse the use of desktop apps. (For the record, they will – at least in the way we currently define a desktop application.) If these site-specific browsers grow in popularity, app developers must consider the small features that let folks working outside of the typical browser box use all features of the app quickly and efficiently.