I've had some experience with the LaTeX document typesetting system before, having used it quite a lot during university for my final project's reports and presentation. I used the beamer package before, but this time I found its styles too restrictive. The three major presentation packages that I'm aware of are prosper (which I believe is quite old now), beamer, and powerdot. After some investigation (looking primarily at features and visual styles), I settled for powerdot. I will explain the basics of putting a presentation together in the rest of this post, but be warned: it assumes some basic familiarity with LaTeX, and I don't explain everything!

Starting out

The first steps when creating a slideshow are different to a regular document. In standard LaTeX, you open the document and just start writing, adding part, chapter and section headings as necessary. Creating a presentation is necessarily different. Here is a skeleton presentation:

\documentclass[style=paintings]{powerdot}

% Presentation metadata

\title{My First Powerdot Presentation}

\author{Joe Bloggs}

\date{8th November 2010}



\begin{document}



  % title slide

  \maketitle



  % section: title takes up full slide

  \section{First section}



  % text slide:

  \begin{slide}{Slide Title}

    \begin{itemize}

      \item This is an item

      \item This is also an item

      \item Finally, a third item in my list

    \end{itemize}

  \end{slide}



\end{document}

Doesn't look too bad, right? The presentation is contained within the document, and each slide is contained within a slide environment. The \section command now builds a standalone slide, as does the initial \maketitle.

Almost anything that you can include in a normal document can be used on a slide, including tables and images, and tricks like using \vspace{\stretch{1}} at the beginning and end of the slide to vertically centre the content.

Progressive disclosure

Powerdot allows you to show only parts of a slide to your audience at a time, to emphasise each point (for example), or to better illustrate the flow through a diagram. This can be accomplished in two ways: the simple \pause command, or the more complex and more powerful \onslide.

The simple \pause command takes no arguments, and simply stops anything in the slide after that command from appearing, as if content display had been "paused" at that point. It is important to note that everything following the command is typeset, in order to work out the space it would have taken up. This ensures that your slide content doesn't shift around as you go through.

\begin{slide}{Progressive Disclosure}

  \begin{itemize}

    \item This is my first item

    \item This is the second item, after which we wait \pause

    \item The third item appears on the page following the second \pause

    \item And this fourth and final item appears on the page after the third

  \end{itemize}

\end{slide}

Note that the command can be used multiple times, and it will work just as you might expect. If you want to do something more complex (such as displaying things out of order, displaying something over multiple frames, or scoping a change to a subset of the frames) you will need to use \onslide.

This command is much more powerful, and takes two arguments: the frames on which the contents should be displayed, and the contents themselves. The example above could be rewritten:

\begin{slide}{Progressive Disclosure}

  \begin{itemize}

    \item This is my first item

    \item This is the second item, after which we wait

    \onslide{2-}{\item The third item appears on the page following the second}

    \onslide{3-}{\item And this fourth and final item appears on the page after the third}

  \end{itemize}

\end{slide}

But we could also (in theory) choose to do something more bizarre:

\begin{slide}{Progressive Disclosure}

  \begin{itemize}

    \onslide{4-}{\item This is my first item, and the last to appear}

    \onslide{3-}{\item This is the second item, although technically the third}

    \onslide{2-}{\item The third item appears on the page following the fourth}

    \item This fourth and final item is actually the first that is visible

  \end{itemize}

\end{slide}

The \onslide command has three variations. The first version, as shown above, allocates space for items that have not yet been displayed. If you add a star to the command before its arguments (\onslide*) then no space will be allocated. In the example above, this means that the new bullet points would appear to push the existing items downwards. If you add a plus to the command (\onslide+) then the contents will always be typeset, but a different colour will be used for the item on the specified slide(s).

I have found \onslide* to be particularly useful for progressive disclosure of diagrams, where not displaying an item at all can be very important.

Graphics and diagrams

It is important to remember that LaTeX itself will only accept graphics in EPS format via the \includegraphics command from the graphicx package. pdfTeX will allow other formats if used directly (including PNG) but something like pstricks may then become unusable. For my presentation, I used a combination of pstricks diagrams and included EPS images.

