Author Archives: Sarah Sidlow

Well, that escalated quickly…

I honestly didn’t expect to have so many issues with this week’s gallery assignment. I totally understood the HTML that we built in class, and could follow all of the granular steps laid out in the JavaScript pseudo-code. Yet when it came time to fill in the JavaScript with actual code, I was at a loss. Sure, I could create a close approximation to what I thought it should look like, but I know that so many things can break code, I was sure I was leaving out critical details. I also found myself missing the instant gratification that Codecademy provides in its exercises: there was no little teal check-mark to tell me I had done something correctly and could move onto the next stage with confidence.

Process and Further Questions

I finally found a resource that helped me work through the structure of the JavaScript. It approached the problem in a slightly different way than we had built using our pseudocode, but it explained each piece of code well enough for me to understand how it worked. Yet, when I plugged that code into my .js file, it still didn’t move the slides! At this point, I wondered if maybe the problem was that the JavaScript wasn’t appropriately linked to my HTML file.

I asked one of our web developers to take a look at my project, and he said that I wasn’t referencing jQuery in my HTML, so he helped me add a line of code.

But I didn’t remember having to link jQuery to the HTML in addition to linking the local JavaScript file. Is this something we have to do when using jQuery in our projects?

Also: are there better/alternative ways of testing JavaScript than pulling up the HTML in a web browser? I’d love to believe that some of my issues stemmed from the browser window not refreshing properly, but I doubt that’s really the case.

On feeling organized

I didn’t. Usually, when I’m writing, I have no problem skipping over a challenging section and returning to it later (in fact, I saved the introductory paragraph for this reflection until the end). But with code, everything feels contingent upon everything else. I’m not yet able to see functions as contained “chunks” separate from one another, and had a hard time creating new sections without finishing previous ones.

My research also felt scattered. It turns out, opening 9 tabs with similar google questions and YouTube videos isn’t a helpful way to work through a coding roadblock.

Because of these issues, I also felt extremely disorganized committing my changes in GitHub. There was so much trial and error going on in the .js file of my project that I was afraid to see what the GitHub history even looked like. By the time I got something to work, I had a hard time articulating the theme of what I had done in order to commit it. Moreover, I can’t even imagine what my complete repo history looks like now—I’m sure I won’t be able to easily retrace my steps. Practice, I guess…


This week’s jQuery lessons came as a relief following last week’s focus on JavaScript. jQuery solves a problem that I’m glad to learn was more universal than just my own shortcomings: the JavaScript language is bulky, the syntax is confusing, and small mistakes are easy to make.

Unfortunately, using the jQuery library doesn’t eliminate the possibility for error, but it does render errors much easier to locate and address. Hooray for jQuery!

The biggest challenge

The exercise I found most challenging had to do with the DOM. I wasn’t expecting to have such trouble with it—I understood the basics of parent-child and sibling relationships within the context of HTML—but I found that using the DOM jQuery methods to reference various elements abstracted the code to the point where I had trouble remembering what I was supposed to be doing in the first place.

I can understand how jQuery selectors are useful for referencing specific areas of code, and how jQuery actions simplify the code that would be necessary to make things perform the desired behaviors. I also understand that utilizing the parent-child HTML structure by referencing it in the JavaScript makes the code more dynamic—that is, as things within the code change, the JavaScript functions will still apply.

Yet for some reason, using the .next(), .children(), etc. methods just felt like a big riddle. Onwards to more practice, I suppose!

Fun facts

This is just nerdy, but I was really interested to learn that the common case used in JavaScript is called “camelCase.” I had noticed its structure in earlier lessons, but didn’t know anything about it. Apparently, it’s named for the shape of a camel’s humps—with each hump representing a new capital. Of course, we’ve all seen it used in cases like “iPhone and eBay.”

A side note along this nerdy grammar thread: Is anyone else frustrated with Codecademy’s consistent misuse of “it’s” when they mean “its”?

What’s next?

In addition to putting out feelers for our midterm web developer profiles, I’ve been giving some thought to what shape I want my final project to take. At Georgetown SCS, we have a number of WordPress microsites that serve specific populations. The Hoya Professional 30 and the SCS Commencement site are two examples of projects I’ve launched. There is a nascent desire among the administration to launch a student life website dedicated to events, social resources, and student groups here at SCS. I think this is a project I’d like to take on in order to test the new development skills I’ve learned. The major hurdle I’ll need to figure out is the hosting (the other microsites are hosted through Georgetown Domains, which limits the themes and add-ons you can use).

More to come!

Dear Duolingo: Consider adding JavaScript

This week I realized that I have begun learning a new language. Reflecting on my past language-learning experiences, as well as my former brushes with code and query languages, will help me set realistic goals and expectations for this new challenge.

