iAchieved.it

Software Development Tips and Tricks

By

MQTT Last Will and Testament

This is another post in a series on writing MQTT clients using Swift on Linux.

In this post we’ll look at the MQTT Last Will and Testament message. Essentially the LWT message is predefined by a client connecting to the broker. In the event the client abnormally disconnects, the broker will then broadcast the LWT to any subscribers of the LWT message topic.

For example, let’s say you are building a chat application where each client connects to a broker and then subscribes to the topic /chat/hottub. Messages then published to /chat/hottub are received by all of the subscribers. A simple but effective way to join a “chat room” (i.e., MQTT topic).

When a client leaves the chat under normal conditions we might expect a message like “Joe has left /chat/hottub.” This would be easy to do; when the user types /exit then publish an appropriate message and then terminate the client. If a client abnormally disconnects (loss of network, client crash, etc.), then what was given to the broker as the Last Will and Testament message is used instead.

Here’s how we set up the Last Will message for our MQTT client:

willMessage is a MQTTWill property of the MQTT class. MQTTWill is constructed with a topic and message. In our example here the topic will be our chat channel /chat/hottub, and the message will be a JSON string that contains our client’s ID and a simple Abnormal Disconnect string.

Get the Code

We’ve been building Swift 3.0 directly from the latest in the Apple repositories and continually upgrade our code. To use these examples you’ll need to install Swift 3.0 from our apt-get repository.

An example of our MQTT HotTub is in GitHub.

# git clone https://github.com/iachievedit/MQTTHotTub
# cd MQTTHotTub
# swift build

To test things out you’ll want to run the MQTTHotTub twice, so open a second terminal.

1__clear_____build_debug_MQTTHotTub__ssh__and_9__clear_____build_debug_MQTTHotTub__ssh_

Run the clients with .build/debug/MQTTHotTub.

Prisencolinensinainciusol

Our MQTTHotTub client simulates a chat of gibberish. Each published message is delivered as JSON:

{"client":"octxktfo", "message":"Gyxswhz nsoxfnj gz."}
{"client":"ajyhyjic", "message":"Cmr w bzwubzv mwfhtklz."}

When a client receives a message that it did not send it gets filtered out:

Remember, if we are listening to messages published to a given topic, and we publish to that topic, the client will also receive that message back as an echo. This is the purpose of filtering with cid != clientId.

You can see each client logging what they are receiving from other clients:

Received "Wlfu zrqyj tady obxnjl lupihobi nph oapplt nyidmja." from octxktfo
Received "Cmr w bzwubzv mwfhtklz." from ajyhyjic

Now, CTRL-C one of the clients, and notice what is received by the remaining client(s):

Received "Abnormal Disconnect" from octxktfo
Abnormal Disconnect

Abnormal Disconnect

This is the MQTT Last Will and Testament message in action; the aborted client had no opportunity to broadcast that it was unavailable so instead the broker sent out the client’s Last Will on the /chat/hottub topic:

{"client":"\(clientId)","message":"Abnormal Disconnect"}

Do I Need to Have a Last Will?

Need is a strong word, and the answer is no, your MQTT client does not need to supply a Last Will message. There are plenty of additional examples that provide guidance on when you might want to use one.

What’s Next?

We’re continuing to work hard on our MQTT implementation for Swift on Linux. With Last Will and Testament now working our attention will turn to implementing secure MQTT connections (MQTT SSL). Stay tuned!

By

Swift 3.0 for Ubuntu 16.04 Xenial Xerus

Swift 3.0

In our zeal to get Swift 3.0 on as many Linux systems as possible we went ahead and got a jumpstart on building for Ubuntu 16.04, also known as Xenial Xerus, for X86 systems. Installation is as easy as using our APT repository with apt-get. Binaries are installed into /opt/swift/swift-3.0, so you will need to update your path after installing the 3.0 package. Editor’s note: For the rationale as to why we use /opt/swift rather than /usr/bin/, see this thread on the swift-dev mailing list.

1. Add the repository key

wget -qO- http://dev.iachieved.it/iachievedit.gpg.key | sudo apt-key add -

2. Add the Xenial repository to sources.list

echo "deb http://iachievedit-repos.s3.amazonaws.com/ xenial main" | sudo tee --append /etc/apt/sources.list

3. Run apt-get update

sudo apt-get update

4. Install swift-3.0!

sudo apt-get install swift-3.0

5. Update that PATH!

export PATH=/opt/swift/swift-3.0/usr/bin:$PATH

6. Try it out

git clone https://github.com/apple/example-package-dealer
cd example-packager-dealer
swift build
Compiling Swift Module 'FisherYates' (1 sources)
Linking Library:  .build/debug/FisherYates.a
Compiling Swift Module 'PlayingCard' (3 sources)
Linking Library:  .build/debug/PlayingCard.a
Compiling Swift Module 'DeckOfPlayingCards' (1 sources)
Linking Library:  .build/debug/DeckOfPlayingCards.a
Compiling Swift Module 'Dealer' (1 sources)
Linking Executable:  .build/debug/Dealer

Run it!

.build/debug/Dealer

FAQ

Q. Did Apple build these binaries?
A. No, I built them on my personal server using the instructions I posted here.

Q. What git revisions are included in the build?
A. You can use apt-cache show swift-3.0 to see this information. For example:

# apt-cache show swift-3.0
Package: swift-3.0
Conflicts: swift-2.2
Version: 1:3.0-0ubuntu10+xenial1
Architecture: amd64
Installed-Size: 370463
Maintainer: iachievedit (support@iachieved.it)
Depends: clang (>= 3.6), libicu-dev
Homepage: http://dev.iachieved.it/iachievedit/swift
Priority: optional
Section: development
Filename: pool/main/s/swift-3.0/swift-3.0_3.0-0ubuntu10+xenial1_amd64.deb
Size: 72513864
SHA256: b1bf548f353466ea72696089a8b666956a2603edb467eb0517e858eb1ba86511
SHA1: 5dd02b14d21f2e821040de3bb1052561653fcfcd
MD5sum: f2c3d3b9517a303cc86558b6c560a8d6
Description: Open Source Swift
 This is a packaged version of Open Source Swift 3.0 built from
 the following git revisions of the Apple Github repositories:
       Clang:  460d629e85
        LLVM:  8d0086ac3e
       Swift:  1abe85ab41
  Foundation:  4c15543f82
Description-md5: a6b1dd247c7584b61692a101d9d0e5fa

The source tree is untouched for each build.

Q. Do you test the binaries before you upload them?
A. The Swift build process tests the resulting binaries, and I then do run some basic tests and compile my own applications, but there is currently no separate exhaustive test suite.

Q. Are you releasing builds on a set schedule?
A. Not really, though I may try to stay in sync with the releases from Apple. The idea was to get something out for folks to experiment with and start coding Swift on Linux.

Q. Where is everything installed?
A. Everything gets put in /opt/swift/swift-3.0/usr.

Q. How do I decipher the package version number?
A. This was my first take on what I thought should be an appropriate package version number. Breaking it down, 3.0-0ubuntu10+xenial1 should be:

  • 3.0 is the version of Swift that is packaged
  • -0ubuntu10 indicates that this is the 2nd package for Ubuntu, with the 0 indicating that there is no upstream Debian package upon which this package was based
  • +xenial1 indicates that this package is for Xenial Xerus

I think I got that right, but if you feel otherwise please do drop me a line at support@iachieved.it.

How Does This Work?

I used these awesome instructions on how to host a Debian package repository on Amazon S3. I tried to set up a Launchpad PPA, but quite frankly, got tired of trying to wade through all the metadata required to put together a simple package. I’m sure for hosting distribution repositories it’s all required, but for this it felt like overkill. The folks that develop fpm also have some choice things to say about it.

The packaging scripts we use to build everything and upload to the repository can be found Github. For Swift 3.0 make sure and look at the swift-3.0 branch.

By

Handling MQTT Subscriptions with Swift on Linux

In our last post we looked at a Swift MQTT client which published information to a HiveMQ broker. Now let’s turn our attention to writing an MQTT client that subscribes to a topic.

Again, we’ll be using MQTT, code that aims to provide a solid MQTT client library implementation in Swift. If you haven’t yet read the tutorial on building an MQTT publisher with it, I suggest you do so before proceeding!

There are two basic components to writing an MQTT client that subscribes to a topic:

  • subscribing to a topic
  • handling a published message from the broker

Ignoring the boilerplate connection logic for a moment, let’s look at subscribing:

There’s nothing earth shattering here: upon receiving a ConnectedNotification a call is made to subscribe to the topic /hostname/cpu/temperature/value (where hostname is obtained from the OS). Now when the broker receives a message published to this topic it will broadcast it to our client. This is the pub-sub pattern in action.

This Transmission is Coming To You

To receive an MQTT message we need to handle the MQTTDelegate method func mqtt(mqtt: MQTT, didReceiveMessage message: MQTTMessage, id: UInt16 ). This can be readily accomplished using an NSNotification with accompanying userInfo:

Unfortunately for us much the userInfo dictionary remains grounded in using NSObjects as keys, so care must taken to cast String as an NSString when assembling.

In the main.swift implementation we listen for a MessageNotification:

For details on the MQTTMessage class, see the source, but we can gather from the above that two properties are of interest here:

  • topic:String – the topic to which the message was delivered
  • string:String? – the message contents, if any, delivered as a String

Get the Code

MQTTSub is an example implementation of an MQTT client that subscribes to our CPU temperature topic. Obtain it and compile with:

# git clone https://github.com/iachievedit/MQTTSub
# cd MQTTSub
# swift build
# .build/debug/MQTTSub

You will, of course, want to be running the publishing client as well:

# git clone https://github.com/iachievedit/PubSysTemp
# cd PubSysTemp
# swift build
# .build/debug/PubSysTemp

If your publishing client is running, you’ll see something like:

2016-06-13 02:55:43 +0000 - INFO    - Connecting to broker
2016-06-13 02:55:43 +0000 - INFO    - MQTT client has connected to broker.hivemq.com:1883
2016-06-13 02:55:43 +0000 - INFO    - Subscribe to topic
2016-06-13 02:55:43 +0000 - INFO    - didConnectAck
2016-06-13 02:55:43 +0000 - INFO    - didSubscribeTopic /darthvader/cpu/temperature/value
2016-06-13 02:55:44 +0000 - INFO    - Received 33.0 for topic /darthvader/cpu/temperature/value

If you want to have fun, try stress testing your system while running the publisher and subscriber. After stress -c 8 was started up:

PubSysTemp

2016-06-13 03:04:55 +0000 - INFO    - Published temperature to 34.0
2016-06-13 03:05:05 +0000 - INFO    - Published temperature to 37.0
2016-06-13 03:05:15 +0000 - INFO    - Published temperature to 42.0
2016-06-13 03:05:25 +0000 - INFO    - Published temperature to 45.0
2016-06-13 03:05:35 +0000 - INFO    - Published temperature to 47.0

MQTTSub

2016-06-13 03:04:55 +0000 - INFO    - Received 34.0 for topic /darthvader/cpu/temperature/value
2016-06-13 03:05:05 +0000 - INFO    - Received 37.0 for topic /darthvader/cpu/temperature/value
2016-06-13 03:05:15 +0000 - INFO    - Received 42.0 for topic /darthvader/cpu/temperature/value
2016-06-13 03:05:25 +0000 - INFO    - Received 45.0 for topic /darthvader/cpu/temperature/value
2016-06-13 03:05:35 +0000 - INFO    - Received 47.0 for topic /darthvader/cpu/temperature/value

What’s Next?

If you peruse the MQTT library you’ll notice it is lacking SSL support. That’s what’s next! In addition, we’ll be looking at writing additional MQTT tutorials that explore constructing topic hierarchies, using MQTT with real-world sensors, home automation devices, and more.

By

MQTT Clients With Swift on Linux

Swift 3.0 Swift 3.0

Over the past few years I’ve made a living managing Internet of Things (IoT) software development projects. In that time I’ve come to learn a number of protocols for communicating sensor and telemetry information back to “the cloud”. Among the most popular in the IoT space is MQTT, a lightweight protocol that allows for publishing messages to topics, as well as the ability to subscribe to topics. This model is frequently refer to as “pub-sub“.

In addition to working with IoT and MQTT, I am passionate about Swift and the inroads it is making into the server space since being open-sourced and ported to Linux. Naturally it made sense to combine the two areas and start working on an MQTT client implementation in Swift! We’ve taken the liberty to port an iOS implementation of an MQTT client over to Swift 3.0 on a Linux platform. In general this is an example that, indeed, Swift will be making inroads into both the server and IoT domains.

A disclaimer before we get started: the code below is based upon Swift 3.0 which is going through developer previews on Linux right now. To get started with Swift 3.0 on your Ubuntu 14.04 or 15.10 system go here. Or, if you have an armv7 device such as BeagleBone Black, try the ARM port of Swift 3.0!

Sample Application

My first idea was to put together a cool BeagleBone MQTT client that was reading one of the ADC inputs and sending it up to the broker. The input was going to be from a Microchip MCP9700 temperature sensor IC. The sensor IC maximum output voltage is 5.5V so I knew a voltage divider would be involved to keep the voltage input to the BeagleBone under 1.8V. I had the voltage divider all sketched out and everything!

Don't Want to Blow Up the BeagleBone!

Don’t Want to Blow Up the BeagleBone!

Unfortunately while testing the sensor IC with a standard match I got the flame a little too close to the IC package and well, Project Icarus came to an end. Our replacement example is a bit less ambitious, but serves the role of learning how to build an MQTT client with Swift. And it doesn’t involve matches.

MQTT

Our application is built around a port of a client MQTT library (yay open source!). We’ve named it simply MQTT and posted it to GitHub. The library is meant to be used in a Swift application that you can create as follows:

Running swift package init --type executable is going to give you a Swift project shell (think npm init) that you can begin customizing for your purposes. We’re going to edit Package.swift and add our MQTT library dependency:

MQTT Client Delegate

The design of the MQTT library is such that you will create a client class that inherits from MQTT and MQTTDelegate. A very basic implementation looks like this:

As you can probably guess the functions above are delegate methods that are called when the underlying MQTT client connects, publishes a message, subscribes to a topic, etc. It is up to you, the client writer, to fill out the implementation to suit your needs. In our case we’re going to implement the mqttDidDisconnect method as follows:

I’ve mentioned in previous posts that I appreciate the flexibility of posting a notification and having it acted upon by whoever was listening for it. DisconnectedNotification will be handled in our main.swift routine.

main.swift

Let’s turn our attention to main.swift which will instantiate an MQTT-based client. At a fundamental level here is all that’s required:

We want our client to be a bit more robust, so we’ll add in the ability to automatically reconnect if our connection is dropped by doing something like this:

Now, one could argue that we don’t want to exit if the connection to the broker fails. What we could do is set a timer and then rebroadcast our DisconnectedNotification. This will be our approach in the working code detailed further below.

We should publish something useful to the broker, so let’s set up an NSTimer to wake up every ten seconds and obtain the CPU temperature and then post that.

It should be noted here that we set the timer up and then fire() it immediately (so we’re not waiting ten seconds for that first post). Also, you will notice that we’re posting to the topic /<i>clientid</i>/cpu/temperature/value. This is one example of an MQTT topic naming convention and meant strictly as such. As you delve further into designing IoT applications it will become apparent that your naming convention is of considerable importance.

Getting the CPU Temperature

I love working with Linux and the wealth of information that is available in the /sys and /proc filesystems. Unfortunately when you’re dealing with hardware you have to frequently tailor your code to the specific hardware it’s running on. For example, on my x86 server the temperature of the CPU can be obtained by reading /sys/class/hwmon/hwmon0/temp1_input. On the BeagleBoard X15 it is at /sys/class/hwmon/hwmon1/temp1_input. That’s aggravating.

We won’t bother with writing portable code for now, but you should be able to take this example and suit it to your own system’s needs:

Putting it All Together

Let’s put everything together to build a working MQTT client that posts our CPU temperature to broker.hivemq.com. As a bonus, we’ll provide a web page that shows the CPU temperature displayed as a gauge.

We have three files that make up our client:

  • Client.swift
  • CPU.swift
  • main.swift

Each of these files should go in the Sources directory. Let’s look at a complete implementation of each:

Client

Client.swift

CPU

CPU.swift

main

Our main.swift appears to be complicated but it’s not really. The key things to recognize is that we wait for notifications and then set timers based upon those notifications to put our client into motion. For example, nothing good will come of trying to publish if we don’t have an MQTT connection established, so we wait for that notification (from our delegate) before attempting. Once a connection is established we set a 10 second timer and then update the temperature if we are still connected.

Note also the use of a heartbeat timer. Runloops will exit if there are no input sources or timers attached to it, so we use a simple repeating timer to keep a heartbeat (and thus, the runloop) going.

Your Package.swift file should look like:

To make life easier you can grab our code from GitHub. Build with swift build and then run it:

# git clone https://github.com/iachievedit/PubSysTemp
# cd PubSysTemp
# swift build
# .build/debug/PubSysTemp

Remember: this code is written in Swift 3.0! For more information see our post on obtaining Swift 3.0 for Linux.

What’s this Broker Thing Again?

Think of an MQTT broker as an NSNotificationCenter. In iOS one typically obtains a reference to the NSNotificationCenter.defaultCenter() and then posts messages to it. Likewise, to receive a message you register to be called when a named notification is posted (topic anyone?).

With MQTT you need to communicate with a broker. If you’re building an IoT gateway you might run your own broker using Mosquitto or HiveMQ. If you’re writing a tutorial on MQTT you might take advantage of a public broker such as test.mosquitto.org or broker.hivemq.com rather than running your own (like we did!).

In our example above we wrote an MQTT client that publishes data. What about subscribing to that data? This is also the purview of MQTT clients. For our example we’ll use a nice temperature gauge widget to power our temperature display.

Compiling Swift Heats Things Up

Compiling Swift Heats Things Up

What’s important to realize here is that the temperature gauge is actually an (JavaScript-based) MQTT client that has subscribed to receive events published to the /darthvader/cpu/temperature/value topic on broker.hivemq.com. (darthvader is our client’s hostname.)

What’s Next

There’s much more to be done with the MQTT library. As of June 11, 2016 it successfully connects and publishes, but subscribing to a topic is another story. That’s our next issue to tackle.

This is just the beginning, however, for Swift on the server. Organizations such as Zewo are working hard to develop libraries that can be used to develop server-side software on Linux with Swift. In fact, our MQTT library uses Zewo’s VeniceX TCP routines for network IO. Time will tell, but I’m convinced Swift has a bright future ahead of it in more than just iOS development.

Postscript: Please don’t comment on my lousy voltage divider. I nearly failed EE classes and do the best I can.

By

Writing Reusable Algorithms With Swift Generics

Learning a new programming language is fun, and learning Swift has been no different. We’ve been covering, through brief tutorials, features that most Objective-C programmers will find to be new. As many have observed, Swift borrows from many different languages and brings the “best” features together in a single language. One such feature is generics.

Simply put a generic is code that is agnostic of type, that is, code that can work with any type. One of the most powerful forms of a “generic” is the generic algorithm, i.e., an algorithm that can be used with most any type. By far the most common “example” algorithm is that of sorting. It’s common because its easy-to-grasp (everyone understands sorting and its applicability to software), easy to implement, and actually a useful algorithm to have in ones toolbox.

We’ve been big fans of showing how Swift can be used as a general purpose scripting language on OS X, and this example will be no different. A reality check, however; Swift is not going to displace Python as a scripting language, but we were able to take this Python implementation of Quicksort and convert it into Swift in two shakes of a lamb’s tail.

For this tutorial, however, we’re going to use the most basic sorting algorithms of all, the venerable bubble sort. We like to think of the bubble sorting algorithm as the thing you’d come up with (perhaps on the back of a napkin) given no previous experience thinking about sorting. Let’s think about how to sort an array of Ints in Swift:

The details of the algorithm aren’t necessarily important, but for completeness sake, let’s review it. So you have a list of integers, say: 10, 11, 8, 5, 27, 1, 25, and you want to sort them. Bubble sort says, okay, I will walk along this list one integer at a time, and when I find two integers next to each other that are out of order, I’ll swap them. Once I swap the two, I’ll move to the next pair. After I’ve done that over the whole list, I’ll come back around and do it again, until I haven’t swapped anything, thus knowing I’m done.

Thus in the first pass I compare 10 and 11, and since 10 is less than 11, I don’t have to swap them. Then I look at 11 and 8. 8 is less than 11, so I swap them giving me 10, 8, 11, 5, 27, 1, 25. Now I compare 11 and 5, and since 5 is less than 11, I swap them. And so on. The point is at the end (after passing through the list several times), I’ll have my sorted list: 1, 5, 8, 10, 11, 25, 27. For a visual representation of this happening, check out this cool animation of bubble sort in action.

That’s handy and all, but the bubblesort function we’ve written only handles Int arrays. If we wanted to handle a String array, we would have to duplicate the routine and change out Array for Array. “There has to be a better way!” you say? Of course there is. Enter generics.

