Forem: ⛩ Caio Zullo

Decomposing Swift code into modules – Intro to modular design

⛩ Caio Zullo — Wed, 21 Nov 2018 10:21:36 +0000

In this episode, we zoom out from the component level view of the system created previously and we showcase how to organize it into modules.

Learning Outcomes

Understand the representation of relationships of components and modules in a diagram
Understand how concrete or modular a system is from its diagram representation
Understand that every system needs to be tailored, rather than fit a predefined template
Understand that the process of abstracting needs to be applied incrementally

Description

We start things off by substituting the type names in the diagram with the name of the modules they belong to. For example, the FeedViewController can belong to a UI module, since it is responsible for rendering views and gathering user interactions, and the RemoteFeedLoader to an API module, as it is responsible for communicating with the network.

Moreover, we demonstrate various kinds of organization and modularity levels, and finally, we examine the case of the famous monolith, where all components belong to a single module and discuss possible tradeoffs.

Understanding the tradeoffs and risks that each design brings can be a tremendous asset while moving forward with the development of our systems. As developers and risk managers we shouldn’t be searching for one-to-rule-them-all kind of solution (it doesn’t exist); instead, we can tailor a solution based on the available resources and requirements.

Subscribe now to our Youtube channel and catch free new episodes every week.

We’ve been helping dedicated developers to get from low paying jobs to high tier roles – sometimes in a matter of weeks! To do so, we continuously run and share free market researches on how to improve your skills with Empathy, Integrity, and Economics in mind. If you want to step up in your career, access now our latest research for free.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

Composable Code Can Be Simple – Intro to dependency diagrams and composition

⛩ Caio Zullo — Wed, 14 Nov 2018 12:53:45 +0000

Watch on YouTube

In this episode, we continue exploring the dependency inversion principle and composition, while documenting our system's evolution in diagrams.

Learning outcomes

Understand basic depiction of dependencies, abstractions and concrete types in diagrams
Understand how diagrams translate into code and vice versa
Understand how the SOLID principles and composition are applied through the examples
Understand differences and similarities between closures and protocols as abstractions in Swift (unnamed type signatures vs. strictly named types)

Visualizing the dependency graph

Visualizing our code in diagrams can be a great framework to think while modeling the design of our systems. The early visualization of the design can make an excellent tool for communicating ideas to our colleagues and planning/coordinating a team effort. Diagrams can also help with independent development, as the team can quickly plan new features design (5-10 minutes on a whiteboard), build them in parallel and later integrate the pieces without conflicting with the work of other developers.

Moreover, diagrams serve as a great diagnostic tool as they embody the dependency graph of components and modules, revealing tight coupling and even retain cycles that could potentially lead to rigidity and memory leaks. Learning how to draw and read diagrams is an excellent addition in the skillset of developers that aim to create sustainable codebases.

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

Careful With “Singleton” Lookalikes (WAY TOO COMMON)

⛩ Caio Zullo — Fri, 09 Nov 2018 15:16:47 +0000

Watch on YouTube

Have you ever been told that Singleton is an anti-pattern?

Well, Singletons can be ok, but if you are not careful, they aren’t just an anti-pattern. THEY CAN BE DANGEROUS!

In this episode, we discuss the good and bad traits of the Singleton pattern, its common benefits and pitfalls, and showcase how dependency inversion can help us protect our systems in 4 simple steps.

We received the following question from a member of the community:

“I have been looking for a robust way to write a testable networking layer. And I am always confused about when and when not to use singletons. If you can answer these questions, I will be really grateful. Thank you for the video!”

What is a Singleton?

The Singleton pattern as described in the Design Patterns book (GOF) by Gamma, Johnson, Vlissides, and Helm is a way to make sure that a class has only one instance and it provides a single point of access to it. The pattern specifies that the class itself should be responsible for keeping track of its sole instance. It can further ensure that no other instance can be created by intercepting requests for creating new objects and provide a way to access the sole instance.

Moreover, to ensure that the class can't be instantiated from the outside world more than once, the singleton pattern prohibits the declaration of a visible to the module, initializer.

What is a singleton with a lowercase "s"?

A variation known as a singleton with a lowercase "s," constitutes a class that is being instantiated only one time in the whole lifecycle of the app, however, its API does not prohibit developers from creating a new instance of the class. The constraint is up to the developer's choice or discipline to instantiate it only once.

