1
00:00:00,000 --> 00:00:02,240
Actually, I've got a little quiz for you.

2
00:00:02,240 --> 00:00:03,920
We have a quiz already, straight away?

3
00:00:03,920 --> 00:00:06,080
Well, yeah, we have a news quiz.

4
00:00:06,080 --> 00:00:06,960
Okay.

5
00:00:06,960 --> 00:00:08,880
It leads to news, I think.

6
00:00:08,880 --> 00:00:09,880
Okay.

7
00:00:09,880 --> 00:00:13,600
How do you add a package to a Swift package manifest?

8
00:00:13,600 --> 00:00:15,960
Can you, off the top of your head,

9
00:00:15,960 --> 00:00:23,840
give me the incantations you have to make to add a package?

10
00:00:23,840 --> 00:00:26,520
Well, yes I can,

11
00:00:26,520 --> 00:00:28,120
but only because I've been working on this thing to say.

12
00:00:28,120 --> 00:00:29,440
Because you've cheated, right?

13
00:00:29,440 --> 00:00:35,480
Yes, I have cheated.

14
00:00:35,480 --> 00:00:36,480
So what is it?

15
00:00:36,480 --> 00:00:39,800
Because I think there's a, there's a, there's a part of it that you probably

16
00:00:39,800 --> 00:00:44,000
don't know, even, even though you've stared at this earlier this week.

17
00:00:44,000 --> 00:00:44,600
Okay.

18
00:00:44,600 --> 00:00:45,160
Okay.

19
00:00:45,160 --> 00:00:52,880
So you add the dot package clause in whatever the top area is, you find the

20
00:00:52,880 --> 00:00:57,040
top area, whether, where all the other package clauses are and you add one

21
00:00:57,040 --> 00:01:01,440
alongside it right? That's the technical, that's exactly what it says in the instructions.

22
00:01:01,440 --> 00:01:02,960
That's what it says in the docs, yep.

23
00:01:02,960 --> 00:01:09,040
And then you find all of the other product areas and you've got a product.

24
00:01:09,040 --> 00:01:16,480
Yeah right, so that's the target dependencies, yeah right and there it's dot product and name

25
00:01:16,480 --> 00:01:21,600
and package goes in there. It's always, it's never quite clear which one it actually is,

26
00:01:22,720 --> 00:01:28,240
But even in the top section, that's, and what I'm alluding to is we've started some work around

27
00:01:28,240 --> 00:01:35,200
making package instructions easier. And it is actually quite easy if you're working in an

28
00:01:35,200 --> 00:01:41,200
Xcode project because Xcode has some references for adding packages to your project. And even

29
00:01:41,200 --> 00:01:49,120
just by importing something, if you import a product that Xcode knows about via some mechanism,

30
00:01:49,120 --> 00:01:55,040
I think it's if it's in a package collection that you've added to your list of package collections

31
00:01:55,040 --> 00:02:00,800
Xcode knows about, then if you do an import statement of a product, it'll actually automatically

32
00:02:00,800 --> 00:02:07,520
add, do all the things that need to be done and add the package to your manifest. Now,

33
00:02:07,520 --> 00:02:13,840
this only works if you have an Xcode project file. And if you're working in an actual Xcode project,

34
00:02:13,840 --> 00:02:21,920
this does not work if you are working on a on a pure Swift package. In that case, you actually need

35
00:02:21,920 --> 00:02:27,440
to go into the package manifest and add stuff. And for quite a while, we've had something to help you

36
00:02:27,440 --> 00:02:31,840
at least a little bit with that because even the package clause, the first thing you mentioned,

37
00:02:31,840 --> 00:02:38,880
adding the package dependency to the package clause, the top part of your package manifest,

38
00:02:39,920 --> 00:02:46,240
even that is that line dot package. You're not done there because you need to specify what package

39
00:02:46,240 --> 00:02:50,720
version you actually want, right? And there's different variants of how you specify that.

40
00:02:50,720 --> 00:02:57,360
Typically it's from colon and then you give a start version and then from that start version,

41
00:02:57,360 --> 00:03:05,600
it picks the highest released version on the same major version. So if you do 1.0.0,

42
00:03:05,600 --> 00:03:13,120
it'll take any 1.xy version with the highest x and y possible. But there are a couple of other

43
00:03:13,120 --> 00:03:18,320
variants of that and we do support that. For instance, if a package has a beta release,

44
00:03:18,320 --> 00:03:25,040
which would be a branch version that you're following, then it has a slightly different

45
00:03:25,040 --> 00:03:29,440
clause. And I think the clause is, and I don't even know, I'd have to look, I think it's branch

46
00:03:29,440 --> 00:03:33,360
colon and then the branch name. So honestly, just to interject on that,

47
00:03:33,360 --> 00:03:40,320
I've not done that manually since the Swift package index existed because we do have those

48
00:03:40,320 --> 00:03:45,920
for the latest stable version and the latest default branch. And if there's a beta version,

49
00:03:45,920 --> 00:03:50,720
we have all of those ready. And I've not typed that in manually in a couple of years now.

50
00:03:50,720 --> 00:03:54,000
Stay Forever Yeah. But the thing is that we're working

51
00:03:54,000 --> 00:03:59,040
towards an adding and that was spawned by a little discussion on Mastodon where Matt Mazzucotti

52
00:03:59,760 --> 00:04:04,400
questioned whether it's actually useful to put installation instructions in your readme.

53
00:04:04,400 --> 00:04:10,720
And a few people were quick to point out, well, it kind of is important because, because of these,

54
00:04:10,720 --> 00:04:16,400
you know, intricacies of, of what you need to add. And, you know, you might know the package name,

55
00:04:16,400 --> 00:04:20,800
you might not necessarily know the product name, and then, you know, you certainly want some

56
00:04:20,800 --> 00:04:27,280
instructions on what to add. And the thing we're looking to add, as triggered by that discussion,

57
00:04:27,280 --> 00:04:33,520
although we did have an issue in our list already, was to help with the second part of that, and

58
00:04:33,520 --> 00:04:41,600
that is the product clause, or rather the product dependency in your target. And there we're looking,

59
00:04:41,600 --> 00:04:47,520
because we have all the information from the package manifest, so we know what products a

60
00:04:47,520 --> 00:04:56,320
package exports, so we can provide a selection dropdown UI element where you can pick the product

61
00:04:56,320 --> 00:05:00,320
that you want to add, and then we can write out the product clause that we need to copy,

62
00:05:00,320 --> 00:05:05,920
at least help with that bit of it. And that's what this little quiz was about, you know,

63
00:05:05,920 --> 00:05:11,600
have this all in one place so that package authors can just point there rather than

64
00:05:11,600 --> 00:05:18,320
have this set up. And it will then automatically also always be up to date. So if you rename your

65
00:05:18,320 --> 00:05:25,200
products in your manifest, you don't need to worry about your readme going out of date and stuff like

66
00:05:25,200 --> 00:05:31,120
that. It'll all be almost up to date on that installation page. And I think that's a great

67
00:05:31,120 --> 00:05:38,000
idea, especially the concept of being able to link to that. So at the moment, and it will continue to

68
00:05:38,000 --> 00:05:47,520
work this way, the "use this package" button on any package page does like a popover where it presents

69
00:05:47,520 --> 00:05:52,800
the information. If you're using Xcode, here's the URL that you paste into Xcode. And if you're using

70
00:05:52,800 --> 00:05:57,520
package.swift manifest, then here are and it will be the both the package clause

71
00:05:57,520 --> 00:06:03,320
and the product clause as you say. The fact that that's a popover will remain

72
00:06:03,320 --> 00:06:09,600
but we will give people a mechanism to link directly to their package page with

73
00:06:09,600 --> 00:06:13,920
that already popped over so that you can link it as installation

74
00:06:13,920 --> 00:06:17,960
instructions in your package readme. Yeah that'd be really nice, really nice to have.

75
00:06:17,960 --> 00:06:23,320
We also discussed - and this is not going to be in the first deploy of this

76
00:06:23,320 --> 00:06:31,440
feature - but we also discussed having a preview of a package manifest

77
00:06:31,440 --> 00:06:38,400
syntax highlighted with the code that you're kind of selecting with the

78
00:06:38,400 --> 00:06:45,960
by picking the version and the product in there too. Now I'm not sure how

79
00:06:45,960 --> 00:06:50,520
necessary that is, but it is the kind of thing that, especially for people just

80
00:06:50,520 --> 00:06:56,240
getting started with adding dependencies to pure Swift projects, that could be

81
00:06:56,240 --> 00:07:00,360
helpful. Yeah, I think it would be really interesting to hear what people think

82
00:07:00,360 --> 00:07:07,760
because I believe we are... it's really hard to think back how weird that was

83
00:07:07,760 --> 00:07:12,120
adding a package dependency the first time because, I mean, even though I can't

84
00:07:12,120 --> 00:07:17,080
remember the syntax. I at least remember there's two things to do and roughly where to put them,

85
00:07:17,080 --> 00:07:22,120
and then there's enough scaffolding there to guide me. I couldn't type a package manifest,

86
00:07:22,120 --> 00:07:28,120
just type it out for the life of me. I just couldn't. I always need a template.

87
00:07:28,120 --> 00:07:33,480
But I'd be really interested to hear if people think this is actually useful to see it in the

88
00:07:33,480 --> 00:07:39,080
context of a manifest, to see where stuff needs to go, or if that's just noise. It's hard to

89
00:07:39,080 --> 00:07:41,320
judge when you're sort of familiar enough with it.

90
00:07:41,320 --> 00:07:44,920
- And if we could take a look over in Apple's direction just for a second, I think

91
00:07:44,920 --> 00:07:51,720
Xcode being able to manipulate package manifest files better would be an amazing step forward.

92
00:07:51,720 --> 00:07:59,880
- Oh yeah, yeah, definitely. I do vaguely remember there was talk about a Swift PM command,

93
00:07:59,880 --> 00:08:08,440
like add package that would then add it to the manifest. But I don't think that went anywhere.

94
00:08:08,440 --> 00:08:11,120
or I'm not sure what state that proposal is in,

95
00:08:11,120 --> 00:08:13,160
but it was talked about at least.

96
00:08:13,160 --> 00:08:15,080
- I just want Xcode to do it.

97
00:08:15,080 --> 00:08:16,200
- Yeah, yeah.

98
00:08:16,200 --> 00:08:18,280
Well, when I say Swift PM,

99
00:08:18,280 --> 00:08:21,960
I kind of assume that Xcode would gain that capability

100
00:08:21,960 --> 00:08:25,880
then also for pure Swift packages.

101
00:08:25,880 --> 00:08:28,080
It's always a bit weird.

102
00:08:28,080 --> 00:08:33,080
Xcode is this thing that has this Xcode project

103
00:08:33,080 --> 00:08:36,960
kind of mechanism and then Swift PM kind of mechanism,

104
00:08:36,960 --> 00:08:39,200
and they're not the same.

105
00:08:39,200 --> 00:08:44,200
It's hard to really talk about it.

106
00:08:44,200 --> 00:08:47,140
It's almost like it has two different modes of operation

107
00:08:47,140 --> 00:08:48,120
in those contexts.

108
00:08:48,120 --> 00:08:48,960
It's kind of weird.

109
00:08:48,960 --> 00:08:51,780
- And I had a standing prediction for a few years

110
00:08:51,780 --> 00:08:56,780
in IOS Dev Weekly just before the conference every year

111
00:08:56,780 --> 00:09:00,300
that my standing prediction was this would be the year

112
00:09:00,300 --> 00:09:02,660
that they would choose Xcode Project

113
00:09:02,660 --> 00:09:06,940
or package manifest file and just have one.

114
00:09:06,940 --> 00:09:09,480
And that hasn't happened yet, so I've stopped predicting it.

115
00:09:09,480 --> 00:09:12,620
- Yeah, well, for that to work, it would actually start,

116
00:09:12,620 --> 00:09:15,640
need to start supporting iOS apps and all that

117
00:09:15,640 --> 00:09:18,000
from a package manifest, right?

118
00:09:18,000 --> 00:09:19,500
- That was where I thought they would, yeah,

119
00:09:19,500 --> 00:09:21,260
that's where I thought they would start going with it,

120
00:09:21,260 --> 00:09:24,100
but it does not seem to be the current,

121
00:09:24,100 --> 00:09:25,660
I mean, it may be the plan for the future,

122
00:09:25,660 --> 00:09:27,260
but it does not seem to be the current plan.

123
00:09:27,260 --> 00:09:29,340
- I mean, it has to at some point, right?

124
00:09:29,340 --> 00:09:33,100
I do wonder if that might happen in the context of a,

125
00:09:33,100 --> 00:09:35,400
there was a pitch, it's quite a while ago now,

126
00:09:35,400 --> 00:09:41,280
to redo the package manifest and do it in a, um, what's it called?

127
00:09:41,280 --> 00:09:47,040
The builder, um, mechanism, you know, like the DSL mechanism to go away, you know,

128
00:09:47,040 --> 00:09:53,800
from this, um, struct that you fill in kind of mechanism to, uh, a, a builder

129
00:09:53,800 --> 00:09:55,080
DSL kind of mechanism.

130
00:09:55,080 --> 00:09:58,960
And I wonder if that might happen all at the same time, maybe for Swift six or

131
00:09:58,960 --> 00:10:02,040
something that, that, that format will change and then incorporate the other

132
00:10:02,040 --> 00:10:03,800
things at the same time.

133
00:10:03,800 --> 00:10:04,480
I don't know.

134
00:10:04,560 --> 00:10:09,560
But I do feel it's not ideal the way it is right now.

135
00:10:09,560 --> 00:10:13,920
- So anyway, the good news is it will get

136
00:10:13,920 --> 00:10:16,860
a little bit easier if we, or should I say,

137
00:10:16,860 --> 00:10:19,040
when we deploy these improvements.

138
00:10:19,040 --> 00:10:20,040
- Yeah, definitely.

139
00:10:20,040 --> 00:10:23,320
- There's another thing which has been going on this week.

140
00:10:23,320 --> 00:10:25,380
At the end of, it was actually at the end of last week,

141
00:10:25,380 --> 00:10:30,380
that we submitted a pull request onto Swift.org

142
00:10:31,500 --> 00:10:35,460
with the first stage of an integration

143
00:10:35,460 --> 00:10:37,980
between some of the data coming out

144
00:10:37,980 --> 00:10:39,340
of the Swift package index

145
00:10:39,340 --> 00:10:42,180
and the official Swift.org website.

146
00:10:42,180 --> 00:10:44,260
So this is something we've been working on

147
00:10:44,260 --> 00:10:45,300
for a little while now.

148
00:10:45,300 --> 00:10:49,300
And it's in pull request at the moment.

149
00:10:49,300 --> 00:10:53,340
So this is very much a kind of first step

150
00:10:53,340 --> 00:10:56,980
towards some kind of integration between the two sites.

151
00:10:56,980 --> 00:10:59,780
And the first thing that we're doing there

152
00:10:59,780 --> 00:11:01,640
is some package lists.

153
00:11:01,640 --> 00:11:05,700
So we've proposed a new page on Swift.org

154
00:11:05,700 --> 00:11:09,420
and it's in the top level menu as packages.

155
00:11:09,420 --> 00:11:14,180
And you can, in fact, you can actually see a mock-up

156
00:11:14,180 --> 00:11:16,700
or a prototype of what we are proposing

157
00:11:16,700 --> 00:11:18,820
to merge into the site.

158
00:11:18,820 --> 00:11:22,180
If you go to the Swift.org open source project

159
00:11:22,180 --> 00:11:25,340
and look for the issue that was opened by me.

160
00:11:25,340 --> 00:11:30,020
And the very first title in that issue is a link

161
00:11:30,020 --> 00:11:34,700
to the hosted prototype that we've got.

162
00:11:34,700 --> 00:11:37,180
So it's a packages page, and on that page

163
00:11:37,180 --> 00:11:42,060
is a list of currently three sets of different packages.

164
00:11:42,060 --> 00:11:44,200
There's one called Community Showcase,

165
00:11:44,200 --> 00:11:46,520
which is going to link to packages

166
00:11:46,520 --> 00:11:49,120
that we mention here on this podcast.

167
00:11:49,120 --> 00:11:51,620
And actually, this is, the reason I'm talking about this,

168
00:11:51,620 --> 00:11:54,780
one of the reasons is we would love to know

169
00:11:54,780 --> 00:11:59,500
if you write a newsletter or run a podcast

170
00:11:59,500 --> 00:12:01,520
or something like that where you talk

171
00:12:01,520 --> 00:12:03,720
about other people's Swift packages.

172
00:12:03,720 --> 00:12:06,900
And if you do, please get in touch.

173
00:12:06,900 --> 00:12:08,660
You can get in touch via our Discord,

174
00:12:08,660 --> 00:12:10,940
which we'll link in the show notes,

175
00:12:10,940 --> 00:12:14,620
because we'd love to get more sources of people

176
00:12:14,620 --> 00:12:18,420
talking and writing about the package ecosystem

177
00:12:18,420 --> 00:12:23,420
and include those packages on the Community Showcase section

178
00:12:23,860 --> 00:12:25,900
of this new packages page.

179
00:12:25,900 --> 00:12:28,940
We then have a couple, and I think this will be expanded

180
00:12:28,940 --> 00:12:30,940
before the pull request is merged,

181
00:12:30,940 --> 00:12:33,760
a couple of lists based on keywords.

182
00:12:33,760 --> 00:12:37,100
So we currently have packages that are referenced

183
00:12:37,100 --> 00:12:41,420
by the networking keyword and the testing keyword,

184
00:12:41,420 --> 00:12:43,600
but I think we're gonna potentially expand that

185
00:12:43,600 --> 00:12:46,500
a little bit more before we look at merging it.

186
00:12:46,500 --> 00:12:49,360
And of course, there will be a whole process of review

187
00:12:49,360 --> 00:12:50,900
before any of this gets merged.

188
00:12:50,900 --> 00:12:52,700
So this is not just gonna go straight through,

189
00:12:52,700 --> 00:12:57,220
This is genuinely an open source pull request

190
00:12:57,220 --> 00:12:59,260
that's gonna go through to the site

191
00:12:59,260 --> 00:13:00,580
and we hope that it gets merged,

192
00:13:00,580 --> 00:13:04,060
but of course it may look different to what we proposed

193
00:13:04,060 --> 00:13:05,660
by the time that happens.

194
00:13:05,660 --> 00:13:08,500
- And of course the list would be changing,

195
00:13:08,500 --> 00:13:10,420
I mean not daily or anything,

196
00:13:10,420 --> 00:13:15,420
but they'd be on a refresh cycle of some sort,

197
00:13:15,420 --> 00:13:16,780
maybe a couple of weeks.

198
00:13:16,780 --> 00:13:19,580
But the idea would be obviously that they,

199
00:13:19,580 --> 00:13:22,660
especially the categories are collecting packages

200
00:13:22,660 --> 00:13:28,740
that are good starting points for certain topics like networking and testing as

201
00:13:28,740 --> 00:13:33,700
the examples that would host packages there that you should take a look at if

202
00:13:33,700 --> 00:13:35,580
you're working in that realm.

203
00:13:35,580 --> 00:13:43,020
Something else I kind of thought of, but might be a nice section as I was

204
00:13:43,020 --> 00:13:49,120
preparing for the podcast, and that was highlighting packages that coincide

205
00:13:49,120 --> 00:13:50,340
with new language features.

206
00:13:50,340 --> 00:13:55,340
So for instance, when Swift 5.9 comes out officially,

207
00:13:55,340 --> 00:13:57,060
I mean, obviously we're already using it,

208
00:13:57,060 --> 00:13:58,320
we're even already testing it,

209
00:13:58,320 --> 00:14:01,460
but it's in pre-release form.

210
00:14:01,460 --> 00:14:03,880
But it might be interesting to have a section

211
00:14:03,880 --> 00:14:05,720
about macro packages, for instance,

212
00:14:05,720 --> 00:14:07,960
when 5.9 officially comes out

213
00:14:07,960 --> 00:14:10,680
and more people will start adopting it.

214
00:14:10,680 --> 00:14:13,340
Obviously people are beginning to adopt it now,

215
00:14:13,340 --> 00:14:16,200
but I guess we're early days in the adoption curve.

216
00:14:16,200 --> 00:14:17,200
So in September,

217
00:14:17,200 --> 00:14:20,100
maybe there might be an interesting collection to have.

218
00:14:20,100 --> 00:14:22,640
And then obviously, you know, other Swift languages,

219
00:14:22,640 --> 00:14:25,500
language versions will have other things.

220
00:14:25,500 --> 00:14:27,160
So stuff like that might be interesting as well

221
00:14:27,160 --> 00:14:29,240
for a section there.

222
00:14:29,240 --> 00:14:30,220
- We could definitely do that.

223
00:14:30,220 --> 00:14:32,300
And that could also be one of the,

224
00:14:32,300 --> 00:14:36,980
so the testing and networking tagged packages,

225
00:14:36,980 --> 00:14:38,580
they're not fully automated,

226
00:14:38,580 --> 00:14:42,380
but we do have a tool that will generate the data

227
00:14:42,380 --> 00:14:47,200
that goes into the Swift.org website for those two tags.

228
00:14:47,200 --> 00:14:50,060
And anything that could go through our search system,

229
00:14:50,060 --> 00:14:53,180
So for example, we can now search on packages

230
00:14:53,180 --> 00:14:57,700
that have the macro product type in there.

231
00:14:57,700 --> 00:15:00,620
We could do a similar thing for really anything

232
00:15:00,620 --> 00:15:02,780
on that search criteria, couldn't we?

233
00:15:02,780 --> 00:15:05,140
- Yeah, yeah, definitely.

234
00:15:05,140 --> 00:15:07,300
I mean, it's a question, open question,

235
00:15:07,300 --> 00:15:09,420
how long those lists should be.

236
00:15:09,420 --> 00:15:13,220
We probably need to sort and truncate at some point,

237
00:15:13,220 --> 00:15:16,500
but it's certainly easy to at least get started

238
00:15:16,500 --> 00:15:22,340
their list and then go through and apply some further selection criteria, I guess.

239
00:15:22,340 --> 00:15:29,860
So if you have, either if you do something yourself or if you know of somebody who is

240
00:15:29,860 --> 00:15:35,780
interested in talking about Swift packages, maybe a podcast that you listen to has a section or

241
00:15:35,780 --> 00:15:41,620
something like that where people can pick a package. Pick a package? It's a tongue twister.

242
00:15:43,940 --> 00:15:50,660
Yeah, please do get in touch and we'll see if we can get something more structured together

243
00:15:50,660 --> 00:15:53,860
to do with how the Community Showcase packages are built up.

244
00:15:53,860 --> 00:15:58,420
Yeah, or even just for the podcast, let us know if... I mean, we do monitor

245
00:15:58,420 --> 00:16:04,340
new additions to the index or releases and stuff like that. But there's enough coming in now

246
00:16:04,340 --> 00:16:12,580
that it's easy to miss one or maybe not give it the attention it deserves. And a ping and a nudge

247
00:16:12,580 --> 00:16:19,540
is a great way to highlight a package that is worth talking about. And then we discussed that

248
00:16:19,540 --> 00:16:24,340
one of the sections, I mean, obviously our podcast would also be a source of input for that community

249
00:16:24,340 --> 00:16:29,140
selection. So that's certainly a good way of getting something in. Yeah, absolutely.

250
00:16:29,140 --> 00:16:34,500
There's one thing I noticed looking at these lists, and I wonder if you feel the same. And

251
00:16:34,500 --> 00:16:40,100
I think I even mentioned this before. When I look at this networking packages, the first package is

252
00:16:40,100 --> 00:16:46,500
Swift-neo. Then we have alarmofire, Pulse, Moya. It strikes me there's a,

253
00:16:46,500 --> 00:16:54,100
there's this weird inconsistency about Swift package names. We have a couple others that

254
00:16:54,100 --> 00:17:02,500
sprung out and I think it's, I got reminded because this is one of the few areas that I've

255
00:17:02,500 --> 00:17:07,060
seen multiple packages listed side by side and then it becomes more pronounced. Like we have

256
00:17:07,060 --> 00:17:13,140
combined Dash schedulers, all lowercase, Swift Dash, Snapshot Dash testing, all lowercase.

257
00:17:13,140 --> 00:17:21,300
So we have a couple of packages that follow, I think it's Apple's guideline to have these package

258
00:17:21,300 --> 00:17:26,580
names that are lowercase and K-Bop case, you know, with dashes in between the words.

259
00:17:26,580 --> 00:17:34,420
Interestingly, the very first word in Swift Neo is, Swift Neo is an open source network

260
00:17:34,420 --> 00:17:39,220
application framework and Swift Neo there is spelled like Swift Data or Swift UI.

261
00:17:39,220 --> 00:17:41,660
It's Swift and then capital N I O.

262
00:17:41,660 --> 00:17:46,300
So apparently the actual package name is Swift Neo.

263
00:17:46,300 --> 00:17:50,700
Like, like I just described in the Swift UI kind of spelling.

264
00:17:50,700 --> 00:17:53,300
It's weird to me that the.

265
00:17:53,300 --> 00:17:59,780
Identifier that is used in the package manifest is sort of like an identifier

266
00:17:59,780 --> 00:18:03,580
type label, you know, it's, it's almost as if something's leaking out that

267
00:18:03,580 --> 00:18:07,540
shouldn't be leaking out and the proper package name should be something else.

268
00:18:07,540 --> 00:18:11,040
And I wonder if that's ever going to change, if there's ever going to be

269
00:18:11,040 --> 00:18:16,260
some sort of guideline, what the, what the name should be, but I, it strikes

270
00:18:16,260 --> 00:18:20,360
me as weird that these, these names pop up like this and, and we're not

271
00:18:20,360 --> 00:18:25,240
doing anything special, we're picking the package name here as it is defined

272
00:18:25,240 --> 00:18:28,320
in the package manifest and it could very well be something different.

273
00:18:28,340 --> 00:18:33,340
I'm a bit puzzled why it's been chosen like this.

274
00:18:33,340 --> 00:18:36,300
I don't know, do you feel the same

275
00:18:36,300 --> 00:18:40,140
or is that just me being OCD?

276
00:18:40,140 --> 00:18:41,460
- Don't get me started.

277
00:18:41,460 --> 00:18:44,620
(both laughing)

278
00:18:44,620 --> 00:18:46,780
My biggest problem with all of this

279
00:18:46,780 --> 00:18:48,420
is why do we need Swift in the name?

280
00:18:48,420 --> 00:18:50,160
- Yes, yeah, yeah.

281
00:18:50,160 --> 00:18:52,540
- I mean, I can understand.

282
00:18:52,540 --> 00:18:55,220
So on GitHub, if you want your repository

283
00:18:55,220 --> 00:18:56,740
to be descriptive on GitHub,

284
00:18:56,740 --> 00:19:00,540
where it lives in an ecosystem of every possible language.

285
00:19:00,540 --> 00:19:01,820
I can understand it there.

286
00:19:01,820 --> 00:19:05,700
But why in the package name are we including the word Swift?

287
00:19:05,700 --> 00:19:07,560
I do not understand it.

288
00:19:07,560 --> 00:19:13,400
My personal preference would be to just use camel case.

289
00:19:13,400 --> 00:19:16,580
Sorry, not camel case, what they call it.

290
00:19:16,580 --> 00:19:17,940
The one where every letter is capitalized.

291
00:19:17,940 --> 00:19:19,140
- Pascal case.

292
00:19:19,140 --> 00:19:20,540
- Pascal case, that's right.

293
00:19:20,540 --> 00:19:23,860
Yeah, my personal preference would be for Pascal case

294
00:19:23,860 --> 00:19:24,940
or something like that.

295
00:19:24,940 --> 00:19:29,940
But I don't really care what we pick as a community.

296
00:19:29,940 --> 00:19:32,980
You mentioned an Apple guideline.

297
00:19:32,980 --> 00:19:35,420
I'm not familiar with an Apple guideline.

298
00:19:35,420 --> 00:19:37,420
I'm only familiar with the way they've started

299
00:19:37,420 --> 00:19:39,120
to name all their packages.

300
00:19:39,120 --> 00:19:42,040
So maybe that's referencing a guideline I haven't seen.

301
00:19:42,040 --> 00:19:45,460
But it does seem to be hyphens and all lowercase.

302
00:19:45,460 --> 00:19:47,380
But they all also include the word Swift,

303
00:19:47,380 --> 00:19:49,140
which baffles me.

304
00:19:49,140 --> 00:19:51,660
- I mean, by all means, call your repository Swift-

305
00:19:51,660 --> 00:19:54,120
if it's on GitHub and you really want to be sure

306
00:19:54,120 --> 00:19:58,360
that people don't stumble into your project thinking it's Rust or something.

307
00:19:58,360 --> 00:20:02,940
But the package name, I mean, I mentioned this before, like if you look in your

308
00:20:02,940 --> 00:20:07,500
sidebar in Xcode and you look at dependencies, it's Swift-Swift-Swift- it's

309
00:20:07,500 --> 00:20:11,960
all Swift- and there's so much noise in there and you can't even tell at first

310
00:20:11,960 --> 00:20:13,360
glance what your dependencies are.

311
00:20:13,360 --> 00:20:17,840
And then there are the sort order because some actually start with S and

312
00:20:17,840 --> 00:20:20,220
they're mixed in with all the Swift ones.

313
00:20:20,220 --> 00:20:21,600
And it's, it's a huge mess.

314
00:20:21,600 --> 00:20:28,300
And I understand why, why we've gone down this path to, to leak all this, you

315
00:20:28,300 --> 00:20:29,480
know, it's like, we're not naming.

316
00:20:29,480 --> 00:20:34,280
I mean, I know in Fortran, you used to, in your variable names, you'd have the type,

317
00:20:34,280 --> 00:20:40,680
you know, an integer type, I think started or ended with an I, um, and F for real, R

318
00:20:40,680 --> 00:20:44,740
for real and, and, you know, we're not doing that anymore because the type system

319
00:20:44,740 --> 00:20:46,180
can actually reflect that properly.

320
00:20:47,140 --> 00:20:53,380
But we're always tacking stuff into names when there's no need.

321
00:20:53,380 --> 00:20:54,340
It's bizarre.

322
00:20:54,340 --> 00:20:55,700
I don't like it.

323
00:20:55,700 --> 00:20:56,500
Yeah.

324
00:20:56,500 --> 00:21:04,260
I forget what the convention was called, but I think that it was very popular in

325
00:21:04,260 --> 00:21:09,460
the C days and you would encode the type in your variable name.

326
00:21:09,460 --> 00:21:14,540
So the one I always remember is LPSZ and then a name, which was a long

327
00:21:14,540 --> 00:21:16,700
pointer to a string zero terminated.

328
00:21:16,700 --> 00:21:22,380
And then the name of your variable. And I agree, we don't do that anymore and that's

329
00:21:22,380 --> 00:21:23,380
a good thing.

330
00:21:23,380 --> 00:21:27,380
But that's weird. I thought everything was just "void* in C".

331
00:21:27,380 --> 00:21:31,700
Do you remember the naming convention name? I forgot.

332
00:21:31,700 --> 00:21:32,700
But in C? No.

333
00:21:32,700 --> 00:21:37,700
Yeah, in C, where you did the LPSZ and I and whatever.

334
00:21:37,700 --> 00:21:42,540
No, no, no. I never really did that. I remember it in Fortran.

335
00:21:42,540 --> 00:21:43,740
Was it Hungarian?

336
00:21:43,740 --> 00:21:49,580
I think it might even have been required in Fortran. That's all I know. I only use C with

337
00:21:49,580 --> 00:21:55,420
proper variable names. I think it might have been Hungarian notation. I think that might have been

338
00:21:55,420 --> 00:22:03,020
the name of it, but I'm not sure. Somebody I'm sure is going to point out that I'm incorrect.

339
00:22:03,020 --> 00:22:09,420
We'll be sure to follow up. The other thing we should just briefly talk about before we move

340
00:22:09,420 --> 00:22:17,500
onto package recommendations is our sponsors. So for quite a while now we've had the support

341
00:22:17,500 --> 00:22:24,200
of a couple of corporate sponsors. We've had both Stream and Emerge Tools, who have both

342
00:22:24,200 --> 00:22:31,860
very kindly supported the site for, I think, over a year now. In fact, yeah, way over a

343
00:22:31,860 --> 00:22:37,820
year. And they have been just wonderful. They believed in the

344
00:22:37,820 --> 00:22:43,540
project from the very beginning. And we thank them so much for

345
00:22:43,540 --> 00:22:47,280
their support. But what we don't want to do is just have the same

346
00:22:47,280 --> 00:22:49,700
set of sponsors over and over again. And we want to keep the

347
00:22:49,700 --> 00:22:52,820
site a little bit fresh. We want to make sure that people coming

348
00:22:52,820 --> 00:22:58,060
to the site see different links every now and then. And so we've

349
00:22:58,060 --> 00:23:04,600
been in conversations with a couple of new companies who just went live with

350
00:23:04,600 --> 00:23:10,940
their sponsorships on the site last week. So those companies are Point Free and

351
00:23:10,940 --> 00:23:15,100
Telemetry Deck. So why don't you tell us a bit about those two companies.

352
00:23:15,100 --> 00:23:22,260
Yeah so Point Free you might know Brandon Williams and Stephen Celis who

353
00:23:22,260 --> 00:23:26,660
are creating a great video series about architecture testing and

354
00:23:26,660 --> 00:23:30,740
more. It's a really great site, you should check it out. I use that stuff personally.

355
00:23:30,740 --> 00:23:35,300
They have lots of open source packages as well, so that's a really great place to check.

356
00:23:35,300 --> 00:23:41,620
Telemetry Deck is a service providing lightweight privacy focused analytics for

357
00:23:41,620 --> 00:23:47,700
apps and websites, so that's also a great place to check out. I think in particular recently there

358
00:23:47,700 --> 00:23:54,820
was a change with Google Analytics not being supported anymore. I think you can't use it in

359
00:23:54,820 --> 00:24:01,300
the EU anymore. So that might be a good reason to look at Telemetry Deck to change your analytics

360
00:24:01,300 --> 00:24:08,500
on your website. I think just like with Stream and Emerge tools, the key thing about both of these

361
00:24:08,500 --> 00:24:13,860
new sponsors is they are part of this community. This is not some company that's just kind of

362
00:24:13,860 --> 00:24:19,220
coming in looking for the eyeballs of iOS developers. I mean, I'm sure they would love it

363
00:24:19,220 --> 00:24:21,200
if you went and checked out what they do.

364
00:24:21,200 --> 00:24:26,200
But Stream, Emerge Tools, Telemetry Deck, and Point Free

365
00:24:26,200 --> 00:24:28,880
are all absolutely at the heart of this community as well.

366
00:24:28,880 --> 00:24:32,460
And that's really important to us because we want to,

367
00:24:32,460 --> 00:24:34,220
you know, we don't want to overload the site

368
00:24:34,220 --> 00:24:36,920
with advertising and that was something that we've been

369
00:24:36,920 --> 00:24:42,600
very keen to keep top of our minds since the beginning.

370
00:24:42,600 --> 00:24:47,060
But we do have a little bit of advertising on the homepage.

371
00:24:48,720 --> 00:24:52,120
But I think it's better if that advertising comes from the community,

372
00:24:52,120 --> 00:24:53,320
and that's what we're trying to do here.

373
00:24:53,320 --> 00:24:58,440
It's also worth just noting that this is not any increase in the number of

374
00:24:58,440 --> 00:25:00,720
adverts or the amount of advertising or anything like that.

375
00:25:00,720 --> 00:25:07,680
This is just rotating around some sponsors and we would love to have Stream

376
00:25:07,680 --> 00:25:10,240
and EmojTools back at some time in the future, and they would love to come back

377
00:25:10,240 --> 00:25:13,400
at some point, but we want to keep that cycle fresh.

378
00:25:13,400 --> 00:25:14,160
Yeah, definitely.

379
00:25:14,160 --> 00:25:17,280
I do think there's a real indie vibe there.

380
00:25:17,280 --> 00:25:21,040
I did mention Brandon and Steven.

381
00:25:21,040 --> 00:25:22,880
I should also mention Daniel Jiig,

382
00:25:22,880 --> 00:25:24,960
who's the creator of Telemetry Deck.

383
00:25:24,960 --> 00:25:28,680
And these are, you know, just indie developers

384
00:25:28,680 --> 00:25:31,240
that have started these companies

385
00:25:31,240 --> 00:25:33,960
and they're now supporting us and that's just great.

386
00:25:33,960 --> 00:25:36,240
- And Lisa Figas as well is at Telemetry Deck too.

387
00:25:36,240 --> 00:25:39,000
- Right, yeah, sorry, I only knew of Daniel.

388
00:25:39,000 --> 00:25:39,840
- No problem.

389
00:25:39,840 --> 00:25:43,920
Yes, I've been doing most of the conversations with them.

390
00:25:43,920 --> 00:25:47,160
So yeah, thank you so much to our new sponsors

391
00:25:47,160 --> 00:25:49,980
And thank you also to our sponsors

392
00:25:49,980 --> 00:25:52,460
who are currently cycling out.

393
00:25:52,460 --> 00:25:55,060
So that's just a little bit of an update

394
00:25:55,060 --> 00:25:56,640
on the sponsorship of the site.

395
00:25:56,640 --> 00:26:00,240
Of course, the other main sponsorship we have

396
00:26:00,240 --> 00:26:02,260
is we have GitHub sponsors.

397
00:26:02,260 --> 00:26:06,440
So if you can go to any of our open source repositories,

398
00:26:06,440 --> 00:26:09,100
there should be a button there for GitHub sponsors.

399
00:26:09,100 --> 00:26:12,780
Or on the site itself, just above the two advertisements

400
00:26:12,780 --> 00:26:17,780
is a button for how to support us on GitHub sponsors.

401
00:26:17,780 --> 00:26:21,180
And then of course the other sponsor that we have is Apple.

402
00:26:21,180 --> 00:26:23,100
And you can see all of that information

403
00:26:23,100 --> 00:26:26,620
on our supporters page, which is on the home page,

404
00:26:26,620 --> 00:26:29,740
linked from the menu bar on the home page of the site.

405
00:26:29,740 --> 00:26:30,560
- There you go.

406
00:26:30,560 --> 00:26:32,580
- So thank you so much to all of everybody

407
00:26:32,580 --> 00:26:33,820
who keeps this project going.

408
00:26:33,820 --> 00:26:35,580
- Absolutely, thank you.

409
00:26:35,580 --> 00:26:38,700
- All right, let's do some recommendations.

410
00:26:38,700 --> 00:26:39,980
- Do you wanna kick us off?

411
00:26:39,980 --> 00:26:43,020
Let's start with a package called Color Toolbox.

412
00:26:43,020 --> 00:26:46,680
I'm continuing my theme of color-based packages

413
00:26:46,680 --> 00:26:48,820
from last episode.

414
00:26:48,820 --> 00:26:52,260
Color Toolbox by Ramon Torres.

415
00:26:52,260 --> 00:26:55,860
And this is, unlike the last one that I mentioned,

416
00:26:55,860 --> 00:26:59,620
this is not a color palette library.

417
00:26:59,620 --> 00:27:04,620
This is a individual color utility library.

418
00:27:04,620 --> 00:27:09,220
So it provides, it's not a huge package.