One thing stands out to me as being immediately familiar to my past experiences: I know what the code supposed to look like, but I still have trouble constructing the right syntax on my own. The end-of-unit quizzes highlighted this tendency. I usually got the syntax questions right on the first try (just because they looked right), but I struggled with the questions designed to explain why something is done. That is to say, I’m better at reading the code than I am at writing it.

This week’s lesson with the JavaScript console also reminded me of Data Reporting, where we learned the basics of MySQL query language. I remember when I started learning about MySQL that the process of writing pseudo code was critical in the writing/development of more complex queries. It’s also a great mental/emotional strategy when you get frustrated with writing code, because it’s pretty hard to get it wrong, and it helps you organize your thoughts. I’ll definitely be taking the extra time to write pseudo code and add comments to my code as it grows, just to save myself some aggravation.

Goals for the Future

If “getting better at JavaScript” is too broad a goal, I’d like to prioritize getting better at reading the error messages. When I was learning how to use MySQL, the error messages were immensely helpful at identifying syntax and other input issues. In the Java console, however, I’m still at a loss. Luckily, I’ll have plenty of opportunities to practice reading the error messages, because I anticipate I’ll be generating a lot of them in the weeks ahead.

Is there a Duolingo option for JavaScript?

A Question I’m Afraid to Ask…

It’s clear that so far we’ve been creating variables and functions, and then defining them within the code (i.e. the user’s name is “Cole” so let userName = ‘Cole’. But when we interact with web pages in the wild, that name field picks up data from our user profile. What does the code look like that pulls data from another source and into the field we’re using?

Welcome to my MySpace

Good Design(?)

Well, I made my first “homepage” using HTML and CSS, and I have to admit I was immediately transported back to my parents house in the early 2000s. I never used MySpace, but I loved Xanga, a blog-based social site that allowed users to edit their own code. I spent hours researching the correct HTML for important things such as:

  • Background music that played when a user visited the site
  • Cursor options that transformed the mouse into small animals and objects (there was likely malware associated with this)
  • Font colors and styles, etc.

I imagine for many students my age, this was the first experience with HTML they had. What struck me the most in this week’s homepage repo assignment was how complex a simple, elegant web page must be behind the scenes. Yes, it was relatively straightforward to change my font to Comic Sans and add a gif of Neil Degrasse Tyson. However, those notably beautiful webpages (Atelier AM, American Documentary, and others here) must have been painstakingly designed to be beautiful on a range of devices.

CSS Stylesheet

I decided to link an external stylesheet to my HTML file, rather than use inline CSS stylings. The Codecademy exercises on CSS made me appreciate how quickly CSS styles can accumulate, and how much more organized it felt to have them all in one place. (Though I will admit I wished Codecademy had hinted to alphabetize the styles for ease of use—which seems like a no-brainer best practice.)

I struggled for a while figuring out how to link my stylesheet to my HTML file, and finally realized it was a combination of incorrect href syntax AND incorrect CSS syntax, so that even if the files were linked, the changes weren’t appearing in my test browser window.

After a few episodes of trial and error, I was ready to give up on the separate stylesheet and just add in-line CSS styles, but I knew that for my final project I would want them to be separate, and I would be better figuring it out now rather than later. I’m glad I did.

A note about GitHub:

I can appreciate the utility of a tool like GitHub to manage the uncountable tiny changes and bug fixes/additions to code. The mechanism of committing changes is simple enough to understand, but I’m concerned that the more changes you commit, the harder the code is to actually read. It takes practice, I guess…

Why is the web inspector editable?

The thought of someone sitting in their home rewriting the headline on the front page of a newspaper makes me cringe. Why then, is it possible for me to go to Sir Ian McKellen’s official webpage and change his background image to that of a cat in a turkey costume?

It’s obvious that the web inspector tool is useful for learning how the building bocks of code and style interact. I can also understand that it may be helpful to inspect the code of a website in order to debug it, or to be sure that it doesn’t contain malicious material. But I can’t think of a lot of reasons why it should be editable to the point of replacing McKellen’s face with Turkey Cat’s.

Regardless of the reason, it reveals a few things about the personality of web development, and perhaps of web developers themselves: they are tinkerers. In using Codecademy for the first time, I was reminded of how genuinely rewarding it is to achieve tiny victories in code. If you’re not de-bugging to figure out a past mistake, you’re often pre-bugging to see if (maybe) you can get something right the first time. Because of this, it’s important to break the code components (and the expected behavior) into its smallest unit.

For that reason, I’m also excited to begin becoming familiar with GitHub, which operates a bit like track changes for large pieces of code. With each small unit of code and expected behavior, new opportunities for error and unexpected outcome are introduced. Thus, the ability to isolate small changes and to keep a clear record of edits over time is extremely valuable.

But I’m still not totally convinced about the web inspector tool…