iOSCon 2017

The 2 days came and gone, so fast you couldn’t believe, it all had ended so fast!
As last year, the organisation was excellent and everything went really well…

I enjoyed all the talks that I attended and had some difficult decisions to make, the two tracks made choices impossible sometimes.
So here are my considerations:

First day

Please don’t lose the master class from Dan Cutting, The Grand Tour of iOS Architectures. A really good explanation of all the MVC, MVP, VIPER, CLEAN and FLUX or REACTIVE architectures/patterns.

Another talk not to lose is TDD in Xcode Playgrounds by Paul Ardeleanu: The power of TDD in a playground showing you how to quickly get feedback from your tests, and how can you then move the tests to your project.

Swift on the server was well represented by this workshop: Workshop: Building a server-side Swift app with the Kitura web framework by Chris Bailey and Ian Partridge.

If you are looking for a new job, please don’t skip Ace The Technical Interview by Abizer Nasir. Very good advises there.

Second day

You get to venue with mixed fillings: you are super excited for the new talks ahead, but you are also exhausted from day before…you are starting to think that your brain can’t take much more, and you sit down to listening to the keynote by Daniel Steinberg, and you definitely start to rethink your life. Why? How? What?

Another great talk was Going Universal: Building an app for Mac, iPhone, iPad and Apple TV (and staying sane) by Adrian Thomas where he explains the process of building and app not just for the iPhone, focus on how to organize your code (essentially your shared code) but not forgetting the UI and how you should maintain some core elements between the different versions of your app.

Unfortunately, there is no video for this excellent workshop by Phil Nash: Test Driving Swift To The Max – with or without the tests!. Very enlightening and using AppCode instead of Xcode.
Building better iOS apps with GraphQL, doesn’t have a video too, but was a really nice talk about how to talk to the server without a REST API. Will it be the next hype on iOS?

And that’s it, folks! Next year there will be more.
It was really nice to reencounter friends and make some new ones and learn new things.
Never stop learning!

Mastering TDD

Two weeks ago I went to Paul Stringer’s course “Mastering TDD/BDD in iOS”. After the two days, I was exhausted… During the course, we looked at all the theory, completed some exercises. Paul gave us lots of links and books to read and, quite frankly, I was feeling overwhelmed.
I saw myself in front of the computer, with all those links to follow and read, and I didn’t know what to do… So I laid back on my chair and closed my eyes and thought… What do I know about TDD?

Following the rules…

Well, I know that it has laws:

  • You must write a failing test before you write any production code.
  • You must not write more of a test than is sufficient to fail, or fail to compile.
  • You must not write more production code than is sufficient to make the currently failing test pass.

I know I should follow the circle Red – Green – Refactoring:

  • Red – Create a failing test
  • Green – Write enough code to make the test pass
  • Refactor – Clean up your code and your tests (don’t forget that your tests are code too)

This works well to enforce the three laws of TDD. And as Kent Beck said:

Make it work. Make it right. Make it fast.

If you want to know all about the cycles of TDD, here is an excellent article by Uncle Bob

Going to your favorite school…

And there are schools… well not physical ones:

  • The Detroit/Chicago School or the Classicist approach
  • And the London School or the Mockist approach.

The first one uses real objects/classes and it tests the state of those objects. The second tests collaboration between objects and for that it uses mocks.
You have this article by Sandro Mancuso and this other by Jonathan Rasmusson that can help you distinguish them better.

Knowing your friends…

As an iOS developer, I tend to be more of a mockist since I drive my tests from the UI. And developing an app in Swift has some challenging aspects since we don’t have a Mocking framework… We do it all “by hand”…So yes knowing very well what kind of test double you need is a good thing. People tend to call them all mocks but as Martin Fowler said here:

Mocks aren’t stubs

But if you still have doubts about test doubles, this excellent article by Uncle Bob will definitely shed a light on it… (and I even found a version for Swift here). Magical!

Setting your priorities

Yes, that’s a really important one: use the Transformation Priority Premise to avoid big steps and to guide you into the generalization of your code. As Uncle Bob said:

[…]Refactorings have counterparts called Transformations. Refactorings are simple operations that change the structure of code without changing its behavior. Transformations are simple operations that change the behavior of code.

Another good article is this one by Pedro Santos.
Don’t forget that during the refactor phase your design skills are put to test: as Sandro Mancuso said here:

TDD is not a design tool. It’s a software development workflow that prompts for code improvement in its lifecycle. […]
The great thing about TDD is that it is constantly asking us “Hey, can you make your code better? See how hard testing this class is becoming? OK, you made it work. Here’s your green bar. Now make it better.”

Having good habits

TDD must be approached like a discipline. You must have good habits to stick with it. Here is the TDD good habits manifesto. This came up for the first time in SoCraTes UK ‘16 in a form of a session facilitated by Mani Sarkar and Pedro Santos, where they challenged us to add or remove practices to their original draft that you can see here.


Well, it seems that I have a minimum knowledge about TDD. Still need to practice a lot, and apply what I have learned when coding. Here are some books that you could read:

Socrates UK


Just came back from SoCraTes UK, and it was amazing as always.
I’m looking at this blog post for 10m now, trying to explain what is SoCraTes UK and still don’t have the correct words… First of all, this is an Open Space Conference, which changes completely the ambient: people go there to share their knowledge not just to receive. And this sharing is what really matter in here…
Second I saw again some good friends that I’ve met before in other SoCraTes( You can check here at the end of the page, the other conferences).

As for the conference itself, I went to several talks about team management, feedback, empathy, and TDD… The second day was really hard, I was running from one place to another because all were amazingly interesting.
The first day I went to:

  • “Identifying signals for feedback loops” by Alastair Smith. A very interesting talk about how a project that had constant positive feedback was canned. We all try to identify where did this feedback fail. Some conclusions here

  • “How to change company structure to support Agile” – this was an interesting workshop where we started to naming all the practices related with Agile/Software Craftsmanship and then in a small group try to come up with ideas of how to convince our managers to accept then.

  • “Compare Craftsmanship and Fashion” by Alvaro Garcia. A really really interesting talk about how craftsmanship can compare with fashion… The main thing to retain is that as we ways wear underwear and just change our clothes as we go, the same happens with Software craftsmanship: our values are always there we just change the tools we use. Here are our thoughts

  • “Integration Design: 5 principles to craft better interfaces” by Giulia Mantuano. A very good talk about all the concerns we must have to give the user a better experience when he uses our products.

And that’s pretty much the first day…we had several lightning talks and after dinner a very entertaining time playing “The Professor”. There were a lot more activities and I had a really nice talk with Dominic Freeston about iOS and Swift.

The second day was a nightmare: all the talks in the market place were looking pretty much amazing and I just wanted to be able to clone myself so I could attend all of then… I really use the law of two feet this day!

  • “Smells (like team spirit) – Common team smells and how to refactor them” by Spike – As all the others, a very interesting talk about how to identify a team smell and how to deal with it in several situations…

  • “Sports and Development” by Houssam Fakih– Interesting point of view: training sports and training development skills.

  • “CQRS – Building an event system from scratch” by Emilien Pecoul– Workshop on CQRS in any language of your preference. Amazing! Here are some photos

  • “Small Small Talk talk and basic Visual Basic visual” by Daniel Irvine – The best title for a talk, and it was revealing to know that almost 20 years ago there was already a test framework.

  • “Empathy” by Antony Marcano and Ryan Alexander – Excellent workshop on how you can react in difficult situations in a team. “Good cop” and “Bad cop” examples. Superb!

  • “Refactoring Developers Habits” – by Mani Sarkar and Pedro Santos – Workshop about best practices in TDD. Here’s what we had to work on and here are some proposals.

We all came back to the main room for reflexions, retrospective and feedback. Still had time to more lightning talks. After dinner was time for me to leave…

Hope to see you all back again next year!

How katas can help you learn

Baton_long by Alain Delmas

In the last couple of weeks I have spent my time doing katas to improve my Objective-C. As you may remember, I had an issue, that you can revisit here.

I’ve learned a lot from other katas too: for instance the RomanNumerals kata… You’d may think it’s a simple task, that you wan’t learn much from. It’s a simple algorithm, a good exercise for your red -> green -> refactoring cycle. So nothing new will come from here… Wasn’t I wrong!!!!!

First I created some tests. Next I implemented the kata and refactored. Whilst I was refactoring, I decided to use NSDictionary to map from a decimal to a roman number. Here is an example:

That’s when I discovered that the NSDictionary does not guarantee insertion order. What???? So my keys were all mixed up… And I needed them to maintain their order!!!! That’s ok! I decided to create a class to map between decimals and romans. That’s cool! Done! In the converter I just added a private property of type NSMutableArray. In it’s constructor I added the class to the array for all elements I needed. But now I have to do:

for every entry in the mapper. God!!!! So much work! Maybe that’s why developers solve problems. They definitely don’t like to do things by hand so they automate everything.
So I decided that I could create a factory method. I really didn’t know how to create this factory method, so I just looked in Apple docs. Here is another thing i learned. Even thought I knew that it existed, I never used it because I never needed to. But as I was in learning mode, I think I was more interested in finding a different way to do it. When you are at a client, you don’t always have the opportunity to experiment with new things. Having this time to learn new ways of doing things is really rewarding. So here is my class:

It’s even more readable then the initialiser. And here is how I initialised it in my converter:

So my class was looking pretty but then I look at my test class…it wasn’t good:

So many tests. They remind me of the DRY principle. I really don’t like to repeat myself. It’s like a broken CD that doesn’t move from the same music track… I’ve done the same kata in C# and my test class was all parameterised and I really liked it. After all this is a simple kata, right? ;).

Well wouldn’t it be nice if I could have that in Objective-C? Well, after some help from Franzi I found a little library that does it. You install the pod, you inherit from it and you create an array of inputs and expected values like this:

And then you just have to use the properties input and expected. So my test class looks like this:

Here is my final solution: RomanNumerals.

So please don’t underestimate what you can learn from a kata. They are a good opportunity to stretch your knowledge and add some more to it!
image: Baton_long by Alain Delmas

Starting your TDD journey

The old story always comes around when talking about tests: it takes too long to do them and we loose a lot of time. Well, everything is hard to do if you are learning it. You need to practice and practice and practice to become proficient in any new skill.

Let’s imagine you want to start playing tennis.  What can you do to achieve your goal? You register in the tennis club near you and you start training. You go every week days. 4 days you practice with the machine that throws balls at you, and the other day you practice with a coach that shows you the technical skills you must develop to become a good tennis player.

So why not do the same when talking about developing a new skill as a developer? Why not start your day with a kata to enhance your TDD skills. Nowadays there is a lot of sites that provide small katas in several languages. There are a lot of then that have the solution so you can see how others have approached the same problem.

Going back to tennis, do you think that after a week you would be able to play against Rafa Nadal or Andy Murray?  And after 6 months? Probably only after 5 or 6 years you would be able to be at there level.  So why think that after a week of trying TDD you should be super efficient and be the best of it? Do you think that Uncle Bob or Sandro Mancuso were proficients in TDD after a week? After 6 months? If you want to be good at something you must practice. What better place that at work were you can beneficiate from having good tests that will improve your code and reduce your bugs?

So now  you can start your journey into TDD knowing what you should expect from yourself: hard work! If you google “kata” you will find a million links to kata sites, Github repositories, there’s a lot of examples in the net, so just put your hands on it.

There’s really no excuse to not do TDD. Well then you’ve got the skeptical one’s that don’t believe  that “wasting your time doing tests” will improve in any way your code or your way of thinking about your code.

If you really want to embrace TDD, and you feel you have a lot of resistance from your colleagues and manger, the best is look for a job in a company that looks at TDD as a fundamental tool for their developers to be great at their job. They are around. Not so many as you expected but the number is growing.