Skip to content
Snippets Groups Projects
Commit 36104251 authored by Uwe Jandt (DESY, HIFIS)'s avatar Uwe Jandt (DESY, HIFIS)
Browse files

added software news posts 2019

parent 1d1c9eda
No related branches found
No related tags found
5 merge requests!203WIP: Test MR,!177HIFIS unified step 1,!165Draft:Hifis unified V0.2,!127WIP:HIFIS Websites unification,!123Import software news, blog, events
---
title: Example Blog Post Template
date: 2019-10-29
authors:
- hueser
- erxleben
layout: blogpost
title_image: default
categories:
- blog
tags:
- example
- template
- markdown
additional_js:
- mathjax.js
excerpt:
This post will give you an overview of all the features you can use in your
very own HIFIS Software blog post.
---
# Blog Post Metadata
This post will give you an overview of all the features you can use in your
very own HIFIS Software blog post.
## The Frontmatter
At the top of your blog post you need to enter the so called _Jekyll_
_frontmatter_ which defines the meta-information about your blog post.
Note that the frontmatter is placed at the very top of your markdown file
and begins and ends with `---`.
For example:
```
---
title: A Sample Blog Post Title
date: 2019-12-31
authors:
- example_author_id
layout: blogpost
title_image: default
excerpt_separator: <!--more-->
categories:
- hifis
tags:
- draft
additional_css:
- my_own.css
additional_js:
- mathjax.js
---
```
Here is an overview over all the variables that can appear in your frontmatter:
| Variable | Mandatory | Default Value |
|-----------------------|:---------:|:-------------:|
| **title** | Yes | - |
| **date** | Yes | - |
| **authors** | Yes | - |
| **layout** | Yes | blogpost |
| **title_image** | No | default |
| **excerpt_separator** | No | `<!--more-->` |
| **categories** | No | - |
| **tags** | No | - |
| **additional_css** | No | - |
## Variables Explained in Depth
If you do not want to set any of the optional variables it is safe to leave
them out completely.
### title
Set the title of the blog post.
Prefer a short, on-point version, it has to fit in the pages' header among other
things.
### date
Set the publication date of the blog post.
Please use a date format according to this example given:
`YYYY-MM-DD`, e.g. `2019-10-29`.
### authors
Give a list of author IDs in YAML syntax.
You can find your author ID in the YAML-file `_data/hifis_team.yml`.
If your name is not contained you can add it by editing the hifis_team.yml file
or opening an issue with the _add team member_ template in GitLab.
### layout
Set the layout of the blog post.
Usually it is not wanted to create and specify your own blog post
layout. In order to create your own styling we might want to
provide additional CSS via variable "additional_css" as stated below.
### title_image
Set the title_image to use.
A good blog post will have an appealing title image.
It is recommended to create a sub-folder of the images folder
`{{ site.directory.images }}` per blog post which should be named
like this: `posts/2019-10-29-my-blog-post-name/`.
If you place your _title_image_ there, providing the sub-folder and
name of the image (with extension) will be sufficient.
In this case you need to set the variable _title_image_ accordingly,
e.g. `posts/2019-10-29-my-blog-post-name/my-title_image.png`.
You can also use the value **default** for the website default
image.
If you omit the variable completely the background will fall back to
Helmholtz-blue.
### excerpt_separator
Separator to be used to indicate end of excerpt.
### categories
Set list of categories for your blog post.
The URL will contain these categories.
### tags
Set a list of tags for your blog post.
### additional_css
You can provide your own CSS file for your blog post.
You can name a CSS-file which provides custom styling to be used within your
blog post.
It is supposed to reside in `assets/css/`.
Providing the file name (including extension) is enough.
---
# Blog Post Markdown Examples
## Excerpt Separator
Use the excerpt separator stated in the frontmatter to provide a short
excerpt of the blog post and cut off the remaining text in the blog
post on the overview / preview page of the blog posts:
Excerpt text as a preview to the blog post. Please keep this short
and meaningful.
<!--more-->
Remaining text of the blog post. Go into details here.
## Headlines
Headlines and sub-headlines can be defined with leading hashes (#).
# This is a Headline
## This is a Sub-Headline
### This is a Sub-Sub-Headline
## List Items
Bullet points can be added by asterisks (*), while numberings are done
by a number followed by a dot (1.).
Examples:
* item one
* item two
1. first item
2. second item
* item one
* item two
1. first item
2. second item
Sub-lists can be achieved by indentation:
* item one
* item two
* sub-item one
* item one
* item two
* sub-item one
## Task Lists
You can define checkboxes by squared brackets, e.g.
* [ ] First task list item
* [X] Second task list item (checked)
1. [ ] First numbered task list item
2. [X] Second numbered task list item (checked)
* [ ] First task list item
* [X] Second task list item (checked)
1. [ ] First numbered task list item
2. [X] Second numbered task list item (checked)
## Font Formatting
For italic characters embed them in underscores
(like this `_my italic text_` which results in _my italic text_).
For bold characters embed them in double asterisks
(like this `**my bold text**` which results in **my bold text**).
## Math
There is syntax for inline math as well as math on separate lines.
These are two examples:
This is an inline math snippet `$$ a^2+b^2=c^2 $$`: $$ a^2+b^2=c^2 $$
Math on a separate line can be implemented like this:
$$
\begin{align*}
& \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
= \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
& (x_1, \ldots, x_n) \left( \begin{array}{ccc}
\phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
\vdots & \ddots & \vdots \\
\phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
\end{array} \right)
\left( \begin{array}{c}
y_1 \\
\vdots \\
y_n
\end{array} \right)
\end{align*}
$$
$$
\begin{align*}
& \phi(x,y) = \phi \left(\sum_{i=1}^n x_ie_i, \sum_{j=1}^n y_je_j \right)
= \sum_{i=1}^n \sum_{j=1}^n x_i y_j \phi(e_i, e_j) = \\
& (x_1, \ldots, x_n) \left( \begin{array}{ccc}
\phi(e_1, e_1) & \cdots & \phi(e_1, e_n) \\
\vdots & \ddots & \vdots \\
\phi(e_n, e_1) & \cdots & \phi(e_n, e_n)
\end{array} \right)
\left( \begin{array}{c}
y_1 \\
\vdots \\
y_n
\end{array} \right)
\end{align*}
$$
## Quotes
Use block-quotes to highlight quotes like this:
For one-line quotes put a "greater than"-sign (`>`) infront of the quote:
> This is a one-line quote.
> This is a one-line quote.
For multi-line quotes put "greater than"-signs (`>`) above and
below the quote, one per qutation level:
>
This is a multi-line quote:
Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
aliquyam erat, sed diam voluptua.
>> There can be second level quotes.
>
>
This is a multi-line quote:
Lorem ipsum dolor sit amet, consetetur sadipscing elitr,
sed diam nonumy eirmod tempor invidunt ut labore et dolore magna
aliquyam erat, sed diam voluptua.
>> There can be second level quotes.
>
The same look is achieved with HTML `blockquote` tags.
## Code
Use inline code with single back-tics:
`$ apt-get update`
`$ apt-get update`
Use three back-tics and specify the language (```shell)
to mark code snippets on separate lines:
```shell
$ apt-get update
```
```shell
$ apt-get update
```
## Images
Images can be included by stating URL, title and alternative text
like so:
![Alternative Image Text]({% raw %}{{ site.directory.images | relative_url }}{% endraw %}HIFIS_Logo_cropped.svg "Image Title Text")
![Alternative Image Text]({{ site.directory.images | relative_url }}HIFIS_Logo_cropped.svg "Image Title Text")
Likewise to the `title_image` variable in the _frontmatter_ it is
recommended to create a sub-folder of the images folder
`{{ site.directory.images }}` per blog post.
It should be named in the form `posts/YYYY-MM-DD-my-blog-post-name/`.
If you consequently put your images into the sub-folder
`{{ site.directory.images }}posts/2019-10-29-my-blog-post-name/`,
you need to provide the full relative path to these images using the
_Jekyll Liquid_ variable `site.directory.images`.
For example:
`{% raw %}{{ site.directory.images | relative_url }}{% endraw %}posts/2019-10-29-my-blog-post-name/my-blog-post-image.png`.
## Links
If you would like to give a link for your references you need to
specify a link text, the URL as well as link title, e.g.
[Text for link to google.com](https://www.google.com "Link to Google!")
[Text for link to google.com](https://www.google.com "Link to Google!")
## Tables
Tables are a bit more complicated.
You need to give headers for your columns embedded in pipe-characters
(|), a separator row with dashes (-) and the cells with your content
embedded in pipe-characters (|) again:
| column 1 | column 2 |
|---|---|
| row 1 | row 1 |
| row 2 | row 2 |
| column 1 | column 2 |
|---|---|
| row 1 | row 1 |
| row 2 | row 2 |
## Custom CSS Styles for Paragraphs
To add custom CSS classes to your paragraph put a colon followed by dot and CSS
class name in curly braces.
You can use all classes from the _bootstrap 4.0_ framework, _fontawesome-solid_,
your own classes provided by the _additional_css_ variable and a couple of
custom built-in CSS classes:
### summary
Puts a blue border around the paragraph.
{:.summary}
This is text which appears in a box with blue border.
{:.summary}
This is text which appears in a box with blue border.
### treat-as-figure
This is a workaround for Markdowns shortcoming regarding figure environments.
It styles text within the following paragraph as if it were an image caption.
This is usually combined with an image, table or other figures.
For the image URL you should use _Jekyll Liquid_ variables
`site.url` and `site.directory.images` instead of hard-coding the URL.
### float-left
Floats the paragraph to the left side of the page and reduce its maximum width
to 30%. Useful for small images, it can be combined with `treat-as-figure`.
Example:
My paragraph above image which is treated as normal text.
{:.treat-as-figure}
{:.float-left}
My text above the image which is interpreted as caption.
![Alternative Image Text]({% raw %}{{ site.directory.images | relative_url }}{% endraw %}HIFIS_Logo_cropped.svg "Image Title Text")
My paragraph below image which is treated as normal text …
My paragraph above image which is treated as normal text.
{:.treat-as-figure}
{:.float-left}
My text above the image which is interpreted as caption.
![Alternative Image Text]({{ site.directory.images | relative_url }}HIFIS_Logo_cropped.svg "Image Title Text")
My paragraph below image which is treated as normal text. It flows around the
image. Even though this is a rather hackish approach to getting more advanced
styling into Markdown it is incredibly powerful and versatile, especially when
combined with custom CSS.
Lorem ipsum dolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmod
tempor invidunt ut labore et dolore magna aliquyam erat, sed diam voluptua. At
vero eos et accusam et justo duo dolores et ea rebum. Stet clita kasd gubergren,
no sea takimata sanctus est Lorem ipsum dolor sit amet. Lorem ipsum dolor sit
amet, consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut
labore et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam
et justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata
sanctus est Lorem ipsum dolor sit amet.
# References
For more detailed explanations of GitLab and Kramdown Markdown Syntax
take a look here:
* [GitLab Markdown Syntax Explained](https://docs.gitlab.com/ce/user/markdown.html "GitLab Markdown Syntax Documentation")
* [Kramdown Markup Syntax Explained](https://kramdown.gettalong.org/syntax.html "Kramdown Markdown Syntax Documentation")
---
title: How to Create a New Blog Post?
date: 2019-11-22
authors:
- hueser
layout: blogpost
title_image: default
categories: [tutorials]
tags: [startblogging, guidedtour]
additional_css:
- 2019-11-22-Workflow-to-Create-a-new-Blog-Post/create_blog_post.css
excerpt:
Nice project web page, how can I contribute with my own blog post?
This is what this blog post is about.
I will explain the workflow of &ldquo;how to create a new blog post&rdquo; and
thereby illustrate how to use the tools Git, GitLab and Jekyll
for these purposes.
---
## TL;DR
{:.summary}
_Nice project web page, how can I contribute with my own blog post?_
This is what this blog post is about.
I will explain the workflow of "how to create a new blog post" and
thereby illustrate how to use the tools _Git_, _GitLab_ and _Jekyll_
for these purposes.
There are minimal requirements for a blogger to add a new blog post
while a proper review process is still essential for the quality of
the blog posts.
So let us jump into it.
Note:
In case you are interested to know how to contribute
to _HIFIS Software_ web-page in general besides writing blog posts
you can find more information in the Contribution Guide
<sup>[[1]](https://gitlab.hzdr.de/hifis/software.hifis.net/blob/master/CONTRIBUTING.md "Contribution Guide")</sup>.
## Tools explained
First, I would like to introduce three tools which are very helpful
if you are going to write a blog post.
**Version Control System _Git_**
_Git_
<sup>[[2]](https://en.wikipedia.org/wiki/Git "Git (Wikipedia)")</sup>
is a decentralized version control system which lets you
store all files of your project and all snapshots / versions
of your changes.
It lets you track back the complete history
with your log messages given.
Decentralized means the whole repository resides as a copy on your
local computer.
**Version Management Platform _GitLab_**
_GitLab_
<sup>[[3]](https://en.wikipedia.org/wiki/GitLab "GitLab (Wikipedia)")</sup>
provides you with user interfaces for several actions which can be
done on the remote server without downloading the whole repository
onto your local computer.
There is also an issue tracker included.
On top, there is a full _Web IDE_ available which also let you review
changes by your colleagues.
Even if you are new to _Git_, the _GitLab Web IDE_ offers an easy
interface which can be employed for most of your Use Cases.
There is no need to install _Git_, download the _Git_ repository to
your local machine and set up your own IDE
to contribute with your blog posts.
**Static Web Site Generator _Jekyll_**
_Jekyll_
<sup>[[4]](https://en.wikipedia.org/wiki/Jekyll_(software) "Jekyll (Wikipedia)")</sup>
is a static web site generator.
You only write _Markdown_ text files and _Jekyll_ takes care of the
rest and generates a static web site containing only HTML and CSS
according to your templates and layouts given.
## Workflow in a Nutshell
Now that we know more about the tools used, I would like to introduce
the steps I took to create this blog post.
You can stick to these steps if you are writing your own blog post:
1. Share, discuss or pick a post idea
2. Write and share your post
3. The review process
4. Your post is online
By agreeing to this process we put you into the position of a
fully authorized and equitable team member who is able to actually
easily contribute with your own work to this web page.
On closer inspection, there are the following persuasive arguments
to use _Git_, _GitLab_ and _Jekyll_:
* You can collaborate with different authors and reviewers using a
decentralized version control system like _Git_.
* There is a full traceback and logging functionality included in _Git_.
* _GitLab_ lets you review, discuss and improve what you write in
a well thought-out review process called _Merge Request_.
* _GitLab Web IDE_ is actually a surrogate for a local IDE with
_Git_ integration.
* _GitLab CI Pipelines_ make sure and check that all is still
working as expected.
* With _Jekyll_ you just need to know very few syntactic markdown
features, there is no need to write your own HTML and CSS.
Finally, to make a clear statement ...
**_you don't end up in a mess with multiple versions of
a document floating around on local computers of
several contributors._**
## Going into Details - a Step-by-step Guided Tour
**1. Share, Discuss or Pick a Post Idea**
First of all, you need some sound ideas regarding the topic you would
like to blog about.
Open a new issue in the _GitLab UI_.
In order to do so, you need an account in GitLab of HZDR
<sup>[[5]](https://gitlab.hzdr.de "HZDR GitLab Instance")</sup>
and being added as member to the respective GitLab project.
Opening an issue is explained in the _GitLab Docs_
<sup>[[6](https://docs.gitlab.com/ce/user/project/issues/managing_issues.html "Managing GitLab Issues")</sup>.
It is essential to give it a comprehensive _title_ and _description_
which reflects the basic idea of the topic.
It is recommended to use the predefined _Issue Template_ "_blog-post_"
which guides you through the important questions that need to be
answered in order to start a fruitful discussion.
By doing so you let us know what you would like to write about.
Assign this issue to the main blog author (which usually is
yourself).
If you use the template this will be done automatically for you.
The images below show such a blog-post issue as well as the
pre-defined description text and questions to answer.
![Blog Post Template View]({{ site.directory.images | append: 'posts/2019-11-22-Workflow-to-Create-a-new-Blog-Post/Screenshot_Blog_Post_Template_View_20191113.png' | relative_url }} "Blog Post Template View"){:.blog_post_template_image}
![Blog Post Template Text]({{ site.directory.images | append: 'posts/2019-11-22-Workflow-to-Create-a-new-Blog-Post/Screenshot_Blog_Post_Template_Text_20191113.png' | relative_url }} "Blog Post Template Text"){:.blog_post_template_image}
**2. Write and Share your Post**
The next step is to create a Feature Branch based on branch _master_
and give it a meaningful name like `<issue_number>-<branch_name>`.
This can be done within the _GitLab User-Interfaces_
<sup>[[7]](https://docs.gitlab.com/ce/user/project/repository/web_editor.html#create-a-new-branch "Create a new Branch in GitLab")</sup>.
Navigate into this branch in _GitLab_ and open _GitLab Web IDE_
<sup>[[8]](https://docs.gitlab.com/ce/user/project/web_ide/#open-the-web-ide "Open GitLab Web IDE")</sup>.
_GitLab Web IDE_ is the preferred tool to contribute if you are
unfamiliar with _Git_.
Notice the file system tree on the left hand side of the _Web IDE UI_.
You can find a template for your blog post in folder `_posts/<year>/<month>`.
The file name is _2019-10-29-Blog-Post-Template.md_.
Feel free to copy it, give it a name according to the pattern
`YYYY-MM-DD-My-post-title.md`, put your new file into folder `_posts/<year>/<month>`,
and use it for your own purposes.
The template explains the so called _Frontmatter_ which contains
variables like `title`, `date`, `authors`, etc.
Additionally, the most important markdown is explained by example
within the template as well.
Of course you want to remove the explanations and examples except for
the _Frontmatter_ at the top of your markdown file.
Another helpful feature of the _GitLab Web IDE_ is the
_Preview Markdown_ pane.
You can check that everything you wrote is displayed as intended.
Now you are ready to start writing your _Markdown_ file following the specific
syntax of _Markdown_ files
<sup>[[9]](https://docs.gitlab.com/ce/user/markdown.html "GitLab Markdown")</sup>.
Once you are done with your editing you would like to _stage_ and _commit_
your changes
<sup>[[10]](https://docs.gitlab.com/ce/user/project/web_ide/#stage-and-commit-changes "Stage and Commit Changes in GitLab Web IDE")</sup>
giving it a meaningful message explaining your changes.
There is a blog post
<sup>[[11]](https://chris.beams.io/posts/git-commit/ "Best Practice of Git Commit Messages")</sup>
about best practices for writing _Git_ commit messages.
The more verbose your messages are, the easier it is for others
to understand your changes.
**3. The Review Process**
After some effort and a few commits, let us assume your blog post
is in a state where you consider it ready to see the light of day.
What you want to do at this point is to open a _Merge Request_
<sup>[[12]](https://docs.gitlab.com/ce/user/project/merge_requests/ "Merge Request")</sup>.
_GitLab's User-Interface_ lets you open _Merge Requests_
<sup>[[13]](https://docs.gitlab.com/ce/user/project/merge_requests/creating_merge_requests.html "Creating a Merge Request in GitLab")</sup>.
Give it a meaningful title and description and mention the
original issue as well (e.g. by stating `Closes #<issue_number>.` in
the description).
Assign your _Merge Request_ to one or multiple persons you would
like to review the blog post.
This is an important quality gate.
Do not rely on reviewing your own work.
Please select at least one other reviewer.
In order to make the review process as easy as possible GitLab
offers a feature called _Review Apps_ to inspect your branch.
This enables the blog post authors as well as reviewers to preview
the page in a test environment.
As soon as your your branch is pushed onto the remote
repository and the _GitLab CI Pipeline_ responsible for
deploying your branch finished successfully,
you can inspect your latest deployments of your branch
by clicking the button _View app_ in the User-Interface of your
Merge Request.
![Review Apps Button]({{ site.directory.images | append: 'posts/2019-11-22-Workflow-to-Create-a-new-Blog-Post/Screenshot_Review_Apps_01_20191121.png' | relative_url }} "Review Apps Button"){:.review_apps_button}
To access these pages you need to authenticate.
The credentials are as follows:
Username: `hifis`, Password: `HIFISReview!`.
As soon as someone reviews your blog post, all comments on your
_Merge Request_ appear as separate discussion threads which need
to be resolved by the reviewers before they can actually merge your
changes into branch _master_.
This means that you first discuss and integrate the suggestions into
your post as well as secondly add and commit changes to your branch.
All opened discussion threads need to be resolved and closed manually
in GitLab before the final merge can take place by the reviewer.
Now, the reviewer finds a button "_Merge_" in that _Merge Request_ in
_GitLab_.
This tells _GitLab_ to integrate your changes into branch _master_.
By clicking that button a _GitLab CI (Continuous Integration) Pipeline_
<sup>[[14]](https://docs.gitlab.com/ce/ci/introduction/index.html "GitLab CI (Continuous Integration) Pipeline")</sup>
is started and makes checks whether _Jekyll_ can still build the
whole project.
In case all is fine, this is indicated by a success icon.
If the original issue has been referenced by `Closes #<issue-number>.`
the mentioned issue will be closed now.
Likewise, if the corresponding checkbox
"_Delete source branch when merge request is accepted._"
has been checked on creation of the _Merge Request_ in the
_GitLab User-Interface_ the source branch will be deleted as well.
Finally, the _Merge Request_ will be closed and marked as _merged_.
**4. Your Post is Online**
Now your post is integrated and online.
Well done!
That was fairly easy.
Wasn't it?
You have all the advantages of _Git_, _GitLab_ and _Jekyll_
at your disposal for quickly creating markdown-based blog posts
of the highest quality.
If you are looking for a good _Git_ tutorial I would like to suggest
the one from the _Software Carpentry_ group
<sup>[[15]](http://swcarpentry.github.io/git-novice/ "Software Carpentry Git Lessons")</sup>.
_So what are the topics you would like to talk about today?_
Give it a try and let us know what your thoughts are which
you would like to share with us.
## References
* [[1]](https://gitlab.hzdr.de/hifis/software.hifis.net/blob/master/CONTRIBUTING.md "Contribution Guide") Contribution Guide
* [[2]](https://en.wikipedia.org/wiki/Git "Git (Wikipedia)") Git (Wikipedia)
* [[3]](https://en.wikipedia.org/wiki/GitLab "GitLab (Wikipedia)") GitLab (Wikipedia)
* [[4]](https://en.wikipedia.org/wiki/Jekyll_(software) "Jekyll (Wikipedia)") Jekyll (Wikipedia)
* [[5]](https://gitlab.hzdr.de "HZDR GitLab Instance") HZDR GitLab Instance
* [[6]](https://docs.gitlab.com/ce/user/project/issues/managing_issues.html "Managing GitLab Issues") Managing GitLab Issues
* [[7]](https://docs.gitlab.com/ce/user/project/repository/web_editor.html#create-a-new-branch "Create a new Branch in GitLab") Create a new Branch in GitLab
* [[8]](hhttps://docs.gitlab.com/ce/user/project/web_ide/#open-the-web-ide "Open GitLab Web IDE") Open GitLab Web IDE
* [[9]](https://docs.gitlab.com/ce/user/markdown.html "GitLab Markdown") GitLab Markdown
* [[10]](https://docs.gitlab.com/ce/user/project/web_ide/#stage-and-commit-changes "Stage and Commit Changes in GitLab Web IDE") Stage and Commit Changes in GitLab Web IDE
* [[11]](https://chris.beams.io/posts/git-commit/ "Best Practice of Git Commit Messages") Best Practice of Git Commit Messages
* [[12]](https://docs.gitlab.com/ce/user/project/merge_requests/ "Merge Request") Merge Request
* [[13]](https://docs.gitlab.com/ce/user/project/merge_requests/creating_merge_requests.html "Creating a Merge Request in GitLab") Creating a Merge Request in GitLab
* [[14]](https://docs.gitlab.com/ce/ci/introduction/index.html "GitLab CI (Continuous Integration) Pipeline") GitLab CI (Continuous Integration) Pipeline
* [[15]](http://swcarpentry.github.io/git-novice/ "Software Carpentry Git Lessons") Software Carpentry Git Lessons
---
title: SWC workshop at GFZ-Potsdam
date: 2019-12-11
authors:
- dolling
layout: blogpost
title_image: default
excerpt_separator: <!--more-->
categories:
- report
tags:
- workshop
- carpentries
additional_js:
- mathjax.js
excerpt:
In November the first HIFIS related Software Carpentry Workshop was held.
<em>How hard could it be?</em>
---
# The First Workshop
### TLDR
{:.treat-as-figure}
![XKCD estimating time]({{ site.directory.images | relative_url }}posts/2019-12-11-SWC-Workshop-at-GFZ/xkcd_estimating_time.png)
Taken from [https://xkcd.com/1658/](https://xkcd.com/1658/) and licensed under
[<i class="fab fa-creative-commons fa-lg"></i>
<i class="fab fa-creative-commons-nc-eu fa-lg"></i>
<i class="fab fa-creative-commons-by fa-lg"></i>](https://creativecommons.org/licenses/by-nc/2.5/
"Creative Commons Attribution-NonCommercial 2.5 License").
In November 2019 the first HIFIS related Software Carpentry Workshop was held.
_How hard could it be?_
When I first took a look into [The Carpentries](https://carpentries.org/),
I thought: "Organizing a workshop about stuff I know - how hard can it be?"
But because the whole _The Carpentries_ idea was new to me, I wanted to
get some more information.
Luckily we had some previous workshops at the Telegrafenberg, so I
reached out to organizers and instructors of the previous ones.
In summary they told me that it takes a lot of time to organize one and prepare properly.
Okay — if you say so — I had no clue.
My colleague and I started by finding a date and a room.
Due to Christmas and the AGU conference we already realized that we had only
two months to do it. Everything seemed fine.
We met with the people that organized the workshops before to learn from their experience and get advice.
Even after that, we where pretty confident: _that's a piece of cake_.
Oh wow, were we wrong:
* The possible instructors and helpers were volunteers[^1], have commitments and thus were partially available only.
* The decision which lessons to teach depend on the availablility of instructors, so the dates, and finally available rooms.
* However, even finding a room that works best took way longer than expected, and
* The joint agreement of the lessons to teach and how to share the work load wasn't straight forward.
Finally, we started registrations around three weeks before the workshop began - which, surprisingly, has been quite enough time in advance since the workshop was overbooked within a few days.
[^1]: Thank you!
Fortunately we had about 35 registrations for 30 seats.
Lessons, staff and attendees were set a week before the workshop — _PHEW!_
We expected issues cropping up days and hours before;
They happend, but nothing to worry about.
Somehow we maneuvered ourselfs pretty well in between the pitfalls.
The only mentionable issue was, that quite a few registered people did not
participate due to different reasons: Some of them canceled a few days and hours before
because of other short-term commitments and others
were not able to submit a SINGLE slide to introduce themselves and their work
in a 60 seconds lightning talk - which has been the ticket to particpate in the workshop.
I have seen all the slides, and many of them looked like they spend less than
five minutes to quickly throw together generic pictures and five words, which
we expected and totally suited for the purpose of the slide.
However, some researchers were not able to invest these _five minutes_ for a free
_two-days_ workshop. Instead others, people from the waiting list, got the opportunity and
got the slides done on the same day they received the seat confirmation.
## On the Workshop Itself
In general, it was a great experience for all of us - the organizers, instructors,
helpers, and importantly the participants.
The lessons went well, some timing issues occured, but summarised everything was more or less
as planned.
From the feedback we got, the participants were happy and some of them even
thanked us afterwards because they learned what they needed.
One thing that we want to do better next time is staff planning.
This time, we were overstaffed with helpers. All the time we were at least two instructors,
plus two organizers and additionally three helpers, which is what we had in mind for approx. 30 participants.
Unfortunately there were 18 participants only in the end.
So somemetimes it felt like the helpers were circling around the participants in the hope of occurring problems.
First of all, the people rarely had issues, considering all the new software
and things to learn.
I am looking forward to our next workshop in April 2020!
---
title: Welcome to HIFIS Software
date: 2019-12-20
authors:
- huste
- leinweber
layout: blogpost
title_image: photo-of-open-signage-2763246.jpg
excerpt:
"We are very happy to announce the initial release of software.hifis.net:
the central platform for distributing information, promoting events and
offering tutorials and content concerning scientific software development
within Helmholtz."
categories:
- blog
tags:
- general
---
# Welcome to HIFIS Software
We are very happy to announce the initial release of **software.hifis.net**:
The central platform for distributing information, promoting events and
offering tutorials and content concerning scientific software development
within Helmholtz.
## Who are we?
HIFIS or Helmholtz Federated IT Services is one of 5 platforms initiated by
the [Helmholtz Incubator][incubator] besides
* [HIDA - the Helmholtz Information & Data Science Academy][hida-link],
* [Helmholtz AI][haicu-link],
* [HMC - the Helmholtz Metadata Collaboration Platform][hmc-link] and
* [HIP - the Helmholtz Imaging Platform][hmc-link].
HIFIS aims to install a secure and user-friendly collaborative environment
offering information and communication technology services that are accessible
from anywhere.
The platform also supports the development of high-quality, secure, and sustainable
research software.
These objectives are implemented through three competence clusters:
- The [Cloud Services Cluster][cloud-link] providing a federated platform for proven,
first-class cloud services,
- A [Backbone Services Cluster][backbone-link] providing a powerful and reliable network
infrastructure with uniform basic services and
- Us, the Software Services Cluster providing a platform, training, and support
for high-quality, sustainable software development.
Our mission is to empower scientists of any domain to implement and to
perpetuate modern scientific software development principles in order to make
research software engineering more sustainable. Our core team is located in 5
different Helmholtz Centers:
- [DLR - German Aerospace Center][dlr]
- [DKFZ - German Cancer Research Center][dkfz]
- [GFZ - German Research Centre for Geosciences][gfz]
- [HZDR - Helmholtz-Zentrum Dresden-Rossendorf][hzdr]
- [UFZ - Helmholtz Centre for Environmental Research][ufz]
Have a look into our [team page]({{ '/team' | relative_url }}).
You will find an interactive map to see how we are spread over Germany.
Since we aim to provide services for the **whole** Helmholtz Association,
we would be more than happy, if **you** would like to act
as our [contact person](#contact-us) in **your** Helmholtz center.
Help us spread the word to make research software development more sustainable.
## What are we going to offer?
Please find that information on our [services page]({{ '/services/' | relative_url }}).
Stay tuned! The first training events, services and materials
will be announced there in early 2020.
## How to get involved?
Distributing information about services offered, upcoming training events or
building Helmholtz-wide communities requires us to have **you** as a
motivated contact person in your research center or research group who is
willing to help in communicating and spreading the word about sustainable
software development and HIFIS.
By using a clearly defined version control workflow contributing is made easy for everyone.
Therefore, you can [contribute to this website][gitlab-project].
If your software project was improved by a HIFIS-provided training or advice,
or want to share an interesting solution or use case,
please feel free to write or re-blog a short post about it here.
You can even add yourself to our team page as an associate.
Our [Contribution Guide][contributing] explains how to contribute to *software.hifis.net*.
You are also welcome to [tell us](#contact-us) your interest and we will keep you up-to-date about upcoming
trainings, events and services in 2020 and forward.
<div class="alert alert-success">
<h2 id="contact-us"><i class="fas fa-info-circle"></i> Contact us</h2>
<p>
Send a mail to
<strong>
<a href="mailto:{{ site.contact_mail }}">{{ site.contact_mail }}</a>.
</strong>
</p>
</div>
[incubator]: https://www.helmholtz.de/en/research/information-data-science/helmholtz-incubator/
[hida-link]: https://www.helmholtz-hida.de/
[haicu-link]: http://www.helmholtz.ai/
[hmc-link]: https://www.helmholtz.de/en/research/information-data-science/helmholtz-metadata-collaboration-plattform-hmc/
[hip-link]: https://www.helmholtz.de/en/research/information-data-science/helmholtz-imaging-platform-hip/
[dlr]: https://dlr.de/sc
[dkfz]: https://www.dkfz.de/
[gfz]: https://www.gfz-potsdam.de/zentrum/escience-zentrum/ueberblick/
[hzdr]: https://www.hzdr.de/
[ufz]: https://www.ufz.de/
[contributing]: https://gitlab.hzdr.de/hifis/software.hifis.net/blob/master/CONTRIBUTING.md
[cloud-link]: https://www.hifis.net/mission/cluster-cloud.html
[backbone-link]: https://www.hifis.net/mission/cluster-backbone.html
[gitlab-project]: https://gitlab.hzdr.de/hifis/software.hifis.net
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment