Cal Ripken, Jr. & Constants

When baseball fans think of Cal Ripken, Jr. they think of consistency: A man whose name we saw in the lineup for 2,632 straight games, a record streak that spanned 16 seasons. Ripken was a constant in the lineup because his presence there did not change.

And that is what a constant in Swift is: Something that does not change. Constants are established by the keyword "let". Here's an example in an Xcode Playground:

If we even tried to change a constant, we'd throw an error. Go ahead, try to run this below the "let battingThird = "Ripken"" line:

let battingThird = "Murray"

No dice. As his manager assigned Ripken to bat third everyday, so we assigned Ripken to the constant "battingThird".

It is important to note that we do not equate Ripken with battingThird. The equals sign here is not the equals sign we are used to from elementary school math problems. More accurately, we are assigning the value to the right of the assignment operator (the = sign) to the constant on the left of the assignment operator (=). We are assigning Ripken to battingThird just the way a manager assigns a player to a position or a spot in the order.

So, as you can imagine, it's better to read statements that include = from right to left. If "let battingThird = Ripken" walked to the plate, old Yankee public address announcer Bob Sheppard would announce it as, "Now batting, Ripken is assigned to the constant battingThird. battingThird." This is about as intuitive as "When you come to the fork in the road, take it," but there it is.

Why are constants important?
Constants are important because they nail down a value and keep it consistent. Once you know Ripken is batting third, you don't have to think about who is batting third anymore and you can depend on that constant to not change. You can also concentrate on the rest of the lineup which is full of question marks, or, variables.

When do we use constants?
Developers use constants for parts of their code they do not expect to change ever. Examples of this include someone's date of birth, Social Security Number, eye color, and Mariano Rivera's run in from the bullpen music.

On Deck: Jose Oquendo and Variables.

Introducing Your Don Zimmers

In 1996, Joe Torre became the manager of the New York Yankees. He had coached the Mets, Braves, and Cardinals previously, but had never taken any of those teams to the playoffs. And now, here he is in the Bronx where the annual expectation is a championship.

The combination of the Core Four + Bernie and veterans such as Dwight Gooden, David Cone, Jimmy Key, John Wetteland, Wade Boggs, and Paul O'Neill got Torre to the Fall Classic, but it was folks like Don Zimmer who helped him along the way.

Torre was fortunate enough to have direct access to Popeye's 42 years of baseball experience sitting right next to him. As you code, who can you call on to help you through errors, bugs, and general unfamiliarity?

You may not have a pot-bellied old guy in an Army helmet, but you do have access to resources to help you through.

Chances are, you're not the first programmer to run into the error or bug that you have. Others have probably dealt with a similar issue. Some have even posted their issues and fixes online for the benefit of others. If you copy the feedback from the error and paste it into a Google search bar you'll be surprised how many hits you'll get. Here's what that looks like:



More specifically, if you go to StackOverflow and paste your error feedback into their search bar you'll find a number of hits as well. Will they line up with your issue 100%? Probably not. But it's a start and your issue probably parallels what's already out there to a certain extent. Are the volunteers at StackOverflow happy to hold your hand and walk you through your error? Not always, but info is there. It's up to you what you do with it. Here's what a search and response on StackOverflow looks like.

Another good source of information for iOS and Swift issues is the documentation from Apple themselves.  Are there helpful baseball metaphors to walk you through new concepts? Unfortunately, not. It's still rather terse reading, but it's another good start. Here's a look at some Apple documentation.

The Google searches, StackOverflows, and documentation of the world will answer some of your questions and get you closer to answers in other cases. At the end of the day, no matter what your Zimmers tell you it's up to you as the skipper to make a call and go with it. Unlike losing the World Series, the worst thing that can happen is that your application doesn't run (or has a ginormous security hole!) and that you try again.

As a friend recently posted, "The line between a good developer and great developer boils down to who is better at using Google." There's a lot of truth to that so be ready to dig past the first few Google results and deep into the work other's have done to figure out the solutions to your coding problems.

E-6

