The yearly, super awesome, Q42 christmas party was last friday. It’s my second since I’m working at Q42 for 2 years now. I really enjoy my time at Q42, mainly because of three things:

1. Autonomy
2. Mastery
3. Purpose & Party

Autonomy

The projects we do, the techniques we use and the approach we take on projects are open for discussion by everybody. Reasonable arguments are always considered, no matter if they’re made by an intern or managing partner. There is no one dictating how you should do your work and often even the features requested by the client are up for discussion.

Deciding with your team, including the client, on what technique your going to use, how you’re going to approach the project and what the most important goals are really makes everybody owner of the proces. This autonomy also results in people that are really committed to solving problems and making a great project.

Mastery

All that autonomy is great, but you need the right people in the right place to be able to let them choose how to work. I’m still wondering how so many smart people can end up in one place. All people working at Q42 are really really great at something. This mastery makes it easy to trust someone.

Constant learning is as important as having smart people around. Not only do we have colleagues that are very eager to learn new stuff, there is actually time built into the planning of every employee to do whatever you think you should do for half a day every other week. People learn new programming languages, crack hard problems and create libraries in that time.

It’s really a pleasure to work with great people that are working hard to get even better!

Purpose & Party

Besides a lot of control over your own work, great people to work with and room to improve yourself there is something else; Purpose. It’s nice to work on things that you really believe in.

We try to do projects that matter, projects about better learning experiences for kids or blind people going to the cinema are really seen as valuable and important. The company would rather do an extra project like this, than go for more profit. Working on project like that or even seeing colleagues work on them really gives you a motivational boost.

Besides meaningful projects it’s also great to see how nice it is to be together outside of work. The amazing yearly retreat, the christmas party and the spontaneous activities organized by the employees themselves like tasting special beers or playing offline games. Those things make Q42 so much more then just a place to work.

q42nl:

One day I found myself looking at a giant spike of crash logs in our monitoring tool. A quarter of all users had a crash on launch when they tried to start the new version of our app. We made a mistake in migrating users to a new data model. The one star reviews came in, angry tweets started appearing all over the place and customer support calls shot up. I found myself in a classic “shit hits the fan”-moment.

Everybody encounters moments like this every once in awhile. It can be quite stressful and it might seriously piss off the client you work for. Going through mistakes like this I learned that you never should jump to a “no mistakes allowed”-style of working. You can’t avoid all mistakes, it’s all about how you handle the issue. If you do that right, you might even end up with a compliment instead of an angry person on the other end of the line.

Keep reading

Another blog I wrote on our company blog. :)

q42nl:

Last week I was enabling Bitcode for the PostNL app we develop. Bitcode is a new technology from Apple that optimizes your app by recompiling it in the cloud with optimizations for the specific device that downloads it, making the app smaller and faster on the user’s device. Later that week I stumbled upon the blogpost “To Bitcode, or Not to Bitcode?” by David Wheeler.

His recommendation on Bitcode is to “wait and see”, because of potential security issues and the possibility of irreproducible bugs. Of course some of us are forced to use libraries that don’t support Bitcode and some of us want to write inline assembly, so those could be valid arguments to temporarily disable Bitcode. All his other arguments do not impress me very much and I believe they shouldn’t scare you either.

Take for example the fear of hackers injecting code into your app. You already submit your apps to Apple. If hackers are so deeply embedded in Apple’s infrastructure that they can control the (re)compilation process, they will have so many other ways of modifying or getting your apps’ data that disabling Bitcode really won’t matter. Besides, I would be more worried of your own developers having malware on their computers, like modified Xcode versions, than Apple being hacked at this level.

Irreproducible bugs due to extra optimizations would be Apple’s own worst nightmare. It would be very bad for customer satisfaction. So you can bet Apple is going to great lengths to prevent apps from crashing. Most code iOS developers write is not so low level that compiler optimizations would affect it in a way that makes it crash. If you write code that stops working when you change compiler optimizations, you’re either doing it wrong or you have found a serious compiler bug. If you happen to be that one person to run into that very specific issue, you can always disable Bitcode as a workaround and report the issue to Apple.

I believe new technologies like Bitcode help us move forward. Bitcode helps us worry less about the small things and gives us more time to develop stunning user experiences. We shouldn’t “wait and see” how things play out, but embrace change and explore how it makes our apps better.

This also touches on a broader point. I think developers should help the business they work for move forward. Develop for the future and where the technology will be going, not for the past. Apple is committed to technologies like Swift and Bitcode. They make them available to us so we can make better apps for our users and will continue to improve them. Embrace change, make your apps even better than they already are and don’t fear Bitcode or any other technology that makes your app better for your users.

Wrote an article about Bitcode on our company blog. :)

If XCode throws that into your face serval things could be wrong, some are easily found on Google/StackOverflow. Unfortunately none of the proposed solutions over there worked for me, so I’ve gone back in history one commit at a time to see where I broke this…

Long story short; One of my classes now imports UIKit, my tests don’t import UIKit and this triggers XCode to create an invalid test bundle. After some fiddling around I found that adding import UIKit in one of my test classes fixes this. My tests run like charm again.

One importent catch with this issue is that once one valid bundle is created XCode will keep creating valid bundles until you do a clean build. So this is why I only noticed this issue only after some time.

Importing UIKit in the tests was a simple solution for this XCode bug and adding it will prevent you from seeing this error over and over again:

2014-11-01 17:15:20.120 xctest[60524:4986818] The test bundle at .../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug-iphonesimulator/CoreDataKitTests.xctest could not be loaded because an unanticipated error occurred. 2014-11-01 17:15:20.121 xctest[60524:4986818] Detailed error information: Error Domain=NSCocoaErrorDomain Code=3587 "The bundle “CoreDataKitTests” couldn’t be loaded because it is damaged or missing necessary resources." (dlopen_preflight(.../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug-iphonesimulator/CoreDataKitTests.xctest/CoreDataKitTests): Library not loaded: @rpath/libswiftCoreImage.dylib Referenced from: .../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug-iphonesimulator/CoreDataKit.framework/CoreDataKit Reason: image not found) UserInfo=0x7af2b1b0 {NSLocalizedRecoverySuggestion=Try reinstalling the bundle., NSFilePath=.../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug-iphonesimulator/CoreDataKitTests.xctest/CoreDataKitTests, NSLocalizedFailureReason=The bundle is damaged or missing necessary resources., NSLocalizedDescription=The bundle “CoreDataKitTests” couldn’t be loaded because it is damaged or missing necessary resources., NSDebugDescription=dlopen_preflight(.../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug-iphonesimulator/CoreDataKitTests.xctest/CoreDataKitTests): Library not loaded: @rpath/libswiftCoreImage.dylib Referenced from: .../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug-iphonesimulator/CoreDataKit.framework/CoreDataKit Reason: image not found, NSBundlePath=.../Library/Developer/Xcode/DerivedData/.../Build/Products/Debug-iphonesimulator/CoreDataKitTests.xctest} Program ended with exit code: 1 *** Test session exited(1) without checking in. If you believe this error represents a bug, please attach the log file at /var/folders/cf/_3xf_8md43s3cd5b05pw08sh0000gn/T/com.apple.dt.XCTest-status/Session-2014-11-01_17:15:16-2IR12h.log

tl;dr: You also should generate XCode/Dash compatible documentation from your own projects! It’s easy, check out the “Hands on” paragraph.

Intro

Let me start with a little confession, I never write “javadoc” style comments in my iOS projects. Why? Well because I never look back at them, it’s not easy enough to browse, search and jump through these docs. I’m just as fast reading/searching through the code.

But I love good “javadoc”-style documented CocoaPods. Why? Well I can look them up on CocoaDocs.org and load them all into Dash (or XCode docs) easily. Together with the XCode Dash plugin I alt-click right into the docs, way easier and faster then reading and searching through code.

If I could make it just as easy to browse through docs of my own projects, the “javadoc” comments would actually be used and add value. I would write them and develops that are new on the project would have great docs to see what is doing what!

So today I fixed auto-generated docs for my own projects!

Hands on

Install Appledoc

First off we install Appledoc to generate Apple style documentation, I would recommend installing the latest binary release from Github or just follow the compile and install instructions in the Readme.

XCode build script

Now let’s XCode generate documentation whenever we build:

1. Click on your project
2. Select your target from the left pane
3. Click the little plus
4. Choose “New Run Script Build Phase”

Now we’re ready to feed XCode the script it needs to execute to build the docs. Open the “Run Script” section you just added and put this script into the “Type a script…” box:

This script will generate a docset and log file into your project directory ignoring .m-files and any Pods you have. It will also document classes/methods etc without documentation. But most importantly it’s async, so it won’t slow down your compilation time and checks if Appledoc is installed so your colleagues won’t get build errors.

Adding the docs to Dash

When you build your project you will see a docset file popping up. Just clicking it will add it to Dash (or XCode). Dash will remember where the file is so when it updates Dash will use the latest version when you alt-click or search for something.

Closing thoughts

I would advise not to commit the docs into your version control system, but ignore it. This will prevent conflicts and the docs will regenerate on build so it’s easy to get up to date docs.

Also I really think its way more rewarding to write documented classes, enums and methods now since people will actually use them!