I get asked about SEO a lot, and it’s a topic I have a some pretty strong opinions about. So this morning, when my wife relayed a message from a friend asking for suggestions (the friend is starting a new business), I responded with the following text, and figured I might as well record it here also in the interest of giving my future self something substantive to link to.

Here’s what I said.

> There are lots of things to consider, but these are the big ones:
>
> *   Have good page titles and descriptions. These are sometimes called “meta tags”, and most website publishing platforms allow you to set them on a page-by-page basis. By “good”, I mean they (1) correlate closely with the content of the page and (2) correlate with the keywords you expect people to be searching by. Page titles are what show up as the link text in a Google search result, and descriptions are what (sometimes) show up in the text just below the link and in social-media previews. Craft these thoughtfully, and if you can, use the same keywords in your page URLs as well.
>
> *   Write lots of good content into your pages. Short pages that don’t have much “stuff” in them generally aren’t as relevant (to humans) as longer pages are, and search engines know this. Having lots of textual content that search engines can ingest and index gives them more data to use to determine whether to show your page instead of someone else’s. The more content you have, and the more relevant it is to the visitors you want to attract, the better. It’s also a good idea to add new content regularly (daily, weekly), as this signals timeliness, and search engines tend to assume people are more interested in stuff that’s been updated recently than stuff that’s been sitting around unchanged for a while.
>
> *   Get trusted domains to link to you. This is by far the the most important, and unfortunately the one over which you have least direct control. SEO is based primarily on two things: content and page rank. Content is the previous two bullets and something you have *total* control over. Page rank is basically the quantitative measurement of “how relevant you are”, and your relevance is directly related to how many other relevant websites link to yours. Note that they need to be relevant themselves; if you’re selling a book, and I link to your website from my low-traffic personal blog that’s mostly about about gardening, I won’t be improving your relevance *as a bookseller* as much as I would be if I linked to you from my popular, highly respected book-review website. Every link is like a tiny upvote, and while lots of upvotes is generally good, higher-quality upvotes matter much more, and lots of low-quality upvotes can actually damage your SEO credibility. (Which is why it’s a good idea to steer clear of most SEO firms, as they often attempt to manipulate this algorithm to boost your numbers just long enough to take your money and disappear when your page rank falls back to earth.)
>
> Basically, just write lots of good-quality content and encourage people to link to you, and you’ll be fine. It can take a little time to build up that relevance, but it’ll happen.

As a content person myself, I know there’s a lot more to it than this — way more, in fact. But the impact curve to the right of these three points is a *long* tail that most people just don’t need to care about. If you get these foundational things right, you’re way ahead of the game, and the web will find its way to you. The rest won’t make nearly as much of a difference.


Don’t stress. It’s easier than you think.


A few thoughts on SEO


