Posts filed under 'AppAcademy'
-
Well, it's the day, and we have an hour until people should start showing up for project day… and I'm just sitting here, blogging.
I spent the day thinking about what I want to say about my project, and how I'm going to present, and refining my resume. I finally have enough final project under my belt that it's not purely embarrassing, but I know that there's so much more work that I can do before I can consider my project "functional".
On the plus side, my resume is much nicer now, and I am much more comfortable with SASS and
@mediaqueries, and it looks nice both on screen and in print. But there is never enough time to do what I want.Case in point: we have to set up for demo day now. Whelp.
-
When you're styling… the whole world, styles with you…
Today was devoted to making my app not look nearly as terrible with a whole lot of bootstrap + sass. I guess I can put those on my resume; they're easy enough to use, and (especially)
.scssis nice because it's compatible with.css.This is kind of a last-ditch: there are so many things I need to do, want to do, with my app, and time's up—tomorrow is presentation day. I'm kind of cobbling together a spiel about what I've actually spent the last month doing, which is to say, learning a framework from end to end (two, if you consider Marionette and Backbone to be separate entities), understanding something of asynchronous calls, and getting everything to play nice.
It's hard to believe it's been a month; there's truly never enough time to learn what you want, and everything takes many more man-hours than you think. Am I faster than others? Slower? I can see what sorts of work others have been able to produce in three months (since we started at a/A… crap, time flies) and I don't think I'm that far removed from my peers. I can certainly field a good set of questions about what I've done, but I can't say that I'm markedly better or worse than anyone.
What other metric can I use? I know I keep coming back to my successes relative to those around me; I might be able to find more hours in the week to work, but at the end of all of this, I can't say that anyone is far superlative to anyone else. I know what I'm learning, and every day there was someone who was able to accomplish more than I was, but in a class of (now) 23, that's bound to happen. If anything, the biggest problem I have, consistently, is having expectations that are much too high…
Does that mean that I will learn more, faster, than others? Or does that mean that I will know more esoteric knowledge, but never have as much to show for it? I've never worked with a meaningful production system, but I suspect that there will be far fewer surprises there for me than for some people… but should I have been spending more time learning things with the most marginal utility, instead of learning the details of a few things?
More questions than answers, and I suspect I'll never truly know. What I do know is that it hasn't stopped being interesting, and that I don't have any plans to slow down in the near future.
So, back to the topic at hand: I
bootstrapped the heck out of my app, and thereby got rid of a couple major styling issues, but there are a lot of things that still need to be done. I'll really need to do triage tomorrow, especially considering that I need to do things like prepare paper copies of my resume (which looks… acceptable, at least) and, perhaps, get a domain for my heroku app.(20 minutes later… done)
Well, I'm a little closer to being ready to hire. *gulp*
-
One of my hangups about continuing work resolved itself over the past couple days. I ended up having a couple of redundant checkins—"Fixes data model", "Data model finally fixed"—but I think I'm there now.
Collections have models, and certain models, like
Posts, have collections of their own (in this case, comments). When you pull the data from the server for a non-root page, the data needs somewhere to "hang" so as not to face sync problems. So, when I fetch a post, I shouldn't fetch the class it belongs to, I should instead examine the post's section_id property, and then put that in an existing class's post collection. … Got it?User -> Sections Collection -> Section Model -> Posts Collection -> Post Model
So, on fetch of the last item in that chain, I need to go to the head of the chain and request that this data goes in the proper place in that chain.
It took me a while, but I think I ironed out all the kinks. It took moving some logic from the models into the collections: if you ask a
Postwhat section (class) it belongs to, it asks its collection, which in turn had that property set upon initialization. (I also needed to start initializing new collections with(null, options)instead of({}, options)because it turns out{}is a model on its own, just one with no attributes… derp.)What does this mean? A whole bunch of crazy sync problems disappeared all at once, and I can finally see the light at the end of the tunnel. I have never truly had a Minimum Viable Project (MVP), and I'm getting to the point where that feels possible, and likely to happen soon.
-
One of our cohort has a job offer! Neat.
I spent the past two (and a half) days getting up late and working later. I got nervous that I have absolutely nothing to show with regards to portfolio work and decided to do some mini-side projects that I thought would be good examples for my portfolio.
The first of these was cleaning up Rails Lite, which I'm pretty happy with. When we were doing it in class, I was frustrated because of how fragmented the lessons were, but once I consolidated my code a little bit everything made perfect sense. When controller instances inherit from the
ControllerBaseclass, they gain all the powers that it has, including auto-routing and rendering of default templates… it's actually quite clear, and quite neat how it all works. The inheritance tree is also much clearer, now, so I can see that parsing of input parameters and session management happens in quite the sensible manner. It's truly improved my understanding of how Rails works.One neat side-effect: When I told Tommy that I wanted to include Rails Lite in my portfolio because it made more sense to me, he and I talked for a bit about how rails is organized and it piqued my interest about the project codebase. So I started reading through the source on github, and ended up identifying a bug in the source that will prevent the current cohort from being able to complete the assignment on that class day. (Long story short: the way the project is designed, it will work with version 4.1.x but not version 4.2.) It was interesting to be able to dive into the code like that and know what I was looking for, and I feel more capable for it.
Late Thursday, I started in on a project that I knew I wanted to do: modifying my Snake (game) code to instead implement Tetris. Besides being (I believe) the better game, it was something that I think could set me apart a bit on my portfolio, and it was fun to see JavaScript in a different light now that I'm more versed in the language. I've finished it up now, for the most part, after quite a bit of late-night logic-checking (pieces no longer get stuck in the sidewalls! Yay!) and I'm quite happy to say that I can be proud of my code in a way that I wasn't for Snake. It is my project and it works well and looks like what I envisioned when starting out, more or less.
Curiously, I got the code 90% right straight out of the box when doing the initial implementation. I started it up without the rendering code, and after making a small fix (ensuring that the IIFE was starting correctly), I could step through the game logic and see little boolean pieces falling like they should. It was pretty empowering to have that be the case; writing (mostly) bug-free code with few syntactic errors is a powerful feeling.
I added both projects to my resume, which has been cleaned up a bit, and I'm feeling (almost) ready to go full-in on the job hunt. I know I'm late to the game, but that's quite alright. This break has done me well, and if I can do that with as much determination as I've been able to muster the past two-three days, I should be fine.
-
Now that we don't have to blog, I can blog whenever I want—which also means blogging in the middle of the day when I've found some solution to a particularly knotty annoyance and am taking a break from whatever.
I'll try to keep this quick, and I still don't have it how I want it.
Sign-in is handled through a modal (using a library that is just okay…). When the app first starts, it tries fetching the
currentUsermodel (asynchronously, of course). Meanwhile, it tries to route to whichever route was input, and if the user isn't signed in (which he won't be, because we're still waiting on a server response), it redirects to the sign-in window, which has an initializer that tells it to destroy itself when it receives a'signIn'event over the Backbone.RadioeventsChannel.Meanwhile, the modal animates, and only adds its keybindings once the animation is finished. But the
'signIn'event is received in the middle of the animation, which means that the view isdestroy()ed before it has attached its keybindings… which it does after the fact.Long story short, when a signed-in user refreshes the page, the sign-in modal installs listeners that get uninstalled before they're installed, and the next time the user hits "enter" the modal executes a "submit" event on empty text fields.
I got around it by having an
onShowcallback that checks to see if we're signed in, and ONCE THAT CHECK HAPPENS, install the'signIn'event listener. If that check fails (we've signed in during the 100ms that the animation has as default) then we uninstall ourselves.Gah. JavaScript, why you hurt so much?
-
Friday, I thought I had sign-in working the way I wanted. Saturday, I spent the day wrestling with the order that actions hit in Javascript.
I am hesitant to say that I think I've got it, but it makes a lot more sense—no matter what path someone takes to a URL, make sure to bottleneck actions that need to take place in a certain order in order to make sure that everything related to cleanup happens when it should.
Originally, the sign-in model we were given had login set with
async: false, which is deprecated and rightfully so. A good portion of my day was spent looking at a repeated message from JQuery stating as much, and once I figured out what needed to happen—the user, on sign-in, throws asignInevent that other objects subscribe and respond to—I was most of my way to getting the interaction happening the way I want.This is a lot of wasted time, but I have to say that I really understand async events much better now, as well as pub-sub. Whenever I think I know what I'm doing, though, I learn more, so I'm reluctant to say that I know everything I need.
One other thing happened in that was particularly frustrating. I removed my homebrewed utils directory from the manifest, only to change my mind and keep it in to be able to take advantage of a couple that I thought were useful. Well, for two hours I was getting weird behavior that, it turns out, was caused by my own implementation of router callbacks. Whoops, shit. I'll have to keep an eye on that sort of thing in the future.
I've noticed that it's nice using a common naming scheme when creating files, but it often makes it challenging to figure out which
show.jsyou need to be editing, or is throwing the error you're looking at. It pays to take the three seconds to verify what you think is happening is what's actually going on.I had a similar problem with Wordpress—I was making changes that didn't seem to be showing up in the final render, and I went down a lot of paths before I figured out that there are actually three different blog post views: all posts, posts by category, and single post. That's not DRY at all :(
-
Holy crap. I wasn't sure if I could do it, but I've got my app rendering a blank screen.
Some elaboration is required.
I set out today to get the basic infrastructure of Marionette working, with a modal login screen, and a router
beforeaction that properly redirects after sign-in.At 9:30 tonight, I checked in the last code that was necessary to get this to happen.
I am so happy. I thought, when we were first learning Backbone, that it was pretty opinionated, but it turns out that it's flexible, and requires more configuration than convention. Sure, there are things that
backbone-on-railstries to enforce, but that's not Backbone per se.Marionette, on the other hand, has some strong opinions, but the documentation is sparse enough that it can be hard to discern what those opinions are. Nevertheless, it desires certain things, and after a lot of secondary reading, I have figured out a lot of what those things are. For instance, Marionette wants you to modularize everything, but the
Marionette.Moduleobject is pretty ghetto and is slated for deprecation.In the meantime, then, one can use standard JavaScript modules and so forth to add in modular portions of an app, or (as I have) simply expand on the
backbone-on-railsopinions by adding a folder for (e.g.) controllers and inserting it at the correct point in app startup. It works for now, but I may have to refactor later.And what a statement that is! Every single line I wrote in Backbone felt like it needed serious refactoring, but everything in Marionette is so DRY. Sure, there's a bit more "needless" code to pass messages, but that is in keeping with the spirit of loose coupling.
Case in point: I spent a good deal of time learning about JQuery Deferreds, which are a means of handling promises in JQ. They're similar in behavior to Arel queries—they don't do anything until you
resolve()them, and until then you can keep modifying them by tacking on further attributes. Pretty cool, if you ask me, although a bit of a trip to wrap your mind around. When reading Essential JavaScript and coming across the section on promises, I didn't quite understand them, only really understanding that they help cut down on callback hell… but I saw the reason for them. Now I think I can consider them a part of my toolbox.What did I do today, then?
- Marionette is starting up
- I have created regions
- I can attach subviews to the correct region
- Calls to routes that require login are properly intercepted
- Once login succeeds, the original route is triggered
- Login is actually working :)
What did I learn?
- Reading the docs, while essential, can only get you so far
- At some point (earlier than you [ed: meaning 'I'] think) you need to sit down and just break things
- Initially, at least, you're not going to have a damned clue what you're doing, so you have to just get the gist and then try things.
- Act more than plan. (This is personal, and in reference to my current state.)
-
I did make headway finding employers today, which is good. There are quite a few that I can tell are doing things I would enjoy, now that I know how important user interactions and a strong API are to me. All the glue in the middle is not so interesting, which suggests, me being me, that this will be my first role out in the real world. Lol.
Most of the work just involves reading corporate copy and trying to suss out what it is that a company actually does. I will say that if I can't understand a company after two or three reads, they don't go on the list at all.
As for the rest of the day, I spent a lot of time stressing out about getting my project portfolio together. I still don't love my final project, but I started doing some major refactoring late yesterday afternoon and well into the night, and even though I haven't tested what I'm writing as much as I'd like I know that I prefer Marionette.
My project won't be done in the way I'd like, but as long as I can show it off, it should be okay.
This is stressful.
-
Yesterday, Tommy asked to sit down with each of us at some point this week, to see where we are and what we're working on. I grabbed the first slot, and basically asked him "so, what are we supposed to be doing this week?" The list of tasks is pretty daunting at the moment, but today I feel like I'm getting a better handle on everything that needs happen in the forthcoming weeks.
In short: I need to figure out how to best identify jobs to apply to, I need to compile those into a "roadmap" of places to apply, I need to (at some point, starting next week) apply to them… and to prepare for that, I need to get my portfolio, resume, and cover letter together.
Speaking of that, I did some work on my personal website (where you're reading this) (ed: this is no longer true; I'm on a different site now), and learned quite a bit about how Wordpress works. It's okay, but I still kind of hate PHP. In time I'll probably get it more to my liking, but it's functional now, at least.
Again, the coming priorities are portfolio and job searching, and how daunting they are! I've decided that I have more to do than Backbone can handle, so tonight I started reading into Marionette. It's not something that happened as a lark; I found myself doing so much repetitive stuff in Backbone, and the solutions I found always seemed to lead to Marionette anyway. Finally, tonight, upon turning my attention to my final project again, I found myself installing three plugins to add functionality that Backbone didn't have and that I didn't much feel like writing… and said, to hell with this, I'm going to do it right.
It looks like a pretty good drop-in add-on to Backbone, so I'm pretty confident about the possibilities. I told Tommy, though, that I'd have it together by Monday, which is going to take a lot of my time. Here's hoping.
-
Well, not much to say… Today was presentation day, and I spent most of the day bug chasing, trying to get core features to work the way they needed to work and not the broken ways they had been. I feel like Javascript has more instances of dodgy edge behavior than any other language that I've worked in…
Afterward, my peers and I spent a good amount of time talking about previous classes' projects. We thought, two weeks ago, that other people's projects weren't very good, but we came out today understanding just how hard it is to produce production-quality code in a short time period.
I pretty much faceplanted on the presentation portion of the day. I want to go back to this project, to finish it up, but I know it can take as much time as I'm willing to give it over the next three weeks, or I can find other projects to also work on… time management will become even more important over this last period. Thankfully, we don't have to go in until 10:30 Monday, and this weekend will be a much appreciated break from the slog that was the project week(s), but … what will my portfolio look like? The pace doesn't ever end. What next? I have a book on Objective C, and an Arduino kit here, and I know that my portfolio might be able to say a lot about me, but what do I want it to say.
Back to work Monday.