Quite some years ago, I used to have an Apple blog called AppRecap. It contained a bunch of Apple-related news, but I also reviewed a load of iOS and macOS apps.

Well, today I realised that I had a backup of the website stored in Digital Ocean, and wanted to do some digging to see what was actually backed up. I did a small tweet thread on my initial findings, but I wanted to put something here on my blog so I have at least some reference to my old blog. Mainly because I plan on deleting the backup as it’s costing me money.

Some general things I noticed:

• I loved apps with dark mode. And if an app added one, that usually granted a blog post.
• My most used Mac apps were either super minimal or lived entirely in the menu bar.
• I thought the iPad Air 2 was “powerful”.
• I really would link to any Apple-related news.

I thought about migrating the entire collection of posts to my personal blog. But that was pretty much stopped when I realised I didn’t have the admin password anymore. I then thought that I should at least go through all the posts and add anything that was still useful. Well, I did that. And, well, I won’t be migrating anything.

Turns out, what I wrote about for AppRecap was very much only relevant in the moment. That’s pretty obvious for news-related posts, but also my experiences with software aren’t that valuable to read now, and most of the apps I covered are either substantially different or just plainly not available anymore. Weirdly, I recently wrote about blog posts having an expiry date, and turns out these definitely did.

However, I will share a few snippets, just because they’re pretty funny to read again in 2022:

Here is what I wrote about the Single Sign-On feature that was announced for tvOS at WWDC 2016:

It’s a pain to authenticate services on things like the Apple TV, especially when you have to find the app, go to a browser, enter a code, etc.But now with Single Sign-On, you just need to authenticate to a service once, and then apps that require the same authentication, can just access it themselves.I guess this will only be useful for people who use apps from the same company, maybe as part of a television subscription. But if you use individual apps from multiple networks, I can’t see this helping. Maybe it’s different in the US

Not sure about anyone else, but I can’t remember actually using this. And I’m not sure if it’s still a thing.

On Instagram’s initial move to “optimised” feeds:

According to the post, the actual images that are in your feed won’t change, however the order of them will be. I guess this is useful for people who follow a stupid amount of accounts, and this could help them find the best posts, but isn’t this just a reason to not follow too many people?I’m not a fan of non-chronological feeds for social networks, it’s one of the flaws in Facebook, and maybe soon, Instagram. When I use a service like Instagram, all I want to do is to be able to follow accounts that I like, and then see their posts in a chronological order.We should see this new “experience” in the coming months, I certainly hope we don’t.

I still feel the same way about this one.

Another on Instagram, this time on a new design and icon (the purple/pink/yellow gradient with the white symbol):

The changes they’ve made to the actual app are really nice, and I much prefer the new black and white interface.But I do not like the new icon.

Yep, the original icon is still the best in my opinion.

On Siri being added to the Mac in OS X 10.12:

I’ve been anticipating this feature for ages, it makes sense to bring it to the Mac when other companies such as Microsoft have done the same.I’m not sure how much functionality it will have compared to the iOS version, but I would personally think it should do more. However you could say that Siri is more beneficial for handheld devices, as it lets you perform more complicated functions easily. But with a Mac everything is pretty easy anyway, it’s just cool!

I was apparently very optimistic about Siri back then. It’s certainly gotten better since then, and I use it semi-regularly on my iPhone and HomePod, but I only ever invoke it on the Mac by accident.

On Twitter thinking about increasing the character limit from 140 to 10,000:

I’m not sure how I think about this at the minute, but my instant reaction was “this is a terrible idea”. I personally think the best thing about Twitter is the short statements, and a quick way of sharing with everyone.I also dislike the thought of scrolling endlessly through massive tweets, but I guess this could be fixed with an expand button for larger ones. This could also get annoying though, as you would be constantly be reading the headings and not real content.

They, obviously, only ended up increasing the limit to 280 characters, which turned out pretty well in my opinion. Although they did add a Twitter Write feature a while ago that added long-form text content, which for some reason, Elon wants to reinvent.

