|
| 1 | +%============================================================================= |
| 2 | +\subsection{Conventions in this guide} |
| 3 | +\label{sec:conventions} |
| 4 | +%============================================================================= |
| 5 | +The conventions used in the \emph{GridPP UserGuide} are, by and large, |
| 6 | +self-explanatory. Here we'll look at a few that might not be. |
| 7 | + |
| 8 | +%----------------------------------------------------------------------------- |
| 9 | +\subsection{The command line} |
| 10 | +\label{sec:the-command-line} |
| 11 | +%----------------------------------------------------------------------------- |
| 12 | + |
| 13 | +Following \href{https://www.railstutorial.org}{Hartl}, we'll present |
| 14 | +command line examples using a Unix-style command line prompt (a dollar |
| 15 | +sign), as follows: |
| 16 | + |
| 17 | +\begin{lstlisting}[gobble=0,numbers=none,language=bash] |
| 18 | +$ echo "Hello, MoEDAL!" |
| 19 | +Hello, MoEDAL! |
| 20 | +\end{lstlisting} |
| 21 | + |
| 22 | +i.e.~you type what follows the dollar sign, and hopefully see the same |
| 23 | +(dollar sign-less) output in your terminal. |
| 24 | + |
| 25 | +\begin{warningbox}{Comparing the output} |
| 26 | +\emph{Computer systems are always going to vary from machine to machine, so |
| 27 | +you may not see exactly the same output from a given command. We've |
| 28 | +tried to eliminate this as much as possible by using the CernVM (see |
| 29 | +later) but more often than not a combination of common sense and |
| 30 | +Googling the output should confirm if you're on the right track.} |
| 31 | +\end{warningbox} |
| 32 | + |
| 33 | +Where possible we'll use bash environment variables to account for |
| 34 | +differences in working directories. However, if a particularly |
| 35 | +user-specific input is needed we'll use square brackets to denote parts |
| 36 | +of the command that require input specific to your circumstances. For |
| 37 | +example, when setting your working directory environment variable |
| 38 | +\texttt{WORKING\_DIR}, we'd write this: |
| 39 | + |
| 40 | + |
| 41 | +\begin{lstlisting}[gobble=0,numbers=none,language=bash] |
| 42 | +$ export WORKING_DIR=[Your working directory.] |
| 43 | +$ echo $WORKING_DIR |
| 44 | +[The value of $WORKING_DIR, hopefully your working directory.] |
| 45 | +\end{lstlisting} |
| 46 | + |
| 47 | +which would actually be completed using: |
| 48 | + |
| 49 | +\begin{lstlisting}[gobble=0,numbers=none,language=bash] |
| 50 | +$ export WORKING_DIR=/home/alovelace/grid-stuff/ |
| 51 | +$ echo $WORKING_DIR |
| 52 | +/home/alovelace/grid-stuff/ |
| 53 | +\end{lstlisting} |
| 54 | + |
| 55 | +%----------------------------------------------------------------------------- |
| 56 | +\subsection{Code listings} |
| 57 | +\label{code-listings} |
| 58 | +%----------------------------------------------------------------------------- |
| 59 | +Generally speaking, we have tried to avoid listing large swathes of code |
| 60 | +in the \emph{UserGuide} itself - that's what GitHub is for. From |
| 61 | +time-to-time it may be useful to include a code snippet like the |
| 62 | +following: |
| 63 | + |
| 64 | +\begin{lstlisting}[gobble=0,numbers=none,language=bash] |
| 65 | +#!/usr/bin/env python |
| 66 | +print("* This works!") |
| 67 | +\end{lstlisting} |
| 68 | + |
| 69 | +Following \href{https://www.railstutorial.org}{Hartl}, we will use |
| 70 | +vertical dots to represent code omitted for the sake of brevity: |
| 71 | + |
| 72 | +\begin{lstlisting}[gobble=0,numbers=none,language=bash] |
| 73 | +#!/usr/bin/env python |
| 74 | + |
| 75 | +class GridJob: |
| 76 | + . |
| 77 | + . |
| 78 | + . |
| 79 | + def submit(self, id): |
| 80 | + self.id = id |
| 81 | + . |
| 82 | + . |
| 83 | + . |
| 84 | +\end{lstlisting} |
| 85 | + |
| 86 | +These dots should not be copied into your code. Obvs. |
| 87 | + |
| 88 | +%----------------------------------------------------------------------------- |
| 89 | +\subsubsection{Hints, warnings, and information} |
| 90 | +\label{hints-warnings-and-information} |
| 91 | +%----------------------------------------------------------------------------- |
| 92 | +The \emph{GridPP UserGuide}, like many instructional handbooks, uses |
| 93 | +little pop-out boxes to highlight important points throughout the text. |
| 94 | + |
| 95 | +\begin{hintbox}{Hint boxes} |
| 96 | +\emph{This is a hint. Hint boxes are used for pointing out things that might |
| 97 | +be useful while carrying out the task being described (particularly |
| 98 | +where we have received user feedback on a given step!).} |
| 99 | +\end{hintbox} |
| 100 | + |
| 101 | +\begin{warningbox}{Warning boxes} |
| 102 | +\emph{This is a warning. These are used to flag up potential pitfalls or |
| 103 | +issues you may need to be aware of to avoid making mistakes or doing |
| 104 | +Something Bad.} |
| 105 | +\end{warningbox} |
| 106 | + |
| 107 | +\begin{infobox}{Information boxes} |
| 108 | +\emph{This is a point of information. These boxes will generally present |
| 109 | +things that may not directly relate to the topic being discussed but are |
| 110 | +nonetheless interesting.} |
| 111 | +\end{infobox} |
| 112 | + |
| 113 | +%----------------------------------------------------------------------------- |
| 114 | +\subsubsection{Checklists} |
| 115 | +\label{checklists} |
| 116 | +%----------------------------------------------------------------------------- |
| 117 | +Once you've waded through the waffle associated with a given section, |
| 118 | +you'll be presented with a \textbf{checklist} section that will give you |
| 119 | +a simple, bullet-pointed list of the things you should be able to do |
| 120 | +once you've read that section. You should go through these to make sure |
| 121 | +you have done them and, more importantly, understood them. If not, |
| 122 | +re-read the section. Alternatively, you could plough on and try the |
| 123 | +tests - see below - to see if it makes more sense when you try to |
| 124 | +actually do something based on what you've just read. |
| 125 | + |
| 126 | +%----------------------------------------------------------------------------- |
| 127 | +\subsection{Testing} |
| 128 | +\label{testing} |
| 129 | +%----------------------------------------------------------------------------- |
| 130 | +All well-written, well-packaged code should come complete with |
| 131 | +\textbf{unit tests}; scripts or bits of code that can be run to test |
| 132 | +whether one's software is working as expected (especially during |
| 133 | +development as changes are made and new versions are produced). We can |
| 134 | +try to emulate this approach by trying to test the success of each of |
| 135 | +the steps taken while following the instructions presented in the |
| 136 | +\emph{UserGuide}. At the end of each section you will therefore find a |
| 137 | +\textbf{Testing} page that will present a number of tasks or tests for |
| 138 | +you to complete to verify that you have followed the \emph{UserGuide}. |
| 139 | +As a rule you should not proceed to the next section until you have |
| 140 | +passed all of these tests. |
| 141 | + |
| 142 | +If you're struggling, there are plenty of ways to get help and support. |
| 143 | +We'll find out more about these in the |
| 144 | +\hyperref[sec:help]{next section}. |
0 commit comments