Tag Archives: databases

Refocusing around Micro.blog

As I talked about on Timetable, now that I have the micro.blog domain I get to figure out what to do with it. And what I’m hearing from friends and listeners is clear: throw out my jumble of Snippets-related names and use Micro.blog as the brand for the platform. It’s obvious now.

Renaming a product before its official launch may not seem like a big deal, but in this case it gives the app a new importance. Just by renaming it, the app feels more ambitious. It forces me to devote more attention to it, which means saying goodbye to some of my other web apps that I can no longer focus on.

I have a difficult time shutting down failing products. Over the weekend, I took some much-needed steps to finish winding down Watermark and Searchpath. I’ll be sending an email this week to everyone who has used Searchpath with the details.

For Searchpath, I had procrastinated making a decision because even simple steps like closing new account registrations requires actually writing code and deploying changes. The index on my Elasticsearch server had grown to 90 GB, including Watermark as well. I needed a clean way to reset it and migrate the small number of active paid accounts somewhere else, to give customers time to find a new solution.

I’ve tried a few technologies for search over the years. The first version of Watermark used Sphinx, which I loved but became a scaling issue with its default need to completely reindex MySQL data. Eventually I moved to self-hosted Elasticsearch, but I had to keep feeding it RAM as the index grew. It was never stable enough with my limited skills.

As I noted in my post about Talkshow.im, there’s no perfect way to admit defeat and clean up the mess left by a web app. It’s always a balance of responsibilities — to your own business and to your customers.

But again, the way forward is clear. I should put everything into launching and growing my new microblog platform. It’s too much to maintain other web apps at the same time.

Parse shutting down

Bad news from the Parse team at Facebook today:

“We have a difficult announcement to make. Beginning today we’re winding down the Parse service, and Parse will be fully retired after a year-long period ending on January 28, 2017. We’re proud that we’ve been able to help so many of you build great mobile apps, but we need to focus our resources elsewhere.”

For years I had always heard great things about Parse. I eventually used it for the first time a few months ago on a client project. It’s got a well-designed API, friendly monthly pricing (free for many apps), and it seemed well supported, with new features like tvOS support and a web dashboard redesign rolling out just a month ago.

Thinking about this tweet from Daniel Jalkut, I’ve always advocated for iOS developers to also be good at web services. Customers expect sync everywhere now, and you can do things with your own server that will give you an advantage over competitors who have a simpler, standalone iOS app. But being forced to migrate server data isn’t fun, especially on someone else’s schedule.