419
00:27:09,220 --> 00:27:10,660
it's a kind of utility package.

420
00:27:10,660 --> 00:27:13,700
It will help you kind of shorthand a little bit

421
00:27:13,700 --> 00:27:15,740
of your color management code.

422
00:27:15,740 --> 00:27:18,620
And then probably one of the most useful things,

423
00:27:18,620 --> 00:27:22,820
which I am surprised that the standards,

424
00:27:22,820 --> 00:27:26,340
well, we talked about how complex color is last time,

425
00:27:26,340 --> 00:27:27,660
but also at the same time,

426
00:27:27,660 --> 00:27:30,420
it would be great to be able to bring in

427
00:27:30,420 --> 00:27:35,180
web hex colors into UI and NS colors and SwiftUI colors.

428
00:27:35,180 --> 00:27:37,120
And that's one of the things that this does.

429
00:27:37,120 --> 00:27:40,520
You can also take a color and get a hex value out of it.

430
00:27:40,520 --> 00:27:43,880
But then it's got a couple of also useful

431
00:27:43,880 --> 00:27:48,720
little features like you can detect the contrast ratio,

432
00:27:48,720 --> 00:27:51,780
which is really useful when you're checking your site

433
00:27:51,780 --> 00:27:53,400
for accessibility.

434
00:27:53,400 --> 00:27:58,400
So you can check the WCAG contrast ratio

435
00:27:58,400 --> 00:28:02,460
of any color to any other color.

436
00:28:02,460 --> 00:28:04,380
And you can also, and this is something

437
00:28:04,380 --> 00:28:06,200
I really find very useful.

438
00:28:06,200 --> 00:28:10,800
you can lighten or darken a color by a certain amount.

439
00:28:10,800 --> 00:28:13,740
So you can say, make this color 20% lighter

440
00:28:13,740 --> 00:28:14,900
than it was previously.

441
00:28:14,900 --> 00:28:17,640
And that's so useful for little things like,

442
00:28:17,640 --> 00:28:21,400
if you have like a header and you might want to have,

443
00:28:21,400 --> 00:28:23,680
to differentiate the background color of page

444
00:28:23,680 --> 00:28:27,300
or a view or something like that from the header,

445
00:28:27,300 --> 00:28:29,440
you can just lighten it or darken it a little bit.

446
00:28:29,440 --> 00:28:32,760
And that's a really nice way to get some subtlety in there.

447
00:28:32,760 --> 00:28:34,360
So it's a small package.

448
00:28:34,360 --> 00:28:38,960
It's the kind of thing that if you use it,

449
00:28:38,960 --> 00:28:42,060
it's only been developed for 22 days, so it's fairly new,

450
00:28:42,060 --> 00:28:43,080
but it might come in useful.

451
00:28:43,080 --> 00:28:45,320
And it's Color Toolbox by Ramon Torres.

452
00:28:45,320 --> 00:28:46,740
- Nice.

453
00:28:46,740 --> 00:28:51,740
Right, my first pick is called File Monitor by Kris Simon.

454
00:28:51,740 --> 00:28:54,460
That's a really nice package.

455
00:28:54,460 --> 00:28:57,580
And what it does is monitor file system changes.

456
00:28:57,580 --> 00:29:02,040
So imagine you want to monitor a directory

457
00:29:02,040 --> 00:29:07,360
for any changes within, you know, like creations, deletions, and modifications of files, you

458
00:29:07,360 --> 00:29:15,080
can spin this up and then have a sort of a subscription or a callback to notify you of

459
00:29:15,080 --> 00:29:16,200
stuff that's happening.

460
00:29:16,200 --> 00:29:17,860
And it's really nice.

461
00:29:17,860 --> 00:29:24,200
The thing that I noticed that I've found especially nice is that it supports Linux as well.

462
00:29:24,200 --> 00:29:30,400
And obviously you can imagine there might be some significant differences in doing this

463
00:29:30,400 --> 00:29:31,680
on Linux.

464
00:29:31,680 --> 00:29:39,200
believe there are. So this is a nice package if you have need for this both on macros and Linux.

465
00:29:39,200 --> 00:29:44,400
It's a very simple interface, you can try it out on a playground as well to get a feel for it.

466
00:29:44,400 --> 00:29:51,840
It works as advertised and it's a nice neat package giving you file system notifications

467
00:29:51,840 --> 00:29:59,200
for whenever you need that. You know, might be doing some... I remember seeing this being used

468
00:29:59,200 --> 00:30:05,280
for instance, in Publish the other day where it's monitoring the file system for changes and then

469
00:30:05,280 --> 00:30:12,480
retrigger a build of the package. Publish obviously being a package to create a

470
00:30:12,480 --> 00:30:19,760
website and then you could automatically trigger rebuilds and then you would have to reload your

471
00:30:19,760 --> 00:30:24,400
page and all that. So that's perhaps a nice application for that if you're looking for

472
00:30:24,400 --> 00:30:26,040
for that sort of thing.

473
00:30:26,040 --> 00:30:29,120
So that's File Monitor by Kris Simon.

474
00:30:29,120 --> 00:30:30,800
- Yeah, sounds useful.

475
00:30:30,800 --> 00:30:34,160
My next package continues a theme

476
00:30:34,160 --> 00:30:37,460
that I think I'm becoming,

477
00:30:37,460 --> 00:30:39,400
like I think it's becoming my thing on--

478
00:30:39,400 --> 00:30:41,080
- Is it about colors?

479
00:30:41,080 --> 00:30:42,200
- It's not about colors, no.

480
00:30:42,200 --> 00:30:45,680
It's about having an amazing name for a package.

481
00:30:45,680 --> 00:30:48,840
Actually, it goes on to our discussion

482
00:30:48,840 --> 00:30:52,140
around Swift-lovercase uppercase.

483
00:30:53,000 --> 00:30:55,800
This does not have the word Swift in the name.

484
00:30:55,800 --> 00:30:58,000
And it instantly stood out to me

485
00:30:58,000 --> 00:31:00,920
as I need to know what that package does.

486
00:31:00,920 --> 00:31:03,840
So the package is called Rearrange

487
00:31:03,840 --> 00:31:05,920
and it's by Matt Masigotti,

488
00:31:05,920 --> 00:31:09,200
who I think you mentioned earlier in the podcast actually.

489
00:31:09,200 --> 00:31:10,040
- I did, yeah.

490
00:31:10,040 --> 00:31:12,160
- So again, this is a small package

491
00:31:12,160 --> 00:31:17,640
that is dealing with extensions and utilities

492
00:31:17,640 --> 00:31:21,680
for making it easier to work with ranges.

493
00:31:21,680 --> 00:31:23,900
So NS range, NS text range.

494
00:31:23,900 --> 00:31:28,380
Matt says in the readme, it says it's particularly handy

495
00:31:28,380 --> 00:31:30,580
when used with the Cocoa text system.

496
00:31:30,580 --> 00:31:35,860
So the kind of thing you can do here with like an NS range,

497
00:31:35,860 --> 00:31:40,120
you can shift a range by a delta.

498
00:31:40,120 --> 00:31:43,100
You can shift the start of a range.

499
00:31:43,100 --> 00:31:45,340
You can shift the end of a range.

500
00:31:45,340 --> 00:31:48,860
So you can very quickly, if you're, for example,

501
00:31:48,860 --> 00:31:51,460
as Matt mentions that if you're working with text,

502
00:31:51,460 --> 00:31:55,660
you might want to change the range of a selection of text

503
00:31:55,660 --> 00:31:59,980
and you might want to shrink it or shift it left or right.

504
00:31:59,980 --> 00:32:01,580
And then there are various other things you can do

505
00:32:01,580 --> 00:32:05,420
with NSTextRange and UITextRange and IndexSet and String.

506
00:32:05,420 --> 00:32:08,640
And again, not a package that's going to be

507
00:32:08,640 --> 00:32:10,380
immediately useful to everybody,

508
00:32:10,380 --> 00:32:13,660
but I'm a sucker for a good name and this is a great name.

509
00:32:13,660 --> 00:32:14,940
- Nice.

