1 00:00:00,000 --> 00:00:06,000 that this might actually be, might actually be for the podcast. So I did run a test this time to make 2 00:00:06,000 --> 00:00:15,120 sure I don't mess up the recording again. And so I set myself a timer half an hour and recorded 3 00:00:15,120 --> 00:00:22,320 myself just, you know, as I was working. And of course I can set a timer and immediately forget 4 00:00:22,320 --> 00:00:28,960 about it. So every Monday I do system maintenance and stuff, and I set a three or five minute timer 5 00:00:28,960 --> 00:00:33,680 for each machine to check it after it's been rebooted. And you wouldn't believe how often 6 00:00:33,680 --> 00:00:38,800 that timer goes off and I think, what's that about? Yeah, what on earth do I need to do? 7 00:00:38,800 --> 00:00:44,720 Within three minutes, I forget what this timer was about. I'm not in the kitchen, 8 00:00:44,720 --> 00:00:51,200 so there's nothing obvious heating up or something that needs attention. And I just don't understand 9 00:00:51,200 --> 00:00:58,080 what's going on. Well, welcome everybody to the Over 50s podcast. Well, it started sooner than 10 00:00:58,080 --> 00:01:05,600 that but yes yeah I'm not I'm not I'm not actually quite 50 yet I'm 14 oh all right all right well 11 00:01:05,600 --> 00:01:12,240 you've you've segmented us nicely there um so anyway you can imagine how long it took for me 12 00:01:12,240 --> 00:01:16,800 to completely forget about this recording and then when the timer went off I stared at the 13 00:01:16,800 --> 00:01:22,240 at the watch and then but because it was 30 minutes that I made the connection 30 minutes 14 00:01:22,240 --> 00:01:27,840 was weirdly very unusual time for a timer then ah right yeah you had this recording running 15 00:01:27,840 --> 00:01:32,880 What you haven't mentioned is why you were doing this. Well, do we really need to 16 00:01:32,880 --> 00:01:39,000 go into this? So well let's let's talk about it. We had a bit of a week last 17 00:01:39,000 --> 00:01:49,260 week. We had a serious issue with the package index itself and we also had a 18 00:01:49,260 --> 00:01:55,560 podcast recording last week and when I received the Sven's audio file it was 19 00:01:55,560 --> 00:02:00,520 about three quarters missing with just complete silence and there must have been maybe a loose 20 00:02:00,520 --> 00:02:07,480 connection or something like that from Sone's microphone and so I asked him to do some testing 21 00:02:07,480 --> 00:02:11,000 and that was his half an hour microphone record that he was just referring to. 22 00:02:11,000 --> 00:02:16,360 Yeah exactly and this actually ties nicely back to the remainder of my story because when I was 23 00:02:16,360 --> 00:02:21,960 listening back to this I'm still working on this problem. I'm still picking up the pieces from what 24 00:02:21,960 --> 00:02:27,400 went wrong last week. I listened back and there are these sighs in the recording like, 25 00:02:27,400 --> 00:02:33,160 "Oh, why is this not working? I completely forgot the microphone. It is hilarious to listen back to 26 00:02:33,160 --> 00:02:41,560 this. Someone's suffering at their desk in agony over stuff. Oh God, I'm just glad this isn't 27 00:02:41,560 --> 00:02:47,960 running the whole time." Well, so that's the thing. We are actually surrounded in modern life by 28 00:02:48,920 --> 00:02:53,000 tens of microphones. I don't know how many microphones there are in my house, but there 29 00:02:53,000 --> 00:02:59,320 are a lot. Yeah, I wonder how many are live. Yeah, exactly. And I don't want to hear all 30 00:02:59,320 --> 00:03:02,040 the exasperation that I say throughout an average day. 31 00:03:02,040 --> 00:03:08,280 I'm actually becoming more conscious of this because I work here with the window wide open. 32 00:03:08,280 --> 00:03:15,160 I can often hear the neighbors talking two floors down on their balcony. I've started 33 00:03:15,160 --> 00:03:18,800 of reining myself in a bit because I do sometimes when stuff doesn't go right I 34 00:03:18,800 --> 00:03:25,080 do tend to curse a bit and I thought I need to dial it back. That's really 35 00:03:25,080 --> 00:03:31,360 interesting I can I hear my neighbor there through the wall. Sometimes it needs 36 00:03:31,360 --> 00:03:38,760 to be done it's like hitting return harder has an effect for sure. Yeah should 37 00:03:38,760 --> 00:03:42,240 we should we briefly talk about what actually happened? Yeah so let's talk 38 00:03:42,240 --> 00:03:42,880 about the problem. 39 00:03:42,880 --> 00:03:43,400 Yeah. 40 00:03:43,400 --> 00:03:47,500 So in broad strokes, we released an update last week, early last week. 41 00:03:47,500 --> 00:03:50,220 I think it was Monday afternoon. 42 00:03:50,220 --> 00:03:54,820 Um, and the repercussions only became obvious later that evening. 43 00:03:54,820 --> 00:03:57,120 And long story short, what happened? 44 00:03:57,120 --> 00:04:01,660 We lost about half of our versions and a version in our system is a. 45 00:04:01,660 --> 00:04:03,460 Get reference essentially. 46 00:04:03,460 --> 00:04:08,620 So we have one, uh, branch that we're tracking the main branch, default 47 00:04:08,620 --> 00:04:14,700 branch of a repository and then we're tracking a reference, a version for every release that package 48 00:04:14,700 --> 00:04:20,780 has. And you can imagine there's a number of them. We have a bit over 6,000 packages and we have 49 00:04:20,780 --> 00:04:28,620 100,000 versions that we're tracking in the index. And we lost, I think like 45,000 before we noticed 50 00:04:28,620 --> 00:04:33,180 what was happening and why it was happening and pulled the plug. And the problem was there was a 51 00:04:33,180 --> 00:04:39,260 delay for us to notice, a significant delay due to how the bug manifested itself between us 52 00:04:39,260 --> 00:04:42,460 actually having a chance to see that we lost the revisions? 53 00:04:42,460 --> 00:04:51,660 Yeah, without going into like real detail about it, it's kind of a complicated 54 00:04:51,660 --> 00:04:59,020 situation where it wasn't... we have these analysis cycles where we'll run past all the packages 55 00:04:59,020 --> 00:05:02,540 looking for changes and then back round again looking for changes and back round again, and 56 00:05:02,540 --> 00:05:04,420 And they take about, is it about three hours 57 00:05:04,420 --> 00:05:05,900 that it takes to run past that? 58 00:05:05,900 --> 00:05:07,340 Last time I checked, something like that. 59 00:05:07,340 --> 00:05:09,780 - One complete cycle takes around three hours 60 00:05:09,780 --> 00:05:11,540 and then it goes back to the start. 61 00:05:11,540 --> 00:05:15,140 - Right, and the bug only manifested 62 00:05:15,140 --> 00:05:18,540 in the second set of analysis 63 00:05:18,540 --> 00:05:21,780 after this bad release was deployed. 64 00:05:21,780 --> 00:05:23,820 And so you're in that worst of all situations 65 00:05:23,820 --> 00:05:27,820 where the release gets deployed, everything seems fine, 66 00:05:27,820 --> 00:05:32,420 and then at some point later, everything goes to, yeah. 67 00:05:32,420 --> 00:05:38,100 And the thing is, I stopped stuff when I initially saw the problem and then I rolled back and I 68 00:05:38,100 --> 00:05:43,540 didn't see a change. And I didn't see the change because the problem didn't manifest itself 69 00:05:43,540 --> 00:05:51,140 immediately. And then I rolled forward again. And that cost us revisions because had I stopped there 70 00:05:51,140 --> 00:05:56,500 and given that more time, that would have saved us. But long story short, we lost the revisions. 71 00:05:56,500 --> 00:06:02,420 that's actually not the end of the world. The revisions come back quickly within one analysis 72 00:06:02,420 --> 00:06:06,660 cycle. We're all back on the revisions. What we also lost, unfortunately, were all the builds that 73 00:06:06,660 --> 00:06:12,100 we have attached to a version. And those are the compatibility builds that we run, that we kick off 74 00:06:12,100 --> 00:06:17,700 for each package across all the platforms and all the Swift versions that we're tracking, which is, 75 00:06:17,700 --> 00:06:22,900 I think 30-ish per version. 76 00:06:22,900 --> 00:06:24,500 32 I think, yeah. 77 00:06:24,500 --> 00:06:28,260 Yeah, so you can imagine that's a lot of builds that we now have to catch up on. 78 00:06:28,260 --> 00:06:31,060 We're actually still in the process, tail end of the process. 79 00:06:31,060 --> 00:06:36,740 We decided last week not to replay a backup. 80 00:06:36,740 --> 00:06:43,460 We do run backups of the database, but that was also unfortunate because we were so deep 81 00:06:43,460 --> 00:06:45,140 in trying to figure out what was going wrong. 82 00:06:45,140 --> 00:06:52,020 we didn't actually, or I didn't actually think through how complex a database rollback is. 83 00:06:52,020 --> 00:06:56,100 And it's actually a lot easier than I thought at the time. I did not stop and think that's 84 00:06:56,100 --> 00:07:00,900 a bit unfortunate because we could have very easily played that database back 85 00:07:00,900 --> 00:07:08,500 and have avoided doing the builds. Yeah. And that's the thing, like in these situations where 86 00:07:08,500 --> 00:07:14,660 you have to make a decision and you make that decision under pressure and while the world is 87 00:07:14,660 --> 00:07:19,700 falling around you, it's sometimes difficult to make the best decision in those situations. 88 00:07:19,700 --> 00:07:22,660 I mean, the other thing that happened last week, 89 00:07:22,660 --> 00:07:27,620 completely outside of this tech stuff is I played a paddle game. Paddle is a kind of a tennis game. 90 00:07:27,620 --> 00:07:36,820 They play here in the South of France. And I hurt my back. I got, did you call it lumbago in English? 91 00:07:36,820 --> 00:07:37,460 Sure, yeah. 92 00:07:37,460 --> 00:07:42,420 Lumbago in French, yeah. And I was completely wrecked. I couldn't move, 93 00:07:42,420 --> 00:07:44,180 couldn't even sit the first couple of days. 94 00:07:44,180 --> 00:07:48,700 since Wednesday afternoon. That certainly didn't help. And it's really, really hard 95 00:07:48,700 --> 00:07:55,180 to think straight in these circumstances. So last week I deployed that release that 96 00:07:55,180 --> 00:08:04,100 nuked half of our versions. I ruined our podcast recording. I ruined my back. I hope this week's 97 00:08:04,100 --> 00:08:05,100 going to go better. 98 00:08:05,100 --> 00:08:08,020 But apart from that, how was the rest of the play? Yeah. 99 00:08:08,020 --> 00:08:12,900 Yeah, just going great. It's just going great. 100 00:08:12,900 --> 00:08:18,740 So in slightly more positive news, we have also been working on...so I think we mentioned 101 00:08:18,740 --> 00:08:27,540 this a few months ago actually, that we were putting in a pull request on the Swift.org 102 00:08:27,540 --> 00:08:35,740 website repository to add a packages page on that site to start to bring in some of 103 00:08:35,740 --> 00:08:39,400 the Swift package index data onto the Swift website 104 00:08:39,400 --> 00:08:44,400 to help kind of showcase and expand the package ecosystem 105 00:08:44,400 --> 00:08:48,520 and what people see on that site. 106 00:08:48,520 --> 00:08:53,520 So we're getting a little bit closer now to merging that. 107 00:08:53,520 --> 00:08:57,840 And I thought it might just be interesting to run through 108 00:08:57,840 --> 00:09:01,620 how we get the data into that page. 109 00:09:01,620 --> 00:09:05,540 And there's the technical side of it, 110 00:09:05,540 --> 00:09:08,220 which is physically, or not physically, 111 00:09:08,220 --> 00:09:13,220 but technically, how do we query the database, 112 00:09:13,220 --> 00:09:16,900 query the API, put together the right file, 113 00:09:16,900 --> 00:09:18,080 submit it as a pull request, 114 00:09:18,080 --> 00:09:20,260 and that will be the technical side of updating it, 115 00:09:20,260 --> 00:09:22,380 but actually that's not very interesting. 116 00:09:22,380 --> 00:09:24,920 The more interesting bit, I think, 117 00:09:24,920 --> 00:09:29,340 is how do we pick the packages that are on that page? 118 00:09:29,340 --> 00:09:33,600 So if you haven't seen the page demo yet, 119 00:09:33,600 --> 00:09:34,860 we did link to it last time, 120 00:09:34,860 --> 00:09:38,180 but we'll pop a link in the show notes again 121 00:09:38,180 --> 00:09:41,360 to the, we have a staging site for it set up. 122 00:09:41,360 --> 00:09:45,360 And that staging site has a little bit of a preamble 123 00:09:45,360 --> 00:09:48,240 about what packages are and what the Swift package index is 124 00:09:48,240 --> 00:09:49,320 and that kind of thing. 125 00:09:49,320 --> 00:09:52,680 But then it quite quickly goes into a set of lists 126 00:09:52,680 --> 00:09:54,320 of packages. 127 00:09:54,320 --> 00:09:56,920 And some of those lists come straight 128 00:09:56,920 --> 00:09:59,400 from the package index database. 129 00:09:59,400 --> 00:10:02,280 So for example, there are categories in there. 130 00:10:02,280 --> 00:10:04,920 So there's a list of six networking packages, 131 00:10:04,920 --> 00:10:07,200 six packages that might help with testing 132 00:10:07,200 --> 00:10:09,160 and that kind of thing. 133 00:10:09,160 --> 00:10:14,160 Those, the sources of that are fairly straightforward 134 00:10:14,160 --> 00:10:17,860 in terms of that's just the top six search results 135 00:10:17,860 --> 00:10:20,620 that come off the Swift Package Index site. 136 00:10:20,620 --> 00:10:23,800 So if you did that same search on the package index, 137 00:10:23,800 --> 00:10:25,900 you'd get the same six packages 138 00:10:25,900 --> 00:10:28,880 as we're currently gonna be showing on swift.org. 139 00:10:29,760 --> 00:10:32,840 Then we have a couple of lists that are things like, 140 00:10:32,840 --> 00:10:35,040 for example, I think one of them at the moment is 141 00:10:35,040 --> 00:10:38,160 packages that have macros in them. 142 00:10:38,160 --> 00:10:42,700 So kind of highlights macros are a new feature in Swift 5.9. 143 00:10:42,700 --> 00:10:45,640 And so let's highlight some packages that use that feature 144 00:10:45,640 --> 00:10:49,140 on Swift.org so that people can see them. 145 00:10:49,140 --> 00:10:52,600 But again, the results that come in are just, 146 00:10:52,600 --> 00:10:54,920 if you did that search on Swift package index, 147 00:10:54,920 --> 00:10:56,500 it would be in exactly that order. 148 00:10:56,500 --> 00:11:00,820 But actually the top category on the list is probably, 149 00:11:00,820 --> 00:11:02,380 I think, the most interesting one. 150 00:11:02,380 --> 00:11:05,480 And it's called, or we've called it the community showcase. 151 00:11:05,480 --> 00:11:11,340 And this is a manually curated set of packages. 152 00:11:11,340 --> 00:11:15,080 And I think it's interesting to talk about 153 00:11:15,080 --> 00:11:17,300 where that manual curation happens, 154 00:11:17,300 --> 00:11:18,820 how it will happen going forward, 155 00:11:18,820 --> 00:11:21,380 who's responsible for it, that kind of thing. 156 00:11:21,380 --> 00:11:24,500 We're about to make a post on the Swift forums about this. 157 00:11:24,500 --> 00:11:26,100 So this is slightly premature, 158 00:11:26,100 --> 00:11:28,860 but I think it's worth talking about here too. 159 00:11:28,860 --> 00:11:33,620 So the whole idea behind the Community Showcase 160 00:11:33,620 --> 00:11:36,540 is that it shouldn't try and be like a best of the best 161 00:11:36,540 --> 00:11:38,200 packages or something like that, 162 00:11:38,200 --> 00:11:42,940 but whatever packages are being discussed in the community. 163 00:11:42,940 --> 00:11:45,860 So whether that be on a podcast like this, for example, 164 00:11:45,860 --> 00:11:49,100 where we're gonna talk about some community packages later, 165 00:11:49,100 --> 00:11:52,260 or any other podcast from the community, 166 00:11:52,260 --> 00:11:55,900 or blogs or newsletters or something like that. 167 00:11:55,900 --> 00:11:59,380 So what packages are being highlighted? 168 00:11:59,380 --> 00:12:01,380 What packages are people talking about? 169 00:12:01,380 --> 00:12:04,940 And the only rule we've made actually 170 00:12:04,940 --> 00:12:09,340 is that nomination of a package to go in this showcase 171 00:12:09,340 --> 00:12:12,660 should be, you should nominate somebody else's package 172 00:12:12,660 --> 00:12:13,500 rather than your own. 173 00:12:13,500 --> 00:12:17,140 So for example, when we do the community packages 174 00:12:17,140 --> 00:12:18,180 at the end of this podcast, 175 00:12:18,180 --> 00:12:20,820 we don't link to our own packages. 176 00:12:20,820 --> 00:12:22,500 We talk about other people's packages 177 00:12:22,500 --> 00:12:25,220 and other podcasts and newsletters and things like that 178 00:12:25,220 --> 00:12:32,540 also doing that. So that's the rough criteria and we will collect nominations 179 00:12:32,540 --> 00:12:36,260 from people who run that kind of, you know, podcasts and blogs and things like 180 00:12:36,260 --> 00:12:41,840 that via the Swift forums. But then of course those nominations have to go 181 00:12:41,840 --> 00:12:46,200 through and six of those - let's say there are more than six nominations - we have 182 00:12:46,200 --> 00:12:50,660 somebody has to make a choice of, you know, which actual packages go onto that 183 00:12:50,660 --> 00:12:56,800 page. And this is where the Swift website workgroup initially comes in. So I'm a 184 00:12:56,800 --> 00:13:02,560 member of the Swift website workgroup and we do various bits of development 185 00:13:02,560 --> 00:13:08,160 and try to push the Swift website forward a little bit. And we do several 186 00:13:08,160 --> 00:13:13,040 bits of work towards kind of making the Swift website a little bit better and 187 00:13:13,040 --> 00:13:19,160 kind of pushing things forward in terms of the content on Swift.org. But also the 188 00:13:19,160 --> 00:13:22,740 Swift website workgroup is going to be the group which is responsible for 189 00:13:22,740 --> 00:13:27,860 initially curating which of these community packages make it onto this 190 00:13:27,860 --> 00:13:33,700 page. And this is going to happen on a fairly regular schedule. So we're 191 00:13:33,700 --> 00:13:36,800 thinking it'll either be every two weeks or maybe every month that these get 192 00:13:36,800 --> 00:13:42,260 updated, something like that. And so there'll be a series of kind of phases 193 00:13:42,260 --> 00:13:45,620 to it. We'll collect some nominations from people who run these community 194 00:13:45,620 --> 00:13:50,620 resources and then the work group will make a decision on which one goes in and 195 00:13:50,620 --> 00:13:56,020 then we'll finally update the Swift website via the pull request that we 196 00:13:56,020 --> 00:14:08,140 talked about earlier. And so we hope that that is a reasonable way to 197 00:14:08,140 --> 00:14:16,020 organize this. It's certainly... we don't want to make the decisions. The Swift 198 00:14:16,020 --> 00:14:19,860 website workgroup is you know managed by Apple and actually the Swift website 199 00:14:19,860 --> 00:14:24,220 workgroup is only temporarily going to be responsible for this. There was a 200 00:14:24,220 --> 00:14:31,500 blog post I think again like a couple of months ago where the Swift 201 00:14:31,500 --> 00:14:34,980 project announced that there would be some new workgroups coming and one of 202 00:14:34,980 --> 00:14:39,660 those work groups is the ecosystem work group. And one of the things that that 203 00:14:39,660 --> 00:14:43,100 work group is going to be responsible for is the package ecosystem. And so I 204 00:14:43,100 --> 00:14:47,060 think the plan eventually will be to have that work group make this decision 205 00:14:47,060 --> 00:14:51,720 rather than the website work group. But what we were very keen for it not to be 206 00:14:51,720 --> 00:14:55,800 was us. We don't want to make this decision, do we? Yeah, I really liked what 207 00:14:55,800 --> 00:15:00,860 you said at the start that this ecosystem category is not so much about 208 00:15:00,860 --> 00:15:07,980 the best package or quality as a metric, but what's interesting and what's being talked about. 209 00:15:07,980 --> 00:15:14,700 And I think this is sometimes reflected also in our choices where we pick stuff that's just 210 00:15:14,700 --> 00:15:21,740 interesting because I think there's more than one reason to look at packages. It can be inspirational, 211 00:15:21,740 --> 00:15:28,420 it can be educational, it can be fun. It can be something that someone who's learning the language 212 00:15:28,420 --> 00:15:31,020 or learning about packages is just trying. 213 00:15:31,020 --> 00:15:32,860 And I think all of these should get some space. 214 00:15:32,860 --> 00:15:35,620 It shouldn't just be about, you know, 215 00:15:35,620 --> 00:15:40,620 what absolutely bulletproof, perfectly maintained package 216 00:15:40,620 --> 00:15:42,540 do I need for my networking? 217 00:15:42,540 --> 00:15:43,900 Of course, that's one of the reasons 218 00:15:43,900 --> 00:15:46,420 why you need a package index or package recommendations, 219 00:15:46,420 --> 00:15:48,260 but it's about more than that. 220 00:15:48,260 --> 00:15:50,060 I mean, a lot of this is educational. 221 00:15:50,060 --> 00:15:54,500 I look at packages that I know I won't have any use for, 222 00:15:54,500 --> 00:15:55,940 but that I just find interesting, you know, 223 00:15:55,940 --> 00:16:03,220 you know, in the way they present themselves, how they do things, what their documentation looks 224 00:16:03,220 --> 00:16:08,100 like, the readme, that sort of stuff. It's often interesting aspects of the language that I don't 225 00:16:08,100 --> 00:16:15,140 know well that I want to learn about a bit. Or just to observe someone taking their first steps 226 00:16:15,140 --> 00:16:20,420 in publishing a package. That's also interesting and fun to see, and I know how that starts. 227 00:16:20,420 --> 00:16:26,420 because we've all started there, right? We've all had our first package, our first pull request 228 00:16:26,420 --> 00:16:33,940 something up and it can be really daunting and seeing that happen and maybe help it along a bit 229 00:16:33,940 --> 00:16:40,980 with a pull request yourself if you notice something can be really nice and welcoming. 230 00:16:40,980 --> 00:16:50,020 And that's part of why we called it the showcase. That word showcase is literally what this is. 231 00:16:50,020 --> 00:16:54,220 and we want to highlight brand new packages there 232 00:16:54,220 --> 00:16:56,680 that maybe haven't had that kind of battle testing, 233 00:16:56,680 --> 00:16:58,800 but they may be interesting. 234 00:16:58,800 --> 00:17:03,360 And I think it's a really positive thing 235 00:17:03,360 --> 00:17:06,020 that Apple wants to showcase that kind of package 236 00:17:06,020 --> 00:17:08,060 on the official website as well. 237 00:17:08,060 --> 00:17:10,960 And that shows that it's not just about, 238 00:17:10,960 --> 00:17:13,480 it's not all about, well, you can't get on this page 239 00:17:13,480 --> 00:17:16,000 unless you absolutely make the best package there is, 240 00:17:16,000 --> 00:17:19,040 because what does that even mean? (laughs) 241 00:17:19,040 --> 00:17:21,840 But this is a look at the ecosystem. 242 00:17:21,840 --> 00:17:25,340 This is, you know, the Swift 6,500 packages, 243 00:17:25,340 --> 00:17:26,980 something like that. 244 00:17:26,980 --> 00:17:28,680 But there's all sorts of interesting stuff 245 00:17:28,680 --> 00:17:31,000 going on inside that thousands of packages. 246 00:17:31,000 --> 00:17:32,680 - Yeah, definitely. 247 00:17:32,680 --> 00:17:35,280 - So the next thing that will happen with that 248 00:17:35,280 --> 00:17:40,280 is that we will make a post to the Swift forums 249 00:17:40,280 --> 00:17:45,200 and the purpose of that post is obviously 250 00:17:45,200 --> 00:17:46,960 to lay out our plans a little bit, 251 00:17:46,960 --> 00:17:49,760 but also to ask for the primary purpose 252 00:17:49,760 --> 00:17:51,320 is to ask for feedback. 253 00:17:51,320 --> 00:17:53,620 So if you have any feedback on this idea, 254 00:17:53,620 --> 00:17:55,560 nothing is too late. 255 00:17:55,560 --> 00:17:58,680 Yes, we have a prototype up and we have been through, 256 00:17:58,680 --> 00:18:00,280 like if you go to the pull request, 257 00:18:00,280 --> 00:18:03,000 you'll see lots of reviews there and tweaks 258 00:18:03,000 --> 00:18:05,600 and we have been moving it forward, 259 00:18:05,600 --> 00:18:06,800 but this is not, 260 00:18:06,800 --> 00:18:12,200 I think the stage that I would consider this at is, 261 00:18:13,100 --> 00:18:20,460 We'd be happy to merge this given no feedback comes from the community, but that feedback 262 00:18:20,460 --> 00:18:25,020 from the community is absolutely within scope to make changes to what we're proposing. 263 00:18:25,020 --> 00:18:29,060 Yeah. Right. We got any other news? 264 00:18:29,060 --> 00:18:35,180 I don't think I have any other news. So should we do some packages? 265 00:18:35,180 --> 00:18:42,380 Actually, one thing we could briefly talk about, which was in our messed up recording, 266 00:18:42,380 --> 00:18:49,120 but that's the first round of Dependabot updates that we saw against one of our projects in 267 00:18:49,120 --> 00:18:50,500 the Swift package index. 268 00:18:50,500 --> 00:18:55,820 So we mentioned this three weeks ago now that there's a new feature on GitHub. 269 00:18:55,820 --> 00:19:01,240 If you have a Swift project, they now run a dependency check against your repository. 270 00:19:01,240 --> 00:19:06,760 believe this is currently only happening if you have a package.resolved checked in, 271 00:19:06,760 --> 00:19:12,600 because that's the underlying information they use to discover whether any of your packages that 272 00:19:12,600 --> 00:19:20,120 you're using as a dependency have any issues. And if that is the case, and it's not even an opt-in 273 00:19:20,120 --> 00:19:27,400 that happens automatically, it will highlight this in a section on GitHub. I'm not sure what 274 00:19:27,400 --> 00:19:31,720 the panel actually is, we'll add a link to the show notes. This actually happened to us. So one 275 00:19:31,720 --> 00:19:39,800 of our packages that we don't update frequently was running an old version of Swift Neo, which had 276 00:19:39,800 --> 00:19:47,160 some updates that fix CVEs. And those were highlighted and alerted us to that fact. And then 277 00:19:47,160 --> 00:19:53,640 we ran a package update to update it to the latest version. So that's really nice. Again, we'll add a 278 00:19:53,640 --> 00:19:57,600 link to the show notes to show what that looks like. And I believe package 279 00:19:57,600 --> 00:20:01,440 resolved being checked in is a requirement, but that's probably the case 280 00:20:01,440 --> 00:20:08,000 for most packages. So yeah, there you go. Yeah, I think it's really nice 281 00:20:08,000 --> 00:20:13,220 that this is on by default for repositories that have that file. I 282 00:20:13,220 --> 00:20:18,000 think you can actually go a step further if you want to, and this is not on by 283 00:20:18,000 --> 00:20:23,200 default, but you can go in and say "also please raise a pull request" and the 284 00:20:23,200 --> 00:20:28,420 dependabot will, if it finds a vulnerability, it will then take your 285 00:20:28,420 --> 00:20:34,400 package.swift and package.result file and upgrade both of them if necessary to 286 00:20:34,400 --> 00:20:39,120 a version that no longer has that. So you can have it literally 287 00:20:39,120 --> 00:20:43,920 open that pull request and all you have to do is merge that to get the new 288 00:20:43,920 --> 00:20:47,520 dependency in there. We take a slightly different - I think we mentioned this 289 00:20:47,520 --> 00:20:51,060 again three weeks ago - we take a slightly different approach to that in that we 290 00:20:51,060 --> 00:20:54,900 have a script that runs every week that says here are you out all of your 291 00:20:54,900 --> 00:20:59,620 out-of-date dependencies so we're not gonna have that automated dependable one 292 00:20:59,620 --> 00:21:04,580 on but we we do love this this feature of the notifications yeah yeah that's 293 00:21:04,580 --> 00:21:09,500 really great okay should we should we do some packages join a kick us off fun I 294 00:21:09,500 --> 00:21:16,940 shall do so my first package my first pick is called xcbeautify by Tuist 295 00:21:16,940 --> 00:21:24,940 I absolutely love this. We've been using xcbeautify for quite a while in the Swift package index itself, not only in the project. 296 00:21:24,940 --> 00:21:39,940 So what I should explain what it does. xcbeautify is a executable, a command line executable that you can pipe your Xcode build and Swift build output and test runs through. 297 00:21:39,940 --> 00:21:41,740 And it beautifies the output. 298 00:21:41,740 --> 00:21:48,820 If you've seen what XCTest failures look like or build failures look like, it can get a 299 00:21:48,820 --> 00:21:51,060 bit messy, XED beautify. 300 00:21:51,060 --> 00:21:52,420 Makes that nice on the command line. 301 00:21:52,420 --> 00:21:57,660 It even adds ANSI colors, so you get nice colored output. 302 00:21:57,660 --> 00:22:01,060 Works also in CI as a nice output there. 303 00:22:01,060 --> 00:22:02,340 We've been using that for a while. 304 00:22:02,340 --> 00:22:11,000 Not only in our CI, we've also run the Xcode builds through Xe-Beautify of our build output 305 00:22:11,000 --> 00:22:12,900 that we generate. 306 00:22:12,900 --> 00:22:17,380 So if you go to a package page and click through to the builds and then click on any of the 307 00:22:17,380 --> 00:22:23,220 Xcode builds, you know, like the iOS watchOS to be OS builds, that output there is run 308 00:22:23,220 --> 00:22:27,920 through Xe-Beautify to make it look nicer, make it more digestible because it can get 309 00:22:27,920 --> 00:22:29,800 really noisy. 310 00:22:29,800 --> 00:22:37,880 Now a new feature they added in version 0.21 and I think now they're also there even on 311 00:22:37,880 --> 00:22:43,480 1.0.0 so if you go to the latest major version you'll effectively have this. 312 00:22:43,480 --> 00:22:50,000 They added a new GitHub actions renderer which doesn't give you quite that ANSI colored output 313 00:22:50,000 --> 00:22:56,200 it but it generates an output that is picked up by GitHub to surface test errors in the 314 00:22:56,200 --> 00:23:01,400 GitHub Action UI. And that is really, really nice because in the package index, we have 315 00:23:01,400 --> 00:23:06,760 hundreds of tests and if there's a failure, it's really hard to find them because we have 316 00:23:06,760 --> 00:23:09,280 our log output is thousands of lines. 317 00:23:09,280 --> 00:23:11,280 So you have to scroll a lot to find the error. 318 00:23:11,280 --> 00:23:19,000 What this does, it shows you the not only the error output, you know, what the failure 319 00:23:19,000 --> 00:23:21,760 was with the expected and actual values. 320 00:23:21,760 --> 00:23:25,600 It also gives you a click through to the source of the test so you can read all the 321 00:23:25,600 --> 00:23:31,680 context around it. And this is on the GitHub Action overview and it's really nice. I think 322 00:23:31,680 --> 00:23:38,760 it also inlines into pull requests alongside the code there. It's fantastic. I just absolutely 323 00:23:38,760 --> 00:23:42,960 love it because in the past I really dreaded when there was a CI failure. I often just 324 00:23:42,960 --> 00:23:47,840 ran rerun the tests locally because I couldn't be bothered scrolling through thousands of 325 00:23:47,840 --> 00:23:51,820 lines of tests. I thought I went, I'm just going to get a coffee, run the tests and see 326 00:23:51,820 --> 00:23:57,820 what's happening and now it's just all there. You can click through and see the results 327 00:23:57,820 --> 00:23:59,740 straight away. Absolutely brilliant. 328 00:23:59,740 --> 00:24:06,020 - I love this feature. I think it's such a time saver. I was in exactly the same boat 329 00:24:06,020 --> 00:24:12,780 as you if I got a CI test. My first port of call would be to run the tests locally again, 330 00:24:12,780 --> 00:24:17,600 and only if the test passed locally would I start to look through that log file. 331 00:24:17,600 --> 00:24:21,760 - First port of call was to shout profanities and run it locally. 332 00:24:21,760 --> 00:24:28,720 right yeah shout to my neighbor kid here that's right so yes it's a it's a great 333 00:24:28,720 --> 00:24:34,840 step forward for it and I think I'm just happy that we've we have this on our 334 00:24:34,840 --> 00:24:40,600 project now it's saving time already yeah absolutely okay my first package is 335 00:24:40,600 --> 00:24:49,200 by Vikram Kriplini and it's SwiftUI Shimmer so this is a bit of a package 336 00:24:49,200 --> 00:24:54,000 that a package that has a little bit of nostalgia to it but also is is still 337 00:24:54,000 --> 00:25:00,420 very much useful today. Do you remember when the original iPhone came out and it had no 338 00:25:00,420 --> 00:25:06,180 passcode on the original iPhone? Why would you possibly need to protect? Yeah, it's 339 00:25:06,180 --> 00:25:13,440 wild that they didn't have a passcode on it. Because there was nothing to protect, right? It had 340 00:25:13,440 --> 00:25:18,300 almost no information on it and we lived - it was a different time, Sven. It was a 341 00:25:18,300 --> 00:25:20,100 - I did lose it. 342 00:25:20,100 --> 00:25:23,540 I lost an original iPhone without any passcode and stuff. 343 00:25:23,540 --> 00:25:25,780 I changed some, I mean, obviously changed my, 344 00:25:25,780 --> 00:25:29,920 I'm not even sure, was it even iCloud at the time, 345 00:25:29,920 --> 00:25:31,080 my password, but-- 346 00:25:31,080 --> 00:25:32,920 - No, no iCloud. 347 00:25:32,920 --> 00:25:34,380 - Unimaginable these days. 348 00:25:34,380 --> 00:25:36,900 - Yeah. 349 00:25:36,900 --> 00:25:38,780 Anyway, so what it did have instead of a passcode 350 00:25:38,780 --> 00:25:42,680 was a beautiful bit of UI where it said slide to unlock 351 00:25:42,680 --> 00:25:46,020 and the text of the slide to unlock, 352 00:25:46,020 --> 00:25:47,400 there was a kind of shimmer effect 353 00:25:47,400 --> 00:25:49,760 that went from left to right across the text 354 00:25:49,760 --> 00:25:51,760 of a little at an angle, 355 00:25:51,760 --> 00:25:54,800 as if the light was catching it. 356 00:25:54,800 --> 00:25:57,400 And it was to indicate, 357 00:25:57,400 --> 00:26:00,880 because don't forget touch screens were fairly primitive 358 00:26:00,880 --> 00:26:04,320 at the time, this was to encourage you 359 00:26:04,320 --> 00:26:05,900 to interact with that element. 360 00:26:05,900 --> 00:26:07,360 And it was a lovely bit of UI, 361 00:26:07,360 --> 00:26:10,940 I think one of the most beautiful bits 362 00:26:10,940 --> 00:26:11,940 of the first iPhone. 363 00:26:11,940 --> 00:26:17,240 So SwiftUI Shimmer is a package that brings that 364 00:26:17,240 --> 00:26:18,980 to all of the modern platforms. 365 00:26:18,980 --> 00:26:22,580 It's actually been around for a couple of years now. 366 00:26:22,580 --> 00:26:25,100 But the reason it caught my eye this week 367 00:26:25,100 --> 00:26:30,100 was because you can add a shimmering slide to unlock screen 368 00:26:30,100 --> 00:26:32,840 on your Vision OS app with this, 369 00:26:32,840 --> 00:26:36,660 with this SwiftUI modifier in this package. 370 00:26:36,660 --> 00:26:39,500 And I think we should encourage everybody 371 00:26:39,500 --> 00:26:42,220 to add slide to unlock to their Vision OS app. 372 00:26:42,220 --> 00:26:44,380 - And then you slide across it with your eyes. 373 00:26:46,140 --> 00:26:47,940 - That's right, you just look from left to right 374 00:26:47,940 --> 00:26:50,440 and the application unlocks. 375 00:26:50,440 --> 00:26:52,260 Actually, I don't know, 376 00:26:52,260 --> 00:26:55,900 this is a little potential rabbit hole 377 00:26:55,900 --> 00:26:56,980 that we're going around here, 378 00:26:56,980 --> 00:26:58,140 but I don't know how, 379 00:26:58,140 --> 00:27:02,660 how does VisionOS do the authentication? 380 00:27:02,660 --> 00:27:05,740 How do you, it must have a class code or a lock or something. 381 00:27:05,740 --> 00:27:06,860 Is there a biometric? 382 00:27:06,860 --> 00:27:10,020 - No, it doesn't, it scans your iris, I think. 383 00:27:10,020 --> 00:27:12,340 - It scans your iris, okay. 384 00:27:12,340 --> 00:27:13,620 - I'm not sure what the name of it is. 385 00:27:13,620 --> 00:27:15,260 There's a marketing name for it. 386 00:27:15,260 --> 00:27:18,580 It's not eye lock or something, 387 00:27:18,580 --> 00:27:22,220 but it is something related to the eye. 388 00:27:22,220 --> 00:27:24,800 But I'm pretty sure it does an eye-risk scan. 389 00:27:24,800 --> 00:27:27,540 Unless I'm fantasizing now, 390 00:27:27,540 --> 00:27:29,520 I'm pretty sure that's what's happening. 391 00:27:29,520 --> 00:27:30,740 - I'm sure I knew at one point, 392 00:27:30,740 --> 00:27:31,700 but I've already forgotten. 393 00:27:31,700 --> 00:27:34,180 So we'll have to see when the device gets here. 394 00:27:34,180 --> 00:27:39,180 Anyway, that's SwiftUI Shimmer by Vikram Kripalini. 395 00:27:39,180 --> 00:27:40,580 - Nice, really nice. 396 00:27:40,580 --> 00:27:41,700 I love that. 397 00:27:41,700 --> 00:27:45,660 It was so, so powerful in what it communicated 398 00:27:45,660 --> 00:27:47,020 and how well it did that. 399 00:27:47,020 --> 00:27:48,140 It's just amazing, yeah. 400 00:27:48,140 --> 00:27:49,980 Definitely lost something there. 401 00:27:49,980 --> 00:27:54,740 - There were several bits of breakthrough UI 402 00:27:54,740 --> 00:27:58,020 with that first iPhone drop. 403 00:27:58,020 --> 00:28:02,540 It's a very rare event that you can have something 404 00:28:02,540 --> 00:28:07,540 that pushes UI forward so far in one moment. 405 00:28:07,540 --> 00:28:09,660 There was a time before the iPhone 406 00:28:09,660 --> 00:28:11,420 and there was a time after the iPhone. 407 00:28:11,420 --> 00:28:12,900 - Yeah, scrolling definitely is. 408 00:28:12,900 --> 00:28:15,500 You know how it continues when you flick it 409 00:28:15,500 --> 00:28:17,100 and the rubber banding at the edges 410 00:28:17,100 --> 00:28:20,100 and I think those are the key things, 411 00:28:20,100 --> 00:28:25,100 the key inventions around these touch screens 412 00:28:25,100 --> 00:28:26,800 that were transformative. 413 00:28:26,800 --> 00:28:29,260 - Well, and the other thing was multi-touch. 414 00:28:29,260 --> 00:28:30,700 - That really was so powerful. 415 00:28:30,700 --> 00:28:34,080 I watched a kid, like in the early days of the iPhone, 416 00:28:34,080 --> 00:28:38,940 toddler pick up an iPhone looking at pictures 417 00:28:38,940 --> 00:28:41,980 and pinching and zooming naturally. 418 00:28:41,980 --> 00:28:43,780 That tells you everything you need to know 419 00:28:43,780 --> 00:28:45,960 about that interaction, that it works. 420 00:28:45,960 --> 00:28:49,860 If a child can pick it up and just naturally do it. 421 00:28:49,860 --> 00:28:52,700 It was so, that was astounding to watch that happen, 422 00:28:52,700 --> 00:28:55,300 watch that, observe that interaction. 423 00:28:55,300 --> 00:28:57,460 - Back to the Over 50s podcast. 424 00:28:57,460 --> 00:28:59,020 I'm actually quite disappointed 425 00:28:59,020 --> 00:29:00,620 when I pick up a physical piece of paper 426 00:29:00,620 --> 00:29:03,660 and I can't do it on that because I need it. 427 00:29:03,660 --> 00:29:04,500 - All right. 428 00:29:04,500 --> 00:29:07,900 This does not zoom, yeah. 429 00:29:07,900 --> 00:29:10,740 - Okay, exactly, nothing's in it. 430 00:29:10,740 --> 00:29:14,540 - My next package is called Swift Prompt 431 00:29:14,540 --> 00:29:17,620 by Michael O'Brien and Michael O'Brien. 432 00:29:17,620 --> 00:29:20,420 I'm actually going to make that same joke as last week 433 00:29:20,420 --> 00:29:22,540 because it's new to all the others, but not today. 434 00:29:22,540 --> 00:29:24,780 We have this nice little bug in our website 435 00:29:24,780 --> 00:29:27,380 where we spell out the author name twice 436 00:29:27,380 --> 00:29:31,020 and that's because I presume that author has commits 437 00:29:31,020 --> 00:29:33,660 with different email addresses and we don't, 438 00:29:33,660 --> 00:29:35,260 at the moment, de-duplicate them. 439 00:29:35,260 --> 00:29:37,060 So-- 440 00:29:37,060 --> 00:29:40,060 we figured out what it was, isn't it? 441 00:29:40,060 --> 00:29:42,260 - Oh, right, right. 442 00:29:42,260 --> 00:29:43,100 - The two different apostrophes. 443 00:29:43,100 --> 00:29:44,900 - Oh yes, I figured it out on the podcast. 444 00:29:44,900 --> 00:29:46,900 So there's the apostrophe exactly one is the- 445 00:29:46,900 --> 00:29:50,220 - We did, we figured it out live on our failed recording. 446 00:29:50,220 --> 00:29:51,460 - Well, we had some successes, 447 00:29:51,460 --> 00:29:54,300 but they just never see the light of day. 448 00:29:54,300 --> 00:29:56,840 (laughs) 449 00:29:56,840 --> 00:30:00,500 Right, so the package is a command line interface package 450 00:30:00,500 --> 00:30:02,900 for text input and option picker prompts. 451 00:30:02,900 --> 00:30:04,420 And it's absolutely beautiful. 452 00:30:04,420 --> 00:30:07,180 You need to look at the readme of the package. 453 00:30:07,180 --> 00:30:08,860 Um, what that looks like. 454 00:30:08,860 --> 00:30:13,860 I, I just want to run off and write a command line tool that, that uses it. 455 00:30:13,860 --> 00:30:21,140 It looks really nice is using these, um, Unicode, um, what you call them glyphs. 456 00:30:21,140 --> 00:30:27,740 There's a little screencast on the, um, on the readme to create menus that you can 457 00:30:27,740 --> 00:30:31,980 arrow through and has a password prompt as well, where it hides your inputs. 458 00:30:31,980 --> 00:30:34,180 Uh, absolutely beautiful. 459 00:30:34,260 --> 00:30:37,180 it's if you have any sort of input that you're capturing 460 00:30:37,180 --> 00:30:40,520 for a script, use this, it looks really fantastic. 461 00:30:40,520 --> 00:30:43,480 Yeah, it's a small little package. 462 00:30:43,480 --> 00:30:44,480 That's what it does. 463 00:30:44,480 --> 00:30:46,260 It apparently does it really well. 464 00:30:46,260 --> 00:30:50,780 It's called SwiftPrompt and is by Michael O'Brien. 465 00:30:50,780 --> 00:30:55,740 - So there's always a decision to make 466 00:30:55,740 --> 00:30:57,820 with this kind of situation 467 00:30:57,820 --> 00:30:59,500 where you're writing a command line tool, 468 00:30:59,500 --> 00:31:01,000 you need some input. 469 00:31:01,000 --> 00:31:04,420 And one way is to go down the pass everything in 470 00:31:04,420 --> 00:31:09,420 as an argument, which is the Swift argument parser 471 00:31:09,420 --> 00:31:11,680 way to do it. 472 00:31:11,680 --> 00:31:14,100 And this is a nice alternative to that, 473 00:31:14,100 --> 00:31:17,000 where you might pass some things in as arguments, 474 00:31:17,000 --> 00:31:19,420 but then you want to have some interactivity. 475 00:31:19,420 --> 00:31:21,280 So maybe you want the user to make a choice 476 00:31:21,280 --> 00:31:23,720 between a few known options, 477 00:31:23,720 --> 00:31:27,840 or maybe that one choice depends on another choice, 478 00:31:27,840 --> 00:31:30,300 and that's hard to get right 479 00:31:30,300 --> 00:31:32,100 with just purely arguments. 480 00:31:32,100 --> 00:31:33,980 And so I can see good uses for this, 481 00:31:33,980 --> 00:31:37,340 where for slightly more complex command line tools. 482 00:31:37,340 --> 00:31:38,160 - Yeah, absolutely. 483 00:31:38,160 --> 00:31:41,680 Or because if you pass stuff in through the command line, 484 00:31:41,680 --> 00:31:42,580 it is visible. 485 00:31:42,580 --> 00:31:46,860 There's ways that can be seen 486 00:31:46,860 --> 00:31:48,500 if you're on a multi-user system, for instance. 487 00:31:48,500 --> 00:31:50,660 So that might be a reason to use it. 488 00:31:50,660 --> 00:31:52,680 That's direct input into the process 489 00:31:52,680 --> 00:31:57,640 that isn't telegraphed on as a command line input 490 00:31:57,640 --> 00:31:59,780 or an environment variable. 491 00:31:59,780 --> 00:32:00,620 - Exactly. 492 00:32:00,620 --> 00:32:07,020 My second package is called sf2lib by Brad House. 493 00:32:07,020 --> 00:32:11,540 And this is not only a new package to me, 494 00:32:11,540 --> 00:32:16,400 but the content or the purpose of the package 495 00:32:16,400 --> 00:32:18,040 was also new to me. 496 00:32:18,040 --> 00:32:22,420 So this is a package that passes and renders sound fonts. 497 00:32:22,420 --> 00:32:24,260 Have you ever heard of sound fonts before? 498 00:32:24,260 --> 00:32:25,340 - Sound fonts. 499 00:32:25,340 --> 00:32:27,580 Oh, is that like an accessibility feature 500 00:32:27,580 --> 00:32:31,580 where it has little, oh no, I was thinking of sparklines. 501 00:32:31,580 --> 00:32:34,220 - That would be a great idea, but it's not that, no. 502 00:32:34,220 --> 00:32:36,100 (laughs) 503 00:32:36,100 --> 00:32:40,820 A sound font is a, well, it's pretty much exactly 504 00:32:40,820 --> 00:32:42,700 what you think it is. 505 00:32:42,700 --> 00:32:44,260 It is the equivalent of a font, 506 00:32:44,260 --> 00:32:47,420 but with musical or sound samples, 507 00:32:47,420 --> 00:32:48,920 any kind of sound samples. 508 00:32:48,920 --> 00:32:53,920 So it is a file format that holds both MIDI map information, 509 00:32:54,980 --> 00:32:58,300 so the MIDI notes mapping to certain sample files, 510 00:32:58,300 --> 00:33:01,060 but also it contains the sample files as well. 511 00:33:01,060 --> 00:33:06,060 So for example, you could create a sound font of a piano 512 00:33:06,060 --> 00:33:09,400 and have all the different recordings of all the keys 513 00:33:09,400 --> 00:33:12,200 at various different velocities and things like that, 514 00:33:12,200 --> 00:33:14,380 and then distribute it as one file, 515 00:33:14,380 --> 00:33:17,220 which is here is the piano sound font, 516 00:33:17,220 --> 00:33:20,820 and people could render that and play back 517 00:33:20,820 --> 00:33:24,300 the right samples at the right time based on MIDI input. 518 00:33:24,300 --> 00:33:29,820 So I love the package index because not only does it teach me about new packages, but it 519 00:33:29,820 --> 00:33:34,060 teaches me about whole new things like this because I haven't come across sound fonts 520 00:33:34,060 --> 00:33:43,940 at all. And it's based on a C++ library behind the scenes and the SF2lib I believe is a wrapper 521 00:33:43,940 --> 00:33:51,960 that supports iOS, macOS, TBS. And yeah, it's not something I'm going to use in the next 522 00:33:51,960 --> 00:33:55,880 few weeks or potentially ever but I found it really interesting to learn 523 00:33:55,880 --> 00:34:00,160 about this. Nice, interesting. So how would you actually use it? What's the... is 524 00:34:00,160 --> 00:34:05,220 that to create those sound files or what's the... what does the package... No, it's 525 00:34:05,220 --> 00:34:11,080 not to create them, it is to parsing and rendering of them. So by rendering I 526 00:34:11,080 --> 00:34:17,200 presume it means playback. Yeah, alright, interesting. It does mention that it 527 00:34:17,200 --> 00:34:23,440 depends on DSP and audio classes from an AUV3 support package. So I think 528 00:34:23,440 --> 00:34:28,120 there's almost certainly playback functionality in there. 529 00:34:28,120 --> 00:34:37,400 All right, my third pick is called Swift Async Assert by Angoo Software. And this 530 00:34:37,400 --> 00:34:43,200 is a really nice convenience package when you're dealing with tests of async 531 00:34:43,200 --> 00:34:49,200 functions, because when you do that, you may have noticed that you, for instance, if you try and 532 00:34:49,200 --> 00:34:56,480 write a test XCT_ASSERT= what you put in there can't be async because it doesn't have an async 533 00:34:56,480 --> 00:35:04,800 context. So you'd need to either grab the value first by, you know, running a let temp variable 534 00:35:04,800 --> 00:35:12,960 equals a weight on your thing and then stick it in there. That's obviously a workaround or you 535 00:35:12,960 --> 00:35:18,480 have to write your own wrapper function that does that for you, which isn't hard, obviously. 536 00:35:18,480 --> 00:35:23,360 I mean, that's an easy thing to add. We've actually done that in a couple of cases in 537 00:35:23,360 --> 00:35:29,360 the package index in our tests. This nice little library does that for you. It packages all those 538 00:35:29,360 --> 00:35:37,040 up, does that for all the XCT assert variants out there, so you don't need to cover them all 539 00:35:37,040 --> 00:35:42,800 yourself or start with a few and then always be annoyed when a new one pops up that you haven't 540 00:35:42,800 --> 00:35:48,960 covered yet because that's the situation we are in. We got a fair few, but as soon as we need 541 00:35:48,960 --> 00:35:55,840 exit assert equals with accuracy, we'll have to go back and add that one. So it's really nice to 542 00:35:55,840 --> 00:36:01,120 have this all packaged up. And it's one of those packages that you can, that's easy to adopt, 543 00:36:01,120 --> 00:36:07,680 right? Because this you can do yourself easily or add it if upstream it's missing, you can open a 544 00:36:07,680 --> 00:36:09,200 and a pull request and added. 545 00:36:09,200 --> 00:36:10,720 I love these kinds of packages. 546 00:36:10,720 --> 00:36:13,400 They're easy to depend on because it's something 547 00:36:13,400 --> 00:36:16,160 you can absolutely do yourself, 548 00:36:16,160 --> 00:36:18,360 but it's a time saver that you don't have to. 549 00:36:18,360 --> 00:36:22,960 So yeah, Swift Async Assert by Angoo Software. 550 00:36:22,960 --> 00:36:25,620 - That's great. 551 00:36:25,620 --> 00:36:29,620 My final package this week is a package called Bezel Kit 552 00:36:29,620 --> 00:36:32,480 by Mark Battistella. 553 00:36:32,480 --> 00:36:37,480 And I love how minimal this package is. 554 00:36:37,480 --> 00:36:40,760 It probably has more than this, 555 00:36:40,760 --> 00:36:44,560 but the main functionality of this package is one method. 556 00:36:44,560 --> 00:36:45,960 (laughs) 557 00:36:45,960 --> 00:36:50,100 And it's not even an instance method, it's a static method. 558 00:36:50,100 --> 00:36:52,300 So how good is that, right? 559 00:36:52,300 --> 00:36:54,280 So what does it do? 560 00:36:54,280 --> 00:36:59,280 It tells you how big and what shape the corners are 561 00:36:59,280 --> 00:37:05,400 on whatever device it is running on. 562 00:37:05,400 --> 00:37:07,920 So for example, on an iPhone, 563 00:37:07,920 --> 00:37:12,920 you have the rounded corners at the screen edge 564 00:37:12,920 --> 00:37:14,960 because none of the corners are square 565 00:37:14,960 --> 00:37:16,660 on the iPhone screen. 566 00:37:16,660 --> 00:37:19,900 And they're not even standard corners, 567 00:37:19,900 --> 00:37:22,020 they're squircle corners. 568 00:37:22,020 --> 00:37:24,960 So I forget the mathematical name, 569 00:37:24,960 --> 00:37:26,800 but it's a slightly-- 570 00:37:26,800 --> 00:37:27,640 - Squircle. 571 00:37:27,640 --> 00:37:29,520 - It's not a perfect, it's a squircle, 572 00:37:29,520 --> 00:37:31,120 yeah, exactly, it's a squircle. 573 00:37:32,600 --> 00:37:37,600 And the purpose of this package is that if you have some UI 574 00:37:37,600 --> 00:37:42,320 in your application that wants to inset 575 00:37:42,320 --> 00:37:45,120 from the edge of the screen by a certain amount, 576 00:37:45,120 --> 00:37:49,120 it's quite difficult to get the radius of your squirkels 577 00:37:49,120 --> 00:37:51,760 to match the radius of the device squirkels 578 00:37:51,760 --> 00:37:54,840 because not only do you need to make it a squircle, 579 00:37:54,840 --> 00:37:57,340 which of course there are APIs to do that, 580 00:37:57,340 --> 00:37:59,480 but as you inset from the edge, 581 00:37:59,480 --> 00:38:03,720 the size of your corner radius is going to be different 582 00:38:03,720 --> 00:38:06,120 than the size of the corner radius on the device 583 00:38:06,120 --> 00:38:10,320 because your inset, like it's not the same size. 584 00:38:10,320 --> 00:38:13,500 And so what this will do is it will tell you, 585 00:38:13,500 --> 00:38:17,680 it will basically give you the device bezel size 586 00:38:17,680 --> 00:38:22,680 and make it really easy for you to draw perfect squirkels 587 00:38:22,680 --> 00:38:26,800 inside the inset of whatever device it is you're on. 588 00:38:26,800 --> 00:38:31,440 nice. Yeah, the readme, I'm just looking at it, lays that out nicely and gives the examples what 589 00:38:31,440 --> 00:38:34,000 that looks like as a nice... Better than I did. 590 00:38:34,000 --> 00:38:37,920 Yeah. Well, I mean, it has the advantage of being able to show a picture, which you 591 00:38:37,920 --> 00:38:43,360 kind of have to try and paint with your words. But yeah, it looks really nice. I'm wondering, 592 00:38:43,360 --> 00:38:51,600 you probably don't know if, does it have to sort of hard code and figure this out? So if something 593 00:38:51,600 --> 00:39:00,800 new came out this September with a new geometry. Does it actually use the, you know, the insets 594 00:39:00,800 --> 00:39:05,760 that it knows about to do that automatically or would it need to? It's a really great question. 595 00:39:05,760 --> 00:39:14,160 Ah well, maybe we'll know by next time. So that's Bezel Kit by Mark Battistella. There we go, so 596 00:39:14,160 --> 00:39:19,840 we will be back in two weeks or potentially next week if the recording has failed again. 597 00:39:19,840 --> 00:39:26,920 We will find out in about five minutes whether we'll be back next week or the week after. 598 00:39:26,920 --> 00:39:31,940 But hopefully with a perfect recording we'll be back in two weeks 599 00:39:31,940 --> 00:39:36,580 time to talk more packages and we will see you there. I hope so much that we'll 600 00:39:36,580 --> 00:39:42,840 see you in two weeks. Bye bye. Me too. Bye bye.