Poetry in Processors

W9D5 was our first "graduation" day––the first of many over the following three weeks. It was the last day of App Academy currciculum that was not directed at the job search, and the last day we were required to maintain this blog. (How many days did I carry on my blogging habit after it was no longer required? Exactly zero.)

In the three weeks since, I've finalized my projects and portfolio (www.adithyamanohar.com), sent out a few dozen applications, started working on a new React project (which is on Github here), and worked through many, many coding challenges and algorithms in preparation for the interview process.

W12D4 was our final graduation event: the first App Academy Idol, where the cohort nominated final projects in categories like "Best-Looking App" and "Most Original Idea."

The MultiVerse was nominated for the latter, but lost out to Pixelate, which is a really fun pixel art application; go draw something now, or upvote the art I made!

Today was a much better day than yesterday. The plan on Github is no longer completely relevant––a lot has changed, and I won't have time to update the Readme until this weekend––but the result is a slightly simpler project with the goal of a self-contained, stable version by Monday. Ideally, I'll have a bit of time to add additional features during the algorithms/job-search curriculum over the next three weeks.

I spent most of today cleaning up the front-end of my app. Using my new skills of React + Flux wizardry, I set up completed Poem components as clickable lists in short order:

var ArchivePoem = React.createClass({ getInitialState: function() { return { poem: PoemStore.one(), favoriting: true, activeId: -1 }; }, ... _setActive: function(id) { if (this.state.activeId === id) { this.setState({ activeId: -1 }); } else { this.setState({ activeId: id }); } }, _buildPoem: function() { return ( this.state.poem.stanzas.map(function(stanza){ var isActive = false; if (this.state.activeId === stanza.id) { isActive = true; } return ( <Stanza active={isActive} setActive={this._setActive} key={stanza.id} {...stanza}/> ); }.bind(this)) ); }, ... });

This works by passing a _setActive callback from the ArchivePoem React component to the Stanza component. setActive is then called from a Stanza when it is clicked and made "active." Active stanzas display information about their authors and timestamps.

This way, the active state is managed by the poem, so one stanza is automatically deactivated when another is activated, without the stanzas themselves having any information about each other.

Probably the most difficult day I've had at a/A.

We were supposed to take a detour from our project timelines after the morning session to pair up and test others' applications. Unfortunately, my morning session was swallowed up entirely by a ridiculous find_by_sql Active Record query that I could have sworn was working as it should have been yesterday evening.

My app is now on Heroku, but, because of the above, it's still a little bare. After getting some testing feeback, I decided to change a couple of features to simplify them. One of the consequences of that change: I no longer need that AR query. Yes, the one that I spent half of today working on. Such is life.

Infinite scrolling was supposed to be part of one day's work.

In the afternoon today, after about a day-and-a-half of work, I finally had it working. Given that my application isn't going to have too many long lists, the payoff will probably not be worth the effort. Still, after all this time of thoroughly working through it, I can get an infinite scroll going very quickly on any React/Rails application I ever make. That has to count for something.

I even made time later in the day to finish off a basic implementation of my poem-favoriting feature, which means commenting is the only thing left on Phase 4 of the MultiVerse. I'm roughly half a day behind on this phase, but that still leaves me a bit of time from my gains on Phase 1.

They call it infinite scrolling because it takes forever to implement it.

Actually, there were a few unforeseen design choices to be made today that slowed me down considerably. The first came from the realization that my wireframe for the home page does not distinguish between incomplete poems in which the current user has participated and ones in which the user has not. Initially, I didn't see this as a necessary distinction, but it seems like it would be a convenient feature.

Unfortunately, separating these two sets of poems into their own infinite scrolling containers on the same page led to all kinds of problems; the most significant of these was the added complication to the poem store. Late in the afternoon, I reverted to a single container and just made the distinction in my CSS classes. Talk about working in circles. To infinity and beyond.

I'm now behind on Phase 3, but I've still got that day I saved in Phase 1. If all goes well, Phase 3 will be done sometime tomorrow, as will most of Phase 4, which is a simple comment + favorite implementation.

Despite taking the morning off due to a persistent (but minor) illness, I finished Phase 2 of my final project on schedule on Friday, which means I'm still a day ahead overall. And for the first time in what feels like forever, I decided this gave me license to take most of the weekend off.

Friday went very smoothly once I got to a/A in the afternoon. I started by creating the last of my React components for Phase 2––a form allowing users to make new poems––which means all of the basic functionality is now complete: users can create poems, contribute to them, and read them in an archive once complete. (I decided to do away with poem deletion entirely.)

Once that was done, a number of smaller tasks remained: I finalized routing and redirection upon poem creation and cleared the stanza-form upon stanza creation. I also dealt with stanzas as collections of lines; now, the home page only shows the most recent line of the poem, rather than the most recent stanza. Lastly, I added a custom model-level validation to ensure stanzas are at least two lines, but not more than three. And, again, switching repeatedly between Ruby and Javascript left me feeling like some sort of powerful wizard. Every time. I am creating a MultiVerse here, after all.

Lesson of the day: start with the router, not with the components. Turns out that the folks who made React included a router for a reason. Who knew?

The router was always part of the plan for Phase 2, but I thought I'd set up all my React components before giving them the appropriate routes. So I gave myself a lot of extra work by doing that yesterday, and then undid half of that work while setting up the various routes today.

That was at least half a day more than I should have needed, but I now know the ins and outs of routers. Clearly it was good for us to plan our timelines with plenty of padding: I'm still ahead of schedule.

The other half of the day was spent trying to get React form components to behave, and passing params from them down to the Rails controllers. All in all, a challenging day, and things are starting to slow down a bit, but that was to be expected: I'm already dealing with a larger volume of code in this project than I ever have before.

My second day working on the MultiVerse wasn't quite as productive as the first, but I can hardly complain. I'm still ahead of schedule on Phase 2, and I've learned a lot more about Flux architecture now that I've had to plan and build it myself. (Should that be a prop or a state? Do I really need this ApiAction, that specific event handler? Where do these query params go???)

The Flux cycle for my application––from PoemStore, through the Poem React component, the action creater, and the dispatcher––is now complete. I also set up a poem index page with click-to-expand functionality from scratch before realizing it'd be far easier to do with the React Router.

Here's the thing about the React Router, though: I'm not yet very comfortable with it, and thus far it's involved a lot of googling "how to do so-and-so with React router." By day's end, however, I had a basic plan of action to complete the router work. If all goes well, Phase 2 will also be done a day early, and I'll be able to create, contribute to, and destroy poems in the browser by tomorrow!

