|
|
Hi. I am Eric. I have dabbled in front end and mobile development for many years. I was once a GIS analyst who did some light weight scripting and was comfortable pulling data from a range of remote sources, but by no means have I ever considered myself a programmer. Most of my career has been in project management, focused on stakeholder management and acting as a client's primary point of contact on a variety of different types of endeavors. I am here to change that. I want to get my hands dirty with code again, and puruse work as an iOS Developer.
As suggested by @Obelix, I will use this thread to share my progress through this course.
I'm starting with Lesson/Day 8 and its wonderful Checkpoint 4. I feel that Lessons seven and eight really took things up a notch.
Day 8
Regarding Check Point 4. As I always do, I started by breaking the challenge down into managable parts.
Some thoughts:
and later in the code:
do {
let result = try findTheSquareRoot(number: number)
print("Your number is \(result)")
} catch {
print("Out of bounds.")
}
- To get started on the whole square root part of the function I relied upon sqrt(). This allowed me to focus on generating random numbers for input, making sure the error handling worked, and my various print statements were in line with requirements.
- Once I had a version working that relied upon sqrt(), I went about making a standalone square root solution function. Wow was there a lot of tiral and error here, including the review of many SO posts about finding square roots, in other programming languages.
- In the end, I made something that worked, but didn't like that I was coming up with ridiculously long Doubles as solutions--I need Ints, also a requirement of the drill.
- Using sqrt() was a tremendous help. Keep things simple. I also used a set Int as my input, a perfect square. Working with the perfect square as an input also helped me focus on making the entire function work correctly, before introducing random numbers as input. I later changed from a set perfect square (for some odd reason I used 900) to random the Ints. I toyed with floor() quite a bit, to help me with test of my input number. I also spent time working with the % operator.
|
|
|
Day 9 - Closures and Cleaner Code
An observation, or maybe a frustration, or how about point of discussion???
Swift does an excellent job of letting developers shorten code--make it cleaner.
As a less experienced programmer, this often frustrates me. Longer version are easier to make sense of and digest, at least for me that is true.
I am getting hit with this in the discussion of closures.
let sayHello = { (name: String) -> String in
"Hi \(name)!"
}
print(sayHello("Taylor"))
The fact that we don't see what I will call an arguement name (or outside name?) makes for cleaner code, but it leaves out a nice indicator of what is required to make the closure or function work.
For me, more syntax can often be helpful.
|
|
|
Checkpoint 5 -- Lucky Numbers
From the hip, here is version 1.0 of my solution to this checkpoint. I will keep after it, as I know there is room for improvement--but I'm out of time right now.
import Cocoa
// Filter out any numbers that are even
// Sort the array in ascending order
// Map them to strings in the format "7 is a lucky number"
// Print the resulting array, one item per line
let luckyNumber = [7, 4, 38, 21, 16, 15, 12, 33, 31, 49]
let arrayWithoutEvens = luckyNumber.filter { $0 % 2 != 0 }
let sortedArrayWithoutEvens = arrayWithoutEvens.sorted()
print(sortedArrayWithoutEvens)
for i in sortedArrayWithoutEvens {
print("\(i) is a lucky number")
}
for i in sortedArrayWithoutEvens {
print("\(i)\n")
}
Output
[7, 15, 21, 31, 33, 49]
7 is a lucky number
15 is a lucky number
21 is a lucky number
31 is a lucky number
33 is a lucky number
49 is a lucky number
7
15
21
31
33
49
|
|
|
Eric makes a case for parameter names within Closures.
The fact that we don't see what I will call an arguement name (or outside name?)
makes for cleaner code, but it leaves out a nice indicator of what is required
to make the closure or function work.
Honestly, I don't have an answer or a rebuttal.
But look at the case below. When I defined someFunction, I just defined a signature that I need. I am leaving it up to the developer to provide me with a function that meets that signature. Indeed, there may be several functions available to a user supplied by a picker selection. I provide two examples.
At the time I define the signature for this function, I dont know if it's someone's first name, peer title, bovine species, or favorite spice.
// Paste into Playgrounds.
// Closure 1: a function that takes a String and returns an Integer
let countChars = { (input: String) -> Int in input.count }
// Closure 2: a function that takes a String and returns an Integer
let almostRandom = { (input: String) -> Int in input.count + Int.random(in: 1...4) }
// someFunction is a variable. not an Int, or a String, or a Bool
// someFunction must hold a function!
// Don't care what the function does.
// BUT the function must take a String and return an Integer.
var someFunction: (String) -> Int // Here I don't know enough to name this string. countMyChars? randomSeedString?
someFunction = countChars // doesn't care what the function does
someFunction("Count the letters in this string.") // What parameter name would you use here?
someFunction = almostRandom // same. doesn't care.
someFunction("Return pseudo random Int.") // What parameter name would you use here?
|
|
|
Eric likes Swifty code.
Swift does an excellent job of letting developers shorten code--make it cleaner.
Which code is easier to read?
// From the hip:
luckyNumber.filter { $0 % 2 != 0 } // Looks like C++ 🤢
// or
luckyNumber.filter{ $0.isMultiple(of: 2) } // This seems easier to read!
|
|
|
Eric sings a familiar song!
Day 8
Regarding Check Point 4. As I always do, I started by breaking the challenge down into managable parts.
Nice! That logic looks very familiar to me!
See-> Elephant Eating Instructions
|
