Site Update and My Move From Tumblr

Photo by Christopher Burns

It’s been a while since I’ve posted here. I’m sorry about that. I had thought I was going to start getting into a nice cadence for posting content.

Over the past few years, I’ve been using Tumblr as my main blogging platform. I used to really like using Tumblr. Since I started posting on Tumblr a few years ago, not much has changed with the service. The dashboard interface and editor are frustrating to use. I usually spend about 5 minutes searching the site for a feature I want to use.

In the past few years, I’ve also started using Medium. I really like their interface for almost everything. It’s not perfect, but it’s so much better than trying to use Tumblr. Medium also brings me a lot of exposure to my posts that I wouldn’t receive otherwise. I’m also not sure Medium is the appropriate place to post more personal posts like this one.

I had been cross-posting my more technical posts to my personal blog and my Medium site. I think for now I’ll continue to do that.

My Alternative to Tumblr

I’ve been tinkering with several alternatives using Tumblr for the last few weeks. I’ve finally come to the following approach.

I’ve set up a GitHub repo and I am using GitHub Pages to host the pages. It’s an open repository. And I did that on purpose. I don’t really care if you take a look at how I have things set up. Feel free.

GitHub Pages allows you to use custom domains. So I just have my domain (ryan.grier.co) pointing to my GitHub Pages site.

The site is using Jekyll, which is supported by GitHub Pages. The theme I’m using is a modified Lanyon theme. I think this theme the best of the pre-made ones I’ve found, but it’s a little outdated and needed some updates.

Using Jekyll allows me to test the website locally before committing my changes to GitHub and (automatically) deploying them to the site. I can also write all of my blog posts (and pages) in Markdown (using Ulysses).

This setup and process aren’t exactly perfect yet, but I’m working on it.

Added SSL to the Site

One thing I’ve been meaning to do for a while now is to add SSL (HTTPS) to the site. When I originally asked Tumblr Support, they didn’t support SSL with custom domains. They may now, I haven’t looked.

GitHub Pages doesn’t support this out of the box. Instead, you can use Cloudflair to accomplish this. It’s exactly what I did. They have a blog post on how to set this up. They make it super easy to set up and use.

Conclusion

Prior to finding GitHub Pages, I had already started converting my site to use Jekyll. I was going to use that somewhere to host the site. I had imported all of my old Tumblr posts to the new format. Since I had the conversion work taken care of, setting up the GitHub repo and GitHub Pages took about 30 minutes to get up and working.

I am very happy with how this setup is working so far. My opinion may change as I work out the kinks in my posting process.

I hope that this change will get me back to regularly posting content here (and on Medium). I guess only time will tell.

Data Sync Series - Part 4

This is the fourth blog post in my new blog series on data syncing in an app. Links to all of the posts in the series are at the bottom of this post.

Where Have I Been?

I know it’s been a while since I’ve posted anything or done any work on this series. Life has gotten in the way. This Summer has been a pretty rough ride for my family. I thought that I would have this series finished by now. But family is more important than any blog series that I could work on.

Sorry for the delay. I should be able to get back on track now

App Update

I’ve pushed up the initial version of ListsApp to GitHub. It’s a very very bare bones iOS app. It was built with various versions of the Xcode 9 beta and Swift 4.

The app has a series of lists. Each list contains items. You can add/delete lists and items. Very simple, I know. It’s supposed to be simple(ish). I don’t want to complexities of an app to get in the way of the syncing mechanism. But I also wanted the app to be a bit more than something I can store in something like iCloud’s NSUbiquitousKeyValueStore.

The data within the app is all stored in memory, so nothing is persisted. When you restart the app, the sample data reloads. There is also no syncing mechanism in place. Baby steps. I wanted to get the bones of the app in place. Now I can start with the next steps.

What’s Next?

The next step is for me to remove the in-memory data source and replace it with an actual persistence layer. I think I’m going to move forward with Realm for my persistence layer.

I also need to clean up the code a bit. I worked on this code in a very haphazard fashion. I worked on it when I could this Summer. 30 minutes here and there. This means that I could have missed something or committed something that was meant to be temporary (or sloppy).

At some point in this project, I want to add unit testing. I used to be a real proponent of unit testing (back in my enterprise Java days). Since I’ve moved to iOS, Objective-C and Swift I’ve really gotten bad about unit testing. I need to learn how to do this properly.

Realm? Why?

We use Realm at my work for our persistence layer. I’ve used Core Data in the past, but I want to (and should) get more experience with Realm.

I could start down this path and change my mind. Or I could get adventurous and develop multiple persistence layers that you can pick. But if it took me this long to get where I am, I wouldn’t get my hopes up. That’s just a long way of saying I may change my mind.

My Hope

I really hope this next phase takes less time than it did to develop the base app. I feel pretty bad about this series taking this long. But sometimes life just gets in the way.

Part 1 | Part 2 | Part 3

Data Sync Series - Part 3

This is the third blog post in my new blog series on data syncing in an app. Links to all of the posts in the series are at the bottom of this post.

So. I’ve got an idea for an app. It’s not a great idea. It’s not original. It won’t make me a penny. But I think it will work well for this series on data syncing.

My daughter gave me the idea for a shared family grocery list. She wanted fruit snacks from the grocery store. I kept forgetting to pick them up, and she said we should have a shared list for groceries. I know there are other apps out there for this, but I needed an idea for this series.

The App

The app will be a series of lists. You can use them as TODO lists, or shopping lists, etc.

Lists can be either private and shared. Private lists will be your own thing that no one else can see. Shared lists will be able to edited by multiple people that you’ve shared the list with.

