MandarisI’m up past midnight and thought that programming is probably the best thing to do.
So tonight/today, I’m learning about Protocols and extensions.
When it came to extensions, I think I learned just as much about the once that I got wrong as the ones that I got correct.
Today is really cool because not only am I celebrating the inauguration of Joe Biden, but I’m on day 10 of Hacking with Swift!
Pretty proud of myself for the most part because most of my errors where me not reading the question correctly.
We continue with structs today and I think I’m getting it for the most part. The issues that I run into are ones where I don’t pay attention to property names.
This session wasn’t as long as others, but I feel that I needed that after going through closures.
Today, is an exploration of structs. A lot of Swift seems to be built using structs. I wasn’t 100% awake when I was doing the computed properties section.
I tried mixing property observers and computed properties, and that does not seem to work.
I understand it as the value cannot be both observed and computed at the same time.
I still enjoy the fact that the questions keep us on our toes. This means that basic things can still trip you up if you attempt to rush through them.
I do wish that I had 100 out of a 100, but I want to be honest with myself.
Update: I used the wrong screenshot and had to remove the second image.
Closures part 2!
Paul Hudson says that this is where closures start to look a little bit like line noise and it can be hard to follow functions that use closures as parameters. Needless to say, I’m happy that I started this section early in the day.
Closures!!!
It took me a while to understand1 but this run through has really cemented how I look at them and just working with them in different tutorials.
For example, I had no idea what the section on “Closures as parameters” actually was saying. Now I can read the code and understand it.
I’m really excited and proud of myself! I did get a little too excited when I start the trailing closure syntax, but I can see where I went wrong versus just scratching my head about it.
I’m still working towards understanding. ↩︎
Today, I decided that I’d use CodeRunner to look at the examples found in the tutorials. It’s part of SetApp.
It’s simple and I can just run the code that I want without the overhead. Plus it catches errors that are in code, which helps when I’m going through tests and logic.
At this point, you can really, really tell that the lessons are building on top of each other and you can’t rush through them.
I don’t like making mistakes. When I do, it drives the lesson home and keeps me awake and cautious of what I’m doing.
As an added bonus, I’m learning that mistakes shouldn’t effect my ego so much.
Also, I can definitely get along with someone who writes this kind of code.
enum PizzaErrors: Error {
case hasPineapple
}
Today is all about loops.
I learned that you can’t loop over a tuple. I think this is because you can’t guarantee that every item will be the same thing.
I got to spend some time look up how to get a real going because it feels like forever to check my answers in a playground sometimes.
I want to point out that I really enjoy the brief discussions on why things are the way they are in Swift.
I got into a grove with the operator overloading and made the assumption that ** was an exponent operator.
I found myself talking through the training and that really helped me with understanding.
I think I’m in the same boat as Paul when it comes to the ternary operators.
I’m very much in the “avoid where possible” camp because even though this code is longer I do find it easier to follow:
I didn’t know that switch statements read the value they were reading once as compared to the if statement which would read it every time that it does a comparison.
The introduction of complex data types: Arrays, Sets, and Tuples. I normally get sets and tuples mixed up hopefully not after today. I spent some time going through my older run throughs of the material.
In a previous attempt to make it through the 100 days, I had created an Xcode playground with pages for the different days.
I’ll brush this bad boy off and use it to take notes. One of the gripes that I have that waiting for results feels kind of nerve wracking as I’m looking at the little spinner in the corner of the status bar.
I liked using playgrounds sometimes to see if certain lines are valid.
Apparently, you can’t use raw values with associated types in enums.
This one took a while, but I think this time was just a little more fun to do.
Working through Paul Hudson’s excellent 100 days of SwiftUI. I thought about changing the title to reflect the fact that I’ll be going through this but decided to stick with this to show that it’s part of a greater arch.
Having the _ as a number separator is kind of fun to think about because it reminds me that not every language looks at the comma , the same way.
I like the fact that every section that I’ve looked at has an option page on “why” something is the way it is.
Overall, a very good start to an addition of my programming habit!
The last day of my run through!
I get to run the completed application.
Tomorrow I’ll start going through Paul Hudson’s Hacking Swift tutorials.
Work got busy and then the Country’s Capital got attacked so I didn’t put any time into my programming.
Well. It’s time to get back to it. I don’t want not working on my task to be a habit!
Purpose: Create a simple view for the history of the the user’s scrums.
The tutorial certainly reads very well, but every once in a while, you run into a scenario where I feel that they probably could have made it a little better. For example, in the history view we give the preview a string for the preview. The website doesn’t read very well in the browser page that it’s on.
Of course, it looks a lot better when it is in Xcode.
I couldn’t stop messing with the code because I wanted the properties for this thing to stick out.
I’m hoping that if I start using source control for this, I’ll be able to go back and refactor a little easier. This might just be attempting to optimize for something that doesn’t need to be optimized.
I need to do some research on how the extension keyword works in swift and at what point. 
I think I understand that we placed it here because no other view needs to do a translation of the attendees array. A discussion on refactoring is most likely not going to be part of this tutorial.
I’m going to finish the last section tomorrow.
This is the last section of the tutorial.
There were a lot of distractions today, but I’m going to finish this so that I can move on.
Purpose: Introduce the code that will allow the application to record speech.
Although the time to go through this is pretty quick, you would really want to go back and take your time to understand how it’s calling access.
Purpose: Learn about dynamically toggling interface elements to let the user know that they are being recorded.
It was pretty fun to do this section, but I’m still reminded that I don’t like ternary statement. The reason for this is that the question mark means it’s an optional if it’s next to the variable but it’s a ternary if it’s not. The rest of the statement should let the developer know, but if you are new or coming back to an old code…
This is the last section of the tutorial and I’m wondering what I’m going to do after this. I’m going to just do one section today because tomorrow is a big work day.
Purpose: Show how to get use of the phones different functionalities like control of the mic.
The first step is to click the “Add (+)” button but it doesn’t show up unless you have the mouse over one of the properties that are already defined. The interface has a lot of white space that could have been used for something like this and it’s a little misleading.
This is the first time I’ve seen autocomplete not work because of case sensitivity.
Yesterday, I stopped so that I could spend time with my family. I’m going to pick up from the draw an arc spot.
Purpose: Learn about drawing in the application
The tutorial gives me a really good example for a computed property.
private var degreesPerSpeaker: Double {
360.0 / Double(totalSpeakers)
}
Purpose: Display the various segments for the speakers.
The following statement just looks wrong.
if speaker.isCompleted,
let index = speakers.firstIndex(where: { $0.id == speaker.id }) {
}
Are you really saving something by omitting the { and }?
Today’s tutorial is about drawing. I’m almost done going through the entire tutorial and wondering what I should look at next.
The code is pretty self explanitory until you get to places where Swift likes to pour on that sweet, sweet clusure syntax.
private var currentSpeaker: String { speakers.first(where: { !$0.isCompleted })?.name ?? "Someone" }
I had to read that line outloud to fully understand it. My brain had more question marks than the line itself. Luckily, I’ve accustomed to optionals thanks to working with Paul Hudson’s tutorials.
Also, there were some wins for the documentation popups.
Purpose: Create a drawing on top of the circle.
I’m going to stop here because I want to spend some time with my family before bed. It’s my last night of vacation.
Continuing with learning about persistence tutorial
<img alt srcset="https://docs-assets.developer.apple.com/published/8b6dcf46ffef24b1ac64555436587521/600/SUI_100-003.png 1x, https://docs-assets.developer.apple.com/published/0f0b16a34e0c11fdc102fb25bb806d15/600/SUI_100-003@2x.png 2x" src="https://docs-assets.developer.apple.com/published/8b6dcf46ffef24b1ac64555436587521/600/SUI_100-003.png" width="362" height="auto">
Purpose: Show how to load JSON
This section is pretty cut and dry and I look forward to what the rest of the application looks like. I like the fact that the tutorial shows how to load test data during development.
Purpose: This is where the user’s data gets stored from one run to the next.
This is my first time seeing a do-catch statement. I other languages, I’ve seen it as a try-catch and it doesn’t have a specific line on which we are trying.
do {
let outfile = Self.fileURL
try data.write(to: outfile)
} catch {
fatalError("Can't write to file")
}
Purpose: Put the finishing touches on the application.
Other than the part where I put “ObservableObject” instead of “ObservedObject”, I think this was a pretty nice tutorial.
Today’s tutorial is about persistence. I think that’s a good one as I make my way through these various tutorials.
Purpose: Make the models that we’ve been working on conform to a protocal that will allow it to be saved as JSON.
It’s interesting to me that they have file names with special characters like “+” in them for the tutorial.
It reminds me of when I first got into computers and how the teachers would tell us that it’s a big no-no.
Section 2: Create Data Model Purpose: To show how data can be stored. It touches on the Combine framework.
At this point, I think the tutorial should define the difference between the data in the different scrum objects/classes and the one for persistence. Or maybe they have and I jumped over it.
I like the way the documentation widgets work for the most part, but I would love to get more information from it.
Clicking on the link “Open in Developer Documentation”, doesn’t really give me hope I’m going to get an answer for any question I might have.
In the above picture, how is someone new to this going to know that the declaration has a link ObservableObject protocol?
It feels like certain notes should be close to the steps that they highlight.
I love ^I for re-indenting my code.
I’m going to stop here and pick this up tomorrow.
Getting back into the swing of things and I’m continuing with the tutorial. Today is about State Management.
In this tutorial, you’ll add two new features to Scrumdinger. First, you’ll add a view to create new daily scrum meetings. Then you’ll update the meeting timer to keep track of past meetings.
Today, I felt a little more confident in myself and my tools. I went with the option of defining the content of views and closures in the way that Xcode wanted.
For example, Xcode places the following as a method signature.
The tutorial defines the sheet as the following.
Semantically, they are both the same but I feel that the one in Xcode definition is less ambiguous. I’m still learning and want to be able to read this code later.
I pat myself on the back for being able to understand both options.
That being said, I don’t know if I like the idea of creating multiple views in a single line to make a composition.
I can see why you would do it since you aren’t using the buttons anywhere else in the application but I hope that I’ll continue to be able to learn and think in the swift way1.
I don’t like long lines for code.
Much better.
Purpose: Re-enforce the ideas of state.
I’m immediately impressed with the object diagram.
The second section really made things click for me and having the alt-click shortcut allows me to look up the documentation quickly.
I liked today’s progress. I really feel that a lot of stuff clicked for me. This isn’t my first tutorial, and I’ve attempted to learn multiple times in the last couple of years. Today was jun and I’m looking forward to tomorrow.
I’m continuing with the Managing State and Life Cycle section of the Apple SwiftUI Tutorial.
Purpose: Learn about State Object
This sections was pretty small and introduced the concept of “Source of Truth”.
At this point, I got a little side track with trying to get an understanding of how it all comes together and getting the above picture.
I’m not a fan on the syntax for closures and views. Defining a closure in the view means that I have to specify it when I call the view doesn’t make since to me.
I guess it’s part of the language. You can’t have a view that has values that aren’t defined.
Purpose: Lear about audio feed back
Right away, I liked this part of the tutorial because it starts showing me how to use different resources.
Today marks the 7th day that I’ve committed to blogging about my development. This continues the walk through with Apple’s updated1 SwiftUI tutorial.
In today’s tutorial, I’ll be working on the following.
In this tutorial, you’ll learn how to use reference type models with SwiftUI views. You’ll display meeting time and progress in views that better represent the final design. And you’ll integrate with AVFoundation to play audio when the scrum’s state changes.
It’s supposed to be 30 minutes.
In this tutorial, I’ve seen more warnings during the individual steps than I have with the previous days.
For me, this causes a little bit of anxiety as I think more about “how do I make this go away?” Versus “how am what I’m doing going to make this work?”
Purpose: Learning about making composited views
The steps have been pretty easy to follow.
I HATE ternary statements!
minutesRemaining == 1 ? "minute" : "minutes"
All in all, pretty fun to follow along with.
Purpose: Make the component view use dynamic properties
As I’m adding things to make the message signature, I notice that some lines need to be wrapped. Xcode does a good job of making it legible, but I’ve spent a lot of time having code be wrapped at 80 characters for one reason or another.
I decided that I was going to end programming for the day.
As of December 22nd, 2020. ↩︎
As this is Day 6 of my self directed move to learning swift, I’m thinking about how this series of tutorials is only supposed to take 3-4 hours. I think that might be if you just copy past the code or maybe to get people started without worrying that this is going to take all day.
The tutorial for today is about Passing Data.
In the previous tutorial, you used bindings to share state between the edit view and individual UI controls within the view. In this tutorial, you’ll build out the editing functions of Scrumdinger using bindings to share state between different screens in the app.
The biggest thing I noticed about this section in the tutorial is the transition from static values to bindings. There are multiple steps where you reference different parts of a large file. For example step one would be line 7 of a file, then step 2 is line 45, followed by step 3 going to the top of that same page. It would look cool on a large monitor but it’s can be easy to loose your spot.
The second memorable thing I noticed was the note about errors showing up during the process of making these changes.
I had complained about that yesterday and understand that this is an opportunity to see what happens when things go wrong and how to fix them.
This section was pretty fun to do and acted as a reminder that I need to brush up on my closure syntax.
One thing that got me was mistyping srum instead of scrums in different lines.
I actually got to this part by attempting to compile the application and then clicking on the error in the Issue Navigator.
On day 5 of the tutorial and I think I’m growing more comfortable with the keyboard shortcuts.
I’m hoping that future versions of Xcode will have more information in the quicklook for different classes. At the minimum, they could offer a link to get more information or have example of the different styles on one page.
I still enjoy the promotion of accessibility at the very beginning of someone’s journey to be a better programmer. There is also a little
When you’re learning, it can be stressful to see errors and warnings. At this point, I don’t know if it’s just a typo or because I haven’t finished all the lines that I’m supposed to be typing.
Ultimately, I had to do a diff using BBEdit to figure out where the difference was between what I wrote and what was expected. Maybe I shouldn’t code at the end of the day?
Today’s tutorial was pretty good. I did run into a small problem with specifying the destination view.
I think it’s pretty cool that I’m recognizing some of the closures in swift.