The Big Picture

Lesson 1: Servers

POST versus GET

As far as I’m aware POST requests are also capable of being used to send much more data than a GET request anyway and the data sent to the server doesn’t need to show up in the URL like a GET request does. Because a GET request doesn’t rely on information being changed, they can be Cached, which means the server stores a pre-calculated copy of the page to be sent to users instead of running any complicated rendering code each time someone requests the page. Because POST requests are all about sending data to a server with the intent of changing the server, POST requests cannot be cached.

Whatever

Hey there

What is a server?

A Server in one sense is simply a computer configured to send information to other computers. The key difference between a server and a client computer is what is done with the data.

POST

The other main request is the POST request. This request sends data to the server with the intention that the server will store that data in some useful way. It is possible for the server to store data sent to the server using a GET request, but this can usually lead to problems.

HTTP Response Headers and Codes

Responses come with some general information and headers as well. First there’s a response code, which gives a general indication as to how the request went. Three common ones are: 200: OK, 404: Not Found and 500: Server Error. The number can be used by programs to quickly identify how things went where the text gives a human an easy indication. Headers generally contain similar information as request headers but in the other way around. For example the Server header gives the client some information about what server software generated the response.

GET

With the web, the primary way servers and clients talk to each other is using HTTP requests. A client will usually send a GET request to the server, asking for a particular URL. Then the server will send back a response. If the URL is valid and nothing else goes wrong, the client will receive the data they requested, if something is wrong, they will receive an error of some kind.

Lesson 2: The Importance of Validating Input

Why Validate: Get the data you ask for

The second biggest and often more obvious reason is to avoid making a mess of the data and causing bugs. If you need someone’s name in a form and they don’t provide one, at best this will result in a weird looking profile output, but usually it would cause bugs to happen.

Why Validate?

Security is the biggest reason to validate input, it is possible for malicious code to be inserted into a web page if a user sends in html code that the website redisplays.

What is Validation?

Making sure the information you need is the information you get. That’s what validating input is. So exactly how to validate input depends on the situation. It should always be done on the server regardless of any checks done on the client.

Validation is boring, so remember to do it!

Validating input is not the easiest thing to do and it’s one of the most time consuming things to do so it’s especially important to make an effort to program it in.

Lesson 3: HTML Templates and Abstraction

Template Engine: Jinja2

HTML template engines such as jinja2 provide a very clean way to describe the overall layout of a web page and then fill it with content. The templates provide the abstraction, while the specific content sent in to the template render for each request makes things interesting.

Abstraction Basics

To revise on the concept of abstraction: it’s the skill of noticing similarities and repetitive elements and separating them from specific uses so that less code needs to be maintained. It is possible to go too far into abstraction and end up making the code worse, so it’s still more of an art form than a hard science.

Templates and Debugging

In addition to making it easier to maintain a website. Templates also make debugging easier. Because if you make a mistake with one of the templates it has a tendency to break all of the pages in some way, which makes it less subtle that things are wrong. The net result is even less time spent working on the templates.

Template Inheritance

On top of that templates often provide template inheritance, meaning common elements no longer have to be retyped up in each template, but only one parent template that all the other templates inherit from. This is very similar to how css files allow style information to be separated from the structure of a page and provides the same advantage: change just the parent template and the children templates change too without any further work from you the programmer.

Lesson 7

Stage 5: What I learned

3: What I learned from Intro to jQuery

I still don’t know a huge amount about web development, I don’t yet know how to manipulate the DOM without a helper library and it’s probably a good idea that I do that at some point. But what I did learn was that jQuery is a small library that I can use to make it far better to work with the DOM. I know how to select elements, add elements, remove elements, modify elements (add classes to them so they get styled). I’m reasonably confident that I know all the basics of jQuery to the point I can create a useful web application and that I can go find out anything else if I want to get particularly fancy. On top of that I learned of the existence of d3 (data driven documents), which is very similar to jQuery and have begun studying that. It’s good to have options.

2: What I learned from JavaScript Basics

JavaScript basics gave me plenty of practice to transfer over my knowledge of programming in Python (which I learned earlier in this Udacity course). It didn’t get too much into the object oriented programming side of things but it turns out in order to do useful things in JavaScript that’s not really all that important. Things went pretty smoothly in this part as I learned how JavaScript doesn’t use tabs and newlines to structure it’s code and instead uses {} blocks for functions and ; to separate the statements. One thing that I found to be a bit odd was the for-in loop doesn’t give me an object to work with but rather an index which I can use to refer to the object I want. It seemed a bit silly to not be able to just use the object. Perhaps a lack of knowledge on my part or perhaps a language limitation, not that big of a deal in the end as long as I can access object data. That for-in loop thing did cause me to make a bunch of mistakes though, nothing that wasn’t solved by some thinking and debugging.

5: d3js - Data Driven Documents (extra 1 of 2)

https://d3js.org/ While I was going through the three courses on Udacity (javascript, jQuery and AJAX), I was introduced to d3.js. d3js, or data driven documents, interests me a lot. It’s a javascript library similar to jQuery in that it’s a library that provides a framework for manipulating the DOM. But it has an emphasis on taking datasets and transforming them into a visual representation. It also provides animation and some AJAX functionality. I haven’t learned enough about it to do anything useful yet but I intend to learn as much about it as is reasonable and create animated web applications with it.

4: What I learned from Intro to AJAX

I’ve heard about AJAX before but never really known what it is exactly. Turns out it isn’t anything exactly. AJAX is the name that refers to a bunch of programming techniques used by developers to get their websites updating their data without requiring a page refresh. This is exactly what I wanted to hear as the web applications I want to make basically demand that functionality. Aside from that I didn’t look hugely into the AJAX presented in the course as it wasn’t specifically what I was looking for, but I did find d3js at some point when exploring these courses…

1: Overview of what I’m trying to achieve

I decided to pick the front end options as I want to create pretty graphical user interface tools. This meant exploring javascript, jquery and ajax through the provided Udacity Courses.

6: Mozilla Developer Network - MDN (extra 2 of 2)

https://developer.mozilla.org/en-US/ The MDN is not the nicest documentation to navigate, but then again, I’m not sure I’ve ever read any documentation that was great to navigate. What it does offer is a good enough rundown of whatever feature regarding html, css or javascript I need to find out. MDN seems to be comprehensive enough that I haven’t become confused reading it. I’m sure it’ll be a while before I ever find a replacement source of general web technologies documentation. I’ve been using the JavaScript documentation the most to supplement my studies of d3js, as it’s far better to know what all the words mean when reading a tutorial on a javascript web technologies library such as d3js.

test

\& testing <b>bold</b>