February 25, 2016
Here’s my daughter’s 500 Words entry.
The Tame and the Wild.
Far, far, away through valleys deep and mountains cold, lived a strong and powerful wolf. In a village there was also a dog that longed to be free. One night there was a terrible storm that shattered the dog’s home. The dog barked and a child cried. The dog decided to escape to explore the valley. He was enjoying his freedom so much that he forgot where he was. Suddenly he felt all alone. After days of climbing up an enormous mountain he came across a cave. He was sniffing outside entrance when he realised there was a dark shape coming towards him as if it was ready to pounce. He became scared, his fur bristled outwards. The shape came closer and into the light. He then saw that it was not a monster. It was a harmless young wolf, about the same age as he was. The wolf sniffed the dog and made a soft whining noises. After a while the dog realised that the wolf wanted to be friends. In a language only known to animals, the wolf said, “My name is Swirl, and I live in this valleyPA with a pack of wolves that are my family. What are you doing in these parts”? “I have got lost, and am all alone” said the dog. Swirl replied “Don’t worry, you can play with me. What’s your name”? “I’m called Buster”, explained the dog. “Well Buster, why don’t you come with me. We can play a game of chase.”
They ran through the trees, until the moon rose, casting great shadows over the forest. Then there was a call, from Swirl’s pack. Swirl said, “Come on, meet family. I’m hungry and there’s sure to be something to eat.” Buster woke one morning, some days later, with a fully tummy, feeling safe and thinking to himself “How wonderful it is to be with a pack of wolves”. But, he knew that he would need to go home soon because his beloved owners would miss him. As usual, the pack had a breakfast of wild rabbit and goat. Then the pack set out on a long journey away from the mountains. They knew Buster needed to go home. They came across a rebuilt log-cabin. On the front door there was a poster with Buster’s picture on it saying “Missing” across the top. Buster knew he was home. For a while, Buster was delighted to be back. But then, at night time, he sometimes heard the wolves calling from far away. He started to howl in reply. He longed to be back in the wild, free again. His owners could see that he was full of sorrow. So, with a heavy heart, they took him back to be with his new wolf family. From then on, Buster spent the summer with his wolf family, and the winter with his human family. He felt lucky to be able to live in both the tame and the wild.
Connie, age 7
Proud dad :)
February 12, 2016
Third-party update service Sparkle, combined with insecure network protocols and parsing, leaves some OS X apps open to person-in-the-middle exploits. A vulnerability has been discovered in an open-source framework that many developers have been using to provide app update services for the Mac.
I’ve always worried that one day a vulnerability in Sparkle would be uncovered and that it would become a malware attack vector.
Well, a vulnerability has been uncovered, but as yet there’s nothing exploiting it (that we know of).
Here, for once, is a reason to actually stick with Mac App Store apps instead of buying direct from developers.
February 5, 2016
Last week I was on the road for five days straight. I brought along my MacBook Pro because, knowing that I would be away from my desk for so long, I anticipated needing to do some actual design work at some point.
I’m in almost complete agreement. I still find it useful to setup and work in a variety of locations, but that location usually involves a desk, because that’s the most comfortable way to use a ‘laptop’ for an extended amount of time.
For my real work, I use dual widescreen monitors. I can work on just a laptop screen, but there’s no pretending I’m as productive as I am with room to spread out on multiple monitors.
February 3, 2016
We’ve taken the decision to take Realm out of our project. It wasn’t an easy decision, considering the team had spent several weeks integrating it recently, but I believe it’s the right move.
Hopefully this post will give you an idea of why we made that decision and perhaps prevent you from repeating our costly mistake.
The Realm team have certainly built a powerful and easy to use technology, and this post isn’t intended as a criticism of what they have produced. Also, I haven’t been personally involved with implementing the Realm integration, so what I know is what I have gleaned through conversations with my colleagues.
Realm sells itself (well, rather, gives itself away) as a fast, reliable and easy to use replacement for CoreData or SQLite. It’s certainly more database like than CoreData, and it’s more of an object persistence framework than a straight SQLite database.
That’s the good bit. There are however, some significant downsides you should be aware of before committing to using Realm in your project.
The team I work with have constantly complained about the quality of the documentation. Often, for anything other than basic usage, you will find yourself searching StackOverflow and Google a lot.
Inaccurate error messages
Almost worse than poor documentation are the inaccurate and misleading error messages. Several times, my colleagues have spent hours chasing down mysterious crashes because the error messages Realm provided were pointing them in the wrong direction.
No support for threading via GCD
The Realm documentation certainly claims that Realm works across threads, although I think some of the same caveats as when using CoreData apply - no passing Realm objects between threads, for instance. However this isn’t the experience that my team have had. I don’t have specific details to share, other than there was talk of potentially having to ‘do everything on the main thread’ at one point, to avoid a serious application crash.
Requires subclassing the RLMObject class
Your Realm objects have to be a subclass of
RLMObject. This is a biggie, and it’s not something that’s unique to Realm by any means - CoreData also enforces this limitation, requiring you to subclass
The problem with this approach becomes apparent when you understand that our app also makes heavy use of Mantle which is a very convenient way to integrate your app model layer with a web API. Unfortunately, Mantle also requires that your objects subclass
MTLModel. Objective-C (or Swift) doesn’t support multiple inheritance. In order to integrate Realm with Mantle you’re looking at writing some kind of adapter layer to convert from one to the other. All of a sudden all these promises of ‘quick’ and ‘easy’ are starting to look pretty hollow.
Aside: One of the key technologies in iOS is
NSCoding - a class conforming to this knows how to archive and unarchive itself when passed to
NSKeyedArchiver. Being a protocol, it doesn’t require that your object is a particular kind of class. I think this is the ideal approach, and with the move to Protocol Oriented Programming, I hope we’ll see more technologies implemented as protocols - allowing you to compose the functionality you desire from a shopping list of capabilities.
No Cascading Deletes
This seems like a major omission, and it was really the straw that broke the camel’s back for our team.
Our use case for Realm was to rapidly and repeatedly store and restore data as the user completes a complex form. We want to prevent any chance of data loss, so we are archiving our object graph to Realm after each user interaction. Some of these interaction can invalidate portions of the object graph, so we were suddenly faced with a growing problem of wasted disk space as Realm didn’t automatically remove objects that were no longer needed.
The team were faced with solving the problem of manually maintaining referential integrity in our Realm. Really, this seems like such a basic function to ask of a database that we were shocked to discover it wasn’t supported automatically.
As of writing, Realm sits at v.0.95x or thereabouts. Meanwhile, CoreData was introduced with iOS3, and before that had been a Mac technology since Mac OS 10.4. It has a dedicated team at Apple who work on it full time.
No, I’m not claiming that CoreData is the be-all for your persistence framework choices. It certainly has it’s detractors. But it’s a mature and stable technology that the industry understands well. I would certainly expect an iOS developer to have working knowledge of CoreData. It’s actively developed, and recent iOS releases have seen big improvements to the way you work with CoreData (specifically parent contexts).
NSCoding is a foundational technology in Cocoa, on both the Mac and on iOS. Yes, it requires writing a bit of boilerplate to get your objects to archive and unarchive themselves, and it doesn’t offer faulting or any ability to run queries. But for a small object graph, I think it should still be your first point of call for your persistence technology.
Realm is another matter. It’s not even hit v1 yet; how can you be certain that you’ll be able to find developers who’ve worked with it next time you need to recruit someone ? Who do you go to when you’ve got an intractable problem ?
Yes, it’s Open Source, but really, who has the time to start forking a project the size of Realm and debugging it when you’re trying to debug and ship your own code ? Not I. And I certainly don’t get paid to debug third party software, when there’s a perfectly serviceable technology that ships with the OS.
If you integrate Realm - or any other third party technology (Parse, anyone ?), make no mistake - you have introduced a huge dependency and liability on something that is mostly, if not entirely, outside of your control. Is that something you want weighing on your mind as you try to hit that ship date and are neck deep in debugging some strange crash. “Was it me or was it Realm ?”.
And if you do find a problem in that 3rd party code, are you really going to have to time to understand and fix it when your boss or client is jumping up and down wondering where his app is ?
My advice to you is to stick with the 1st party frameworks unless you have a very solid reason not to.
CoreData is solid and reliable, and although it requires careful setup and a good understanding of it’s peculiarities and quirks, that knowledge is widespread and mainstream. It takes care to set up your CoreData stack, but once done you won’t get much trouble out of it. And for less demanding needs, you’ve always got
NSKeyedArchiver. Thats two ways to easily persist your data that ship with the OS.
January 31, 2016
Just give into the seduction of iOS. Much like with 2Do, an astonishing amount of people right now are moving — in one way or another — to iOS as a full time computing platform. Perhaps not ditching the Mac completely, but at the very least declaring iOS ready for most of their work.
If I’m doing anything other than coding, I reach for my iPad rather than my MacBook. I have a sneaky feeling we’ll see some iPad Xcode goodness this summer too (maybe Swift Playgrounds) - which will give me one less reason to use the Mac.
January 28, 2016
Xcode - the developer’s worst best friend ?
David Barnard posts a thoughtful piece about how Apple shapes the The App Store as an Economy.
It’s mostly spot on, but this off the cuff comment was a little harsh:
Tooling - It may seem far fetched, but the capabilities of Xcode shape the App Store economy. By pushing interface builder and auto layout, Apple has encouraged developers to build universal apps and made it more cumbersome to build separate iPad/iPhone apps. Bugs, crashes, and other deficiences of Xcode likely cost developers millions of hours of productivity each year, which has obvious implications for the App Store economy.
I think it’s a little egregious to claim that ‘millions’ of hours of developer time is wasted due Xcode bugs, crashing and other failings. I use Xcode for a minimum of 8 hours a day as part of my job and I don’t recall the last time it crashed on me other than maybe when switching git branches that altered the project file in a major way.
It Xcode perfect ? No, of course not. I can list a number of things I’d like to see urgently - not least real refactoring tools and a better debugger (and the list goes on…)
But I think we have to also acknowledge the huge amount of time and effort that Xcode saves developers. Apple’s big push to use Autolayout has undoubtably saved me tens, even hundreds of hours personally, and new features like
UIStackView will continue that trend.
Xcode’s recent improvements to units test support has also been a big benefit, encouraging developers to write tests and keeping them informed about their testing history. UI test also got a huge shot in the arm with Xcode 7.
I know that Apple know that developers have a love/hate relationship with Xcode. But they are obviously working hard on improving the tooling and the results are bearing fruit. I think the perception that Xcode is a buggy, crashy nightmare is at least a couple of years out of date.
What do we want ? “Better tooling”. When do we want it? “Yesterday” ! But in the meantime, Xcode actually does a pretty decent job.
January 27, 2016
Tritium, also known as super heavy hydrogen, was first discovered by Ernest Rutherford, ML Oliphant and Paul Harteckin in 1934. Tritium emits electrons through beta decay and when these electrons interact with a phosphorous material, a fluorescent light is created that can last up to 20 years.
I have an Apple Watch. But there is something undeniably cool about watch markings that are illuminated by radiation. I want one of these.