Welcome to the mac world

Wether you’re new to macOS or an user coming from different machines, the tools we tend to use is very important to be productive.

Here you’ll find my list and what I install on a fresh machine to get started.

System tools

First and foremost, I start with brew to handle all my packages, but instead of doing so manually, I use my dotfiles and my “magic” install script that does all the heavy lifting for me.

Keyboard tools

I use a TypeMatrix with a Colemak layout and also the internal keyboard of my laptop with its default layout. Colemak layout is available on a fresh macOS install but it is far from perfect as there are a lot of missing dead keys (to type accented letters mainly), so I start by installing the layout provided on this page: Colemak mac

To easily switch between the two and get almost the same feeling, I use Karabiner Elements.

Everyday tools

• sdkman: to manage installation of various sdk (mainly Java based)
• iTerm: nice terminal app with profiles
• tmux: multi terminal in one window, switching terminal with a keystroke
• zsh: Z-Shell
• starship: fast shell prompt
• ripgrep: faster grep
• bat: nice cat alternative (with paging / highlighting)
• exa: replacement for ls
• Alfred: Spotlight with more features, this is my main app launcher / switcher
• SetApp: App subscription service, use many tools from this (BetterTouchTool, iStat, BarTender…)

Now that iOS13 is available for more than year, we can start to set it as a lower bound for our deployments.

This allows us to play with all sugar that Apple put in it, one of the biggest thing is the arrival of SwiftUI to supercede UIKit (write cross platform UIs and so on).

Bridging the two worlds

Using SwiftUI from UIKit

The first thing we might try to do, is embedding a SwiftUI View inside our UIViewController based application. To do so, Apple gives us UIHostingViewController which is a simple bridging controller, straightforward to use.

struct MyNewView: View {
    var view: some View {
        Text("I'm in SwiftUI")
    }
}
class MyNewViewViewController: UIHostingViewController {
    init(){
        super.init(rootView: MyNewView())
    }
}

UIViewController in SwiftUI

However, at times we still need to reuse our good old UIViewController, either because we can not afford a full SwiftUI rewrite, so we want to keep old code and migrate pieces by pieces or because we are using something not yet adapted to SwiftUI.

In my case it was using the camera to scan a QRCode.

Non elegant solution

I faced a few issue with examples I found out, most of them are adding an extension to the UIViewController that makes it conform to UIViewControllerRepresentable.

class MyViewController: UIViewController{
    var cancellable: Cancellable?
    // classic stuff
}

extension MyViewController: UIViewControllerRepresentable {
    public typealias UIViewControllerType = MyViewController

    public func makeUIViewController(context _: UIViewControllerRepresentableContext<MyViewController>) -> UIViewControllerType {
        self // don't .init() please, class instance is already available
    }

    public func updateUIViewController(_: UIViewControllerType, context _: UIViewControllerRepresentableContext<MyViewController>) {}

    static func dismantleUIViewController(_ uiViewController: UIViewControllerType, coordinator _: Coordinator) {
        uiViewController.cancellable?.cancel()
    }
}

struct MyView: View {
  var body: some View {
    MyViewController()
  }
}

I find this not easy to read, as we’re doing weird thing by returning self from a function named makeUIViewController. Some example are telling to return MyViewController() instead of self. Please don’t do this otherwise you’re creating the UIViewController twice for each call !

I also had a leak when using Combine (more to come about this great framework), my Cancellables were never freed, leading in a memory cycle that kept the UIViewController living even though it was no longer presented.

It is important to do proper house keeping in the dismantleUIViewController method if you don’t want to use too much memory and slow down your app.

Nice looking way of doing

You will find a working example below, basically we need to implement a UIViewControllerRepresentable struct to represent be the container for our UIViewController in the SwiftUI world.

class MyViewController: UIViewController{
    var cancellable: Cancellable?
    // classic stuff
}

struct MyGreatView: UIViewControllerRepresentable {
    public typealias UIViewControllerType = MyViewController

