Google Apps Team Edition: extending an older domain with new services

Google has a version of Google Apps aimed at "teams" inside corporations who want to be able to collaborate beyond the limits of their IT department.

Welcome to Google Apps

Collaborate at work with Google Apps Team Edition.

• Work on the same document together, instead of sorting out changes in attachments
• Share documents and calendars securely with your co-workers with a click
• Access it all from any computer, and even from mobile phones
• Invite other team members to join and share with you

The trick is that Google Apps Team Edition can be setup without anyone demonstrating control over the corporate domain, though if you do demonstrate domain control then you can have more admin controls.

Using Google Apps would, of course, be cause for termination at many companies.

It has a safer potential use, however, as a way to extend an existing domain service.

An existing domain, like, for example, faughnan.com. I've long owned that domain; it's registered with Network Solutions and the DNS functions are managed by lunarpages. Through lunarpages I get the usual web/email/ftp services. The web pages are mostly legacy documents now, in part because they're published from a FrontPage 98 repository living on an old XP box.

In the past 10 years, I haven't come up with anything better. Google Sites, though, is interesting. It doesn't have many of the capabilities of FrontPage 98, but it has some other advantages. Most of all, though, a Sites collection is accessible from anything that can run Firefox/Camino/Safari/IE

It took only a few minutes to create a Google Apps Team Edition add-on for faughnan.com. The login name is my old faughnan.com email address and I've created a "Site" with a temporary address: http://sites.google.com/a/faughnan.com/faughnan-com-extension/Home

The next step will be to to ask Lunarpages (alas, they don't give us direct access) to add a CNAME pointing to whatever I end up calling this Site. After that point any web extensions on my Google Apps Team Edition site will appear to have an address like abc.faughnan.com

I'll post on how well this works - or doesn't work!

Yahoo! Pipes: what they're good for

I've posted a couple of times about Yahoo! Pipes, but I thought I didn't have a personal use case. Pipes do things like:

combine many feeds into one, then sort, filter and translate it

Now that I've lived in the Feed world a bit longer I can see LOTS of uses -- especially in a corporate settings. One example is when feed categories (streams, tags, labels etc) have their own feeds. Then one can combine well tagged posts from multiple sources into a single feed.

For example, in a few minutes, without reading any documentation, I merged two of my blogs into a single Pipe feed [1].

Now that's cool.

It would be much cooler if Google's Blogger supported category-specific feeds, but they don't. Other blog tools do better, I hope Blogger eventually joins the 21st century.[2]

[1] Pipes couldn't auto-discover the Blogger Atom feeds, I had to enter them directly.

Update 3/4/08: Oops. Blogger can do "label feeds" , but the capability isn't exposed in the templates I use -- not sure it's in any template. I'll have to explore a bit more.

OmniFocus for the iPhone - under development

The famed Omni Group evidently believes the iPhone SDK will allow apps to sync with the desktop:

Macworld: 25 native iPhone apps we hope to see

...We're working on a mobile version of OmniFocus for the iPhone which will synchronize with the desktop version. (We don't have the SDK yet, so we've been working on things that don't require the SDK: designing the mobile interface, adding synchronization support to the desktop app, and so on.)...

Sign me up for the beta program.

Update 3/8/2008: post-sdk release notice on the Omni blog. I'm now tracking that blog.

Aperture's peculiar selection behavior - primary only

Aperture can't manage iPhoto metadata that I care about, such as comments associated with albums. So I can't use it as my media management solution, but I'm still seeing if I can use it as an image editor.

It's not doing so well.

One of the peculiarities is 'select primary'.

It's easy to set this mode by accident -- an errant touch of the S key will do it. In this mode even if you select multiple images in the UI, one is "primary" (the first selected). Operations apply only to the Primary.

To disable this mode either unselect it in the Edit menu or type S again.

I'm sure it's a useful mode for a serious Aperture user, but it's awfully easy to set it by accident. Of course Aperture is a pro tool, while what I really want is iPhoto Plus (with !$%@ Library Import capabilities).

