Leveling up

My lab consists of four developers, all bootcamp graduates. We have 2 iOS developers, and 2 Android developers. The Android developers are converted from other disciplines, so they have some experience in other areas besides Android. Both are very good back-end developers, having built back-end systems for the lab in both Ruby on Rails and Golang.

My supervisor has suggested I do the same so in the little spare time I have, I’m venturing into Golang and Dart to learn more about back-end and front-end development. That rabbit trail has led me into systems programming, which has historically been done in C. On top of that, I’m still playing with Algorithms and Data Structures so that I can be prepared for the eventual job interviews after my time at Emory in concluded.

Make no mistake. I’m not a front-end guy. I’m not really a back-end guy. But the pragmatist in me understands the appeal to a candidate that is more well-rounded. I’m not trying to leave iOS or Swift. I’m just trying to make sure I have an understanding of how the other stuff works in conjunction with iOS.

It can be overwhelming. Do I look at several things or focus on just one and get really good at it? I tend to go back and forth. “This week I only want to focus on A&DS” or “This week I’m going to spend the first 30 minutes of work on A&DS and then my lunch break on Dart.” It’s not particularly well-organized, I admit. Still, I’m feeling my way around and trying to find what works best for me. Organization has never been a strong suit of mine.

Podcast ranting

I listen to a few Swift podcasts while driving to/from work. Most of these are quite good. A few months ago, I thought I’d found a promising one. It was supposed to be geared toward new developers and the topics were one’s I was (still am) currently learning.

I was please with the first few from this one particular podcast, but around the time of the inauguration, it turned to more of a ranting/preaching podcast on what the podcaster deemed as not fair/ or “here’s how it should be.” Initially I defaulted to his judgment because, here I was, a brand new developer, and his first few podcasts were helpful and informative. Over time, I discovered he had 1 week more experience as a developer than I did. Not that being new at development is wrong. I’ve learned some good things from him. But once he began preaching about how new developers should or should not do this/that/the other, I began to wonder why he thinks he’s experienced enough to make these kind of opinions. Most developers I talk to on Slack are constantly having to adapt to an ever changing industry. His advice runs counter to that logic. It reminded me of the pointless faculty meetings I sat in on as a teacher and were told “Do it this way.” Why? I have a better way. I have a circumstance that doesn’t make your “way” the best way. Why should I adopt it/limit myself?

I reached out to him to ask if he was planning to go back to discussing iOS dev because lately I didn’t get much out of his podcast. He said he was, so we’ll see. I say all that to say if someone with 30 years experience talks about how much she’s changed in the industry and had to adapt, why does someone with 8 months experience feel like he’s got it all figured out? I don’t like limitations. I feel it stifles problem solving and makes my job boring.

Algorithms

I’ve started working through a book called How to Solve it by Computer by R.G Dromey. It was written in 1982. It was recommended to me on the iOS Developer Slack forum as a good starter book for bootcamp grads that need to level up on Algorithms logic. It’s a great read. The programming language he uses is Pascal, but aside from that he walks through the steps on how to solve basic problems. So far I’ve worked through how to reverse a number, how to convert a decimal number to any other base system (octal, binary, ternary, etc…) and how to calculate the factorial of any number. It’s enjoyable without being overwhelming, which I what I got when trying to solve problems out of Cracking the Code or Interviewcake.com.

Functional Programming

My previous posts on closures has led me down this rabbit hole called functional programming. I briefly touched on FP in those posts without explicitly calling it that. But as I read through a book on test-driven development (writing tests to make sure functions work the way they’re supposed to), the author is trying to move away from what he calls “writing swift in an objective-c way”…aka…the way I currently understand…

For example:

return string.characters.reduce(0) { $0 + (vowels.contains($1) ? 1 : 0) }

This is the Swift-y way of writing what is basically a for-loop and an if statement.

What I think it’s saying is this: take all the characters in a string and starting with a value of 0, reduce all the values of an input I give into one single value. Basically, this is starting with 0 and if conditions are met, we will increase that value. At the end of the function(closure), we’ll have our final value.