Here’s a quick wireframe of what this simple app may end up looking like.

There’s not a lot going on. There doesn’t really need to be. The important part of this app is that there is data to be synced between devices and shared between users.

More App Details

The app will be written entirely in Swift 4 in Xcode 9. The deployment target for the app will be iOS 11. There’s really no need to work with anything else in this project.

I’ll be using CloudKit and either Core Data or Realm. I haven’t fully committed to Core Data or Realm as the persistence model. I’ve used CoreData for numerous projects in the past. We use Realm at my day job, I would mind learning more about it.

This will be an app for both iPhone and iPad. These days that should really be self explanatory, but I thought I would mention it anyway. Depending on how things go, I may make it available for the Apple Watch too.

What’s Next?

The next step is for me to start building this thing. Once I get something very basic in place, I’ll be publishing it to GitHub in my repo for this project calls listsApp.

Notes:

I used this Sketch Resource to build the wireframe above: Mobile UI Wireframe Kit Sketch Resource

Part 1 | Part 2 | Part 4

Data Sync Series - Part 2

This is the second blog post in my new blog series on data syncing in an app. You can read the first one here. This took me a little longer than I wanted, I got busy with the kids and end of year school stuff for them. Sorry for any delay.

In this post, I’m going to take a look at the various types of data synchronization that exist and outline which one I’ll be using in the new app that I develop.

A lot of the data synchronization technique information listed here is taken from this excellent article on Objc.io called Data Synchronization by Drew McCormack. He does a great job of explaining this topic. Some of the example services in his post no longer exist, but the concepts are solid.

Synchronization Types

At a very high level, there are two types of data synchronization. Both of the synchronization types can be either synchronous or asynchronous. This technically makes four types of synchronization methods. The two types are Client-Server and Peer-to-Peer synchronization.

Client-Server Synchronization

The client-server approach means that there is a server which acts as the source of truth. Not only does the server act as the source of truth, it also has some “smarts” built in to handle any conflicts that may come up.

In many of the applications that I have developed as an iOS Engineer have used a Synchronous Client-Server model. The server (or set of servers) act as a source of truth. The clients request the latest data from the server. But any changes to the data are immediately sent to the server for processing.

An Asynchronous Client-Server model works just like the synchronous version, except there is an in-app (local) copy of the data. This is usually a third party solution that gets integrated into your app. Any third party solution here, takes care of syncing with a server. The application’s interaction with the data should remain the same as the synchronous version of this model.

Peer-to-Peer Synchronization

Peer-to-Peer synchronization means that there isn’t a “smart” server in place, the syncing and any conflict resolution is handled by the clients.

Synchronous Peer-to-Peer is old school. It was used largely for syncing things like devices (iPods, etc). Clients (or peers) communicate with each other synchronously.

In an Asynchronous Peer-to-Peer model, the clients communicate with each other, figure out the most accurate data (or “truth”) and deal with any conflicts that may arise. The only data that is often passed between clients (and “the cloud”) are transactional logs, or what’s changed in the data.

Conflict Resolution

I mentioned conflicts a few times earlier. What are they? A conflict is when the same data is changed in two different locations. The server or clients, need to know how to resolve the conflict. There are a few ways to do that, but I’ll save that for another post.

Our Synchronization

For the exercise that I outlined in my previous post, I’ll be using an asynchronous peer-to-peer model. I think that this model is ideal for iOS (and other mobile) clients. This allows for the most flexibility in a (still) questionably connected world.

The cloud storage mechanism we’ll be using is CloudKit. In the past, I’ve wanted to use Core Data iCloud Sync. Using CloudKit isn’t a huge departure from that desire to stick with Apple technologies. CloudKit has been reported as a solid technology.

Wrapping Up

I did not go into great detail about the various synchronization types. Drew already did a very good job of that in his article. I wanted to give much briefer overview.

This is how I understand these syncing types. If I’m wrong, or misguided, please feel free to let me know. I’ll be happy to make any corrections.

In the next post, I’ll be discussing the app itself. I have the rough idea for a new app in my mind. The details haven’t been completely worked out yet, but I’m OK with the details changing.

Soon enough the real work (and fun) will begin.

Part 1 | Part 3 | Part 4

Data Sync Series - Part 1

I’ve been thinking about incorporating a data syncing component to my app MyCntdwn for a long time now. I have just never gotten around to it. It’s always been a daunting idea.

When I first wanted to add data syncing to MyCntdwn, it was 2012 and Core Data iCloud Sync was a thing. It was also a mess. I had a few false starts using Core Data iCloud Sync. I even spent time with Apple Engineers at WWDC and still couldn’t get it working right. I eventually gave up on it. I’ve heard that Core Data and CloudKit have made things much easier to get working, but I don’t have any experience.

My first experience with data syncing in 2012 has really scared me off. I’ve thought about it from time to time, but never really committed to it.

It’s time. It’s time to finally sit down and figure out how to do this. I’m going to do things a bit different here. I could just spend the Spring/Summer figuring out how to do data sync, add it to my app and call it a day. Instead, I’m starting this series.

This series is going to be an experiment. I plan on writing a completely new app, open-sourcing it, and documenting the entire thing. This could be a huge failure. I could get three or four blog posts into the series and give up. I hope that doesn’t happen. I hope that I can follow through on this idea. It’s an ambitious project for me.

I have an idea for the project. I’m not sure which technologies I’ll use for syncing. I believe I have several options for the syncing technology, but that’s something I’ll weigh in a future blog post.

Part 2 | Part 3 | Part 4