Swift Pair Programming – Session 8

I’ve been sick for a few days. Didn’t want to cancel pair programming with Nick. We met online at 6pm. I got access to a repo we were working on last time with GPS. Very glad we paired. Finally getting comfortable with Swift. Started in on the agenda and didn’t stop until 7:20pm.

I had a list of topics I wanted to cover last night:

  • Conditionals
  • Coalescing Operators
  • Optional Chaining
  • Guard
  • Defer
  • Unwrapping (forced vs implicit)
  • Typealias

Surprisingly, we were able to cover all of the topics last night. I’m excited because next time we’ll be dipping into xctests.

Here are my notes from the session:

Conditionals are either some() or none(). If they are none that means they are allowed to be nil. If they have a value they will return some() with the value inside of it.

Coalescing Operators allow us to set an enumeration with a default value. If no value is set for it, we will give it this default value

Optional Chaining allows you to code nested ifs. If the first item fails, none of the following nested calls will ever be called. Allows for elegant failing.

Guards are for hacky code. If fails, we will know it and react accordingly.

Defer executes code in a block whether the containing function’s block succeeds or not. I like to think of defer as a function’s deconstructor – use it as clean up.

Code in a defer is guaranteed to execute whether the following code in the method executes or not. We also verified that the defer block has access to variables in the containing method block’s scope.

Unwrapping signals to the compiler, “I know, compiler, this will have a value when this statement is called. It may not look like it now, but I guarantee it will have a value when it needs it.”

Forced Unwrapping differs from Implicit Unwrapping.

Forced unwrapping means that you create a conditional with a question mark. This means that you are telling the compiler that “this value might be nil. Don’t freak out, I know this can be nil.” Then when you use the conditional parameter, you MUST force unwrap it in the method block.

Implicit unwrapping simply saves you from having to force unwrap a conditional every time you use it in the method block. By writing a bang character in the parameter list in the function signature, you are telling the compiler, “I know this might look like it’s nil now, but I promise I will have something in it.” Implicitly unwrapping a parameter, saves time from having to force unwrap a conditional every time it comes up later in the statement block

Typealias is used to make your code more readable. That’s it. Let’s say you create a tuple that holds an int and a String. Let’s say you’re using this to hold a customer id and a string.

Now let’s say you have a tuple that saves an Int and a String to hold a business with a business id and a string. If you just had the datatypes (Int, String) and (Int, String) how would you tell them apart?

This is where a typealias comes in handy. By typing the tuple, you can refer to them with a name rather than have to determine each time you see a tuple with (Int, String).

For customers we could write:

typealias customer = (Int, String)

For employers we could write:

typealias employer = (Int, String)

Questions that came up during the pairing session:

  • Should we use a guard statement, a conditional, an implicitly unwrapped variable, or if let when dealing with potential nils?
    if let n = function_001(), let m = function_002() 
    
      // do something
    
      else 
    
      // return error code
    
      Assignment that may or may not succeed.
    
      Only expects argument

Shared Xcode Tips and Tricks:

  • Set Finder to always show scroll bars – System Preferences -> Finder -> Always show scroll bars
  • Use GPX files to spoof Pokemon Go game – Allows you to play out a GPX file, including location and speed, catch pokemon without walking to them.
  • Fold all code to reduce cognitive load while coding: Shift + Alt + Command + Left Arrow
  • Unfold all code – Shift + Alt + Command + Right Arrow
  • Enable Focus Follows Selection to know where your cursor is at all times – Editor -> Code Folding -> Focus Follows Selection
  • Update the comments in Xcode to show at a smaller font size – About -> Preferences -> Font -> Click on comments -> reduce font size

Questions for next time:

  • Are there any online Swift playgrounds?
  • Is ScreenHero invites open to anyone?
  • Should we start streaming these pair programming sessions on twitch?
  • Mind if I start screenrecording these sessions?
  • What’s the difference between a argument and a parameter?
  • Is there an Xcode plugin that allows finger pinching to scale the font size of the code?

Thoughts to meditate on:

  • Closures are like expressions. Think of it like a parameter, or a return, or a type.
  • Able to capture scope (I don’t understand this)
  • Start xctests next time

Hawaii iOS Developer Meetup – Session 1

I biked to HICapacity at the Manoa Innovation Center and arrived 15 minutes before 5pm. I passed out nametags and felt a strange feeling bubbling up. Haven’t felt it in a long time – Impostor Syndrome.

As more developers piled in to attend the first Hawaii iOS Developer Meetup, I started feeling the Impostor Syndrome ramp up. Good sign right? This means that I’m not the smartest person in the room. And I’m gonna learn things I didn’t even know I did not know.

We had a great first meeting but I wanted to start out with something that might help other people with their own meetups. According to Gitte Klitgaard, Imposter Syndrome “affects smart people. 70% of people you know suffer from it.”

Part of Impostor Syndrome comes from being made aware that you do not know nearly as much as you do. We freak out and imagine we’ll be found out if we don’t know everything.

In the YouTube video, Gitte suggest that networking allows you to know people that know the stuff you don’t know. Now, instead of freaking out that you don’t know everything, your brain can chill and minimize the internal freak out.

She also mentions that getting out of your comfort zone pushes you into the learning zone. I found that pushing your limits is the secret to slowing time.

Prior to the meetup, weeks seemed to be racing by. This week, it’s slowed to the point of feeling like no time has passed at all.

Impostor Syndrome minimized, let’s get to the meat of the meetup.

“I have learned one thing. Showing up is 80 percent of life. Sometimes it’s easier to hide home in bed. I’ve done both.” – Woody Allen

Here’s a list of the developers who attended the first meetup:

Joseph is working on donation app for non profits. Focused on payments facilitation with PayPal. His strengths are building teams. His weaknesses are mobile. He can help with best coding practices.

John is new to Hawaii. He moved here from Washington state. He has experience working on TV apps that feature live streams and security cameras. His strength is OCD. Which allows him to work on a problem until he gets it working. Interestingly, his weakness is that he stops once he’s hit MVP and has a hard time finishing after his proof of concept. He needs help with UI. He is willing to help out with backend.

Mike is originally from Osaka, Japan. He’s been in Hawaii for 15 years. He’s been working for wedding companies. A couple of years ago he started making his own apps in Cocos2dx and Unity. He’s released 5-6 apps on the App Store. His weakness is not knowing Swift. He’s hoping to learn Swift at the meetup.

Chae started in Swift 1 and is now learning Swift 3. He’d ultimately like to put Swift on a server. He’s currently learning Vapor, a web framework for server side Swift. He’s also working on an energy auditing app and wants to put it on a server.

Jonathan is HICapacity member who is finishing up his degree in EE.
He’s currently playing with Elixir, Erlang, PureScript, and ElmEmail servers in Elixir and Phoenix.

Eric attended a bootcamp on Swift. He’s currently doing Unity game development. He has experience using SpriteKit to do games. But he’s interested in switching gears to focus on AR and VR in Swift. He’s also interested in leveraging Siri Kit. Eric made a SpriteKit template for anyone with an idea to drop right in. Eric is also a artist and painter who does animation.

Paul has a PhD in electrical engineering. His background is in C, C++, and ObjC. His strengths are algorithms. Unfortunately, he doesn’t have enough time to play with new stuff. He’s developed in Obj and enjoys hardware projects.

Jesse doesn’t have much programming experience. He’s interested in creating VR music videos. He’s just purchased a $700 3d camera that arrives in March.

Notes for Improvement

With such a varied group of developers I struggled with how to best serve them and make Thursdays from 6-7pm as beneficial as possible.

Initially the meetup agenda pivoted on introductions. I was hoping that the introductions would be a launching pad for informal conversations and camaraderie. And I still believe the format is right. Now, I see how important it is to provide a second track for developers who aren’t ready to share their progress.

I feel like it’s important to provide some kind of learning time which could take the form or a info session, article discussion, or free form conversation. I’m going to try this out at the next meetup today.

I will be requesting suggestions from the developers to build up our repository of interesting articles, tutorials, resources, open source projects.

I sent out messages to all attendees for feedback on the first meetup. The number one most common request was to move the start time from 5pm to 6pm. Now we are meeting at 6pm.

That’s it for the recap of the meeting. I am eager to see how this meetup evolves over time. I am confident that the start time will allow more people to attend.

If you are interested in attending, please RSVP for one of our weekly meetups here.

Misc Thoughts

  • Post XCode keyboard shortcuts
  • Post screenshots of current projects
  • Schedule first talk
  • List articles we are interested in talking about
    • Fuckingswiftblocksyntax.com
    • Text to speech
    • Push notificaitons (Ray Wenderlich)
    • Lets Encrypt
    • https://whatilearnedtoday.io/
    • Swift Style (Ray Wenderlich)
  • List book recommendations
    • iWoz
  • Lingering questions:
    • Why swift on the server?
    • Can work with MySQL
    • What else?
    • Why is this better?
    • Swift playground online?
    • Installing Swift on linux
    • Installing Swift on Windows 10 / 7

The first draft of anything is usually complete sh*t

img_2273 I had a meeting with my supervisor today. She congratulated me on writing such thoughtful posts🙂 She mentioned that she had a hard time writing posts herself. So, I thought I’d write a blog post to discuss the procedure I use to write posts. It’s the same process every time.  I’m proud of the results. The difficulty of just getting started can be daunting. The “tyranny of the blank page” is terrifying. Read on to learn about my process.

TLDR; Follow these steps to get over your fear of writing a blog post:

  1. Read a lot
  2. Highlight the good parts while you read
  3. Transcribe the notes you made from the book
  4. Identify the quotes that speak to you the most
  5. Copy and paste the best quote at the top of the post
  6. Freewrite for 20 minutes by elaborating on the quote
  7. Don’t even think of posting this online
  8. You did it! Now get comfortable with shitty first drafts
  9. Read it over 3 times
  10. Take out the redundancies. Add more quotes.
  11. Embolden your most salient points
  12. Tell them what you taught them
  13. Leave the reader with a challenge or a question

I hope that by the end of this blog post you will have learned how to find blog post ideas, get over the fear of the blank page, learn how to format your post for easy scanning, and ideally start posting regularly.

Read a lot

Here’s a list of the books I recently finished reading:

How do I manage to read so many books?

  • Schedule an  hour of reading time every day.
  • Split your time between 3-7 books so you never get tired of one.
  • Don’t read books that suck.

I read nearly every book on the history of computing that I can get my hands on. One book keeps coming up: “Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age” by Michael A. Hiltzik.

Sorry Mr. Hiltzick. I’ve tried getting through this book multiple times. But the writing is so stilted I had to finally just say, “I pass.”

Most books aren’t required reading after college. Don’t waste your time. Find another book that holds your interest. Life’s too short to waste time reading dull books.

Highlight the good parts while you read

I don’t read without a mechanical pencil. If I don’t have a pencil to take notes while I’m reading there’s no point.

Here’s a photo of the mechanical pencil I use to do my bracketing:

img_2277When I find a great quote, book recommendation, or a wonderful turn-of-phrase, I draw a bracket in the margin curling around the quote that I want to remember.

If it’s a book that I want to read, I draw the bracket with my mechanical pencil in the margin and write a little “b” to remind myself that I was interested in borrowing this book in the future.

If it’s a word I don’t know, I bracket the word in the margin and write a little “d” next to it. This reminds me to look up the word I didn’t know.

This slideshow requires JavaScript.

Transcribe the notes you made from the book

My friend’s mom was my English teacher in 12th grade. She said something in class one day that I didn’t understand at the time:

You only really understand a book the second time you read it. While you’re reading the book the first time, you don’t know the points the author is trying to make. Only, once you’ve finished the book, do you have the full picture of what the author was trying to say.

This advice didn’t made sense to my high-school-brain. It only made sense when I started bracketing out the quotes, book recommendations, examples of good writing.

Transcribing the notes later give me a chance to reread the book. This way, I’m not re-reading the entire book, I’m reacquainting myself with the best parts that are now clearer having read the entire book.

As I reread through the book I transcribe all the good parts into my notes. I like to call these notes my “Takeaways.” These takeaways are the gold I’ve uncovered by reading the book. By transcribing these takeaways, the points have a chance to hit me again.

Identify the quotes that speak to you the most

I read through my list of takeaways and fix any typos along the way. During these error correcting passes, I pay attention to which quotes provoke a reaction.

I highlight these reactionary quotes and continue to fix the typos. Now you have the list of quotes that will be the starter for your blog post.

Copy and paste the best quote at the top of the post

Open up your favorite writing program. Mine is Sublime Text. It’s free and great for writing. Sublime Text simplifies the process of writing.

Got your writing app open? Great! Now copy and paste the quote at the top of the page. Got it? Good, let’s keep going.

Freewrite for 20 minutes elaborating on the quote

Set a timer for 20 minutes. Now get started. Free write. Do not stop freewriting until that timer dings. No. Matter. What.

Sit with the problem. Stare it in the face. You’re not on stage. This private time with the page is for screaming your crazy ideas into a pillow.

Write like a little mouse scratching at a wall to break through – blindly, passionately, like your life depends on it.

Get it all out of your system. Discover connections between different types of work, politics, money, ethics, favorite foods, behavioral psychology. Make connections! Dig deep! Mine that gold!

Write and write and write. Go off on tangents. This doesn’t even have to be prose! Make lists. Compare pros and cons. Come on! Just get started and keep going until that timer dings…

Ding!

Don’t even think about posting this online

Finished writing? Immediately take a break. Close down the text editor. I mean it. Hell, shutdown the computer. Get away from it.

Go wash the dishes. Go do anything else that will take you away from the page.

Resist the urge to read through what you wrote. No one is going to see it. No one is going to judge you on it. Especially not you if I have anything to say about it.

This is not the time to revise. This is the time your subconscious has a chance to chew on the content you just created.

Feel like you need to look at the first draft again to refresh your ideas? NO! Keep away from it. Let it mature on its own. Trust your body to work on the content while you give your conscious mind a break.

“A watched pot never boils.” – Arcade Fire

You did it! Now get comfortable with shitty first drafts

Steven Pressfield is famous for writing “The Shawshank Redemption” and “The War of Art.” He’s a fantastic writer with a voice that cuts through the bullshit, addresses the lizard brain, and produces results despite an active inner critic. I reread his books and relisten to his audiobooks to “defeat the inner critic.”

Pressfield blogs too. He wrote a great post on accepting the shittiness of first drafts, getting them out, and allowing them their need sit untouched:

“If you start re-writing, you will despair.  The reason is obvious.  The first draft of anything, until you’ve written 10,000 stories, is usually complete shit.  That’s just the definition of a first draft.  If you despair, you will not finish the draft. Simple logic.”

Read it over 3 times

Now you’ve let your first draft mature like a fine cheese.

Your subconscious has been working overtime, redrafting your points, making connections between your writing and other disciplines, and things that have happened in your life that remind you of what you’re writing. You might even get flashes of lessons you learned growing up. If you’re lucky you might even get insights into your hidden culture.

After this proofing time, your subconscious has digested enough that it will guide your through the process of pruning your first draft.

Take out the redundancies. Add more quotes.

Remove passages that waste the reader’s time.

Take out the passive voice. Read it over and over and over. Craft it. Steer it. Feel where it’s going.

See points you made that need more examples? Find more quotes in your takeaways that support the point you are trying to make. The quotes don’t have to come from the same book.

Better yet, look for quotes from other books to reinforce the points you are trying to make.

Great! You’ve pulled out the shitty parts of the first draft and added supporting quotes. Now it’s time to think about the presentation of your blog post. The content is great. But we need to persuade the reader to read what you wrote. We do this by cutting the post up into visibly digestible sections.

Embolden your most salient points

What would happen if you opened a 200 page book and there were no paragraphs? I know what I’d do. I’d close the book and take it back to the library.

People are not willing to waste time reading something that has not been formatted for easy digestion.

Cut up long paragraphs. This is not a book. This is a blog post. Make it easy to read.

“Short sentences get read.” – Seth Godin

Tell them what you taught them

I learned this lesson from my professor. The hardest thing in your life will be communicating your ideas clearly and having the receiver (your readers) hear the message you intended to send.

This advice can be applied to blog posts, presentations, books, trainings, etc:

  1. Tell them what you are going to teach them.
  2. Teach them.
  3. Tell them what you taught them.

Leave the reader with a challenge or a question

Shitty first drafts are required. They are expected and thus acknowledged and accepted. Do not stop until you have made your point. It doesn’t have to be eloquent. It just has to exist.

I hope this has helped remove the “terror of the white canvas/page.” Finish your first drafts no matter what! Then let them sit. Clean them up, pretty them up, and add more quotes to reinforce your ideas.

Gambate! Go forth and write shitty first drafts!

Has this blog post helped you write a shitty first draft? I’d love to know! Email me a link!

Swift Pair Programming – Session 7

steve-jobs-and-wozniak-1977

Fantastic pair programming session with Nick last night. In the span of 1 hour we solved a datatype casting issue and set up CoreLocation on a new project.

Last week we were stumped authenticating with Twitter through an p2/OAuth. The code was built to OAuth into github. I had an hour after work so I looked for another OAuth library and found OAuthSwift.

Unfortunately it doesn’t build. I tried it both ways. Once with a Podfile to install. And another time dragging in the xcodeproject file and adding the framework to the target’s Build Phase. No Dice.

Building the app fails with 366 errors. “That’s cool,” I thought. I’ll just update the code to Swift 3 syntax. Minutes later, do another build.

Great. Only 306 errors.

I switched it up and switched targets to the demo build within the OAuthSwift project. Hit build, still errors errors errors.

I wasn’t satisfied with the outcome. What am I doing wrong? 

I got the idea to test building against a trivial open source app on github written in swift. Enter FlappySwift, a nice little flappy bird clone. NOTE TO SELF: Use this framework to build Mathogen in Swift with SKSprites.

FlappySwift built with no errors!

The issue was not with my Xcode installation or configuration. It’s in the OAuthSwift library. I was in the middle of submitting an issue to the maintainers of OAuthSwift when Nick called me on ScreenHero to start our pairing session.

We visited for a bit and talked about how we each spent our respective Thanksgivings. I shared that I had been working on OAuthSwift for the past hour. And we decided to shift our focus of the night to other things.

OAuthSwift, you’re still in my sights. I will get you to work!

We decided to make a list of the things we wanted to pursue next. Nick had an issue with an NSObject passed in a local notification. This weekend I added push notifications to my app and learned that my app needs to have a https connection in order to receive push notifications. I did a hacky workaround that allowed for http but felt weird about it.

I suggested working on creating SSL certificates with LetsEncrypt, but it seems kind of server based. The pairing session is for iOS pairing!

We decided to focus on Nick’s Notification code. Here’s the finished code:


//: Playground - noun: a place where people can play

import UIKit
import CoreLocation

var str = "Hello, playground"

//enum NotificationTitle {
//    static  NotificationToPostName
//}
typealias payloadDict = [String: AnyObject]

class ReceivingClass: NSObject {

func registerForNotification() {

NotificationCenter.default.addObserver(forName: NSNotification.Name(rawValue: "TheNotification") , object: nil, queue: nil, using: { notification in
let tuple: (CLLocation, String) = notification.object as! (CLLocation, String)
print(tuple.1)
})
}
}

class BroadcastClass: NSObject {

func postNotification()  {

let myTuple: (CLLocation, String) = (CLLocation.init(latitude: 12.1, longitude: 12.2), "The String")

let notification = Notification.init(name: Notification.Name(rawValue: "TheNotification"), object: myTuple , userInfo:nil )
NotificationCenter.default.post(notification)
}
}

let receivingClass = ReceivingClass()
let broadcastClass = BroadcastClass()

receivingClass.registerForNotification()
broadcastClass.postNotification()

Here’s the exact place in the code we were able to sort it out:

let tuple: (CLLocation, String) = notification.object as! (CLLocation, String)
print(tuple.1)

Can you see where the object in the tuple needed to be casted before it was printed? The tuple holds a string but the compiler doesn’t know that. It needs to know that this data is a string or else it’s like, WTF man?

Having made quick progress squashing that bug, Nick asked me what I wanted to focus on.

I said I was interested in GPS. I haven’t worked on any projects that have used GPS yet. We dove in and created a quick project. After the session Nick posted it to github. You can check it out here: Stalker.

Programmers come up with silly names for their projects to keep ourselves from throwing the computer out the window🙂

Over the course of the rest of the pairing session I learned the following:

  • In order to add GPS functionality you need to add keys and values to the plist
  • Set the values with strings that will come up in the alert.
    UIBackgroundModes
  • Call Background Execution to keep the app polling for updated locationDo the location requests in the View Controller

Before the next meeting I am going to do the following:

  • Check out the swift style guide.
  • Read the rest of the fuckingswiftsyntax
  • Check out crashlytics for showing
  • Can add a bash script to run on start up.
  • Add a new buildphase and run the script there.
  • Create PCH file: pre-compiled header file in objective C to hold OAuth tokens and keys.
  • Use typealias to set the kind of datatype you want to use. EG: typealias payloadDict = [String :AnyObject]
  • Write all code in Swift 3.

And here are some unsorted extras:

  • Command + 1 to zoom in on the simulator.
  • Asked Nick how he learns. Videos? Nope, gets into a blog post or a how to and just dips in and dips out. We agreed that we both get stuck and a little fatigued learning the entire codebase at once. Good to dip in and out of documentation.

Looking forward to the next pair programming session! In other news, the first Hawaii iOS Developer Meetup is tonight at the Manoa Innovation Center at 5pm. See you there!

Whiteboarding C Programming

image11

Today after pivoting from pseudocode on the whiteboard, I had J do FizzBuzz on the whiteboard. I set my timer for 20 minutes. I was surprised when he said he was finished. 3 minutes had passed. Somebody is getting good at this🙂

Question Posed:

How would you code in C to make the computer fizz when it finds an even number and buzz when it finds an odd number?

But did he get it right? What about checking the input? An hour later I had the code from J after it had been put into Eclipse and tested:


#include <stdio.h>
#include <stdlib.h>

int fizbiz(int num)
{
    if(num%2==0)
    {
        printf("fiz \n");
        return 0;
    }
    else
    {
        printf("biz \n");
        return 1;
    }

}

int main()
{
    int number;
    printf("Type in a number: \n");
    scanf("%d", &number);
    int result = fizbiz(number);
    printf("Remainder is: %d",result);
    return 0;
}

Next we’ll build from this simple little code snippet into a programming adventure that will reveal the importance of pointers and addresses, compiler specific caveats, and data type reveals!

Question Posed:

How would you update the code in C to have the computer take in an array of numbers?

UPDATE: I asked J to update the code to take in an array of numbers and he sent this back to me:


#include <stdio.h>
#include <stdlib.h>

void fizbiz(int num[])
{
  int i = 0;
  while(i<10)
  {
    if(num[i]%2==0)
    {
        printf("fiz \n");
        printf("Remainder is: 0 \n");
        i++;
    }
    else
    {
        printf("biz \n");
        printf("Remainder is: 1 \n");
        i++;
    }
  }
}

int main()
{
    int number[] = {11, 22, 33, 44, 55, 66, 77, 88, 99};
    fizbiz(number);
    return 0;
}

I want the problem of data types in C to reveal itself in the exercise. Just asked him to update the code to fizz on chars and buzz on ints. Very interested to see how he approaches this!

Question Posed:

How would you code in C to have the computer fizz on chars and buzz on ints?

UPDATE: Five minutes after emailing J the new request he emailed me his updated code:


#include <stdio.h>
#include <stdlib.h>

void fizbiz(int num[])
{
  int i = 0;
  while(i<10)
  {
    if(num[i]%2==0)
    {
        printf("fiz \n");
        printf("Remainder is: 0 \n");
        i++;
    }
    else
    {
        printf("biz \n");
        printf("Remainder is: 1 \n");
        i++;
    }
  }
}

