Posts tagged 'javascript'
-
Today: solo
Today's project was to create a web chat client using
socket.io. Surprisingly, to me, I had a lot of fun doing this work—this sort of systems~ish programming is right up my alley. Massaging packets and managing client-server data processing is fun, once I figured out a couple questions about namespacing and the like.In terms of "people won't remember what you said, only how you made them feel", I know that I had fun today… but between 5:30 and 8 pm, I made some changes that completely broke how the server handles command requests. I can change my user
nick, and then immediately the socket closes, and a new socket is created, losing all the previous state. I managed, in just under two hours, to track down the call that's causing the error—something about callingsocket.emitinside a particular logic branch—but I couldn't manage to kill the bug, and it's kind of driving me insane.That said, this is one of the first projects in a long while that I want to keep working on even at the end of the day (as can be seen by my still being at the office after 8 pm). It was a ton of fun, which I can't seem to overemphasize despite my best efforts, but I have to throw in the towel. Maybe this will be something that I can keep working on after the final project.
Speaking of, today was the day that we had to present our initial wireframes to the instructors. Tommy sat down with me and my admittedly crappy, half-baked wireframes, and we walked through the app I'm going to spend the next two weeks creating. This is the really fun, really hard part, one because I keep having to rein myself in, and two because … actually, that's it.
When it comes to large projects, I struggle to keep the scope of my work to a reasonable level, instead letting my ambitions smash up against the realities of implementation. This will either be an unmitigated disaster or a really excellent personal learning experience. I'm good at debugging and problem solving, but when it comes time to interview after this cycle is over, I don't want to have to say that my greatest weakness is that I don't know how to bite off only what I can chew.
The assessment went well; again, the class as a whole were missing quite a few points, but the median score was perfect, which means that a few people had a lot of failed tests. Hopefully they'll overcome; I'd hate to see any of the people I've been working with the past eight weeks get washed out now… although I can understand if it has to be that way. We're not General Assembly; we have to maintain some standards ;)
-
Today: solo day
I think it's just me, and not the time off. Backbone is… opaque.
Today was our solo project day with javascript/Backbone, and let me tell you, I was struggling. I've been looking forward to having another solo day, but I consistently fail to gain traction on these days. So, I don't know, I'm kind of torn about solo work. All I know is that I'll have to figure it out eventually: how not to struggle the first hour or two after I sit down at the computer, since that's the time I should be "making my money."
Our project today was to work on a clone of Trello. This is an app that I (thought I) had installed on my phone once upon a time, but I didn't quite realize what it did. Basically, you have boards, lists, and cards. Boards have a name/topic ("trello project"), lists have a topic ("features to add"), and cards have short bits of content that can be rearranged and reordered as needed to describe the list they contain. Additionally, there are collaboration features and a bunch of different varieties of actions that can be done to cards… all pretty cool until you realize that it's topologically equivalent to a tree/outline, and that there are literally a million variations on this theme out there.
As an aside, how many ways can you have to make an outline? Maybe I'm missing something here, but the main differentiation between say, Trello and workflowy is simply presentation. All these things are supposed to help make you more productive, but if the stuff you need to get out doesn't outline readily, or is topologically distinct from a tree, you'll spend all your time trying to shoehorn it into a broken topology.
That isn't to say there's no value in the presentation layer. Structurally, there's little difference between OmniFocus, WorkFlowy, any of a number of GTD apps, and a MS Word outline… but functionally, presentation matters. The biggest thing that any of these programs do is to hide junk that's not "in scope" at the present moment, as well as allowing you to manipulate objects and their sublists as a coherent object. I've told people countless times about the power of the MS Word Outline for structuring a document, but where it really shines is when you have a good idea where you want to end up and just need to flesh out concrete topics. It, and others, are not so good at just letting you dump a mess of thoughts and then bucket them as needed—there often is no general purpose "inbox" that can collect detritus that you can in turn process later, despite this requiring little more than a database field and a view. I wonder what all these app developers' workflows look like that this is desirable behavior.
Anyway, I started today really slowly, and gradually picked up steam as the day progressed. Toward 3 pm, though, I felt my momentum fail as I struggled with some stuff that I can't quite quantify about Backbone. I couldn't think of what I needed to do or what I even would need to do to figure out what needed to happen, and I can't decide whether it was because of Backbone, javascript, the instructions, or what. I still largely prefer ruby and rails, but I understand that JS is the bread and butter of webdev, so it'll pay to overcome my issues, and yet I can't properly decide … much of anything. Guh.
-
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 ↩
-