Building diagrams in pstricks gave me a major advantage that I had not foreseen: the ability to define and then re-use a picture. I used this to good effect with the diagram of the OAuth "dance", showing the data flow between the User, Consumer, and Provider. When it came to the code samples for the implementation, I kept a miniature of this diagram on each slide to remind the viewer which stages of the dance were covered by the code on the current slide. This would not have been possible to do with OpenOffice (as far as I'm aware), and it saved me a great deal of time when I made changes to the original diagram.

If you have never used pstricks, then I highly recommend it. Although it may seem weird to specify co-ordinates in a text file rather than drawing the image graphically, it is extremely powerful and I found that I soon got used to it. It is worth remembering that some programs, like Inkscape, can actually save a vector image as a set of pstricks macros.

Code samples

Something that's often important when building a technical presentation is including one or more code samples. It's usually nice if they are syntax-highlighted in one way or another, to make it easier to read at a glance. By the way, it is generally advised that code samples in a presentation should be dark-coloured text on a light background rather than the other way round.

When it comes to using code samples in powerdot presentations, there are two things to be aware of. Firstly, choosing the typesetting package. I have always used the listings package for code samples. It has support for a large number of languages (as well as defining your own), and it is very configurable. You can even define short-cut environments for re-using options if you are working on a multiple-language presentation, for example.

The second thing to remember when adding listings to the presentation is that you need to inform the powerdot package that a slide has special "verbatim" content. This is done with an optional argument to the slide, method. This has three possible values (normal, direct, and file), but I have only found the first two to work reliably.

If the slide contains verbatim content, you must use either the direct or file rendering method, otherwise you will get an error. The file method can easily get confused (in my experience) and so I used direct. The downside is that you cannot use the \pause or \onslide commands in a direct-rendered slide; they will be silently ignored.

\begin{slide}[method=direct]{Hello World in C}

  \begin{lstlisting}[language=c,gobble=4]

    #include <stdio.h>



    int main(int c, char **v) {

      fprintf(stdout, "Hello, world!\n");

      return 0;

    }

  \end{lstlisting}

\end{slide}

Choosing and customising your style

The visual style of your presentation can make a difference to how it is received. Dark text on a very light background is usually considered to be the most readable. The powerdot package has a number of built-in styles (pp. 21-25), and I eventually settled on a modified version of paintings with the Charon palette. Creating your own style is not difficult, and you have a large amount of control over how it looks. I won't go into it here, as it is already well covered by the manual.

And finally...

This is all very much a work in progress. This post was based upon my first experience of writing a presentation in LaTeX with powerdot. As time goes on, I hope to build upon and standardise a visual style for both personal and company presentations. I am also prepared to send the LaTeX sources of my OAuth presentation to anyone who is interested, so please let me know either in the comments below or contact me by email or Twitter.

For me, the biggest advantage of LaTeX is that content comes first -- it's much easier to write a presentation without obsessing over how it looks until the very end. The better-defined your visual style, the less you have to worry about the design, and the more time you can spend making your presentation great!

Apache module

The first thing I have in mind is to create an Apache 2.2 module that uses the APR (Apache Portable Runtime) to make configuration file templating easy.

On my server, there are a lot of very similar Apache configuration files. At the moment, they are semi-automatically generated by running a Perl script that reads the configuration from a database and then creates the output files as required. This is all well and good, but changing anything requires running the Perl script, regenerating all of the configuration files, then prodding Apache to reload its configuration. There has to be a better way, especially one that doesn't require elevated permissions like that.

Enter my proposed solution: mod_sqltemplate. This module will add a few extra settings and (at least) two extra sections to the standard Apache configuration. The propsed features are:

• SQLTemplate_DBDriver «driver» – sets the APR driver to be used
• SQLTemplate_DBOpts «option-string» – options for the driver (e.g. database name, username, password...)
• SQLTemplate_Caching «on|off» – enable/disable configuration caching
• SQLTemplate_CacheDir «path» – directory in which to save cached configurations
• <SQLRepeat «query»> – new section, as described below
• <SQLCatSet «sep» «query»> – new section, as described below

SQLRepeat

The SQLRepeat section is probably going to be the most-used new directive. It provides templating functionality similar to mod_macro, although the template variables are taken from the column names of the query rather than being explicitly specified. The section will then be repeated for each row of the resultset, substitutions occurring as required.

Perhaps an example would help:

<SQLRepeat "SELECT id,hostname,domain FROM apache_hosts">
<VirtualHost *:80>
  DocumentRoot /var/www/${hostname}.${domain}
  ServerName ${hostname}.${domain}
  # ...
</VirtualHost>
</SQLRepeat>

For this example, I've avoided the configuration directives for clarity, assuming they are specified elsewhere. Supposing the database table contains simply:

Then this will expand to be equivalent to:

<VirtualHost *:80>
  DocumentRoot /var/www/www.example.com
  ServerName www.example.com
  # ...
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /var/www/test.example.com
  ServerName test.example.com
  # ...
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /var/www/yourhost.somewhere.local
  ServerName yourhost.somewhere.local
  # ...
</VirtualHost>

And so on. These sections can be nested, so if you wanted to store a list of aliases as well:

You could use something like this:

<SQLRepeat "SELECT id,hostname,domain FROM apache_hosts">
<VirtualHost *:80>
  DocumentRoot /var/www/${hostname}.${domain}
  ServerName ${hostname}.${domain}
  # ...
  <SQLRepeat "SELECT alias,target FROM apache_aliases WHERE hostid=?" ${id}>
    Alias "${alias}" "${target}"
  </SQLRepeat>
</VirtualHost>
</SQLRepeat>

which would then expand to:

<VirtualHost *:80>
  DocumentRoot /var/www/www.example.com
  ServerName www.example.com
  # ...
    Alias "/icons" "/var/www/_share/icons"
    Alias "/example" "/var/www/_share/foo"
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /var/www/test.example.com
  ServerName test.example.com
  # ...
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /var/www/yourhost.somewhere.local
  ServerName yourhost.somewhere.local
  # ...
    Alias "/bar" "/var/www/_share/foo"
</VirtualHost>

So far, so good. Something to note is that the variable names above did not conflict. If we had included "id" in the list of columns for the inner SQLRepeat, then included ${id}, the module should use the innermost scope. Disambiguation should be obtained by table alias prefixing (e.g. ${apache_hosts.id} or ${apache_aliases.id}). Full variable names should always be specified for clarity. This also shows that if the query returns no results, the repeating section is not included, as you would expect. Also note that queries that use variable substitution should use the prepared statement format, with variables specified afterwards. Variables will be included directly, so anything that might contain spaces must be quoted.

However, there are some directives like ServerAlias that must be specified once with a list of space-separated values. Enter SQLCatSet...

SQLCatSet

This acts in a similar way to SQLRepeat, but it concatenates all of the results for each field before substituting, and it includes its content at most once. If there are no results for the query, then it will not include its content. For example, with a server aliases table like:

You could use something like this:

<SQLRepeat "SELECT id,hostname,domain FROM apache_hosts">
<VirtualHost *:80>
  DocumentRoot /var/www/${hostname}.${domain}
  ServerName ${hostname}.${domain}
  <SQLCatSet " " "SELECT alias FROM apache_server_aliases WHERE hostid=?" ${id}>
    ServerAlias ${alias}
  </SQLCatSet>
  # ...
  <SQLRepeat "SELECT alias,target FROM apache_aliases WHERE hostid=?" ${id}>
    Alias "${alias}" "${target}"
  </SQLRepeat>
</VirtualHost>
</SQLRepeat>

which would then expand to:

<VirtualHost *:80>
  DocumentRoot /var/www/www.example.com
  ServerName www.example.com
  # ...
    Alias "/icons" "/var/www/_share/icons"
    Alias "/example" "/var/www/_share/foo"
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /var/www/test.example.com
  ServerName test.example.com
    ServerAlias test2.example.com test.example.net
  # ...
</VirtualHost>
<VirtualHost *:80>
  DocumentRoot /var/www/yourhost.somewhere.local
  ServerName yourhost.somewhere.local
    ServerAlias *.somewhere.local
  # ...
    Alias "/bar" "/var/www/_share/foo"
</VirtualHost>

This would seem to cover the major functionality needed for automatically generating configurations in a really flexible way, although I'm sure more will probably be needed at some point... like SQLIf, perhaps.

PHP Framework

It occurs to me that having a framework's code in PHP itself could mean that it is quite slow. It would be interesting to put together a framework in C and embedded as a module, to see if there are any memory/speed improvements possible. It might just be a case of implementing an ORM (Object Relational Model) system to begin with. Obviously, this idea is nowhere near as fully-formed!

• More on Partis and its future
• A web service integration API proposal
• A PHP system to make it easy to plug together a load of code modules for rapid development
• Not to mention some others which are too fleeting or too vague to pin down yet

Partis

Partis is the name of a project I had originally planned to put together many years ago when I started university (back in 2004!).

The basic idea was to create a P2P system that worked internally on networks using IP multicast for peer discovery, which also allowed browsing and cross-network searches. It would provide bandwidth limitations, both in terms of speed and amount, as well as dynamic limits (e.g. 500KB/s for the first 300MB downloaded, then 50KB/s thereafter).

While I think this is still a good idea for places like the halls networks (where we were limited to 5GB bandwidth per 24 hours) I have decided on a better direction for the project, which is something almost completely different: distributed backup.

I don't want to talk about Partis too much in this post, as I want to discuss other things too, but I will note down some of my ideas and things that have come out of discussion with others.

Changing Partis to a distributed backup solution came from a fairly selfish beginning, as have many of my ideas. If I want to put a system together because I'll find it very useful (and perhaps indispensible) then perhaps other people will think the same. When I was getting ready to begin my final year project, I wanted to be paranoid about my work. I wanted to guard against losing it in any conceivable way:

• Hard drive or computer dying or becoming corrupted or destroyed
• Losing a USB stick
• Accidental deletion/overwriting
• Malicious tampering
• Theft
• External server failure (e.g. Department of Computing or my own server), although highly unlikely

So after considering all these options, I thought it would be great to create a distributed P2P-style backup solution. Sadly I haven't had the time to do this, but the basic idea for myself was to use the fact that many of the computers in the Department have an empty partition that is about 20GB in size. If I could use that space to store my data and redundantly distribute it across multiple machines (to account for failures/reformats/reinstalls, computer being off or in Windows or otherwise inaccessible, etc) then I would feel a bit safer. And of course I could use some spare space on my housemates' computers, and maybe my home computer, and my server, and some other friends around the country or even the world...

The data would have to be encrypted, of course, as I wouldn't want just anyone reading it, and there would have to be checksums to guard against modification or corruption. I quickly realised that this project was something that I wouldn't have the time to undertake in parallel to my Masters project, and that it might have made a viable alternative. Then of course, there's the possibility of storing versioned copies of files, and the question of how to distribute everything, and so forth.

Then it hit me that other people would find this useful. Surely most students would want to have a gigabyte or more of redundant, safe storage? Then this creates and solves the problem of finding enough space at the same time. As a potential business model, for example, people could have 1GB of free storage by offering 3-5GB of their own disk for usage by the network.

There would be different storage tiers based on host reliability (uptime/online time/connection speed/etc) and so on. It would perhaps be possible to charge a premium for upper-tier storage (i.e. things you'd need to be able to recover ASAP) as opposed to lower-tier storage (data that you want safe but you don't need immediate access to, e.g. family photos), with varying prices depending on the service you offer to others. The better the service you offer (the more you put in), the better you get (the more you get out). Of course, those who don't want to contribute their resources to the network (or can't do so) would be able to pay for some centralised storage.

