#hashmaplabs.com

This morning was different than other mornings. On an ordinary morning, we come in and Ned gives a lecture on the thing we probably read about the night before, performs a demo of how to use the new technology, and then outlines the direction for the app we are expected to build, but this was no ordinary morning. Instead, he just made a brief announcement in which he told us that he thought we were ready to do more of the research on our own, and we should practice figuring things out from the documentation since being good at doing so would give us a lot of power in the future. He said, make a Labyrinth style game where you use the device's motion detection to allow a person's movement of the phone to animate a ball into a hole. Put up walls to form a maze and figure out how to mathematically handle collision detection if it runs into those walls.

I mean, my pair partner and I looked at each other and then at the documentation and then at each other and just kind of gaped a little, not really having any idea how we were going to pull this off,  but we kind of had no choice but to just start. We'd hardly even heard of CoreMotion (the library we had to use) let alone used it or read about it. Luckily, as Ned pointed out when he was walking around, CMMotionManager was a lot like the LocationManager we had already gotten comfortable using, so within an hour or two we had a ball rolling in response to your tilt of the screen and staying within the frame of the device. 

After some technical difficulties, we got a little fancy and swapped the ball out for a weird black bird so he could land upon a stick instead of running into a wall. Essentially, we used the MotionManager to get data every 1/60 if a second to tell us how the phone was oriented in space, then took the data it returned to us about the roll, pitch and yaw of the device, and used it to change the animation's direction of motion. The hardest part for a lot of us was getting down our collision detection strategy, how to find out when the bird touched the wall, and what should it do once it touches it. It took us for a walk down geometry-memory lane, and we left at the end of the day with progress to be proud of. 

The primary reason why I have not written before now this weekend is that I was too busy working on a personal rails project, Evincel, which is almost at a presentable working state and contains these icons of which I am at least marginally proud. 

What's happening at App Academy now though is the much-anticipated turning point. Starting today, after a week of ruby and a week of intensive rails, we're going to dive into Objective C, and that's what we're going to use for the majority of the rest of the class, using this book. Of course, as in any other area of life, you can't make such a vast transition without a blowout.

So today before we get too ahead of ourselves, we're having our first "assessment." Now it's like we're back in school for real! It will be on APIs consumption and rails structures. Here are some notes with a good little overview of some API basics.  Shall we talk about last week?

Friday we had our second guest speaker (the first was Douglas Calhoun, a former Dev Bootcamp student), Dave Hoover, who told us all about how even after App Academy, we're all going to have a ton to learn and just don't forget that, you can only just scratch the surface here and have to be prepared to keep learning. You have to get yourself into a situation that's ideal to keep learning in, and you have to keep pushing yourself.

This was casual Friday:

But not in terms of code. We worked a little more before class on our BART-trip application, and made a lot of progress, but it still needs a lot of love before it'll do what we want it to do.

 When we all got going as a class, we worked through the first chapters of this rails tutorial to set up little applications that would be ready to deploy on Heroku. I'd done a little rails work before, but always used a MySQL database instead of the one that Heroku supports, so it was several headaches worth of error messages before we got to the point where everything was set up.

To save someone else the pain of the weird error messages: ultimately all we had to do was download PostGres from here, then symlink it to our application and configure bundler to recognize it (A little more on that here).

Now we're going to be practicing writing tests with rSpec, they're little lines that say what the code should do, before actually writing the code that does it. I've never been too big on TDD in the past but I know it'll be a valuable skill to have.

What a day! That magnetic draw that I mentioned yesterday? It has become more like a black-hole-level attraction that I feel I essentially only leave to take sleeping breaks from. So today we talked about APIs, what they do, and how to hunt, tame and seduce them. It all started off with a little romp through Jumpstart's Twitter guide, which looked innocent enough and guided us through the steps to creating our own little bitty twitter clients who could tweet and send messages from our command line. We learned that when you access an API, it makes requests to a server and elicits a response. Clear enough, so we're suddenly handed another instance of infinite possibility. What we really spent most of the day on, though, was working though something (appropriately?) called the Bastard's Book of Ruby, trying to scrape tweets from the USGov's twitter account. Interesting choice for some hands-on experience, fellows. The highlight of the workday for me is probably a toss-up between the break-time round of Cards Against Humanity, with background music by George Michael and the Sexy Sax Man, or the time my pair partner and I accidentally did this with our screen-sharing: