2019 and 2020 have been years of personal transformation. I focused on anything but tech. It was not exciting for me anymore. But in the last few months, I was able to get out of my comfort zone, ask for help to great friends and invest time and effort in building.

Now, I am finally ready to share my latest creation: Mastering the iOS Interview. It’s a video course to learn how to master your next iOS job interview and get that dream job you’re after.

Mastering the iOS Interview

I hope this is the beginning of a series of video courses to help other software engineers get the jobs they like.

Let keep 🤞.

PS: feedback is alway welcome!

Mastering the iOS Interview was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

It becomes essential then to install multiple versions of Xcode on the same machine. Here it’s how to do it.

Latest Xcode version

The latest version of Xcode should generally be installed from the AppStore, since Apple does not provide a downloadable version. It will get updated by the AppStore when a new stable version comes out (automatically or manually depending on your AppStore settings).

This Xcode version will just be named Xcode in your Applications folder.

Older Xcode versions

You can download old versions of Xcode and install them on the side of the latest one. So you can just choose which version you want to launch depending on your situation.

Open https://developer.apple.com/download/more/ and login with your developer account. Then write Xcode in the left column’s search bar. You will now be able to dowload older and newer versions Xcode, including betas and RCs.

After downloading the archive, unpack it. Rename the extracted Xcode app something like Xcode_11.7. Then, move it into the Applications folder.

You are done. Good development!

How to Install Multiple Versions of Xcode on the Same macOS Machine was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

It’s good etiquette because it gives transparency. It’s good practice because it makes the component you created more scalable. It makes sense because it makes code easier to test.

When creating your future entity store the init parameter as a property with the same access control level of the entity itself. If your entity is public make it public. If internal keep it internal.

One last thing. Please be consistent in the codebase. Don’t go for one logic in one place and a different one in another. Consistency makes understanding your codebase much easier. Especially when there are many team members.

Expose Init Parameters and Dependencies in Swift and iOS Please was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

A while ago I wrote an article which introduced what I called Swift Action Delegate pattern. It is an attempt to write less boilerplate code while implementing delegation for objects communication.

This was the core (maybe re-read the original article for more context):

protocol DelegateAction {}
protocol ActionDelegate: class {
  func actionSender(_ sender: Any, didReceiveAction action: DelegateAction)
}

Few ex-collegues gave me an interesting piece of feedback. The sender is Any type. This is a code smell and not following the Swift principles. We should send an actual type instead, avoiding casting.

Yesterday, I finally figured out how to solve this problem:

protocol DelegateAction {}
protocol ActionDelegate: class {
  func actionSender(didReceiveAction action: DelegateAction)
}

We just remove the sender from the function and pass it as part of the DelegateAction payload. If DelegateAction is an enum (as I generally suggest) it can simply be another parameter of its cases.

final class RedViewController: UIViewController {

  enum Action: DelegateAction {
    case close(sender: RedViewController)
    case complete(sender: RedViewController, success: Bool)
  }

  weak var delegate: ActionDelegate?
    
  func pressButton(sender: Any) {
    delegate?.actionSender(didReceiveAction: Action.close(sender: self))
  }
}

And the class which conforms to the ActionDelegate protocol, has access to the sender which is of the actual type, not a simple Any type.

final class ParentViewController: UIViewController, ActionDelegate {

  func actionSender(didReceiveAction action: DelegateAction) {
    switch action {
    case RedViewController.Action.close(let sender):
      print("Close red. Sender: \(sender)")
    case RedViewController.Action.complete(let sender, let success):
      print("Complete red. Sender: \(sender). Success: \(success)")
    default:
      print(action)
    }
  }

}

I think this makes the ActionDelegate pattern stronger than it used to be.

As always, I am curious to get your opinion and feedback.

Introducing Swift Action Delegate pattern Part 2 was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Let’s say you have a protocol, which only describes an interface. It does not restrict the conformance to only instance types (no : class).

protocol AlphaProtocol {
    var message: String? { get set }
}

Why do the compiler treats the conforming value/object always as a Value type?

If we modify alphaValue property, the compile will ignore the actual type of alphaValue. It will always treat the property as a value type (e.g. struct). So it will create a copy of alphaValue with a different message, then it will replace the old copy with the new one.

If you restrict the AlphaProtocol to classes only, then alphaValue will be correctly be treated as an Instance type. So if you now update the message in AlphaObject, it will just update the message in the current instance.

protocol AlphaProtocol: class {
    var message: String? { get set }
}

This behaviour has been particularly hard to understand, since it’s not intuitive at all.