I’ll be honest: I don’t *fully* know what I’m doing, [bailing on Twitter](https://twitter.com/cnunciato/status/1594361226066563072) and [moving to Mastodon](https://hachyderm.io/@cnunciato), except that it feels like the right thing to do, and it definitely feels like the right time to do it.

I’ve heard here and there that [Mastodon](https://joinmastodon.org/) is a “different” social experience from Twitter, and I haven’t fully taken the time to learn how — but the thought of continuing to hang around on Twitter, with a [nutjob at the helm](https://www.nytimes.com/2022/11/18/technology/elon-musk-twitter-workers-quit.html?action=click\&module=Well\&pgtype=Homepage\&section=Technology) now and with [Trump reinstated](https://www.nytimes.com/2022/11/19/technology/trump-twitter-musk.html) (not to mention all the *noise*, *ads*, and relentless self-promotion), just makes me feel sick inside. The last few weeks have made clear what an astonishingly despicable person Elon Musk really is, and I can’t bear the idea of lending any more of my time, attention, and creative energy to the business venture of yet another despicable person. I left Facebook in 2008 for the same reason, and aside from missing out on a few family photos from time to time, I haven’t regretted that decision since.

So far, [Mastodon](https://mastodon.social) looks like an [interesting experiment](https://www.nytimes.com/2022/11/07/technology/mastodon-twitter-elon-musk.html?searchResultPosition=5) — and if the influx of new users over the weekend is any guide, the experiment might actually be working. Most of the people I follow on Twitter are already there, which doesn’t hurt. And I love the open and distributed nature of Mastodon, too. Kris [@nova](https://hachyderm.io/@nova) and her colleagues have done an amazing job setting up [hachyderm](https://hachyderm.io) and defining the guidelines for the community; I must say, it’s hard not to love the official [Don’t be a Dick policy](https://github.com/hachyderm/community#dont-be-a-dick-policy), which I’m hoping will shut up at least a few of the insufferable loudmouths I’ve had to endure over the past several months. So I’m excited, to say the least. Fingers crossed — we’ll see how this goes.

Oh! And here’s where you’ll find me: <https://hachyderm.io/@cnunciato>.


So long, Twitter! It was was fun while it lasted, kinda.


Moving from Twitter to Mastodon


Lately I’ve been hacking away on a handful of [Pulumi templates](https://pulumi.com/templates) to make it easier to deploy common cloud architectures — static websites, serverless apps, containers, virtual machines, and the like. The idea with templates is that with a single run of `pulumi new`, you should be able to kick out a finished program, in your language of choice, that works out of the box and can handle the most common scenarios, while still leaving you plenty of room for expansion and customization. Templates, I think, are one of Pulumi’s most unsung (and unique) features; unlike [components](https://www.pulumi.com/docs/intro/concepts/resources/components/), they’re open rather than closed, so they tend to be great not just for bootstrapping new projects, but also as tools for learning, as they’re pretty much made to be tinkered with.

My first task was to build out a set of templates for [static websites](https://pulumi.com/templates/static-website), which, as you probably know, are essentially just a bunch of HTML, CSS, and JavaScript files stuffed into a folder somewhere. This site, for example, is a static website built with [Next.js](https://nextjs.org/), one of the more popular static-site generators these days, and as of today, it clocks in at a little over a thousand pages. At work, we build [pulumi.com](https://pulumi.com) with another popular static-site generator called [Hugo](https://gohugo.io/), and all up, that site comes in at a little over 20,000 pages. Static websites vary drsmatically in terms of size and complexity, but ultimately they all have that same thing in common: they’re all just a bunch of files in a folder on a computer connected to the internet — a computer that likely belongs either to Amazon Web Service, Microsoft Azure, or Google Cloud Platform.

But while building out the first set of these templates, I ran into a problem: getting files into the cloud isn’t always as easy as you’d think, at least not with declarative infrastucture-as-code tools like Pulumi.

Here’s an example. Imagine you had a bunch of files in a folder on your computer that you wanted to get into the cloud. With Pulumi, the way to do that would be to begin by writing a program declaring some cloud storage, which, if you were using AWS, might look something like this:

```typescript
import * as aws from "@pulumi/aws";

// Make a bucket.
const bucket = new aws.s3.Bucket("my-bucket");
```

Easy enough, bucket created. Now, let’s upload some files!

Here’s where things get tricky, though. Most of the examples you’ll find online (including several I’ve written myself) handle this by using the programming environment to fetch a list of files from the filesystem, then declare them, one by one, as individual cloud resources, like so:

```typescript
import * as aws from "@pulumi/aws";
import * as fs from "fs";
import * as mime from "mime";
import * as glob from "glob";

// Make a bucket.
const bucket = new aws.s3.Bucket("my-bucket");

// List the files in `myFolder`, then for each one, declare an `s3.BucketObject`.
glob.sync(`${myFolder}/**/*`).forEach((path: string) => {
    if (!fs.lstatSync(path).isDirectory()) {
        let object = new aws.s3.BucketObject(path.replace(siteDir, ""), {
            bucket: this.resource,
            source: new pulumi.asset.FileAsset(path),
            contentType: mime.getType(path) || "text/plain",
        });
    }
});
```

And this works, to be sure. With Python, Go, C#, Java, things look a bit different of course, but in general, the approach is the same: make a bucket, then use the facilities of your chosen programming language to get the files into the bucket.

But while being able to break out of the declarative box and write a little code when you need to is awesome — indeed, it’s one of the other things that makes Pulumi so special — there’s something about *having* to write code like this I also find a bit irritating. All I need to do point a push a folder into the cloud. Shouldn’t I be able to just say *that?* Why do I have to dig into the filesystem, generate and manipulate a bunch of file paths, programmatically deduce MIME types, and so on, just to move a bunch of stuff verbatim from one folder to another? I mean it’s great that you *can* do that, sure. But it’d also be great if you didn’t have to.

And sometimes, you just can’t. Take YAML, for instance. I *love* our YAML support. It’s so tidy:

```yaml
resources:

  # Make a bucket.
  my-bucket:
    type: aws:s3:Bucket
```

But there’s one little problem with YAML: It isn’t a programming language. Unlike with languages like TypeScript and others, you can’t break out of the box and reach into the filesystem with YAML — and that’s by design. We built YAML to give our users the tersest, most statically declarative option we could, and we did: you literally *can’t* write code with Pulumi YAML, just [expressions](https://www.pulumi.com/docs/reference/yaml/#expressions). Of course, you can always [convert your program to a different language](https://www.pulumi.com/docs/reference/cli/pulumi_convert/) if you find YAML too limiting, and that’s great, too — but it’s also a pretty big thing to have consider when all you need to do is push a few files into the cloud.

So I took a few days to figure this out, for all languages and all three major clouds. The result is a little [Pulumi package](https://www.pulumi.com/docs/guides/pulumi-packages/) called [Synced Folder](https://www.pulumi.com/registry/packages/synced-folder/).

## Introducing Synced Folder

Synced Folder is a [multi-language Pulumi component](https://www.pulumi.com/blog/pulumiup-pulumi-packages-multi-language-components/) that you can install and use with any Pulumi-supported language. It’s deliberately simple and focused, and it works — or at least it’s my hope that it works — exactly as you’d imagine: make a bucket, sync a folder to that bucket, and be done. Here’s how it looks in TypeScript, for example:

```typescript
import * as aws from "@pulumi/aws";
import * as synced from "@pulumi/synced-folder";

// Make a bucket.
const bucket = new aws.s3.Bucket("my-bucket", {
    acl: aws.s3.PublicReadAcl,
});

// Sync the contents of `my-folder` to the bucket.
const folder = new synced.S3BucketFolder("synced-folder", {
    path: "./my-folder",
    bucketName: bucket.bucket,
    acl: aws.s3.PublicReadAcl,
});
```

Here’s an example in Python:

```python
from pulumi_aws import s3
import pulumi_synced_folder

# Make a bucket.
bucket = s3.Bucket(
    "my-bucket",
    acl=s3.CannedAcl.PUBLIC_READ,
)

# Sync the contents of `my-folder` to the bucket.
folder = pulumi_synced_folder.S3BucketFolder(
    "synced-folder",
    path="./my-folder",
    bucket_name=bucket.bucket,
    acl=s3.CannedAcl.PUBLIC_READ,
)
```

And in Go:

```go
package main

import (
	"github.com/pulumi/pulumi-aws/sdk/v5/go/aws/s3"
	synced "github.com/pulumi/pulumi-synced-folder/sdk/go/synced-folder"
	"github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
	pulumi.Run(func(ctx *pulumi.Context) error {

        // Make a bucket.
		bucket, err := s3.NewBucket(ctx, "my-bucket", &s3.BucketArgs{
			Acl: s3.CannedAclPublicRead,
		})
		if err != nil {
			return err
		}

        // Sync the contents of `my-folder` to the bucket.
		_, err = synced.NewS3BucketFolder(ctx, "synced-folder", &synced.S3BucketFolderArgs{
			Path:       pulumi.String("./my-folder"),
			BucketName: bucket.Bucket,
			Acl:        s3.CannedAclPublicRead,
		})
		if err != nil {
			return err
		}

		return nil
	})
}
```

In C#:

```csharp
using Pulumi;
using Pulumi.Aws.S3;
using Pulumi.SyncedFolder;

return await Deployment.RunAsync(() =>
{
    // Make a bucket.
    var bucket = new Bucket("my-bucket", new BucketArgs {
        Acl = CannedAcl.PublicRead,
    });

    // Sync the contents of `my-folder` to the bucket.
    var folder = new S3BucketFolder("synced-folder", new S3BucketFolderArgs {
        Path = "./my-folder",
        BucketName = bucket.BucketName,
        Acl = (string)CannedAcl.PublicRead,
    });
});
```

And finally, in YAML:

```yaml
resources:

  # Make a bucket.
  my-bucket:
    type: aws:s3:Bucket
    properties:
      acl: public-read

  # Sync the contents of `my-folder` to the bucket.
  synced-folder:
    type: synced-folder:index:S3BucketFolder
    properties:
      path: ./my-folder
      bucketName: ${my-bucket.bucket}
      acl: public-read
```

And if you’re targeting Microsoft Azure or Google Cloud, it’s just the same: make an Azure Blob Storage container or a Google Cloud Storage bucket, then drop in a reference to Synced Folder and call it a day. [See the docs](https://www.pulumi.com/registry/packages/synced-folder/) for examples with various languages and clouds.

To deploy the contents of the folder, just run `pulumi up` in the usual way:

```bash
$ pulumi up
```

When you make local changes to the files in your synced folder — add new files, delete old ones, change existing ones, etc. — simply deploy the changes again in the same way. (Changes, by the way, are synced one way only, folder to cloud, so deleting a file in the cloud will have no effect on the files on your local machine.)

To remove the cloud bucket and all of its contents, run `pulumi destroy`:

```bash
$ pulumi destroy
```

Pretty neat, IMHO — and again, hopefully works just like you’d expect.

## Bonus feature: Unmanaged file objects

One thing you’ll notice about the component’s default behavior is that it manages your files as individual cloud resources — e.g., as discrete Amazon `s3.BucketObject`s or Azure `storage.Blob`s — and not just as an abstract “folder” resource. For folders that contain only a few files, that’s probably fine, and indeed it’s sometimes nice to have Pulumi track changes to those files individually as well. But if your folder were to contain, say, a thousand files or more, you could end up waiting a long time for Pulumi to examine and reconcile the state of every last one of those file objects. Moreover, if you happen to be using Pulumi on a commercial plan, you might not love the idea of each one of those objects contributing to your monthly bill.

So to address these two unpleasantries, I added an option to instruct Pulumi to ignore individual files and instead, delegate the work of synchronization to the cloud provider’s official CLI. By setting the optional property `managedObjects` to `false`, you can have Pulumi invoke the AWS, Azure, or Google Cloud CLI during an update to sync your files that way instead:

```typescript
import * as aws from "@pulumi/aws";
import * as synced from "@pulumi/synced-folder";

const bucket = new aws.s3.Bucket("my-bucket", {
    acl: aws.s3.PublicReadAcl,
});

const folder = new synced.S3BucketFolder("synced-folder", {
    path: "./my-folder",
    bucketName: bucket.bucket,
    acl: aws.s3.PublicReadAcl,

    // 👇 Set this property to false to manage files with `aws s3 sync`.
    managedObjects: false,
});
```

Synchronization-wise, the effect the same: files that exist locally but not remotely are uploaded, and those that exist remotely but not locally are deleted. But the upshot is that it’s *much* faster and less expensive than using Pulumi alone, so if you’re okay with Pulumi shelling out to the `aws`, `az`, or `gcloud` command-line tools, you might want to give it a try. Again, [see the docs for details and examples](https://www.pulumi.com/registry/packages/synced-folder/#managed-and-unmanaged-file-objects).

Enjoy! And happy Pulumifying.


This multi-language Pulumi component package makes it easy


Sync a Folder to Any Cloud with Pulumi


A friend once told me — or rather announced to the group of friends with we happened to be standing around at the time, in line for a roller coaster in Southern California — that I didn’t have enough “stick-to-it-ness” to be a writer.

It was one of those out-of-nowhere comments that kind of hit you from the side, like an unprovoked smack — and it was odder still since by then, I’d already been working as a writer for a handful of years.

But it was also true that this person wasn’t wrong. Yes, I’d been writing professionally since college (tech writing mostly, with some [freelancing](https://www.ocweekly.com/) on the side), and yes, writing had in fact been paying my bills — if barely so. But it was also true that I hadn’t gone through the writing program at [UC Irvine](https://uci.edu) to learn how to write the Great American User Guide. What I wanted back then, or so I thought, was to write short stories and screenplays, and eventually maybe make a little movie or two of my own. I certainly *liked* technical writing (probably more than I cared to admit), but technical writing was definitely a means to an end, a practical solution to the problem of making a living stringing words together. To get by, I figured I’d work my day job, slinging tech docs like everyone else, then come home at night and work on the stuff I really cared about.

The problem, though, as any full-time-working human will tell you, was that by the time I got home, I was legitimately beat; the last thing I wanted to do after staring at a screen all day writing about network-attached storage was come home and stare at another screen trying to write fiction that, if I was honest, I wasn’t sure I cared about as much I probably should. So day after day, moving through life as it happened, I just kept on *not writing*, promising myself I’d try harder tomorrow.

And I did, from time to time — but it never really went anywhere. Tech writing led pretty quickly to programming — docs were moving from print to HTML, and my creative imagination was immediately hooked by the potential of the web — and the demands of becoming a programmer (self-teaching, job hunting, several years working in startups and then venturing off on my own) ate up just about all of my time and mental energy and left me even more exhausted than tech writing or journalism ever had. Somehow I still managed to get a lot done with the next two decades — went to grad school, studied film theory (and loved it), made a few really bad, really fun movies of my own, got married, moved to Seattle, built a life in the Pacific Northwest \[^1] and brought three more lovely humans into the world whose company I get to enjoy working from home every day. But writing, for the most part, once my programming career took off, never quite found its way back to the central place in my life that it once held.

Here’s the thing, though: it was never a stick-to-it-ness problem, and it wasn’t that I was simply *too tired*, either. It was interest. My brain was simply *more interested* in messing around with *other stuff* than it was in writing fiction. If I’d cared about writing fiction as much as I cared about programming and the web, I’d have written fiction until I fell out of my chair. I didn’t. Instead, I read tech books, learned languages, built websites, went to conferences, and did just about everything I could to get better at making software. And not because I had to. Because it was *fun*.

But the urge to write *something* has definitely never left me. The mind I have now may be different from the mind I had in college, but it still wants to write, and it still wants to make movies — just not the same kinds of writing and movies it did back then. These days, I’m much more interested in finding things out, figuring out what I think about those things and trying to explain them, being a good dad and teacher (the hardest things ever), and just trying to capture the beauty and overall interestingness of the world around me as best I can.

So to that end, expect me to start showing up here a little more often as I work to figure out what that means in terms of writing. I’ve got [one technical book on the way already](https://thepulumibook.com/) — maybe not so much a means to an end after all — and I’m sure there’ll be more — though about what, I’ve no idea. Time will tell, though. It always does.

\[^1]: … which I love — though I do still miss California pretty terribly sometimes.


The obligatory post about vowing to write more posts


Dusting off the cobwebs


Imperatively Declarative


This past weekend, I did a [Twitch session for Manning](https://twitch.tv/manningpublications) in which I built a little serverless app with [Pulumi](https://pulumi.com) and [Mapbox](https://mapbox.com) and deployed it on [Amazon Web Services](https://aws.amazon.com). It was the first time I’d ever done such a thing — I’ve done many demos, but never a public live-coding session — and surprisingly (to me, at least), I actually enjoyed it. In a little over an hour, I wrote an app with Pulumi and TypeScript that renders GPS-tagged photos on a map with AWS [S3](https://docs.aws.amazon.com/s3/), [Lambda](https://docs.aws.amazon.com/lambda/), [DynamoDB](https://docs.aws.amazon.com/dynamodb/) and [API Gateway](https://docs.aws.amazon.com/apigateway/), and aside from a few little bumps, and my crazy-long COVID hair, everything worked out pretty well.

The hardest part was definitely setting up [OBS Studio](https://obsproject.com/), but now that that’s done, I plan to start doing more of these, as they’re (a) fun and (b) probably the best way to demonstrate how Pulumi really works and what makes it so awesome.

You’ll find the [full recording here](https://www.twitch.tv/videos/793943710), and the annotated code of the finished product’s [up on GitHub](https://github.com/cnunciato/photomap). Enjoy!


Live Coding with Pulumi, Mapbox, and Leaflet


Good news, friends! I’m writing a book.

In *Pulumi in Action*, I’ll be writing about how to use [Pulumi](https://pulumi.com), the open-source project I work on full time, to build cloud applications and infrastructure with [TypeScript](https://www.typescriptlang.org/) and [Amazon Web Services](https://aws.amazon.com/). I’m incredibly excited about this book — it’s my first — so I’m writing this post as a public expression of that excitement. (My wife often says I don’t often emote as much as I should, so I’m attaching an appropriately celebratory emoji as well, lest we be left with any lingering doubt. 🎉)

As of now, I’ve only written the [first few chapters](https://livebook.manning.com/book/pulumi-in-action), but since the book is the first ever focused on Pulumi, [Manning](https://manning.com) (the publisher) wanted to release it as a work-in-progress through [MEAP](https://www.manning.com/meap-program), its early-access program. Thanks to them, you can both read and purchase — or if you like, read and *not* purchase — the book today, and as new chapters roll out, at around once a month, you’ll get access to them immediately, in all of the finest digital formats of the day. It’ll cover a lot of surface area — infrastructure as code, Pulumi itself, cloud-native software development and delivery patterns, and more — and is generally aimed at helping full-stack developers get a solid foothold into the cloud. You can read the first chapter for free [on manning.com](https://www.manning.com/books/pulumi-in-action?a_aid=chris\&a_bid=20ca8d8a) today, and browse all of the examples [on GitHub](https://github.com/pulumi-in-action). The print version is scheduled to ship sometime early next year, and should come in at around 300 pages.

So that’s it — that’s the post. I *had* written around two thousand words recounting the tale of how it was that I, a mere web developer, came to write a book about [infrastructure-as-code](https://en.wikipedia.org/wiki/Infrastructure_as_code), but my wife, upon reading those words, declared that most of them were unnecessary: what mattered, she pointed out, was what was *in* the book. So I’ll save the full backstory for the eventual preface, and for now, leave you with this: if you’re a full-stack developer, you should check out [Pulumi](https://pulumi.com), and when you’re ready to learn more, [I’ll be here](https://www.manning.com/books/pulumi-in-action?a_aid=chris\&a_bid=20ca8d8a).

> **Update**: I’m still writing a book — just not *this* book. After the better part of a year, I decided to part ways with Manning — long (and rather odd) story — and [publish the book on my own](https://leanpub.com/pulumi). You’ll find the *new* (and still in-progress!) book on Leanpub. [Check it out](https://leanpub.com/pulumi)!


Pulumi in Action is available now in early access.


I’m writing a book!


I’ve been a user of [Adobe Lightroom](https://www.adobe.com/products/photoshop-lightroom.html) for several years now, and I’ve generally been happy with it. While I’ve never been in love with the Lightroom interface — it works, but design-wise it’s a bit on the clunky side, and dated, and it often performs sluggishy even on my newish Macbook Pro — but it’s generally gotten the job done, and there aren’t, even in 2018, many photo-management apps that can handle tens of thousands of photos and videos.

I’m not the only one in my house who takes pictures anymore, either. My wife is a great photographer herself (she has a much better eye than I do, actually), and my kids are starting to get into it, too. So managing everyone’s photos, and making sure we all have access to them, has been a serious challenge for me over the years. I’ve thrown together many an awful hack, some involving external drives, some shared network drives, synchronization schemes, DropBox (nope), even dedicated computers, but nothing ever seemed to work, mainly because Lightroom operates as a window onto your filesystem: you can do just about anything you want with it, but your pictures have to be *on your computer* (or on a drive connected to it), which makes sharing your library with your scrapbooking wife an invariably awkward and frustrating process.

So when Adobe announced Lightroom CC, a cloud-based approach and ground-up rewrite of what’s now called Lightroom Classic, I was excited: it looked like we might finally be able to keep all of our photos (and videos!) in the Adobe cloud, and share them all easily between our Macs and our iPhones. I downloaded the app, fired it up, chose Migrate Lightroom Catalog, pointed it at my `.lrcat`, and let it run.

![](/media/images/migrate-catalog.jpg)

The import took a while, and when that was done, it took another couple of weeks to get everything uploaded and synchronized. But the result was *glorious*: not only was my entire library available on my laptop, but it was also synced magically to my phone, to the Lightroom website, and *to my wife’s laptop and phone*, too — I was thrilled. And since the Lightroom CC mobile app lets you choose to have all of your photos uploaded automatically, whatever my wife happened to shoot with her iPhone would show up moments later on my desktop, and vice-versa. As a software engineer who understands the complexity of this problem, I was (and remain) thoroughly impressed with Lightroom CC. It’s not perfect, and it’s certainly not free, but it’s *by far* the most sophisticated and complete solution out there today.

There was one little problem, though.

When the migration from Classic to CC had finished, I noticed a number of my pictures (some 9,500 of them, in fact) had been dropped into a bucket labeled **No Date** — which was odd, considering that hadn’t been the case in Lightroom Classic, and irritating, given how date-oriented I am in my photography. (A bit of Googling led me to realize this is a [fairly common problem](https://forums.adobe.com/thread/2438359).) The only remedy seemed to be tweaking the Capture Date manually, one photo at a time, using the controls in the UI — which would’ve been fine, if there were only a few, but with close to ten thousand of them, I’d be at it for the better part of a week fixing them up, which seemed insane. There had to be a better way.

![](/media/images/lightroom-edit-date.jpg)

One of the nifty things about Lightroom Classic is that it uses a [SQLite](https://www.sqlite.org/index.html) database to store everything about your photos, including their dates, which means, if you’re a geek like me (I *love* SQLite), you can get in there and run queries to fix these kinds of problems on your own. Lightroom CC *appears* to use SQLite also, but even if I could update its database manually (the schema is completely different), a number of the photos in the dateless batch really did seem to lack one or more [EXIF](https://en.wikipedia.org/wiki/Exif) dates; the right thing to do would be to update the files themselves and set their date fields properly.

So I came up with a plan, and with a little trial and error, it worked.  Here’s what I did:

1.  First, I exported all of the photos in the **No Date** bucket into a folder on my desktop called `Exports`. The important thing here wasn’t the photos themselves, but their filenames. You’ll see why next.

2.  Then I wrote a little program to locate each of those files, using their filenames, in their original (i.e., Lightroom Classic-managed) locations, which for me happened to be on an external drive. The program would copy them into another folder on my desktop called `Originals`, leaving me with two folders, side-by-side: one called `Exports`, the other called `Originals`.

3.  After checking to make sure the number of originals matched the number of exports — meaning I had an original for every No Date export — I deleted the contents of the No Date bucket in Lightroom CC.

4.  Then I ran another program called `exiftool` on each file in the `Originals` folder, setting its EXIF capture date using the original file’s creation date. This might not work for everyone, but given my workflow, it happened to be a safe bet that the creation date would be pretty close to the actual capture date, so I went with it.

5.  Finally, with all of my `Original`s now properly dated, I imported them into Lightroom CC.

That was it — no more No Dates!

I’ll run through the steps in detail below, in case you happen to find yourself in this predicament, too. You’ll have to do a little [Bash](https://www.gnu.org/software/bash/) scripting to make this work, so I’m assuming you’re on a Mac (apologies to Windows users) and that you’re relatively comfortable on the command line.

Okay! Let’s make this work.

***

## Step 1: Create Two Folders on Your Desktop

Pretty straightforward. Again, I named mine `Exports` and `Originals`.

## Step 2: Export Your Dateless Photos

In Lightroom CC, click **By Date**, then scroll to the **No Date** folder and click it. Choose Edit » Select All, then File » Save To, then browse to your `Exports` folder and click Choose. Let the process finish — it’ll probably take a few minutes.

## Step 3: Find Your Originals

Open a Terminal and make a new file on your desktop called `find-originals.sh` and make it executable:

```shell
$ cd ~/Desktop
$ touch find-originals.sh
$ chmod +x find-originals.sh
```

Then copy the following script into that file and save it:

```bash
for f in $1/*; do
  exported="$(basename $f)"

  # Locate the original
  original="$(find $2 -name ${exported})"

  # If the original isn't found, log it and continue;
  # otherwise, copy it over
  if [ -z "$original" ]; then
    echo "Could not find a match for $exported"
  else
    echo "Found a match for $exported -- copying"
    cp -vf "$original" $3/
  fi
done
```

The script accepts three arguments:

*   the path to your `Exports` folder
*   the path to your Lightroom Classic originals
*   the path to your `Originals` folder

As I mentioned, I had exported my **No Date** files into a folder on my desktop called `Exports`. My originals were located on an external drive called `Elements`, and the empty destination folder, `Originals`, was on my desktop alongside `Exports`. So the command I ran was:

```shell
$ ./find-originals.sh \
    /Users/cnunciato/Desktop/Exports \
    /Volumes/Elements/Media/Lightroom \
    /Users/cnunciato/Desktop/Originals
```

When that finally finished, I had about 9,500 files in `Originals`, which matched the number of images in the **No Date** bucket in Lightroom CC. I could now safely delete the bad ones.

Feel free to comment out the actual `cp` statement at first, just to make sure you’ve wired things up correctly. When you’re ready, run it for real. (We’re just copying, here, so don’t worry — all you have to lose is a little time and disk space, temporarily.)

## Step 4: Kill All No-Dates

You can do it! After all, you still have your Lightroom Classic originals — and now copies of them, even — and you’ve verified the number of files in `Originals` matches the count of your **No Date**s in Lightroom CC. So go on — select all, Edit » Delete, and get ‘em outta there.

Well done.

## Step 6: Write Out Some EXIF Dates

As I said, I was sure a good number of my photos really didn’t have EXIF dates (over a thousand of them were from an old Samsung flip-phone), and I wanted to fix that problem properly by modifying the files themselves, rather than just their Lightroom metadata.

![](/media/images/me/flip-phone-selfie.jpg)

There’s an [amazing little command-line app](https://sno.phy.queensu.ca/~phil/exiftool/) called `exiftool` that’ll both tell you which files are lacking certain EXIF fields (e.g., dates) and also let you set their values, either “in place” (meaning on the source file itself) or, if you’re a little paranoid like me, on a copy of the file, preserving your original.

So I did this in two steps: first, I ran `exiftool` to find out how many dateless photos I had, and then I ran it for real to copy each file and burn a capture date into it. (I shoot a lot of video, too, and `exiftool` handles video formats, also — even the obscure ones from the early 2000s! It’s really great stuff.)

So assuming you’ve still got that same Terminal open on your desktop, run `exiftool` on your `Originals` folder to get a count of how many dateless images you’re dealing with:

```shell
$ exiftool -createdate -if 'not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00")' ./Originals
```

This command asks `exiftool` to tell you which of the files in `./Originals` is missing a `datetimeoriginal` value, which is what Lightroom considers a capture date. When you run it, you’ll get some output for each file, along with an aggregate result at the end. If, for example, I’d had three files in my `Originals` folder, two with dates and one without, my output might’ve looked something like this:

```shell
$ exiftool -createdate -if 'not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00")' ./Originals
======== ./Originals/IMG_2949.PNG
    1 directories scanned
    2 files failed condition
    1 image files read
```

Personally I find this output a little inscrutable, but I believe what it means is that two of those files *have dates* (i.e., they failed the `-if` condition of `not $datetimeoriginal`). If instead we’d gotten something like this:

```shell
1 directories scanned
3 files failed condition
0 image files read
```

… then we’d be done, as `exiftool` would be telling us that all of our files actually *have* capture dates. In my case, though, I had around 3,000 without them, so I decided to go ahead and update them all.

To do that yourself, run:

```shell
exiftool -P -O ./Output/ '-datetimeoriginal<filemodifydate' -if '(not $datetimeoriginal or ($datetimeoriginal eq "0000:00:00 00:00:00"))' .
```

This is essentially the same command you ran above, but with some additional options instructing `exiftool` to *do some stuff:*

*   `-P` means “preserve my originals”
*   `-O ./Output/` means “put the modified copies into the `./Output/` directory”
*   `'-datetimeoriginal<filemodifydate'` means “set the capture date using the date the file was last modified” (which for me was also the date it was created)

If you’d like to use a different algorithm for setting your own EXIF capture dates (or even just learn more about what this awesome little program can do for you), [check out the `exiftool` docs](https://www.sno.phy.queensu.ca/~phil/exiftool/exiftool_pod.html).

Once this was finished — it ran surprisingly quickly, considering how many photos I was processing — I imported a few into Lightroom CC just to make sure things looked right. When they did, I imported them all.

## Step 7: Re-Import!

The hard part’s done. Now, just choose File » Add Photos, browse to your newly populated `Output` folder, and click Review for Import. If things look good, click that shiny Add Photos button, then sit back and watch the magic happen.

## Step 8: Celebrate

Well done! With any luck, once Step 7 completes, that **No Date** folder should be a thing of the past. If that’s the case, go ahead and delete everything we created from your Desktop. You’re done.

![Cheers.](s3/images/20140622-14-56-18-4.jpg)

***

I’m sure I’ll write more about Lightroom in general; while I’m definitely a CC convert now, I still use Classic to manage my kids’ catalogs (they each have their own — they shoot way too many pictures of absolutely nothing), and the CC software is continually evolving, which is awesome (and yes, occasionally frustrating). Nothing is perfect, but man, I have to say — on the whole, glitches and all, I’m still really impressed, and stoked that we’ve finally found system that works pretty much seamlessly for us.


How I managed to migrate from Lightroom to Lightroom CC


Bad Dates


First post! Exciting, right?

It’s really more like my five-thousandth, if you count everything I’ve stuffed into various micro- and regular-sized websites over the years (so many, and nearly all lost to history, alas), but that probably only matters to me, anyway. You’re here because — well, I’m not sure why you’re here. But I’m glad you are nonetheless.

I don’t have much to share yet, but I will. For now, I’ll just say thanks for stopping by, and encourage you to return: I plan to take lots of pictures, make lots of little movies, and write virtual reams (reams, I say!) of words, some of which you might actually enjoy, if we’re lucky.

In the meantime, here’s a snapshot from a hike we went on recently, at the beautiful [Redmond Watershed Preserve](https://www.wta.org/go-hiking/hikes/redmond-watershed-preserve).

![A mossy fern.](/media/images/mossyfern.jpg)

Have a lovely day, and do come back soon, won’t you.
