#hashmaplabs

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.

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.

Kush asked each of us to put together a short bio to include in an interview packet that he'll be supplying to prospective employers. I’ve never written a professional bio before. I wasn’t sure what to include. The whole process is a bit intimidating actually - not just the bio, but everything involved in navigating the waters of going from student to employed developer.  I know I have a lot to offer but I’m not sure I know how best to demonstrate that.  Hopefully what ended up in the bio will be suitably impressive.  And hopefully I'll nail demo/interview day -- my demo apps will be impressive, and I'll answer even the technical questions with eloquence.

After working on the bio, I got back to more comfortable territory: iOS development. With Kringle, my Secret Santa app, in presentable condition, I started in again on my location based personality app, where you can quickly and easily find the coffe shop where you'd best fit in. I restructured the idea a bit. I refocused it in a way that will allow me to spend more time integrating features that will showcase a number of different frameworks, design principles and concepts while limiting the amount of time I'll have to spend optimizing features that will at best minimally illustrate my newly acquired development skills.  

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.

I spent all of today working on my secret Santa app, tentatively titled Kringle. Does anyone have a better name?  I'm all ears.  In any case, it's coming along nicely.  I'm ambitiously hoping to have it finished by tomorrow night, but realistically it'll be done in 2-3 days.  There will be lots of little things that take longer than expected, and lots of little niceties that I'll want to add.

Today I integrated the app with Facebook, created the necessary data models, got the user info form that I created yesterday to populate the user data table, created a singleton to store the PFUser object (using Parse.com for a backend), wrote the logic for displaying the correct views based on whether it's time to draw names or not, and got the scrollview to play nicely with the keyboard.  The last part took me longer than I would have liked, but it now works exactly as I want it to.  All in all, I'm pretty happy with my progress.  

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!