It's not just individuals who could use this system, however. Think about companies with large numbers of desktop machines in geographically distinct locations. Bump up the redundancy factor and it could be licensed as an alternative off-site backup solution. Archived data could be distributed across employees' desktop computers, using a percentage of the disk space that would otherwise just be sitting idle. For a fee.

Of course, there are a large number of things to consider and tweak, such as how to deal with encryption, and the inevitability of people losing their keys. My first thoughts on this are to have a two-layer system, although I'm not sure this is possible. The user has a passphrase-protected key that can decrypt a secondary key which is actually centrally stored and used to encrypt/decrypt their files. Then if users lose their passphrase, their data isn't lost - another key held in central reserve that requires a combination of personal details to unlock can be used to decrypt the secondary key and create a replacement personal keypair.

That's probably enough about Partis for now!

Update (2008-04-29 18:25): Dan Lester (who uses the same WP theme - what are the chances?) has drawn my attention to Zoogmo which is similar on the surface, but is Windows-only and based around the idea of sharing with friends rather than the Partis network. Also, they don't yet appear to have different tiers. They do have a suitable "Web 2.0" name though. Something to look into and keep an eye on though. Are any ideas original any more?

Web service integration

Something that came to my attention the other day when reading Charles Miller's blog was the fragmentation of data across the web. There are few central authentication schemes (such as OpenID) and little support for them. There is no standard for integrating the services offered by the multitude of different sites. This isn't helped by the lack of incentive for sites to bring their offerings together, but I believe it could be really useful. I then read various blog posts on this subject and decided that I would like to hammer out the beginnings of a web interaction/integration API. With help and assistance from other people, of course!

