https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=WebFund_2024F_Lecture_7 2026-04-22T15:57:19Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=WebFund_2024F_Lecture_7&diff=24760&oldid=prev 2024-10-01T19:15:24Z

<p>Created page with &quot;==Video== Video from the lecture for October 1, 2024 is now available: * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec07-20241001.m4v video] * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec07-20241001.cc.vtt auto-generated captions] ==Notes== &lt;pre&gt; Lecture 7 --------- We&#039;ve got lots of languages on the web - HTML - CSS - JavaScript (client side) - SQL - (server side language, which coul...&quot;</p> <p><b>New page</b></p><div>==Video==<br /> <br /> Video from the lecture for October 1, 2024 is now available:<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec07-20241001.m4v video]<br /> * [https://homeostasis.scs.carleton.ca/~soma/webfund-2024f/lectures/comp2406-2024f-lec07-20241001.cc.vtt auto-generated captions]<br /> <br /> ==Notes==<br /> <br /> &lt;pre&gt;<br /> Lecture 7<br /> ---------<br /> <br /> We&#039;ve got lots of languages on the web<br /> - HTML<br /> - CSS<br /> - JavaScript (client side)<br /> - SQL<br /> - (server side language, which could be JavaScript or almost anything else)<br /> (Python, Java, C#, Ruby, JavaScript)<br /> <br /> All of these are programming languages<br /> - Normally we think of a full &quot;programming language&quot; as a language that is Turing complete<br /> - you can implement a Turing machine in it<br /> - classic model of computation<br /> - but really, a programming language is just a language that can be used to give a computer instructions on what to do<br /> - most config files can be thought of as being written in a programming languge<br /> - more specialized languages are known as &quot;domain specific languages&quot;, or DSLs<br /> <br /> There is a tendency for DSLs to become Turing complete, but generally that is a sign they have gotten too fancy<br /> <br /> A classic strategy for solving problems in CS is:<br /> - define a DSL for the problem space<br /> - create a solution in the DSL<br /> <br /> A programming language is a language for solving problems<br /> - different problems &quot;fit&quot; better with different vocabularies, syntax, semantics<br /> <br /> For example, C has atrocious string handling capabilities<br /> - but you can make it do anything, and people do<br /> <br /> Is a markup language a programming language?<br /> - I would say yes!<br /> - but generally, it isn&#039;t Turing complete and that is okay<br /> <br /> Why do we have so many programming languages on the web?<br /> - because there are many sub-problems to solve!<br /> <br /> When you define a level of abstraction, implicitly you define a language<br /> - you may implement that language using objects or an API, but at its heart it is a language just maybe with bad syntax<br /> <br /> Original idea of web tech:<br /> <br /> HTML - structure, content of a page<br /> CSS - styling of a page, so a language for talking about the style of HTML<br /> JavaScript - make a page dynamic! (drop down menus, scroll views, etc)<br /> <br /> (And this all was served from static pages on the server)<br /> <br /> <br /> But what if we want the server to do computation, maintain state beyond a set of files?<br /> <br /> CGI - common gateway interface<br /> - early form of dynamic web<br /> - standard for programs the server would run on request<br /> <br /> So, when you requested certain URLs, the server would run a Perl program and return its output rather than return a static page<br /> <br /> And then websites became more Perl scripts than files, and so we got Apache keeping the Perl runtime loaded (to make things faster)<br /> - Apache was the &quot;main&quot; web server application for many years, still widely used<br /> - name came from &quot;a patchy server&quot;, it was a set of patches on an earlier web server<br /> <br /> Then we got PHP, a language designed for adding server-side code to HTML documents<br /> - unlike Perl, PHP was created with the web in mind and was designed to be<br /> mixed with HTML in the same program<br /> <br /> <br /> JavaScript was first created as a client side language, but then developers wanted to move code &amp; data between the server and the client<br /> - so why not use the same language on both ends?<br /> - also, JavaScript runtimes got really fast, much faster than Python, Perl, and most PHP runtimes<br /> - that&#039;s how we got node.js and then deno<br /> <br /> <br /> <br /> But JavaScript on the server was part of a big change in how web applications were structured<br /> <br /> What we&#039;ve seen so far is that the server sends HTML, CSS, and soon JavaScript to the client, and the client sends back GET and POST requests, the latter with user data.<br /> <br /> Today, we more send back and forth objects in the form of JSON<br /> - GET, POST, other methods are mostly transport for JSON objects<br /> <br /> It was a twisty path to get here and we&#039;re going to skip over most of the ugly parts (e.g. XML, SOAP mostly)<br /> <br /> The early web was mostly one of a LAMP stack<br /> - Linux<br /> - Apache<br /> - MySQL<br /> - PHP/Perl (earlier more Perl, later more PHP)<br /> <br /> So we haven&#039;t talked about the third, MySQL, i.e., databases.<br /> <br /> MySQL was (initially) a bad but fast implementation of SQL<br /> SQL is an old language of relational databases<br /> <br /> Databases are a solution to an eternal problem - how to manage state<br /> - i.e., how do you manage information that changes over time<br /> <br /> Mostly up until now you&#039;ve dealt with files<br /> <br /> What is the API of files?<br /> - open, read, write, seek, close<br /> - we mostly open a file, read its contents, and then close it...or<br /> - we open a file, write stuff to it, then close it<br /> <br /> But really, they are an example of a hierarchical key/value store<br /> - the key is the filename<br /> - the store is the contents of the file<br /> - the hierarchy is that of directories and subdirectories<br /> <br /> While you can do incremental changes to files, it gets complicated fast, especially if more than one program wants to modify a file<br /> - typically the last writer will overwrite all previous writers<br /> <br /> If you&#039;ve ever seen an editor complain about a file having changed on disk when you try saving, you&#039;re seeing the risks of multiple concurrent editors of a file.<br /> <br /> Files are great as long as they are mostly being read, or there is clearly only one writer at a time.<br /> <br /> This is NOT the situation with a dynamic web server!<br /> - every requesting client could potentially require changes to stored data<br /> - 1000 web browsers all contacting the same web server, sending POST messages<br /> is entirely realistic<br /> <br /> This was a really big problem with early web servers because every incoming request was handled by a new process<br /> - followed a &quot;fork on request&quot; model<br /> - later turned into &quot;new thread on request&quot; or &quot;thread from threadpool&quot; model<br /> <br /> (Think about this more for COMP 3000)<br /> <br /> Don&#039;t confuse how we test web apps with how they normally run<br /> - won&#039;t just be on localhost<br /> - won&#039;t just have one person accesing them<br /> <br /> SQL (structured query language) is a language designed for interacting with relational databases<br /> - relational databases were first developed in the 1960&#039;s<br /> - so when the web arose in the 1990&#039;s, was already and old and mature tech<br /> - web developers took it off the shelf and used it for their own purposes<br /> <br /> Relational databases were originally created for businesses &amp; govt, storing data on people, money, etc.<br /> <br /> <br /> Key data structure in relational databases is a table<br /> - rows and columns<br /> - columns are fields (categories), e.g. name, address, etc<br /> - rows are the values of the fields associated with a specific record<br /> - an individual row is a record<br /> <br /> You can think of it as a spreadsheet sheet, and indeed spreadsheets can be accessed as databases<br /> - but have to have a rigid structure of labeled columns<br /> <br /> But where does the &quot;relational&quot; come in?<br /> - relations are connections between tables<br /> - an invoice table may have a relation with a customer table<br /> - the invoice just has a customer ID<br /> - to get all the info on the customer, look in the customer table<br /> - thus, invoices won&#039;t duplicate customer information<br /> <br /> When you retrieve data from a database to build a report, you&#039;ll incorporate data from multiple tables using relations to get a coherent view<br /> <br /> SQL is the common language for accessing and manipulating relational databases<br /> - THE standard<br /> <br /> So we&#039;re going to do VERY BASIC SQL in this course<br /> - take 3005 to learn more about databases!<br /> <br /> Since it is a standard, there are many implementations of SQL, many database engines<br /> - Oracle<br /> - IBM DB2<br /> - MS SQL Server<br /> - AWS, Azure, Google Cloud have multiple database offerings<br /> - many other cloud DBs<br /> <br /> - MySQL, MariaDB &lt;--- forks<br /> - Postgres (open source successor to Ingres)<br /> - become the standard API that cloud databases emulate<br /> - SQLite<br /> <br /> SQLite is not like the rest<br /> - in-process database<br /> &lt;/pre&gt;</div>

Soma