Ok…so what exactly are we combining/reducing/evaluating? Well, we’re reducing the characters in a string, but the closure part of the expression above specifies what will be reduced. In this case, comparing the characters of the string to some vowels. If this character matches with any of the vowels, increase the value that we started with (0), by 1. Otherwise, if the character does not match with any of the vowels, increase the value by 0.

I have left a few things out to reduce for simplicity. I could have expanded on what $0 or $1 mean, but I haven’t come up with a good explanation yet. It makes sense in my head, but I haven’t figured out the best way to put it in writing. Perhaps the next blog post will cover that.

I’m still here…somewhere.

I suppose my attempt at twice weekly blog posts was a bit ambitious. I’ve been rather busy at work trying to finish up the second game on our project and while I have explored the topics I’m interested in: enums, functional programming, protocols, and still more on closures, I’ve yet to have time to write about it.

Last week began the annual CrossFit Games competition. The Open is available to anyone who wants to attempt it and serves as the qualifying stage for Regionals, and eventually the Games itself. If you’ve read my blog in the past, you’ll know how important CrossFit has been for me in both physical and mental improvement, so it’s an exciting few weeks for me.

The Open consists of 5 workouts, one per week that are announced on Thursday evening. Participants have until the following Monday, 8pm EST, to complete the workout and upload their score, verified by a coach.

I completed 17.1 at Friday Night Lights at CrossFit Loganville. Last year, I had to scale every workout as I was new to CrossFit and couldn’t handle most of the movements required. This year, I was able to attempt the prescribed (Rx) workout. Big steps for me!

If that wasn’t enough, I attempted it again on Monday too see if I could do better which turned into 5 more reps that I had Friday night. The physical and mental gains are always encouraging for me. It rejuvenates my desire to improve, both at CrossFit as well as at work.

So in the spirit of that rejuvenation, I will double down on my efforts to blog more regularly. Certainly the twice a week goal is too ambitious, but I think twice a month is an acceptable and attainable goal.

The next topic will be Protocols and Protocol-Oriented Programming in Swift, as I used them in a Weather app I built, but didn’t really quite get them. So I’ll explain what it’s doing so as to clarify to myself how they work.

Cheers!
-Chris

Closures – continued…

As I’m reading more about using closures in Swift, and then reflecting back upon the closures I’ve used, it leads me to more questions. Down the rabbit hole I venture!

Below is a closure I wrote last week. In fact, it’s exactly what has led me down this rabbit hole. I got tired of failing my way through finding a solution with no discernible reason as to why it worked. I was lost in Swift-land with no roadmap, no compass, and no sherpa to guide me through. I still found my way home, but if asked to repeat the performance, I knew I wouldn’t be able to.

UIView.animate(withDuration: 0.75, delay: 0, options: .curveLinear, animations: {self.cursorLabel.frame.origin.x = nextAnswerX }, completion: nil)

So what I was trying to do was get a label to move across the screen as the user answers each question. This animation is part of a function I wrote that will move the cursor if the user answers the question or chooses to move to another question using the left and right arrow buttons that I also have on the screen.

So, what is going on here? The animate function is pretty clear. I want to animate something. It takes several parameters such as the duration of the animation, if I want the animation to delay before it starts, the style of animation I want (in my case I’m using curveLinear), and then the last two parameters are called animations and completion.

Those two parameters take a closure. The completion closure I have set to nil because I don’t want anything to happen after the animation has finished. The animations closure, though, I have used.

animations : {self.cursorLabel.frame.origin.x = nextAnswerX }

As wordy as that looks, I’m grabbing the x-value position of my cursor label (where it currently sits) and setting it equal to the x-value position of where I want it to be. The nextAnswerX is a reference to another label’s frame.origin.x value as I don’t want to alter it’s state. I want a copy of it. I actually made that mistake in the first part of the closure, but in the opposite way. I made an instance of the x value of the cursor and was trying to alter the instance instead of the actual cursor. It’s similar to writing a letter, photocopying it, altering the photocopy and expecting the original to have changed as well. Sometimes we want the state of the original to change, and sometimes we want to leave it alone.

