I couldn’t register to leave a comment (*cough*OpenID*cough*) so I’m writing this here post to say: right-click on the Pages file containing the images you want to get at, and click on “Show Package Contents”. All the images are available there as files for your perusal and eventual management. It’s quite handy. Now if only they’d fix the damn file format.

• Me: 8
• Now: 4
• Shit: 5
• Fuck: 7
• Ha: 15
• No: 9
• Yes: 6
• More: 6
• Oh: 5
• Badger: 6
• Spam: 5
• Echo: 4

As a control group, here are some words that are not commonly repeated, and their associated AEDNs:

• With: 4
• Spoon: 3
• Grim: 2
• Cheek: 3

This proves conclusively that the items in the first list have longer AEDNs than the items in the second list, as of this writing.

That’s because Pages documents aren’t files, they’re bundles. Bundles are a special type of directory that OS X knows to treat as a file. Unfortunately, as my group discovered, you can’t email a directory! If you use Mac Mail, your Pages bundle will get automatically zipped, but those zipfiles get flagged as viruses by the UToronto mail server, and I wouldn’t be surprised if that held true for other servers as well. Can’t upload them to an FTP server, either. They’re just completely unsendable, and when you try, you get no explanation telling you whhy. Apple’s only suggestion is to zip the bundle before you send it. Mysteriously, people seem content with this solution even though, as bad solutions go, converting to Word is marginally easier.

This design decision is Microsoftian in its dumbness. Applications in OS X are bundles, which is fine because applications are not meant to be passed around casually. But documents — especially work documents, as in “iWork” — are meant to be opened by multiple people. OpenOffice documents are .tgz files, which have all the advantages of bundles with none of the drawbacks. Is that so hard? I can’t think of any reason why this would be difficult from an implementation perspective.

The problem is compounded by the fact that Pages doesn’t let me edit Word files directly. I have to import the Word file (as an untitled document), make my changes, and export it again. This turned our groupwork into a farcical dance of file conversion. I would write an assignment in Pages and export it to a .doc file so that I could email it to my group, who then had to import it into Pages to make changes, and export it again in order to email it back to me.

It’s a damn shame, because apart from this problem, Pages ‘08 is a masterpiece. It’s the best application Apple makes, as judged by its simplicity and ease of use relative to the complexity of the task it’s designed to perform. I think this bundle issue will keep it from getting the adoption it should. Microsoft gets tons of traction from network effects — if more people are using Word, you’ve got more incentive to use Word as well. But even if everyone in the world switched to Pages tomorrow, we’d still be tossing Word docs around.

Soon after declining Starbucks’s buyout offer, Hyman received the expected news that the company was opening up next to one of his stores. But instead of panicking, he decided to call his friend Jim Stewart, founder of the Seattle’s Best Coffee chain, to find out what really happens when a Starbucks opens nearby. “You’re going to love it,” Stewart reported. “They’ll do all of your marketing for you, and your sales will soar.” The prediction came true: Each new Starbucks store created a local buzz, drawing new converts to the latte-drinking fold. When the lines at Starbucks grew beyond the point of reason, these converts started venturing out—and, Look! There was another coffeehouse right next-door! Hyman’s new neighbor boosted his sales so much that he decided to turn the tactic around and start targeting Starbucks. “We bought a Chinese restaurant right next to one of their stores and converted it, and by God, it was doing $1 million a year right away,” he said.

The article also mentions that, unlike Wal-Mart, they don’t compete on price, so they actually have to make people like their products, which is a depressingly rare corporate strategy. But I also think Starbucks was responsible for introducing the whole concept of “good coffee” to the American conscience, thereby expanding the market for indie cafes. Many people think Starbucks coffee is swill, but I bet the only reason it occurs to them to make that judgment is because Starbucks spent the last fifteen years saturating them with the idea that coffee is something they should be picky about. That’s the sort of meme you can only propagate if you’re a very big company, and indie cafes should be somewhat glad that Starbucks spent the billions of dollars needed to spread that message for them.

I always wondered if my San Francisco location gave me a false impression of a robust, diverse cafe economy in America. I mean, if there’s going to be a Starbucks backlash anywhere, it’s gonna be here. But it sounds like small cafes are doing well anywhere that there’s demand for them. I certainly don’t think Starbucks is perfect (I hang out in indies usually), and I sympathize with anyone who hates the coffee or the cloying ads, but overall it’s a good thing they’re in business.

(via Daring Fireball)

They’re mostly generic thrillers, mysteries and military novels. The sort of books where characters have strong-chinned names like “Clint Magnum”. A yen for potboilers doesn’t necessarily reflect badly on someone, even a powerful someone, but lines like this are kinda creepy:

“For those who think the world does not possess weapons of mass murder with terrorists poised and ready to use them, this work of fiction is a good introduction to the dark side of the twenty-first century.”

He acknowledges that it’s fiction, but then says we should construct our non-fiction worldview around it. Unfortunately for him, I constructed my worldview around Douglas Adams books long ago. For those who think that mice are merely rodents, Adams’ works of fiction are a good introduction to their hyperdimensional intelligence and power. Be nice to mice, and obey their orders.

I don’t care if the applications that do those things aren’t as shiny as native iPhone apps — I need to be able to decide for myself whether installing a program is worth it or not. Apple didn’t design the thing for people with my priorities, and that’s fine, because that’s what Nokia is for. I got a Nokia E70 a few days ago (the iPhone is driving down prices of other smartphones on the secondhand market), and since then I’ve been a gleeful little nerd.

Last year’s BarCamp San Francisco was a bit of a transformative experience for me. I had a great time, schmoozed with great people, and became more confident about some ideas I had tossed around in my head for a long time. One of them has since borne fruit, and I’ll be talking about in an hour or two. My work on Quaintance has slowed to the occasional coding binge on plane trips, and I find that getting discussing my projects in a group spurs me to work on it more frequently.

It never occurred to me that I’d help to organize a BarCamp a year after my first one, but I did, and I’m astonished at the number of people who showed up and how smoothly it seems to be going. We (Will Pate, Bryce Johnson, Ryan Coleman, Mark Kuznicki and myself) threw this together in like three weeks, but in BarCamp terms, that’s plenty of time to do what needs to get done, apparently.

Technorati Tags: barcamp, barcampttw, torcamp, web2.0

The session was an introduction to the CRM API that some of the folks at Trellon have been working on. It’s basically an interface layer that allows module writers to add CRM functionality to their work without having to know the ins and outs of the various CRMs that are compatible with Drupal. For instance, a web contact form module may want to insert mailing events into a CRM, so that it can keep track of who’s used the form. There shouldn’t need to be a separate version of the module for SalesForce and one for CiviCRM. That’s what the API is for.

My demo served mainly to tell folks that this was happening, and to get feedback. There isn’t much to show at this juncture, because we’ve just started and we’re looking for community involvement. Here are some other resources:

• The project page at drupal.org
• The Drupal group for the API
• The announcement on the Trellon blog

Technorati Tags: barcamp, development, drupal,drupalcamptoronto ,interoperability

First up is the Debugging Techniques Swap Meet (slides: pdf ppt keynote). I wanted a session on debugging because there are precious few resources for debugging Drupal problems. Part of this is due to the structure of the Drupal documentation, but it’s also due to the many layers of technology involved in Drupal projects. I’m much more familiar with debugging techniques for HTML, CSS and Javascript than for the server side of things. Since I’m not a debugging guru, and it was a BarCamp, I decided to frame the session as a discussion rather than a listen-to-me-talk session.

I started with a discussion of hardware- and OS-level problems. I’m definitely less of a UNIX jockey than some of the other attendees — I don’t even use screen (yet), for chrissakes — but kbahey had led a terrific session on Friday about optimizing Drupal that included many useful tools. Optimizing isn’t quite the same as debugging, but when it comes to filesystem-level bugs, they tend to be permission problems that are not easily diagnosed with tools. I encourage people to look at Khalid’s slides and learn how to tail -f their various system logs.

Moving up to the Apache layer, there are still not many tools that can help with debugging here. Know your way around the conf file format, ensure that the critical modules (mod_rewrite, mod_php) are enabled, and that directories can overwrite permissions using a custom .htaccess file. Also, tail -f /var/log/httpd/error_log can help with problems. Someone mentioned a syntax highlighter for these error logs that make them easier to read, but I can’t remember what it’s called. It might be this GeSHi thing.

Further up, we’ve got PHP. Again, in general it’s good to know the conf file format, and to check that those php_ini directives can be modified from Drupal’s settings.php files. Check the Apache error log if you’re getting a blank screen — that means it’s a PHP error. The debugging tools I knew of were phpinfo() and the Zend debugger. Many folks scoffed with great scoffing scoffs at my mention of Zend. They claim Komodo is better. Interested parties should investigate; I’m not an IDE person and have never used Komodo. Ashok pointed out that Eclipse has a PHP plugin, and if I were an IDE person, that’s probably what I’d use, but it doesn’t come with its own debugger, only support for third parties.

Oy, I can’t talk about PHP bugs without talking about this one wacky problem some of us at Trellon ran into a few weeks ago. If you’re having trouble setting the maximum file upload size in the Drupal admin section, even after correctly setting max_post_size and upload_max_filesize, you should know that Drupal automatically sets the maximum file upload size to half of post_max_size. If you’ve got them set to equal amounts, it won’t solve the problem.

