Gopal Sharma's Blog

Kotlin Data Class Constructor Problem Follow Up

Fri, 18 Aug 2017 15:23:00 +0530

I wrote about a problem I was having with Kotlin data class constructors a few days ago. I sent it to a few people and asked for thoughts on how they might address the issue.

A few people proposed a few different possible solutions to the problem. I thought I’d write them down here, as well as what I ended up doing.

Make constructor private

One proposed solution was to make the constructor private and instead have a factory method:

data class User private constructor (
    val userId: UUID,
    val name: String,
    val emailId: String
) {
    companion object {
        fun create(
            userId: UUID,
            name: String,
            emailId: String
        ) {
            return User(
                userId = userId,
                name = name.trim(),
                emailId = emailId.toLowerCase()
            )
        }
    }
}

On the face of it, this looks like a good solution. However, there is a problem with it that IDEA very nicely warns you about: the copy method.

Even if you make the constructor private, it is still exposed by the copy method that is generated by the compiler.

You could still write something like this:

val user = User.create(UUID.randomUUID(), "Foo", "foo@bar.com")
user.copy(emailId = "FOO@bar.com")

which is problematic.

Make fields private

Another proposed solution looks like this:

data class User(
    val userId: UUID,
    private var _name: String,
    private val _emailId: String
) {
    val name: String
        get() = _name.trim()

    val emailId: String
        get() = _emailId.toLowerCase()
}

There’re unfortunately a couple of problems with this as well. First, every time you read name, or emailId you end up creating a whole new object, which means more garbage. This seems unnecessarily wasteful.

Second, the call site becomes ugly:

val user = User(
    userId = UUID.randomUUID(),
    _name = "Foo",
    _emailId = "foo@bar.com"
)

Admittedly, this is not a problem if you don’t use named parameters. However, named parameters are super useful, especially when you have model objects (the obvious use case for data classes) with > 5 parameters. It significantly reduces the likelihood of making a mistake.

Eventual non solution

Eventually, I wasn’t able to find any solutions to this problem that still allowed me to use data classes. So I ended up not using a data class, and instead writing out all the boilerplate necessary:

class User private constructor(
    val userId: UUID,
    val name: String,
    val emailId: String
) {

    companion object {
        fun create(
            userId: UUID,
            name: String,
            emailId: String,
        ): User {
            return User(
                userId = userId,
                name = name.trim(),
                emailId = emailId.toLowerCase().trim()
            )
        }
    }

    override fun equals(other: Any?): Boolean {
        // Have IDEA generate this for me
        // Remember to re-generate it everytime I add a property to this class
    }

    override fun hashCode(): Int {
        // Have IDEA generate this for me
        // Remember to re-generate it everytime I add a property to this class
    }

    // Unfortunately IDEA cannot generate this for me, so type it out
    // I might eventually create a live template for this
    fun copy(
        userId: UUID = this.userId,
        name: String = this.name,
        emailId: String = this.emailId
    ): User {
        return create(
            userId,
            name.trim(),
            emailId.toLowerCase().trim()
        )
    }
}

Not ideal, but it works…

If you have a better solution in mind, please do let me know: @gopalkri!

Subscriptions

Thu, 17 Aug 2017 10:21:03 +0530

Recently, a lot of iOS and macOS apps have switched from a pay once and use until next major version pricing model to a subscription model. The latest example I’m aware of is Ulysses. I don’t use Ulysses, but one of the apps I use that has also made the switch is 1Password. There’s been a lot of discussion about this all over the internet.

Here’s a quick summary of both sides of the debate. Some people think subscriptions for iOS and macOS apps are good - they provide a way to increase revenue, and have it be more predictable. Other people are of the opinion that subscriptions do not make sense for “apps” - people are ok with paying a subscription fee for something like Dropbox, but not for an app like Ulysses. I thought that the discussion on the latest CoreInt episode put forth both sides of this debate much better than I can. I highly recommend giving it a listen.

However, I feel like there are some factors I haven’t seen discussed yet (perhaps they have been, and I just haven’t seen it).

Total cost of ownership

Most apps switching from a paid upgrades model to a recurring subscription model are also raising their total cost of ownership at the same time. Even if the amount of money you pay up front is lower, your total cost of ownership is way higher.

I’ve been a 1Password user for over 5 years now. During that time, I’ve spent around $75 on 1Password for Mac, and iOS. I use Dropbox to sync my passwords, but I don’t pay for Dropbox specifically for 1Password.

If you think about the total cost of ownership over 5 years, with 1Password’s subscription model, which is $2.99 per month (billed annually), that’s $180. That is more than 2 times my previous total cost of ownership!

So far, I haven’t really seen anyone make the switch from paid upgrades to subscriptions without also dramatically increasing the total cost of ownership. I’d be very interested to see if the backlash against subscriptions is as high if the total cost is no different, or lower.

The only things I can think of that reduce or maintain total cost of ownership are all content subscriptions. Things like Netflix, Apple Music, etc. If I watch 2 or 3 movies a month that are available on Netflix, I’ve reduced my price compared to renting them on iTunes (this is partly why I pay for Netflix). Having said that, content and software are really different beasts, so I’m not sure this really applies.

Subscriptions are good because developers won’t hold back features

The argument here is that in the paid upgrades pricing model, developers have to hold back features that are ready for the next major release in order to make paying for an upgrade worth while.

I think this has theory has already proven itself to be invalid. Great example: Adobe Lightroom. In the last 2 years, Lightroom has added virtually no meaningful new features. I’ve paid adobe $240 over that period for absolutely nothing.

This leads me to my next point…

Comparisons to Adobe, Office 365, etc.

A lot of people are pointing to subscriptions like Adobe’s Creative Cloud, and Microsoft’s Office 365 as successful switches to subscription based models. However, I believe this is a misleading comparison to make.

There are no alternatives to Adobe Creative Cloud, and Microsoft Office for the vast majority of people using it. Think about it - what would a Lightroom user switch to? What would a Photoshop user switch to? What would a Microsoft Office user switch to? You could say Apple Photos, Pixelmator, Acorn, or iWork, but really, in a professional context, none of those are real options. Even if you’re willing to switch, the people you work with won’t.

So even if Adobe and Microsoft do atrocious things like having a garbage installer, not allowing you to unsubscribe without making 12 phone calls, or charging you outrageous amounts of money for absolutely nothing in return, you’re still going to have to pay them - you simply have no choice.

Ulysses, 1Password, etc. however, are not in that category. For most users, there are loads of alternatives.

So when do subscriptions work?

I think Manton was on to something on CoreInt when he said people are willing to pay for apps with a server component because there are real costs to running servers. However, I’m not convinced that most people really understand the details of how software is built, and that servers cost money, etc. I like to think of it more as a difference between products and services.

Let’s take software out of the picture for a moment. Would you pay once a week to have someone clean your house? You would. Would you pay once a week to have a vacuum cleaner in your house? Highly unlikely!

In summary, I believe that subscriptions are great for services. They are a much harder sell for products.

Kotlin Data Class Constructor Problem

Tue, 15 Aug 2017 10:25:22 +0530

I’ve been trying to do something with a model class in Kotlin that I’ve done many times before in Java, and I’ve been left without a clean way to do what I need.

Here’s what I’m trying to do in java:

import org.jetbrains.annotations.NotNull;

import java.util.UUID;

class User {

    @NotNull
    private final UUID userId;

    @NotNull
    private final String name;

    @NotNull
    private final String emailId;

    User(@NotNull final UUID userId, @NotNull final String name, @NotNull final String emailId) {
        this.userId = userId;
        this.name = name.trim();
        this.emailId = emailId.toLowerCase();
    }

    @NotNull
    UUID getUserId() {
        return userId;
    }

    @NotNull
    String getName() {
        return name;
    }

    @NotNull
    String getEmailId() {
        return emailId;
    }

}

The key things to note are the calls to name.trim(), and emailId.toLowerCase() in the constructor. These calls ensure that every User object created has a “valid” value for name and emailId.

Initially, in kotlin, this is what I had:

data class User(
    val userId: UUID,
    val name: String,
    val emailId: String
)

The problem here is that I don’t see any way of putting in the calls to trim() and toLowerCase().

Do you know of any ways to solve this problem? Please let me know: @gopalkri!

An Interesting Swift Benchmark

Thu, 27 Jul 2017 12:15:56 +0530

Problem

I recently wrote about creating extensions on Optional<String>. When I shared this post in the Swift India slack group, one of the people there pointed out to me that I could just use the nil coalescing operator instead of the extension methods I’d created.

So:

fooLabel.text = bar.foo ?? ""

instead of:

fooLabel.text = bar.foo.orEmpty()

I had a real doh! moment for not thinking of this myself. I was going to update my original post to say “well actually, nevermind - just use the nil coalescing operator”. Then however, I got some more feedback, which is why I let the post remain.

One person told me that they didn’t even know Swift had a nil coalescing operator, and that orEmpty was obvious to them where ?? was not. Hmm, interesting. The fact that I knew the nil coalescing operator existed, but didn’t think to use it made me think that perhaps orEmpty was cleaner. FWIW, I’m still not sure what the right tradeoff to make is in this regard - use a language feature that may not be super obvious, or use something custom that probably won’t exist in other projects?

The more interesting piece of feedback I got though, was that the nil coalescing operator was slow in terms of build time. I believe it was based off of this post. While that sort of made some sense intuitively, I figured I’d write a quick benchmark to see if I could prove/disprove that theory.

The general strategy was to generate Swift source files that used each of these ways of doing the same thing and measure how long it took to compile.

Experiment

Here’s the quick and dirty python script I wrote to do this:

#!/usr/bin/python

import os
import time

common = '''
extension Optional {
    public func or(other: Wrapped) -> Wrapped {
        if let ret = self {
            return ret
        } else {
            return other
        }
    }
}
extension Optional where Wrapped == String {
    public func orEmpty() -> String {
        return self.or(other: "")
    }
}

struct Foo {
    let foo: String?
}
let foo = Foo.init(foo: "foo")
'''

N = [1, 100, 500, 1000, 2500, 5000, 10000]
M = 10


def benchmark(name, template):
    for n in N:
        content = '' + common
        for i in range(n):
            content += template.format(i)
        fn = os.path.expanduser('~/Desktop/foo.swift')
        with open(fn, 'w') as fout:
            fout.write(content)
        results = []
        for i in range(M):
            st = time.time()
            os.system('swiftc -o ' + os.path.expanduser('~/Desktop/foo') + ' ' + fn)
            et = time.time()
            results.append(et-st)
        write_csv([str(n), name] + [str(r) for r in results])


def write_csv(line):
    with open(os.path.expanduser('~/Desktop/results.csv'), 'a') as fout:
        fout.write(', '.join(line))
        fout.write('\n')

try:
    os.remove(os.path.expanduser('~/Desktop/results.csv'))
except FileNotFoundError:
    pass

benchmark('nil', '''
let a{} = foo.foo ?? ""
''')
benchmark('nil with type specified', '''
let a{}: String = foo.foo ?? ""
''')
benchmark('empty', '''
let a{} = foo.foo.orEmpty()
''')
benchmark('empty with type specified', '''
let a{}: String = foo.foo.orEmpty()
''')
benchmark('other', '''
let a{} = foo.foo.or(other: "")
''')
benchmark('other with type specified', '''
let a{}: String = foo.foo.or(other: "")
''')

Results

I ran it on my 15 inch 2017 Macbook Pro with a 2.8 GHz Intel Core i7 processor plugged into power, and fully charged (be warned: this takes a few hours to run - I let it run overnight). I used the swift compiler that ships with Xcode 8.3.3. I took the median of the 10 samples, and graphed them:

So, it turns out I was totally wrong - the nil coalescing operator is way faster than my ways.

However, I noticed something weird that the graph above hides:

You may want to open those images up in a new tab - they’re much higher res than is visible, but I was too lazy to change the markup of my page to actually use the resolution.

If you remove the 2500 and 5000 values, you’ll notice that orEmpty is faster than nil-coalescing.

Weird!

Nil coalescing is faster, but only if the number of times the compiler has to do it is larger.

I haven’t been able to figure out why this is so far, but I’ll keep digging. If you know why, or have any theories, please let me know: @gopalkri!

Conclusion

This benchmark is highly synthetic. First, it only uses one source file (hopefully your apps are not all in one source file). Second, I highly doubt that most code bases are going to have more than a few hundred of these occurrences. At that volume, and at these absolute times (0.6 - 1 second) per 1,000 occurrences, I don’t think performance is a reason to use one or the other. The question goes back to one of style, and I’m not really sure which way to go. At this moment in time, I’d probably go with the nil coalescing operator.

Extensions On Optional String In Swift

Fri, 21 Jul 2017 22:17:11 +0530

Earlier today I was writing some code that looked like this:

if let foo = bar.foo {
    fooLabel.text = foo
} else {
    fooLabel.text = ""
}
if let baz = bar.baz {
    bazLabel.text = baz
} else {
    bazLabel.text = ""
}

I figured there had to be a cleaner way to express this. My initial thought process was to write an extension to String that does this. Very quickly though, I realized I need to extend Optional, not String.

So I came up with this:

extension Optional {
    public func or(other: Wrapped) -> Wrapped {
        if let ret = self {
            return ret
        } else {
            return other
        }
    }
}

This allows me to now write:

fooLabel.text = bar.foo.or(other: "")

Much better!

Then I thought, there’s a way to make this even better for Optional<String> specifically. So I came up with this:

extension Optional where Wrapped == String {
    public func orEmpty() -> String {
        return self.or(other: "")
    }
}

And voila! I can now write:

fooLabel.text = bar.foo.orEmpty()

Way better!

Removing Passwords From PDFs

Thu, 13 Jul 2017 18:29:46 +0530

I recently came across a pdf file that required a password to open. This isn’t a super uncommon thing, particularly when sensitive files are being sent over email. The problem with this though is if I want to save the file (to say iCloud Drive), and open it later, I’m never going to remember the password when I need to open the file.

There’s usually a pretty simple way to “remove“ the password from pdf files. Unfortunately, for some reason that way did not work on this file.

I went looking around for another way to do this, and came across qpdf. And… it worked!

I figured I’d share this in case it’s useful to anyone else, and so I can find it easily when I need it the next time.

qpdf can be installed with homebrew: brew install qpdf. Once it’s installed, here’s how you use it to remove the password from a pdf file (in this example, a.pdf):

qpdf --decrypt --password=<password> a.pdf a-nopasswd.pdf

Why I Dislike CoreData

Wed, 26 Apr 2017 08:37:01 +0530

On a recent episode of Fatal Error, the hosts talked about why they’d never use Core Data in a new project. I’m one of those people as well. I’d definitely recommend listening to the episode, but I also thought I’d jot down my reasons for never using Core Data if I have a choice in the matter.

Magic

If I had to summarize my problems with Core Data in one word, it’d be this: magic. Core Data does a whole bunch of stuff that for all intents and purposes is black magic. Most of the time you have no idea how anything works. For instance, if you read a property on a model object, you don’t actually know whether it’s in memory, or is being faulted in from disk. Figuring it out is an extremely daunting task (often impossible, since Core Data is not open source), and I don’t know too many people who can actually use Core Data well.

Garbage API

IMO, CoreData’s API is garbage. Here’re the top reasons why.

Model objects need to subclass NSManagedObject

Your model objects need to subclass NSManagedObject. This means no more value types for model objects. It also means your code is forever tied to Core Data (see point below about isolation).

Everything is mutable

All your model objects are mutable, and can change underneath you in several circumstances. This means you have to reason about concurrency every time you do something as silly as a property read.

Need to pass contexts around everywhere

You basically cannot do anything without a context, so you have to pass contexts around everywhere, effectively making them global. In fact, I recently saw an app which sticks a global context in AppDelegate, and references it from a whole bunch of places in the app. This effectively makes the app untestable.

Hard to isolate

Good design encourages separation of concerns. Your data layer should not be intricately tied into your presentation layer. Ideally, your data layer should be defined by a protocol, and your presentation layer should simply treat that protocol as a dependency. If implemented this way, I could swap out my data layer from one implementation (say JSON files written to disk), to another (say SQLite), and have no impact on my presentation layer.

With CoreData however, this is virtually impossible, without also losing all the benefits of using CoreData. Swapping CoreData out for another persistence mechanism would require you to effectively re-write most of your app from scratch.

Okay, but I don’t ever want to swap out CoreData for something else. Why should I care? Because separation of concerns is a good idea anyway. It makes testing your app a heck of a lot easier, for one.

Massive learning curve

One of the things I like about Swift, is the idea of progressive disclosure. The idea is that there is a small learning curve to do simple things. As you go along your journey, you will learn more, as you need to. You shouldn’t have to climb a mountain just to get started.

The problem with CoreData, is that you need to learn a ton of stuff to just get started with it. Sure, there are a lot of well written tutorials about it, but the fact is, you shouldn’t need them.

Not portable

This one is not relevant if you’re only on Apple platforms. However, if you are also on Android, using SQLite on both iOS and Android allows you to not have to re-think a whole bunch of stuff again.

What about Realm?

I haven’t used Realm for anything significant yet. Realm fixes two major problems with CoreData: it is open source ¹, and portable.

However, the reason I chose not to delve into Realm too deeply, is that it has several of the problems above as well. Magic, mutability, passing around contexts, etc. I’m also not sure how solid their business model is, so there’s also a risk of the project being abandoned if their company shuts down.

So what do I actually use?

Currently, GRDB. It is a fantastically designed thin, Swifty API around SQLite. It doesn’t try to do too much. It allows you to define model objects the way you want, have them be value types, and have them be immutable. It supports writing SQL just as well as it supports its own SQL generation wrappers.

It does progressive disclosure quite well, IMO. To start with, write your model objects as you usually would, conform to the requisite GRDB protocols, and you’re good to go. If you need to do more, start writing SQL. But, if you don’t understand what WAL is, that’s totally fine - you probably don’t need it. If you do though, it’s right there for you to use.

If you’re writing in Objective-C, FMDB is pretty great.

I’ve also heard good things about YapDatabase, but I haven’t used it myself. Their API seems to be pretty nice, though.

Further reading: a Hacker News comment from Mike Ash on the topic.

Get in touch on twitter @gopalkri if you have any thoughts, comments, feedback, or questions!

Which means that at least in theory, you can go figure out what it’s doing. ↩

Multi Line Strings In Kotlin

Thu, 20 Apr 2017 10:43:16 +0530

I’ve recently been writing a fair amount of Kotlin for one of our products. We’re using it both in the Android app, as well as in the backend server. Since both of these use cases involve writing SQL, I looked around to see if Kotlin supports multi line strings, so I could write my SQL inline, but also not have it be littered with + and \n everywhere. Turns out, Kotlin is pretty great for this use case!

Consider this example from our Android code base:

val cursor = db.rawQuery(
        """
        SELECT
            ${TN.PROJECTS}.${CN.PROJECT_ID},
            ${TN.PROJECTS}.${CN.NAME},
            ${TN.PROJECTS}.${CN.COLOR_CODE},
            ${TN.PROJECTS}.${CN.CHANGE_TOKEN},
            ${TN.PROJECTS}.${CN.DELETED}
        FROM ${TN.PROJECTS}, ${TN.TIMERS}
        WHERE
            ${TN.PROJECTS}.${CN.DELETED} = '0' AND
            ${TN.TIMERS}.${CN.DELETED} = '0' AND
            ${TN.PROJECTS}.${CN.PROJECT_ID} = ${TN.TIMERS}.${CN.PROJECT_ID} AND
            ${TN.TIMERS}.${CN.START_TIME} BETWEEN datetime('now', '-14 days') AND datetime('now', '1 second')
        GROUP BY ${TN.PROJECTS}.${CN.PROJECT_ID}
        ORDER BY ${TN.PROJECTS}.${CN.NAME}
        """,
        null
)

TN and CN are enums which represent table and column names.

Ideally, I’d like to avoid all the ${} crap, but using those ensures I don’t make a typo and have my query fail. Aside from that caveat, this SQL is pretty readable, as it is appropriately indented, and logically broken up into multiple lines.

Best of both worlds, really!

Unfortunately, there is one problem with this code. You’re likely writing something like this in a situation where the statement is already indented 2-3 levels. If that’s the case, the resulting string is going to be littered with unnecessary indents because the lines after the first one do not begin on the first character of the line. So if you’re debugging this code, and you want to log the exact query string, or copy paste it into an sqlite3 (or your SQL client of choice) to play around with it, it’s going to be ugly.

Fortunately, Kotlin has this handled as well. Enter trimIndent! Stick a call to this handy little standard library function at the end of your multi line literal, and it will handle the rest.

For example, without trimIndent, the above query would look like this:

                    SELECT
                        PROJECTS.PROJECT_ID,
                        PROJECTS.NAME,
                        PROJECTS.COLOR_CODE,
                        PROJECTS.CHANGE_TOKEN,
                        PROJECTS.DELETED
                    FROM PROJECTS, TIMERS
                    WHERE
                        PROJECTS.DELETED = '0' AND
                        TIMERS.DELETED = '0' AND
                        PROJECTS.PROJECT_ID = TIMERS.PROJECT_ID AND
                        TIMERS.START_TIME BETWEEN datetime('now', '-14 days') AND datetime('now', '1 second')
                    GROUP BY PROJECTS.PROJECT_ID
                    ORDER BY PROJECTS.NAME

With trimIndent, it looks like this:

SELECT
    PROJECTS.PROJECT_ID,
    PROJECTS.NAME,
    PROJECTS.COLOR_CODE,
    PROJECTS.CHANGE_TOKEN,
    PROJECTS.DELETED
FROM PROJECTS, TIMERS
WHERE
    PROJECTS.DELETED = '0' AND
    TIMERS.DELETED = '0' AND
    PROJECTS.PROJECT_ID = TIMERS.PROJECT_ID AND
    TIMERS.START_TIME BETWEEN datetime('now', '-14 days') AND datetime('now', '1 second')
GROUP BY PROJECTS.PROJECT_ID
ORDER BY PROJECTS.NAME

Much better! 👍

There’s also a slightly different variant of this function called trimMargin which may suit your needs better.

Get in touch on twitter @gopalkri if you have any thoughts, comments, feedback, or questions!

Apple Accelerator

Thu, 06 Apr 2017 12:30:02 +0530

Recently, Apple launched a App Accelerator in Bangalore. Phil Schiller tweeted about it:

App Accelerator Bengaluru - now open for iOS developers https://developer.apple.com/accelerator/

I signed up for a couple of sessions on the first day of sessions:

Designing Great Apps
Advanced Swift

The sessions were held at Apple’s offices in RMZ Galleria.

A couple of people on the Swift India Slack asked me to take notes during the sessions and share them since not everyone who wanted to attend could attend. I figured I’d start with the first session in this post: Designing Great Apps.

Designing Great Apps

This talk was given by the resident “design guy”, Karthick Gopal. The goal of this talk was to highlight what makes great apps (was also referred to as “next generation” apps).

To start off with, ask yourself this:

What does your app make your users feel?