Now the odd part is that this animation closure doesn’t use words like return or in anywhere in there. Doing some research, I’ve found, courtesy of the Apple Swift documents:

Animations : A block object containing the changes to commit to the views. This is where you programmatically change any animatable properties of the views in your view hierarchy. This block takes no parameters and has no return value. This parameter must not be NULL.

So, it looks like since the block takes no parameters or return value…which looks like this:

(String) -> String
or
(String, String) -> Int

We can eliminate that part of the closure syntax when deciding what the view should be doing. My code is finding the frame that houses the label, then finding the x value of that frame, then setting the x value to a new value.

To be honest, that may be the simplest closure I’ve ever written. I was curious how they set up a closure that doesn’t take parameters and this is what I’ve found.

animations: @escaping () -> Void

So the animations parameters is an escaping closure that takes a function that returns no value (that’s the -> Void part). Upon further research, the -> Void part is required even though the closure doesn’t return any sort of value. If the closure just had the (), Swift would think it was empty tuple.

The escaping part means the closure will be called after the method has returned. By that, it means “Hey we might need to use this closure later, so lets hang on it.” This could be because the closure is running on a background thread, or waiting for the user to interact with the screen, or some other reason I haven’t yet discovered. My animation only happens upon a button click, and after looking online, apparently happens after the function is called, so it has to be escaping. I’ll admit, I don’t understand that fully right now.

Update: I saw this in the Apple documentation about closures…

One way that a closure can escape is by being stored in a variable that is defined outside the function.

So if I have a variable holding a closure, and I place that variable into a function that accepts the closure, that function will need to be set up to have an escaping closure so I can access the variable later after the function has been called. I don’t think that’s technically what is going on in my situation as I’ve just written out what I want my closure to do inside the animation parameter, but it is the first time that I’ve seen documentation that makes sense to me on when to use the @escaping syntax.

I’ve now gotten to the point where the information I’ve read is a repeat of other information, so I don’t have anything new to add, but suffice to say I’ll be paying more attention to completion handlers and other parameters that require closures to get a better idea of why some have to be escaping and others do not.

As far as the syntax goes, I understand better what is happening, and the short-hand syntax doesn’t unnerve me as much when I see it. I just need to keep writing them the way I’m comfortable until the shorthand becomes second nature. For now, I’m all about code readability.

#fiyf

Closures – my interpretation

I’m going to try and explain to myself how closures work.  This is a normal departure from my usual blog posts as it will be more code focused–which was the original point of my creating this blog.  So my goal is to twice a week, blog about a specific programming topic I’m trying to learn or use, or would like to use in my programming.

So a closure is a function–without a function name.  I write functions all the time.  They’re easy to understand as the function name generally describes what it does.  For example:

func double(input : Int) -> Int {
        return input * 2
    }

This function takes any sort of integer and sends back a value of that integer multiplied by two.

Now, I can use that function as a standalone by calling it…


  double(8)

and it will return a value 16

What if I want to use that function as a parameter or argument in another piece of code?  What if, for example, I want to take a number and divide or multiply by 4 or add 16 to it?  I could write those individual functions similar to the one above, or I could write one function that allows me to customize what I want to happen to the input on the fly.

If that’s confusing, it certainly has been for me.  I’ve used closures and never really understood them.  The code I used was almost always written by someone else and I trusted it worked.  But as I write them more and more, I have this desire to understand why it works.

So I want a function that I can reuse and that I can alter what happens to the input (for example, an integer) at any time.   Basically,  I want my function to accept a number from the user, and then manipulate that number in any customizable way I want; basically, i want to take that integer, modify it, and return that modified integer to be used elsewhere in the function, and return another value.

func modify(input : Int, byApplying f : (Int) -> Int) -> Int {} 

So the stub of the function I have above (which I borrowed from ‘A Swift Kickstarter’), takes a number from the user which I have named input.  byApplying is a placeholder name that Swift 3 has now incorporated to allow the user to understand the context of the argument.  byApplying is basically a nickname for what follows after it — in my case f (shorthand notation for me, the programmer to indicate a function) of the following data type (everything after the colon).

(Int) ->  Int 

In my instance, my function needs to take an integer type and will return an integer type.  Once that argument has performed whatever I need it to do, it will take that answer, and return at the end of the modify function, which is denoted by the return f(input) below.

The first time I saw this, I was confused.  Wait a minute…I’m returning a parameter from the function?  Short answer is yes.  I’m taking the second parameter of the modify function, putting the first parameter into it and returning the value.

So if we look at the original double function from above, we could do something like this…

modify(3, byApplying double) 

So what is happening, is double is taking the first parameter, 3 , and using it inside of it’s function.  It then returns the answer.  Since double is supposed to take an integer and multiply it by 2, it’ll return the value of  6 .

So, for most people, that would work fine…if all you needed to do was multiply by 2..and there are certainly easier ways to accomplish that.  But what if you needed to customize that double function on the fly?  You still want to take an integer and return an integer, but the math involved may change depending on what you need.

You could write other functions and pass it into the byApplying parameter…for example:

func addSeven(input : Int) -> Int {
    return input + 7
} 

and then call the addSeven function in the modify function…

modify(14, byApplying : addSeven)

and it would return the value of 21.

Or you could write the logic of addSeven or double or divideOneHundred directly into the modify function.  Basically customize it as you see fit.

This is where a closure comes in.  it’s basically a function without the function name.  Instead of naming it, you just wrap what you want the function to do inside  of curly braces { }. You also write it where the second parameter of the modify function should go.

modify(14, byApplying: { (input : Int) -> Int in return input + 7 } )

So what is happening here?  Well, the addSeven function took one argument, input, and returns an Int.  The closure above does the same thing, hence the (input : Int) -> Int part in the first half of the closure.  It matches exactly with the argument and return value in the addSeven function.

The ‘in’ part of the closure is what separates the expression in the first half of the closure with the body in the second half.  Basically, the closure reads: “input is an Integer which returns an integer and I’ll use input’s value IN the following bit of code….which in our case is take the input value and add seven to it and return (send back) that value.

Now, that finally made sense to me once I started using closures more, but it was never intuitive.  I had to use the closure, trust it worked, and then the more I used it, the better I became at figuring out how to ask the question on why it worked–a backwards process to be sure, but sometimes code is like that.  It also didn’t help that most of the closures I saw first looked like this…

modify(14) { input in input + 7 } 

or

modify(14) {$0 + 7} 

tumblr_m5wdv30ps91qb7gbyo1_500
They mean the exact same thing as my earlier closure.  They do the same thing.  They just look different.

So this…   

modify(14, byApplying: { (input : Int) -> Int in returninput + 7 } ) 

is using the two arguments in the original modify function, input & byApplying.  However, in Swift (and probably other languages), if you’re last parameter is a closure, you can just delete the byApplying part, close the parenthesis after the input part and write your closure after it…this is called a trailing closure.

becomes this:  

modify(14) { (input : Int) -> Int in return input + 7 }  

but we can take it a step further.  Since Swift can infer (understand) the data type you are using, in this case an Int that returns an Int, the code…

now becomes this:  

modify(14) { input in return input + 7 } 

Basically, it knows that the input parameter is an Integer.  It also knows the closure returns an Integer so we just lop that bit of extra code off.

If the closure only contains one expression, like ours does..i.e. input, we can also lop of the return part…

now becomes this:  

modify(14) {input in input + 7} 

The $0 part is new to me and I have yet to come up with a good explanation or demo, but it basically just means that $0 is the first parameter in the closure (i.e. input) and lop off the ‘in’ so it becomes:

modify(14) {$0 + 7 } 

So for me, who is just now getting the hang of it, I will probably stick with this

modify(14, byApplying: { (input : Int) -> Int in return input + 7 } ) 

or this

modify(14) { (input : Int) -> Int in return input + 7 }  

because the extra bit of code helps explain to me what is happening.  As I get used to closures, and begin writing my own, then I’ll start using more short-hand syntax.

It’s like any other language you learn.  Slang is picked up after you already understand the language.  I’m going to hold on using the swift slang until I feel I can converse normally in it.

If you don’t understand closures, I understand you pain.  I don’t really understand them either, but I want to understand them, so it does provide me with some motivation to learn them.

2016? I’m in the minority…

As I sit here in my office taking a break from some game logic, I just heard that another celebrity has passed away. Social media is naturally frenzied about it and suggests that this year needs to be put behind us and that nobody wants to remember 2016.

I’m in the minority.

While I admit, seeing that some of my favorite actors and musicians have passed away this year (Alan Rickman & Merle Haggard chief among them), my daily routine doesn’t really revolve much around them.  My family is happy and healthy and plays a much larger role in my life.

However, 2016 may be one the best years I’ve ever had.

It started last Christmas when I walked into CrossFit Loganville at the behest of my fellow teacher and gym owner, Lindsey.  She’d seen me struggle to lose weight through running.  She said, you can try it for a week for free.  I started, struggled, and continued.

Strangely, it was this change in my fitness routine that led me down the road to wanting to change my mental routine.  I persevered through some truly awful, but gratifying workouts.  I learned to try new things. I never tried to compare myself to anyone else–just trying to improve on movements and weights that I had previously thought unattainable.  Here I am a year later and still in love with the daily workouts and my pre-Christmas day feast weight was 40lbs lighter than it was a year ago (post-Christmas is most likely less than that).

Around March, my principal came to see me.  This gentleman had given me a chance to switch up my teaching career from teaching economics to programming.  I spent a lot of hours on my own learning how to program so I could teach it.  I’m grateful for the chance he took on me.  He came to tell me he had been offered a position in another county.  It was a step up, and professionally made sense for him.  I couldn’t be happier.

Personally, I wanted to know where my next professional step would be.  I had no interest in education administration.  I wanted to spend more time in code, and less in the classroom.  Teaching was something I did.  It wasn’t something I felt called to.  I loved the complexity and creativity of programming.  It tickled an itch I didn’t know I had.  I was 37 and thought going back to get an undergrad degree in CS was probably not in the cards.

Another teacher I worked with told me about the Iron Yard–a bootcamp that aspires to train non-coders into junior developers in 3 months.  Admittedly, I was skeptical.  I had spent 2 years teaching myself Python, and I didn’t feel I was any sort of programmer.  My teaching was confined to late hours and after school, but I still had spent a good deal of time doing it and felt I knew enough to play around and write some fun, nonsense programs with my students, but 12 weeks, even full-time, seemed too good to be true.

I started researching, and the best resource I found were current student blogs.  Instead of the rosy offers on the website, I was able to get a first-hand viewpoint of what the current students were doing and thinking.  The projects seemed intense and varied…something I was lacking.  Then they graduated, and they got jobs.  I thought maybe there was something to this.

I wanted to do iOS development.  The Atlanta campus, at the time, didn’t have an instructor yet.  Salt Lake City did.  SLC also had a scholarship, which made the cost of living combined with the scholarship, about equal in what I’d pay in Atlanta.  I took a leap of faith, applied, was accepted, and moved out to Utah on May 19 –also the last day of school.  I said goodbye to my students, family, and friends and departed for the unknown.

Truthfully, 3 months alone was probably the best environment I could ask for.  All I had to do was learn.  I had few distractions, and could devote myself completely to code and learning Swift and Objective-C.  I know others may hint at this, but if you treat the experience like a 9-5 job and do little else outside the required hours, you’re doing yourself a disservice.  There is no way I could have accomplished what I have without the extras 4-5 hours at night on my own trying to get my assignments completed.  I lived and breathed code for days.  I made myself take breaks.  I kept wanting to learn.  I had never felt this way in any of my economics or education classes.  I was a sponge hoping to sop up a few more morsels of programming knowledge.

I didn’t know it at the time, but that drive and enthusiasm is probably what helped me get a job.

