Task B: Knowledge Exercise

This second part is a rehash of the things that are going to make up our Drupal installation, and things that we need to consider while doing it.

Markup, Markdown?

Markup in context of web development is basically, marking up.

You didn’t quite understand that? I’ll elaborate. Markup is a way of annotating text in such a way to enable programs to use that information. Take a look at this:

Unrelated, but peanut butter is really resilient against the dishwasher. (Public Domain)

Aside from being introduced to a bunch of tags you don’t know are used for anything meaningful, these annotations in the form of angle bracket tags instruct whatever software is reading it to process it (and usually to not show it to the user).

HTML is one such example of markup, and the tags they use like <p>, <h1>, and <picture> tell the browser to layout and render the HTML in a particular way. Your paragraphs come out as paragraphs, your headings come out as headings, and your pictures are pictures. So let’s move on.

Server Side Language: What you weren’t meant to see

Server side languages power a lot of the dynamic nature of the web. From Rails, to PHP, to Node.js, there’s so many languages you can shake a stick at! So what is it?

Well, it’s basically scripting, but in such a way that every user that then accesses it gets a tailored response, rather than a static page (going back to plain HTML). By leveraging the features of our language, the server can deliver a page that handles content posting, authentication status, even make financial transactions!

This is different from Client Side Languages like JavaScript, in that it runs on the client rather than the server, and thus why using a Server Side Language might be a bit more attractive, especially if you’re storing and handling user data. But that comes to the next point:

Security in the world of server-side languages

Security is one of those things that you typically find being put on the wayside when there’s a deadline to fulfil, or there’s money to be saved. But it’s very important to consider security in a web application.

Let me reiterate. Security is very important.

Every part of the infrastructure running your web app can be considered an attack surface. Let’s go over them in a general order:

• Location
• Hardware
• Kernel/OS
• Installed Software
• Your Web App

All these things have one thing in common: They all have potential vulnerabilities.

Run your server from home? Hardware that can’t be audited? Old version of Windows? These are all vulnerabilities. And this is before we get to the server stack running your app.

So if you’re the type of person who’s paranoid and decides to go the static site route, you have all of this, then your web server. This too is also an attack surface.

But after that, if you want to use a server side language on top of that, that too is also a vulnerability.

BUT EVEN AFTER THAT, your web app is also an attack surface! Poor coding practices and unseen bugs can lead to loss of data, or worse, being expelled:

Comic by Randall Munroe / CC BY-NC 2.5

A CMS might be a good idea if you need to go a step up from static pages. Ideally you want to pick something that undergoes security audits, well supported by the community, and is pretty stable. Just remember you need to address all those other points as well. It’s no good having a well coded web application if an attacker can walk right in and take your computer!

Whew. Let’s step back and take a look at a different topic.

Accessibility: that’s a pretty high percentage you’ve got there

As of May 22 2017, the Australian Bureau of Statistics estimates Australia’s population to be around 24.5 million people. Of that, it is believed over 4 million have some form of disability. This includes physical, mental, and sensory impairments.

You might think that making websites accessible doesn’t really matter. But try telling that to your client that you’ve decided to disregard 16% of potential customers/sales just because you didn’t want to put in the effort.

These people make use of various technologies in order to access web pages. For the visually impaired, they may use screen-reader software in conjunction with the keyboard to read and navigate around pages. For the deaf and hearing-impaired, they may depend on transcripts and captioning to interpret imagery, audio and video.

Hence it is essential when developing a website to consider accessibility throughout the development process, and not just as an afterthought. And this doesn’t apply just to the website design, but also its content.

But anyway, that’s all from me. See you next time!