Introducing Clean Swift Architecture (VIP)
A couple of years ago, all of the iOS apps were small containing less than 10 screens. The codebase was small, storyboards were working excellent, and it was easy to maintain your project. From an architectural point of view, MVC was doing a great job. How about today? Today, we are facing big technological advancements and an insane app market growth. In other words, apps are becoming big and complex. We are working on projects that contain 20, 30 or even 40 screens making it impossible to be maintained with MVC. As technology moves forward, so should we (developers). Recently, I really got tired from MVC and started looking for a new architecture. After a short research, I have noticed the Clean Swift architecture and instantly fell in love with it! This architecture was exactly what I was looking for. About the Clean Swift Architecture Clean Swift (a.k.a VIP) is Uncle Bob’s Clean Architecture applied to iOS and Mac projects. The Clean Swift Architecture is not a framework. It is a set of Xcode templates to generate the Clean Architecture components for you. That means you have the freedom to modify the templates to suit your needs. In an MVC project, your code is organized around and grouped by models, views, and controllers. In Clean Swift, your project structure is built around scenes (or screens). Here is an example how does one scene looks like. In other words, we will have a set of components for each scene that will “work” for our controller. These are the components: Models Router Worker Interactor Presenter Configurator Communication The communication between the components is done with protocols. Each component will contain Input and Output protocols which will be used for receiving and passing data between them. Worker communicates with Interactor, then Interactor with Presenter and Presenter with ViewController. I have also designed a Flow Diagram so you can get a visual representation of the relations between these components. Clean Swift (VIP) Flow Diagram Models We will store all the models related to the controller. The Models class will be related to each component, as you can see in the Flow Diagram. It will be of type struct and mostly it will contain Request, Response, and ViewModel structs. import UIKit struct TestModel{ struct Fetch { struct Request { var itemId = 0 var keyword: String? var count: String? } struct Response { var testObj: Test? var isError: Bool var message:
Swift 4 – Top 3 new String API features
With each release, Apple makes us love Swift more and more. But, it wasn’t always like that. For me personally, Swift 3 felt to be the first official Swift release, and not the versions 1 and 2. They felt more like beta releases of the language. Now we get Swift 4 which is an upgrade of Swift 3 and not a complete revamp of the language like in the previous versions. It comes with the new Xcode 9. After playing around with Swift 4, I have decided to dedicate a story which will focus on the new exciting String API. About Swift 4 Swift 4 builds on the strengths of Swift 3, delivering greater robustness and stability, providing source code compatibility with Swift 3, making improvements to the standard library, and adding features like smart key paths and serialization, all while shortening build times and reducing the size of app binaries. String API String is one of the most used classes in Swift, so finally, it received a lot of well-deserved love. The new API contains a lot of changes, but I will focus only on the best ones. #3 Multi-Line String Literals It will make you forget about adding new lines with inline \n on a long string and make your strings looking dirty and hard to read. This is one of the many examples how multi-line strings literals can be helpful. Let’s compare the current and the new string multi-line approach by adding an example string into print()… Swift 3 print("\nExample:\n- first line\n- second line\n- third line") Swift 4 print("""Example: - first line - second line - third line""") Probably you can spot the difference and how clean the new multi-line string is. In order to use multi-line string literals, you will need to use “”” to determine the base indentation of the string. #2 Collections Strings are collections once again. It was introduced first in Swift 1 but was removed later in Swift 2. The string is now treated as a collection of characters and we can perform various operations on them (iteration, filter etc.). Iterate directly over String let str = "Awesome String" for char in str{ print(char) } Use filter on String let str = "Awesome String" let filteredString = string.filter { $0 != "a" } #1 Substring Type Swift 4 adds a new type used for referencing a subsequence on String, called Substring. They are both
Speed up Swift compile time
Nothing is perfect Swift has become one of the greatest modern programming languages, but as everything else, it has its own issues. When working on large-scale projects, you can notice an issue where Swift compile time is growing. And it’s a real frustration and waste of time. I have witnessed compile times up to 5–6 mins, but there are examples that show it can grow a lot more than that. In those moments, Xcode reminds me of Android Studio in the earlier days. 🐢🐢🐢🐢 Wasting an hour or two daily in Swift compile time is a lot of unproductive time. That’s why we must optimize Xcode and the way we code. I will show some of the things that decreased the Swift compile time dramatically, so you can try it out and tell me if they have helped you. It’s optimization time! An Awesome Tool Let’s start by installing this awesome open source tool, called Build Time Analyzer for Xcode. Install this tool by following the instructions provided on the GitHub link, and then run your project. It will analyze your code, and tell you which parts of your code take the most time to compile. It will be much easier to optimize the code with this tool, so don’t skip this step. Before going to the code, let’s check some optimization tips that we can try on the IDE. Tweak the Optimization Level — navigate to Build Settings -> Optimization Level and make sure that Debug is set to None. Next, go to Build Settings -> User-Defined and add SWIFT_WHOLE_MODULE_OPTIMIZATION = YES. From my experience, this flag always tackles a big part of the compiling time. Remove dSYM file from Debug— dSYM(debug symbols file) is a file which takes debugging information and stores it in a dSYM Bundle. This file is generated each time you compile your project. However, you don’t need this in Debug so change the value to DWARF, and leave it active only for the Release mode. You can locate Debug Information Format setting under Build Settings. Check your Build Active Architecture Only values — for all the non-release builds set Build Active Architecture Only to YES. This will prevent Xcode to compile files twice. You can locate Build Active Architecture Only setting under Build Settings. Empty your Derived Data — if you have any kind of problems with building the project, you should start from here. Go to File -> Project Settings and click
Implementing the DistBelief Deep Neural Network Training Framework with Akka
Presently, most deep neural networks are trained using GPUs due to the enormous number of parallel computations that they can perform. Without the speed-ups provided by GPUs, deep neural netwroks could take days or even weeks to train on a single machine. However, using GPUs can be prohitive for several reasons GPUs are expensive, both to buy and to rent. Most GPUs can only hold a relatively small amount of data in memory. CPU-to-GPU data transfer is very slow. Depending on your application it can be so slow that it actually negates the speed-up that the GPU provides. The CUDA GPU programming library is written in low-level C which many programmers are not experienced with (however there are many deep learning libraries written in high level languages with GPU capabilities e.g. Theano, Torch, Caffe, etc.). DistBelief is a framework for training deep neural networks that avoids GPUs entirely (for the above reasons) and instead performs parallel computing with clusters of commodity machines. DistBelief was first presented in the 2012 paper "Large Scale Distributed Deep Networks" by Dean et al. In this paper, the GraphLab distributed computing framework was used to implement DistBelief. As we shall see later in this post, DistBelief relies heavily on asynchronous message passing which makes the Akka actor framework a suitable alternative. This post will describe how to implement the DistBelief framework using Akka (all code is in this github repo). This post will be divided into five sections A brief overview of how neural networks are trained using the backpropagation algorithm. A brief overview of how Akka handles asynchronous message passing. How the DistBelief framework trains deep neural networks using the distributed, asynchronous Downpour SGD algorithm. How Downpour SGD can be implemented using Akka. Finally, a demo applying DistBelief to the classic XOR function problem. Let's get started! 1. The Backpropagation Algorithm This section is only meant to be a brief overview of the backpropagation algorithm (there are a multitude of online resources available if you want to learn more). Consider the following 3-layer neural network. The 3 layers are called the input layer, the hidden layer and the output layer. Each layer consists of a number of nodes that are called neural units. Each neural unit in the input layer is connected to every neural unit in the hidden layer via a weight (these are illustrated by the arrows in the above diagram). The neural units in the input layer correspond to the elements of the input vector for a given training example. The input to a neural unit in the hidden layer is the weighted sum of its inputs coming from