Meanwhile, JSX continues to be an absolute pleasure to write. (I don't understand the naysayers!) Here's a bit of code that lets me create an index of poems as a list:

var Index = React.createClass({ ... _buildPoemIndex: function() { var that = this; var poemList = this.state.poems.map(function(poem){ return ( <li onClick={that.selectPoem} key={poem.id} {...poem}> {poem.title} {poem.author} {poem.first_stanza} </li> ); }); return poemList; }, render: function() { var poems = this._buildPoemIndex(); return( <ul className='poem-index'>{poems}</ul> ); } });

Aaand we're off! My first day of capstone project work went very well, despite my being under the weather and staying far away from coworkers.

Phase 1 of the MultiVerse is now complete, a full day ahead of schedule!

We were told, when making our estimates for the timeline, to take the amount of time we thought we'd need for each phase, double it, and then add a day. So user authentication + basic models, which I completed in well under two hours for Assessment Four, was given two full days. It's deinitely good to feel like you're ahead of schedule; if I had given it just one day, I'd have felt like I was just getting by, and I certainly wouldn't have spent time on looking at alternate design choices.

So I spent the day going up and down my schema and finalizing the back-end of my application. Thus far, it's a bare login/logout page (no React until Phase 2), but the basic model and API controller setup on Rails is complete. My Poem and Stanza models were unlike models that I'd used before, so it took a bit of exploration to finalize them.

In the end, to ensure that a Poem object cannot be persisted to the database without a Stanza object to serve as it's opening stanza, I used the after_create ActiveRecord callback, and set up an attribute assignment method Poem.first_stanza= that looked very similar to User.password= in user authentication:

class Poem < ActiveRecord::Base attr_reader :first_stanza ... validates :first_stanza, length: { allow_nil: true, minimum: 1 } after_create :ensure_first_stanza ... def first_stanza=(first_stanza) @first_stanza_content = first_stanza end def ensure_first_stanza first_stanza = Stanza.new( body: @first_stanza_content, order: 1, author_id: author_id, poem_id: id ) first_stanza.save! end end

The Poem controller handles "first_stanza" as an input param to the new Poem object, which allows the user to save a Poem instance and its first Stanza instance to the database without actually creating a Stanza separately.

There's never a good time to fall ill at a/A (or anywhere), but my timing was as good as it can get. Today was a solo project day, and the day before final projects start, so I didn't miss too much. Relatively.

I'll be back on the train tomorrow. Some edits were suggested for my project proposal, so that will be the first order of business.

On the last day of Week 7 (already!), we started to work on a full-fledged Rails + React.js web application for the first time. We're cloning AirBnB over two days as a practice run for our final projects.

Speaking of, my original poetry-related project idea was approved. I didn't expect to be playing with poetry + code quite so soon!

Finally, a project that involved both a React front-end and a Rails back-end. For the first time, our interactions with the application views persisted changes to the database.

React routes are really cool! They allow a lot of navigation to occur on the client side. The Ruby controllers now just respond with JSON rather than HTML, so our applications work off a single page, with any necessary changes managed by React.

I spent way too much time on my project proposal last night, so I was behind on the readings, but the lecture brought me up to speed, and my partner and I flew through most of the day's work. Which was, incidentally, to build a Pokedex. (Also, take note, Rails: the plural of Pokemon is not actually Pokemons.)

The Flux pattern makes debugging and understanding code incredibly straightforward. Several times today, we tracked errors around the one-way data flow and caught them far quicker than we would have otherwise. We also had no trouble adding new features to our app, because the Action => Dispatcher => Store => View architecture kept things nice and tidy.

We made a piano today. It might have been only one octave long, and the built-in computer notes might have sounded slightly more pleasant than a fire-alarm, but it was a working piano right there in the browser. Complete with a vaguely punny name that my partner and I felt was a vast improvement on the one the instructions gave us.

The main takeaway from the day's work, however, was the architecture we used: Flux. For a project as small in scale as a single, static, browser-piano, our setup was overkill, but the pattern of Action => Dispatcher => Store => View was the important thing. The store and dispatching mechanism that was enforced in yesterday's project definitely made today's work a little easier to follow. That said, lots of practice with Flux is still necessary.

React was a lot friendlier today. Familiarity is the cure to all magic, it seems. This was also the first time we used React on a Rails application, and seeing it work as a View made a lot more sense. And JSX continues to be lots of fun to write.

(Also, it's odd how quickly the subtleties of syntax fade from memory after just a few days of complete disuse. No, Ruby if statements don't need curly brackets. Returns are implicit. And methods are snake_case here, unlike Javascript's camelCase. I know all that! It takes a minute to warm up.)

We built a classic to-do list application by building our own system of store + dispatch. This part was entirely new to us, and we were instructed to do it this way because it's how Flux (an architecture that pairs with React, which we'll learn tomorrow) does it. More on that tomorrow.

React is pretty cool so far. It's under-the-hood workings are still a mystery to me, and we've been told that we won't explore it with the depth with which we studied Rails (this is a Rails bootcamp, after all). Still, I expect, with good reason, that it'll become more familiar and less magical over the next few days.

We got some way through a browser-version of minesweeper by day's end. Most of the day involved building smaller widgets (clock + weather, reactive search with auto-fill, etc) to get used to React. JSX is an especially interesting part; it essentially lets us use code formatted like HTML inside Javascript functions.

Friday was AJAX day. My day. If I had a curly bracket for every time someone reminded of that, I'd have enough for a lifetime of Javascript code.

We spent the day working on Asynchronous Javascript and XML (AJAX), so every "AJAX lets you accomplish so-and-so" was met with a "Thanks, Ajax!" or something similar. AJAX errors became complaints in my direction. At the end of the day, to general amusement, we were instructed to get very comfortable with AJAX over the next few days.

It never got old. Besides, AJAX is really cool, and lets you build things like reactive search bars and perform background operations without re-rendering your page. It was somewhat ironic, though, that I struggled with some of the day's material; mostly the jQuery bits. Still, I learned with a kind of depth that was lacking during previous days this week. It felt good to be challenged.

Earlier in the day, however, I brushed the fifth assessment aside. It's fair to say, based on how the corhort did on the test, that we're now as comfortable with JS as we are with Ruby, which is surprising, since we've spent only a week and a bit on the latter. We're just getting very good at learning new languages.

A good half of the cohort proceeded to celebrate the passing of the penultimate assessment by barhopping across the city on Friday evening. We're halfway through the program, so it's nice to feel a sense of community, but it's also to incredible to think that we've only known each other six weeks. Six long, busy, intense weeks that have absolutely flown by.

We're learning React during Week 7, which will be the last week before we begin final projects. ("All the jQuery you learned this week is great, but don't worry too much about it; React is going to change things.") React is the newly-popular Javascript front-end framework created at Facebook, and we've been promised it'll be transformative and exciting.

We saw the various elements of the front end all really working together for the first time today. The big new concept was event delegation, which is a bit of jQuery magic that lets us handle various events related to the page, like clicks, hovering, element transitions, etc. (And it's taken just one day for the magic to give way to a fairly good understanding of the inner workings.)

Yesterday was browser games. Today was browser elements. We built a tab switching system, an image carousel, and a thumbnail navigator. All were filled with cats and corgis, naturally.