12 weeks isn’t enough time to learn everything.  The job market is competitive, and the junior developer roles, specifically in iOS are few.  Companies are still feeling their way around bootcamps and what they can and can’t do, and some are starting to warm up to what we have to offer.  Most of us are older, with some decent life experience, a proper work ethic, and are open-minded to being taught new stuff.  There is definite upside.  Still, it’s a slow process.

What all those extra hours did for me was help me develop a routine to survive the job search.  The best thing that happened to me was the feedback from my first interview with a company here in Atlanta.

“At this time, your skills aren’t really helpful to any of our current projects.”

However, following those words in the email were several items they suggested I work on.  It was constructive criticism in its simplest form.  “You aren’t where you need to be, here is how you get there.”

If I had gotten that email at 22, I’d have probably given up.  At 37, I just saw it as a challenge…another movement or weight I needed to achieve in CrossFit…another morsel of programming knowledge that I had to sop up.

I am still a junior developer.  I spend more time reading that I do coding.  Nine weeks into my first job, I’m amazed at how many things I’ve done that I didn’t even know could be done before I started.  I found the right opportunity after pecking away one interview after another.  All told, I applied to over 100 jobs and was offered an interview for 18 of them.  16 said no, 2 said yes.

My dad told me the other day that I sound happy.  I am.  I’m doing something that pushes me mentally.  I’ve learned to balance the physical demands of CrossFit with the mental demands that I require from working.  I was complacent in teaching.  I was bored.

So I took a risk and it has so far paid off.  I’m a junior developer in iOS programming at a university in Atlanta. I have spent countless hours learning, asking questions, and probably the most important part–PUSHING MYSELF to learn about topics that scared or intimidated me.  Meeting that nervousness with renewed sense of vigor and an understanding that I had to make small gains to achieve big gains.  After I solved one task, I look back on it and thought, it wasn’t THAT bad.

So if you’re wondering if 12 weeks is enough to get a job.  Yes and No.

If you expect to be besieged by phone calls on the day you graduate, then No, you will be disappointed.   If you don’t continue to learn new things or go back and try to understand tasks that you did earlier that didn’t make much sense after your bootcamp experience is over, then your interest in this career field is probably not that genuine.  You have to continue that learning on your own.  You’re given some tools, now go build something that interests you with them.  Add new tools.  Ask others how to use them.

If you expect to continue the learning process that was offered by your bootcamp by going on interviews, “failing” at some of them, and doing better on each additional interview, all the while adding to your already heavy knowledge base, then YES, you will find a job, and you will thrive.

2016 has been quite a year for me.  I’m not sure I’m ready for it to end.  However, I have goals for 2017 and hope that this time next year, I have more appreciation for what 2016 has helped me achieved.

 

 

 

Recharging

#fiyf

I’ve been at my new job for 8 weeks.  I have a great time learning topics I’ve never dealt with before and although it’s slow going sometimes, I have yet to doubt myself on whether I’ll solve the problem, nor have I doubted that I’m in the right career.  Stress, anxiety, joy, repeat–the emotions of a coder.  I mean, who gets up in the  middle of the night to go to work to try out a solution to a problem that’s been plaguing them for days?  This guy.

That said, I could tell I was getting run down the last week or so as I skipped CrossFit completely for the week.  This week marks my one year anniversary of when I walked into CrossFit Loganville, so taking a week off in week 51 of 52 is probably not going to hurt me too much.

I also had trouble getting going in the morning once I go to work and just felt worn down.  I’ve probably been running at breakneck speed this entire time and my body said, “SLOW DOWN!”.

So what’s the best way to recharge?  Spend time with fellow coders!

I flew out to Salt Lake City last Thursday to visit the current Iron Yard cohorts, see some of the people in my cohort and teach a kids coding class. I wanted to share some of the encounters I had after I graduate and was searching for a job.  I also wanted to share how I coped with what felt like endless rejection.  But basically, I just wanted to be around fellow people who understand the fraternity that is a bootcamp.  Almost all of us are career changers, a bit older, looking to become the newbie in a competitive industry.

