Commit 79f744fe authored by Florian Goth's avatar Florian Goth
Browse files

stuff

parent f9d0f790
gfx/isp1.png

17.1 KB | W: | H:

gfx/isp1.png

31 KB | W: | H:

gfx/isp1.png
gfx/isp1.png
gfx/isp1.png
gfx/isp1.png
  • 2-up
  • Swipe
  • Onion skin
gfx/isp2.png

14.8 KB | W: | H:

gfx/isp2.png

32.3 KB | W: | H:

gfx/isp2.png
gfx/isp2.png
gfx/isp2.png
gfx/isp2.png
  • 2-up
  • Swipe
  • Onion skin
gfx/isp3.png

13.9 KB | W: | H:

gfx/isp3.png

29.9 KB | W: | H:

gfx/isp3.png
gfx/isp3.png
gfx/isp3.png
gfx/isp3.png
  • 2-up
  • Swipe
  • Onion skin
gfx/isp4.png

17.7 KB | W: | H:

gfx/isp4.png

29.5 KB | W: | H:

gfx/isp4.png
gfx/isp4.png
gfx/isp4.png
gfx/isp4.png
  • 2-up
  • Swipe
  • Onion skin
gfx/isp5.png

18.8 KB | W: | H:

gfx/isp5.png

26.9 KB | W: | H:

gfx/isp5.png
gfx/isp5.png
gfx/isp5.png
gfx/isp5.png
  • 2-up
  • Swipe
  • Onion skin
......@@ -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}
......
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment