App Academy View: iOS in SF

Hi everyone! It has been a long time since I first walked into the App Academy world in 2012. Ever since then, I have continued to receive numerous questions from aspiring programmers trying to decide or prepare to take the plunge. I haven't had the time to keep up with every individual email or message, so here is a compilation of the most frequent concerns. Enjoy!

Link to the FAQs

So one of the most popular questions from interviewers at Demo Day was, "What's next?" That one was especially easy to answer; the next step, of course, is to make sure we keep learning. An important step in that process is making sure that we get jobs where we continue to be challenged to take on brand new problems every day, and in order to land that kind of job we're going to need to not just brush up but polish, varnish and shine our problem-solving skills. 

It has been an incredible ride at App Academy. I can't believe it, but the nine weeks of heads-down, full time coding under Ned's mentorship have finally come to a close. You can see what I ended up having to show for it here! I was going to say that I am going to really miss coming in and working with this bunch of people, but I don't exactly have to do that yet. As all of us know that finding the right job is going to be a difficult, demanding task, we're all inclined to take it on together and help each other out in preparing for this daunting endeavor. Yesterday, our first Saturday after the Big Day on Friday, we already met up at one student's house to talk about data structures and to practice whiteboarding problems in front of one another.

There's no stopping us, really. The class may be officially over but the momentum is so intoxicatingly high that through sheer inertia I'm not at all compelled to let up the pace. But in terms of closure I can say that during these nine weeks of non-stop long days in San Francisco programming with some of the brightest people I've ever worked with, I've learned so much more than I could have imagined, not only from the jam packed curriculum and the awesome leadership, but also from the wonderful variety of perspectives imparted by the students with their eclectic range of experience and backgrounds. I am going to miss coming in to 'the Office,' but I think it's best to focus not on what we're losing, but on what we can take with us.

Today is going to be our last day of class, and as though finishing our projects wasn't exciting enough, last night we also got a taste of the interview process. Ned and Kush gave us a little talk about what to expect in technical interviews, and how we ought to handle it when things get tough. Here are the main lessons we took out of it:

Clarify. Before jumping into a problem, ask questions until you know that you're on the same page as the interviewer and you understand the prompt.

Keep talking. While writing code on a whiteboard or paper, whatever you do, even if you have to stop coding in order to think, do not stop explaining your thought process. This gives them a chance to give you hints or at the least, to know that you're not brain-dead.

If you get stuck, simplify, try an example, or break things down further with questions. If you don't know something but you've heard about it, tell them you've heard about it.

Do the easiest version of the solution first so that you get something down; worry about optimization later, if they even want you to.

Work in a language you're familiar with.

It was a little bit brutal and a little bit amazing, the way they taught us these things. They called up three students one by one to the white board and straight up posed some common interview questions. We got to watch our fellow students apply the above ideas and do their best to go with the flow, sometimes stunning us with their aptitude and other times making us realize where we could get stuck.

 Yesterday we talked about facebook integration in a mobile app. Basically all you have to do to get started is install their SDK, either via CocoaPods or from their website, and then you start writing some OpenGraph methods; Open Graph is their API that you make calls to, using 'graph paths' that get you access to different resources. The login process uses OAuth behind the scenes, so your app never gets the user's password, making it fairly secure. 

Now we've got two days left in class, today and tomorrow, and that's it! Most of the day in class is pretty quiet now, as we each code away at our final projects, deciding what's important enough to polish up by Friday. So in two days, at 9AM, what's supposed to happen? Well, we've put together short bios and links to our projects, which presumably, Kush has sent off to any prospective employers who have already signed up to meet us.

So in the morning (early as it is), we'll all be there bright-eyed and bushy-tailed ready to show off our work. We'll have five-minute or so interviews with each of the prospectors who show up, and in that short amount of time do our best to demonstrate our capabilities, while sizing them up as people we may or may not want to work with. This goes on for up to three hours after which time, the sixteen of us and our mentors will stand around going, "well." "yep." and then sigh a huge sigh of I-don't-know-what-yet. That doesn't sound so scary. Bring it on.

We went in yesterday, on a Sunday, to work on our projects and learn a little bit more as the ninth and final week of App Academy begins. I finally have most features of my app working almost all the way, so it was a good experience to hand it off to people to play with and get back some honest criticisms.

There are always a lot of little things to think about with User Experience, but with iOS in particular where convention is so enforced, largely by Apple, you might be surprised how many details are expected to be just a certain way in order to make the interaction feel "natural" to the user. A button being in the wrong place, a weird transition, a keyboard not hiding on enter, these are all going to be noticed by the user. So even once I do have the functionality down, I see that I'm also going to have to make a lot of detail checks to polish it up, which is exciting, but also daunting as we only have four days left before presenting our projects.

Toward the end of the day, Ned started talking to us about Hadoop and Map Reduce, which are methods for processing huge amount of data by means of parallel computing; it involves splitting up the workload amongst many computers and then aggregating all the work back into a final analysed result afterward. There are three phases to the Map Reduce process: first, each of the computers gets part of the work and does it, this is the map phase. Then, the 'shuffle': each key (in a hash which is key=> value), is assigned to a computer, and all of the other computers send any work related to that key to that computer until all computers have a distinct set of keys. Lastly, the 'reduce' phase, where all of the work for all of the keys is put together into one giant hash.

It's Sunday, and we're in class. Our new challenges are: make our apps presentable, and figure out how to present ourselves. With interview day just five days away, how should we balance the two concerns? We need to have something concrete to show for our abilities, but we also need to be mentally prepared to answer questions about things we may not have been concentrating on to build our projects.

Yesterday, we worked all day as usual on our personal projects, and during the last hour, we all demo'd our apps to one another to get a glimpse at what the rest of the class was working on and to give us the experience of having to answer questions. Everyone seemed to have a really cool and interesting project going on, which was wonderfully exciting but also somewhat worrying - I didn't feel like my project was really up to snuff during the presentations, largely because instead of implementing sparkly features, I spent long hours over the past two days struggling (successfully) to get a better understanding of some tricky concepts, namely authentication and data stores. I'll share my painstakingly newfound knowledge here in its simplest form. There is no concept of a session in iOS, but there is authentication. With RestKit, you will basically send your credentials to the server every single time you make a request, and the server will validate you for the request. If the backend uses AuthLogic, as mine did, it by default finds the current_user (which it uses to validate) through the user_session, which doesn't get created by the iOS app, so after hours of trying various things, it became clear that this was where a change had to be made, and I had to redefine "current_user."

I also spent a very long time switching my data pattern over form RestKit-based dataStores to internal CoreData files, so that the app will fetch all the current data from the web when it has internet connection, but it will also cache everything it brings down so that you can  still see all the records when you are not connected. The reason that it took a long time and a lot of headaches for me was that I was unable to find the basic data-flow explained before I dove in, and a lack of the big picture when it comes to intricate processes like data flow can lead to a lot of inefficient design decisions and bugs. I drew the picture above in order to perhaps save someone else the heartache.

Last night, a few of us went to a drink-up at Parse, who is celebrating the release of their new 'Cloud Code' feature, and we were repping App Academy pretty hard. It's becoming apparent to me how valuable networking is when you're learning and/or looking for a job, but the more valuable lesson was a moment when I sort of put a couple of things together. A guy who works at CueUp.com asked me, "What is your specialty?" and my very first mental reaction was "What? I don't know! I don't have a specialty..." but I realized that this was not a satisfactory response. I wanted to have an asnwer, so I thought about what I am currently working on, and said "We've been really focused on iOS for a while, and the things I'm working on are quite focused on RestKit API interactions and custom views." Voila, an answer 100x better than I don't know. I've been reading a little bit from this book that a few classmates recommended, Programming Interviews Exposed, and the chapter I just read talks about how important it is to demonstrate above all else that you have a logical thought process. The context was in regards to tough programming questions, and the gist of it was that when you get stuck, the worst thing you can do is to give up or say nothing, you have to at least show that you can try, even when you can't succeed.   

I'm thinking this idea applies to a lot of things and especially to a lot of things directly relevant to where we're at right now, with eight days left of App Academy, hardly any time to finish up our projects and try our best to let them show what we can do. What are we going to present at demo day? What are we going to say we can do? During the process of building on our own this past week, I've tried to apply this to my everyday workflow and I've learned quite well how to not ever stop. If something gets tough, narrow it down to its most basic parts, and many times this allows you to solve it but when it doesn't, it allows you at least to communicate it to a source that may help you solve it. Even then if that source is not available, isolate the problem and move onto a new one.

