Author Archives: Cory Dawson

jQuery: The shortcut language

Whoever came up with the idea for jQuery deserves a medal. Such a simple concept can go such a long way. Some effects are difficult for me to conceptualize, like for example in the second jQuery exercise, we were able to simply change the speed of a dropdown menu using either the  “slow” or “fast” parameter. Whereas some methods, like .fadein, you can quantify for exactly how long in milliseconds the animation should last. Perhaps this comfortability just comes with practice. For example:

$(‘#nav-dropdown’).slideToggle(‘fast’) vs. $(‘#nav-dropdown’).slideToggle(‘100’)

Either way, it’s easy to see how powerful the combination of JavaScript and jQuery can be. The complex animations I see daily on websites, which just weeks ago would have been impossible for me to explain, make sense now.

I wonder if other programming languages have libraries like jQuery that can condense complicated and extensive chunks of code into easily-referenced bits of code only a line or two long.

I also found reviewing the DOM very helpful as It’s easy to get lost in the weeds when doing this line-by-line coding. I think of it as a sort of order of operations, which I’m sure it’s been described as before.

Looking ahead

I’m very excited to start building a profile site and to include the plethora of media I’ve produced over the past four years. I’m especially excited to show off my news photography and video work. Every profile site I’ve used on WordPress has had an unattractive profile layout that I didn’t find conducive to showcasing media. And the themes that did showcase media well I wasn’t interested in paying for.

I’m looking forward to talking with my profile subject, Ryan Schneiderman, about how he’s built his dad’s photography showcase, and hopefully take some good tips from him.

Logic, JavaScript and some questions

JavaScript proved to be simultaneously the most interesting and most challenging language yet for me. The Codecademy lessons were as good as they could be, but I certainly will need to review this language the most.  

Having struggled through logic in college, I was familiar with some of the key terminology and the concepts behind it — boolean connectors, statements, arguments, inferences and implications. I never had an opportunity to really apply those concepts except within equations. I now wonder if we should have been taught JavaScript alongside logic.

Learning how to write pseudo-code was a key takeaway for me. I know that writing pseudo-code will be immensely important not just for my own understanding but also to make sure the code is organized. For me, it’s always more important to understand the why rather than the how — I find that especially important here. I’m confident that the goal can be reached when I understand the concepts. The how will come.

There were some requirements that I found unnecessary in JavaScript that I feel I need more clarification on. Why is it that, when interpolating, you need to use the + sign? Why aren’t there more standardized ways to access your JavaScript in the HTML?

Coming together

This week for me represented a big step forward. I was quite nervous to build a prototype homepage from scratch — I was pretty sure I was unprepared to hand-code a full webpage. The assignments for this week ended up taking me more time than I anticipated and that — combined with starting a new job and some light procrastination — pushed me past the deadline.

But however long the work took me to do, in all the work ended up not being as difficult as I feared. My fingers started to type the correct tags with ease and my page slowly but surely came together. The lessons taught some important new information, especially styling conventions, that for the first time for me felt as if they were logical extensions of what we’ve already been learning.

It did take me a little while to figure out an ideal workflow when actually using Sublime Text in conjunction with GitHub. I found myself working past where I should have entered a commit, and therefore felt I had to cut out some code, make a commit, and re-enter it in Sublime Text and make another commit. I also wanted to check my page before a commit, so I ended up writing some code, popping it into a browser, refining it, and then committing. Just logistically, it’s a lot of jumping around on a laptop screen, so once or twice I got a bit lost between different windows on my laptop.

I also started to get a sense for how I should use CSS — I can see how a separate style.css page would be almost required for a larger page. But for our purposes for this assignment, using inline CSS between <style> tags felt more natural and easier to manipulate.

 

Cause and effect panels greatly helped my understanding

Those multi-panel windows in Codecademy are honestly a genius and elegant way to show how what you do to the underlying code affects the displayed webpage. After learning a few basic tags and following the lesson instructions, it was interesting to toy around and go off-script to see how things changed. Only once or twice were the instructions difficult for me to follow and I had to use the hints.

It speaks to the economy of HTML that you can only know how to use no more than a dozen tags and be relatively well-equipped. With some basic research I found that there are only about 250 HTML tags that anyone would ever really need to know — this makes me more confident that learning this language will be a lot easier than I originally anticipated.

It was also revealing (and strangely powerful) to use the inspector tool. The example in the “Meet your web inspector” showed how it was easy to download a picture that the site perhaps wanted to prevent (obviously you could also screenshot anything). Not to skirt the ethical boundaries of the technology, but I did experiment with the tool a bit… I used the web inspector to delete a site overlay on The Boston Globe website when the paywall hit, but the site didn’t load any part of the article. The inspector did come in handy on the Wall Street Journal site, which will load the lede and second paragraph, but obscures the second paragraph making it hard to read. Using the inspector though, you can easily read the first two paragraphs within the HTML. I suspect that with more poorly-designed paywalls, simply deleting the paywall pop-up could reveal an entire article. Or we could all just start paying for subscriptions to newspapers…but I digress.

 

Metaphor is key

I’ve never been great at left-brain thinking — math especially. Reporters are notoriously bad at math, so that was one more thing that helped me fit into this profession.

But the further removed I’ve become from the feeling of stressful confusion that dominated my experience in math and other classes that generally served as precursors for those who went into computer science careers, the more interested I’ve become in the prospect of learning code. Computers aren’t going away.

Getting past the jargon of programming will be a huge hurdle for me. I love deciphering jargon — good journalism writing is being able to cut through jargon and clearly explain concepts to readers — but up until I really understand a concept, it’s difficult for me to connect the dots for myself, let alone readers. That’s why Greg Linch’s post on computational thinking was so helpful.

Specifically this passage, from Jeannette Wing’s article that Greg pulls is very helpful for getting in the right frame of mind:

“When your daughter goes to school in the morning, she puts in her backpack the things she needs for the day; that’s prefetching and caching. When your son loses his mittens, you suggest he retrace his steps; that’s backtracking. At what point do you stop renting skis and buy yourself a pair?; that’s online algorithms. Which line do you stand in at the supermarket?; that’s performance modeling for multi-server systems. Why does your telephone still work during a power outage?; that’s independence of failure and redundancy in design…”

Metaphors like these will greatly help me de-mystify the definitely mystifying world of computer programming and instill some much-needed confidence when I’m tackling topics like this.

I also felt super mellowed out when reading the Zen of Python post. Many of these mantras work for life.

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.

Especially in regards to the “explicit is better than implicit” piece, I’m getting a sense that writing code is a bit like doing the work of an observant reporter — one who shows rather than tells — but it’s even more akin to writing a screenplay. When doing screenplay writing, every action is clearly denoted and explicitly stated. Actors in a horror never “feel scared” in a screenplay. They start to sweat. They clench their fists. They dart their eyes around. Their intention and thoughts are only conveyed through action.

It’s a very different way to think about writing than what many of us are used to, but learning it has helped my journalistic writing.