CHUCK:
Oh, Alondo’s back.
ALONDO:
Oh. Did I leave?
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco, New York and L.A. bid on iOS developers, providing them with salary and equity upfront. The average iOS developer gets an average of 5-15 introductory offers and an average salary offer of $130,000/year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It’s totally free for users, and when you're hired they also give you a $2,000 signing bonus as a thank you for using them. But if you use the iPhreaks link, you’ll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them on Hired and get a $1,337 bonus as thanks after the job. Go sign up at Hired.com/iphreaks]
[This episode is sponsored by DevMountain. DevMountain is a coding school with the best, world-class learning experience you can find. DevMountain is a 12-week full time development course. With only 25 spots available, each cohort fills quickly. As a student, you’ll be assigned an individual mentor to help answer questions when you get stuck and make sure you are getting most out of the class. Tuition includes 24-hour access to campus and free housing for our out-of-state applicants. In only 12 weeks, you’ll have your own app in the App store. Learn to code, it’s time! Go to devmountain.com/iphreaks. Listeners of Iphreaks will get a special $250 off when they use the coupon code IPHREAKS at checkout.]
CHUCK:
Hey everybody and welcome to episode 104 of the iPhreaks show. This week on our panel we have Alondo Brewington.
ALONDO:
Greetings from Goldsborough.
CHUCK:
I'm Charles Max Wood from Devchat.tv and this week we have a special guest and that's JP Simard. You want to introduce yourself really quickly?
JP:
Sure. Yeah. Well, my name's JP. Greetings from San Francisco, I guess, I should say. I work at Realm based here in San Francisco - database company. It is as nerdy as it gets. [chuckles]. And me, personally I worked on a Cocoa Team, do a lot of Swifts, a lot of Objective-C and I really try to blur the lines there and try to make it do things – sometimes it wasn't supposed to do but for the benefit of the user.
CHUCK:
Very cool. Realm – it's funny because I heard the name and I was like “Are we talking to another game developer?” [chuckles] – but it's not. You want to give us a brief overview of what Realm is?
What's it about?
JP:
Sure. I don’t mean to [inaudible] on the name. It's so better than the name we had just about a year ago before we launched – TightDB.
CHUCK:
Oh, yeah.
JP:
That was an improvement, let’s just say.
CHUCK:
I had about three jokes come into my head, I’ll refrain. [chuckles] Clean rating and all of that.
JP:
Well, before I actually say what the company is about – what Realm is – a bit of back story about the founders. They're all from Denmark. They came out of Nokia. Actually, their English is flawless really. I learned words from them pretty often but nonetheless, they didn't necessarily catch on to necessarily how the name could be perceived. Just about this time last year, we're big and pushing a new name. Now we're called Realm. Sounds like a game company but databases. Why not?
And since you asked, Realm is a database for mobile platforms. We have bindings for Objective-C, Swift and Java for Android.
ALONDO:
Gotcha.
JP:
In a nutshell what it is – it's basically a Core Data replacement but it doesn't use SQLite under the hood. It's a brand new database engine that was built along our development and it's basically bringing the modern features of databases from the last 15 years – from ServiceI databases back to mobile.
ALONDO:
Gotcha. So it's local to the device. It's not another [crosstalk]
JP:
It certainly is. Yeah. It's an embedded database.
ALONDO:
There you go. Okay.
JP:
You can think of it like SQLite, like Core Data except that it's a little bit more optimized for mobile, we tend to think.
ALONDO:
In what ways would you say that – like something that we could see as an advantage over SQLite or Core Data implementation particular to mobile as an advantage?
JP:
Right. For one, you've said performance. SQLite was never necessarily developed or even designed to run on smart phones. It was designed in the early 2000s and it was designed to run on military [chuckles] aircraft carriers of all things.
That being said, it's an incredibly well-written piece of software. Amazing apps and amazing imbedded software’s been written using it. But ultimately, it was never necessarily designed for iOS apps or Android apps. That's fundamentally a very new concept when it comes to that.
When you look at the way it was designed, it never really mapped to the way that people tend to use it in apps where it's really kind of this graph-like data model and that's where Core Data comes in and these other ORMs where they'll map an Object Graph to this more tabular relational database style.
What Realm brings in to the table is cutting out that indirection – that mapping. It represents object graphs directly in the database. In that sense, the Cocoa bindings and the Swift bindings, Android bindings, they're really just thin wrappers rather than ORMs. Really all of this functionality when it comes to maintaining the object graphs, inverse relationships, traversal of links, that's all really done in the core database engine.
That's a fundamental difference but ultimately, as a user, you might not necessarily see the difference other than you're a lot closer to the metal and so you can get very similar performance as you would with say raw SQLite or even faster but with the functionality that you'd get out of something like Core Data.
ALONDO:
How long has this been around? How long has this been under development or actually on the wild?
JP:
Well, building a database is not something that you reach in MVP in a few months unfortunately. This is actually been in development for just about four years now. The first three years of that was Stealth basically working on a Core database engine. I joined just about last year when we really started putting an effort on focusing on bindings. That's kind of where I fit in working on the cocoa side of things.
CHUCK:
I guess what I'm wondering is – first off, if I want to add this to an application and start using it, what are the best steps or first steps to just getting it in so that I can start playing with it?
JP:
Yeah, well. There's a handful of ways. These days with the proliferation of the dependency managers for Cocoa, there's no shortage of ways to install this but it's essentially a framework. Now that iOS8 and Mac has had these forever but essentially dynamic frameworks, you basically can just drag in this .framework into your Xcode project and fire away. Then from there it's linked and you start using it just like say you were linking any other system framework. Of course, we support CocoaPods and Carthage and you can install static framework if you're using iOS7.
There's a handful of ways but it's essentially a framework or module if you're using it from Swift.
ALONDO:
Gotcha. Is this something that you can use in like a Swift sandbox?
JP:
Yeah. It's totally sandbox. What Realm will do is it'll – you can use what's called – what we call the DefaultRealm. It really cuts away a lot of the boilerplate. If you ever use Core Data, you're familiar with the concept of an NSPersistentStore and plot coordinator and all that and there's actually quite a bit of boilerplate just to setup a file that you can write to. By using the DefaultRealm, it's basically a shortcut that’ll just pick a location in the sandbox - in the iOS that would be in Documents directory. On OSX, that would be in the Applications port directory of your app. It'll just create a file called “default.realm” and then it'll store everything in there. It works entirely in a sandbox way – both from a file access standpoint and from all the APIs that we use.
ALONDO:
That makes sense. And then, how does the – I've just been browsing through the documentation and stuff –but how does the API actually compare to Core Data or SQLite or both?
JP:
It's actually quite similar in terms of using this concept of object accessors to represent underlying database information. What Core Data and Realm both do is that you'll be able to create, say, an Objective-C class. Core Data does this through code generation where you'll define your model and geographical editor in Xcode and then you have a code generation step that gives you Objective-C classes – MyModel class or something like that. In Core Data, it'll inherit from NSManagedObject.
In Realm, you basically skip this code generation step and you just write your class as if it was just an in-memory regular NSObject. You just inherit it from RLMObject. Once you have these classes, you define you're schema just by setting properties. Say we wanted to model a person, you'd have @InterfacePerson that inherits from RLMObject and then you can add an@PropertyNSString for a person's name, NSInteger for that person's age. From there you can also have – say you have children for this person or friends. You can have this concept of relationships just like you would with regular NSObjects so you do @PropertyPerson is the type of the property. And then you'd have spouse or child or parent or whatever.
Then you’re going to have the same concept with typed collections – so one-to-many collections or many-to-many where we have this concept of an RLMArray so you basically specify that you want a property of children and that's @PropertyRLMArray of children.
That's basically how you define your schema in Realm. Then from there, when you're actually using the objects, you can instantiate this regular Objective-C object and then you have this basically view of the underlying database data. You set a property and it'll set the database value. You read a property; it'll read the value from the databases, etcetera. You bypass loading everything into iVars altogether.
ALONDO:
Is there reverse relationship that you get with Core Data? Is that present in Realm as well so that [crosstalk]
JP:
Yeah. The nice thing with relationships in Realm is that they're represented natively in the database file and the database engine. Whereas in SQLite, say, if you're building any sort of ORM that's built on top of that; because it's an entirely relational database, you basically have to create foreign keys for any relationship that you would want and then you'd have to a join operation in SQLite on this tables in order to get what matches up.
Thankfully in Realm, it's really just a pointer that you follow. The internal representation of this data is essentially this giant B-tree where you can really just follow links so there's no difference between, say, an integer column and a link column. When it comes to backlinks, because it's this basically giant tree and this graph in a sense of your objects, then to do a backlink is really just doing that link in the inverse direction. It's really quite efficient.
ALONDO:
Let's say, I’ve got an existing app with a ton of domain objects, would I, in practice here, simply replace the inheritance directly from NSObject with RLMObject or is there a better practice or another practice – I shouldn’t say better – but another practice I should use if I was to implement Realm from an existing application?
JP:
No. That's exactly the main design and the main use case that we designed for was really to bring this concept of persistence, add it to the equation and bring working with a database in this data model framework to be as close as possible to what people are already familiar with in terms of inmemory NSObjects – plain old NSObjects. That’s definitely a good approach to take because ultimately, things will mostly work – in terms of defining your data model anyway – just inheriting from RLMObject instead of NSObject.
There's a handful of properties that we don't actually support and say that you had properties in your Objective-C objects before migrating to Realm that had a NSURL property or any sort of nondata model-like property that you had on your object, then you would either have to compose that into another RLMObjectand then you can create a relationship on it which is what a lot of people do. Then you can create a computed property, say like a read-only property, or override the setter/getter for this kind of property so that you can write and read the composed type. I'm probably not explaining that very clearly. Do you understand what I'm saying?
ALONDO:
I do, actually.
JP:
Okay.
ALONDO:
Yeah, I have a particular object case that I’m thinking of while you’re describing this.
JP:
Right. Let's say you had a rather – data model, it was all in memory, you’re not using any thirdparty framework or Core Data or whatever, just using an NSObject-based models and you had an object, say website, that had an NSURL property. Say you wanted to persist that in Realm, what you could do is still keep that URL property but mark it as ignored in Realm which you can do through overriding this class method to tell Realm to ignore that property. Instead, you create something like backing URL which would actually point to, say, an NSString where anytime you read from your actual URL property, you would construct an NSURL from the string. Then every time you write to the URL property, you would take that string out of the URL and store it in the backing URL string. So that's one way to do things.
Ultimately, this is a pretty flexible approach which really sense to being able to store – basically if you can compose any type – then in terms of the data types that Realm supports – then you can basically have those types in your model as well. It really just brings concept of computed properties. That's, for example, really useful for Swift where say you want to use Swift enums that don't really have – ideally you would have an associated type and so what you could do is have this computed property that when you set the enum property, it will assess this backing enum that just grabs the string from it or the int from it and stores that in Realm. You can do the same thing the other way around when you're reading from an object.
It’s a pretty flexible way I think. We've debated – the team – so many times, in terms of adding more explicit support, more native support for certain types like NSURLs. Ultimately, there's a tiny bit of boilerplate that allows anyone to create – to basically add support for their own types that it's never really been a major consideration for us.
CHUCK:
So, I want to change directions a little bit.
JP:
Yeah, please do.
CHUCK:
First of all, it looks like you have realm-cocoa and realm-java, so do you maintain two versions of the same database?
JP:
Well, there are two bindings on top of our cross-platform core.
CHUCK:
Okay.
JP:
The core is really the heart of the database engine. It's written in C++. It's very portable. It's especially optimized for arm devices and especially imbedded platforms but it still runs pretty performantly on things like Intel chips, Macbooks and things like that. Realm-cocoa and realm-java – they're really just bringing the idiomatic language components in mapping those to the core database engines. For example, in cocoa,it’s what wraps the Objective-C runtime and this concept of Objective-C objects to how those are stored in the underlying database file but ultimately; it's a pretty close one-to-one mapping.
CHUCK:
The other question I have.
JP:
The cocoa binding does other things like add support for parsing NSPredicates and things like that.
CHUCK:
Okay.
JP:
It's just makes it a lot easier to work with from the language standpoint but, I would say, that it really doesn't do any of the heavy lifting.
CHUCK:
The other question I have is – I clicked on pricing because I always wonder with these kinds of things where it's a company that is backed by funding or whatever – basically, Realm has people working for them to build Realm so it's, “Okay, well. How are they going to sustain this? How do I know it's going to be around for a while?” It looks like you offer additional enterprise products, services, etcetera. What kinds of things fall under that Realm so to speak?
JP:
[Chuckles] Nice pun. Ever since, we actually had minimum wild product even just for the database core not even for these bindings that we built on top and then we’ve send to open source. Ever since the core was pretty stable, we've had clients, basically enterprise clients – enterprise is kind of a strange word – they're more like bigger clients that wanted access to that source directly or they wanted a special level of support. We try to answer all of the support calls – not calls; we don't have a phone line set up or anything like that – we try to support all the support tickets even for the free and open-source stuff as soon as we possibly can and usually that's within a few hours.
Ultimately, some companies, especially in the earlier days of Realm, wanted a more direct line. We had some special arrangements with those companies. Ultimately, they don't end up getting a different product at all from what we offer in the open-source variety. It's really just a way for us to keep the lights on.
CHUCK:
Yup. That makes sense.
JP:
One thing I will say is we're still, at this point, – I think we're 24 people across the world now working on Realm. We've got people working on the core database engine, Java, Objective-C and some other stuff that we hadn't quite announced yet. It's still a company almost entirely made up of developers. Something that's super important to us is this concept of open-source and keeping the bindings completely open and taking in poll request and developing this in the open as well. Anytime we have a design discussion, we put it up on github or it'll be on our blog or something like that. That'll remain extremely important to us for the foreseeable future.
That's why it's super important for us to have a business model that can sustain us in a long term without sacrificing the overall product or even the users of the free and open-source product.
ALONDO:
[inaudible] ask a question that I was actually going so that we can get us back to some of the technical aspects of Realm. The first thing I thought about was one of the pains that I've had if you're doing something other than the most basic of changes in Core Data and that's migrating, updating the data model because it tends to change over time. How difficult is that with Realm?
JP:
All of us working on the cocoa side of Realm anyway come from an app-making background. Some of us worked at agencies – companies like Tumblr and all sorts of places. We're all pretty familiar with Core Data and that's what we look for in people joining the team, too. It’s just some level of familiarity with the existing tools out there.
Yeah, we're acutely aware of the pains that are associated with Core Data migrations. And so when we're designing the migration API, we thought about this a lot and we ended up comparing all sorts of different model frameworks even across different platforms and different languages and what they tend to do.
Ultimately, I think we ended up settling on this sweet-spot solution that still gives you some of the power and almost ease-of-use for simple Core Data migrations where you have this concept of automatic migrations. The problem with Core Data migrations is when you start to do something and anything remotely more complex than, say, just adding a new property and you don't want any data in there. That's really when you start to manipulate data as part of migrations which is really the predominate-use case. That's where solutions like Core Data is really start to be pretty heavy actually where you have to create this special – what is it called – NSManaged. I forgot what it's called but basically you have to subclass this migration worker in Core Data.
Anyway, it's starts to be pretty hairy. We were looking at that – another source of inspiration for us was the way that FCModel does its migrations. I don't know if you've seen this, it's a model framework by Marco Arment of Instapaper and Overcast fame. The way that he ends up doing migrations in there was really quite nice but it really had no support for this concept of automatic migrations. What we've ended up doing is something that's in between with a few inspirations from a little bit elsewhere as well.
The concept is basically that before you open a Realm – when it needs to be migrated – say, you've made some model schema changes. Then what you'd have to do is just update the schema version of your Realm file. That's a must. Then, from there, you can enumerate over all of the data that's in your Realm and then, from there, you can access the contents of your RLMObjects through keyed subscripting.
It's an interface that's really similar to NSDictionary. Because you're basically dealing with information in models that maybe outdated, classes and properties might not exist at runtime where the user would pass. That's why we have this flexible stringly-typed keyed subscripting approach where you can say “New object and then you subscript something like full name property equals the concatenation of old object subscripted on first name plus old object keyed subscripted on last name”. You can do this data manipulation in a type-unsafe manner which is pretty different from the rest of Realm but it's necessary if you don't want to have to preserve all of the different states of your model schema throughout the entire history of your app. Which is really what tends to bite people with Core Data is that you have to basically freeze your model schema and all the previous versions and preserve all those previous versions and even ship them with your app.
We thought that was a little bit redundant given that the database file already has all this data about what the data model used to be. In that sense, we take away some of that work away from the developer who, let's be honest, can make mistakes andback towards the database file which already has the relevant information. Probably, the best way to understand it is really just take a look at our docs, realm.io/docs/cocoa. That should give you an idea of what the migration API looks like.
ALONDO:
So, had there been any having explanation migrating from Core Data to Realm?
JP:
Yeah, we have and to be honest, that's a little tricky at this point. What's easy is doing the code we factor. We've had – some of our users even some of the bigger users with hundreds of thousands of end users or install base on their app managed to do the conversion, I should say, in an evening. We really do strive to keep Realm's API simple and straight forward as possible. I think, in practice, most people that I've seen transfer over have had a pretty easy time. Where it starts to really get complicated is when you have a data files on your end users' devices that need to be migrated. What's tricky about that is that if there's no way around it, you basically have to maintain for certain amount of time, anyway, all of your old Core Data code, all of your old Core Data schemas and models and NSManagedObjects, subclasses and all that because it’s the only way that you can get data out of a Core Data SQLite file and then put it back into a Realm file, say, because they are incompatible formats. Realm has its own file format.
That's where it really gets tricky and we've had lots of users do this but it is essentially a manual process that you basically have to do that mapping yourself because there really is no straightforward way where Realm could just pick up on all the information stored in a SQLite file and that you wouldn’t have to link Core Data to be able to get the information out.
It’s something that we're considering writing a little helper tool for where you can basically add this library to your app that would basically just be a thin Core Data reader that would be able to get this information out of Core Data file and then into a Realm file. But the problem with that really is none of this is publicly documented. Core Data's internal representation of the SQLite file format – at least the way that it uses it – is completely undocumented. It's pretty easy to figure out but the thing is that could break at any time. Apple can change that at any minute. To basically provide users with this thin reverse-engineered Core Data reader that they’d be shipping in their production app seems a little dangerous. Therefore, we just recommend thatpeople would go to manual rep.
ALONDO:
Is there a good guide for that though that says “You probably going to want to look at these things. You probably going to want to hook up Core Data this way and here are some of the gotchas that people run into and that's why we don't have an automated process is because these are the concerns that may or may not apply”?
JP:
Yeah, that's right. Well, actually, the best resource is there. We have a handful of user interviews at realm.io/users. There is a handful in there that explain the transition that they went through going from Core Data to Realm. There are probably some tips that listeners who are interested in doing the switch or at least trying it out you can read up on.
ALONDO:
Gotcha. I have a question about transactions being able to, say for instance, I have an app or I have a user go through maybe two or three screens as a part of a [crosstalk]
JP:
Like on-boarding process?
ALONDO:
Exactly. Yes. I'm saving informationas I go but at the very end if they cancel it, I need to basicallyunwind all of that. How easy is that to implement using Realm?
JP:
It depends on how you want to do it. There's a dozen ways that you can potentially implement that. Each of them has different drawbacks. Ultimately, what you could do – here's kind of a little side. RLMObjects can be instantiated and initialized as just a regular NSObject. You can basically have this person property that were talking about or say it’s a user for this on-boarding example. You call UserAllocInit and you basically just have an equivalent object as if you're inheriting from NSObject.
What you could do in this on-boarding process is basically just pass this in-memory object that's not tied to a Realm at all –it's not persisted, it's not even tied to an in-memory Realm, it's just a plain old NSObject– you can pass that around throughout the process and then set whatever properties that you need or do whatever data manipulation that you want. Then if, say, the user cancels at the end of the process, then you just throw away this in-memory object because you didn't really do anything Realm related, all you did was reuse the same data model that you've already defined for your database.
Now, if the user says “Yes, finish, save” whatever, then you can just call RLMRealm –RLMRealm is the class for Realm – you can just do RealmAddObject and you pass in this in-memory object and it’ll persist it. That's probably the easiest and most straightforward way that I would recommend that you do it.
The only reason that I can think of that you might want to persist along the way is if say, you wanted – say, for whatever reason, the user force quit your app like halfway through the onboarding process and when you launch the app again, you wanted to start off from where they left off. Then you might want to persist it at every step of the way but you might not actually want it to be beneficial to user until they’ve actually press the Save button at the very end of the process. At which point, to be honest – at that point, you can necessarily roll back those transactions because they could have happened like weeks ago essentially. What I probably do there is basically just set is Saved property – like a boolean property on the object that you would just flip to Yes once the user actually press the save. It really depends on the use case but there's a handful of ways you could do it.
ALONDO:
Okay. In going along those lines making these changes, writes or deletes from the database. For cascaded deletes, if I have an object that has children objects and I delete that object, is that something that is automatically done for me or get the cascading deletes? Do I have any control for that at all?
JP:
Unfortunately not. That's actually a pretty drawback right now over, say, Core Data where it would take care of those cascading deletes for you. We're working on a design that would essentially provide this kind of ownership semantics. So you could have properties having strong or weak relationships to their relationships – the strong or weak ownership over the relationships. In that sense, if you had a weak relationship, deleting a parent object wouldn’t actually cause the children objects to be deleted. But if you had a strong relationship, then if you were the last object linking to a child object, then deleting the parent object would actually delete the child.
We thought this through and I think we have a decent design in place but it's not something that we’ve shipped; it's not something that we’ve fully implemented just yet. This is actually one of those things that's very tricky to have to do on your own because you basically want to know how many objects are linking to the entirety of your object graph. For an end user to build this functionality on top of Realm would be pretty tricky. We have this information in the core database engine already; it's just that, we haven't fully implemented this cascading delete logic just yet. But we have people working on it.
CHUCK:
I'm wondering are there use cases that – it sounds like this is more or less a complete stand-in for Core Data or at least that's the idea – are there instances that you would want to use Realm as kind of just solid examples one way or the other?
JP:
A big one there is sync. Core Data through iCloud depending on your thoughts on that [chuckles] just offer a synchronization method or mechanism I should say whereas Realm doesn't have any concept for sync just yet. That's something that we're working pretty heavily on actually. Thankfully, the way that we designed the database engine – I think when we do actually have sync, I think it's going to be quite nice. It won't necessarily be patched on top of a database, on top of an ORM. It'll actually be core to the way that Realm works but ultimately we don't have that today. If sync is a big requirement for you, then Realm will definitely be a harder sell because you'd have to build that in yourself.
That being said, if you want to use things like RestKit or if you want to build your own syncing on top of Realm, you're more than welcome to. For a lot of cases, that's what people have done when they have custom SQLite stores. They'll just build a sync solution that's specific to their business needs. That's one limitation where you'd want to look at other options other than Realm.
Another big thing – and that thankfully is pretty close to landing in terms of functionality but currently we don't have any sort of way to know – when a notification triggers that a change happened in the database – we don't currently have a mechanism to inspect that notification to see what has changed. There's no equivalent concept to say NSFetchResults controller in Core Data where you'd be able to say which items were moved, removed, added, updated. Right now, our users who are doing this kind of functionality are doing this manual diff between the old version and the new version. Thankfully that's something we're working pretty hard on and we have a work in progress KVO branch the equivalent to NSFetchResults controller that should be landing pretty soon but it's not in there now.
Finally, since I'm on a roll here in terms of talking about the drawbacks of Realm. There's another big one and that's No Values aren’t supported – basically optional properties. Say, I had a model; all of the properties on that model have to be set to something even if it’s an empty string or just zero. It has to be set to a value. We're in the process of adding this no support for types on a piece-meal basis but it was a pretty core design decision originally when the database engine was first built. Now, we’re going back and changing a lot of these assumptions to allow this concept of null to be supported.I'd say those three are really the biggest drawback currently.
CHUCK:
When you're talking about syncing, I don't know why – whenever somebody says syncing, I was thinking of this video on YouTube. I'll put a link in the show notes just because it's pretty funny. But, yeah, that makes a lot of sense. I am wondering with some of these features; do you foresee having those features in in the next few months or year? Or are you just not ready to make any kind of commitment that way?
JP:
Well, I can tell you that they're super highly prioritized but in terms of giving you an absolute timeline on that, it's not something that we like to do. I'll be perfectly honest with you; it's not even something we like to do internally. It's not like we're necessarily keeping schedule very close to the chest or anything like that. It's more that we prefer to be flexible and often times other things will come up.
For example, there was a very strong community interest in us adding native encryption to Realm. Even though on iOS, you can use NSFileProtection which will encrypt your files in a pretty robust way. That wasn't available on– there's no equivalent on OSX or on Android and so we ended up building that in. But that wasn't necessarily a feature that we thought we would be prioritizing just a few months before that. Other things happen like sometimes – Swift happens and so we divert some cycles and we're going to Swift API.
It's more that we don't want to disappoint anyone but currently the three major drawbacks that I just mentioned are really the three highest prioritized – highest priorities for us internally. I – we don't really want to commit to any time frame.
CHUCK:
I just know that [crosstalk]
JP:
You end up rushing functionality and that's certainly not something that you want out of a database.
CHUCK:
Yeah. I talked to some companies and they tend to have an announced timeline or something like that. That's something that I was driving at. But yeah, that makes sense.
JP:
I can say that a lot of these features we want to have the next year for sure – in the next 12 months. If you look at the changelog on github, you'll see that we've actually been – I don’t know, I would think that we've been pretty prolific in terms of adding new features and fixing bugs and do things like that. I see no reason for that to slow down especially given that our cocoa team has grown about four times over in the last six months alone.
ALONDO:
A quick question is, as for someone getting started and getting some assistance and see your documentation [inaudible], is there a forum where users of Realm can discuss issues? Share?
JP:
Yeah. There's a few ways: One is the google group. We do have a mailing list where users can talk to each other. They can ask questions to the general community. Sometime we answer. Sometimes a member of the community answers. That's really a great place. So if you have just general questions about usage, you're actually – it's better suited for in depth conversations about why something is designed in a certain way or whatever.
Then, there's Stack Overflow. There's just so much that happens over Stack Overflow. People just say “How can I do this in Realm?” and most of the time it's really just their questions that relate to “How do I restructure this inNSPredicate?” But it's still something we actively monitor and we support.
Another place where people tend to chat or at least tend to communicate with us is viagithub. So people have an idea for a feature or they have either poll request for something implemented or they found a bug, github is really a pretty good media for communicating that.
And you can always email us. Sometimes we have people who want to email us private files or their private projects in which case you can do that in complete privacy at help@realm.io. In that way, it's not something that you share publicly. You're just sharing it with us.
ALONDO:
Nice, very cool. I did have one other question. I was curious about the SQL queries. Is it closely mimicking just basic SQL or is there a special subset function that we need to know?
JP:
Yeah, there is. From the cocoa APIs, the only way to query or to do any statements like that is through NSPredicate. We actually don't have any SQL statement parser or anything like that. All of these concepts don't even apply. Just because of the architecture of Realm, a lot to the SQL statements that are in the specs just wouldn't apply – things like limit on a SQL statement. Because everything is lazily loaded and you basically just have this view of this data, limiting wouldn’t actually have any effect.
That, in this concept of foreign and primary key is unnecessary with native relationships. For a bunch of reasons, those included, we really opted to expose our own query interface and so the core database engine had this type-safe, all-method-based, function-based query interface but as a cocoa user, as a user of the realm-cocoa binding or even the realm-swift binding, you're never going to see those. You're just going to deal with NSPredicate and you’re familiar with that.
ALONDO:
Okay.
CHUCK:
I guess the last question is: If people want to know about Realm or if somebody is totally sold on it like “I'm never using Core Data again!”, where do they go?
JP:
They can reach us on Twitter at @realm or any of the other mechanisms that I mentioned. If they have questions Stack Overflow. If the found an issue or they want to file a PR, then github is a great place for that. Then, they can always reach us privately help@realm.io. But I'd also say, if you're not sold on Realm and there are things that you find that it's lacking – since Realm is in beta which I probably should have mentioned earlier on, Realms.091.5 is our version number – since we're in beta, this is really the best time to shape the product. We really hope that Realm can help usher in a new era of data modeling and even databases in mobile. So if you have any thoughts in terms of things we can improve or if there are parts that you don't like and that you'd like to work on more actively, please you reach out for that too because this is a very feedback critical stage that we're at.
CHUCK:
I did have one other question and I can't believe neither of us asked is because we've talked about testing a bit. But when I'm testing my code, does it more or less like I'm testing code that accesses Core Data?
JP:
Right. Yeah. Well, that's actually a big concern of people who are familiar with testing Core Datarelated things where you have to setup a scratch context or maybe in some sense a different context. With Realmthere are a number of things that make that way easier.
For one, you can essentially use yourRLMObjects and your model objects just as regular objects. And so if you just want to test basically the business logic of your app – you're not necessarily testing the persistence aspects of it – then you can really just instantiate those objects as if they were regular NSObjects. That really just simplify a lot of the testing around it because you basically take away this other concern that you're hoping, anyway, that Realm takes care of.
Then, there are certainly parts where you do want to test that things are being persisted properly and you want to test it exactly as your app will go through it as well, in which case, you can always inject an RLMRealm instance which is this class that we use to represent to database access essentially. So if you shape your code in such a way where you can inject which database that it's using – which Realm it's using – then that makes things much easier to test as well where you're not relying on any database persistence state that happened in your app because you can basically inject that from your test. That also simplifies other traditional concerns that you'd probably have if you're dealing with asynchronous potentially expensive operations like writing to the disk where you can actually inject in the in-memory Realm and have your test run significantly faster with the knowledge that it's still going through the same code path.
CHUCK:
Alright. I don't think I have any other questions.
ALONDO:
I do. No I haven't.
CHUCK:
Alright. Well let's go ahead and get to the picks then. Alondo, do you want to go first?
ALONDO:
Sure. I actually only have one pick and I'm going to take a page from you, Charles, from something you did a few weeks back. I'm going to recommend a thing that people do. I'm a big fan of coworking. I try to go to as many co-working spaces as I can. I think it's a better environment that just working out of a coffee shop. I do that as well but I like supporting co-working communities. I think its a great thing. It's a great place to just feed on creative energy and also work with other people as well. So along that line, there is one site you can use to locate co-working spaces near you. That's desksurfing.net and it's pretty. I believe it's pretty up-to-date. I've been looking at it, using it to try to locate places when I'm traveling. That is my one pick this week.
CHUCK:
Very nice. I'm going to make a couple of picks this week. I just finished the book – and I'm sure a lot of people have heard of this one – How to Win Friends & Influence People by Dale Carnegie. I really enjoyed it. I need to go back and go through it again but it was pretty awesome.
I'm also going to pick WorkFlowy. That's in workflowy.com. I've been playing with it. I've tried a whole bunch of other ToDo apps. Some worked better than others but, anyway, I'm trying this one out just see how it goes. Basically what you get is a free-form outline and then you can mark stuff that's completed or whatever. It also has tagging and stuff like that. It's kind of a minimalist textbased ToDo list that syncs to all my devices and so I'm really enjoying that.
And then, I also want to pick a couple of books. I've been out for the last couple of weeks because I've been in conferences and when I travel I listen to books on Audible. Two really short books that I listened to that are influencing the way that I'm using WorkFlowy are Mini Habits and Habit Stacking. So If you're going to read those two books, they're both different approaches. They're kind of orthogonal to each other so you can use them both at the same time then you can use them together.
this:
that there's less resistance to doing something small than to doing something large. What it is is it's a hack to getting bigger stuff done. You pick a small habit like do one push up today and so you think about doing a push up and it's like “Shh. That's easy. I can totally do one push up.” If you do just one push up, you reached your goal, you get pat on the back, you get all the good feelings from reaching a goal but a lot of times, you're down there, you do one push up and you're like “Hey, I'm already in push up position. Why don't I do a few more?” So then you can wind up doing five or ten or 20. But the idea of doing 20 pushups or a hundred push ups in my mind, that brings up this resistance because it's going to take some time and it's hard. But doing one push up is “Oh, okay. I'm under no obligation to do more than one. I can just get down and do one.”
And then, Habit Stacking is more about building a routine. Now, the idea is that you probably have several things you want to be better at. So, rather than starting the habit of brushing your teeth every morning or something like that, you can setup a routine. Then you get in the habit of doing your routine everyday. That's just one habit, right, that you could work through. Or you can have one in the morning or one in the evening or one during lunch or whatever but then you put these other things to your routine. Then you just get into the habit of starting your routine and then you just work your way through.
JP:
That's actually a pretty great idea.
CHUCK:
Yeah.
JP:
Have you found that it helps you be more vigilant and responsible I guess?
CHUCK:
Yeah. I'm only been really doing this for a week because I just got back from RailsConf last week and I listened to these books when I was in Las Vegas for MicroConf which was two weeks ago. So far, yes. I just get up and start going. The only things I really worry about is that I'm trying to do a morning routine and that routine runs at the same time that my kids are getting ready for school and things. Sometimes it easy to get derailed but then I just make sure I get back to it.
this:
that the last thing in my routine is sit down to do something for client or sit down and record a video depending on the day. So, by sitting down and making that the last thing in my workflow, it's easier to just flow right into work. So I don't sit down and hit the resistance that I hit when I'm thinking about “Oh, crap. I've got this major feature I've got to add to my client project.” It's, “Okay, I'm just going to sit down and flow right into that.”
A lot of times I actually throw a mini habit at the end. For example, I need to record videos because I had a Kick Starter campaign fund for Ruby on Rails videos. So, that's just sit down and do ten minutes of research. No big deal. Then, by the time I'm done, I've got another video planned out because I spent more than ten minutes. But that gets me into my day.
There are a lot of different ways to piece these things together and make them work and it's really cool stuff. Since I'm so terrible about “Oh, that's a big thing.I'm going to put it off, put it off, put if off.”, if I can turn it into a mini habit, then it's just “Okay. I'm going to do this small little thing everyday.” So then I can just start. Then, if that's all I have – the energy for it – then that's all I do, then I don't feel bad because I didn't fail. But if I have more energy, then I go after that. Anyway, I've talked a lot about this but yeah. [Chuckles]
JP:
Those sound like some pretty great life hacks. Do you find that the actual mechanism is actually making a big difference there rather than just – or is it just a matter of – because you're thinking about it, then you will actually end up doing a lot more? Almost like the exact format of say of this habit stacking or this micro Habits is just getting you to think about the things you have to do more and so you end up doing them?
CHUCK:
No. For me, if I think about it more all the things I have to do, I get overwhelmed.
JP:
Right.
CHUCK:
It really is a hack. It's a mental hack that gets me to do this stuff. So, if I'm thinking “Okay, all I have to do is one pushup. No pressure. I don't have to go to the gym. I don't have to go lift weights. I just have to do one pushup.” Then I do it. Then if I think about “Well, I'd like to do ten but I only have to do one.”, then I set myself up to fail because I may not do ten. So it really is “Look. All I have to do is reach my goal.” That's it. It's idiotically simple, it's small but that's what I have to do.
The same thing with the habit stacking is that, again, it's just “I just need to get up and brush my teeth.” Then after I get up and brush my teeth, then I have a drink of water. Then I go find something to eat. But the thing is all I have to do is get up and start the routine and then I just know “Okay. Whatever I have next in list is the next thing I'm doing.” Mostly the get up and brush my teeth stuff, brush your teeth, have a drink, all that stuff is just – they're things that help me wake up so that then I can go to the gym. So my routine in the morning is get up, brush your teeth, have a drink, find something to eat, go to the gym. All I have to do on that one – because that's another mini habit hack – is all I have to do is drive there. Then I could just drive straight home if I want but I never do. If I drive all the way down there I'm going to go in. But yeah, all I have to do is drive down there but under no obligation to go on the door at all. Then when I get home from that and I have some family things going on and then I start another routine after that. Yeah. It's just basic stuff.
JP:
Yeah. You're really stacking those routines. You don't want that to overflow.
CHUCK:
Yeah. So the first routine is – he say to keep them to about a half hour. – that first routine takes about 15 minutes, maybe 20 minutes to get all the way to the gym. Then, the next series – it takes a little bit longer because it's more reading for personal development, reading for spiritual development and all that stuff. Anyway, do you have some picks for us JP?
JP:
Yeah, I do actually. I took a minute to just think about them as both of you we're talking about yours, Alondo and Chuck. The first pick that I want to talk about is this service called Waffle. It's a funny name but it's actually a great product – Waffle.io. It's essentially a kanban board for your github issues and poll requests. It's something that we use in our company quite extensively and it's a great way – if you do any open-source work or any work on github, really, you can basically link up your repository with Waffle. Then from there, you can basically use whichever columns that you like. That's the nice flexibility about it but I find that it really gives you a nice overview of what you have categorized and under which labels and what you should work on next. So it's something that we use at Realm but I use that for my personal open-source projects too. Otherwise, just to see githubs massive monolithic list of everything that's in there – like you mentioned Chuck, it just gets overwhelming. So, just like knowing all the habits that you have to do or all the push ups you have to do, you can get overwhelmed. I'd really recommend it if you do any work on github.
ALONDO:
I'll just jump in on that real quick. I use a system called KanbanFlow. It doesn't connect to github issues but I've used it for making my list of things to do during the day and it has a Pomodoro Timer built-in. It's kind of the same thing for life that you're getting out of Waffle.io for your projects.
JP:
Yeah. That's great. Life hacking and code hacking.
ALONDO:
Yup.
JP:
It's all the same. Yeah that's it.
CHUCK:
Alright. Well, thanks for coming. It's been really interesting and hopefully [crosstalk] people find useful and great ideas. If you're doing something with Realm, please leave a comment on the show notes and let JP know. Is there a good way to let you know about that stuff – can they tweet at you or email you?
JP:
You can always ping me at Twitter @simjp and then there's always @realm as well.
CHUCK:
Okay. Thanks again for coming.
JP:
Thanks for having me guys.
CHUCK:
We're going to wrap the show and we'll catch on next week.
[This episode is sponsored by MadGlory. You've been building software for a long time and sometimes it gets a little overwhelming. Work piles up, hiring sucks and it's hard to get projects out the door. Check out MadGlory. They're a small shop with experience shipping big products. They're smart, dedicated, will augment your team and work as hard as you do. Find them online at MadGlory.com or on Twitter @MadGlory.]
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]
[Would you like to join a conversation with the iPhreaks and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at iphreaksshow.com/forum]