Make your testers' lives easy and handle errors

Let me know if this sounds familiar: your QA engineer just installed a fresh version of your application. 2 minutes in, you already got your first issue reported: they’re stuck because nothing happens when they press the login button. They’re literally stuck at the entrance of your app and they can’t do their work until you send them another build fixing this issue. That also means stopping whatever you were doing.

Continue reading

How to make a build automatically available to your boss

Imagine this: you’re in the zone, writing code, totally focused, working on that feature you finally managed to wrap your head around. All of a sudden, you feel a tap on your shoulder. It’s your boss.

Continue reading

Handling keyboard notifications with ReactiveSwift

Marc is a good friend of mine. He has a lot of qualities and I even thanked him in my book for all the support he provided me. That being said, he’s still using a super-small iPhone 5S and when I sent him the first build of this project, I forgot to handle the keyboard and it was impossible for him to log into the application. Fortunately for the both of us, handling keyboard-related notifications in an iOS application is super easy. Let’s see how Swift and ReactiveSwift can make it even easier.

Continue reading

Make your codebase more reactive with ReactiveSwift and protocol extensions

Lately, I’ve been working on a fun side project involving the MailCore2 library. This tool allows you to work with emails protocols, such as IMAP and SMTP in my case. Mailcore2 is a cross platform library written in C++ with native bindings for the iOS, Android, Windows and Linux platforms. It’s super easy to use (and works with Carthage!) but as it’s often the case with 3rd party libraries: interfacing with ReactiveSwift is not pretty.

Continue reading

Nobody loves Continuous Integration

I’ve been thinking a lot about Continuous Integration lately. I’m not sure why but it’s a topic I’ve always enjoyed talking or thinking about. I think as long as I’ve been coding, there’s always been a tool that I spent time playing with. I remember cijoe, a tool written in ruby working on top of git. I can also mention Sismo, which was written in PHP. Both tools share a common thing: they weren’t actually used by their creators in their daily jobs, in favor of a more complete tool. To some people, it might seem like time wasted. Why would you work on a tool that you’re not actually going to use for serious, real life projects? To me that’s beautiful.

Continue reading