In 1993, Derek Jeter committed 56 errors playing short for the Single-A Greensboro Hornets. With each error, though, he had an opportunity to learn. Over time, he improved his footwork, he settled down, settled in, and he got a better feel for it all as he worked with Brian Butterfield.

When it comes to coding, you’re going to make errors. A lot of errors. Unfortunately, the computer is not a home scorer who’s going to let one slide once in a while. If you type a “;” instead of “:” that’s an error. If you spelled “player" correctly on one line and then spelled it “playerr” on another line it’s not going to understand and cover for you. It’s going to throw an error the way Jeter used to overthrow his first baseman. 

With practice, you’ll get a better feel for what throws an error. Just know that a high percentage of the errors that pop up early on will be nothing more than miscues (throwing before you have the ball, picking up your glove from the infield dirt too soon, etc). They’ll be spelling mistakes, forgetting to type something altogether, making something lower-case that should be upper-case (or vice versa), making something plural when it should be singular (or vice versa), putting things in the wrong order or in the wrong file altogether.

It happens to all of us.

Blaming the computer is about as useful a blaming your glove after booting a routine grounder.

The good news is errors appear in bright red print in Xcode and they give you a general idea of what went wrong and where in the code the problem might have occurred. Here's an error I made the other day.

Are these pointers helpful? You bet. Do they point exactly to the error and tell you clearly how to fix it? Nope.

Remember those vague words of instruction from the dugout, or worse, the stands? “Throw strikes!” “Keep your eye on the ball!” “Be a hitter!”

Well, no shit. Error notes aren’t going to cheerlead for you, but they may give you similarly vague pointers to fix the error. It then becomes trial and error as you tweak different parts of code to make whatever you’ve written run. 

If you still come up empty, there are other ways to correct or cut down on your mistakes. We’ll get to those in the next post.

If you’re a baseball fan you know that hall of fame hitters get out 70% of the time.

All these dudes failed over 64% of the time. Then they dug in again.

Over the course of 162 games a year, year after year, that’s a lot of failure. Bring that patience with and tolerance for failure with you to coding. It will keep you sane.

*Thank you, baseball-reference-com, for the data and the pic.

Mandarin to Portuguese to Pepper

At the end of my first coding bootcamp a classmate remarked that coding went from feeling like learning Mandarin to learning Portuguese with the hopes of it one day making it to English.

I've described coding as akin to assembling Ikea furniture in the dark with Japanese instructions.

Long story short, it's hard. Why is it hard? How many reasons do you want?

At the end of the day, for me, it comes back to a combination of having no mental picture in my mind to revert to. The first time you travel to a new place it seems to take a long time and you aren't quite sure when you'll get there. The next time you make the trip you see markers along the way that remind you of your progress and you get a better feel for where you are in the journey. There may even be some muscle memory built up from the turns you've made.

In the beginning, coding is like that first road trip. My goal with The Wheelhouse is to align the unfamiliar (coding) with the familiar (baseball) so that it can sink in a little faster and so I can have a richer set of images to associate with coding's abstract ideas. Think of this like the memory of loci, but instead of homes we're using baseball to strengthen our coding memories and abilities.

I'll get into the basics (what is a variable? what is a constant?) and gradually dig a little deeper into Swift and iOS programming minutiae. We'll also get into more general stuff that I've found helpful along the way. Each post will address the following in bite-sized portions:

1) What are we addressing?

2) Why is it important?

3) When do you use it?
4) How does it work?
5) Provide an example of it for readers to see what it looks like (in code and live)

I don't like to make promises, but here is one that I will do my best to observe: I will refuse to use the words easy, simple, basic or obvious when describing any of the concepts or steps ahead. It drives me nuts when tech writers use these words as they make an assumption that may be false while, at the same time, potentially insulting and frustrating to their readers. I still remember what it's like to be that reader which is why I'm writing The Wheelhouse. If I do use the words easy, simple, basic, or obvious in non-sarcastic ways, you have my permission to remind me of the promise I made.

Deal?

Good.