Getting to listen to their projects, answer their questions and basically, finally have a proper Iron Pints was just the pick me up I needed to come back and spend more time deep in my learning environment.  Perhaps boot campers are an anomaly, but we are definitely social creatures.

I don’t know how often I can afford to recharge that way, but I do know that 2-3 times a year is going to be my goal.  I left to head out there hoping to help a few soon to be graduates, but spending time with them helped me too.

img_0019
Downtown SLC during Christmas

A thoroughly disheartening, but then satisfying experience.

I have spent 5 days on one issue.  Such is the life of a developer with no senior developer to lean on when things get tough.  The lab I work in is comprised of Iron Yard graduates.  None of us has more than a year of coding experience.  What this means is that problem solving major tasks always boils down to us.  The web is a wonderful resource, and we use it extensively, but at the same time, tasks will take us longer as we navigate the learning curve of tasks that aren’t generally asked of a junior developer.

I took on a pretty difficult task this week.  Our app is required to send information to a couple of remote servers.  The university wants to make sure the integrity of that data is secure so my lab has built it’s own back end server to connect with first before sending information on to other servers like AWS.  Doing it this way has created some headaches along the way, but will serve us better in the long run.

At the end of last week, a co-worker sent us a client certification to use when making requests to our back-end.  He then went over what is going on when the requests happen.  Basically, both sides want to authenticate that they are who they say they are.  Think of it as having a clubhouse as a kid and requiring passwords by both parties to be able to enter inside.  It’s known in programming parlance as “mutual authentication”.  I trust you are who you say your are and you trust that I am who I say I am.

The problem, generally, is this thing called man in the middle attack.  This attack attempt to get each side to believe they are talking to the correct server, when in reality, you may have been routed to a different server intent on stealing whatever information you may be providing.

An example:  Jon wants to talk to Sansa.  He sends Sansa a letter in the mail.  Petyr, passes by the mailbox of Jon, intercepts the letter and replaces it with one of his own, which gets sent to Sansa.  Jon thought he mailed a letter to Sansa, Sansa believes she’s reading something written and sent to her by Jon, but in reality, both have been duped by Petyr.

So the client certification attempts to prevent this by using public and private key encryption.  I won’t get into how this works, but it’s a more secure way to encrypt and decrypt or in my case, authenticate a user.

To make my calls to another server, I’ve been using Alamofire, a cocoapod that streamlines the amount of code necessary to write to make server calls by creating it’s own function that has all the necessary code behind the scenes.  The pod is written in Swift and I can use it in my projects.  The documentation is pretty good and I felt comfortable using it to send this certification through.

The problem is that while I had Alamofire set up correctly on my end–all the code–including my customized session manager was fine, the certification wasn’t being sent.  I was basically trying to gain access to the clubhouse by knocking on the door and not saying anything to get in.

I didn’t know this was happening until our backend guys sat down with me and watched what was happening on their end when I would make my request on my end.

And therein lies the problem.  I was searching for answers without really understanding the entire problem.  Stack Overflow is a wonderful site and resource to help debug, but you still have to be able to ask the correct question.   My question was too vague, because I wasn’t fully aware of the problem.

In any event, Thursday evening, just before our lab holiday party, we (the backend guy and I) finally found a promising SO post about a similar issue.  My manager which I set up to send the request only had about 1/2 of what it needed to accurately make the request.  The documents by Alamofire, while quite good, don’t handle every single weird scenario out there, just the most common.

My code was making a request, but when challenged by the server on the other end, I wasn’t giving any sort of response.  Pretty much a “knock knock knock”….”WHO GOES THERE?!”….silence on my end.

ch900823
Basically how I felt this week…

 

So Friday morning, I implemented the solution we found late Thursday night and, voilà!  Success.

Strangely, I never worried about not finding the answer.  Yes, it took me most of a week to figure out (although I did work on other stuff too), but I didn’t doubt I’d figure it out.  Reading documentation is key, but knowing the full extent of the problem can make life so much easier to problem solve.  I consider this last week a huge bump in my knowledge base regarding computer science…not just programming.