Posts from 16 November 2014
-
Today's partner: Connie
It's a bit of a challenge to reconstruct my memory of Friday after I failed to save my draft Friday evening, so excuse this entry for being perhaps a bit vague. Also, I'm going to speak in the tense I would have had I completed this entry Friday.
Today was the first day where there wasn't enough work to actually fill out the day. We had two main projects: a small class that built trees of moves for a Knight navigating a chessboard in order to find the shortest possible route between two points via knight's moves, and a Tic-Tac-Toe solving AI (on top of a couple small vignettes). Of course, the point of the AI wasn't to show any great details about AIs; rather, we were working more on Object Oriented programming, data structures, and algorithms.
These algorithms can broadly be called "paint bucket", or "flood fill" algorithms: starting at a point, do some action to all the "neighbors" (keep in mind that a knight's neighbors on a chessboard are moves of 1,2 away, and not adjacent squares - one of those mathematical things where you have to keep in mind the context you're dealing with), and then repeat for the neighbor's neighbors, ad nauseam until there are no more valid spaces to apply the action.
Doing this sort of naive AI over and over has certainly helped drive home how to best write recursive OO code to do breadth-first search in different contexts, with different types of objects, but again we're not making contest-winning AIs here.
Our biggest problem today was a weird edge case bug in the TTT AI. The spec was a bit hard to read, and once we nuked the half-dozen syntax errors in our collected source files, we found the logic as stated in English in the instructions to be a bit vague on what the various parameters means and how to pass them around. It took the better part of an hour or more to vary the code and make the lynchpin methods work properly, but once we got those right, the tests all passed without a hitch, and it was glorious.
Of course, at that point, we only had an hour left to work. Without a bonus problem to chew on, there wasn't much to be done except to dip our toes into this weekend's reading and talk about the course as a whole. I showed my partner a couple resources I had seen on using git, which I hope she found valuable, and then just chatted about stuff. I know I'll pay for it this weekend in terms of worktime lost, but sometimes you just need a break, you know?
-
I'm using this tumblr to keep a couple people up-to-date on my doings and not only for assignments, so I thought I'd offer an overview of what the program's about.
It is, of course, twelve weeks long. The first nine weeks are mainly curriculum, followed by three weeks of project development—looking at what the previous cycle is doing, this consists of cloning the functionality of another public website as an proof of skills. I don't think most people choose to make a novel project (it's easier to solve a solved problem), but I don't know whether it's banned per se.
As for the "curriculum", it consists of a couple languages in a sequence that ramps up in relevance to web design. So, to start, we're using Ruby to script basic stuff—algorithms, data structures, the fundamentals of programmatic thinking, that sort of thing—and then add in other elements, like JavaScript, SQL databases, CSS for visual design, and so forth. I haven't looked at the elements of the curriculum for a bit because I'm trying to stay focused on the here and now for the time being, but it's basically web development from end to end, from core scripting to design.
Of course, one part of the program is blogging your reflections on a public tumblr. My alumnus friend tells me that the only people who will be interested in most of this will be fellow students, but I try to cover enough other topics that maybe others will want to read about my time in aA.
Central to the instruction methodology is a working strategy called Pair Programming. How this works is a single computer is hooked to two monitors, and one person controls the keyboard and mouse, while the other talks about their thought process and, almost but not quite, tells the other person word-by-word how to get through the problem.
In practice what ends up happening is one of a couple things. First and most ideal, the pair is matched well, at which point you can easily forget who's actually in charge at any given moment—it feels like the executive portion of your brain is the other person, and you become the mechanical/error checking portion, or vice-versa.
Second, there's a close disparity, or a symmetrical disparity—A knows something B doesn't, and maybe B knows things A doesn't. My pet peeve is people doing motion commands multiple times, so I am constantly teaching my partners motion commands (delete line is ctrl-shift-K, select line is cmd-L, etc.). I don't restrict myself to this sort of thing—I've been spotting a lot of errors and edge cases while driving, which I don't do as much when navigating because I'm thinking of the overall strategy. It's sort of like the source of the analogy—the navigator in a car doesn't tell the driver how to pass or avoid an accident, but s/he does make damned sure the driver doesn't pass their exit.
My perennial weakness is syntax specifics; I don't bother spending a lot of brainpower memorizing the syntax of every command when the reference material is right there. What I have spent time on, by contrast, is understanding what the elements of the function signatures in the documentation are, so I can quickly parse and interpret what sorts of things a function is capable of, and what sorts of things it returns. I'd like to think I'm helping others learn how to do these things with greater facility.
Third and most rarely, one person is completely clueless and is basically told by the driver what to tell them ("okay, so how are we going to solve this problem? What search algorithm should we use?"), and then when they're the driver, they're simply a glorified typist. I think this is why Pair Programming often gets a bad rap—in organizations with programmers of vastly different skill levels, you won't always have two people who can pair well.
One of the advantages that you'll see regardless is that, as long as one person isn't a complete pushover, the pair will produce cleaner, more readable code, and each person will come away knowing more than when they started, either about programming and problem solving, or about communication and education.
The office, on Cooper Square, is relatively compact and a bit on the old side. It's not all glitz and glamour; it's functional, in a building that could really benefit from a bit of TLC from a motivated DIYer. The local shopping options, especially for food, are amazing—it's going to be hard not burning through my savings by going out to eat every day, especially because some of the best conversations happen at lunch when everyone has a chance to relax—and it's nice and central to a lot of people and train lines.
We only use the school's computers, not our own. I guess previous cycles had mechanisms for students to bring their own computers, but there are logistical problems with that, especially when it comes to supporting non-default install environments and version conflicts. Further, we all use the same editor to work—Atom, by the same people who make the git version control system (ed: this isn't true; it's made by the github people)—which is a good editor, but not great, out of the box. One advantage to learning Atom is that, in time, you can add plugins to do almost anything any other editor does, but it can be quite frustrating not having some of the more clever IDE shortcuts available by default (TextMate's "Command-enter autocompletes a function signature" is one I miss almost daily.)
One thing I'm noticing is that if you learn Unix shortcuts, specifically readline mode's motion and deletion commands, and the shortcuts for a single editor, most of the other editors out there will support the same shortcuts. So really, the learning curve to switching to Sublime or TextMate after using Atom should be quite low. Atom does file browsing better than TextMate, so even though I bought the latter, I am considering just sticking with Atom. (If you don't understand, navigating the file hierarchy of a big project can be quite a pain in the ass with bad tools.)
Their current stats are 98% of grads are hired within a certain timeframe for a median salary of $84,000 (in NYC). This is promising, because I run out of money mid-March :)