Join us as we talk about The Server Side Swift meetup, the Server Side Swift conference, Wasm, new features in Swift Package Index, Hummingbird 2, Vapor 5, and hear our regular package recommendations.
News
- SSWG Meetup #3
- Server Side Swift Conference
- Contributions to Swift Package Index
- Hummingbird
- Vapor
Packages
- swift-snowflake by Jaehong Kang
- Versionator by Sam Deane
- GameControllerKit by Wesley de Groot
- swift-export by Frank Lefebvre
- Chip8iEmulationCore by Danijel Stracenski
- SpectreKit by Patrik Svensson
Creators & Guests
What is Swift Package Indexing?
Join Dave and Sven, the creators of the Swift Package Index open-source project, as they talk about progress on the project and discuss a new set of community package recommendations every episode.
So I think we can start with lots of news this week.
It's been a few weeks since our last episode.
We had to postpone last week,
which has given us a little bit of a chance
to get a little bit more queued up news,
but we have several things to talk about this week.
- Yeah, indeed we have.
Actually last week, I had just finished participating
in the Server-Side SWIFT meetup, the third one,
organized by the SSWG,
which is the SWIFT on Server Working Group.
There's just so much SWIFT and server in those names.
And I think this is of general interest.
I mean, it's a Server-Side SWIFT meetup and working group,
but the topics were actually
not all that Server-Side specific, I'd say.
So there was a great talk by Jutta Seito
about SWIFT WASM.
And there's a package also that I can mention
while we're at it, WASM Kit.
It's not a single thing.
So there are a number of things
that are sort of in the category of WASM.
And WASM, what does WASM actually stand for?
I keep forgetting.
It's Web--
- WebAssembly, I think, yeah.
- WebAssembly, exactly.
So effectively it's sort of,
I think, and Jutta had a really great way of phrasing
what, why WASM is such a big deal.
Think about what JSON has done for data exchange.
Like really, you mentioned JSON
and you want to receive JSON.
Everyone knows what you're talking about.
And it's just about what fields do you want?
But all the exchange format is really, really clear.
It's sort of become the de facto standard
for data exchange.
And WASM could be that for executable, for logic.
Because it's essentially something that can be produced
by various different languages, Swift being one of them.
So, you know, Rust, I don't know, I guess Python,
you know, all manner of JavaScript,
all manner of languages can produce WASM
as an executable format,
which can then run on many different,
in many different places.
Like the browser, they are just runners.
Like there's a thing that's actually written
in Swift that can execute WASM.
So it's a proper exe exchange format,
executable exchange format.
And it could be sort of the lingua franca
for exchanging logic.
You know, think plugins, you know,
what if you wanted to have plugins that are shippable?
That could be WASM.
There's a really great-
- I think that's-
- Yeah, go on.
- I think that's a really nice way to think about it,
actually, because I'm much more excited.
So I actually, I attended the meeting
and watched this talk on WASM.
And I actually, I asked the question halfway through,
which was, you know, how does it interact
with the browser APIs?
And I'm, and it does interact with those browser APIs,
but I'm much more excited about WASM
as a non-browser technology.
So I don't think I'm going to be rushing
to interact with the DOM
when we're doing the bits of JavaScript
that we need to do on the Swift package index in WASM,
because I don't really see any advantage to that.
In fact, all you get is a slightly degraded experience
because those browser APIs, they work,
but they're, you, it's not,
it's not how they were intended to be interacted with.
But for other bits of code
where you might have to either re-implement something
that you had in your server-side code or something like that.
And as you say, as maybe like an interchange format
for code, I think it's a much more exciting technology
in those cases.
- Yeah, exactly.
I mean, think of all the places
where you have executable code
that should run cross-platform, for instance.
And like one example that's been brought up
that has actually been pitched is macros.
So right now you have to include Swift syntax, right?
When you have macros and you want to generate the source code
and you have to build all of Swift syntax,
and that's a huge strain on the build system,
on your builds in particular, if they release builds.
WASM could be the exchange format,
such that you don't have to ship Swift syntax
in source, but you could ship it as,
my understanding is at least that it would be shipped
as a WASM build that then gets run.
So you skip the build step of it.
You automatically have a cross-platform plugin
and you don't need to ship like five different slices of,
you know, how would you even do that with Linux?
You know, you can ship a binary that runs
on macros, Intel and ARM, you know,
by having a binary that has the two aspects of it,
but that wouldn't work for Linux.
And then you'd have to bundle that up somehow.
But with WASM, it's just one thing that gets run
on different platforms because they know how to execute that.
So that's quite interesting.
Just give the, the meeting has been recorded.
So there's a YouTube up where you can watch the presentation
or it's really nice, really interesting.
Opens up lots of possibilities around that topic,
you know, executable logic exchange.
- Sure.
- Yeah, and there was a second interesting talk
by Konrad Marowski of the Swift team at Apple.
And that's also not, wasn't really server specific
because he talked about getting ready for Swift 6.
And that was a really interesting talk as well.
Was, he started, I think he started off with a reminder,
you shouldn't panic, don't panic about Swift 6.
It might even have been his first slide,
but he also had great tips on how to hold your towel
when you do panic.
And if you don't know the towel reference,
you can do a web search, but you know,
you might end up in places where you get warnings
and you don't know how to deal with it.
And Konrad had examples of those
and how you deal with them.
And I think that's a great talk
to take the edge off because I think,
and we've talked about this a number of times,
there is a lot of concern around Swift 6
and Konrad really addresses that
and calms people down, I think.
And he's done a really great job
laying out how you should approach it.
- That's great, yeah.
And talking of events, Swift events,
you are actually at an event where you will be,
by the time this gets released, you will be at,
you're not at, talk about a Swift event.
(laughing)
- Yes, I will be at the Swift on Server Conference
in London next week.
In fact, I'll be leaving tomorrow and this podcast,
I'll be ahead of the podcast
and the podcast will arrive after me there.
Yes, I'm really looking forward to this one.
Lots of people I've interacted with.
Online that I've never met in person,
so I'm excited to meet lots of folks.
I've already got a list of names of people
to get in touch with.
Yeah, exciting times.
Unfortunately, you're not one of these people on the list,
but we'll manage here.
- I'm afraid I'm not.
Yeah, like I said, I've not been super well recently
and I'm not gonna be able to be there this week,
which is a tragedy because I was there
the last time this conference was put on
and it was not only a fantastic conference,
but a great opportunity to meet a lot of people
who I hadn't yet met in the server-side Swift community
and it was a great event.
Fantastic venue.
I think it's at the same venue this year.
It's the Science Museum in London,
which is a fantastic venue.
And as you say, just a really good chance
to meet a lot of people.
But it unfortunately does mean
that we won't get a chance to meet up again this time.
- Yeah, unfortunately not.
But you mentioned, we were on a call yesterday,
you mentioned a cardboard cutout that exists of you.
And do you own that?
Could you ship that so I can prop you up here in my office?
- I don't own it.
No, at the end of,
so we'll pop a link in the show notes too.
This is something that happened a few years ago
and there's a whole story behind it,
which is too long to go into on the podcast.
But at WWDC and Alt Conf 2019,
there ended up being a life-size printout of me
that was put in the Alt Conf kind of main lobby area
for the entire week of WWDC.
And it was there for people to take pictures with,
which is the strangest possible backstory to this.
So strange, in fact,
that I felt I had to clarify it in a blog post,
which I did do,
and we'll include a link in the show notes to that.
But the main reason I wanted to clarify it
is just to make sure that people understood
that I didn't make a huge life-size cutout of myself
because nobody wants to be that person.
And that's not what happened.
But the slightly worrying thing is I didn't make it,
I don't own it, and I don't know where it is,
but I'm pretty sure it still probably exists somewhere.
- This was spawned by PicswithDave, right?
There was this Twitter thing.
- It was, yeah.
- I mean, be honest,
you just outsourced the PicswithDave
to a cardboard cutout, right?
(laughing)
- Exactly, yes.
Yeah, it's all Kevin Hocter's fault.
That's all everyone needs to know.
- Right, right.
- We also have a bit of contribution news
to talk about this week.
We have a couple of things I'd like to mention.
First is a contribution which is kind of in progress
at the moment.
So we've had a discussion around an enhancement
with Daniel Lyons, who came to the discussions board
on our GitHub project and suggested that we add
a new type of filter to the search options.
So we already have filters for things like
license and platform.
So you can say, show me all packages
that match this search string,
but also are compatible with iOS
or have a specific license or something like that.
And one of the filters that you can add there
is a filter on last activity.
So when was the last commit or pull request closed
or issue opened or something like that.
So how active is the project?
And Daniel suggested that we had a first activity filter
as well, so that you can start to filter packages
by effectively how old they are.
So you can filter to only packages that have been created
within the last year, for example.
Or you can say packages that are at least six months old
or something like that,
which is maybe a more realistic way to use it.
And so we had a little discussion on the discussion board
and that got transitioned into an issue.
And Daniel is on his way to producing that
as a pull request, which will get into the system
and add that functionality into the software,
which is great.
And then another contribution,
which is a little bit further along.
In fact, I think the final part of it
is going to be merged today,
which means it will be live on the site
by the time you hear this.
It's from Mirza Ucchanbalik.
And that is a feature that we had in our heads
since almost the very beginning of this project.
It's a three digit issue number,
which is pretty rare these days,
that this was originally there.
And it's to add some information on package pages
for packages that have been forked from
another Git repository.
And so what's going to happen is,
as of by the time you hear this,
you'll be able to, if a package is a fork of another package,
you'll be able to see that right at the top
of the metadata description on the package page.
And it will say this package is forked from
and then give you a link to the previous package.
And this is one of those features
that is really interesting because it sounds
much more simple than it is.
And it's one of those that has a couple of little edge cases
and it's been kind of interesting going through with Mirza
to find those and then decide what to do with them
and cope with them.
So the idea is a couple of these are like, for example,
the idea is that we could provide a link
to the parent package, of course,
that seems an obvious thing to do.
But then we have the choice of, well, what do we do?
Do we link to the GitHub repository?
Do we link to the Swift package index page?
In that case, what happens if the package
isn't in the index?
I think most of them are,
but we have to cope with those edge cases
where it might not be, or for some reason,
the original package author of the fork
wants their package removed.
And that the fork is now the definitive package
or something like that.
So you have this condition of, well,
what happens depending on where that repository currently,
where that parent repository currently is.
So that was kind of interesting.
And then you've got things like, well, what happens
if the parent repository is renamed
or the child repository is renamed?
And you've got all these kind of little edge cases
around a feature like this.
That something quite simple initially
can turn into a much bigger feature
than you might've thought it was.
But it's been great to work with Mirza on this.
And I think it's turned into a really great little feature.
And I'm really happy to see it ship finally,
because this is something that's,
well, this is something that tripped me up recently
that I thought I was talking about a package
and actually I was talking about a fork of a package.
And it is really useful.
There's nothing wrong.
I'm happy that we have forks in,
and I'm happy to have as many forks
in the package repository as can exist.
That's not the problem at all.
But the knowledge that you are looking at a fork
is really quite important.
- Yeah, exactly.
I'm really glad we're getting to this finally, so to speak.
And I actually was thinking about that as well.
I mean, I think that prompted it effectively, right?
Us revisiting that issue was the fact
that we ourselves were tripped up,
not realizing that the package is actually a fork.
- Yeah.
- Right, in other news,
there are a couple of important packages
we wanted to mention that have seen recent updates.
This is also server-side Swift.
So Hummingbird 2 has come out.
So the second version of Hummingbird.
I believe you also linked to this
in iOS Dev Weekly, didn't you, Dave?
- Both of them, yeah.
- Yeah, both of them, exactly.
Yeah, and Hummingbird 2 is out.
Beautiful webpage.
I want to give out a shout out to the webpage.
Looks fantastic.
Really, really nice to navigate.
Briefly, what's new in version two,
it's fully async/await.
So written with async/await in mind from the start,
and it is Swift 6 ready.
Give it a go.
I always, when I talk about Hummingbird and Vapor,
the other package that I'll mention in a minute,
to compare them, and this,
apologies if you don't know Python,
but in the Python world,
there's two packages that are Flask and Django.
And Django is the one where everything comes,
you pull in Django, you have everything,
and Flask is the one where you pull in a core package
and then you add things as you need them.
And that's how I think about when I compare
Hummingbird and Vapor.
Vapor's the one where you get everything off the bat,
and Hummingbird is where the one
where you're more focused and more diligent
about where you start and what you then pull in,
in addition.
- It's a really common pattern in the Ruby world.
There's Rails, which is the whole everything,
and then there's Sinatra,
which is the one where you start with the minimal
and then bring other modules in as you need.
- Right, yeah.
Yeah, and it makes perfect sense, right?
Sometimes, especially early on, maybe,
when you're learning a framework or a language,
it's nice to have something
where you don't need to worry about
finding the best thing to do, X.
You know, how do I do database?
And then you have to go hunting,
well, what's the package?
It's really great on those occasions
to have everything at the ready.
If you know your way around,
it's also nice to start small, right,
and not incur the build costs and all that,
and stuff that might be confusing
or might be in the way when you actually know already,
well, I'm not going to need that.
So it's really great to have the choice.
And as I mentioned, Vapor also hasn't had the release,
the next release, which is version five,
but they've put up a post about the future of Vapor,
and it's laying out the plans for version five of Vapor,
which is, it's very similar
to what Hummingbird 2 is really.
It's fully async/await,
using structured concurrency throughout,
and it's Swift 6 ready,
which isn't to say that neither of those
is the case for Vapor 6.
It's just that in Vapor 6, it is async/await ready,
so you can use it, and it's fully Swift 6 ready as well,
but the async/awaitness has been sort of retrofitted,
and in lots of places,
stuff has been made sendable via locks.
So as a user, as an API user, you wouldn't notice it,
but under the hood, I think you're going to,
if you're very performance sensitive, perhaps,
you would probably see that there's locking going on
under the hood,
but I think, and we've been using Vapor for years now,
and we've transitioned to async/await fully.
We don't notice any downsides of this right now,
but it's still nice to have the plan laid out,
and there's also a couple other things,
like moving to use a few more upstream packages,
like for instance, the HTTP types from the Swiftlang,
Swift HTTP types repository,
so there's, and that's going to make it easier
once you use these types as currency types to exchange.
If you have different packages that all use these types,
it becomes easier to exchange those types
because they then live in an upstream library,
so imagine you have a router that returns
some common HTTP type.
You can easily plug it into another component
that uses that same type without having to write
a little converter for that,
so that's really nice to see.
The first alpha should be released really soon.
In fact, it might be released already.
I haven't seen it, but I might have missed it.
I didn't go actively looking.
It certainly should be imminent,
perhaps around the conference end of this week,
or maybe shortly after.
You should see the first beta of Vapor V.
- The only other thing I'd add there
is I think I should add some clarification
on version numbers because there were a lot of Swift 6
and Vapor Vs and Homebird 2s and Vapor 4s in there,
and I think you may have got the numbers mixed up
a little bit, a couple of points.
- Oh, did I?
- Yeah, so you were talking about Vapor 6,
which is not a thing.
That's Vapor V.
- It will be, though.
It will be, I'm sure.
(laughing)
- Yeah, so that's Vapor V with Swift 6 support,
and Hummingbird 2 also with Swift 6 support.
- It's, you know.
- Just to clarify that.
- I was 18 on the iPhone 17, right,
and running on MacOS, oh God, it's all so terrible.
- Exactly, yeah.
And the Swift package index is still on version 2
and has been for the last three and a half years.
- Yeah, but for a minor version 101.
(laughing)
So yes, lots of version numbers.
We shall, as an industry, we shall one day solve
the mystery of how to do version numbers.
- Oh dear.
- So should we do some package recommendations?
- Let's do some packages.
Do you wanna kick us off?
- Sure thing.
I'm gonna talk first about a package called Swift Snowflake
by Jaehong Kang, and this is,
so I hadn't actually come across the idea
of this Snowflake ID.
Had you?
Do you know about a Snowflake ID?
- No, it sort of rings a bell.
I might've read about it, but I can't recall any details.
- Right, okay, yes, it might, yeah.
You probably will have heard something about it,
or at least there are lots of technologies
which I'm sure you do know.
Like for example, UDIDs are a similar,
solving a similar problem to this.
A Snowflake ID in best Wikipedia terminology
is a form of unique identifier
used in distributed computing.
It was initially created in the early days of Twitter
and used for the IDs of tweets,
but now it's used by Masterdard, it's used by Instagram,
it's used by Discord,
it's used by a whole load of other products.
And it is a kind of guaranteed unique number
that an individual machine can generate
without needing to know what the previous number was.
So 64 bytes binary, it starts with a timestamp,
it then has a machine ID,
and then has a sequence number for that machine after that.
And a little bit like UUID or UD-
- UUID?
- No, UDID is unique device, isn't it?
And UUID is universally unique.
Yes, you can then generate these numbers
which are good for, maybe you can use them as database ID,
but you can certainly use them for public identifiers
for unique resources inside your application.
And Swift Snowflake is a implementation
of Snowflake IDs for Swift.
So it's very, very simple to use.
You can either represent a specific Snowflake ID
if you would like to represent one that you already have,
or you can ask it to generate one.
And there are various different strategies
for encoding that if you want to put it into JSON.
And yeah, it's a very, very simple package to use,
but I hadn't come across the Snowflake IDs before,
and I thought they were kind of interesting.
- Interesting.
Just to clarify, you said 64 bytes.
Did you mean bytes or bits?
- Bits, I meant bits.
Like it's like Vapor 6 and 64 bytes.
Yeah.
(laughs)
Yeah, a 64 byte identifier would be amazing.
That would be more identifiers
than there are grains of sand in the world, I'm sure.
- Yeah, that's for sure.
But also, I mean, UUID is 128,
and that is, that bears, I mean, it's a small risk,
but there's a risk of collision.
You said guaranteed unique.
I mean, and that's half the size, I guess, that-
- Probably.
There is no mention of the word guaranteed unique
on the Wikipedia page.
- Oh, okay.
(laughs)
- That is me projecting my wishes onto this forum.
- Okay, that's a wishful thinking addition.
It does say,
it does say, I mean,
per machine secrets number two,
allow creation of multiple snowflakes
in the same millisecond, which is quite reasonable.
- Yeah, yeah, I mean, even with,
especially with UUID, the chances are really, really slim.
I mean, if you think your problem is a UUID collision,
then in all likelihood, you need to think again,
if that was really what's happening.
- Right, yeah, exactly.
Yeah, yeah.
And I think maybe that's the place to think about this
rather than maybe a UUID,
which is if it tends to be used for
identifiers that might end up in like a URL.
So where a UUID might be a little bit long for a URL,
this is a little shorter
and might fit into a URL more conveniently
than some of the longer identifiers.
- Yeah, yeah.
Plus also not always,
there are scenarios where you can think
you might need an ID.
And if, I mean, even in the remote chance
that there is a collision, it might not be fatal, right?
You might be able to detect and just regenerate.
You know, that's also sometimes an option.
- Right.
- Uh-huh, interesting.
Nice.
Right, my first pick is called Versionator by Sam Dean.
And that's a nice little package.
It's a build plugin that generates a source file
with version control info.
So I think that's quite a common scenario.
And I even thought we talked about a package
like this before,
but I didn't find anything in the show notes.
So if this is a repeat mention of a,
not this package in all likelihood,
but a similar package, apologies.
But this covers the scenario where you have an app
and you want to expose version information
that is, you know, like what git hash
did generate this build, that sort of thing.
And you don't want to automatically,
you know, don't want to manually track that version number.
This plugin will generate a source file
that you can use and reference in your application
and then, you know, display it and whatnot.
It has a number of different things in the struct
that it generates, like for instance, the build count.
And this is using git under the hood
to determine these values.
So it counts the number of commits since the start.
So that's a good thing to use for build count.
The git commit, as I mentioned, the hash, the shah.
And it can generate a git describe string.
So that's typically the tag,
but it can also include additional information
if you're not exactly on a tag, it'll add some extra info.
It's really nice, you just stick that in there
and you get this source file that you can then use.
It's a bit like in the old days,
which doesn't work with git anymore,
but in older version control systems,
you could place special tags in your source code
that would be replaced by the version control system
whenever you made a commit.
CVS, if people old enough to know CVS
will know the little dollar.
I think it was $CVS$ that you put in your source code
and it replaced that under the hood.
So yeah, that's Versionator by Sam Dean.
- Fantastic.
My next package is Game Controller Kit by Wesley de Groot.
And this is predictably a package
that allows you to easily interface with game controllers
on lots of platforms,
iOS, macOS, VisionOS, tvOS.
No support yet for watchOS,
which I'm terribly disappointed about
because I desperately want to.
Actually, how would you hold the controller
and look at your watch?
Maybe that's why it doesn't support watchOS.
(laughs)
- You got there eventually.
- But...
(laughs)
It was only as I actually looked at my watch
and realized the difficulty that would cause.
So we'll forgive the lack of support for watchOS.
But yes, what it is, is it's a package
that really gives a nice, convenient programming interface
to a game controller.
Both the detection of button events and joystick events,
but also control of the haptics.
So most, if not all game controllers
have pretty sophisticated haptics these days
and you get control of...
I actually can't see at what level
you get control of the haptics,
but it does say that you get control of the haptics.
So that may just be as simple as, you know,
give it a vibrate,
or it may be something a little more subtle
like we have on the iPhone.
But yeah, I thought this was just a very,
really super simple way to get access
to an input device that you may not be thinking about
at the moment.
Comes with a demo app that for the iPhone or for the Mac,
or there's also a tvOS screenshot here,
which I guess is a great platform for game controllers
where it has every input and button mapped out
onto the screen, including things like the touchpad.
So I think it's the PlayStation controller has a touchpad.
All the trigger buttons, all the left, right, up, downs,
the X, Y, A, Bs,
and of course the two joysticks as well.
So it seems like a great and comprehensive library
to get access to that.
Should we add game controller support to SwiftPackage Index?
Is that something that people are crying out for?
- That's a tough sell, but who knows?
Maybe open a discussion first.
- That's a very polite way of saying no.
- That's a standard way of dealing with feature requests.
- Yes, please put it in a discussion.
So yes, that's a game controller kit by Wesley de Groot.
- Nice.
Right, my second pick,
I was going to snipe you in iOS Dev Weekly,
but then because we pushed it back by a week,
you actually sniped me.
And the package is called Swift Export by Frank Lefebvre.
And it's a package, it's a command line tool
to make it easier to sign and authorize executables
on macOS.
And that sounds like a great tool to help with this.
So it's been a while that I actually
redeployed my app or our SPI app.
And what I normally do, I've sort of written down the steps
that I go through in Xcode,
you know, like clicking through dialogues.
But I always love having something that I can make file
or a script that I can run that sort of encodes the steps
in like actual code that I can check in
because I can never, like a few months later,
I don't remember how to release things.
And I would absolutely use this and change this
and use this to notarize an executable
because I could then put it in a script.
So this is really nice way of automating that
and dealing with this sort of, yeah,
taking out the dialogue based distribution.
Yeah, so that's Swift Export by Frank Lefebvre.
- I believe, so I did link to that in our Dev Weekly.
And I believe it also has some extra features
like it can automate the generation
of a package-based installer.
So a .pkg file, which if you, yeah,
if you need to do additional things like, you know,
move files into places that are not just
in the applications directory, for example,
you can again automate and create a configuration file
to perform those steps as part of the installer.
And it will then generate that package installer as well.
I think as long as I didn't get it mixed up,
but I believe that's the case.
- That's great, I didn't even notice that.
That's fantastic.
- Well, I think probably because we're not going to need that
with the SPI app, because that is just a pure, simple copy
into the applications directory and you're done.
But yeah, it reminds me of the old,
and this is going back a long time now,
the old install shield.
Did you ever have to use install shield on Windows?
- Oh God, yeah, yeah.
I mean, it's still, they still run installers, right?
- It is, yeah, yeah.
It does still exist.
And I believe it still makes package,
installer packages for Mac OS, I believe.
But it's certainly, it's a bit of a,
I think it's a bit of an old technology now of that whole,
well, let's build our installer.
But certainly this would be a simpler way of doing that
than some software like that, I'm sure.
Maybe I'm being terribly unfair to install shield,
but I somehow doubt it.
- Nice.
- My final package this week is a little bit of a fun one.
I like to occasionally include a fun package
in the recommendations here,
and it's called Chip8i Emulation Core by Danijel Stracenski.
And I also hadn't heard of the Chip8 system,
which is, again, an old,
it's an old microprocessor originally used
on the Cosmac VIP and Telmac 1800
that were 18, eight-bit microcomputers in the,
from the '70s.
And what it is, is it's a swift emulation
of the, that whole processor.
So what you get as an API from Swift
is a way to load ROM files in.
So you don't get to code in the basic
or whatever the language of the thing had.
It just enables you to load the ROM files in.
And then you get to call this emulation function,
and it has 16 input keys, which, again,
so it didn't even have a full keyboard.
It had one, zero to nine numbers,
and A to F, so it could input hex, I guess,
is effectively what it could do.
And then you get to hook into various key presses.
So you can say on key down or on key up on any of the keys.
You can observe the output.
You also get a 64 by 32 grid of Boolean values,
which represent the pixel states on the screen.
So it was a very high resolution display,
which you could then represent in SwiftUI
or whatever technology you would like
to represent those pixels as.
In fact, there is an example in the readme file,
which is a Mac OS SwiftUI app that generates CG images
and lays them out on a SwiftUI display
based on this 64 by 32 bit grid of Booleans.
So it's kind of interesting that something like this
would end up emulated in Swift,
but I thought it was an interesting thing
to have a quick look at.
- That's amazing.
Actually, if you think about it, as you were talking,
I was looking at my watch and I thought,
well, this is a tiny piece of a complication on my watch.
(laughs)
- Exactly.
Yeah, I mean, 64 by 32 is really low resolution.
It's like super low resolution.
- Yeah, but it's not that far off where we started.
But my first computer was the Commodore 64,
and I think that was 320 by something or 480 by 320,
something like that.
It wasn't that much more.
I mean, a little bit more, but-
- No, not that much more, yeah.
- Not way more.
So yeah, really fun.
- So you could take a little trip down.
It's probably not exactly a trip down memory lane
because I'm not confident that many people
will have used this system listening to this podcast,
but it's always fun to look at
a bit of the history of computing.
- Yeah, absolutely.
Right, my third and final pick is called Spectricate
by Patrik Svensson.
And can I just say, great last name, Patrick.
(laughs)
The package is a library to help you
create beautiful terminal applications.
I think that's a quote I lifted from the package.
And just look at it.
If you open that up and look at the screenshot
that Patrick has placed there of a table,
a panel and a table created with it, it's just fantastic.
We had a couple of packages
to create terminal applications in the past, I believe.
And I always pick them.
So if you want to get mentioned,
I think that's a package you sort of need to create.
But it's just beautiful.
I think the UI is Swift UI like,
but even if it isn't, just look at the result.
You'll implement this with any API,
I think, to get results like this.
I recall having written a little tool
that deals with our ProSquare database in the past.
And I was looking around for packages
that output nice table views, like tables in the terminal.
And I'm very sure that that hadn't existed at the time
because I would have certainly picked it.
But it kind of makes me want to go back
and substitute that one in now.
- Yeah, I just had a look at it and it looks great.
It's really, I quite like the kind of curved edge boxes
as well as the straight edge boxes.
Is that using, they're not characters.
Are they being drawn or are they characters?
- Yeah, those are, so all these use Unicode glyphs
to generate the tables.
So this would be fully selectable and pasteable.
I mean, obviously you'd have,
you wouldn't get just the text,
you'd get the text and the Unicode stuff.
So it'll, formatting might change if you have a non,
you know, a font that doesn't support all the glyphs
or if you paste this into a proportional font thing,
then it would be messed up.
But no, it is proper text.
- I'm very familiar with the single and the double boxes
from back in the old DOS days.
But I haven't yet seen the boxes with curved corners before.
So that's news to me.
There are still characters in the Unicode character set
that I'm unfamiliar with.
- Yeah, it's beautiful, isn't it?
- That's, it is, yeah, it's great.
It takes me back to the days of Ball and IDEs
where they used the double box characters to great effect
to create all their windows and UIs.
Very fond memories of that.
There we go.
So that brings us to the end of another episode.
And if you are at the Server-Side Swift conference,
please do try and find Sven and say hello.
And if not, then we'll see you back here
in a few weeks time.
- Yep, see you in a few weeks.
Bye-bye.
- All right, bye-bye.