int main()
{
    int number[] = {11, 'b', 'd', 55, 77, 'f', 'h', 99, 33};
    fizbiz(number);
    return 0;
}

Reading over the code, the concept started to open itself up. I remember reading somewhere, “In order to recreate you must first break it into pieces.” If you listen closely you can hear the problem cracking. I emailed J the following.

Question Posed:

How would you code in C to have the computer fizz for a char and buzz for an int? We are no longer checking for even or odd. We are checking datatypes.

Very interested in seeing the code that comes from this request. Will he get it?

UPDATE 3: With a single import of ctype.h, J was able to check to see if the current element in the array is an alpha character or a numeric character. Not exactly what I was looking for but who’s at fault when the problem is not clearly defined?


#include <stdio.h>
#include <stdlib.h>
#include <ctype.h>

void fizbiz(int num[])
{
  int i = 0;
  while(i<10)
  {
    if(isalpha(num[i]))
    {
        printf("Character: fiz \n");
        i++;
    }
    else
    {
        printf("Integer: biz \n");
        i++;
    }
  }
}

int main()
{
    int number[] = {11, 52, 'b', 'd', 51, 23, 'f', 'h', 45, 13};
    fizbiz(number);
    return 0;
}

I decided to be clearer in my instructions. How can I phrase the question without having to indicate how to solve it?

Question Posed:

How would you code in C to make the computer create an array of ints and longs then fizz for ints and buzz for longs?

Interested to see how he updates the code🙂

Update 4: J sent me the following email:

Hi David,

I just found that the size of an int and long are both 4 bytes. Did you want me to compare another datatype?
Int – 4 bytes
long – 4 bytes
float – 4 bytes
double – 8 bytes
char – 1 byte
J
Exactly what I was looking for! Now I’m interested in showing him the difference between a signed int and an unsigned int. I sent him the following question:
Hi J,

Good going! Please update code to fizz for int and buzz for unsigned int.
David
I’m looking forward to what he discovers along the way!

Swift Pair Programming – Day 6

swift

Last week Nick and I took another run at OAuth2 in Swift. Hawaii isn’t affected (neither fall nor spring) by Daylight Savings Time. I called him an hour early while he was still driving back from work. Once we determined why the scheduling was incorrect, we reconvened and dove back into OAuth with Swift.

Unfortunately we weren’t able to get the application to authenticate. After the first run through, I looked deeper into the actual OAuth process. I have a better understanding of the delineation between Consumer Keys and Consumer Secrets versus the Access Keys and Access Secrets.

I suspect that we are unable to connect because we are using an open source library to connect to Twitter that was actually written to use OAuth to connect to github. The list of attributes necessary for the connection are different from the way we are meant to connect with Twitter.

As our pairing time was winding down, we did two things. We searched for another open source OAuth repo to test with. We also talked about how we both don’t really understand lambdas.

“Wait, have you heard of this fucking website for Swift closures?” Nick asked.

Thinking I hadn’t heard him correctly, I said, “No.”

He was already sharing his screen and opened up Safari. He started typing in the url, “fuckingswiftblocksyntax.com” and I couldn’t help  laughing. Once we finished typing the url I couldn’t hold it in. And laughed for an uncomfortably long time🙂

To put this in context a few weeks back he shared a JSON parser called Freddy. Their tagline is:

“So, Freddy vs. JSON, who wins? We think it is Freddy.”

You have to add some levity to this profession that sometimes feels like crafting concrete skyscrapers with steam. That’s the thing about the profession. There’s nothing tangible. We’re working with electricity. Making it to magical things. And it could break at any time.

Nick also mentioned a testing framework that was developed to allow debugging inside the simulator but I can’t remember it now. I made a note to myself to ask him tomorrow.

This weekend I successful set up push notification in my app. Hemingway was famous for saying that when he was writing he would always stop at a place where he felt he could easily get back into the groove the next day.

As I get more and more experience developing I find myself forcing myself to stop as soon as I have made some serious project after a full day of working. Knowing when to stop to avoid burn out is a hard lesson to learn, an even harder rule to follow, but a worthwhile lesson in humility, patience, and love of the craft.