Then there’s Drupal itself. There are a few modules you should install on your staging site. Your first stop should be the devel module, which is a swiss army knife for aiding all sorts of development tasks. The trace module provides a customizable stack trace for errors — a huge improvement on the current error-reporting system. Finally, the drush module looks awesome. It provides a command-line shell interface for Drupal, making some admin stuff very easy.

In the non-module area, there are a million ways to log messages in various places. There’s watchdog(), but that’s not very immediate. There’s drupal_set_message(), of course. You can write to the various log files, or use the dprint_r() and db_queryd() functions that come with the devel module.

Now for the front-end stuff. This post is getting a bit long, so I’ll just say: FireBug, WebKit, Drosera, IE Developer Tools. Refer to the slides for more options.

And now, a bulleted list of miscellanea that people contributed:

1. Use CSS or HTML validation tools if you’re having issues. They can tell you about unclosed DIVs, for instance. Various FireFox plugins can help with this. Total Validator was recommended.
2. If you’re stumped by a CSS or HTML problem, try changing the DOCTYPE declaration at the top of the page.
3. The JavaScript IDE Aptana sounds cool, but it also sounds Rails-centric.
4. Don’t forget to ask in IRC! Lots of Drupal developers hang out in #jquery, as well as #drupal obviously.
5. The coder module is a “Developer Module that assists with code review and version upgrade.” It was endorsed by many people at the session.
6. We’re getting out of debugging territory with this one (who had the gall to go off topic? Oh yeah, it was me.), but module_builder is good for quickly and easily building module skeletons with nicely documented hooks and skeleton code.
7. I frequently encounter a blank screen immediately after loading a custom module for the first time. This means there’s a PHP error in the code, but it also means the whole site is down until you can disable the module. In order to do this, you’ll have to go into MySQL and find the “system” table in your Drupal database. Find the entry that corresponds to your module and change the “status” field to 0. Follow a similar procedure for blocks, except use the “blocks” table. The aforementioned drush module can also take care of this.
8. Finally, empty the cache on the server and the browser to avoid being confounded by cache issues when debugging.

I hope this list is useful, and Google-able. Feel free to add your own tips or resources in the comments.

Technorati Tags: barcamp, debugging, drupal, drupalcamptoronto,development

PROBLEM: There is no easy way to tell the TinyMCE window to accept dropped thumbnails.
CAUSE: The TinyMCE editor doesn’t exist when document.ready() is called, so there is no way to turn the editor into a Droppable() when the document finishes loading.
SOLUTION: I wrote a TinyMCE plugin that makes the editor Droppable in the initInstance() hook. That way, the editor makes itself into a Droppable when it’s good and ready.

The onDrop code is pretty simple as well. You just have to construct a snippet of HTML based on the thing that’s being dropped, and insert that snippet into the editor using tinyMCE.execInstanceCommand(). If the thumbnail that’s dropped is of an image (as determined by its class), build an IMG tag based on its attributes. If it’s audio or video, build an EMBED tag (except not. More on this later.).

PROBLEM: TinyMCE appears to modify URLs when it refreshes the canvas. If you’re on the page “/foo/bar/index.html”, and you create a link to something like “/image.jpg” in TinyMCE, you’ll find that when you move that image around, it disappears because its URL gets changed to “../../image.jpg”. This should resolve correctly, but on my Drupal system, it didn’t.
CAUSE: TinyMCE marshals many lines of code to accomplish this munging, because it’s actually a counter-measure for the URL rewrites that are apparently part of the Gecko editable-canvas window. I guess Gecko does the rewriting, and TinyMCE tries to counteract that with its counter-munging. These new URLs didn’t work with the Drupal installation on our server, apparently because all our development sites are in subdirectories on our development server. The base URL included these subdirectories, but the munging wasn’t taking them into account somehow.
SOLUTION: We set up a subdomain for this site, so that it could reside at top-level while we were working on it. I think the Drupal TinyMCE plugin needs to work on this.

PROBLEM: Once I got images working, it seemed like getting audio and video working would be trivial, and I gleefully reported this to my co-workers. Unfortunately, getting any HTML more complicated than images (such as a Quicktime EMBED tag) to display in TinyMCE proved difficult. The HTML that I dragged into the editor just wouldn’t show up, even when I dragged a movie in and disabled the rich-text editor.
CAUSE: At first, I tried to examine this by dragging the code into a plain textarea and then enabling rich text. Nothing happened, and nothing showed up in plaintext when I dragged a movie into TinyMCE and then clicked “disable rich-text”. Turns out, TinyMCE keeps a list of tags that you’re allowed to use, and filters out exotic ones like OBJECT with extreme prejudice unless told otherwise.
SOLUTION: To tell it otherwise, I enabled the media plugin. Plugins can modify the list of allowed tags, and the media plugin opens the door for Quicktime embeds and other fun things.

