Swift on the Raspberry PI

In this article we will discover how to use the Swift programming language to write software running on our Raspberry PI. We’ll be reading and writing through the GPIO of our board, connecting a number of widely available components and, at the same time, interacting with a remote sever.

Here, I’ll be covering how to get started with Swift on a Raspberry PI board.

Continue reading Swift on the Raspberry PI


Yesterday I talked about Carthage at CocoaHeads Paris. Here are the slides of my presentation, in French: https://speakerdeck.com/viteinfinite/carthage.

Even if I am not involved in the project, I believe Carthage has some great potential, I really like the minimalist approach and, in particular the fact that developers can keep control over what really happens when you add an external dependency.

The idea of using committed xcodeprojs to retrieve informations about the build is quite good, even if it obviously requires to have a shared scheme – which it’s not the case for the majority of project so far.

I’m looking forward to see more and more libraries supporting Carthage though even if for now, at least for client work, I’ll stick with CocoaPods.


Be the Quality you Want to See in the World – Code Quality Metrics

I somehow forgot to publish the slides on this blog. You can get them here.

It’s been fun discussing with people about the subject. I think there is still a long way to go before having this integrated in the majority of the applicable projects, mostly because the setup process needs to be automated. Still, I believe it’s a step in the right direction.

How to add custom environment variables in Xcode and CocoaPods

Let’s say we would like to share some Xcode environment variables across multiple targets in a project configured with CocoaPods. For instance, we would to use the same app version number across our development and distribution targets in order not to retype the same values for each version bump over and over again.

The solution I opted for was to:

1. Add a custom xcconfig file (for instance “SharedSettings.xcconfig”) from the Xcode menu

Screen Shot 2013-05-21 at 12.16.11 PM

2. In the project settings, change the configuration settings file to “SharedSettings”

Screen Shot 2013-05-21 at 12.18.43 PM

3. In settings file, in order to preserve your pod configuration, add

#include "Pods/Pods.xcconfig"

And it’s done: now you can use the environment variable $(VERSION_NUMBER), even in your plist file, without breaking the compatibility with CocoaPods. As a result, any future “pod install” will not break the configuration you have just created.

How to resolve “Unable to start status bar server. Failed to check into com.apple.UIKit.statusbarserver: unknown error code” exception

Ever wondered how to resolve the following error while executing GHUnitTest by Command Line?

*** Assertion failure in -[UIStatusBarServerThread main], /SourceCache/UIKit_Sim/UIKit-2372/UIStatusBarServer.m:96
*** Terminating app due to uncaught exception ‘NSInternalInconsistencyException’, reason: ‘Unable to start status bar server. Failed to check into com.apple.UIKit.statusbarserver: unknown error code’

Well, I did.

In my situation, the exception was caused by having an iPhone Simulator session opened while executing the CLI tests. So, in order to resolve the issue, I simply had to add

killall -s "iPhone Simulator" &> /dev/null
if [ $? -eq 0 ]; then
killall -m -KILL "iPhone Simulator"

on top of the run script file (RunTests.sh) which is executed as last “build phase” of the build process.

EDIT: I wrote another post explaining how to solve the error after migrating to XCode 5.

La merditude des choses

‘Contrairement à la voiture, le train passe par les coulisses du monde, les belles maisons classées du quartier de la gare s’avèrent en réalité être des taudis.
Mais ces ruines ne se voient que depuis la voie ferrée.
Rien ne vous donnera une vue plus sincère de notre pays que le train.
regardez nos jardinets, nos pigeonniers et nos cabanes, admirez nos sous-vêtements qui sèchent dehors, contemplez nos nains de jardin, nos céleris, nos poireaux, nos vérandas et nos barbecues maçonnés, regardez comment dans les prairies les vaches font place à des monstres de brique bâtis par des gens sans goût, avec la complicité des banques, des monstres qui défigurent le paysage belge, prenez le train et regardez comment, immobiles, le long des voies, le marbre et le granit s’ennuient sous la poussière, offrant une dernière demeure à nos morts.’

Come non essere d’accordo? – 3D TV falls flat for me

It’s generally a bad idea to extrapolate larger consumer behavior from personal experience and say “if I like it, surely everyone else will as well.” It’s a mistake that happens all the time, but there’s is one case where I will use my personal behavior to at least start the foundation for analysis — when I don’t want a new gadget or technology. Granted, sometimes I’m just not the target audience, but even then I’m usually able to remove myself from the process and say it might not be for me but others will love this. In the case of 3D TV, however, I think my lack of interest doesn’t bode well for the market.

I’m surprised by figures, forecasts, predictions and prophecies all showing a rosy outlook for 3D TV beginning as early as this year, because I’ve seen most of the 3D offerings available and I have no plans to buy — not now and not anytime soon. I should be a part of the core demographic for 3D: I like TV, movies and video games. I’m am early adopter. I have reasonable disposable income. I’m not afraid of betting on the wrong standard. And yet, I’m not buying. Here’s why.

Cost: I’m fortunate that cost isn’t the biggest inhibitor for me when I buy things, but I still do a cost/benefit analysis before I make a purchase. To really embrace 3D, I need a new TV, even though my current 1080p set is only a few years old and is wonderful. I’d need a new media player. I’d need glasses — lots of them, as there can often be five or six people sitting around my set. I’d probably want a new digital camera to take 3D shots. And of course, I’d need some compelling 3D content from somewhere. That’s already starting up to add into a significant cost proposition that takes it far out of impulse purchase territory.

Hassle: It’s not just the cost to move to 3D. It’s the hassle. Moving to HD was a breeze — you just plugged in a new TV and were wowed by immediately available content. My upscaling DVD player made existing SD content look better than ever. By contrast, just viewing 3D content is a hassle due to the glasses. They’re not cheap. They are gadgets in and of themselves, which means they require care and feeding, and everyone in the room needs a pair. Worse, I find 3D glasses very uncomfortable to wear for long periods over my regular glasses. The hassle alone of acquiring and viewing 3D content is enough to put me off.

Benefit: The cost and hassle of 3D could easily be justified and rationalized if there was a superb benefit on par with the move to HD. For me, 3D is cool but at best gratuitous. It doesn’t change the visceral viewing experience for most of the content I’ve seen. I just don’t see the value or wow factor that 3D brings to the table in its current format.

Someday technology will advance and 3D will be integrated into every screen. Standards will be deployed and the bulky and costly glasses will disappear. Content providers will figure out how to tell better stories with 3D that wouldn’t have been possible before. And if that happens before I do my holiday shopping this year, I’ll be on board. Given the low probability of that scenario, I’m going to pass for now. I expect many other consumers will as well.