More on this another time. All I will say for now is a potential name: OpenIntegrate.

Pluggable PHP system

While in the shower the other day (an excellent place for ideas to appear, it seems), I decided that what I really want to create is a library of PHP code that I can just plug together for various tasks. It would have to know a bit about database layout, so that I didn't really have to think about it in advance. The more I thought about it, the more developed the idea became. This system would be a set of PHP files and a preprocessor, so that modules can have optional dependencies and hence conditional code generation/inclusion in a fast way, as well as automatically creating/updating the database in order to work.

For example, I was recently thinking about how persistent logins work, and how nice it would be to just write a component once that I can just add to a generic user authentication component. A user authentication component requires (at minimum) a username and password field in a users table of a database. When coupled with a persistent login cookie system, however, either the users table has to be updated to include a persistent_token field (and maybe a series_id, see here) or a new tables is required if you want to allow login to be remembered from multiple places.

It would be really nice if the PHP could take care of these database modifications by itself, and automatically integrate with the user login module, so that I don't have to worry about it. That way, I can just put a load of files together, run something similar to rake/bake on them, and end up with an SQL file that will contain the required database schema and also include/exclude bits of the PHP code based on the available modules, perhaps commenting/uncommenting blocks based on available modules, etc. This would prevent a number of checks for optionally available functionality. Each module would then contain a comment header, perhaps something like:

/*# PROVIDES: userauth
 *# REQUIRES:
 *# SUPPORTS: persistlogin
 *# DEFAULT_DEF: TBL_USER="users"
 *# DB_REQUIRE: [ TBL_USER, [ username: varchar50, password: char32 ] ]
 */

and then:

/*# PROVIDES: persistlogin
 *# REQUIRES: userauth
 *# SUPPORTS: persistlogin
 *# DB_REQUIRE: [ TBL_USER, [ persistent_token: char32, series_id: char32 ] ]
 */

... and then make a sensible minimum required database structure out of them. Of course, much more than this would be required, and the format described above is very nasty, but that was just my first thoughts. You could then have conditional compilation:

/*# IF HAS_MODULE("persistlogin")
  // code to check for persistent login cookie
  if ($_COOKIE['persist_login']) { }
  elseif (/* check DB ... */) {
 *# ELSEIF #*/
  if (/* check DB ... */) {
/*# ENDIF #*/
    // log them in
  } else {
    // ...
  }

or:

/*# IF HAS_MODULE("persistlogin") #*/
  // code to check for persistent login cookie
  if ($_COOKIE['persist_login']) { }
  elseif (/* check DB ... */) {
/*# ELSEIF #*
  if (/* check DB ... */) {
 *# ENDIF #*/
    // log them in
  } else {
    // ...
  }

depending on whether the "persistlogin" module is available at the time the preprocessor is run.

I thought about calling it GHOTI (prounounced "fish") because I like quirky words, but couldn't immediately come up with a backronym. G- H- Offering Tight Integration? Maybe I'll come up with something from Latin instead. Or call it RADPHP or PHP-RAD. Who knows?

Anyway, that's probably enough of my random ideas for now. More to come after exams, I don't doubt! First one is tomorrow at 14:30. Sigh.