BTW, there's an obvious bug in Aperture. Switching to Quick Preview mode should place a checkmark in front of that item in the View menu. It doesn't.

Update 3/2/2008: Well, I'm still at a loss. Even when I disable Select Primary mode an adjustment operation is only applied to the Primary image. This could be a bug, or just odd design -- equally probable I'd guess. Aperture has always had quality issues for me. Aperture doesn't have integrated Help functions (another budget cutting move), and the old PDFs aren't even on the Help menu (a last minute delivery bug), so it's a pain to investigate. Despite delivery version 2.0 the product still feels like it's on life support.

Update 3/2/2008: From the awkward PDF only documentation:

You can apply an adjustment or group of adjustments to a range of images by first applying the adjustments to one image and then lifting the adjustments from the first image and stamping them on the other images. You do this by using the Lift and Stamp tools and the Lift & Stamp HUD.

So if you want to get started by applying an auto-adjust function you can't do it in two clicks, you have to use extra clicks. Why?

Update 3/2/2008b: From Apple Discussion.

...If I just copy an adjustment of the auto level from an image to others, i think the copied auto level is only based on the first image...

...That's correct. There's no way to auto-level multiple images at once in Aperture...

In other words, even using the awkward Lift and Stamp operation, you only apply the results of the image-specific auto-level setting to multiple images, you don't auto-level each in turn.

Bizarre.

Don't buy your iPhone yet

This is why I decided I wouldn't buy an iPhone until I saw exactly what the SDK would be:

iPhone/iPod SDK: Apple to approve, distribute apps, limit add-ons

...No accessory connectivity. Under current plans, SDK developers will be prevented from interfacing directly with Dock Connector-based accessories connected to the iPhone or iPod touch—a decision that we are told could cripple development of new accessories such as physical keyboards, traditional add-ons, and more ambitious, creative accessories such as Delphi’s iPhone car control prototype. One source described this limit as a guarantee that SDK-developed applications would be nearly as limited as current web-based ones, while consuming more of the device’s storage capacity. Yet integrated iPhone or iPod touch features such as the phone, Wi-Fi, and camera will be developer-accessible, certainly permitting development of programs that weren’t possible before. It is presently unclear whether Bluetooth 2.0, which is included in the iPhone but crippled to permit only monaural phone call streaming, will be opened to permit stereo audio streaming and data functionality as well.

Sources told iLounge that the collective impact of Apple’s decisions will be to control and stifle third-party development at a critical juncture in iPhone and iPod history, limiting what could be an open, thriving Mac-like collection of applications and accessories to a smaller, more stagnant iPod-like controlled environment. Consequently, a source suggests, developers who “jailbrake” iPhones and iPods to develop applications will be at an advantage relative to those who use Apple’s official tools...

No keyboard. No GPS. Nasty. All because Apple needs DRM control of movies, and has to block digital outflow by the port. I suspect they'll lockout Bluetooth for the same reason.

I want to see what it will be possible to sync across the dock. If sync is disabled I may decide to wait for the gPhone.

Use your headphones for iPhone calls -- with a Griffin SmartTalk adapter

I figured that when I buy an iPhone I'd also buy a Bose Communicator kit to go with it. Turns out there's a better, cheaper option:

Macworld | Review: iPhone headphone adapters

...The answer is to buy an iPhone headphone adapter, offering an iPhone-compatible mini plug on one end and a button and microphone on the other end, along with a place to plug in whatever headphones (or speakers, or cassette adapters — basically anything with a mini plug) you might have, as well as a clip to attach it to some part of your clothing close enough to your mouth to pick up your end of the conversation...

...The best of the bunch was the Griffin SmartTalk, a real bargain at $20. The SmartTalk’s microphone/clicker module is excellent, a compact block with a small integrated clip. The module was the least obtrusive of the ones I tested, and its button was easy to double-click when I wanted to switch tracks. Its microphone also offered the best sound quality of any of the adapters we tested, providing clear sound with a minimum of noise. The SmartTalk’s cord is wrapped in nylon, which makes it feel a bit classier than the rubber coating on the other adapters.

Besides being half the price of the Bose kit, the SmartTalk works with any headphone set. The Bose kit only works with newer versions of their headphones.

I don't think this would work all that well if the output was going to a car stereo though. Be real tough to avoid feedback with that setup ...

Microsoft Access: Snapshot and Dynaset recordset queries - what the heck are they?

Using Microsoft Access is a bit like being in an Indiana Jones movie. There are dark and mysterious ancient temples to explore, hidden treasures, snakes, spiders and the occasional death dealing trap. The scrolls that would explain everything are all losts in the mists of time, before there was a web.

It keeps me from boredom.

Yesterday a complex and powerful set of nested subqueries began retuning unpredictable results. Yes, I'd again broken Microsoft Access. It seems that Access was getting variable results depending on the sequence of subquery execution, such that it couldn't decide if a value were NULL or not.

So I tried to figure out if setting the sub-query(s) (recordset) to behave as a "Dynaset", "Dynaset (lazy update)" or "Snapshot"  would make any difference.

First, of course, I looked for documentation on what the differences are. It's not in the Access Help files. Google found precious little at first -- one of my page one results was a post I wrote in January 2006!)

This search worked better: recordset, dynaset, snapshot.

From it I got a few references:

O'Reilly Network -- Access Design and Programming Tips

But it is important to remember that DAO (Data Access Object) provides several forms of recordsets: table-type, dynaset, snapshot, and forward-only. The point here is that if a snapshot or forward-only recordset will suit your purposes, you should use it, because it will be more efficient and therefore your code will run more quickly.

Snapshot recordsets are faster to create and to access than dynaset recordsets, but they use more memory because the entire record is stored in memory. The downside is that you cannot update the records in a snapshot recordset.

Forward-only recordsets are like snapshot recordsets, but you can only move forward through the recordset.

Ultimately, the only way to tell whether you will save significant processing time is to try the various suitable recordset types in a given situation. The point here is to not fall into the habit of always creating a table-type or dynaset-type recordset.

and

DAO Object Model The Definitive Reference Chapter 8 Recordsets Collection and Recordset Object

...There are five types of recordsets: Table-type, Dynaset, Snapshot, Forward-only, and Dynamic. (See the Type property section for a discussion of recordset types.) Each Recordset object contains a collection of Fields that represents the fields in the underlying table(s). You can list the field names and values, but you will just get the values in the current record, unless you first go to a particular record. For example, the following code moves to the last record in a recordset and lists the field names and values for that record:...

Recordset Property Summary which shows almost NO difference between Snapshot and Dynaset.

But then we come to the precious table 8-13:

Dynaset: Represents a table or an updatable query. Supports the AddNew, Delete, and Find* methods, but not the Seek method.

Snapshot: A read-only recordset; useful for finding data or printing. Does not allow updating, except in the case of an updatable Snapshot in an ODBCDirect workspace. Supports the Find* methods.

Elsewhere I read

Dynaset:
1. Can be formed by large number of tables resulting in Virtual Tables.
2. Does not store on the Machine but occupy temporary memory that is RAM.
3. The changes made in the database can be reflected in the this.
4. Allows operations like edit and update.

SnapShot:
1. Creates table on the machine and occupies space of the memory.
2. Does not allow edit and update operations.
3. Can be used for small amount of data.

Another source (lost) said a Snapshot is often quite a bit faster in a query than a Dynaset, but the speed requires more memory use.

By extension of the above, I imagine "Dynaset (lazy update)" is an extension of Dynaset with some of the speed of a Snapshot but the possibility of doing updates (delayed or lazily).

So, after all that, did changing some of my subqueries to "Snapshot" fix the problem of the "Schrodinger's Cat" results that were sometimes NULL and sometimes NOT NULL?

Yes, it did. The results were much faster too.