510
00:32:14,940 --> 00:32:17,740
Yeah, Matt, he's here, he's there, he's everywhere.

511
00:32:17,740 --> 00:32:20,420
- He is, yes.

512
00:32:20,420 --> 00:32:22,700
He's actually a great supporter of the project as well.

513
00:32:22,700 --> 00:32:26,020
So it's nice to give him a shout out on the podcast.

514
00:32:26,020 --> 00:32:27,620
- Absolutely, yeah.

515
00:32:27,620 --> 00:32:31,460
Right, my second package is called

516
00:32:31,460 --> 00:32:33,760
Swift-Concurrency Extras.

517
00:32:33,760 --> 00:32:37,160
And it's a package by Point Free.

518
00:32:37,160 --> 00:32:40,180
And disclosure, which we've just given you,

519
00:32:40,180 --> 00:32:42,100
Point Free are a sponsor,

520
00:32:42,100 --> 00:32:44,420
but anyone who's been following me

521
00:32:44,420 --> 00:32:46,900
knows I'm a huge Point Free fan

522
00:32:46,900 --> 00:32:48,540
and can hardly be surprised that I'm again

523
00:32:48,540 --> 00:32:50,180
mentioning a package of theirs.

524
00:32:50,180 --> 00:32:53,340
So here you go, Swift concurrency extras.

525
00:32:53,340 --> 00:32:57,620
This is a package they released just last week, I believe.

526
00:32:57,620 --> 00:33:01,420
And it's about testing asynchronous code,

527
00:33:01,420 --> 00:33:02,980
which is notoriously difficult.

528
00:33:02,980 --> 00:33:06,220
There is sort of a motivational link

529
00:33:06,220 --> 00:33:07,680
that I'll add to the show notes

530
00:33:07,680 --> 00:33:11,540
where they've raised issues around testing,

531
00:33:11,540 --> 00:33:14,540
in particular, Swift concurrency code on the Swift forums

532
00:33:14,540 --> 00:33:18,580
that sort of spawned all their investigation into this.

533
00:33:18,580 --> 00:33:21,700
And they actually came up with a solution to deal with this.

534
00:33:21,700 --> 00:33:24,620
And the problem is that it's,

535
00:33:24,620 --> 00:33:26,300
in a heavily concurrent system,

536
00:33:26,300 --> 00:33:28,200
it's difficult to do testing

537
00:33:28,200 --> 00:33:33,200
because you sort of need to assert on an order of tasks

538
00:33:33,200 --> 00:33:37,000
or an order of execution, which you don't really have

539
00:33:37,000 --> 00:33:40,140
because if it's concurrent, stuff can happen out of order.

540
00:33:40,140 --> 00:33:43,380
But that's really hard to assert on then.

541
00:33:43,380 --> 00:33:46,880
And what they've done is they came up with something

542
00:33:46,880 --> 00:33:51,880
to actually use a serial executor in test context,

543
00:33:51,880 --> 00:33:58,520
so that everything really happens deterministically

544
00:33:58,520 --> 00:34:01,560
and you can actually rely on the order of the tests.

545
00:34:01,560 --> 00:34:03,760
So you're not actually changing your production code,

546
00:34:03,760 --> 00:34:05,000
that stays all the same,

547
00:34:05,000 --> 00:34:08,840
but you inject a serial executor that sort of then

548
00:34:08,840 --> 00:34:11,120
takes all the concurrency out of the equation

549
00:34:11,120 --> 00:34:13,680
and just execute stuff serially,

550
00:34:13,680 --> 00:34:19,160
as if you had only one single task and a single executor that's doing everything.

551
00:34:19,160 --> 00:34:24,600
And that then allows you to assert on all the steps and have reason about

552
00:34:24,600 --> 00:34:26,360
the order in which things are happening.

553
00:34:26,360 --> 00:34:29,680
And in case that wasn't clear, this is really for testing only.

554
00:34:29,680 --> 00:34:32,440
You shouldn't be messing with this in production, obviously, because, you know,

555
00:34:32,440 --> 00:34:36,600
you'd screw, you'd screw over your concurrency system with that.

556
00:34:36,600 --> 00:34:41,840
And the repository comes with a really good example to illustrate why that is

557
00:34:41,840 --> 00:34:45,160
necessary, why you might want that, why you would need that.

558
00:34:45,160 --> 00:34:48,720
Um, and it's not a convoluted example.

559
00:34:48,720 --> 00:34:53,520
You, you very easily end up in situations where it might appear to be working, but

560
00:34:53,520 --> 00:34:58,080
if you run a test often enough, it'll eventually fail and eventually isn't,

561
00:34:58,080 --> 00:35:02,720
isn't a large number, it can be tens or 20 or a hundred runs where it'll happen.

562
00:35:02,720 --> 00:35:05,600
And obviously that's, that's no good in CI.

563
00:35:05,600 --> 00:35:09,200
If every 10th run fails, that's, that's terrible because you'll

564
00:35:09,200 --> 00:35:11,400
always be chasing some odd failures.

565
00:35:11,400 --> 00:35:15,200
So this is a really great tool to be able to deal with that.

566
00:35:15,200 --> 00:35:20,080
The package comes with a couple of other nice things,

567
00:35:20,080 --> 00:35:21,660
things that we're actually already using

568
00:35:21,660 --> 00:35:23,340
in the Swift package index,

569
00:35:23,340 --> 00:35:28,340
because they are structures that have actually published

570
00:35:28,340 --> 00:35:30,000
individually earlier on,

571
00:35:30,000 --> 00:35:32,160
and they've now pushed this into this package,

572
00:35:32,160 --> 00:35:35,040
and they're called actor isolated and lock isolated.

573
00:35:35,040 --> 00:35:37,520
These are little wrappers around structs

574
00:35:37,520 --> 00:35:40,800
to make them safe for use in testing

575
00:35:40,800 --> 00:35:44,240
and to make them, to avoid race conditions in your testing

576
00:35:44,240 --> 00:35:46,800
when you're asserting on stuff that,

577
00:35:46,800 --> 00:35:49,720
you know, for instance, you have a variable

578
00:35:49,720 --> 00:35:51,720
that you want to save stuff into,

579
00:35:51,720 --> 00:35:56,720
and it's not living in a concurrency context.

580
00:35:56,720 --> 00:36:01,920
You could use lock_isolator to allow access to that struct

581
00:36:01,920 --> 00:36:05,440
without worrying about race conditions and stuff like that.

582
00:36:05,440 --> 00:36:08,680
So this is a really nice package if you're into testing

583
00:36:08,680 --> 00:36:13,280
And if you're having trouble with testing of things

584
00:36:13,280 --> 00:36:18,680
that are heavily concurrent or making use of async/await.

585
00:36:18,680 --> 00:36:22,000
And that's called Swift Concurrency Extras by Point Free.

586
00:36:22,000 --> 00:36:25,040
- I think if there was a feature in Swift Package Manager

587
00:36:25,040 --> 00:36:27,280
where you could subscribe to every package

588
00:36:27,280 --> 00:36:31,400
from an organization, then Point Free would be added

589
00:36:31,400 --> 00:36:35,240
to the Swift Package Index manifest in that way.

590
00:36:35,240 --> 00:36:37,080
- Well, you're trolling me right now, right?

591
00:36:37,080 --> 00:36:37,920
Because--

592
00:36:37,920 --> 00:36:38,760
(laughing)

593
00:36:38,760 --> 00:36:39,580
- A little bit.

594
00:36:39,580 --> 00:36:40,420
- All right.

595
00:36:40,420 --> 00:36:41,620
I'm not gonna bite then.

596
00:36:41,620 --> 00:36:44,920
(laughing)

597
00:36:44,920 --> 00:36:49,380
- Okay, my final package for today is a SwiftUI package.

598
00:36:49,380 --> 00:36:54,140
And it's from Vansun Leung,

599
00:36:54,140 --> 00:36:57,740
and it's called SwiftUI-VPSwitch.

600
00:36:57,740 --> 00:37:02,120
And it's basically a replacement

601
00:37:02,120 --> 00:37:05,060
for the iOS style toggle,

602
00:37:05,060 --> 00:37:09,660
where you have a rounded kind of lozenge shape

603
00:37:09,660 --> 00:37:12,960
with a circle at one end and in one position it's on,

604
00:37:12,960 --> 00:37:14,460
and when you slide that across it

605
00:37:14,460 --> 00:37:16,280
into the other position, it's off.

606
00:37:16,280 --> 00:37:20,460
And this is just a really nice implementation

607
00:37:20,460 --> 00:37:22,820
of a design style that I've seen

608
00:37:22,820 --> 00:37:24,260
all over the place actually.

609
00:37:24,260 --> 00:37:26,860
If you ever look through Dribbble

610
00:37:26,860 --> 00:37:29,380
or any of the design inspiration sites,

611
00:37:29,380 --> 00:37:32,060
you'll see this kind of effect quite often.

612
00:37:32,060 --> 00:37:34,420
And this is an implementation of it in SwiftUI.

613
00:37:34,420 --> 00:37:38,580
So imagine if you had, for example,

614
00:37:38,580 --> 00:37:43,500
a switch that was representing day mode and night mode.

615
00:37:43,500 --> 00:37:47,100
You might have an image that at the top of the image

616
00:37:47,100 --> 00:37:51,340
represented a starry night sky, something like that,

617
00:37:51,340 --> 00:37:54,060
with maybe the moon in it or something similar

618
00:37:54,060 --> 00:37:56,780
to represent the concept of night.

619
00:37:56,780 --> 00:37:58,500
And on the bottom of the image,

620
00:37:58,500 --> 00:38:02,640
you could have a set of clouds and bright blue sky

621
00:38:02,640 --> 00:38:08,320
something like that to represent a daytime toggle. And as you toggle the switch from

622
00:38:08,320 --> 00:38:14,680
on to off, what it does is it animates the background of the switch up and down to move

623
00:38:14,680 --> 00:38:21,040
between the day and the night states in the kind of viewport, the masking viewport of

624
00:38:21,040 --> 00:38:25,200
the switch itself. Hard to explain. Go and have a look at the readme. There's a beautiful

625
00:38:25,200 --> 00:38:26,200
animation there.

626
00:38:26,200 --> 00:38:32,200
I was just going to ask if it's in the readme because I had trouble following along.

627
00:38:32,200 --> 00:38:38,920
Yeah, I got halfway through, Anil, I had to continue because I couldn't just stop it halfway.

628
00:38:38,920 --> 00:38:43,440
But also the best thing to look at here is just go and have a look at the readme.

629
00:38:43,440 --> 00:38:48,920
And it's the kind of thing that I think is a lovely little...

630
00:38:48,920 --> 00:38:54,800
I wouldn't advocate putting this kind of effect on every switch in your application.

631
00:38:54,800 --> 00:38:57,920
But if you've got a really important switch,

632
00:38:57,920 --> 00:39:00,160
then this is the kind of thing that can highlight

633
00:39:00,160 --> 00:39:01,640
how important that switch is.

634
00:39:01,640 --> 00:39:02,860
- Yeah, nice.

635
00:39:02,860 --> 00:39:04,980
Definitely need to check that out.

636
00:39:04,980 --> 00:39:06,280
That sounded really interesting.

637
00:39:06,280 --> 00:39:07,940
- Yeah, go and have a look at the readme.

638
00:39:07,940 --> 00:39:12,440
So it's SwiftUI-VPSwitch by Vanson Leong.

639
00:39:12,440 --> 00:39:14,020
- Nice.

640
00:39:14,020 --> 00:39:18,840
Right, my third pick is called TLD Extract Swift

641
00:39:18,840 --> 00:39:20,880
by Marco Eidinger.

642
00:39:20,880 --> 00:39:23,640
Not sure why he put Swift in the name there,

643
00:39:23,640 --> 00:39:26,940
but otherwise the name gives away what it does.

644
00:39:26,940 --> 00:39:29,340
It's one of these packages.

645
00:39:29,340 --> 00:39:31,900
I picked it mainly to talk a bit about things

646
00:39:31,900 --> 00:39:35,600
that are deceptively simple.

647
00:39:35,600 --> 00:39:37,140
Not that it's overly complicated,

648
00:39:37,140 --> 00:39:39,960
but it's really easy to fall into this slight trap.

649
00:39:39,960 --> 00:39:44,580
And what it does is it extracts the TLD top-level domain

650
00:39:44,580 --> 00:39:47,200
and the root domain and subdomain from a host name.

651
00:39:47,200 --> 00:39:50,920
And this package is recommended to you

652
00:39:50,920 --> 00:39:53,200
by the Ministry of How Hard Can It Be, right?

653
00:39:53,200 --> 00:39:56,440
because you just split by the dots

654
00:39:56,440 --> 00:39:58,680
and then take the last two elements, right?

655
00:39:58,680 --> 00:40:01,180
That's your root domain.

656
00:40:01,180 --> 00:40:05,360
Except greetings for example, .co.uk, right?

657
00:40:05,360 --> 00:40:10,360
Because that isn't the root domain, the last two,

658
00:40:10,360 --> 00:40:14,760
because that co.uk are considered as the root domain.

659
00:40:14,760 --> 00:40:19,760
So that's not a domain you can register.

660
00:40:19,760 --> 00:40:22,940
And there's actually, I didn't know this,

661
00:40:22,940 --> 00:40:30,780
a public suffix list on the web that lists out and Japan has the same. There's .co.jp

662
00:40:30,780 --> 00:40:39,180
and Australia I think as well. Some countries have a second level of official domains under their

663
00:40:39,180 --> 00:40:47,100
national domain that they hand out. They're sort of, I don't know what you call them, like

664
00:40:47,100 --> 00:40:53,340
like Lamented, you know, you can't freely get those domains there. And it's one of these things,

665
00:40:53,340 --> 00:40:57,740
right, it's very easy to not consider that when you're doing that sort of thing and then suddenly

666
00:40:57,740 --> 00:41:07,500
Co is your subdomain or rather your top domain and when it actually isn't because you've had

667
00:41:07,500 --> 00:41:15,740
enough by one error. The other thing this package has, it has a CI setup to actually refresh from

668
00:41:15,740 --> 00:41:18,340
from this public suffix list automatically.

669
00:41:18,340 --> 00:41:21,780
So it does checks and I guess releases as well,

670
00:41:21,780 --> 00:41:24,080
if it changes and you can even run,

671
00:41:24,080 --> 00:41:26,120
if you use the package, you can run it yourself.

672
00:41:26,120 --> 00:41:29,660
So you can actually refresh this list on the fly.

673
00:41:29,660 --> 00:41:31,620
Not that I think it changes that often,

674
00:41:31,620 --> 00:41:34,380
but it's always nice to have this sort of thing considered

675
00:41:34,380 --> 00:41:37,580
because you can rely on this package to track

676
00:41:37,580 --> 00:41:39,660
any sort of changes there.

677
00:41:39,660 --> 00:41:44,580
So nice little package, TLD Extract Swift by Marco Eidinger.

678
00:41:44,580 --> 00:41:46,020
When you first said the name of that package,

679
00:41:46,020 --> 00:41:49,460
I thought you said TLDR, but no, it's TLD.

680
00:41:49,460 --> 00:41:55,500
And that brings another episode of the podcast to an end.

681
00:41:55,500 --> 00:41:59,380
So we will be back in a couple of weeks.

682
00:41:59,380 --> 00:42:04,380
Please do let us know if you have any packages

683
00:42:04,380 --> 00:42:09,820
or ideas for sources of community package recommendations

684
00:42:09,820 --> 00:42:13,660
for our Swift.org community showcase.

685
00:42:13,660 --> 00:42:17,460
And yeah, we will be back in a couple of weeks.

686
00:42:17,460 --> 00:42:19,180
- Yeah, see you in two weeks.

687
00:42:19,180 --> 00:42:20,020
Bye bye.

688
00:42:20,020 --> 00:42:21,220
- See you then, bye bye.