Author Archives: Cory Dawson

Developer Profile: Ryan Schneiderman

Ryan Schneiderman is the younger brother of a good friend of mine, Jason. They’re both developers — Jason works at Bloomberg and develops applications for the Bloomberg Terminal, a key piece of technology that traders, banks, and financial institutions worldwide use to get information on the price of a stock, for example, as fast as technologically possible. Though Jason doesn’t really use any of the technologies we’ve been exposed to in this class, he suggested Ryan would be a good choice.

Ryan graduated from Tufts University with a computer science degree last year and has been working as a freelance web developer since then. He recently finished a complete website for his father, a successful photographer in Vermont.

The first stage was architecting the overall project. He wanted to figure out what backend framework to use. Schneiderman eventually went with Django, which is a high-level Python web framework, mostly because he saw that a lot on job applications and assumed it was one of the more marketable backend architectures to learn. It turned out to be a really good framework to use for the website.

The first step after deciding to use it was to research a bunch of tutorials on how to use it, and then started to get simple “Hello World” pages working. He used Amazon Web Services to host the website. It was an early major hurdle, Schneiderman said, to know that he could host a Django application on AWS and then, from that point forward, it was just a matter of writing code.

The first thing he tried to do was just to display one of his dad’s images on a page with nothing else, just an image by itself on the front page. That in itself contacted all of the different parts of the application, from the database, to the view which queries the database and sending that information to the front end.

“I remember when I did that it was like the first  ‘eureka’ moment,” Schneiderman said.

A lot of the early process was troubleshooting. it was a lot of Stack Overflow, Googling, some YouTube videos. Every step of the way Schneiderman said he gained a little better understanding of what’s going on, then chunking away, getting a breakthrough, and hitting another obstacle.  Learning a new language or framework is a lot of small little victories that contribute to a greater understanding along the way.

“It was more a mental hurdle than anything else, just to stay the course and keep chipping away,” he said.

To design the prototype for what he wanted the site to look like, Schneiderman just used pen and paper just to figure out the aesthetic, the organization, what he wanted to have on each page.

As for giving his non-programmer father ability to use the site, Schneiderman said Django allows for a templated admin page that’s attached to the website. It’s basically an interface for the database, so you can upload images.

Django comes with a decent template structure to interface with the database from a user perspective. So that was actually one of the things that Schneiderman felt very fortunate to have chosen Django because otherwise he likely would have had to build an application that his dad could use to upload.

Most of the communication and collaboration between Schneiderman and his dad was on the functionality of the front end, which ended up being mostly HTML, CSS and JavaScript, including some React.

React is a JavaScript framework that allows for updated and state-based JavaScript. So for example, you can have constant rendering of different content that doesn’t require completely reloading the page.

On Schneiderman’s website there is a gallery that displays cascading images, and then when you click on the images, it enlarges it and then will take you to a separate page. And what you can do on the page is click on arrows that act as a slideshow and it gets you to different images. That function of moving through the images meant he had to reload the page every time.

But when he built the same slideshow on React, it was basically instantaneous. The tradeoff was that in order to do it, the page had to load more content up-front. So when the page is first loaded, all the images that you could possibly click on are already loaded, which takes a little longer.

This is as opposed to having one image on the page, then clicking through and sending a request to the backend to get a different image, so it was definitely worth it.

“If you’re planning on implementing anything dynamic on the front end, I would highly recommend looking into React,” Schneiderman said.

There was a lot of JavaScript, mostly interacting with dynamic content. For example, some images are vertical or horizontal, different sizes and proportions. When the page was loaded, Schneiderman wanted certain styling to be as a function of what the sizing of the image would be and of whether the image would be matted or framed.

With Django, there are certain tags where you can access content from the backend in the front end without having to do really complicated queries.

“It’s literally curly brace, percentage sign, and then whatever you named your image in the backend. Very simple,” he said.

Schneiderman recommended using YouTube videos to gain a high-level understanding of a new framework, and StackOverflow to get more granular. Google is also useful, but it’s key to use precise vernacular.

If he was to do the same project again, he likely would have used Bootstrap, which is a powerful HTML, CSS and JavaScript library Schneiderman wanted to use to simplify his CSS. Schneiderman styled the site by hand, and regrets not knowing about Bootstrap before.

Schneiderman, who coaches a middle school basketball team on the side, is now developing an app that helps basketball coaches and players facilitate the team building process. The app is within a website that can diagram and animate the plays. This way, players are able to study and learn plays more effectively and more academically, because the only time players are learning a play is in practice.

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.