If you’ve made it this far, then I want to share another little funny story about AppRecap that I’ve just rediscovered.

So, back when I was writing AppRecap, I was still at university, and not exactly making much money. And for some reason, I liked the idea that I could one day sell a domain name for a high amount of money. That led me to sign up for Sedo, and place the apprecap.net domain for sale.

Well, in March 2016, I got an email from Sedo saying that I had actually successfully sold a domain name. And going by my tweets at the time, this was a bit of a surprise:

I just got a email saying AppRecap has been sold :O. I made it available on Sedo ages ago when I didn’t want to continue with it anymore. Tweet

But then I changed my mind and kept working on it, but forgot to make it unavailable. Is there a way to reject it? Tweet

After digging through my Sedo account and some old emails, turns out I had sold the AppRecap domain name for a whopping £299. But at that time I wasn’t ready to let it go.

So I talked with Sedo for a while, and eventually, they ended up cancelling the sale, luckily before the buyer made any payment.

That was around March 2016.

My last post for AppRecap, before starting a new blog called “Radical Thinker” (because I was cool and thought I knew some stuff), was about Tumblr adding live broadcasts, and that was on the 21st of June 2016.

I denied a sale of £299 so I could blog for another 3 months.

Eventually, I decided to stop renewing the domain, and some time since then, it was registered by someone else. Sadly, it’s not being used though, as it’s been set up to redirect to apprecap.io which doesn’t seem to work at all for me.

Going back over this blog has made me remember how much I enjoyed reviewing apps and covering Apple news. Maybe I’d enjoy writing about similar things again. But I have a feeling that it would end up being a lot of effort, and probably not provide enough value.

Finally, so I have at least some visual memories of the website, here are a few screenshots of it’s final form.

The first blog post (that was available in this backup, I’m pretty sure older ones have been lose):

The last blog post:

And a small glimpse into the sort of content I thought was relevant:

(It wasn’t.)

Yesterday, I configured my blog to support micro posts, and I had a lot of feedback asking, essentially, how I did it. So, I’ve decided to write exactly what I did to enable micro posts on my Ghost blog.

As a side note, my blog is a self-hosted instance of Ghost on Digital Ocean. This is the only way I’ve ever used Ghost, so if you pay for a Ghost instance directly on Ghost.org, then I’m not sure if you will have access to everything a self-hosted instance does.

What Is a Micro Post?

Essentially, a micro post is a blog post without a title, and usually of a very small size. Many people will associate them with Micro.blog. However, you may not realise that Twitter and Tumblr are forms of microblogging too. But the only real limitation that I’ve had to work around in Ghost, is the limitation of a post always needing a title, and the knock on effects of that throughout the feeds, website theme, etc.

How I Distinguish Micro Posts in Ghost

This is probably the simplest part. The way I distinguish micro posts from full post in my blog is with a new tag.

I now have a micro tag, which will be used as the sole tag on any micro post, which the rest of the solution is based on.

Displaying Them Differently on the Website

On my website, you can see that micro posts and full posts are styled slightly differently. The difference is relatively minor, and boils down to the removal of the title, and having the data become the permalink to the post.

This separation is handled via my custom theme, and in two ways.

Firstly, in places where I am building the layout for the post, I added a condition on the post having the micro tag, and then using separate layouts:

{{#has tag="micro"}}
	<!-- Micro post layout -->
{{else}}
	<!-- Full post layout -->
{{/has}}

Most of the differences are handled via the layout, but I also added specific styling for micro posts via CSS.

This is done via the {{post_class}} which I have added to the class of the article element in my post layout:

<article class="{{post_class}}">
	{{> "post-header"}}
	{{content}}
</article>

This results in the following HTML:

<article class="post tag-micro no-image">
	...
</article>

This means you can use the tag-micro class to directly make any style changes.

How Are the RSS Feeds Handled?

As for the RSS feeds, As you may have seen in my earlier post, I have now added three RSS feeds. One for micro posts, another for normal blog posts, and another for all posts. This is handled via Ghost’s Routing system, which I have only discovered recently, but which I currently use to manage my RSS feeds, and a few extra collections on my blog.

As for the routing, this is handled via a yaml file which is managed via the Ghost dashboard under Labs.

In my routes.yaml file, this is the section that contains the configuration for the RSS feeds.

routes:
  /feed/micro/:
    content_type: text/xml
    template: rss-micro
  /feed/:
    content_type: text/xml
    template: rss
  /feed/all/:
    content_type: text/xml
    template: rss-all

As you can see, the paths are defined, along with the content type, but the most important field is template, which refers to a .hbs file in my theme that handles the template for each RSS feed.

Each feed has a separate template, however instead of including each one here, I have uploaded them as GitHub gists to make it easier to see each entire file.

• rss.hbs - RSS feed for non-micro posts.
• rss-micro.hbs - RSS feed for micro posts.
• rss-full.hbs - RSS feed for all posts.

These templates are mostly identical. However, they do all differ on the data that is fetched, and also the title field.

As for the micro post feed, the data that is fetched is the latest 30 posts that have the micro tag. The title element is also left blank.

[...]

{{#get "posts" filter="tag:micro" limit="30" include="authors,tags"}}
	{{#foreach posts}}
	<item>
		<title></title>
		<[...]
	</item>
	{{/foreach}}
{{/get}}

[...]

The feed for the non-micro posts is similar, however has a limit of 15, and will, obviously, fetch all posts that do not have the micro tag.

[...]

{{#get "posts" filter="tag:-micro" limit="15" include="authors,tags"}}
	{{#foreach posts}}
	<item>
		<title><![CDATA[ {{title}} ]]></title>
		[...]
	</item>
	{{/foreach}}
{{/get}}

[...]

As for the combined feed, I have this fetching the most recent 15 posts. But there is also a condition on the micro tag, which is used to show/hide the title.

[...]

{{#get "posts" limit="15" include="authors,tags"}}
	{{#foreach posts}}
	<item>
		{{#has tag="micro"}}
		<title></title>
		{{else}}
		<title><![CDATA[ {{title}} ]]></title>
		{{/has}}
		[...]
	</item>
	{{/foreach}}
{{/get}}

[...]

How Are These Posts Imported to Micro.blog?

Thanks to the magic of Micro.blog, this really didn’t take much effort at all. This is handled via the newly created RSS feed that only contains micro posts.

The character limit of a micro post on Micro.blog is 280, so I have been keeping my micro posts within this limit. But simply by adding this new feed to Micro.blog, the posts are being imported to the platform and appearing on the timeline as if they were written there.

I have a feeling this is down to the lack of a title and the post length being within the limits, so I would assume this is also how it works if you are using another blogging platform.

Real-World Example

I’ve now gone over the work I needed to do to configure my blog to allow for micro posts, which leaves me with the question of how I actually write a micro post.

In the future, I want to try building out a Shortcut that can interact with my blog via an API. However, I have so far been writing them directly in the web editor.

There are just three things that I need to do to make a micro post, and have it handled correctly. Obviously, the post content and the new micro tag, but I also add a title of Micro.

You might wonder why I added a tag, since this whole concept is to have a post without a title. However, a title is still required in Ghost. What I’ve done, is to work around this restriction. In an ideal world, Ghost would remove this restriction, enabling posts with no titles, and then none of this would be necessary.

What this title does, is that it firstly gets around the restriction, but it also takes care of the slug. Because if I keep the title the same for all micro posts, the slug will automatically become micro-1, micro-2, etc. Meaning, I also don’t have to worry about the URLs looking ugly.

I hope this post can be of use to people who want to do the same or similar things with their blogs. But like I said earlier, it would be my preference if Ghost could handle this itself without any workarounds.

If you’re reading this, and you get stuck anywhere, please feel free to leave a comment below, or get in touch via Micro.blog, Twitter, or Email.