    public func makeUIViewController(context _: UIViewControllerRepresentableContext<MyGreatView>) -> UIViewControllerType {
        MyViewController()
    }

    public func updateUIViewController(_: UIViewControllerType, context _: UIViewControllerRepresentableContext<MyGreatView>) {}

    static func dismantleUIViewController(_ uiViewController: UIViewControllerType, coordinator _: Coordinator) {
        uiViewController.cancellable?.cancel()
    }
}

struct MyView: View {
  var body: some View {
    MyGreatView()
  }
}

As I was working on an iOS project, I added unit tests to ensure things are not behaving badly (and will not).

During the process, a common pattern showed up and a few fields were required, I came up with the idea to basically create a BaseTest for my tests, so that everything is unified.

Base idea

I came up with something like the following for my tests

class BaseTest<T, Action>: XCTestCase {
    var subject: T!
    var actions: [Action]!

    override func setUp(){
        subject = T()
        actions = []
    }
}

class LoginTest: BaseTest<LoginMiddleware, LoginAction> {
    func test_loginIsWorking(){
        // ...
    }
}

It worked very well within XCode, I could run the tests by hitting the 🔹 in the gutter.

Bad things happen

The thing that I discovered later (thanks to the CI feedback), is that XCode was not properly discovering my tests as it should. At first I blamed the fact that my new tests were not at the top level of my sources folder (and the other ones were), but it was easy to check that this was not the problem at all.

Then, I blamed fastlane and thought that I’ve missed something in my test target configuration or something, but in fact, the problem was similar when using classical CMD + U key combo.

XCode was simply not discovering my test.

Workaround

Inheritance is often misused, in this case, I think it is relevant, but I applied classical way of working around this. I changed my BaseTest to a BaseHelper instead, to which the test delegates the calls.

With this, the test class properly inherits XCTestCase and is discovered as expected (even in subfolders).

class BaseHelper<T, Action>{
    var subject: T!
    var actions: [Action]!

    init() {
        subject = T()
        actions = []
    }
}

class LoginTest: XCTestCase {
    var helper: BaseHelper<LoginMiddleware, LoginAction>!

    override func setUp(){
        helper = .init()
    }
    func test_loginIsWorking(){
        // ...
    }
}

The nice thing in this solution is that the setUp call is no longer magical !

It’s been a long time

It’s been a very long time since last post (5 years…).

I am convinced that blogging is useful, at least for my present self, and for my future self that tends to lose track of important things.

What will this be about ?

In the past I blogged a lot about Java / Maven and so on, my days have evolved to another languages, so I guess there will be less JVM things (but may be a few Kotlin) and more Swift / Rust on the other end.

Technical stack

In a blog reboot, we (I mean dev) like to follow the latest trend and migrate our blog system to latest hype stack. I will avoid this and focus on writing instead, so the site stays in its 15’ shape:

• jekyll
• github-pages
• markdown (I think jenkins-asciidoc is around the corner though)
• github actions for building

The sole new thing is that I’m trying to write using gitpod.io to get a distraction free environment.

Proxying with Docker

When using docker under a corporate proxy, it can be cumbersome to have a working networking in all containers. You often end up being blocked by specific network access which does not seem to be properly forwarded to the proper proxy. For example when using apt.

Classic way of doing

There is a documented way of using a proxy, by adding command-line switches to your docker deamon. However, it does not seem to work everytime and could require exporting additional settings to your in-container applications (in my experience though).

Why not using docker

Nicolas pointed me an image he created to help with the setup of a corporate proxy. It uses redsocks under the hood that listen to the docker socket and automatically add the glue to do the forwarding through the proxy.

Easy proxying in docker is just one command away ! (fill in the blank of your proxy ip and port)

docker run \
       --restart=always \
       --privileged=true \
       --net=host \
       -d ncarlier/redsocks \
       $PROXY_IP $PROXY_PORT