Some examples of such objects are Apple’s URLSession.shared and UserDefaults.standard. Although they offer a shared instance for accessing an immutable reference of themselves, they also allow their clients to instantiate them through their initializers.

Singletons vs. Global Mutable Shared State

Another important point when it comes to singleton objects is not to be confused with mutable global shared state. Mutable global state is usually accessed by a static sharedInstance of a class and allows the access and mutation of that reference (static var instead of static let). For example, a global mutable "Context" that provides access to various values and references such as Date, Networking and Database components.

Mutable global shared state can be risky but offers ease of use when it comes to accessing objects throughout the system and the easy configuration of the system environment (e.g., mocking the current time, locale, or network responses).

Examples of good Singleton candidates

So when should we use the singleton pattern?

When we need precisely one instance of a class, and it must be accessible to clients from a well-known access point.

For example, a class that logs messages to the console is a good candidate to do so, as the system may require access to it from any given point, plus we should only need its public API to log something, instead of re-creating and mutating its reference.

Moreover, if we need to extend the functionality of that class, then the singleton pattern allows us to subclass or create extensions on the class type.

Examples of bad Singleton candidates

The rule of thumb is to decide which objects should be created just once. Singleton objects should be rare in most systems and need to have a one-to-one relationship with the system. Meaning "it makes sense" or it’s mandatory for a system to have only one "instance of such type."

For example, Views are bad Singleton candidates as they should be able to allocate and deallocate memory on demand. The same holds for types of components such as Presenters, View Models, and Coordinators, for example.

Dependency Inversion

It's a common practice for libraries to use singleton objects instead of allowing us to instantiate internal classes to facilitate their use. Although this approach provides convenience for developers, it can create tight coupling in the system. A simple way to break the tight coupling and protect the rest of the system is to use dependency inversion instead of accessing the concrete singleton instance directly. By hiding the third-party dependency behind an interface that we own and we can extend (e.g., protocol/closure), we can keep the modules of our system free of knowing about the implementation details of another system. Such separation can protect our codebase from external library breaking changes.

As we showcase in the video, our modules can break the tight coupling and internal dependency of a shared instance, by injecting and inverting the dependency of the shared instance.

Conclusion

It's important to differentiate between bad and good Singletons.

By unnecessarily introducing Singletons (especially as implicit dependencies) we can increase coupling and risk, thus the probability of introducing regressions and making mistakes. It may be ok initially, but we need to be proactive and identify when it’s time to invert dependencies and decouple the modules.

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

“How do you think when writing tests?” – It’s simpler than you may think

⛩ Caio Zullo — Thu, 01 Nov 2018 14:25:05 +0000

Watch on YouTube

In this episode, we reply to an important question raised by a member of our community.

Question

“I'm trying to understand how you think when writing tests. Do you just try to cover everything that comes to mind or you have some kind of list with priorities? Or you just try to reach max possible coverage?”

Answer

We follow the basics. Our main process is to write the test first, see the test fail (red), then write the minimum amount of code to make the test pass (green), then refactor the code/test *if needed.* By following this process, we end up with pretty high coverage (not always 100% but very close to it). The coverage is not a direct goal. The coverage is more like a positive side effect of following the process.

With that said, it requires discipline and skill to *always* write the test first. You may get stuck in the beginning. We've been doing this for many years, and we still get stuck sometimes! However, the goal is never to be stuck for long. It's wasteful. At the end of the day, shipping is more important than testing first.

When you're stuck, spike some ideas. Go free, without tests (or anything else) in your way. Play with the code (Xcode Playgrounds, Swift REPL, Debugging...) until you're unstuck and found the solution you are happy with. Then think, "now that I know what I want to build, how could I have written the test first?"

When you have the answer, you can discard the spiked solution (commit the spike solution into a separate spike branch), and start fresh, by writing the test first. Next time you have to solve a similar problem, you know how to do it test-first without spiking.

We practice, learn, and get a little bit better every day. The daily practice compounds!

Subscribe now to our Youtube channel and catch free new episodes every week.

What’s More Essential for Developers to Focus On: Result or Process?

⛩ Caio Zullo — Thu, 25 Oct 2018 12:10:11 +0000

Watch on YouTube

In this video, I'd like to ask you an important question, but before that let me tell you what we believe to be one of the best skills a software developer can master: Long-term vision.

It might sound obvious, but in our experience, most developers focus on short-term gains in the endless pursuit of Silver Bullets and Magic Solutions, when the fastest route is usually patience.

Why is the long-term so important? Most results in our life/career are asynchronous (good results take time) or are even out of our control. Instead of trying to control the result, we can visualize what the result can be (the long-term vision) but focus on the process to get there. Even better, be flexible and welcome changes along the way!

For example, Test Driven Development is a discipline that can give you control over the development process. For TDD to work, it's required consistency. Consistency is the key. Consistency is the focus on the process. TDD is just an example, you can choose your own preferred process. But follow the process. Every day.

Now, the important question I want to ask you: Right now, do you focus more on the result or the process to get there?

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

iOS Interview Experience: Why You Didn't Pass the iOS Technical Test

⛩ Caio Zullo — Mon, 22 Oct 2018 11:28:07 +0000

At Essential Developer, we help many developers go through the iOS Interview Experience. Recently, we got this message from one of the members of our community:

“Hello Caio. I have recently had a job interview with a tech test, which I completed in two days and got rejected.

The story goes: I got a message from a successful search/indexing company willing to have an iOS interview with me. I had a 30 min conversation with an iOS developer from the company. I don’t know what level they are looking for. I said to him that I am at a mid-junior level in my opinion. He said they were going to send me a tech test to see how I organize code, objects, what architecture I use (they mentioned VIPER), design patterns, testing approaches, TDD, XP, etc.

I tried following TDD for the test, but not entirely. They replied with: "I appreciate the time you took and your interest in our company. Unfortunately, on this occasion, we have decided not to progress your application further. I really enjoyed talking to you, and I wish you success with your current job search.“

That’s it. I don’t know what’s wrong with my project . Can I send you the test description and my little project to hear your opinion on how good or how bad it is ?”

Most companies do not give full details of their decisions, and that’s fine. It’s their choice. As a job candidate after an iOS Interview Experience like that, it’s common to blame our technical skills first. Notice the “how bad is it?” question. Such negative look of the events can discourage developers from further pursuing their dream job. Maybe it has nothing to do with the candidate’s skills. So it’s important to remember that there are many factors out of our control. However, for this blog post let’s focus and assume the motives for the rejection were solely technical.

The tech test

Given a text file:

Write an application that outputs the individual words (ignore punctuation and capitalization) that appear in the text file, and how many times that word appears in the text file.
Output whether the number of times each word appears is a prime number.

The test is intended to show your skills on Problem-solving, TDD, OO, Architecture, Code Quality, and Performance. Bonus if you can come up with more than one solution and explain the pros/cons.

Research What the Company is Looking For

As a job candidate, before going through an iOS Interview Experience and the tech test, it’s essential to do a bit of research on the company. So, before having a look at the candidate test project, I did a bit of research on the company. By looking at the company’s website, I quickly noticed how proud they are about their fast, efficient, scalable, reliable, great, first-class, successful, and state of the art platform. It looks like they perform several web scrapings a day and serve several clients through their APIs. In short, scalability, performance, and correctness of data are vital to the company. Also, from the conversation and the tech test description, the company looks very keen on TDD, OO, Clean Code, and Architecture.

Fulfill the iOS Test Requirements

From a quick look, the project looked good overall. The project was well organized, the classes were small and the code was readable. The candidate really proved he can make an app from scratch and I would gladly offer him a junior/mid-level position. The candidate even made an extra effort to build a very nice user interface and added a great feature to enable importing files from a URL. However, there are some areas where I believe the candidate could have focused more to fulfill the test requirements of this iOS Interview Experience.

The code was organized and readable, but it seemed not to handle errors accordingly. It might be ok for a tech test to assume input is always valid, but going the extra mile to handle error cases can help you show great programming skills.

Pay Attention to Detail

There were common anti-patterns to avoid like primitive obsession, leaky abstractions, refused bequest, unused code, and unnecessary/redundant comments. All of which can be acceptable for junior developers, but might be red flags for the interviewer.

The code was not under version control. We suggest you always use git for your tech tests. And send it over to the interviewer. Many teams will look at the history to understand how you got to the end solution. It’s in your favor, so don’t hide this from them!

The test coverage was not throughout enough. The candidate is conscious that he couldn’t follow TDD completely, but he showed a great effort. Candidates with TDD experience are hard to find. The company could have made a choice of investing in a candidate that showed aptitude, but it’s up to them. (Tip: If you want to increase your value as a developer, TDD skills are valuable and scarce. Companies are continually looking for experienced candidates!)

The candidate followed the MVC design pattern. MVC is fine, but the company was very keen on VIPER. Maybe investing a bit of time making it more like VIPER could have won the candidate some extra points.

Always Implement Bonus Challenges

When trying to pass a tech test, it can be essential to tune your skills to impress the interviewer during the iOS Interview Experience. Taking the time to implement different solutions is an excellent way of doing so. The company even requested it as a bonus, but the candidate provided only one solution. The solution provided would not scale well and would not be performant with larger amounts of data. Nothing wrong with that, it is still a valid solution. However, the candidate could have invested that time to provide different approaches and explain their pros and cons. Especially because when running at scale, the cost of a lousy implementation can quickly jump up to 7 digits. Being a mid-level developer is no excuse here. A bit of research and googling around could have helped the candidate provide different solutions.

Explain Your Solution

Reviewing code is very subjective. A pairing session is much better to communicate intent, but not every company would invest the time in the first stage of the iOS interview experience. Taking the time to write down some notes, draw some diagrams, and even recording a video explaining your decisions can be a great way to engage with the interviewer at this stage. Using git can also be a great way to show the progression from start to end. Small and meaning git commits can make a big difference.

Deliver the Test in a Reasonable Time

The candidate took two days to complete the test, which could have been a red flag. The requirements were not complicated. However, from what I gathered, there was no agreed deadline to send the test. Also, the candidate made it clear he was not working on it full-time. The real red flag is that a lot of the time was spent on the UI and the extra unrequested feature, instead of the bonus challenge. For the test reviewer, it could have been taken as “this candidate might have a hard time following requirements.” In Lean and Agile teams, it’s important to eliminate waste, such as over-engineering/complicating implementations (YAGNI!). Of course, that can be a wrong assumption about the candidate, but how we present ourselves in the iOS interview and tech test can help eliminate those assumptions.

Always negotiate a deadline. If you work full-time and don’t have much time to work on the tech test, let the interviewer know and negotiate a reasonable delivery date that makes sense to you. The company shouldn’t expect you to stop your life to finish the test, but showing some energy and effort can help you show interest in the job.

iOS Interview Experience Conclusion

It's important to remember that from this point we're just wondering/assuming what could have gone right/wrong.

I believe the candidate is a great developer and that he should be motivated to learn from the experience and try again. Practice makes perfect!

We wish all candidates good luck in their future iOS Interview Experience and we hope this article gave you enough tips to help you succeed.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

The Minimum You Should Do To Prevent Memory Leaks in Swift

⛩ Caio Zullo — Thu, 18 Oct 2018 10:38:44 +0000

Watch on YouTube

In this episode, we continue the Clean Swift Tests discussion, and we demonstrate a way for preventing memory leaks through automated testing.

There's a large class of bugs, security threats and user experience problems (e.g. crashes and high memory consumption) related to memory leaks. Although this is an important topic, why do the majority of apps (Apple included) fail to prevent memory leaks?

Answer: many developers rely on error-prone manual checks.

Manual checks might seem like a good fit in early stages. However, the codebase expands, requirements change, new developers join the team, pressure builds up, and deadlines approach. Under those stressful conditions, the manual checks have a high probability of failure due to human error. Moreover, the number of possible combination checks are too many, and they grow exponentially, which makes it humanly impossible to check all logical branches. Can we avoid such a scenario?

Answer: yes, with good architecture and automated tests!

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

XCTest + Swift: SetUp/TearDown vs Factory Methods

⛩ Caio Zullo — Wed, 10 Oct 2018 15:04:58 +0000

Watch on YouTube

In this episode, we dive into XCTestCase’s lifecycle and show different ways for configuring your system under test.

XCTest, similarly to JUnit, invokes each test method on a separate instance of the test case. To illustrate with an example, imagine that you have ten test methods, the XCTest framework will instantiate ten instances of the test case class and invoke only one of the methods per instance. We believe this is a good design choice, as by running the test methods in separate instances we can avoid sharing state between tests. However, XCTestCase’s behavior isn’t that obvious which can make it counterintuitive when compared with how we're used to using objects to share state between methods.

Swift Factory methods

Although the setUp/tearDown configuration method is valid, at Essential Developer we noticed that moving configuration code to factory methods would yield better results in most cases.

Here are the main reasons why we prefer factory methods over the setUp/tearDown configuration:

Many tests have a different setup/configuration, so there are no significant benefits in sharing the object instantiation.
We normally use constructor injection. If we create a class as a property in the class scope, we would have to use property injection to be able to configure the instance for each test. Which is fine too, but we prefer constructor injection since most of our classes don’t allow mutability.
We want to test the whole lifecycle of the system under test instance, to guarantee there are no issues when it's removed from memory. We could achieve this with the setUp() approach, but to test the whole lifecycle we would also need to set it to nil in the tearDown(). By creating the instance in the test method scope, we guarantee its lifecycle is tested within the method (since the instance will be freed automatically).
It would take more lines of code to do the same thing and, in our opinion, it would negatively impact the design of the test and the production code (e.g., constructor->property injection).
setUp/tearDown can make the tests harder to read/understand since, when reading the code, we would have to scroll/jump scope (from test method to setUp/tearDown code) to understand the whole context. We prefer to keep our test setup (Given/When/Then or Arrange/Act/Assert) in the shortest scope possible.

When we use XCTestCase setUp/tearDown in Swift

To be clear, we avoid setUp/tearDown configuration because we believe there are better ways, but we do use it when it's useful to us.

For example, setUp/tearDown can be useful when dealing with global state (e.g., databases) that needs to be restated for each test (as we don't want to pollute the test methods with those details).

Conclusion

We would like you to be proactive and think about the problems you're facing so you find the best solution for you. For example, our approach could be wrong for you, so be critical and let us know your preferred way.

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

iOS Interview Experience – 7 Essential Nontechnical Skills

⛩ Caio Zullo — Tue, 02 Oct 2018 12:14:48 +0000

Watch on YouTube

Have you ever had an iOS interview experience, never heard back and wondered what went wrong? In this article, we’d like to share some reasons why that might have happened.

For at least 7 years in a row, I’ve been an active part of the dev recruitment process in every company I work with. At the same time, I’ve been helping developers build up their technical and nontechnical skills to stand out in the job market. A typical reaction I noticed when developers don’t get the job is to ask “what’s wrong with my technical skills?” “Did I do something wrong in my coding test?” What they don’t know is that a lot of times, the nontechnical skills can be as critical as the technical ones.

iOS Interview: What are nontechnical skills?

Nontechnical or as also called “soft skills,” usually refers to a collection of social skills that can help the individual to interact effectively with others. In a professional environment, soft skills can relate to how one build and foster relationships with colleagues and customers, resolve conflicts, take responsibility, solve problems, and more.

After a rejection in an iOS Interview, I usually recommend developers to evaluate not just their technical skills, but also their soft skills. Here is a list of 7 soft skills employers are looking for, and you might need to improve:

1. Communication

Good communicators can:

Clearly and comprehensively pass their message
Comprehend and act efficiently on instructions
Explain complex issues in simple terms
Mediate meetings and conflicts
Be good leaders
Be good listeners

2. Teamwork

Good team players can:

Work together towards a common goal
Hold each other accountable
Provide honest and empathetic feedback
Help underperforming members step up to the team standards
Incentivize team collaboration
Be proud of collectively decisions and outcomes
Know when to be a leader
Know when to be a follower

3. Leadership

Good leaders can:

Build trust to achieve a prosperous collaboration inside (within the team) and outside (within the business)
Build a fearless environment where everyone contributes with ideas
Help the team members be focused on shared goals and priorities
Incentivize collaboration within the team
Enable the members to tackle and deal with controversial matters
Never resort to the “I’m the lead so do what I say” card

4. Responsibility

Professionals that hold themselves accountable can:

Accept responsibility for mistakes
Respect, comply and encourage high-quality standards
Be focused on continuous progress
Be humble
Be a constant learner
Strive to not to let other team members down

5. Conflict resolution

Good leaders can:

Find solutions that can benefit all parties
Establish a harmonious relationship with peers and clients
Seek commitment to decisions from all members, instead of consensus
Respectfully exerts influence
Tackle and deal with controversial matters
Respectfully address people’s misbehavior
Make everyone’s opinions heard and valued

6. Time management

Disciplined professionals can:

Get things done effectively
Simplify tasks
Clarify priorities
Limit work in progress
Estimate better
Think clearly under pressure
Delegate
Outperform and over deliver

7. Flexibility

Flexible professionals can:

Quickly respond to change (e.g. goals, expectations, resources)
Find creative to perform tasks more efficiently
Find ways to improve work/life balance in the team (e.g. flexible hours/work from home on snow days)
Help others and never say “That’s not my job.”
Cover for others on vacation or sick leave
Learn from constructive criticism

Why we should care

A healthy work environment depends on soft skills. In iOS Interviews, they not only search for technically talented developers but individuals that the team would be happy to work with.

Soft skills are valuable and scarce. Developers that build their soft skills will have a substantial advantage and in the job market. Also, soft skills can be essential to function and thrive in high-performance software teams.

Junior developers can benefit and accelerate their growth by building their soft skills early in their career. Mid-level to senior developers should be able to display good soft skills.

As the professional gets more experience, those soft skills are expected to improve as well. So, for example, it’s not uncommon to see senior developers applying to lead roles and getting rejected. Even though senior developers may have a strong technical background, they may not have other essential skills like good communication, teamwork, and leadership.

Bonus reasons (Out of our control)

Sometimes we prepared accordingly, had our technical and soft skills sharp, did everything right, but still didn’t hear back. When I’m on the interviewer side, I usually like to give feedback to all candidates. I don’t want to leave people “wondering,” and it doesn’t hurt to help them realize areas they can improve. Not every interviewer follow this principle, and there’s nothing wrong with that.

Many other factors are out of our control. For example, they could have already hired another strong candidate, the budget for the role was suddenly not available anymore, we were overqualified (yes, that’s a real thing!).

It’s essential to be resilient against things out of our control on an iOS Interview. To endure and accelerate our career path, we should focus our energy on what we can control.

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

Migrating to Swift 4.2 using a TDD + Git workflow [S01 Extras]

⛩ Caio Zullo — Tue, 25 Sep 2018 12:08:24 +0000

Watch on YouTube

In this episode, we migrate the Quiz project and its dependencies to Swift 4.2 and modernize our code with the newest additions.

Just like in the Swift 4 and Swift 4.1 migration episodes, we migrate each module independently, while making sure that all tests are passing at every step and that we end up with no build warnings.

One delightful change that Swift 4.2 brings is the improved ability of the compiler to synthesize an implementation of the Hashable protocol. We take advantage of this change and, by following our standard workflow combining Git and Automated Tests, we remove our custom implementation of hashValue we wrote for the Question type in Episode 13 - Improving the Game Flow with Swift Generics.

During the Hashable refactoring, we are surprised by some of the tests breaking. We resist the urge of deleting the tests by following a highly disciplined approach to solving the problem.

It’s important to notice that without a test suite we trust, it can be much harder to do such changes with confidence.

Finally, we take advantage of the new Sequence.shuffled function that Swift 4.2 offers. We use Sequence.shuffled to showcase how to test randomness by using probability rather than mocking. By not relying on mocking, we can freely change the implementation of our code without breaking any of the tests.

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

#1 Reason Why You Don’t Improve As a Software Developer

⛩ Caio Zullo — Wed, 19 Sep 2018 11:25:46 +0000

Watch on YouTube

In this video, we are going to discuss the main reason why we set goals to improve but sometimes cannot achieve them.

There’s a common trend that we all go through. It’s one of the oldest problems people face and, as part of our evolution, it’s deeply wired in our brains. The problem is: we want something, but we don’t want to do what it takes. We procrastinate and avoid doing the work at all costs. In other words, we want to avoid the uncomfortable.

The Plateau

Our learning curve looks typically like this:

We want to learn something new, and we may even think we know what we need (or What We Know We Don’t Know). All of us go through this initial phase with ups and downs until we hit a roadblock or a plateau. It feels like we stopped progressing.

When we hit a plateau, it doesn’t mean we’re doing something wrong, but often it’s a sign we need to do something different. Progress often doesn’t come from doing the same thing that generates the same mediocre results. A roadblock usually means we should go back to basics and reevaluate if we really got it right. That’s one of the most critical steps to improve. We probably have some misconceptions that need to be adjusted.

The problem is that we might not even know we really need. We call this gap “What We Don’t Know We Don’t Know.”

To make matters worse, we usually expect continuous growth. Always going up. Continuous growth is, most of the times, an “Unrealistic expectation.”

We often hear people say that: "Developers don't follow good practices because they don't know them or don't understand their value." and we believe that’s a fallacy.

The more we teach, meet, and collaborate with developers, the more we see that many developers already know what they should do to improve. Many developers know which skills will get them to the next level. They don’t need to “gather more information” – they need to choose a path, act and stay in the path with discipline and focus.

The Comfort Zone (The 99%)

Fear of the plateau and avoiding the “adjustment phase” plus unrealistic expectations create a false perception of progress. The false sense of progress is also called the “comfort zone.”

The comfort zone prevents us from achieving what we really want or even worse, it may create limiting beliefs. We often hear developers say “I really tried X/Y/Z, but I just can’t do it.” Which is limiting and not true. Everyone can do it.

As you can see in the graph, the red line shows the common path 99% of the people take. The comfort zone. And it’s often far from what we really need. And the times where growth seems to go down, are probably times where we try something new–trying to improve. When we try something, it’s natural that performance can go down. The problem is that mostly we seek the “Unrealistic Expectation of Continuous Growth,” and we go back to what we know (the comfortable). We give up too quickly.

And to be fair, there’s nothing wrong in staying in the 99% or the comfort zone. Most people can have a decent living in this zone. However, we often find individuals unhappy with their performance, and they want to improve.

The high-performance individuals (The 1%)

When learning to ride a bike, for example, we are probably going to move slower than we would if we just walked. One may say “walking is faster and easier than riding this bike, why would I waste more time trying to balance in this very uncomfortable mode of transportation?” The same happens when we’re learning advanced software development topics, collaboration skills, leadership, software architecture, automated testing, etc.

A more realistic approach of high-performance individuals looks similar to the green line in the graph below.

It starts similar to the others, but growth goes down as these individuals understand that to ride a bike properly, they need to take the supporting wheels off, fall a couple of times, and practice until they learn. They had to slow down at first, but, as they learn to ride the bike, they will be able to move much faster in the future.

Our brain is wired mostly to survive, not to go through the uncomfortable phase.

And most of the time we know what we have to do to improve. We know the skills we need. We attend courses. We read books. We even practice it for a while. But we don't have the discipline or focus to keep doing “what we know we should be doing.” So, it doesn't matter what we know. It matters what we do with what we know.

Mentors

When learning how to ride a bike, it may seem like an impossible task at first. And incredibly enough most people learn how to ride the bike. Why? A big reason is that there’s usually a person we trust pushing and helping us go through the fear (the uncomfortable phase). That’s why it’s so important to find mentors we trust. Mentors that have achieved what we want and that can guide us through the tough phases to achieve the “impossible.” However, mentors can’t do the work for us. We have to do it.

It’s not our fault that our brain is wired to avoid uncomfortable situations, but it’s our responsibility to do something about it. ⛩

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

Clean iOS Architecture pt.7: VIP (Clean Swift) – Design Pattern or Architecture?

⛩ Caio Zullo — Tue, 11 Sep 2018 12:08:12 +0000

Watch on YouTube

Today we're going to analyze the VIP (Clean Swift) Architecture. And, as we did in previous videos with VIPER, MVC, MVVM, and MVP, we will decide if we can call VIP a Software Architecture or a Design Pattern.

The Clean Swift Architecture or, as also called, "VIP" was introduced to the world by clean-swift.com and, just like VIPER and other patterns, the main goals for the architecture were Testability and to fix the Massive View Controller problem.

The name VIP can be confused with VIPER, and interestingly enough the creators of VIPER almost called it VIP but decided to drop the name because it could stand for “Very Important Architecture,” which VIPER creators thought it was derogatory.

VIP is very similar to VIPER as both originated from Uncle Bob's Clean Architecture ideas.

So can we consider VIP a Software Architecture or just a Design Pattern?

The VIP diagram describes its main structure, which explains its acronym definition: the ViewController/Interactor/Presenter relationship, or as they call it: The VIP cycle.

The unidirectional VIP cycle.

The VIP cycle differs from the VIPER relationship model described in our previous video. In VIPER, the communication between Interactor and Presenter, and View and Presenter is bidirectional.

The bidirectional VIPER cycle.

Instead, VIP follows a unidirectional approach, where the ViewController talks to the Interactor, the Interactor runs business logic with its collaborators and passes the output to the Presenter, and the Presenter formats the Interactor output and gives the response (or view model) to the ViewController, so it can render its Views.

Does this unidirectional communication model define an architecture? Also, are those 3 components (the ViewController, Interactor, and Presenter) enough to describe the Application Architecture?

It may seem like an architecture, but the VIP cycle is such a limited outlook of the application that we consider it a Design Pattern. And this design pattern has a name already: MVP. Regardless of what we call it, the MVP design pattern is not a software architecture.

However, VIP or "Clean Swift" has more components than just ViewControllers, Interactors, and Presenters, for example, Data Models, Routers and Workers.

Like VIPER, the Clean Swift author describes that VIP can have less or even more layers of separation, as needed. But the core must follow MVP or the VIP cycle! So the VIP cycle sounds more like an organizational design pattern that can solve the Massive View Controller problem and make your code more testable, but it doesn't describe the big picture or the “Software Architecture.”

VIP or Clean Swift, just like VIPER and other patterns, is trying to solve class dependency issues like the Massive View Controller and testability, rather than module dependency issues, like modularity. With the described Clean Swift components, we may end up with testable code but Spaghetti Architecture.

VIP also encourages the use of templates to "facilitate" its implementation. It can be very convenient to have templates, but, at the same time, it may create a limited framework to think. We don't believe there's a design pattern or "template" that can solve all the problems and can be infinitely extended. We believe that, instead of trying to fit every problem into a template, every software architecture must be carefully crafted to solve the system challenges. For example, some systems would benefit more from an Event-Driven (Producer/Consumer) streaming model where other systems would not.

Let's have a look at the Clean Swift sample project (CleanStore) dependencies diagram.

CleanStore sample project class and module dependencies diagram.

As you can see, there are arrows everywhere, crossing module boundaries, so changes to the software can break multiple modules (and of course, numerous tests...).

In the Clean Swift sample app, the application is separated in scenes (or modules). There’s a List Orders Scene, Create Order Scene and Show Order Scene. A higher level look at the modules dependencies shows that scenes are highly coupled with each other and with other system’s components.

High-level modules dependencies diagram shows a highly coupled architecture.

Another way to look at the application architecture is to examine its modules in a circular form so we can see the dependencies between the modules. The closer to the center, the more abstract and independent the module is.

High-level modules dependencies diagram shows a highly coupled, monolithic architecture.

Different than Uncle Bob’s Clean Architecture, we can see services, frameworks, and drivers in the core rings. Also, inside each scene, some Interactors might contain business logic, and they depend on frameworks and other services. Throughout the codebase, we can even notice that core models are used in all levels of abstraction (UI/Presentation/Business Logic/Routing/Services/Workers) which is a no-no in Uncle Bob’s Clean Architecture.

The VIP sample app architecture is a highly coupled and monolithic architecture. If we want to create a somewhat testable monolith, it might work well. However, we might quickly find out that the lack of modularity prevents us from scaling the team, moving fast and prevents us from achieving key business metrics. For example:

Deployment Frequency
Estimation Accuracy
Lead Time for Changes
Mean Time to Recover

As explained in the previous video, we believe that software architecture is less about types, classes, and even responsibilities and more about how the components communicate to each other, how they depend on each other, and what is the shared understanding of the senior developers regarding: What are the important parts? What is coupled? What is decoupled? What is hard to change, What is easy to change? How is the data flowing between layers and why – is the data going in one direction? Two directions? Multiple directions? Can we support the business short and long-term goals?

We would like to reinforce that our codebases are like living organisms and they're changing all the time. So does the architecture. It's continually evolving, and there are no templates for that.

At Essential Developer, we do believe software architecture has a strong correlation with Product Success, Product Longevity, and Product Sustainability. We advise professional developers to learn from Uncle Bob's Clean Architecture, VIP, VIPER, MVC, MVVM, MVP, and other patterns, but not try to copy and paste solutions. Remember: Every challenge is different, and there are no silver bullets.

VIP, VIPER, MVC, MVVM, MVP, as design patterns, can guide you towards more structured components. However, they don't define the big picture or the Software Architecture. So, use them with care!

For more, visit the Clean iOS Architecture Playlist.

Subscribe now to our Youtube channel and catch free new episodes every week.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.