PROBLEM: Enabling the plugin still didn’t get me my QuickTime icon when I dragged and dropped.
CAUSE: Aside from filtering, TinyMCE performs other operations on HTML that make it such that the code I saw in the textarea did not accurately reflect the code that TinyMCE was rendering. Specifically, the QuickTime icon I was hoping to see was not some quirky rendering of a Quicktime plugin OBJECT, but was actually just a div with an image. The media plugin converts this DIV to OBJECT code when the form is submitted or the rich editor is disabled.
SOLUTION: Instead of attaching OBJECT code to QuickTime draggables, I attached DIV code that matched the code that TinyMCE generates from OBJECT tags. Worked like a charm: it gets displayed properly and is automatically converted to the right OBJECT html. At this point, the basic functionality was complete.

PROBLEM: Usually when you drag and drop an image into text, the text caret moves around with the mouse pointer, so that the image shows up where you dropped it, not where the text caret was when the user left the editing box. This wasn’t happening in TinyMCE. It happens when you drag things from one spot in the editor to another, but there doesn’t seem to be a way to get that behavior when you’re dragging something in from outside the box.
CAUSE: TinyMCE doesn’t have a good way of moving the caret around based on mouse position, because browsers don’t have good semantics for this.
SOLUTION: None. Wait for this kind of thing to become supported. I need to file a bug report.

PROBLEM: In FireFox, images don’t do a good job of keeping up with the mouse cursor when they’re dragged. After about half a second, the image catches up, unless the mouse is over the TinyMCE window, in which case the image hangs out at the edge of the window. The only way to get the image to catch up with the pointer is to move the pointer back outside the TinyMCE window. Unfortunately, the TinyMCE window is exactly where users will want to drop images, so this bug is actually rather serious.
CAUSE: The TinyMCE editor operates within an IFRAME, and IFRAMEs have their own separate DOM. When the mouse goes over the TinyMCE box, the mouseOver event goes to the IFRAME DOM, not the DOM of the larger document. The image that we’re dragging has no way of getting that mouseover event, because it’s part of the outside DOM and its mouse events are being intercepted. It’s Supposed To Be That Way, according to Mozilla.
Crucially, when the pointer is over the image and the image is over TinyMCE, it’s still in the parent window DOM, because the image is in the parent window DOM.
SOLUTION: If FireFox improved its dragging responsiveness, this would not be an issue. If FireFox changed its semantics to fire mouseover events in the parent window when drags were going on, that would solve the problem. I actually tried surrounding each of the draggable images a “trampoline” DIV that extends for 200px in each direction from the draggable image, so that there was always something between the mouse and the editor, but that was complicated (if you want to try that in certain Draggable modes, you have to access the copy of the image, not the image itself).
In the end, I realized that TinyMCE has an addEvent() function for attaching hooks to the IFRAME. I attached hooks that passed the events to a callback in the parent window. The callback called the onDrag() function of the Draggable, which, according to the Interface docs, allows me to alter the resultant coordinates of the image.

PROBLEM: That’s bullshit. The onDrag() function does no such thing.
CAUSE: There’s a separate callback, onDragModifier(), that does what we want here, but the most recent docs don’t mention it. In fact, the most recent docs don’t mention a host of useful parameters that callbacks like onDrag() can take.
SOLUTION: Submit new documentation, and use onDragModifier(). You basically adjust the position of the image to correspond with the coordinates you get from the IFRAME mousemove event.

PROBLEM: When you tell the image to assume the coordinates of the cursor over an IFRAME, the image winds up in either the upper-left or bottom-right corner of the screen.
CAUSE: The coordinates that get passed from the IFRAME are relative to the IFRAME, not the larger window. Also, the coordinate system in native DOM events is different than the one jQuery uses in its events (which seem to represent the location of an item relative to its original position, rather than the absolute screen position).
SOLUTION: Do some math to adjust the coordinates. I had to take the starting point of the image into account, and add the position of the TinyMCE window, or something, but in the end it worked really well. Make sure that code only gets applied when the browser is FireFox.

PROBLEM: Nothing works in Safari.
CAUSE: the mceInsertContent command of TinyMCE is totally broken for Safari. In fact, its whole browser-checking mechanism needs a tune up.
SOLUTION: Submitted a bug, working on a patch.

See, that wasn’t so hard now, was it?