We want to write a function that can sort an array of any type. An array of Strings, an array of Doubles, even arrays of object types we haven’t created yet. We do this all through generics. Here’s the definition of our new bubble sort function:

Pay attention to the comment we wrote, “Everything else remains the same.” That’s right. The bubble sort algorithm doesn’t change just because we’re sorting SelfSealingStemBolts instead of Strings.

In theory you should be able to enter this code in a text editor and run it from the command line:

A side bar: to quickly run the code above and all of our examples, add the following to the end of your .bashrc (assuming you are using Beta2, adjust appropriately if not):

Re-source your .bashrc, add the code to a file called ~/Documents/generics.swift and then just run swift ~/Documents/generics.swift. See our previous post for more details.

We said in theory the above code would work, but in reality it won’t. You will be greeted with the error:


error: could not find an overload for '>' that accepts the supplied arguments

Let’s think about what this means for a minute. Swift has to compile your code and determine how to accomplish the task you’ve requested, namely that Swift can take any type T and apply the algorithm you’ve provided. That algorithm happens to include the greater than comparison between two objects of this generic (there’s that word again) type we are calling T. So in effect, you are making an implicit statement about objects of type T, and that’s that they are comparable. With Swift you need to make that statement explicit, by telling the generic function that types you will be handling adhere to certain protocols. In our case we can use the Swift Standard Library protocol Comparable, like this:


func bubblesort(list:Array)

The inclusion of the :Comparable declaration here is critical, and it tells Swift that elements given to the generic function will implement the Comparable protocol, which requires the definition of the function less-than (and subsequently also provides greater-than, as well as less-than-or-equal and greater-than-or-equal).

With this addition we can now throw an array of integers or array of strings at our bubblesort routine. Since Int and String adhere to the Comparable protocol out of the box, things will “just work.”

Of course, we are not satisfied with sorting just integers and strings! We demand more! Enter our Element class, which holds information about an element, as in the periodic table of elements.

With this basic definition we can do the following:

and get Gold (79) printed. Note that we inherit from NSObject and implement the Printable protocol to enable our ability to override var description:String and utilize println to pretty-print our element.

Now, we want to create an array of Elements and sort them with our bubblesort routine:

This isn’t going to work, and it should be painfully obvious as to why, but Swift will tell you if its not obvious: error: cannot convert the expression's type '()' to type 'Comparable'.

Our bubblesort function says “I accept generic types that adhere to the Comparable protocol”. We have passed in a class that adheres to Printable, but we’ve said nothing about Comparable. So let’s go back add see if we can trick Swift by just adding Comparable to the class definition.

If you are following along executing Swift code in the terminal you will see all manner of hell break loose trying to run that. We stopped counting how many notes Swift tossed out, but they are all along the lines of candidate has non-matching type (X, X) -> Bool. In short, the compiler is telling you, I have looked high and low trying to match global comparison functions to your class, but I can’t. We have declared our class to follow the Comparable protocol, but didn’t back it up with an implementation as to what it means to compare two elements. So we have to do that.

So, what does it mean to compare two Elements? We aren’t chemists (thank God), so we’ll just make something up for illustration and say that “a given element X is less than a given element Y if the atomic number of X is less than the atomic number of Y”. That’s a fancy way of saying, “elements are sorted by their atomic number.”

To implement, we add the following outside the class body:

Now Swift will have a function that “matches” when it goes looking for something to fulfill the Comparable protocol for Element. The code embodies what we wrote out, and lhs and rhs are simply abbreviations for “left-hand side” and “right-hand side”, meaning of the equation.

We are almost done. When declaring yourself to adhere to the Comparable, you are also declaring support for the Equatable protocol, which requires you to define == (equality). So, we oblige with:

Add it all up and you should have:

Run this code and see the magic:


[Titanium (22), Zinc (30), Silver (47), Gold (79), Plutonium (94)]

To recap: Swift’s support of generics allows us developers to write algorithms and data structures that are not bound to a concrete type or the type’s implementation. In the above example we explored only the generic algorithm, but Swift also supports generic types for implementing data structures such as stacks, queues, etc. We will admit, the syntax can be a bit daunting (too many brackets!) and Terse (get it?), but with patience and perseverance you’ll be writing your own generic data structures and algorithms in no time.

Now, we promised an implementation of Quicksort in Swift using generics. You can find a full example on Pastebin.