But the real question is: is this behaviour correct? Is it intended to work that way? If so, why?

Why Swift protocol conforming values are treated as Value types by default? was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Delegation is one of the core pattern on which most iOS SDKs are based on. First of all UIKit. Being familiar with them is core to developing a proper iOS app.

Delegation is solving one of the hardest problem in software development: communication and sharing of information between objects. It’s a complex problem with different opinionated solutions.

I have experimented different solutions which try to solve this problem, but I still think plain delegation is the way to go. It’s simple and robust. Yeah, it’s not trendy like reactive programming 🤐, but it works 🤷.

The problem with delegation is that it’s not immediate. It takes a moment to understand. And when you get familiar with it, it still involves writing a new delegate protocol for every context in which you need it.

Delegates are being used for two main reasons:

• A generic object that can be customised in the point of use. Think about a UICollectionView. It depend upon DataSource delegate methods to get the information it has to display.
• An object which has to communicate with another object. Think about a ParentVC which has presented modally a ChildVC. After ChildVC has completed his goal, it has to communicate to ParentVC he wants to be dismissed.

Let’s say we have a ParentVC which at different moment in time has to present RedVC and BlueVC. They both have to be dismissed at some point in the future. Maybe because the user just want to go back or because the user has selected some value.

In a classic scenario both the RedVC and BlueVC have to define a protocol which ParentVC has to conform to. This way ParentVC will be able to receive some information and eventually dismiss the child VCs.

This generates boilerplate code (which a lot of developers hate very much). It will generate boilerplate in each child VCs files, because protocols need to be defined. It will generate boilerplate code in the ParentVC because it has to conform to two differnent protocols.

Here a practical example (which you can run inside a Playground).

To avoid creating every time a new protocol, which adds very little value, let’s explore another avenue. Why can’t we create just one ActionDelegate protocol which is made for communication between objects? It would be enough to have a flexible way to pass context specific information and it should work everywhere.

The idea is very simple: an ActionDelegate protocol which receives a generic Action as parameter. The Action is any value conforming to the DelegateAction protocol. This way every object who wants to use the ActionDelegate pattern can define his own context specific actions.

protocol DelegateAction {}
protocol ActionDelegate: class {
    func actionSender(_ sender: Any, didReceiveAction action: DelegateAction)
}

Here it follows the previous example, but adopting the ActionDelegate pattern.

The solution, in my opinion, is a (bit) simpler and more consistent delegation pattern. I think it could be a way to write a (bit) less boilerplate code, but especially to have a consistent and stable communication channel between objects.

There are questions that need to be answered. Like, is it a good idea to have a single method responsible to reply to messages from other objects? It’s something similar to prepareForSegue (🙈🙉🙊).

I am interested in your opinion. Please comment or test/fork the gists in a Playgorund and let me know a better solution.

Since I published this article, I got some feedback on some concepts to be improved. So, I wrote a follow up article: Introducing Swift Action Delegate pattern Part 2.

Introducing Swift Action Delegate pattern Part 1 was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

The concept is simple. I am going to mount the Linux machine HDD as remote drive (via ssh) on my Mac.

This means being able to to use Xcode on my Mac, with all the nice tools I have there. I will only have to open the terminal on the Linux machine to compile and run.

Step 1: Install SshFS

On your Mac install OSXFuse and SshFS. You can download them both from https://osxfuse.github.io/

Step 2: Create a mount directory

Somewhere on your Mac create a folder which will be where your remote drive will be mounted (where you will find the remote drive’s files).

mkdir ~/Desktop/RemoteDrive

Step 3: Mount the remote drive

You will have to mount the remote drive at every system startup.

sshfs USER@MACHINE-HOSTNAME:/home/USER/ ~/Desktop/RemoteDrive

Step 4: Code

Now you will be able to open the directory from Finder and use it as USB stick. Just open it, create your Xcode project and develop as usual.

Step 5: Unmount the drive

When you’re done, you should unmount the drive securely.

fusermount -u ~/Desktop/RemoteDrive

Simple and convenient. Yay!

To get my latest Swift misadventures subscribe to the publication. Cheers.

How to use Xcode to write Swift code on a remote Linux machine was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

I am working on a robotic project which has at its core a Raspberry Pi with Ubuntu minimal (no GUI) and Swift 3.0.

The problem with a vanilla Ubuntu is that it requires you to have a monitor, keyboard and mouse. All of this in inconvenient and I would love to just do everything by ssh-ing into the machine. Sadly, it’s not possible out of the box.

After some experimenting I’ve been able to achieve that. What follows is the tale of this mighty nerd.

Step 1: Preparation

Get your Raspberry Pi 2 or 3, an SD memory card with 8Gb or more memory (class 10 or more), a micro USB cable (for power), an ethernet cable and the Wifi USB dongle.

Step 2: Flashing Ubuntu 16.04 server minimal on the SD card

Download Ubuntu server classic from here or here. This is a flavour of Ubuntu server, which have been stripped out of everything which is not strictly necessary, so it’s very light.

Now you have to flash the image on the SD card. On the web you will find a lot of multi step command line guides. But that’s nuts, since there’s a great apps, called Etcher.io, that make the process incredibly simple, fast and safe.

Download Etcher app (for all platform), then select the Ubuntu image, the SD card (which you have to insert in your computer) and flash it. Few minutes and it will be done and verified.

Put the SD card into the RPi, you’re ready to rock!

Step 3: Ssh-ing into your RPi

After you’ve inserted the freshly backed SD card into your RPi connect the ethernet cable between the RPi and your router. Turn the RPi on by connecting the micro USB cable to the electricity or to your computer.

Wait few minutes, since the first boot takes longer than usual. Then open your router’s dashboard and look at the ethernet connected devices. You will see a device hostname ubuntu-minimal. Take a note of the IP of that device.

Open your terminal and type:

ssh ubuntu@THE_IP_YOU_JUST_FOUND
(password ubuntu)

You should be in!

You are now connected to the RPi via the network. The only problem is that you still need to keep the RPi connected to the network throughout the ethernet cable. But let’s address that.

Step 4: Going wireless

First we need to update the operating system:

sudo apt-get update
sudo apt-get upgrade

Install the wifi support:

sudo apt-get install wireless-tools wpasupplicant

Now reboot. It’s important to do it now, since my wireless interface changed name after this step. From a nice “wlan0” to a weird “wlx000f6005a699”.

sudo reboot

Attach the USB dongle to your RPi. Then, ssh again into it. Then, list the wireless network interfaces with:

iwconfig

Take note of the wireless interface name (e.g. wlan0 or wlx000f6005a699).

Open the network interfaces configuration:

sudo nano /etc/network/interfaces

At the bottom of the file add (replacing the wlan0 with the name of your interface):

allow-hotplug wlan0
iface wlan0 inet dhcp
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Now, open the wireless configuration file:

sudo nano /etc/wpa_supplicant/wpa_supplicant.conf

and add at the end of the file the informations about your wifi network:

network={
    ssid="your-network-ssid-name"
    psk="your-network-password"
}

Save and exit the editor. Remove the ethernet cable and then reboot:

sudo reboot

Now in about 30 seconds your RPi should be up an running. If you try again to ssh into the RPi (still looking for its IP in the router dashboard), you should just be able to connect to it via wifi!!

Step 5: Ssh-ing into the RPi with a dynamic IP

As you’ve already noticed, checking the the RPi’s IP every time you want to connect to it, it’s a bit of a pain in the ass.

So, let’s install avahi which will make you able to connect to the RPi via its hostname.

sudo apt-get install avahi-daemon

Now, after a reboot, you will be able to ssh into the machine:

ssh ubuntu@ubuntu-minimal.local
(password ubuntu)

Step 6: Securing the ssh authentication

I suggest you to secure your login with a rsa key authentication and enabling it only the port 22.

From your Mac laptop:

ssh-copy-id ubuntu@ubuntu-minimal.local

Now you should be able to ssh into RPi without password:

ssh ubuntu@ubuntu-minimal.local

The-wise-guy-last-step: Backup your RPi

It’s very easy to burn an SD card by writing to it too many times. Or irreversibly fuckup your configuration by doing what sudoer should not do. Cloning your SD card, as an image that you can flash on a new card when you need it, is the perfect backup strategy. Here you find how.

You are now ready to install Swift 3.0 developer preview on your sexy Raspberry Pi Ubuntu box.

To get my latest Swift misadventures subscribe to the publication. Cheers.

How to setup your Raspberry Pi 2/3 with Ubuntu 16.04, without cables (headlessly) was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Step 1: Understanding the GPIO pins numbers

The core concept is that not all the pins in available on the board are GPIOs (General Purpose Input/Output). Some are power supply, others are ground connection and others are other-stuff.

The number inside the circle is the pin number. Some of these pins match a GPIO pin. For example the pin 7 matches the GPIO4 pin.

We can control only the GPIO pins, not the other ones. The other ones are used to power up your circuit or to do other-stuff.

