Glad it was helpful!

Will do!

Thank you! Yep, the refreshed Air came out back in March: www.theverge.com/2024/3/4/24089999/apple-macbook-air-m3-announced-13-15-inch

Wow, seems like you’ve got a lot of experience to compare Swift to! Good luck with your console project!

Thank you! Perhaps my main advice is to try different formats (textbooks, KZfaq videos, etc.) before committing to a 500-page book or an expensive online course. For instance, I choose hands-on projects because I can take different routes and experiment beyond the given task, keeping myself focused and entertained. On the other hand, practical projects don’t always go smoothly (you have to investigate and solve unforeseen problems by yourself), which can demotivate those who prefer comprehensive guidance. So try a few things first and then see what works best for you. I don’t believe you need a “special talent” to learn programming-but wrong tools can make this experience miserable.

Sure, I’ll clarify. The purpose of this video is to highlight the updates you might’ve missed after the consumer stuff had stolen all the spotlight at the keynote. A new programming language and UI framework serve only as an illustration: Had Apple introduced something like that, it would’ve been _all_ people talk about (I witnessed the lines for SwiftUI sessions at WWDC19). The point I’m making in the video is, you shouldn’t overlook the other (exciting) updates simply because they’re not as groundbreaking as a new UI framework.

I wouldn’t say we’re _proxying_ the production code in tests; more like defining the constraints it has to fit into, without recreating (or even knowing about) the implementation. In Swift Testing, it’s no different from the usual way we write tests. Typically, the body of a single test consists of four parts: 1. Define an input (which we control); 2. Define the expected result (which we know is correct); 3. Call the production code (which we’re not sure works correctly) on our input and get the actual result; 4. Make sure the actual result matches our expectations. We often need to check the same production code on different inputs, for which there’s a number of techniques: duplicating test methods (which is error-prone and tedious to update but gives you good visibility of which scenarios fail), using a for-in loop to iterate over different inputs within a single test (which requires less duplication but makes finding errors more difficult), etc. Parameterized testing solves this specific problem, without reinventing the fundamental approach to testing. It’s basically syntactic sugar to duplicate tests without you copying and pasting them manually. Test arguments move the inputs and expectations out of the test body, but you _still_ have two more tasks to do: call the production code and compare the results. That’s what the test body is for. In the demo, I don’t multiply anything _in the test code:_ The test knows _what_ the production code has to return, but doesn’t care _how_ it does it, so the production implementation doesn’t leak into tests. Not sure I 100% understood what you meant, so please correct me if I didn’t.

Я также проверил эту связку и не могу не подтвердить её эффективность.

Отлично, спасибо!