It’s not just about what features it has, what it looks like etc. It’s about what it makes users feel.

Great apps are:

Inviting. This is done with judicious use of colors, contrast, etc.
Accessible. 1 in 7 Indians has a disability. We should cater for them in our design. Use technologies like Dynamic Type to do this.
Engaging
Intuitive
Specialized
Personal
State of the art

They also stand out, and provide clear value to their users.

3 Steps To Make Great Apps

Use state of the art technologies
- Use the latest and greatest frameworks and extension points provided by Apple. However, do not blindly just integrate everything - think about what makes sense for your apps.
Optimize your apps
- Think about which devices in the Apple ecosystem your app makes (iPhones, iPads,  watch, Macs) sense to be on.
- Think about how your apps will work on the specific devices your apps will be on.
- As you design your app for a device, also think about whether your app could work on other devices in the future, even if that is not your current focus.
Specialize your apps
- Use  frameworks.
- Particularly extension points.
- However, do so judiciously.

Examples

Karthick highlighted a few apps in his presentation for having great design.

Ixigo

Ixigo has a fantastic on boarding experience, making it inviting for new users. It uses delightful animations to draw you in.

Bear

Bear focuses on the task at hand: taking notes. Icons and actions are very subtle. They use colors really well. It’s also fun, and engaging. There first note you see when you open the app has a cute bear in it. It also looks similar on iPhone, iPad, and Mac, while still staying true to each platform.

Mr. Crab 2

Mr. Crab 2 is a fun game. Not crammed with all kinds of buttons and features. Optimized for each platform it is on.

Not On The High Street

This is a premium shopping app in the UK. It is highly visual. Focus is on the item, and it’s photos. They have high fidelity photos everywhere. Very little text.  TV app is video intensive, since video is most used on  TV. However, since people are not used to buying stuff on their TV, it uses handoff to allow the user to purchase an item being viewed on the  TV on their iPhone.

Night Sky 4

Night Sky 4 has fantastic user interaction. Super smooth, and performant. Does not distract you with information you don’t need until you ask for it.

Field Day

Field Day is a game designed specifically for  Watch. Designed for kids, so has a lot of cute animations, transitions, and graphics.

Summary

Karthick summarized with these points:

Have a great on boarding experience
Exhibit a clear and precise design language
Leverage key iOS technologies
Exist on the platforms where your users do
Surprise and delight users over time
Deliver clear value

Overall, I quite enjoyed the session, and learned a few things from it. Hopefully this is useful to the people who weren’t able to attend this time around. Feel free to hit me up on twitter @gopalkri if you have any thoughts, comments, feedback, or questions!

Migrating Repositories with Git LFS

Fri, 07 Oct 2016 14:54:52 +0530

I recently decided to try migrating a private repository from github.com to gitlab.com since GitLab seems to have shipped a lot of great features recently. GitLab has a feature that allows you to import repositories, including Issues from Github, so I decided to give it a try.

After GitLab was done importing, however, I was disappointed to find that it had not actually copied over several assets I had checked in with LFS. All the references to those assets were still pointing to Github.

After getting over my initial disappointment, and filing an issue, I figured hey, this is still git. I can do the LFS migration myself.

I set about googling for answers on how to migrate git repositories with LFS, but to my dismay, I did not find any information about this. There are loads of blog posts that refer to migrating assets from a vanilla git repository to LFS, but nothing about what I was trying to do.

So I started digging around in man pages, and eventually found git lfs fetch and git lfs push.

Turns out, you can use these commands to migrate lfs assets as well.

I’m assuming you have your original LFS enabled repository on github cloned (this remote is assumed to be origin). You’ve also imported it into GitLab with their importer, and added it as a remote (called gitlab).

Now, run:

git lfs fetch --all 
git lfs push gitlab --all

This can take a while (it will show progress), but once it’s done, you’re good to go!

Hopefully, if you use git LFS, this gives you some peace of mind that if the need arises, you will be able to migrate to another git host if you so choose without too much hassle 😀.