Step 2: Connecting the circuit

We want to create a simple circuit where an LED is turn on by the GPIO4 (pin 7). So we create a simple circuit like this:

Step 3: Making sure we can actually set a value on a GPIO pin

We are installing a package that allow us to set values on a pin from command line. Just to make sure we’re actually able to turn the GPIO value high and low.

sudo apt-get install wiringpi

Now let’s set pin 7 as output and turn it off, then on and then off again:

gpio mode 7 out
gpio write 7 0
gpio write 7 1
gpio write 7 0

It should work. If it doesn’t, well, it’s very likely you’ve made some wiring mistake in your circuit.

Step 4: Using SwiftyGPIO library to control the GPIO pins

Uraimo has created a very nice Swift wrapper around the GPIO pins, so we can control them in our Swift app. There are few things that could be done better (e.g. more protocol oriented representation of the different GPIOs types, better representation of the GPIOs states and more immutability of a GPIO representation), but it’s still a good starting point.

Since the Swift Package Manager is still not working properly on Raspbian to date (July the 8th, 2016), we are going to clone the git repo and use the file directly within our code.

The important bit is to have all the sources in one folder, to be able to compile them all in one simple command.

mkdir ~/ledtest
mkdir ~/ledtest/Sources
cd ~/ledtest
git clone https://github.com/uraimo/SwiftyGPIO.git
cp SwiftyGPIO/Sources/* Sources/

Let’s create our main:

nano Sources/main.swift

with this code:

import Glibc

// Get the Pin where the LED will be attached to
let gpios = SwiftyGPIO.GPIOs(for: .RaspberryPi2)
guard let ledGPIO = gpios[.P4] else {
    fatalError(“It has not been possible to initialised the LED GPIO pin”)
}

// Set the GPIO to output
ledGPIO.direction = .OUT

// Turn on and off the led few times
ledGPIO.value = 1
sleep(1)
ledGPIO.value = 0
sleep(1)
ledGPIO.value = 1
sleep(1)
ledGPIO.value = 0

Now compile and run as super user (it needs sudoer permissions to access the GPIO pins):

swiftc Sources/*.swift
sudo ./main

The LED should blink two times and then stop. Success!!

Step 5: Cleanse our soul with some cleaner code

I feel dirty in writing hacky scripts. I start regretting all my life decisions when I understand I wrote something that’s not even close to be acceptable good. So the following code is the v2 of the app.

But first I really suggest you to configure your Atom or SublimeText editor (on your main computer) to edit code remotely on your RPi, so you don’t have to use nano or vim. (Info for Atom and for SublimeText).

That should be it. Compile and run. The LED should keep blinking until you stop the execution.

This is the basic you need to know to start doing amazing things in electronics with a very nice programming language and all the things that comes with it.

To get my latest Swift misadventures subscribe to the publication. Cheers.

Using Swift to control the Raspberry Pi GPIO pins and turn an LED on was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ssh into your RPi:

ssh pi@raspberrypi.local
(password raspberry)

Open the apt sources file:

sudo nano /etc/apt/sources.list

Uncomment the last line:

deb-src http://archive.raspbian.org/raspbian/ jessie main contrib non-free rpi

Update your system and install some required packages:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install clang git

Installing Swift 3.0 build at root level. We’re going to use Joe Bell’s incremental builds:

cd ~
wget http://47.186.11.166/job/Swift-3.0-ARMv7-ubuntu1410/29/artifact/swift-3.0-2016-11-03-armv7-ubuntu14.04.tar.gz
sudo tar -xzpf swift-3.0-2016-11-03-armv7-ubuntu14.04.tar.gz -C /
rm swift-3.0-2016-11-03-armv7-ubuntu14.04.tar.gz

You have installed Swift!! Now start screaming like Steve Ballmer in a moment of uncontrolled excitement.

Let’s write our first Swift script to see that it’s actually working:

mkdir swifttest
cd swifttest
nano main.swift

Add this simple hello world (which ironically doesn’t say “hello world”):

import Glibc
import Foundation

let currentDate = NSDate()
print(“My first Swift binary! Executed at \(currentDate)”)

Compile and run:

swiftc main.swift
./main

Well done! You’re ready for the world. Now go and write beautiful swift code. Or turn some LED on with Swift!

To get my latest Swift misadventures subscribe to the publication. Cheers.

Installing Swift 3.0 preview on a Raspberry Pi 2/3 with Raspbian was originally published in A Swift misadventure on Medium, where people are continuing the conversation by highlighting and responding to this story.