And when it comes to problem-solving, the first answer isn't always the best answer, sometimes you're going to have to completely scrap what you've done and do it differently. This is how I ended up getting unstuck from the problems I had with RestKit: First my JSON data was stored as an NSDictionary in Objective C, but this didn't allow me to set properties on it, so I created an Class and a Store. Then RestKit wasn't calling its delegate methods, so I switched to blocks, and everything worked. Then I ran into another problem when I got to the question of how to allow my app to post to the API, so I switched from blocks to Object-Mapping, a really cool feature of RestKit whereby you can translate a JSON object into an Objective C object by mapping values for keys to attributes. This may not have been the most efficient workflow in this case, but it led to an elegant solution and it taught me a lot. Now we're moving on to bigger and better things, like remote user authentication and mapping to CoreData. Every second I just feel like I've really got my work cut out for me.

Yesterday and today we didn't have any lectures, and we didn't have any pair programming, just ~9 hours of heads-down planning and coding on our own personal projects, and it's presented quite a shift in the feeling of the class. We still have our amazing instructor and TA slowly making their ways around the room checking in to make sure we don't need advice or to re-think design, logical and structural decisions we are making on our own. We still have plenty of questions for them all the time, but we're getting on for the most part without getting totally stuck anymore, which is very encouraging. I've got three apps underway and have been focusing on two of them this week so far; both involve using RestKit to make API calls and populate views with the parsed response. I've gotten a lot of mileage out of Grand Central Dispatch for multi-threading time-intensive processes (Ray Wenderlich has an awesome intro on that here). One thing I have found helpful to remember is that when you start a block, the program will go through it line by line, which means that if you start up another block inside of that block, such as when getting a different queue, you can be sure that the second, inner block won't get called until the lines before it are completed, which makes GCD an ideal choice for when you need things to happen in a particular order. One note, though: setting the priority of the queue (Low to High) doesn't necessarily guarantee the order in which things get done, so your structure has to take care of that.

Other than more adventures with blocks, my Evincel mobile project for instance has led me into a deeper understanding of how to use iOS to reflect the MVC perspective that was so important in rails. Building a mobile app that makes API calls to the rails app seemed simple enough, but as soon as your navigation flow gets a little more complex, it's absolutely necessary to separate data logic from UI logic and to have associated models for specific items. I had initially taken the hacky route of making API calls with my viewController and having it save an array of objects to load from, but obviously this was not logical long-term, so I spent most of this afternoon refactoring and restructuring the flow of data until it became rather charming to me.

For the next twelve days, the sixteen of us at App Academy will be working like crazy to produce some polished personal projects with what we have learned so far. What is going to catch employers' eyes? Lovely, well executed, thoughtful work. The pressure is way up now, and there's only one thing that can ever truly pacify such a vast amount of stress, and that's beauty. I'm making my weekend projects focused on custom views, and next week I'll be diving into something perhaps a little more complex, but for all of us wanting to make something pretty, here are some resources I've found helpful for coming up with interface ideas:

AppFlows article on side navigation trend 

Designspiration's iOS section

Balsamiq for Layout Mockups

Six Revisions Article on Beautiful Apps

This is it. In less than two weeks we'll be showing our projects as proof for the claim that we have obtained the skills to be junior iOS developers. Suddenly the pressure is on the individual to show what we have learned. Friday we had a short lecture in the morning and then spent the entire rest of the day working independently on our personal projects, which is pretty much what we'll be doing for the remainder of the class.

During the lecture Ned talked about using the AVFoundation framework to allow your app to record audio and then play it back. It was pretty basic and high-level; there are classes AVAudioRecorder and AVAudioPlayer which you need instances of in order to record and play, and you set it up to write files to your application's Document Directory, which is like its sandbox on the device where it's allowed to change files while it runs.

You know how sometimes you wake up from your sleep thinking "Eureka! I've got it!" and you think you know the answer to some problem you've been thinking about? Yeah well that happens to me too, but this morning, it was actually true. We'd been having some trouble getting our multi-dimensional array to populate correctly and to draw the correctly positioned blocks to the screen for our Bejeweled/Tetris game, but I woke up an hour and a half before my alarm went off knowing just what to do and fixed it before even getting out of bed, which was - although not the most prudent path as far as avoiding sleep depro - very satisfying. Today we went back to work on the Bejeweled application, which turned out to have a good deal of nuances and easily entangled details, and made a bit of progress. Ned gave a lecture on overriding inherent methods of NSObject such that you can control the way that data structures check to see if objects are equal to one another based on their contents and their address in memory. The two methods to override, of course, are isEqual? and hash, and this way you can ensure that two objects are being evaluated in terms of the custom properties that you have assigned to them. For clarity, here's a fine example of the analogous steps being taken in ruby. 

After class, instead of giving one of his usual algorithms talks like he does from time to time, Ned gave us a problem to solve by writing an algorithm: create a little maze and write an algorithm to solve it.  The idea is simple, starting with a 2x2 maze and building up from there, you want the first position to be at 0,0 and the last to be at 1,0, with a wall between them that cannot be crossed. Our approach was to create an array of walls, which were sets of illegal moves, and then try to build and output a path(another array) that would get you from the starting position to the ending position. 

It's been a bit of a challenge, as I've never really done this before, but of course we had another cool moment of coalescence where the lesson from an earlier project (overriding the equal and hash methods) could be useful here; think of the fact that in order to avoid an infinite loop, you can't visit the same spot twice in your first path, which should be able to check for equality based on the coordinates of the position. That means you want to be able to define what qualifies as an equal object!

Einstein said that joy in looking and comprehending is nature's most beautiful gift. So I'm inclined to be grateful to HashMap Labs for giving us this opportunity to see and comprehend more than we ever imagined, because it's been bringing me the most tremendous levels of joy as we become more and more comfortable with programming in Objective C and watch as our own capabilities unfold before us.

That may sound a bit poetic; granted, it's the emotional viewpoint, and when I tell you what the objective point is, it may take some explaining to bridge the gap. Today we returned for a bit to our bird Labyrinth game, which has been rechristened as "Bird Wars" by my talented namer programming partner Liam. The progress we made relied on one primary milestone: we established bluetooth connection between two devices using GKSession delegate methods, and got the game to the point where each device shows two birds, one controlled by you (the blue bird), and one controlled by your opponent (the red bird). We were pretty proud of ourselves. 

After the break, during which we visited San Francisco's renowned  mobile eatery Le Truc, we switched it up and started working with new pairs on a bejeweled-like  game wherein you create a grid of blocks and try to make them disappear when the user creates or finds adjacent sets of same-colored blocks. Here was our main problem, starting out: we had to create a matrix or multi-dimensional array containing rows and columns, such that we could populate it with blocks who had their own class that allowed them to draw themselves with different colors to the screen. Strangely enough, our approach led us into a long adventure of logic trying to account for the positions of the blocks onscreen in the matrix.

I'm not going to lie, at first when Ned assigned this project I was a little skeptical about what its value was to us, but now I'm realizing that this process we are going through now with drawing instances of a class to the screen in a logical way is going to be immensely useful in the implementation of real-life designs.

Think about it, when you're making a web-app, it's easy enough to just create an unordered list or a container whose sub-elements are floated or positioned with margins, and after setting these styles on the container, you just run a for loop that fills it up. In iOS, we don't really have that flexibility that CSS provides you, so we have to do this sort of structured population programmatically, and now I'm starting to imagine exactly how we would do this using matrices or arrays that contain objects with CGRect properties. A CGRect is a struct representing a rectangle that may be a frame for a layer(a viewable object) on the screen, that contains a location and a width and height. We could increment the location values using a for loop and then allow a user to view a long collection by implementing the custom infinite scroll view that we learned about on Friday.

I woke up one hour late, eyes taking a long cool minute to adjust. On the train, I met a French mathematician, who recognized XCode immediately when I started working in transit and we started talking about programming. We were collectively amazed with how many educational resources are available for free right now (eg Coursera, Udacity, Stanford lectures on iTunes U). It's refreshing. Here is why we decided that objective C is an elegant language:

when you write a method, you can include all of the arguments inline like so:

-(void)methodThatDoesThingsWithObject:(NSObject*)object andWithNumber:(NSNumber*)number andWithPoint:(CGPoint)point { ...

It's lovely, really. We sort of marveled at it for a moment, imagining it in the air.

In class, we got back to our Labyrinth game, and after refactoring our methods to accommodate the random generation of walls to form a maze that our bird could not fly through, we spent a while trying to figure out how to use the GameKit library to allow us to connect two devices on a peer2peer network via Bluetooth. It's turning out to be very tricky, but at its core, we're using a class called PeerPickerController's delegate methods to connect the two devices.

Then some engineers and a founder from Parse came by and gave us a lecture on cool features in their platform and ways to use them to support a fully functional, fairly easy to setup backend for an iOS app. We'd already been using Parse, actually, but it was cool to get a chance to talk to them about the philosophies behind the technology (make a good user experience for the developers, there's a novel idea in fact), and the experiences they had bringing their product idea together while going through the process at Y Combinator. They were fantastically pleasant and patient guys, answering all of our curious questions in regards to the business and its stack.