Posts tagged 'css'
-
Today: clearing out the backlog of things that I wanted to do on my homepage.
You know, until AppAcademy, I hadn't seen much purpose for a homepage. I remember the days of the late 90s, when everyone had a homepage with "About Me" sections that (let's be honest) no one really cared about, and then some collection of things that they cared about, like spacecraft of the Federation. (There was one guy who had a homepage dedicated to the Performa 6400, and that I used for years to diagnose issues.)
I may do something similar on my own page in time, but for now it's just a pretty good hub for everything I want people (who might want to hire me) might want to know about me.
In trying to put my best face forward, I've been customizing my hosting. Among the NEAT things I discovered today:
- Bare
gitrepos, and thehooksdirectory in a git repo, that allows you to auto-deploy files (for instance) - I have control over all components of my chosen theme, which means I can debug broken scripts (damn designers!)
- It's easy to override the designer's css, especially when he barely uses classes.
- It's easy to keep my version of given plugins up-to-date in order to use the most recent features.
I know, nothing here that's ground-breaking, but there were a couple times today that I found myself exclaiming, "neat!", if only because I figured out a way to get something closer to exactly what I wanted. … well, within a certain definition of "exactly". There are a lot of things I would do differently if I chose to build my theme from scratch, but given the constraints of using Wordpress and (most of) a pre-baked theme, it's pretty cool.
I may still SASS my page up, since SASS is cool, and choose to redo major components of the design (e.g. the font-family), but all-in-all, it's close to where I want it to be to represent me.
One thing I discovered: I haven't been nearly as consistent at posting here as I thought. The calendar widget at the bottom of the page has a LOT more gaps than I'd have believed at first. I shall try to rectify that. One change is that I intend to post more stuff that may not be public up there (here), including blog posts that don't have anything to do with AppAcademy. All in due time.
- Bare
-
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.
-
Today was the .css assessment, and after working late (and falling asleep while working a few times) and doing the practice twice, then studying the solutions last night and this morning, I kicked ass.
To summarize: good design often has a logic, and good instructors are consistent, almost without fail. If there are exceptions, they are for a good reason - your instructor is working at the forefront of the field and the rules aren't established, the design language you're working with has some foibles that you have to work around.
In our case, I've managed to pick up on and benefit from the design habits of our CSS specialist, Jonathan, and have slowly been trying to incorporate them into my own design language. For instance, set consistent (and generous) margins/padding, keep visual space symmetrical, tend to favor making item borders on the inside and container borders on the outside, … and so forth. I haven't built all of this into my site yet—it still looks like baby's first webpage, although thankfully not as 90s as all that—but there are a lot of things coming together very quickly.
Case in point: investing in figuring out backbone means that I've basically added three full collections, three full models, and half a dozen views to my app today alone. I also added two utility … packages? files? to my app that enable some neat stuff, one that makes my life easier, and another that enables a pretty cool "live search" feature to the website.
Yeah, it's all pretty silly overall—I'm reinventing the wheel—but I know why and how I'm reinventing the wheel here, which is okay by me.
There's very little of what I'm doing that is really challenging now, which is okay after the weekend. To use a workout metaphor, this is my plateau, where I'm consolidating gains before looking for more of a training effect. Again, I'm okay with that.
Meanwhile, I'm able to explain to a lot of people what their code is doing wrong, or able to sort through arbitrary code and understand it pretty idiomatically; I'm much more confident with
gitand amaliasing my most common commands regularly, and can find my way around Atom like nothing.Wow, they have taught us something. :P
-
Today's partner: Jake
Yes, you read that right. We didn't travel back in time; to the contrary, time keeps marching forward (despite the date overflow back to Jan 1).
Today was the day we put Jonathan's lectures on CSS to use. It was kind of funny; I made sure to do my best to read the lectures for the day last night, and by this morning not only had I been assigned a different partner, but the readings and project were different. It turns out that JT was putting some final touches on his version of the CSS day, and it was (I believe) a much more effective day than what I thought we would have been doing.
On a plus note, today was much more approachable than Backbone has been, for me. Boxing off elements and figuring out style hierarchies is something I'm capable of wrapping my mind around, and despite some of css' foibles it was easily in reach. Per usual, coming up with descriptive names for things was challenging—Jonathan is of the belief that you should add
classes to DOM elements early in the design process, even though we often weren't sure what role something would be playing—but this is one of those times that the cmd-D shortcut, for selecting the next token in the source file, came in handy. You see, any time you decide that something isn't named quite right, you can simply find the first occurrence of that name in your source file and mash cmd-D to select subsequent items, then overwrite them all at once.There's something very satisfying about using eight or more cursors to overwrite some chunks of text. :D
I'm not totally solid on CSS, but I am much more comfortable with it than I ever have been with Backbone. Really, I would not mind doing more of this—converting wireframes into semantic websites—but I know that this is not, by far, my strong suit. After all, I didn't have the skill to actually create a design from scratch, only to make it into semi-sane CSS, and I can't believe that that's a skill that's so much in demand that I can make my mark there.
It's fun, though :)
Tomorrow's the Backbone assessment, and per usual, I feel like I understand it a lot more than I have so far. I still have issues juggling state between all the separate files, but I was able to cobble together 100% passing specs by the 50 minute mark (out of an hour) despite not always knowing exactly what the pattern I was trying to replicate looked like. Looking at the practice solution and my own code side-by-side, there were maybe two redundant lines, and very few differences otherwise.
-
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.