Posts from January 2015
-
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.
-
My biggest challenge of the moment is maintaining focus. Maybe if I had a single project to work on, it would be a bit different, but there are a lot of little time-consuming things that need to happen in a lot of areas to be ready for, say, next Friday's employer presentation day. I really need a decent portfolio to send out, or a bigger list of employers to contact, or a number of other things… I'm working constantly, but I'm not sure if I'm working on the best use of my time at any given moment. It's an old problem.
Today I think I'm going to take a break by putting some polish on some of the smaller portfolio-like work. I hope that will be enough to get me motivated to hammer on the rest of what I have to do. It's daunting, though, and I know there's not even any free time on the weekends, not that I would necessarily want it. What would I do with the time? Everything I know anymore is here.
-
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.
-
There are limits to what a person is capable of. In a given population, maximum skill lies along some sort of distribution. If everyone were to devote themselves totally to a single pursuit in a given society, people would eventually reach a point where there was a compressed distribution of that skill close to the maximum possible within that society.
To put this in concrete terms, if everyone in the US decided to devote themselves to football, we would eventually (within a generation or two) see every person within a couple percent of their maximum possible skill in football. The variance could be explained by factors such as lack of motivation, choosing a bad position (a person whose physiology was more suited to being a linebacker devoting themselves to becoming a quarterback, etc.), and normal imperfections of the world.
Ignoring other follow-on consequences of such an arrangement—such as the selection pressure to breed more capable children—a lot could be said about the population in a world like this. For instance, the total market for talent would be nearly saturated. Many of the people who are professionals today would not be in such a world because of selection pressures. Most people would be better at evaluating others' skill at the common task—not good necessarily, just better. Given that evaluation of skills and performance of them are correlated yet distinct, not everyone would be suited to determine which of their fellow citizens is better than others.
Consider: in a given domain, not only are there different specialties (quarterbacks and linebackers; percussion, strings, and wind), there are also different meta-specialties and synergies. A football team, due to the nature of competitive games, needs trainers, managers, coaches, strategists, data analysts, businessmen, and so forth. What makes a team successful in a competitive sense (winning games) and what makes a team successful in a business sense (bringing in as much money as possible) are somewhat distinct skills. Getting the attention of customers and getting them to want to spend money is in part due to the prospect of being excited—close scores, a memorable experience, novelty (being part of something no one else is), camaraderie (being part of something others are)—and not necessarily seeing one team utterly destroy another. A single star player is not enough to produce long-term interest: if no one can ever get the ball to the running back or the defense crumples under an offensive drive, no one is going to be interested in the "product" over time.
The football metaphor is limiting, so I will set it aside for now. Consider the following, then:
There is nothing that everyone does well, so we don't know what the limits of performance are. Given that time and attention are limiting factors in most business relationships, we tend to choose products and experiences not on raw quality but rather on some combination of the above factors, and others: exclusivity, inclusivity, identity, memorability, compatibility, reputation, exhaustion.
When it comes to occupations, there are two main poles at which work accumulates: that which can only be done by many people, and that which need only be done once. The former is represented by the term "labor": cleaning, cooking, building, advising, teaching. The latter is represented (mostly) by the term "creation": design, invention, research, architecture. That isn't to say that this second set of tasks only need be done once, ever; however, designing a particular (e.g.) car allows for the creation of a practically unlimited number of cars, whereas the construction of a single car doesn't allow thousands of people to drive.
-
My first year in college, I was best friends with someone whose entire existence has since been reduced to a single anecdote about spoons.
This isn't to say that I never think of him in any other context, nor that he didn't have any other effect on me. However, the only reason I ever have to bring him up to other people is to mention the following: I knew a guy who decided to steal a spoon from the cafeteria every time he went for a meal, to the point that they no longer had enough to make it through the day without constant washing. Meanwhile, he had an entire desk drawer full of spoons that he brought with him when he moved out of the dorms.
It's not a particularly interesting anecdote, and I can't recall a single time someone has requested a follow-up. "Oh, that's interesting; why did he do it? How many did he accumulate in the end? He sounds like an interesting guy; tell me more about him…" When I'm reminded of it, I could probably chuckle quietly and reminisce to myself rather than inflict the non-story on another person, but that never happens. I can't say why, precisely, but I have some theories.
When I arrived in my dorm, the college hadn't opened "officially" yet. Due to the nature of the residence community—we were two floors within a four-building, twenty-floor complex dedicated to people from overseas or who had an interest in international "stuff", for lack of a better word—we were allowed to move in early. For the students who chose to take this option, it was an unparalleled opportunity to explore the college in that golden moment of perfect anticipation, where everything is open and available but not ruined by the pressing crowd.
The beginning of the semester is defined by people exploring themselves, trying to start anew. This is doubly true for the beginning of the academic year, when the light and warmth of the summer are still making their presence felt, and the clarity provided by three months' vacation meets the promise of all new courses untainted by the anxieties of years past. While the beginning of the spring term is defined by resolutions to do better—the gyms and dining halls are full-up with students trying to make up for past failures, by eating right, working out, waking up early, and so forth—the end of summer is an explosion on all fronts. Freshman are learning what it means to define oneself in the vacuum created by the absence of authority; sophomores and juniors are seeing the world with the veneer of experience (and taking advantage of freshman naïveté), making up for missed opportunities by exploring those places that went ignored in earlier years; and seniors break in the old favorites for the first time of a new year. The end of August is the true spring in a college town: no venue goes unvisited, no random adventure goes untaken, no resource or club goes unconsidered.
Moving in early allowed us to get a jump on the lines. In the first days before move-in, the international students (real and fake), gained the jaded veneer that only occurs during mass transitions. "Student rate football tickets? Yeah, me and a bunch of the guys bought a block of ten consecutive seats a while back" (yesterday afternoon). "
-
Politics is sometimes described as the art of the possible. The possible is the set of all states that are reachable from the current world, given the preferences and abilities of the people currently in power.