stuff

mrs.tex

@@ -149,59 +149,113 @@
 
 \begin{frame}
  \frametitle{Malleable Code?}
- - Does the right thing, efficiently.
- - Portable/backwards compatible.
- - extensible.
- - User friendly
- - Not bad software:
-   - Rigidity
-   - Fragility/Brittleness
-   - Immobility
- https://web.archive.org/web/20110714224327/http://www.objectmentor.com/resources/articles/dip.pdf
+ \begin{columns}
+\begin{column}{0.5\textwidth}
+\begin{itemize}
+ \item Does the right thing, efficiently.
+ \item Portability, Backwards compatibility, User friendly
+ \item \emph{soft}ware!
+ \item \textbf{NOT} bad software
+\end{itemize}
+\begin{block}{bad software}
+ \begin{itemize}
+  \item Rigidity: changes affect every part of the system
+  \item Fragility/Brittleness: changes unexpected parts of the system break
+  \item Immobility: Hard to reuse, because it cannot be entangled.
+ \end{itemize}
+\end{block}
+$\rightarrow$ Bad Software prevents adaptation
+\end{column}
+\begin{column}{0.45\textwidth}
+ \includegraphics[width=\textwidth]{gfx/hotiron.jpg} 
+ \vfill
+\end{column}
+\end{columns}
+%  https://web.archive.org/web/20110714224327/http://www.objectmentor.com/resources/articles/dip.pdf
 \end{frame}
 
 \begin{frame}
  \frametitle{Issues in Software Projects}
- 
- - research groups are small and lack required knowledge(Either this is the research)
- - or due to constant flux of people.
- - This encompasses people
- - Bus-factor.
- - Also remember that different parts of your code can have different bus-factors with different persons.
- - knowledge about parts?
- - Availability? Don't store it on a single pendrive.
- - Backups
+\begin{itemize}
+ \item Research groups usually lack manpower and the required knowledge.
+ \item Possibilities are research, or the flux of people.
+ \item Bus-Factor: How many people in your project have to get hit by a bus so your projects dies?
+ \item Knowledge about parts? Different Code paths can have different bus-factors.
+ \item Sharing, Security, Publishing,...
+\end{itemize}
 \end{frame}
 
 \section{Agile Development}
 \begin{frame}
- \frametitle{Adaptable Software Process: Agile Methods}
- The simple thing: Use a collaborative Development Platform with Version control: backup, sharing, SSG give you a home for your project
- and a place for your documentation.
- Agile Development cycle.
- 
- Parts can be automated, e.g. testing
+ \frametitle{Adaptable Software Process: Agile Tools}
+\begin{columns}
+\begin{column}{0.5\textwidth}
+\begin{block}{Good Tools go a long way}
+\begin{itemize}
+ \item Collaborative Development Platform
+ \item Decentralized Version control
+ \item Documentation, Website Generators
+ \item Issue trackers
+ \item test framework
+\end{itemize}
+\end{block}
+\end{column}
+\pause
+\begin{column}{0.5\textwidth}
+\begin{center}
+ \includegraphics[width=0.7\textwidth]{gfx/gitlab.png} 
+ \end{center}
+\end{column}
+\end{columns}
 \end{frame}
 
 \begin{frame}
- \frametitle{gitlab/github-flow}
- 
+\frametitle{The agile cycle}
+\begin{center}
+ \includegraphics[width=0.7\textwidth]{gfx/agilecycle.png} 
+ \end{center}
+ Very much like the research cycle.
+\end{frame}
+
+
+\begin{frame}
+\frametitle{Version control branching}
+\begin{columns}
+\begin{column}{0.45\textwidth}
+\begin{block}{Feature branch workflow}
+ \begin{itemize}
+  \item Open an issue. Describe what you want to do, and why.
+  \item Open a branch dedicated to this particular work item.
+  \item Do the work! You have a free space, undisturbed by others!
+  \item Open merge request: Describe to the others what you have done.
+  \item Submit for review.
+  \item Review once for yourself.
+  \item fix criticisms.
+ \end{itemize}
+\end{block}
+\end{column}
+\begin{column}{0.5\textwidth}
+ \includegraphics[width=\textwidth]{gfx/githubflow.png} 
+\end{column}
+\end{columns}
 \end{frame}
 
 \begin{frame}
  \frametitle{How to review}
- - transfer of responsibility: Will I, as a software project take responsibility of this code?
- - Can I take responsibility of this code?
- - Covers basically everything: correctness, quality, documentation.
- - Review should ensure that somebody else is knowledgeable about that part -> Hive-Mind notion.
- - Make new people part of the review early on, such that they can learn from the others.
- - Ask the question to plan for refactoring!
- - ideally a feature branch should only touch the smallest number of files that are required to change.
- - Have the will to design and to change to design.
- - How can I now keep this number of files with changes down?
+ \begin{itemize}
+  \item Transfer of responsibility: Will I, as a software project take responsibility of this code?
+  \item Can I take responsibility of this code?
+  \item Covers basically everything: correctness, quality, documentation...
+  \item Review should ensure that somebody else is knowledgeable about that part -> Hive-Mind notion.
+  \item Make new people part of the review early on, such that they can learn from the others.
+  \item Plan/think about refactoring!
+  \item Have the will to design and to change the design!
+  \item Ideally a feature branch should only touch the smallest number of files that are required to change.
+  \item How can I now keep this number of files with changes down?
+ \end{itemize}
 \end{frame}
 
-\section{Code Design}
+\section{Code Design - The SOLID principles}
 
 \begin{frame}
  \frametitle{Software Design}
@@ -502,10 +556,17 @@ Miscellaneous
 
 \begin{frame}
 \frametitle{Summary}
-- The research cycle requires software that is able to evolve with the growing external needs.
-- Workgroups should strive to quickly adapt to changing external demands. This is helped by agile processes.
-- Don't expect your code to fit perfectly to future tasks. But make it easily adapteable and changeable to be reusable.
-- The SOLID principles can give you some design principles to look out for, such that you code is suitable for agile processes.
+\begin{itemize}
+\item The research cycle requires software that is able to evolve with the growing external needs.
+\item Workgroups should strive to quickly adapt to changing external demands. This is helped by agile processes if built on malleable software.
+\item Don't expect your code to fit perfectly to future tasks. But make it easily adapteable and changeable to be reusable.
+\item The SOLID principles can give you some design principles to proactively design against code rot, such that you code is suitable for agile processes.
+\end{itemize}
+\pause
+\begin{center}
+ Thank You for your attention!
+\end{center}
+
 \end{frame}
 
 \begin{frame}
@@ -514,7 +575,8 @@ Miscellaneous
  \item https://www.youtube.com/watch?v=glYq-dvgby4
  \item https://www.youtube.com/watch?v=Ntraj80qN2k
   \item https://web.archive.org/web/20110714224327/http://www.objectmentor.com/resources/articles/dip.pdf
-  https://en.wikipedia.org/wiki/SOLID
+  \item https://en.wikipedia.org/wiki/SOLID
+  \item https://martinfowler.com/articles/designDead.html
  \end{itemize}
 \end{frame}