InRhythm

Your partners in accelerated digital transformation

InRhythmU

SwiftPM – The Swift Package Manager

Swift Package Manager

Introduction

The Swift Package Manager (SwiftPM) is Apple’s tool for managing package dependencies for Swift application development. SwiftPM has been an integrated part of Swift since v3.0.

So, what are Packages? Packages contain reusable code or other resources stored in repositories that your application needs to provide a feature or function. Some examples include, but are not limited to, the fonts and color scheme for your app, a library that provides access to a web resource, a file with images required by your application. Other examples are the APIs and Frameworks that add functionality to your app and simplify your coding tasks.

This post will provide a high-level overview of basic SwiftPM usage and features.

What do Package Managers bring to the Table?

Package Managers give developers a way to control which packages and which versions of those packages that the project will consume.

Other features include:

  • Allows easy use of light-weight, reusable libraries
  • Reduces code duplication
  • Supports development best practices by simplifying and supporting modular coding (easy module/package creation)

While it is possible to manually manage dependencies in a project, it isn’t practical for anything but the smallest of applications. Best practices fall on the side of using a package manager to handle this function automatically.

SwiftPM supports Swift 3+ and XCode 8+. Since Swift 5 and Xcode 11, SwiftPM has had cross-platform support for iOS, macOS, and tvOS.

Are there SwiftPM Alternatives?

There are two mainstream alternatives, CocoaPods and Carthage. Both are third-party tools requiring installation and much configuration before use.

CocoaPods

CocoaPods (2011) – Supports Swift 5+ and Xcode 3.11+ – Mature and stable. A centralized, easy-to-use command-line tool for package dependency management and integration into the application. CocoaPods is written in Ruby.

However, Cocoapods lacks direct control over project configuration and is basically a blackbox. CocoaPods also experiences random build failures that can’t be explained. Resolving these often involves removing and reinstalling CocoaPod dependencies from the project, clearing caches, and completely rebuilding the entire project. These steps can add a significant amount of time to the development process, especially on large projects.

Each CocoaPod dependency must have a “Podspec” file to define the metadata for that dependency. These files are typically uploaded to a different repository from the dependency itself. A “Podfile” within the app project will include a reference to this repository, and CocoaPods will use the information in this Podfile to fetch and install all of the dependencies for the app project. 

Carthage

Carthage (2014) – A decentralized command-line tool for dependency management. Developers have full project control and must manually provide all package and dependency information. Carthage pulls the packages the developer specifies.Configuration requires much more manual work than CocoaPods and is somewhat complicated.

Using SwiftPM

SwiftPM has many advantages over Carthage and CocoaPods. Foremost, SwiftPM is a native Apple tool integrated into Swift. Other advantages include a quick and simple configuration, easier control over packages and their sub-dependencies, and a GUI built into Xcode for managing package configurations. Each package’s metadata is defined in a “Package.swift” file, which  resides in the same repository as the package source files. 

Package Resolution

With the Package dependencies configured in the SwiftPM GUI, Xcode will download the packages and resolve dependencies at build time with no further developer interaction.

When setting dependencies, you have the following options:

  • By Version: Next Version, Up to next minor, Range, or a specific commit
  • Branch (Specify)
  • Commit(Specify)

Adding a Package to your Project

  1. Swift Packages> Add Package Dependency 
  2. On the “Choose Package Repository” dialog, enter the desired Repository.
  3. Click Next. 
  4. On the “Choose Package Options” dialog, set the dependency rules (Versions, Branches, Commits). 
  5. Click Next. Xcode now fetches the dependency.
  6. On the “Add Package to YourPrjName dialog,” ensure that the relevant packages are checked and the proper Target is selected in the Add to Target cell.
  7. Click Finish.

Your package now appears in the Navigator under Swift Package Dependencies. Note that SwiftPM can reference both local and remote packages.

Create a Module and Add a Local Package with SwiftPM

SwiftPM simplifies the process of modularizing your code and adding it as a package to a local or external repository. This section will briefly describe the process of creating a module and adding it to a local repository.

  1. Identify a self-contained portion of code or another resource that is suitable for use in a module.
  2. Create a new file: Files > New Package. Name the package accordingly and add it to your application using the same dialog.
  3. Copy the code or resource to the new file.
  4. Delete the existing code or resource from the app
  5. Add the new package to the Application Target. In “Application Project Settings,” add the new package under Frameworks and Libraries.
  6. In the Package code, define the platforms and versions where this Package works.
  7. In the Application’s code files, import the new package into every file where its code or where its resources are used. 

If desired, you could upload the new Package to an external repository for use by developers outside your organization.

Additionally, SwiftPM will allow you to create and use binary packages. Binary packages permit developers to distribute libraries and frameworks without also distributing their source code.

Package Distribution

You can use SwiftPM to distribute resources, in addition to frameworks and libraries. SwiftPM also has built-in support for Apple’s  DocC Documentation format, which makes it easy to build robust interactive documentation files and tutorials. 

The Future

SwiftPM is a mature product still under active development to improve and add new features. Usage stats currently show it being about equal in popularity with CocoaPods. However, since SwiftPM is a native tool that requires no additional work to begin using, its future is more sure than that of CocoaPods or Carthage.

Resources

InRhythm University Lightning Talk: Lightning Talk / Swift Package Manager / January 27th 2022 / Andrew Balmer

SwiftPM at Swift.org: https://www.swift.org/package-manager/

SwiftPM Repository: https://github.com/apple/swift-package-manager

State Management: Redux vs. MobX Comparison

Redux versus MobX

This post discusses two State Management packages. The first library, Redux, was developed in 2015 by Abramhov and Clark based on concepts used in Facebook’s Flux architecture. MobX also began in 2015 and was originally called Mooservable by the dev team. It became MobX with the 2.0 release on 26 Feb 2016.

There are three parts to state management. The State, which is the source of truth for your application’s State; the View, which is a rendering of the current State; and the Action, which is something that triggers a State change.

Bare Javascript passes State via property trees. A function needing State obtains the information via property drilling. Depending on a function’s layer depth, property drilling can introduce significant overhead.

Using State Management introduces a structured workflow in the application and makes obtaining the application State trivial.

Redux

Redux Overview

Redux manages application state in a centralized repository. There is a single state in the application and it is immutable. It can’t be modified by the application. This is similar to how State is managed in Flux. Redux is designed to be a predictable container for application state.

Redux combines Flux and Functional Programming and uses an immutable State as a single, predictable, source of truth in the application stored in a Javascript object. 

Redux Implementation

Using Redux requires a considerable amount of ramp-up work. There is a great deal of boilerplate code, configuration, and to take advantage of some capabilities, developers must follow explicit coding patterns. 

Redux Workflow

There are three main workflow components:

  • The UI
  • The Event or Action Handler/Dispatcher
  • The Store with Reducers and the State

The UI passes the user’s activity, or their Action, to the Event Handler. The Event Handler’s Dispatcher then notifies the Store of the Action. The Store clones a copy of the current State for the Reducers to act on based on the user’s Action. On completion,the Store passes the new state to the UI. The updated State will trigger a refresh of any component accessing that State.

The State’s Reducers are responsible for updating the State of the Store. They are pure functions that analyze the Store’s recursive data structure. They do not mutate the current state, nor do they make external API calls. Using a combining function, they recombine the results.of their recursive processing into their constituent parts, thereby building a return value.

MobX

MobX Overview

MobX was created in ES5 Javascript and follows Functional Reactive Programming patterns and prevents an inconsistent State by automatically performing all derivations. MobX’s main difference from Javascript and Redux are that State is not immutable and your application can automatically store different observable data types into different MobX Stores.

MobX uses abstraction to hide much of the background operation and reduce the boilerplate code requirement. MobX directly modifies its current state(s) without cloning beforehand.

MobX Implementation

MobX is implicit by nature, and requires little boilerplate code. After implementing State storage in the desired data structure (plain, arrays, objects, etc.), set those properties that will change over time to observable for MobX tracking.

MobX Workflow

There are four main workflow components:

  • Actions
  • Observable State
  • Derivations (Computed Values) 
  • Reactions (or Side Effects)

Events invoke Actions. Those actions can originate with the user or the application, and are the only thing that can modify the Observable State. MobX propagates any changes to the Observable State to all Derivations and Reactions. 

Deciding on a State Manager

