[More work. Tony Garnock-Jones **20050904142336] { adddir ./slides adddir ./slides/KeepingWebsitesAlive addfile ./slides/KeepingWebsitesAlive/KeepingWebsitesAlive.tex addfile ./slides/KeepingWebsitesAlive/Makefile addfile ./Notes.html addfile ./outline hunk ./Notes.html 1 + + + + + + +TiddlyWiki + + + + + + + + +
+
+ + + +
+
+
+
+
+
a reusable non-linear personal web notebook
+
http://www.tiddlywiki.com/
+
TiddlyWiki
+
[[Introduction]]
+
From http://www.lshift.net/:\n\n"LShift is a pure technology company with experience of developing complex solutions for large companies.\n\n"Our sole aim is to deliver the most suitable technology for your business. We don't just look at the technical brief, we look at the overall solution. We achieve our high standards by hiring only the best & most experienced people in the industry.\n\n"In short, LShift will offer you a speed and quality of technical solution you won't be able to find elsewhere."
+
\n[[Introduction]]\n\nTiddlyWiki\nTonyGarnockJones\nLShift\n\n<<newTiddler>>\n<<newJournal "DD MMM YYYY">>
+
I work for LShift.\nmailto:tonyg@lshift.net
+
Type the text for 'Introduction'
+
+ + hunk ./outline 1 +-*- outline -*- + +* Main outline + +** What is Content Management (CM)? + +*** set of design principles; a toolkit +*** off-the-shelf products +*** a way of relating to the customer + +** When is it appropriate? + +Rough rule of thumb: when you want to present the same information in +more than one way; or, when the work involved in hand-rolling the +presentation of the information starts to get bigger than the work +involved in building a generic information-presenting program. + +** Off-the-shelf, or DIY? + +*** Choosing a CMS + +**** the database is key. The information is king +**** presentation is a distant second +**** do you have live objects or dead data? (?) + +** Keeping Sites Alive - tips ideas and pitfalls + +** How to make sure a site grows as its parent organisation grows + +*** refactoring +*** keep the level of abstraction right + +** Building a simple CMS in ASP + +* Things I want to cover + +Reflection - the meaning of a set of information is partly in the +information itself, and partly in the interpretation of the +information. (Reduction-ad-absurdum cases?) + +Your databases are valuable, right? The value in the website stems +from the information in the database. Need to keep the information in +a readily-accessible format. + +Vital that the data itself, and management of the model, is kept +totally separate from view- and controller-related aspects. Introduce +MVC, mention Smalltalk, Java, Swing, modern web frameworks. + +Databases - denormalised, normalised; normalizing +information. Relational DBs are a badly-engineered hack on an elegant +piece of maths, plus industrial-strength concurrency control (ACID +properties). A denormalized database is OK, but when it needs +changing, refactoring is really important. You can normalise a table +and replace it with a view, modulo insertion. Adding a column to a +denormalised table means you have to alter each query that references +that table; normalised databases don't have that problem. + +RDF - frame representation. Graphs. The neat trick is the standardised +metadata: you can describe edge categories. An extension to RDF lets +you annotate individual edges, too. + +Access control, permissions. Capabilities, ACLs. + +Change tracking. Publishing changes as RSS. + +Choosing an interpretation of the data. When you present the +information in the database to the user, you're choosing an +interpretation. Make sure the level of abstraction fits the intended +communication - even if the representation of the information is more +low-level. + +Use the tools your language gives you to work at the correct level of +abstraction. No point in grovelling over a set of tables when you +could give a high-level query. HL queries free you from the +representation, so you can change it later if need be. When using SQL +databases, views and stored procedures can help isolate you from +changes in representation. + +Wikis - the wiki markup can be seen in two different ways: as a set of +instructions for spitting out HTML tags, or as a description of an +HTML document. It's both data, and program, for a simple HTML-oriented +DSEL. + +Your job is to choose an appropriate level of abstraction for your +domain, and to design a little language for talking about and +manipulating objects in the domain. Your server-side scripts will then +use this little language. Languages can scale from a simple set of +subroutines through to a full-blown programming language with its own +syntax, semantics and IDE. + +If there's not a great mismatch between your domain language and the +language implemented by an off-the-shelf CMS, you can wedge your +application in there. This is called encoding - you encode your domain +language in someone else's domain language. Usually CMSs don't have +good support for automatic encoding, so you have to do it by +hand. Beyond a certain level of mismatch it becomes cheaper to write +your own tool: either to encode into another CMS' domain, or to manage +your domain directly. + + +* Excerpts from Emails to Rachel from me + +Mikeb and I sat down and had a chat about the workshops the other day, +and came up with a few ideas and a few questions. We don't really have +any idea what level the students will be up to, but we thought perhaps +to compare and contrast a few different CMSs, looking at the +separation of concerns in design and implementation. We thought it +would tie in with the theme "Keeping Websites Alive" by emphasising +the structured data kept at the back-end of each CMS, and the +separation of the data itself from the layers of processing and +rendering for display. We might also briefly mention +RSS/RDF. Obviously, given our technical focus, we'll try to stick to +the *technical* side of keeping sites alive rather than the *marketing* side! + +Mikeb mentioned there were coursenotes for the year he taught the +workshops: are there any for this year? We looked at the wiki but +couldn't find anything obviously intended for 2005. + +* Excerpts from Emails from Rachel + +** Hardware in labs + +iMacs. Tried to get PCs in to no avail, sadly. + +** Software on Macs + +Dreamweaver. + +** Server capabilities + +Each student has their own virtual server which they can use for ASP +projects. + +For some reason I couldn't get the Access drivers to work on them, so +we have been using text-based databases, which have worked well for +small projects. + +** Student capabilities + +I have taught them XHTML and CSS. + +They know enough ASP 3.0 to be getting on with (I know it's an old +technology, but it's the only one cheap enough to give each student +their own managed server, and it's the principles of server-side stuff +I want them to get their heads round, not one particular technology.) + +They know the prinicples involved in flat-file databases and SQL +statements etc, but I haven't taught them much about the relational +side of things. + +They have also had about 16 hours teaching in Actionscript 1.0 so +Javascript will not be totally foreign, hopefully, but we're not +talking tech-heads here. + +** Excerpts from the original email from Rachel to Andy + +Following our conversation, here's a bit more detail about what I and +the students would like you to cover / explore. We have a budget for +15 hours worth of teaching, so there's a reasonable amount of room +there, although like with most of these subjects I teach, I know you +could probably to an MSc in it and still leave wanting more. + +I have now taught the students some ASP, not because it's the best +technology (not by a very long way) but the cost of hosting it has +allowed us to provide each student with their own sandbox server, +something which other courses would be unable to do with a server-side +technology. So they understand the principles now of dynamic sites, +but I think they need to be taught and shown: + + - Intro to the principles - what is CM and is it appropriate for a given + problem? + + - Off-the-shelf or DIY? + - Keeping sites alive - tips, ideas and pitfalls + - How to make sure a site grows as its parent organisation grows + - The build - a simple CMS in ASP + +The reason we're doing this is because the students said to me 'we +want to know about how to make it easy for clients to update their +sites' and I said, ahah, you mean CMS. So here we are. hunk ./slides/KeepingWebsitesAlive/KeepingWebsitesAlive.tex 1 +%% +%% INSTRUCTIONS FOR COMPILING THIS DOCUMENT +%% +%% Choose one of the two ``documentclass'' declarations below. +%% Use the ``ps'' one for printing; and the ``pdf'' one for an +%% online slideshow PDF format. +%% +%% You will need a tarball of the ``prosper'' software untarred +%% into a directory called ``prosper'' in this directory. You +%% can download prosper from prosper.sourceforge.net. +%% +%% +%%\documentclass[ps,azure]{prosper} +\documentclass[pdf,slideColor,azure]{prosper} + +\hypersetup{pdfpagemode=FullScreen} + +\title{Keeping Websites Alive} +\author{Tony Garnock-Jones (tonyg@lshift.net)} + +\date{September 2005} + +\begin{document} +\maketitle + +\begin{slide}{Introduction} + This talk will cover + \begin{itemize} + \item An introduction to process languages + \item Applications + \end{itemize} +\end{slide} + +\part{Introduction to Process Languages} + +\overlays{5}{ +\begin{slide}{What is a process language?} + A {\bf process language} describes a group of simultaneously + executing programs and how they communicate. + + \begin{itemstep} + \item Parallel -- not sequential + \item Allows solid reasoning about concurrency + \item Strong mathematical foundations can allow you to {\bf prove} + that your program behaves in certain ways + \item This is something traditional languages are poor at -- using + threads is a nightmare; no math in sight! + \item Not a panacea -- deadlock still possible, etc. + \end{itemstep} +\end{slide} +} + +\part{The End} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +\part{Backup} + +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% + +%% \overlays{1}{ +%% \begin{slide}{} + +%% \begin{itemstep} +%% \item foo +%% \end{itemstep} +%% \end{slide} +%% } + +\end{document} hunk ./slides/KeepingWebsitesAlive/Makefile 1 +TARGETS=KeepingWebsitesAlive.pdf + +TEXINPUTS:=$(TEXINPUTS):./prosper:./prosper/img + +LATEX=TEXINPUTS=$(TEXINPUTS) latex +DVIPS=TEXINPUTS=$(TEXINPUTS) dvips + +%.eps: %.dot + dot -Tps -o $@ $< + +%.view: %.eps + gv $< + +%.view: %.ps + gv $< + +%.pdfview: %.pdf + acroread $< + +%.xpdfview: %.pdf + xpdf $< + +%.ps: %.dvi + $(DVIPS) -o $@ $< + +%.pdf: %.ps + ps2pdf13 $< + +%.dvi: %.tex + -$(LATEX) "\\batchmode\\input{$<}" + -$(LATEX) "\\batchmode\\input{$<}" + $(LATEX) $< +# Three is a magic number. + +%.force: %.tex + -$(LATEX) "\\batchmode\\input{$<}" + -$(LATEX) "\\batchmode\\input{$<}" + -$(LATEX) "\\batchmode\\input{$<}" + $(DVIPS) -o $*.ps $*.dvi + gv $*.ps + +all: $(TARGETS) + +clean: + rm -f KeepingWebsitesAlive.{aux,bbl,blg,idx,log,toc,dvi,ps,pdf,out} + +.PRECIOUS: %.pdf %.ps %.dvi }