Posts from December 2014
-
Today's partner: Ben
Another Backbone day, another day thinking that I know enough about Backbone already only to realize there's a lot to know. Once again, the book they have assigned is a great resource, and really backbone (and rails, and some other technologies) deserve a full read-through in order to understand what they have to offer.
Maybe that will be one of my priorities in the new year.
Resolutions:
- Get a job
- Actually read Backbone Annotated Source
But then again, talking around the water cooler, I keep hearing that other frameworks are much more …expressive? than Backbone. You'll always remember your first, but I shouldn't really pigeonhole myself as someone who's only willing to learn one framework… even though I haven't really learned it, yet.
In any case, it nice to get some depth. The topics feel much faster paced lately compared to Ruby/Rails, and I really am chomping at the bit to move on, but this time isn't being wasted. Especially not for the class as a whole—pair programming continues to yield educational benefits, due to cross pollination and so forth.
Our app today was a simple news reader. The coolest thing was using a gem, SimpleRSS, to pull live rss data from various sites around the web. I'm sure that we didn't do any more queries than any other random people during the day, but (for instance) while we were testing the reload button, I did feel a twinge of guilt for smacking their servers around lightly. It's weird to be using real data and not Yet Another Sample Set, because it's a reminder that we're not just messing around.
Hopefully the New Year finds a couple of us working on Real Problems™ with Real Data™… no matter what, we'll all be up to our ears learning for some time …
-
Today's partner: Cihangir
This morning started out with alternating stupid. John and I were both feeling lingering effects of the long weekend, and for the first hour or two before lunch we each had several moments of "wait, what are you doing there?" before we caught up with one another.
I'm glad to say that I remember more about Backbone than I thought, but it was still a bit humbling to realize just how fragile our knowledge is at this point. Way back at the beginning of the cycle, I remembered seeing requests for assistance pop up from the previous cycle's students in chat, and I thought that it was ridiculous that they, in their advanced state, would need TA help… I thought I was missing something.
What I was missing is that, while nine weeks in more than enough time to learn a lot of new things, we're not perfect nor are we professionals (yet). There are entire other languages and frameworks to be learned, knowledge to be solidified, skills to be polished… we've barely just begun. I feel like this cycle's schedule has been pretty perfect—we've had breaks when we needed time off, and the hardest assessments happened at times we were prepared for them. The silver lining to this most recent break, then, is the memento mori we all had coming back this morning: any time spent away from these skills reveals just how far we have yet to go.
I'm reminded of basic training. Everyone was so intent on getting any information that allowed them to pierce the veil of future uncertainty that we'd grill anyone who was as much as two weeks ahead to ascertain what lay ahead. In a new environment a tiny difference in starting point can make a huge difference in perceived knowledge, and we all kind of figured out that the career soldiers didn't have answers that would be relevant to us, yet. However, someone who just graduated basic, whose skills were fresh and memories raw and who could recall just how far they had come from civilianhood could provide much more useful information for us, the recently transitioned, than could anyone else.
The project today leveraged the anal retentive
backbone_on_railsgem, which has a very particular way it wants you to setup your javascript files. It was what I was waiting for after watching Ned's videos introducing Backbone, where I could see each piece going to a very specific and predictable place in the file structure. I like this kind of obsessiveness: rails has its conventions, rspec its own, and now backbone on rails, as well… between all of these, it's good to see a right way to do things, even if it's not the only way to accomplish what we're trying to do.I've seen a lot of programmers come out of four-year programs not knowing anything about style or consistency, and I suspect they drift into corporate codebases, uglifying things and driving their team into technical debt while ostensibly meeting their career goals… some, presumably, get the bug for style and consistency, but I fear that many do not.
There's really not much to say about the project today. It was another CRUD app—posts and titles, and a bit of dynamic rendering—but I feel a lot more comfortable with backbone's paradigms when it comes to generating and manipulating DOM elements, and handling client-side data manipulation. Tomorrow should be more of the same, as evidenced by the complete and total lack of readings, barring the project description itself… I think we're all chomping at the bit to get to final projects. We'll be hearing more about that tomorrow, god willing and the creek don't rise.
-
Today's partner: Mark
A lot to absorb today.
We rounded out the pokedex app, starting from a standardized skeleton again (but this time incorporating a "clean" version of what we accomplished yesterday), and templated the hell out of it, then separated what was once a single
Backbone.Viewinto individual views for each task.I can't say that it was the most interesting lesson we've had here; I was kind of done with this project yesterday, and refactoring a somewhat broken initial model just wasn't that engaging. I'd rather do it right from the beginning, and actually split out the modules into what should have rightfully been separate files in the first place. Further, since the plural of Pokemon is… Pokemon, it was often difficult to figure out which
renderPokemonmethod we were calling—the one attached to the index, or the one attached to the show route.That said, we certainly learned a lot about how Views and (eventually) Routers work on the client side, but it felt like we spent most of our time wrestling with callbacks. I thought I understood them pretty well, but when you have a related view (display requires index to be loaded beforehand) figuring out just how much of your render method needs to live in the callback can be challenging.
Nonetheless, we figured it out eventually. It's done and behind us… I'll probably want to read the assigned book cover to cover over the holiday break, just to solidify what we saw, so I don't trip over my feet come Monday.
Speaking of Monday, that's when Jonathan has asked we have our project proposals ready. I won't have as much time as I thought, but since we're required to make a clone of something it'll be easier (and harder) than I thought.
I would still like to make a clone of something that's at least a bit socially conscious, but then I think of Freshman English class and how some of my best essays were the ones I was least invested in. That is to say, when I can think logically about a problem, without letting my passion cloud my vision, it's often easier for me to make something I can admire.
Maybe, though, I've changed since I was 13. I'd like to think so.
-
Today's partner: Jake
"Stop trying to make
.fetch()happen! It's not going to happen!"I spent all weekend trying to make heads or tails of backbone, and apparently either it paid off, or today's assignment was easy/well composed enough that it was tractable well within the allotted time.
Today's project was the first half of a 2-day project implementing a single-page webapp - a pokedex. (For the unaware, there's a game called Pokemon, and in the game, every time you see a new Pokemon, it's added to your in-game computer index of Pokemans, aka the pokedex… poke poke poke…). The skeletal structure was set up already when we came in, so we started with a rails server with models and routes setup already, and did nothing more than build out the client-side functionality using backbone.
What started in the morning as a static page without much functionality became, by the end, a templated, asynchronous, pretty cool (as these things go) index of pokemans. We didn't accomplish much, all told, except remove a lot of the opaqueness from Backbone models and collections, but given the overall confusion I was experiencing on Saturday it's very much a relief. Backbone isn't that hard, it seems, once you get a handle on the problem it's designed to solve - removing a lot of the drudgework of making an API-driven client-side single-page web-site. But, like Rails, it really merits a cover-to-cover read-through of the source and documentation to understand what is possible, and what's in good taste/style.
Like I've been saying, there are a lot of things I'm seeing that would be incorporated into an eventual portfolio-level project, and since Backbone is the last thing we have to learn to make our projects, I'm thinking that maybe I'm ready to start sketching out what I'd like to accomplish in the next month and a half, starting as soon as I get to the airport Wednesday… I think there will be, and ought to be, a lot of pen-time, hovering over a notebook and essentially drawing wireframes of… what, exactly? I know there are tons of different things I could implement with the skills we've learned, but it's all so daunting now. All the projects I have in mind so far are a bit too large in scope, or too personal/bespoke to merit the effort.
I think.
Hmm. Time to hit people up for ideas.
-
Today's partner: Max
We spent the day implementing a lot of the things that are now standard on the modern web. Notably, modifying webpages while they're open without executing a page reload… and sending and receiving data in the background asynchronously by calling on the Homeric hero Ajax to carry our data.
Wait, no. AJAX (Asynchronous JavaScript And JSON, originally XML) is indeed a means of sending and receiving data in the background while on a website, and it is somewhat heroic in terms of making the web work, but it's mostly a marketing term. What you're actually doing when you make an AJAX site is decoupling page rendering, moving the processes responsible for making your website look and operate onto the client side by leveraging small data transfers and pre-baked rendering operations that live on the client's computer.
Someone else remarked that they would have felt capable of making a website (with server-side rendering) last week, but now they can't imagine not using AJAX, and I agree. The magic of the web today is being able to do things without having to transition, having access to all your tools through DOM elements appearing on page and stuff just getting whisked away to the cloud without your intervention. Everything feels snappier that way, and for someone like me (who gets angry with a 20ms lag while word processing) it's practically essential. I can already think of the sorts of things I want to implement and test with AJAXy techniques, but as we keep seeing, the class rapidly moves past "the coolest thing we know". The first week, I wanted to make an app in Ruby, then I realized what huge advantages SQL offers, then I thought Rails was the bee's knees, then I thought Javascript was the coolest thing we'd see… now I'm just waiting for the next thing.
One thing, as an aside, that I can see is that there's virtue to practicing the things you're learning, but there's only so much to be gained. If the pet project you want to do is mostly nitpicking and trying to accomplish something the world has really moved past in the meantime, and all details of implementation… I can't necessarily see the virtue. There's always something to learn that will be maximally useful (of all the things you could be doing, and given your learning style) and it's not necessarily the obvious thing, or tying off the previous lesson.
Learning relies on practice and scaffolding, but I'm getting the feeling that a lot of technologies require total comprehension of the basics (what's a closure? what's the difference between a proc and a lambda?), some understanding of the intermediate ideas, and total ownership of the thing that makes you money. To get to that point, you have to jump to the next thing while you still have the previous thing fresh in your mind, and have everything gel as a collection of "correct practices" and good habits, … and eventually you can make progress, actually breaking new ground after reaching the top of the (first) cliff. (The rest of the cliffs, of course, are "real" problems to be solved.)
Learning all the nuance about everything is just pointless, though. There are just too many libraries and frameworks to learn back to front, and generally (successful) people build on what came before, and so the new thing is more or less like the old thing in structure and/or syntax.
I can foresee, or imagine, programming always tickling the dopamine receptors in my brain because there's always some new framework… in the 50s, academic languages were the forefront; in the 60s it was all about business-specific languages; the 70s saw C gain popularity, with its general purpose systems programming capabilities… but there's not so much that's new in the history of computing. And there's never a point where you can sit still, content with what you know. Maybe that's a good thing.
-
Today's partner: Jonathan
Today was all about JQuery plugins.
Once we got into the rhythm of writing the html boilerplate and CSS resets and JavaScript namespaces… well, then we had a bunch of trouble trying to write event handlers. God. I don't know how anyone did anything before JQuery, and yet we spent most of the day smashing our heads against JQuery, trying to figure out what it was actually doing. I blame Brendan Eich, frankly. :)
By the end of the day, we had picked up some real speed, but it wasn't nearly as exciting as some other days have been. That said, JQuery plugins probably do more for the web than CSS snake games. I was learning all day, even when we weren't making progress on the specific task in front of us, because we were constantly flipping between APIs, HTML, CSS, and JS/JQ, learning about how they interact. Short of creating specific toys for playing with each component separately (I'm very interested in playing with the Safari inspector's snippets, for instance), there's not a really good way to learn these syntaxes.
From a pedagogical standpoint, then, we return to the problem of unit and integration tests. Today was a lot of integration testing, but our unit tests (building out the basic HTML page, etc) were not well developed enough to truly focus on JQuery. I don't know if there would be a better way to do this—it's possible that, by the time you polished such a curriculum, the technologies of the web would have moved on, and frankly the time (and cost!) of developing such a curriculum is not something you could easily recoup… but it might be fun. That seems to be the main purpose of the web, after all: having fun.
-
Today's partner: Wes
Thank god for Jonathan's CSS lectures.
We skipped the W6D2 content, which was supposed to be on CSS, but last week JT held lectures on CSS at the end of the day each day. Today, we took pre-baked JS solutions for the Tic-Tac-Toe game and Towers of Hanoi and made "visual" versions of them in the browser by using CSS selectors enabled by JQuery.
Holy crap, that paragraph was a mouthful. Basically, instead of using (e.g.) Canvas (which, it turns out, is a difficult term to Google), or a text-only terminal to represent our game state and to select pieces/grid squares, we contrived to capture mouse clicks on a simple webpage, and then to draw game states using document properties of the webpage.
The most important things we learned were the varied uses of JQuery selectors, and how to do basic styling with CSS. By the end of the day, the most we were struggling with were edge-cases in the implementation of our final project, Snake; JQuery and CSS were well under our belts.
I've mentioned before that my memory is one of my best character traits. Well, after this week, I'm realizing that (syntax?) debugging is also another skill I have that others don't always. It's not entirely clear to me whether this is because of my deliberate pace when learning (and the consequent, presumably, deeper understanding that I can achieve), or if I just have more practice/skill than others—or if it's just because I only try the right thing after I've tried all the wrong things. No matter the root cause, I've been happy with my ability to read a stack trace or error message and smash the bug in question, most of the time.
Wes, on the other hand, is much better than I am at identifying a minimum testable product. There were a couple times he had me tie something off and open it in the browser, and while I wasn't immediately certain what he was doing, as soon as we nipped a problem in the bud, I understood. I'd like to add this to my toolbox, too.
Storytime: So it turns out that I'm not very good at games such as chess. My friend tells me that I have a comet-sized ego, and this was nowhere more visible than how I'd play games, especially when I was younger. At the time, I would play a move that could only be considered good if my opponent had no skill whatsoever… but my opponents were never were so bad as I wanted them to be, and inevitably they'd paint the floor with me.
Typically, I want to code for a couple hours, and then run my code and have it be perfect. It is, perhaps, a skill to have the humility to know that you're not as good as you want to be, and (especially when testing carries low overhead) to test your assumptions at good breakpoints. "Measure twice, cut once."
Or, in my case, measure three times, take a break, measure again, and cut once.
-
Today's partner: Sai
Today's project was second or third portfolio project1, Asteroids. We were playing with JavaScript and Canvas to draw the classic game on screen, and using an external key handler to bind input keystrokes to game functionality. A lot of ground covered in a short time, but I have to say it was pretty cool.
Canvas is powerful and expressive—no less than I expect from an Apple-generated extension—and gives you the ability to do some very nice prettifying operations for cheap. JavaScript is, as usual, insane, but we were able to generate plenty of working code (once we figured out a couple issues with
this, inheritance, and some other piddling details) in a reasonable amount of time.It doesn't even matter that I see other groups demonstrating more functionality in less time at this point. I'm learning a lot, we're learning a lot, and what we're producing meets my standards. I'm getting more familiar with the reference materials for the technologies we're using, and doing a lot of meta-learning in turn—learning how to find the more pertinent information from the MDN, for instance.
This is the first project so far where I just really want to keep working on the code. Mostly this is because I can see where organic extensions can take place, for instance when drawing objects that are wrapping around the screen (what's the proper way to eliminate "popping" into and out of existence? Should I make the canvas larger while keeping the window the same size, or should I "clone" objects when they're within a certain range of the border and have the "clone" mirror the original's properties, or something else? Does canvas support a "toroidal space" mode?), but there's not a lot of time for that at the moment. I think I'll keep playing with it from time to time for the next couple weeks, but for now I'm obligated to tap out.
I accidentally began reading the HTML tags guide, and it turns out we won't be doing the W6D2 curriculum until January… man, I want to do the lessons on semantics and document properties. The page layout/editing geek in me is drooling. Oh, well. Tomorrow's JQuery; time to get to work.
-
depending on whether you view chess and ActiveRecordLite as both worth posting ↩
-
-
Today's partner: Max
I'm kind of liking JavaScript, which is surprising on day 2. We'll see what day 30 looks like, but so far, it's been forgiving.
Today was another example of re-creating Ruby code with JS, but emphasizing the features specific to JS—mostly callbacks and (more) closures. The paradigms are different, and JS is much more verbose (less of a profusion of one-line methods and more C-style 20 line blocks of
if-elses and explicit loops). Which means that we're a lot more "productive" in the "productivity = lines of code" sense, and it was easier to make each individual line work, but I get the sense that finding an error will be harder in the future.Which wasn't really a problem today - most of our issues boiled down to "Does this one-word function exist in JavaScript? No? Damn." - and between Max and I, we were able to handle pretty much everything there was to know about callbacks. We ended up finishing by break, and sort of trying to find something to do with ourselves to make productive use of the last hour and a half.
I don't think I like node, but we can make it do what we need to. What's most frustrating is that when you do have a real problem (debugging or experimenting), building up workable state to the point that you can try to find the problem is much more difficult. I really hope we get exposure to a testing framework or something for JS so that we can automate a lot of the process of iterative development.
Other than that, the module packaging in JS is ugly, but given the power and portability of JS overall, I think I'll be able to survive.
All in all, I'm enjoying JS, but what I'm really looking forward to is the power of JQuery and .css. Is it odd that selectors are so interesting to me?
Me, a typography nerd… liking text styling… who would have thought.
-
Today's partner: Jesus
Well, that was surprising. Javascript, right now, feels like dirty C with closures, which is well up my alley.
Javascript (aka ECMAscript) is NOT Java, btw.
For overview, we did a lot of basic stuff—array manipulation, iteration and recursion, and so on. The thinking was pretty standard, considering that we'd seen some of the problems on the prep work, in the first week, and again on the first assessment… at this point, my brain is pretty much prepped to think about how to solve this particular set of problems.
I was kind of thinking the other day that I'd like to be able to play with C/C++ again one day, and … jeez, the syntax of Javascript is all C. It's not surprising if the story we were told in lecture was true, viz. the creator of JS having to design the language spec in basically a week. "Good artists create, great artists steal," as they say, and the best place to steal from in the programming world seems to be C.
I was afraid that it would be a lot more troublesome than it was, given how many JS readings we have (and how many I didn't quite read). Other than some hair-pulling over trying to figure out exactly what a closure is, I think the day went pretty smoothly. My partner was having a slightly harder time with the algorithms than I was, so I tried to pace myself to allow him the time to get more out of the day, but I can feel that I'll probably look more intensely at JS over the weekend than Rails or Ruby. This all even though most of my to-do list consists of lingering Ruby and Rails work that I want to tie off.
Ahead of us: more .css fundamentals, a lot more JS readings, and then putting it all together. After the semi-slog that was Rails, I'm okay moving on, even if it is a LOT to process.