Types of Derivations could be computation, serialization,  rendering, etc. and example Rendering side-effects are I/O activity, DOM updating, network activity. etc.

  • Application Architecture – Is the architecture Flux/Functional Reactive Programming (Redux) or more OOP (MobX)?
  • Ramp-up – Time until productive
    • Boilerplate
      • Redux requires extensive boilerplate setup
      • MobX has very little boilerplate
    • Learning Curve
      • Steeper – Redux requires developers to follow explicit coding patterns to access capabilities. 
      • Flatter – MobX is more implicit and doesn’t require extra tooling. Setup is adding a class and setting Observers, Actions, and Compute Values.
  • State Stores – Redux usually maintains a single immutable State even though it is possible to set up multiple Stores in Redux. It is a cumbersome process. MobX makes it much simpler to have multiple Stores and it uses changeable States.
  • Purity
    • Redux uses pure functions and does not allow State modification.
    • MobX allows mutable States. 
  • Scalability
    • Redux’s pure functions make code scaling much simpler and predictable. 
    • MobX’sMobX’s workflow does not include many pure functions, making testing not as straightforward, and as the application grows it becomes more difficult to determine what exactly should an output be, given an input.
  • Performance
    • Redux can suffer performance degradation from very frequent updates to its single State Store. 
    • MobX, on the other hand, with support for multiple Stores can better support frequent State updates, such as real-time updates on market pricing for a trading platform.
  • Community Support and Tools
    • Redux has a much larger community and more widely tested tools.
    • MobX has a smaller community and fewer tools.
  • Debugging
    • Redux has a single source of truth and uses a pure Store making its output predictable and repeatable. Redux has better debugging tools, including ReduxDevTools and the Time Traveling Debugger (provides State history).
    • MobX with its implicit nature, multiple States, and code abstraction can be very difficult to troubleshoot and determine the proper output from a given input. All State updates happen behind the scenes and do not offer any history. MobX also suffers from fewer robust tools.

Resources

InRhythm University Lightning Talk: Lightning Talk / State Management: Redux vs MobX / February 17th 2022 / Eric Marcatoma

Redux: https://redux.js.org/

MobX: https://mobx.js.org/the-gist-of-mobx.html

Apache Kafka Overview

Apache Kafka is an open-source, distributed event-streaming platform, or message queuing system. Kafka provides real-time data analysis that runs on servers and clients, either locally or in the cloud, on Linux, Windows, or Mac platforms. Kafka’s messages are persisted on disk and replicated within the cluster to prevent data loss.

Some typical Kafka use cases are stream processing, log aggregation, data ingestion to Spark or Hadoop, error recovery, etc.

One of the main differences between Kafka and other Pub/Sub providers is that Kafka maintains a persistent event store and allows consumers to re-read events

Basic Architecture

There are four main components:

  • The Producer – The client apps that write their Events, or Topics, to the Kafka queue.
  • The Topic – Topics are the Events that Kafka stores. They are multi-producer, multi-subscriber (Consumer), decoupled, and can have any number of subscribers or none at all.
  • The Broker – Each Broker is a Kafka server that organizes and sequentially stores incoming Events by Topic and stores them on disk in Segmented Partitions.
  • Consumer – The apps that subscribe to Kafka Topics.

A Kafka cluster is made of one or more servers, called Brokers. Topics live in one or more Partitions on one or more Brokers. 

Basic Kafka Dataflow - Producers create Records that they send to the Kafka Cluster where Kafka Brokers process and store the records before providing them to subscribers.
Basic Kafka Dataflow

As Producers write events to the Topic queues, the Brokers store the message in Segments within their Partitions according to Topic ID. Kafka always writes Event messages into any Partition configured for that Topic ID, on any Broker. Because the save is spread across all Brokers that service that Topic ID and the data is written non-sequentially into Segments within those Partitions, there is no single Broker or Partition that contains the full, sequential list of Events for that Topic. Each Partition only holds a subset of Event records in its Segments.

Kafka Producers

Producers are client applications writing Topics to the Kafka Cluster. 

Kafka Brokers

Brokers receive event streams from Producers and store them sequentially by Topic ID in one or more Partitions across one or more Brokers. Each Broker can handle many Partitions in its storage. All received messages are stored with an Offset ID.

For example, when receiving three events on a given Broker having three partitions, the Broker could store those Events to Partitions in this order 2, 1, and 3, while another Broker in the cluster could store them to 3, 2, and1. Because the writes to Partitions within Brokers are ad hoc, the individual Segments in any one Partition do not contain a sequential string of events. However, on retrieval, Kafka provides those records in their correct order by using their Broker-assigned Offset ID. 

Additionally, you can configure the Event retention as suitable for the application.

The Topic

Kafka organizes events by Topic and may store a Topic in multiple Partitions on multiple Brokers. This provides reliability and also enhances performance by avoiding the I/O bottlenecks that using a single Broker might entail, by spreading the store action across multiple computers.Topics are assigned Topic IDs.

Kafka Consumers

Consumers are apps that read Topic information from Kafka queues. Consumers automatically retrieve new messages as they arrive in the queue.

Benefits 

  • I/O Performance – Non-sequentially writing Event records to multiple Brokers/Partitions avoids I/O bottlenecks that could occur if they were written sequentially into a single Partition.
  • Scalability – Kafka scales horizontally by increasing the number of Brokers in the cluster.
  • Data Redundancy – You can configure Kafka to write each event to multiple brokers.
  • High-Concurrency, low-latency, high-throughput
  • Fault-Tolerant
  • Message Broker Capabilities
  • Batch Handling Capability (providing ETL-like functionality)
  • Persistent by default

Advantages of Apache Kafka

Real-time data analysis provides faster insights into your data allowing faster response times. For example, to make predictions about what should be stocked, promoted, or pulled from the shelves, based on the most up-to-date information possible.

Even on very large systems, Kafka operates very quickly. You can stream all data in real time to make decisions based on current information, rather than waiting until the data has been obtained, aggregated, and analyzed, which is the case for many companies with large datasets.

Kafka is written in Java, so it is easier to learn.

Use Cases for Kafka

Kafka is used for: 

  • Stream processing
  • Website activity tracking
  • Metrics collection and monitoring
  • Log aggregation
  • Real-time analytics
  • Common Extensibility Platform support (CEP)
  • Ingesting data into Spark
  • Ingesting data into Hadoop
  • Command Query Responsibility Segregation support (CQRS)
  • Replay messages
  • Error recovery
  • Guaranteed distributed commit log for in-memory computing (microservices)

Resources

InRhythm University Lightning Talk: Lightning Talk / Kafka / February 3rd 2022 / Kyle Pollack

Apache Kafka: https://kafka.apache.org

Human Interface Guidelines

A desktop on a table with paper next to the screen.
Photo by UX Store on Unsplash

Human Interface Guidelines suggest how interface components should look and how users will interact with them. There are as many ideas about interface design as there are proponents of any particular library or API. 

All interface designs share a similar goal, which is to create a unified user experience across the environment. To accomplish that, the guidelines help make their design’s interface intuitive, consistent, and learnable, both for the OS for its applications and tools. All interface elements and their guidelines should be included in an interface design document with usage examples, when practical. For example, buttons, checkboxes, dialog boxes, application views, buttons, bars, etc.

Apple Human Interface Guidelines

Apple was one the first companies to use “look and feel” in their literature when referencing the MacOS interface in the 1980s. As technology advanced, ideas on interface design also advanced. Today, Apple has “Human Interface Guidelines” that establish how your application should look and feel to users on all of it’s platforms.

Apple’s HIG is an extensive document covering all aspects of application look and feel across the entire Apple ecosystem. There is a platform-specific HIG for each Apple OS environment: 

  • macOS for MacBooks
  • iOS for iPhone/iPad
  • watchOS for Apple Watches
  • tvOS for Apple TV

Apple’s HIG is organized by platform and technologies. Each platform is subdivided into sections. For iOS, for example, the sections cover architecture, user interaction, system capabilities, icons and images, bars, views, controls, and extensions.

From the iOS section topics, it’s evident that Apple is invested in ensuring that applications on their platform have that certain Apple “look” and that those applications function in a consistent manner. 

Consistency is an important factor in user uptake of new applications. When UI elements function similarly, it’s easier for your users to transfer their operational knowledge between applications. 

Using the HIG helps maintain the quality of your application by guiding your UI decisions to support the application’s operation. Following the HIG will improve your engineering and design decisions by helping you to anticipate what most users will expect from your application’s interface.

It’s important to remember that the HIG does not dictate how your application operates, it describes the user/application interaction through visual cues, controls, and application feedback.

Customer Impact

Photo by Faizur Rehman on Unsplash

When followed, the Human Interface Guidelines ensure that the components of your application’s UI are understandable to the average Apple user through familiarity with the OS and with other applications.

Maintaining a consistent interface helps you create an application interface that is more rapidly accepted and gives your users an increased feeling of being in control, which creates a positive user experience. A side benefit is that your application will complete the App Store in a more timely manner because the UI and its controls appear and operate in the manner expected by the reviewers.

Resources

InRhythm University Lightning Talk: Lightning Talk / Human Interface Guidelines / February 24th 2022 / Hamid Mahmood

Apple’s Human Interface Guidelines: https://developer.apple.com/design/human-interface-guidelines/

Lightning Talk: Creating a Proxy with Node + Express

tldr;

I created a Node and Express proxy that rams together two websites / apps. If you are ever asked to develop code for a site you don’t have access to, this could save the day.

  1. Download the code:
    https://github.com/mattbillard/code-collider-v2
  2. Watch the video:

My most recent hobby project involved building a Node and Express proxy to ram two websites or apps together. I dubbed it “The Code Collider.” 

The idea of the Code Collider was born about two years ago when I was given a rather difficult coding challenge at a client. Another department had a website and we were being asked to iframe it. As you might know, iframes have a lot of “interesting nuances” as they might politely be called, one of which is that if a user right-clicks on a link and chooses “Open in new tab,” they will break out of the parent’s iframe and go directly to the iframed child site. Of all things, I was asked to write some code to prevent this and provide my solution to the other team. There was just one catch: I had no way of running the other team’s site in my local environment and thus (or so I initially thought) no easy way to test my code as I wrote it. 

This situation comes up more often than you’d think. There are several reasons a developer might not be able to run a site or app in their local environment. Perhaps it’s complex to set up, involves a lot of permissions, or the other team just can’t be bothered to spare the time to help you out. Regardless of the reason, I did eventually strike upon a novel way to solve the problem.

After what felt like a meandering odyssey of Stack Overflow posts, I managed to cobble together a Node and Express project that took the other team’s site, piped it through a proxy, injected my script into it, and served it to my browser. Even though my innovation worked and I was able to deliver the final code requested, there was just one thing that bothered me: I always had the nagging feeling that I had only gotten the proxy to work through a mixture of stubborn persistence and blind luck. I resolved to rebuild it from scratch in my free time one day, piece by piece, actually understanding how the solution worked – and that as it turns out is exactly what I did.

The Architecture

Here’s a diagram of how it works:

The browser makes a request to our Node Express proxy server where we then have three scenarios:

  1. If the user requested an HTML page, we need to combine the page from website 1 and 2. The proxy first asks website 1 and then website 2 for its HTML. It then modifies the two HTML files, combines them, and returns the result to the browser. (Details on how this works below.)
  2. The HTML page will then request the CSS, JavaScript, and other assets it requires. These requests will again go through the proxy which will pass on the requests. If website 1 has the asset, great, the proxy will return it to the browser. 
  3. If website 1 does not have the asset, the proxy will then ask website 2 and return it to the browser.

Here are screenshots of the result:

In this example, we’ll use the real InRhythm.com website as the target into which we’ll inject some local code (in this case a basic Create React App project). The final result on the right is an actual screenshot of the 2 websites living together in the same browser window. Now this is pretty exciting; the target website and the code that you are developing could be anything!

How it Works

  1. As mentioned above, website 1 and 2’s HTML are combined. This involves a few steps. Webpages can’t have 2 doctype, html, head, or body tags, so we’ll use some regex to strip those. Now that website 2’s HTML is ready, we’ll inject it before website 1’s closing </body> tag. 
  1. And here is the code that shows our modifications to website 1’s HTML. It shows a few things.

    Firstly, many websites have full ‘absolute URLs’ for their links. They look like this: https://www.inrhythm.com/who-we-are/
    The problem is if the user clicks on this, they’ll be taken away from our proxy and go to the target website. We’ll solve this by removing all www.something.com bit and keep just the bit after the slash.

    Secondly, we show injecting the CSS discussed above to remove backgrounds and allow clicks to pass through website 2 to website 1. (Keep in mind this will probably be slightly different depending on the two sites you are combining.)

    Thirdly, we show injecting the HTML from website 2 we modified from above before the closing </body> tag.

Gotchas to Avoid

As mentioned above, it took a lot of research as well as trial and error to solve all the technical hurdles this project presented. Here are some of the main ones below.

  1. Websites usually compress or “Gzip” their content. Normally this is a great thing. It means less data is transferred and websites load more quickly. This is not going to work for our case however. You can’t parse, manipulate, and modify HTML if it looks like gibberish. The solution was actually quite simple: as it turns out, there’s a header you can send with your request to ask the server not to Gzip anything.
  1. There’s another header we need to send however. Because we’re using a proxy, all requests are going to have the header ‘host’ set to ‘localhost’. Now this is probably not a problem for most sites, but to the target server, this doesn’t look like a very normal request, and indeed, I did find some websites responded oddly and returned pages that looked nothing like I expected. The solution again was quite simple, just modify one of the headers of our request. 
  1. Now as you’ve probably gathered from above, we’ve modified our requests quite a lot, and as a result this is going to cause the browser to do some odd things. The solution to this problem is to delete the ‘content-length’ header before the proxy sends your browser any response. This will stop the browser from truncating the response and removing all the hard work we did. 
  1. Finally, I’ll mention one other problem I solved. If you are combining sites that use https, the proxy might complain that the SSL certificates don’t match what it’s expecting. Turns out it’s rather easy to relax this with the following code: 

Conclusion

That’s it. Feel free to download the code, follow the instructions in the readme, and open your browser to localhost:8000 . You should be able to see two web sites rammed together.