This book has specific content depending on your educational programme and operating system. Please select them in the bar above!

Introduction

Congratulations! You are about to take your first steps towards becoming not only a programmer, but a computer scientist or engineer! This book aims to provide you with the tools and context that you will need during your university years, especially related to programming and computing.

This material will also try to create a common ground so that assumptions can be made in later courses. For example we will teach you how to use Git, a tool made for tracking version history of files, that is very important for collaboration, both in your courses and in the workplace.

This book will use the official program codes: TKDAT (Datateknik 300hp), TKITE (Informationsteknik 300hp) and N1COS (Datavetenskap 180hp) instead of the full names.

Who is this for?

This book mainly targets those who have just started a program relating to computer science and have no, or very little, previous knowledge. This means that we try to write as clearly as possible even if it means being redundant.

As this book is written and maintained by DNS we will also have some information from us regarding courses and your student rights at Chalmers. We urge all TKDAT students to read through everything under the "Courses" and "Studies" categories because this is the main place we will be sharing useful information for your studies.

{{ .DV .IT }} Much of this information applies to TKITE and N1COS as well!

If your only experience comes from a course or two during Gymnasiet then you should still find useful information here but may find the steps to be a bit too granular. Hopefully, you can look past this! If you're even more experienced than that, we still urge you to at least have a look through, there could still be useful information here!

If you think that there is a topic that needs improvement or have ideas for new topics, please look at the contributing page!

Structure

Note that if you print this book images may not be included as they are supposed to. Reading this guide on the web is recommended.

Begin by reading the beginner chapters sequentially. These will prepare you for your real courses and can be deemed as essential. We will go through each topic from the bottom up and each sub-chapter is meant to be self-contained, meaning you can take 10 minutes and read a small bit every day. To receive the greatest benefits, these should preferably be read during the reception or the start of your studies. Once you have read all the beginner chapters you can progress to whichever chapters you are interested in.

We cannot stress enough how important it is that you actually try what you are reading. Just like any other craft, it is impossible to master computer tools without hands-on experience.

Under studies you will find course-specific information. These chapters provide specific tips & tricks from older students and should generally be looked at just before beginning the course and can be used as a reference during the course. You will also find guidance on how your studies are structured and what choices you should make. These become more relevant later in your education but we still recommend that you become familiar with the basics and exams.

Boxes like these are used to give interesting information or context that is not necessary to understand the guide but can provide further reading or useful tips for those interested.

If you get stuck

While we have tried to be as thorough as possible, there might still be cases we haven't thought about. Feel free to email the authors any questions you might have. You can reach them at dns@dtek.se.

{{ begin .Data }}

The student division

For Data students we have a Discord here where we also post news regarding the student division. We also share information from the program or from us regarding deadlines or things of importance for you! Make sure you sign up in order not to miss anything!

Lectures

There will be two lectures where we go through some of the early chapters. The first lecture we will go through how to use the CLI, the editor and some general information. The authors will also be available during the PISS-kväll in the afternoon to help you. The second lecture will primarily cover Git. This lecture is if anything more important than the first so please come to both!

The authors will also be attending the hackkväll at 18:00 in NC (Idéläran) and will be assisting you with any problem you might be having!

{{ end }}

Getting started

To begin with, you need to install a couple of applications. These will be useful throughout your education. This section will only briefly describe how to install the software, while in the later chapters we will tell you more about why and how we use them.

Editor: VSCode

VSCode is our recommended editor. This is the application you write code with. Download it here.

Online meetings: Zoom

Sometimes you will have the ability to join lectures online, where the university uses Zoom. It is also possible to set up your own room and talk to your group partners remotely. Download it here.

{{ begin .windows }}

Windows Subsystem for Linux

This is only necessary if you use Microsoft Windows. WSL allows you to run Linux programs while running Windows as your primary OS. Linux is another operating system that you will get to know more about during your studies. The official instructions can be found here but they can be a bit complicated. So we have included our own instructions below as well.

Start by running cmd or powershell. This can be done by pressing !kbd[!win] and searching for powershell. Then right-click on Windows Powershell and select Run as administrator. Note that if you have Windows set to another language than English it will be translated to that language.

A new window will open where you can run commands. After typing your command you can run it by pressing Enter. Run wsl --install and then reboot your computer.

You can now start WSL by searching for "ubuntu" from the Windows Start Menu. Follow the instructions on screen and you are good to go!

{{ end }}

IT-services at Chalmers

During your time at Chalmers you will have to use a wide variety of tools. Most can be found through this link.

Chalmers ID (CID)

Your CID is used to access all Chalmers services. You will get instructions on how to get one during your first days at Chalmers.

You will need your CID to use all the services in this section. Feel free to come back once you have it.

IT-support

Using Chalmers IT-services is never easy but there is some help to be had at the IT-portal, though it does not cover everything.

Wi-Fi: Eduroam

Chalmers and GU uses the global university network "Eduroam" for Wi-Fi connectivity (there is Wi-Fi everywhere on campus). Look at our chapter on Eduroam or search for "Eduroam" on the IT-portal (requires a CID) to find out how to connect your devices.

Online storage

Chalmers provides OneDrive storage to all students where you can store and share files online.

Chalmers Apps

Sometimes you need special software or more computer power for a lab. It is almost always possible to use the computers at school but it is also possible to access them remotely from home using Windows App or on Linux, through your browser. For more information see our chapter on Chalmers Apps

Schedule: TimeEdit

You can find both program and course schedules on TimeEdit. It is also possible to export the calendar to other calendar programs such as Google Calendar.

Canvas

Canvas is the learning management system at Chalmers. In simpler terms, it is where you will find course information, submit labs and so on. We have a short chapter going through it!

Ladok

Ladok is the national service for managing your courses, exams, etc. This is where you will do your final registration for courses, exams and re-exams. Make sure to keep an eye out for when you have to register. The window for course registration is usually from two weeks before the course starts, until the end of the first week of the course. Exam registration is usually open during the second half of the study period. If you do not register in time, then you won't be able to take the course or exam. There are no exceptions to this rule and the administration services can't register you manually.

You can log in at student.ladok.se.

Files

Before we talk more about the tools we recommend, we need to talk about how a computer stores information. These days you don't have to think about it too much as it is hidden away from you by your phone or computer, but having a basic understanding of this is essential. How does your computer store the programs that you have installed, the photos you have taken, or the online worlds you have explored in games? How does it find that information again when you need it?

In order to find information, computers store it into something called a file system. They contain two different kinds of objects: files and folders (also called directories). A file is something that stores information, and a folder is a way of grouping together multiple files. Folders can also contain other folders. Every file and folder has a name that can be specified by the user. This is very abstract at the moment, so we will give some concrete examples.

Example 1: Storing and organizing photos

If you have a large number of photos, you probably want to organize them in some way. This could be both a physical photo album or a digital one (like DFoto). Every photo is a file, which contains the information to actually display the photo. You might also name photos with the date they were taken.

If you were at some event, and took a lot of photos there, you could collect all of those photos into an album and give it a label with the name of the event. This is similar to a folder/directory. If you then go to multiple events in a year, you could group all event albums into an album for the entire year. This would then be a folder containing folders, which then contain files.

Example 2: Storing books in a library

Libraries have a lot of books and need some way to store them where you can still find them efficiently. Books are grouped together into shelves based on the topics they cover and the shelves are given names. Your book on JavaScript will probably be on the shelf about programming. But as there are a lot of different subjects, we group together shelves that cover similar topics. It doesn't make sense to have your books on programming right next to children's books, or if it would be next to fiction. Here the books would be your files, the shelves and sections would be folders.

Going back to computers, we don't just have one type of file like in the above examples, we have multiple! Some files are programs that you can run, others are photos that you can open in some program to look at. Some are videos that you can watch, other are PDFs that you can read. Some files contain code that you write that will then be run by the computer. How a computer interprets a file depends on its contents.

How do we then refer to a specific file? With something called a path! We will cover paths more in depth later, but the basic idea is that we list all directories you have to look in to get to the file, and then the name of the file itself. In order to make it clear where the name of one directory ends and a new one starts, we separate them with forward slashes (/).

{{ .windows }} Windows usually uses backward slashes (\) in paths instead. We will go through the differences between so called "Unix" systems and Windows later!

A concrete example would be how you find the text for this chapter! The project is on GitHub. All files for this book are in a folder named src. Inside of it, there is one folder for each of the sections you see to the left. This document is in the folder called beginner. The file itself is called files.md. The path to it would thus be src/beginner/files.md.

The Editor

The tool you will be looking at the most when working on your computer will be either your browser or your editor. This guide will set you up with one of the world's most used editors which should be suitable for most. This guide is not directed to those already comfortable with their editor of choice but may introduce some useful functions which you may not have used before.

So which editor should I choose?

Short answer: Visual Studio Code. (VSCode)

Long answer: When writing this guide we compared different editors to determine which is the "best". Editors are one of the tools that people have very strong opinions about, and you will likely hear people talk about their editor and why it's so good. But there are several reasons we recommend VSCode:

• Available on all platforms (Windows, macOS, Linux)
• An intuitive and user friendly interface.
• Not specific to a certain programming language or environment (e.g. PyCharm which only works for Python)
• Extensive plugin support for different languages and for use in certain courses at Chalmers.
• Very configurable to your needs with a simple to understand GUI. (Graphical User Interface)

Setup

To get started, begin by downloading VSCode from the webpage.

Did you know that you can open links in a new tab by either

• Holding !kbd[!ctrl] while clicking on the link
• Middle clicking on the link

After installing VSCode, start it like you would any other program. We will now go through the most basic functionality you will need to start programming! After this we will go through some useful shortcuts, extensions and ways to navigate your editor. Of course it's absolutely okay if you can't remember all of it, it's going to be a lot of new information so come back here any time you want a refresher!

Further reading

If you want to look at the official documentation yourself you can do so here.

The Start Screen

The first time you start up VSCode you will be presented with a short introduction, which can help you set up Copilot, choose a default theme, and that can give you resources like video tutorials for getting started.

However to not get stuck with customizing and watching videos we will give a quick overview of the very basic functionality of your new editor. In the top left corner you will see an small arrow with a "Welcome" next to it, this will take you back to the Welcome page which greets you every time you start VSCode from here on out.

Welcome

Now you'll be presented with a screen that gives you a few options

[Warning] This warning goes out especially to Windows users, but does apply to everyone. Do not use spaces in your file or folder names. At best it will be an annoyance and at worst it will break things! On top of this avoid using non-ASCII characters in paths if you're on Windows. This might not be obvious what it means now but what this mainly means is do not use non-latin characters, notably å, ä, ö (or emojis!!).

The one we're going to start with is Open... or Open Folder.... Alternatively using your keyboard press !kbd[!ctrl+o]. This will bring up your operating systems graphical file explorer, here you can choose to open an existing folder, or to create a new folder.

{{ .macos }} On MacOS you will most likely be placed in your users home folder. Our suggestion is to create a new folder here, named something like "data101" and then pressing Add.

{{ .linux }} On Linux you will most likely be placed in your users home folder. Our suggestion is to create a new folder here. How you do this depends on your distribution and primarily what file manager you have. The standard one in Gnome has the create folder button under the blue Select button. Name it something like "data101" and then press said Select button.

{{ .windows }} On Windows you will most likely be placed in your user folder. To create a new folder, right click and hover over New, here select Folder. Name it something like "data101" and then press Select Folder.

Files

Now on the left side of your screen you will see the Explorer. Here you can see the name of the folder you just entered as well as all the files in the folder. However, currently there are none!

To create a file we can click on the New File... button in the middle of the screen. You'll notice your "search bar" gets a little dropdown menu (this is called the command palette and we will return to it in a minute). As it says, you can now write in a file name. As an example write in "testing.txt" and press !kbd[Enter]! You will get a little pop up from your operating system asking if you want to create a file in this directory. Press Create File. Alternatively you can press !kbd[!ctrl+n] which immediately creates an untitled text file. You will then get to name it once you save it.

Left of the Explorer you can see the so called Activity Bar marked in red below. By right clicking this you can change its contents or position on the screen.

The menu bar

The problem you may have noticed is that now the Welcome page is gone. To do something like open a folder, create a file or to save now we have to instead use the command palette or the menu bar.

{{ .macos }} On MacOS the menu bar will look like this

{{ .windows .linux }} On Windows and Linux the menu bar will look something like this

Here press File and you'll get a bunch of options. To save, click on Save or alternatively as suggested in the dropdown, !kbd[!ctrl+s]. Using this menu bar you can do most of the things you will need in VSCode. This includes everything we've already gone over how to do using the welcome screen. From here you can open and create new folders, open files and much more that we'll be getting into in some of the other subchapters.

Navigation

Before writing code it is necessary to understand how to navigate the editor. Remember that this is all about muscle memory. You will have to train and it will feel uncomfortable, especially if you aren't used to using your keyboard extensively. But learning it now will make you fast as lightning by the time you graduate. You will probably neither feel motivated nor have the time to learn this when you are out working.

The caret

The caret is the blinking line from where text appears, you probably know all about it but the name may be new to you. To move the caret, use the arrow keys. If your keyboard has them, you can also move to the start or end of the line by pressing !kbd[Home] or !kbd[End] respectively. To move the caret word by word, hold !kbd[Ctrl] (or !kbd[Alt] on MacOS) while pressing !kbd[Left] or !kbd[Right].

{{ .macos }} On MacOS there are also certain standard navigation options for moving the caret that work in every program. You can use !kbd[Ctrl+a] to move to the start of a line and !kbd[Ctrl+e] to move to the end of a line.

Holding !kbd[Shift] while doing any movement also selects the text!

The command palette

VSCode also includes a powerful tool called the Command palette. This may be the most important method of navigation. It can be used to efficiently navigate your project by first opening the palette and then writing a command. You can open it with !kbd[!ctrl+p].

There are a few different modes of operation. The first and simplest one is to search for files in your project. Try creating a new file in your project, open the command palette and then type the beginning of the name and press !kbd[Enter]. This is a fast method of moving between files in your project.

The palette also has another function which is to run various tasks, such as opening preferences, building your project or opening a new terminal. This mode is accessed by prefixing the search with > or entered directly by pressing !kbd[!ctrl+Shift+p]. This is incredibly powerful and anything that you can do by using your mouse can be done here. When you're in this Command mode try searching for something you want to do. Be it "Create new file" or "Add line Comment", the command palette can probably do it!

Lines

When writing text you seldom worry about adding line breaks, but in code lines have meaning. They change which computer instructions the code represents. Naturally because of this we have ways of working with lines.

• You can move lines up and down by using !kbd[!alt+Up] and !kbd[!alt+Down].
• You can cut entire lines by using !kbd[!ctrl+x].

You can also navigate to a line by opening the command palette (!kbd[!ctrl+p]) and prefixing the line number with a :. For example :52 will move you to line 52. An even faster way of doing this is to press !kbd[!ctrl+g] which automatically prefixes your search with a :.

Find & Replace

Sometimes you want to find a certain string in a file. For example, say that you have a function named "startProgram" that you want to find. By pressing !kbd[!ctrl+f] you will open the find menu where you can search for any text in the file. If you instead want to search your whole project then that would be !kbd[!ctrl+Shift+f].

This command also works in your browser and can be used to find text on websites.

This type of functionality can also be used to replace text. Maybe that function name you invented at the start just isn't cutting it any longer so you decide to replace it. Rewriting this by hand is tedious and error-prone (what if you miss one place?). Luckily VSCode has us covered. You can use !kbd[!ctrl+h] (!kbd[!ctrl+Alt+f] on macOS) and !kbd[!ctrl+Shift+h] to replace occurences in the file and project, respectively.

It is also possible to perform more complex searches and replacements. See the reference for more information.

There is actually one final tool which is even more powerful than a normal find-search which is The symbol search. In short, a symbol is some sort of identifier in your code. It could be a function name, a variable or some other named construct. The symbol mode of the command palette lets you swiftly navigate to these, just the same as you would navigate to other files. To use this feature, prefix your command with @.

Final notes

Searching text visually has several drawbacks. It is time-consuming, an inexperienced searcher may have to go through the whole file to find the text in question. It also breaks your flow. You can only keep a certain amount of information in your head at once. For a beginner this may just amount to a few lines of code, while for someone experienced it may be several files at once. But in the end it is a finite amount and there is no need to let go of it when we have tools which can help.

Some people use PageUp and PageDown to move the window up or down one page at a time, others scroll the mousewheel to fly over a file. What these methods have in common is that they are relative movements and searches. What we want is to ask the computer for something and get it without us having to filter the information.

Here are a couple of cherry-picked examples demonstrating the effectiveness compared to simply scrolling.

If you get an error that says "Error, undefined variable on line 32 in file 'main.py'", then you may be tempted to scroll through main.py until you find the line. It would be much faster to use !kbd[!ctrl+g] and enter 32 to navigate to the correct line immediately.

You may have a large file (files with more than a thousand lines are not uncommon) and your friend tells you to look at the function toLowercase. You can, just like the previous example, scroll and search by eye. However you can also use the powerful symbol mode of the command palette (prefix with @). Searching for @tolowercase will get you there without the need to manually scroll and search.

The most generic of the methods described above is the Find word functionality (!kbd[!ctrl+f]). If your Teaching Assistant asks you to bring up anything on the screen, then this command will always get you something reasonable.

Using shortcuts

While the mouse is very useful most of the time when using a computer, programming is not necessarily one of those times. Programming is made far easier by using the keyboard for actions you'd normally do with the mouse. Every single action that can be done using your mouse can also be done without lifting your fingers from the keyboard.

You may be tempted to click on the screen to move the caret, save your file or create a new file, and while this works, it isn't very fast, and requires moving your cursor a whole lot. Instead use keyboard shortcuts! In the beginning, you may not notice how much faster this is but as you go through the semester it will become second nature to you.

{{ begin .macos }}

!kbd[Ctrl] or !kbd[⌘]?

On Macs the !kbd[!win] key is replaced by !kbd[!cmd] and is usually used instead of the !kbd[Ctrl] key. This guide tries to match the shortcuts to the OS you have selected in the top bar but may not always be 100% accurate.

{{ end }}

Below you can find some of the most commonly used shortcuts in our cheatsheet. If you have a hard time memorizing them feel free to print one for yourself and bring it along in your backpack as a way to remind yourself of what you can do with the editor. It can also be useful to use this as a reference during the rest of this tutorial, but don't worry if you don't understand what all the shortcuts do yet.

[Task] Try writing some text on a new line. What happens if you press !kbd[!ctrl+x] without selecting any text?

[Solution] The entire line gets cut, meaning it is put in the clipboard and can be pasted elsewhere.

Extensions

One of the reasons for recommending VSCode over other editors is due to its extensive and easy to use plugin marketplace. In this sub-chapter we will go through how to install extensions as well as some of the most useful extensions to install. These extensions can help you customize your editor, or to help you set up your programming environment.

When we say environment we are talking about a collection of programs and settings that you have available. Sometimes we make changes to a local environment that only affects a certain folder or project, but most of the time we make changes that affect your entire computers environment.

Installation

In the activity bar, which by default is furthest to the left in a VSCode window, you have a few icons. The one on the bottom is the extensions marketplace.

Pressing this you'll get a big menu where you can now install extensions. By default they're displayed in order of popularity but you can also search for specific extensions using the search bar at the top of this menu.

To install an extension simply press the Install button! The arrow next to it typically allows you to install a "Pre-release" version. This is usually not worth doing unless you have a very specific reason for doing so. Your installed extensions will be visible under the Installed dropdown.

If you want to make this entire extensions menu bigger or smaller you can drag the edge of the pane. This is also true for most panes in VSCode.

Language support

The two most popular extensions in VSCode as seen in the image above are two python extensions. The top one is needed to load other python extensions, it is a dependency, other extensions depend on it. It also offers certain nice features like syntax highlighting. A syntax highlighter mainly change the color of different elements in code to make it more readable.

Installing this plugin also installs the next most popular one, "Pylance". This is a so called language server. Language servers offer assistance when programming. They help you write functions of different types, make it easier to navigate your code, and can help you understand what certain things in code mean.

However be very careful when using language servers.

To learn to code you need to understand what that code does. Sometimes a language server will recommend you to do something that you do not understand. Sometimes it will tell you there are errors where there are none. Sometimes they will make code harder to understand in an attempt to make it better. For these reasons we suggest avoiding language server extensions for a start until you're a bit more comfortable with a language, a sentiment you might hear echoed by professors and other students.

These syntax highlighting and language server extensions exist for nearly every programming language you can think of and can be very useful. If you want to install one just search up the language name in the extension marketplace and they will likely be the first thing to show up. For syntax highlighting especially we always recommend getting an extension for your current language.

Environment

There are also extensions to allow you to set up a particular environment for your programming. As an example they can let you enter docker containers or allow you to interact with hardware, something which will be used in one of your courses in study period three if you are studying at computer engineering.

Customization

There are also extensions that allow you to change how your editor looks if you'd like! This can include things like changing icons and the way windows and panes look. Another popular customization option is themes. These change the colors of your editor. Some popular ones are "Gruvbox", "Monokai" and different flavors of "Catppuccin". This website allows you to see and compare different ones easily.

Command-line interface (CLI)

You may be used to using graphical interfaces when using your computer, but initially, interfaces were mostly text-based. This still holds true for a lot of developer tools. There are several reasons as to why but it mostly comes down to that they are easy to create and simple to use. They may feel clunky at first but as soon as you have used a few you will realize that they all follow very similar patterns. Here is short list of reasons for why you should learn to use the terminal.

• Most programming tools are made for the command line, especially with flags allowing for extra flexibility.
• Most unix terminals are very similar, so if you can do something in the terminal on your computer you can probably do it on your friends computer.
• The above point also means you'll be able to get help easier, in courses and in your personal projects.
• It gives you a better understanding of how your computer works, and how it all fits together.
• If you ever need to use a server, or a remote connection you will be restricted to only using a terminal in most cases.
• It's fun! It might seem scary at first but when you get used to it and learn it, it can actually make using your computer a whole lot of fun.

There are two words commonly used when talking about how you interact with text-based interfaces: terminal, and shell. They refer to different parts of using text-based programs, but as it isn't important for this book, we will use terminal to talk about both.

A lot of people naturally get stressed and think that it is easy to write some command that will cause harm to the computer. Please be assured that it is in fact incredibly difficult to destroy anything using the terminal.

{{ begin .windows }}

Most systems you will interact with use what is called a Unix terminal. Windows has its own terminals called cmd.exe and PowerShell which are quite different from Unix terminals. cmd.exe is really old and is not used much these days. PowerShell is Microsofts newer replacement, and although it can be used on other platforms than Windows, the most commonly used terminals are still Unix based, and most command line utilities are written for Unix terminals. For those interested, we have a short overview of PowerShell.

{{ end }}

Installation

{{ begin .windows }}

To get a Unix terminal on Windows, we need to install WSL (Windows Subsystem for Linux). Open Microsoft Store and search for Ubuntu. Install the first option. You can now search for "Ubuntu" in the start menu and start it that way. This should open a terminal. WSL is a way to run Linux on your Windows PC. You can read more about Linux here.

Important to note is that your WSL install is basically a separate computer running inside of windows. It's a so called Virtual Machine. Feel free to ask dHack or DNS about what this means and we'll gladly talk about it. The reason it matters though, is because programs installed in Windows will not be available in WSL and programs installed in WSL will not be available in Windows.

This is not required, but we also recommend you to install Windows Terminal. It gives a more modern look and feel than the default that comes pre-installed with Windows.

{{ end }}

{{ .macos.linux }} MacOS and Linux already have a Unix terminal and so there is nothing to install.

Getting started

{{ .windows }} On Windows you start WSL by searching for "Ubuntu" in the Windows Start Menu. You should see something like this:

{{ .macos }} On macOS, press !kbd[!cmd+Space] and then enter "terminal" to open a terminal. You should see something like this:

{{ .linux }} On Linux, how you open a terminal depends on your distribution. Usually one of !kbd[Ctrl+Alt+t], !kbd[!win+t] or !kbd[!win+Enter] opens one. Otherwise, search for "how to open terminal <insert your distro here>". You should see something like this:

You can also open a terminal in VSCode if you prefer working there. Open the command palette (!kbd[!ctrl+Shift+p]) and type "terminal: create new terminal" and press !kbd[Enter]. This should open a new terminal at the bottom of your screen. You can also open one by clicking on Terminal in the menu bar at the top of your screen, and then pressing New Terminal.

With a terminal open, what are we looking at? Exactly what you see will depend on which terminal you are using, if yours looks different that is okay. At the start of the line of text you will see your username followed by @, and then the name of your computer. After that you will see the current directory. Your terminal keeps track of something called its working directory, which is where on your file system it is located at the moment. Right now it is ~, which is a symbol used to represent your home directory. Every user has a home directory where all of their files are stored. At the end of the line you will see a solid block, which is your cursor. Here we can write commands and run them by pressing !kbd[Enter].

We can print the exact location of our working directory by running the command pwd (print working directory). This should print /home/ followed by your username. You can also list the contents of your working directory with the command ls (list).

Commands are case sensitive. This means that pwd and PWD aren't the same thing, and you will get error if you try and run the second one.

Creating and deleting files and directories

We can create directories with the command mkdir <name> (make directory). The text inside angle brackets is a placeholder which shows that a command needs some extra data to run properly. This extra data is called an argument and you are supposed to replace them (including the <>) with what you want before running the command. For commands that require multiple arguments, you separate them with spaces. In the case of mkdir, we replace it with the name of the directory we want to create. Try running mkdir test_directory and look at the changes with ls.

To create files, you can use touch <path>. Here we replace <path> with the name of the file we want to create. Run touch file1 and touch file2. If you run ls now you should see the two files. We can create multiple files at once by giving multiple names as arguments. Try this with touch file3 file4.

To remove files, use rm <path>, where <path> is the name of the file we want to remove. Here we can also list multiple files we want to delete.

[Danger] Be careful with using rm as the files will not be moved to the trashcan like they would if you deleted them from a user interface. If you use rm, the files are gone and you cannot recover them. You won't be able to remove system critical files without extra authentication, but you should still be careful. The next chapter covers Git, which can protect you from costly mistakes like this!

If you want to open up VSCode to start editing some of the files, you can run code to open up the working directory in the editor. You can also use code <path> to open a specific file or directory. If you are using a different editor, there is probably a command to start it from the terminal too.

{{ .window}} On windows the ability to do this requires you to install VSCode to your path. This is one of the options that should be pre-selected when you install it, and this will not function if you unchecked that box.

Navigation

Up until now we have only run commands from our home directory, but it would be cumbersome to do everything from here. We can change our working directory with cd <path> (change directory). Here we replace <path> with the name of the directory we want to move into. Try running cd test_directory. You can verify that you have changed the working directory by running pwd again.

You can also move to the previous directory using cd ... The argument we are giving to cd is more generally known as a path, which we will cover in more depth in the next subchapter.

In many terminals you can autocomplete commands and arguments by pressing !kbd[Tab]. If there are multiple alternatives, you will get a list of them. You might need to double-tap !kbd[Tab] to see all available alternatives.

You might wonder how you can refer to a directory with a space in its name, as we use spaces for separating arguments. In these cases, we can surround the path in quotation marks like this cd "My directory". This applies to any arguments that contain spaces, not just directory names. When using tab completion, you might instead get a suggestion of cd My\ directory. Here backslash acts as a way to "escape" the following space.

You can access your command history using the up and down arrow keys.

It is common to alternate between cd and ls when navigating in the terminal, but this can quickly clutter up the screen. You can clear it by either running the command clear, or by pressing !kbd[Ctrl+l].

Special shortcuts

There are a couple of shortcuts that might be helpful.

• !kbd[Ctrl+c] terminates the current program (does not force a program to exit if it is busy).
• !kbd[Ctrl+z] sends the program to the background, can be sent back to the foreground by running fg.
• !kbd[Ctrl+d] sends an End of Line (EOL) to the terminal. This usually exits the current program if it is interactive.

Paths

In the previous chapter, we referred to something called a path. We will now explain more thoroughly what they are. A path is a string that specifies a location on your file system. It consists of a series of directory names, separated with /. Paths can either refer to files or directories depending on the name of the last part of the path.

You have already seen some examples of paths when running cd test_directory or cd ... These are relative paths, meaning that they are interpreted from our current working directory. They look like directory/sub_directory/subsub_directory.

Paths can also be absolute. This means that instead of interpreting the path from your working directory it is interpreted from the root of the file system. All paths that start with a / are considered absolute. An example would be /directory/sub_directory.

There are also some special path symbols:

• . refers to the current directory.
• .. refers to the directory above this one, often called the parent directory.
• ~ is an absolute path to your home directory.

All of these symbols can be used together to form paths. Though it is worth noting that most programming languages do not understand ~.

It is common to use the word parent and child when working with computer terminology. A parent is usually something on a layer above while a child is something on the layer below.

Here are some examples:

~/test_directory : This is an absolute path to the test_directory we created in the previous chapter.

/etc/shells : This is an absolute path to the file containing shells

../../etc : This a relative, and what is refers to depends on you working directory. If you are in you home directory, it is equivalent to /etc.

[Task] If you run ls ../ inside test_directory what do you expect you will see?

[Solution] You will see the files in your home directory as test_directory is a child of your home directory and ls ../ lists the content of the parent directory.

Hidden files

Files and directories that have a . as the first character of their names are called hidden files. They usually don't show up when using ls, we instead have to use ls --all. Most of the time you won't interact with them, which is why they are hidden.

Globbing

For commands that take multiple arguments, you sometimes want to specify multiple paths that follow similar patterns. For this we can use something called globbing, which is done by inserting one or multiple *s into the path. It is a placeholder that means anything goes. So ls *.txt would list all files in the current directory that end in .txt.

You can also use ** to mean any number of directories. So ls **/* would list everything in the current directory, including any content in directories, and any content inside of the sub-directories, and so on.

Flags

We've previously seen how we can use rm to remove files. Now let's try and remove test_directory. cd back to your home directory and try to remove it by running rm test_directory. It will refuse to do so because it is a directory. To remove directories you need to append a flag. Flags are switches that change the behavior of the command or allow you to provide optional extra data to it. They are added just after the command like this: command --flag. You can add as many flags as you want to but some combinations may not make sense.

Here you will notice a philosophy of command line utilities: they are quiet if things work, and scream if something goes wrong. If they don't print anything beside what you expected, they did what you wanted them to do (or at least what you told them).

In our case we need to append the --recursive flag to remove files recursively. This means that if our path is a directory, the command goes through the directory and deletes all files within it as well. Try running rm --recursive test_directory.

[Danger]

Remember that rm will completely remove files and that they won't end up in your trashcan. This is especially important to be aware of when you use it with the --recursive --force flags as this will remove entire directories without asking if you are sure. Without the --recursive flag it will never delete more than the exact files you give it, nor delete directories with files in them so it is usually not an issue.

Almost all command-line programs include a special flag that will print help information. This is almost always --help. This will usually give a short description of what the command does and list flags that it accepts.

Short-hand flags

Some commands have single-letter flags which are easier to type. These are often just variants of long-hand flags, such as -h instead of --help which can be used for many programs. There are however also short-hand flags that have no long-hand variant, like -l, which displays in a long-listing format. The same goes vice-verse, there are certain long-hand flags which have no short-hand variant, like --color.

These short-hand flags can also often be combined without needing another hyphen. An example of this is ls -ahl. This will apply the flags --all --human-readable -l. This will give you the ls output in long listing format, display hidden files and turn byte amounts into more readable forms, like KB and MB.

[Task] Using the help flag, what is the short-hand flag for --recursive in rm?

[Solution] It is -r.

Common commands

Now that you know the basics of how paths work and how to interact with a terminal, we will present some common commands in more rapid succession. We will also list the commands we have already covered so you can use this as a quick reference.

If you want to know more about a command you can either use command --help to print a quick reference, or use man <command> to get more thorough documentation. The latter option can be a bit unintuitive to use at first, but you can use the arrow keys to move up and down, and !kbd[q] to exit out of the viewer. If you want to print out your own version of the below version you can download a PDF here!

More on notation

Sometimes when looking through the help page for commands you might see something like this:

touch [OPTION]... FILE...

Here the square brackets ([]) indicate optional arguments. Sometimes they might list exactly which flags or arguments you can provide, but in this case it just says options. You might also see required arguments in all caps without any angle brackets (<>), such as in this case.

The ellipsis (...) also bear significance. They indicate that you can specify multiple of the preceding item. So for this command we can provide multiple options and multiple files.

System files

Sometimes when working in a terminal, you need to touch system files or run commands that affect core parts of the system. When you do this, you will get an error that says "Permission denied". In these cases, you need to give extra permissions to the command by typing sudo followed by the command you want to run. For example (don't run this):

sudo cp /etc/fstab /etc/fstab.copy

After pressing !kbd[Enter], depending on how your system is configured, you will be prompted for your users password. While typing it in, you will notice no characters are appearing on screen. Don't worry, your typing is being registered, this is just another security measure to make sure no one is peaking over your shoulder and sees the password. Once you have typed in your password, press !kbd[Enter] and if your password is correct, the command will be run with elevated privileges.

Mind you, you should actually be careful with sudo. We've said earlier that it is difficult to do proper damage to your computer but sudo is the one command that actively lets you do things to your computer that might be dangerous. It is used for many everyday things, so you might get used to using it. But if you get a warning telling you that you need sudo, don't just do it right away without thinking about its effects. If you're not sure what a command does you can always look it up online!

You can configure which users can use sudo and which commands they are allowed to run with it in order to limit the access they get to your system. Commonly it is setup so you can run any command with sudo, provided you can authenticate yourself with your password.

Package managers

When you want to install programs on your computer, you might be used to either downloading the program from their website or using your operating systems app store. However, there are also ways to install programs from the command-line. In order to do this, we use something called a package manager. Package is just a different (and more general) name for referring to a program. Package managers provide a central and unified way of installing programs and tools, and are especially useful for installing developer tools. They also make it a lot easier to install a lot programs all at once.

There are a lot of different package managers, and which ones are available to you depends on which operating system you use. Most of them follow them same patterns for how to use them. Here we will help you install a package manager and provide you with the basics commands for using it.

{{ begin .windows }}

{{ .linux .macos}} Windows

On Windows when you're using WSL you can use apt to install programs inside of WSL. This is useful for programming tools like git or installing compilers like GHC which you might want to use in WSL. However it might still be nice to be able to install programs outside of WSL. This can help you keep programs up to date easier, or allow you to install programs in an easier way.

The two most popular package managers for Windows are winget and chocolatey. Windows comes preinstalled with winget but it has fewer packages while chocolatey requires you to install it but has more packages. The main reason for this is that chocolatey has a community repository, which allows users to publish packages themselves and upload them. This might sound scary, but is quite normal, just be sure that you're installing the right package! If you want to see what packages are available in both you can see winget package search and chocolatey community package search.

To install chocolatey use this command in CMD:

@"%SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe" -NoProfile -InputFormat None -ExecutionPolicy Bypass -Command "[System.Net.ServicePointManager]::SecurityProtocol = 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))" && SET "PATH=%PATH%;%ALLUSERSPROFILE%\chocolatey\bin"

or this command in PowerShell:

Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

To verify your install use choco -v

Apt (inside of Ubuntu WSL)

Winget (inside of CMD or PowerShell)

Chocolatey (inside of CMD or PowerShell)

{{ end }}

{{ begin .macos }}

{{ .windows .linux }} MacOS

On MacOS we recommend using Homebrew. There are a few other MacOS package managers but none of them¹ are as up to date and have as many packages as Homebrew. It can be installed by following the instructions here. There you can also find more information about it. Homebrew uses the terms cask and formula, which can be a bit confusing. In Homebrew, a cask (generally) refers to a graphical program, and a formula is a command line tool.

To use Homebrew these are the basic commands you will use:

Updating

The differentiation between update and upgrade here is important. Update means to update Homebrew itself, which also includes updating the version of packages that can be installed. Upgrade is what actually updates the packages on your computer to the most recent version. After upgrading we suggest always running brew cleanup as well to get rid of old files. They can all be run together with:

brew update && brew upgrade && brew cleanup

{{ end }}

{{ begin .linux }}

{{ .windows .macos }} Linux

If you are on Linux, you already have a package manager installed! There are however a lot them to choose from which all work in slightly different ways, and which one you have depends on the distro you use. For this reason we will only cover how to use some of the more common ones from the larger distros. If yours is not listed, try searching for <distro> package manager and you should find some documentation for it.

Apt (Ubuntu, Mint, Debian)

Apt is one of the largest package managers and is used on a lot of systems.

Dnf (Fedora)

Pacman (Arch, Manjaro, Artix)

Pacman is the base package manager that comes with Arch Linux and any distros that are derived from it. There are various helpers that you can install that make it easier to install some packages. If you have one of these, just replace pacman with the name of your helper in the commands below.

{{ end }}

Powershell

On Windows you have two different terminals: cmd.exe, and PowerShell. The latter being the new one, which we will briefly cover the basics of using here. We assume that you have read the previews chapters that cover the terminal as a lot of it is shared. PowerShell uses some different terminology and calls commands for "cmdlets". We will continue to call them commands though.

There are some slight differences in how paths are handled. Windows prefers to use \ for separating directories, but PowerShell also understands /. On Unix systems we have one root directory for the whole system, but on Windows each drive has their own root, and each drive gets a one letter identifier. To indicate which drive we are talking about in absolute paths, we prefix the path with the drives letter followed by :/ and then the rest of the path. Your main drive will usually have C as its identifier. An example of an absolute path would be C:/Users.

PowerShell has its own version of all commands we have covered, but most of them have aliases that match the names in Unix shells. There are however slight differences in their behaviour, so read through their help pages to understand all of the details. To get access the help pages, use help <command>, or help <command> -Online if the first page is incomplete which happens at times. You might need to press !kbd[Enter] a few times to see all of the help screen. Here you might also notice that PowerShell use just uses one - instead of --. There are also only longform options.

The following is a listing of the PowerShell equivalents for the commands we covered earlier. Note that they only operate on single files, compared to Unix shells where they operate on multiple.

The error messages you get if a command fails are more verbose and a bit cryptic at times, but we encourage you to read them. With times you will learn which parts of them are important.

You can still use !kbd[Ctrl+L] to clear the screen and !kbd[Ctrl+C] to cancel commands.

Sometimes you might get a prompt asking if you are sure about performing and operation. Here you can either press the key in square brackets that corresponds to the option you want, or leave it empty for the default option, followed by !kbd[Enter] to continue.

Cooperation

This chapter will be all about working together and it is also one of our longest. This is something you will be doing constantly during your time at Chalmers. Your programming courses will most likely contain labs or assignments to be done together with others, and sometimes your math courses do as well. Therefore it is crucial to have a good environment set up to be able to work with a group.

It's very common for new students to gather around a single computer, or to write code separately and test which is best before turning it in. Others share files over Discord or Snapchat and this can lead to major issues when you're working at the same time or if you've missed a message.

To facilitate group work we will introduce two tools: Git—the stupid content tracker—and LiveShare, a VSCode plugin which we will go through in chapter 5.7.

What is Git

Git is a form of Version Control System (VCS for short). That is, a set of tools that help you track changes you make to your text files. It helps you collaborate with others by keeping track of who did what, as well as guiding you in merging your different versions of files. Git lets you be fearless when changing your code, safe in the knowledge that previous versions of your code are easy to access.

This chapter will probably feel very long compared to the others but it is also the most important, which is why we needed all the other chapters to build up to it. Knowing Git is a crucial skill and there are many good and important reasons for learning it.

• It's used in virtually every software-related job on the planet. Be it backend work, programming, systems development or a role as system administrator, you will most likely be using Git.
• It's incredibly useful in your courses, and even required in a few. Being able to write code simultaneously and to work on different parts of the code at once is a requirement for effective work.
• Having access to previous versions of code can be a life saver, for both personal and collaborative projects. It serves as a backup system in case your hardware breaks, but also lets you go back to older versions or test different feature implementations.

In this tutorial, we will guide you through setting up the necessary software and accounts for a modern Git experience. We will also introduce you to the basic concepts of version control.

To make Git a bit easier to understand we will primarily be using the Git integration built in to VSCode. We will also go through how to use Git in the terminal for those of you who prefer the CLI.

Git installation

Before you can use Git in VSCode or in the terminal it needs to be installed on your system. For macOS and Linux this means we have to use the terminal, but there's not a lot we have to do, so don't be dismayed if you're not used to it yet!

Install Git

{{ begin .windows }}

{{ .macos .linux }} Windows

On Windows, you install Git by downloading the installer from here and following the instructions.

If you are using Ubuntu WSL like we recommend you can install Git using Ubuntus package mangaer. In WSL run:

sudo apt-get install git

Then verify your install by running:

git --version

Note that this only installs Git for WSL and that the Windows installer we linked to only installs Git for Windows.

{{ end }}

{{ begin .macos }}

{{ .windows .linux }} MacOS

For MacOS users, there are two ways to install Git which we recommend.

1. The preferred way to install command line tools like Git on MacOS is with Homebrew. If you don't know what that is we recommend going back and reading about package managers in the previous chapter. If you do not want to use Homebrew, try the other method instead. In your terminal write:

   brew install git
   

   To confirm that Git has been installed correctly run the following. Then move on to the next step.

   git --version
   

2. Use the Git bundled with XCode. Chances are that if you're going to program on a Mac, then you are going to have to install XCode's command-line tools at some point anyways. Git comes bundled with XCode's command-line tools. Check if you have it installed by opening a terminal and typing:

   git --version
   

   If you see something like the following, you've already got Git installed and can move on to the next step.

   git version 2.33.0
   

   If not, you need to install XCode's command-line tools (and its bundled Git). You can do so by running the following command:

   xcode-select --install
   

   Let this install, restart your terminal and type the following again. It should now display a version. Move on to the next step.

   git --version
   

{{ end }}

{{ begin .linux }}

{{ .windows .macos }} Linux

The easiest way to install Git on your Linux machine is using your distro's package manager. On Ubuntu and Debian-based distros you will want to run the following in a terminal:

sudo apt install git

On Arch-based distros you want to run:

sudo pacman -S git

Then verify your install by running:

git --version

{{ end }}

Create an account on GitHub

When using Git you will want a place to store your repositories (projects, commonly called repos for short), the most popular site for this is called GitHub, but other alternatives include GitLab and BitBucket.

We recommend setting up a GitHub account, as it comes with some excellent student benefits. Sign up for an account here, and while you're at it sign up for the GitHub Student Developer Pack using your Chalmers email (cid@student.chalmers.se) here. The GitHub Student Developer Pack gives some good benefits for GitHub.

Chalmers GitLab

Chalmers also supplies its own GitLab instance where you log in with your CID. We highly recommend it for school projects as it doesn't require any extra setup. Important to note however is to not store personal projects there as you won't be able to access Chalmers' GitLab after you graduate, so keep this in mind.

You will also need to use this for at least one course during your bachelors, so it's at least worth remembering that it exists!

Setting up a remote

Now that you have a GitHub account you're going to want to set up an SSH-key. This is a sort of encryption key that is commonly used for connecting to other computers, but is also used for verification on GitHub and GitLab. It is required to be able to access private repositories on GitHub so this is a must.

{{ begin .windows }}

On Windows you might have to enable the OpenSSH client to be able to use SSH. How you do this might depend on your version of Windows, but on Windows 10 and 11 you should be able to follow this short guide.

1. Open your settings application.
2. Search for "Optional features".
3. In this menu you should see another search bar, search for "OpenSSH".
4. If anything shows up that means you already have everything you need and can move on to Generating keys
5. If there is nothing, click on Add a feature right at the top of the page.
6. Here search for "OpenSSH" again.
7. Click the checkbox for OpenSSH client and OpenSSH server and then press Add (2) at the bottom. You can now move on.

{{ end }}

{{ .macos.linux }} On MacOS and Linux SSH comes pre-installed on your computer so you don't need any additional setup.

Basic configuration

Git requires two configuration settings to be set before you can use it. There is one additional one we will recommend you set up as well. These options are most easily set in the command line and that's how we suggest you do it.

When using Git, especially for larger projects we want people to be able to reach us, and for people to know who we are. This is to give proper credit for your code but also so people can contact you if that code breaks or if they're wondering something about it. So we connect an email account and a name to Git. You do not have to use your real name or your private email but lots of people do. If you don't want to use your name or your private email address, you can use a nickname and a more public email address.

To configure these settings we use the git config command in the terminal. To make changes stay permanently we use the --global flag. We run these commands:

git config --global user.name "<name>"
git config --global user.email "<email address>"

Beyond these two options we also suggest changing your "default branch name". What branches are is outside the scope of this course and you'll learn about it after you've used Git for a while. Then why do we suggest changing this setting? The "default branch" is functions as the "name" of your Git history. Historically this has been called "master", which refers to "master" and "slave". This terminology is grossly outdated and nowadays we prefer using "main" and something else, common words are child, replica, and secondary. This should be default on most Git installs nowadays but not on Windows, and it won't hurt to set it explicitly. To set this option run:

git config --global init.defaultBranch "main"

Generating keys

First of all open up your terminal. From here, run ssh-keygen. When you've done this you'll be asked to write in the path to where you want to save your new key. Do not write anything here. The default location is where programs will look for the SSH key by default, so just press !kbd[Enter].

Now you'll be asked to write in a passphrase. Again, do not write anything here (unless you really know what you're doing). Certain programs like VSCode do not play nice with SSH-keys with passphrases and can straight up crash with no warnings. Just press !kbd[Enter], and when prompted to write the same passphrase again, just press !kbd[Enter] again.

You'll now be presented with your fingerprint and randomart image. Neither of these are what we need however. Your SSH-key will now be found in ~/.ssh/ (inside your home directory). You'll be presented with two files, one named id_ed25519 and one named id_ed25519.pub. The .pub file is your public key which you need to put into GitHub later. ¹

The other file is the private key, and is for verifying that you are who your public key says you are. Do not share this with anyone else. Ever. Only you should have access to your private key.

SSH-keys in GitHub.

Now the hard part is over! Hooray!

Assuming you followed our steps on creating a GitHub account, you can now put your public key in GitHub to enable SSH verification. If you are signed in you can use this link to go straight to the SSH-keys page. Go to Step 4 below in that case. If you hate clicking links, here's a full guide for finding your way there as well.

1. On the GitHub web page click on your profile icon in the top right corner.
2. Click !icon[gear] Settings (it is the sixth option from the bottom).
3. Click on SSH and GPG keys, it is under the "Access" header.

4. Click on the green New SSH key button.
5. Give it a name if you'd like, such as what computer you're on. Keep the key type as "Authentication Key" and paste in your public key which can be found at ~/.ssh/id_ed25519.pub. Do not use your private key here.
6. Press Add SSH key.

And that's it! Now you can use GitHub on this computer, or any other computer with the same SSH key pair. We recommend using different SSH keys for different computers for security reasons, but nothing is stopping you from using the same ones.

SSH-keys in GitLab.

Here you can use your CID to sign in. If you are signed in you can use this link to go right to the SSH-keys page. Go to Step 4 below in that case. If you hate clicking links, here's a full guide for finding your way there as well.

1. Click on your user icon. It will be at the top of the left sidebar.
2. Click Preferences.
3. Click on SSH Keys, it's right around the middle.

4. Click on Add new key.
5. Put in your public key and feel free to give it a name. Keep the key type as "Authentication & Signing". Here you can also change the expiration date of the key. If you'd like you can change this to any date you'd like, such as when you will graduate.
6. Press Add key.

The Basics of Git

Now that you're all set up we can get started! When using Git you store your code in repositories, directories with a special, hidden directory inside called .git. In .git, Git stores the information needed to keep track of the changes you make in the rest of the directory. We will have instructions for terminal and VSCode in parallel so use whichever you prefer.

Creating your first repository

First we need to go into a folder where want to track our files. Create one or use one we've created earlier in the book. In VSCode, to graphically initialize a repo we will enter the source control menu in the activity bar. It's the third one from the top. Here you can press the Initialize Repository button and magically you will now have an empty Git repository! Alternatively use the command palette, search for "Initialize Repository", or simply git init should choose it as the first option.

To do the same in a terminal we first have to open one in VSCode. To open one using the command palette, press !kbd[!ctrl+shift+p] and type in "Create new terminal". The terminal will by default open in the folder you have open in VSCode but you can move around as usual with cd and create directories with mkdir. To initialize your repository, write git init and press Enter. You'll get a little text blurb saying Initialized empty Git repository in /Path/to/current/directory/.git/. If you now type in ls -a you can see that you have a .git folder here which is what you want!

Your first commit

Onto your first change! In Git your changes are grouped into a commit. While you're working on your files, the idea is that you commit each time you want to save a version of your files you might want to come back to in the future. In the beginning, while you're still learning, this might be each time you and your lab partner feel done for the day. Over time, as you get more used to version control, you'll probably find yourself committing more often, each time you make a meaningful change. A good rule of thumb is to commit your changes each time you start something new. In a typical lab assignment, it could be a good idea to commit each time you've finished a task of that assignment.

In the same folder as you created your repository, create a new file and add some content!

VSCode

In your source control menu you will have a list of changed files. If you have multiple changed files you can click on them in the list to see that file. To add the code to your next commit you need to stage the file. To do this press the !icon[plus] sign that shows when you hover over one of the changed files. The file will now go from Untracked to Added. You can then continue writing code if you want, and stage those changes as well. If you do, you'll see that changed lines will now get a small marking in your editor until they are staged. You'll also be able to see which files are added, modified or untracked in the normal explorer without being in the source control menu.

If you want to use the command palette like we recommend, search for "git stage" in the command mode. Here you get a few options.

• Git: Stage Changes stages the changes in the current file. This should be your default choice!
• Git: Stage All Changes stages every change made in the directory.
• Git: Stage All Tracked Changes stages every change made to files which are already "tracked", which means they've been staged before at any point.
• Git: Stage All Untracked Changes stages every change made to files which are not yet "tracked", which means they haven't been staged before at any point.

When you feel happy with your staged changes you can now add a commit message describing what you've done and commit. To do this, write a message in the text field over the big Commit button and then press commit! You've now saved the changes and created a snapshot which you can look back to at any time. Alternatively, with the command palette, search for "Git: Commit". Most of these options don't matter for now, just choose the one that says Git: Commit.

Terminal

To do the same thing using the terminal, there are three commands we'll need. First to see the status of your repository use git status. This will show you which files are staged, which are changed, and which aren't tracked yet. To add something to your Index, use git add <files>. You can add multiple files at once by separating them with spaces. To commit your staged changes use git commit [-m "your message here].

If you do not use -m you will be put in your operating systems default editor to type in a commit message. If you want to use VSCode as your git editor you can change it with git config --global core.editor "code --wait". For Windows you'll need to have installed VSCode with Add to path selected, and for MacOS you'll need to run Shell Command: Install 'Code' command in path in VSCode's command palette. If you do this, when running git commit, you need to properly close the commit window with !kbd[!ctrl+w] or by closing it with your mouse after you've saved the file.

[Warning]

If you don't change your editor for Git, the default will likely be nano or vi. If this is vi or vim, press i, type in your commit message and then press Escape and write :wq followed by !kbd[Enter], this saves you file, quits the editors and finishes the commits. If this is nano, write your commit message and use !kbd[ctrl+x] to quit and then press Y to save the file.

Where is your file right now?

It is important to note that only the changes you stage get added to the commit. The idea is that a file change can be in one of three places:

1. On your system only, in Git speak these changes lie in your Working Directory.
2. Staged to be added to the next commit, these are local changes visible to only you. They haven't been committed yet, but are marked to be committed soon. These changes lie in what Git calls the Index.
3. Committed, these changes have been saved in your history. The state containing all the changes up to the latest commit is called HEAD.

The life of a file is basically: Working directory !icon[long-arrow-right] Index !icon[long-arrow-right] Head.

A note on commit messages

At times you might feel the urge to write commit messages like: "did some stuff" or "did the assignment". While these are fine for the time being, your message should summarize what you did. A good commit message describes in a few words what was done in that commit. Some examples of good commit messages are "first draft of section 5 in report" or "add function getContent to Main.hs"

If you can't sum up your commit in one sentence, you've probably created a too large commit

Putting your repo on GitHub/GitLab

You've now gotten to the point where you can work quite well on your own. Writing changes, staging them, and committing from time to time. But what good is working all on your own? And wouldn't it be nice having a backup of your repository just in case? This is where remotes come in, online locations where you can store your repository.

VSCode

If you followed the last chapter in setting up a Git repository you are now presented with a new button in the source control menu once all changes have been commited. It will say Publish Branch. If you press this you'll most likely be prompted to sign into GitHub. If you haven't done so already, this is the point where you'll be forced to set up two factor authentication as well. If you want to use GitLab instead, we suggest creating the repository on GitLab first and then cloning it, unless you want to use the termnial which we will cover under cloning

Once this is all done, upon pressing Publish Branch again, the command palette will get a small dropdown asking if you want to publish to a GitHub private repository or a GitHub public repository. For all of your school projects you must use private, and for something like this we suggest doing so as well. If you now sign into GitHub you'll be able to see your repo there!

An important note on public vs private repositories

Make sure that repos you use for lab assignments and projects are private. Having solutions for these publicly available is considered cheating.

Terminal

To push your repository to a remote via the terminal, you'll first need to create a repository on your chosen remote service. Unlike VSCode, which integrates with GitHub directly, using the terminal is platform-agnostic, it works the same way for GitHub, GitLab, Bitbucket, and others. For this example, we'll use GitHub. Head to GitHub and create a new repository. Give it a name, set it to private, and click Create repository. Once you're on the repository page, GitHub will show you how to either create a new repository locally or push an existing one. We'll choose the latter. Now, run the following commands in your terminal:

git remote add origin git@github.com:{YourUser}/{YourRepo}.git

Here, "origin" is the name you are assigning to your remote. Unless you have a specific reason to use another name, stick with origin as it is the default.

git branch -M main

This renames your current branch to main. The -M flag forces the rename if a branch named main already exists.

git push -u origin main

This command pushes your local commits to the remote and sets the upstream branch, which tells Git where your remote main branch is located.

Syncing

Now that you have a remote and a local repository a problem arises. How do we sync between the two? Git uses a system where you push and pull changes between your local and remote repositories. Whenever you want to add changes from your local to the remote, you push these changes. Similarly, whenever you have some changes in the remote that you wish to have in your local repository, you pull these changes in.

In VSCode there are several ways to do this. The easiest is using the command palette. In command mode (!kbd[!ctrl+Shift+p]) you can write git pull and git push respectively. Funnily enough this is exactly how you do it in the terminal as well! You might get a warning when you try to use git push that says the remote contains work you don't have locally. We'll go through what this all means in the next sub-chapter about merge conflicts.

Back in VSCode, if you really want to synchronize using your mouse the controls are a little more hidden away. In the left source control bar you can press on the three small dots next to "Changes". There you will find buttons for push and pull. You can also find them next to the dropdown called "Graph" further down, where they have custom icons. Them being so out of the way is another reason for why we highly recommend learning keyboard shortcuts. It can easily get tedious to switch between using your mouse and your keyboard.

The big sync button does't do just one of these actions, but rather both at once. There isn't really a parallel for this in the terminal except for git pull && git push.

Try adding a commit to your example repository and push this commit to your remote. If you then go to your remote repository, you should see your new commit there!

You can also create a so called README in your git repo if you'd like. A README.md file is a text file which can be displayed on a remote right under your files. This makes it valuable for documentation or information about your project.

Cloning

Now a big reason for having a remote repository is to be able to share your code with a collaborator or lab partner. Our recommended way is for all collaborators to clone the remote repo. When you clone a repo, it is automatically set up to have the proper remote.

VSCode

If you want to clone a repository from GitHub in VSCode you can either search for git clone in the command palette, or if you don't have folder opened in VSCode and go to the source control menu you will be presented with the option to clone a repository. Here you can either search for a public repository or paste in a SSH "link" to a private repository. To find this "link" go to the repository in GitHub or GitLab and press the button labeled Code. It's colored in both so it's easy to spot. Here you get a small dropdown and can select SSH.

Terminal

In the same way as above, go to your remote and find the SSH link. Then in your terminal write

git clone git@github.com:<YourUser>/<YourRepo>.git

This creates a new folder in your working directory for the repository, and puts all of the contents of it there.

Causing, and resolving merge conflicts

As always, when trying to sync things, problems might arise. What happens if you and a buddy have both made commits to the same file, and both try to push? The first push will go through just fine, but the second will be greeted with an error, there are newer commits on the remote, not present on the local! The second person will then have to pull before pushing. If you haven't touched the same files Git will just add the commits together and you'll be ready to push right away. However! If you have made conflicting commits to the same file you will have to solve a merge conflict. Merge conflicts arise when the remote and the local cannot sync. Preferably you want to avoid these, but they are bound to show up eventually so it is crucial to learn how to deal with them.

Here's a recipe for causing your first merge conflict!

1. Grab a buddy and have them clone your example repo (Or if there is no buddy readily available clone your example repository to a second location on your computer).
2. Both make commits changing the same file, e.g. one of you could change Main.hs to

   main :: IO ()
   main = putStrLn "Merge conflict incoming!"
   

   While the other changes it to,

   main :: IO ()
   main = putStrLn "I dislike merge conflicts"
   

3. Now both try to push! You'll find that one push succeeds and the other fails.
4. Pull to the local repo that failed to push, congratulations you now have a merge conflict to solve!

Now that you have a merge conflict, let's solve it! You'll find that VSCode gives you a little popup in the bottom right corner and also has a list of "Merge Changes" in the source control menu.

Clicking the file will present you with something like this:

main :: IO ()
<<<<<<< HEAD
main = putStrLn "I dislike merge conflicts"
=======
main = putStrLn "Merge conflict incoming!"
>>>>>>> main

This scary mess marks where the conflict in your file has occurred. There may be several of these in one file. They begin with <<<<<<< current version, which outlines what is currently the latest committed version of that row, after that version, there's ======= which outlines the other version of that row. Finally, the end of the conflict is marked with >>>>>>> incoming version.

But in your text editor window you might also see a button called Resolve in Merge Editor in the bottom right. Pressing this will present you with a screen that looks like this:

On the left side you can see your "Current", what you have locally, and on the right you have "Incoming", what exists on the remote. On the bottom you can see the result. Here you can choose to click on the Accept Current and Accept Incoming buttons. You can also press on both and accept both changes! But in this specific case that would make Haskell sad.

But there's also a more flexible way to solve merge conflicts, and that is using your editor. Open the file as you normally would, and you'll have the scary tags there. Write what you want the merged result to look like and remove all the tags. VSCode calls this a manual resolution. When the file contains what you want it to contain go back to source control and mark that file as resolved. You can do this either in the merge editor by clicking the Complete Merge button or by staging the file and commiting normally.

The resolved file for the above could look something like this:

main :: IO ()
main = putStrLn "I dislike merge conflicts"

Or, if you wanted to keep both prompts it could be:

main :: IO ()
main = do
  putStrLn "I dislike merge conflicts"
  putStrLn "Merge conflict incoming"

When all the files are resolved, all you have to do is commit. Congratulations! You've just solved your first merge conflict.

Terminal

This guide mainly focused on VSCode but we still recommend reading through it for terminal users. The information is important for solving a merge conflict in your terminal as well.

In the terminal if you ever push up against a remote which has newer commits you will get a message that looks like this:

What this means is you need to pull down changes. However when you do this and there are changes on the remote you'll get a merge conflict! Oh no!

We can go into more depth about merging vs rebasing if you ask us about it but we'll go through it quickly here. Our preference is setting git config --global pull.rebase.true. This means you will always use rebase when you pull. Rebase adds an additional step in solving merge conflicts but allows your git history to remain cleaner and a bit easier to work with in the future. This doesn't matter much for a single commit, but for large projects this can make a huge difference. If you want to disable it once you can use git pull --no-rebase. The VSCode terminal seems to have rebase on by default.

If you choose to use git rebase then solving your merge conflict will look like this:

• Go into the files in your editor and rewrite them as you want them to look, get rid of the HEAD and main tags.
• Stage them with git add (or git rm if you want to remove a file completely)
• Then run git rebase --continue
• You might be put in an editor to write a commit message. It will use your system default editor. Read the information about this under terminal in 4.3.
• Push your changes with git push

If you choose to use git merge then solving you merge conflict will look like this:

• Go into the files in your editor and rewrite them as you want them to look, get rid of the HEAD and main tags.
• Stage them with git add (or git rm if you want to remove a file completely)
• Commit as normal
• Push your changes with git push

A note on force pushes

When trying to push to a remote repo which has newer commits missing on the local, Git will give you two suggestions

1. The sensible thing is to pull, solve eventual merge conflicts and then push.
2. Or, you can do a force-push. Never, I repeat, never, take this option. Force push overwrites your buddies work with your own. It does not attempt to merge your different commits, but rather just overwrites the remote with your local version. This will inevitably cause headache for your buddy the next time they pull, as well as possibly remove their work.

Working with .gitignore

Keeping track of what you want, and ignoring the rest

Often when programming, you'll have files that are automatically generated. Or perhaps files are needed only by you. Or files automatically added by your OS which are not part of the codebase. Committing changes in these files often results in unnecessary work and unsolvable merge conflicts. So this raises the question: How do we tell Git what we want to keep track of? The .gitignore file!

Open your example repository and create a file called .gitignore. In .gitignore, you list the files you don't wish Git to keep track of. Say for example that we often want to compile Main.hs into the executable main. You probably don't want to have the executable in your git history, since you wouldn't know how to solve merge conflicts. You can then add main to the .gitignore. In addition to regular files, you can specify entire directories which should be excluded. As well as glob-patterns, for example, you could ignore all pdfs by adding *.pdf.

"Well okay, great now I know how to ignore, but which files should I ignore?" Great question! Here are a few basic rules, and a short justification:

1. Never track files that are generated from your other source files. Ignore the output from your compiler, and only keep track of the source code. If you're writing a document in LaTeX ignore the pdf, and keep track of the source file.

   Generated files are in general hard to solve conflicts in, and changes in them generally only reflect changes made in other documents which are more easily edited.

2. Ignore editor folders. If you open a repo in for example IntelliJ or PYCHARM these editors will create a folder called .idea which stores extra information relevant to the editor only. These can vary between people working on the project and aren't part of the source code. They are also incredibly hard to solve merge conflicts in, ignore them!

3. Ignore .DS_STORE. .DS_STORE is a hidden folder that Finder uses to keep track of metadata for directories on macOS. If you can foresee someone opening your repository in Finder, ignore this folder.

4. Files relevant to your project management tools, using stack when programming in Haskell? Ignore .stack-work. Using npm? Ignore node_modules. These often contain large amounts of libraries, the histories of which are kept in their own repos.

A Workflow for regular Lab Assignments

Sometimes it is easier just to commit to the main branch.

Now that we've gotten this far you know enough to start working on regular lab assignments! Here's a basic workflow that works well as long as you're just 2-3 people.

1. One of you, create a private remote repository through GitHub.com.
2. Add the starter files from the assignment, as well as a .gitignore. GitHub has wonderful templates for pretty much every language out there. Use one of them or start with an empty repository!
3. Clone your repo to your computer(s).
4. Start editing your files, remember to commit often, and remember to push your commits! Solve merge conflicts as they arise and enjoy Git!

It is that simple! As long as you follow these steps, you'll be collaborating easily, safe in the knowledge that your history is preserved and your project is backed up.

Make sure that the repos for school assignments are private.

Having your assignment solutions publicly available is considered cheating. This can result in disciplinary action.

This is all you need to know when using Git for your regular lab assignments. Of course, there are a whole bunch of features that we haven't covered yet. Like branching, rebasing, and GitHub features like issues and pull requests. If you're interested try to learn these on your own, however, they are not at all necessary for working on regular programming assignments.

Live Share

Live Share is a plugin for VSCode which lets you connect to someone else's computer and work inside their VSCode session. You can see it as a kind of Google Documents but for code. It has support for multiple people working in the same file and in different files at the same time. It will most likely be most useful to you during your studies and lose relevance a bit during your career. But it is easy to use and can be nice for labwork and collaboration.

Installation

To install Live Share you need VSCode set up first. If you skipped to here and haven't installed VSCode, go back to chapter 3 and install it now. Live Share can be installed as an extension in the extension marketplace, you can find it here. Once installed it should be working right away if you've followed the rest of the book until now! If you haven't logged in to GitHub or your Microsoft account you will be prompted to do so once you try to start a session.

Starting a session

Once the extension is installed you'll have a button in the bottom bar in VSCode titled Live Share, click it to start a collaboration session. You can also start a session from the command palette by searching for "live share", but you'll get a few more options then. The most interesting one right now is Start Collbaoration Session (Share). This one allows others to see and edit text in the same folder as you're currently in.

If you instead choose Start Read-Only Collaboration Session you can show code off to other people but they can not edit it. This can be useful in specific situations but is usually not what you want. In this mode you'll get a small pop up in the bottom right corner letting you change your session to Read/Write.

Starting a session will automatically copy the invitation to your clipboard. The pop-up in the corner will also let you copy it again. If you need to copy it again later you can use the command palette. Search for "live share" and you will get several options, including copying a collaborator link.

Using Live share

To join a Live share session hosted by a friend, again search for "live share" in the command palette and select Join Collaboration Session. Paste in your friends invitation link and press !kbd[Enter] to join.

Once your session is started, the "Live Share" button in the bottom left will change to "Shared". Clicking on it will allow you to manage parts of the session. This is for example where you can end the session. There is a user interface where you have more control for managing Live Share sessions in the Live Share tab in the activity bar the left.

One more useful function you'll see here (and in the command palette) is sharing a terminal. This will allow all participants of your session to use a shared terminal inside of your VSCode. Do not do this willy-nilly though, as they have access to your entire system from this terminal and can get rid of important files. What this can be useful for however is letting you share a repl, or running your program that you're writing without needing to push it to git, pull it, and then run it on your machine.

Linux

This chapter is mostly informational. It is not necessary to read it but it is helpful to know about Linux as you will have to use it during your studies.

Linux is a free and open-source operating system. This means that anyone can view the code that drives a Linux system, unlike Windows or macOS which are closed-source.

Linux comes in many variants called distributions or distros for short. They vary only slightly, it is mostly a spectrum of ease-of-use vs freedom of configuration. Some of the easiest distros to install and use include Ubuntu and Fedora, while some of the more customizable include Arch Linux, Gentoo, and nixos.

If you are interested in getting started you can either choose a more user-friendly distro such as Ubuntu or jump in knee-deep and start with something like Arch. People will tell you that one is superior to another, but the true charm of Linux lies in that it can be whatever you want. It is easy to change distro and most people try at least two or three before finding one that fits them the best.

Many computer science students use Linux as their day-to-day operating system. This is extremely educational but it is not necessary. It is possible to have both Linux and Windows/MacOS on one system and there are also other options which you will discover in the next chapter.

If you are eager to get started look at the website of one of the linked distros or try grabbing an older student and asking them for advice.

Differences between operating systems

There are three major differences between OSs.

First, and most obviously, they have different desktop interfaces and therefore also look different, although it is usually possible to make different systems very similar.

Secondly, the programs they can run are specific to each OS. A program for Windows can't be run on a Linux machine, and vice-versa. There are however workarounds to this.

Hardware support is also different between operating systems as they require different drivers.

Study tips and tricks

The following chapter will consist of tips to make your life as a student a little easier! This will consist of some general help and information, as well as information for specific courses and programming languages.

Do you have tips and tricks to share? Things that you felt helped you when you took the course? Or perhaps tips on where to go if you liked a course and would like to know more? Feel free to contribute! Follow the contributor's guide here.

General tips

This chapter will teach you some useful tricks that all computer science students should know.

When you don't know how to program something

The first thing to do is search for it on Google, Duckduckgo or similar web search sites.

Writing good searches

This may seem like a joke but a good estimate would be that over half of all new students have issues finding answers online. It is easy to get low-quality results but you can take a few steps to ensure that you get mostly good-quality results.

Before we begin, keep in mind that you will get much better results if you search in English, compared to any other language.

First, we have to decide what we want to know. As an example, suppose we would like to know how to reverse a list in python. Good searches are usually in the form <what you want> <language or program you want to use>. So for our example, we might search for How to reverse a list in python. This is more verbose than it has to be and reverse list python works just as well.

If possible, search directly on sites that are known to have good results. For example, Stackoverflow is a place where developers can ask questions and everybody can answer, think of it as Wikipedia but for questions related to programming. While the answers are curated by experienced programmers you still have to be skeptical and understand that most programming answers are good enough rather than strictly correct and you will most likely have to adapt the solution to your specific problem. This might sound like a joke, but for certain applications, especially when troubleshooting or configuring programs, reddit is a very good source of information.

Finding good search results

There are countless sites offering programming advice. Avoid sites that look like news articles or have short sentences. These are usually either computer-generated or written to rate high up on search results. If possible try and find the official documentation. Remember that you can use !kbd[!ctrl+f] to find content on the page. This is more a problem than ever with AI generated slop articles showing up as a first result very often. These aren't always worthless but can often contain incorrect or misleading information.

If in doubt, and you can't find anything helpful for your language, search for documentation specifically, it can be tricky to read and understand at times but it can be incredibly useful.

Official or high-quality sources

• Stackoverflow (and other sister-sites)
• Hoogle, search haskell functions
• MDN, web technologies such as HTML, CSS, Javascript

Artificial intelligence and chat services

We felt the need to put this in a separate sub-chapter because this is a very important topic. This chapter is our way of looking out for you!

This will start negatively, but we will have a part of this section dedicated to good uses for AI in your studies! The debate around AI is complex and intricate. It's not a black-and-white issue which is what this chapter's about. We want to highlight it's weaknesses, it's strengths, and the risks of using AI excessively.

In recent years, the usage of AI assistants in the field of computer science has truly exploded. Several options are available, all of which can assist you in your programming. Asking a chatbot a question such as "Write a program that calculates X digits of pi in Python" can provide a useful scaffold for your own code.

However, AI tools also come with risks. Most courses expect you to be able to program, write, and demonstrate your engineering skills without AI tools. They are very rarely allowed during exams and only sometimes permitted in labs. The rules for using AI in a course are determined by the examiner for that individual course. Chalmers currently has no overarching rules, so ask your examiner before you use any AI at all. Information regarding AI specifically for a bachelors/masters thesis can be found here but the same typically applies for ordinary courses as well.

These are the most important aspects taken straight from the above page but we want to include them here because this is very important:

• Being cautious of over-reliance on AI, which includes the risks of uncritically accepting AI-generated answers that can be biased or wrong. For example, do not uncritically accept a rewrite of your text, code, literature review, or analysis of your data.
• Understanding the potential for plagiarism and copyright infringements. For example, GitHub Copilot has used copyright protected code when helping programmers to code, so always be wary of such problems.
• That the use of AI tools must be clear and transparent. At a minimum, provide a description detailing how and to what extent AI tools have been utilized in your work. If you have used AI generated content in you thesis, this should be cited as other works.
• Recognizing the need to secure sensitive or proprietary information. For example, you might have access to valuable information in the organization you are writing your thesis and sharing it with the AI tool might not be advisable.

Using unapproved tools could lead to serious consequences—including suspension from your studies. It is better to talk to your teacher and try to submit something late than to submit something you do not understand yourself.

You might have heard about how big companies want to use AI and how they expect programmers to be able to use these chat services. But what usually isn't included in the headlines is that they mean as a tool.

Just like google can be a tool to help you learn things, so can AI chat services. But just like google, if you search up code that you didn't write and turn it in, that's a form of plagiarism.

You might question calling it plagiarism, but the way AI, or large language models work is they are trained on large sets of data. For programming this means they are trained on other peoples code, this is all the context they have for programming. Which means all they can do is rewrite and reuse that code they were trained on. This lets them come up with more complex functions and string together functions they have been trained on, but it also means someone else originally wrote that code.

Our goal here isn't to scare you, but we do want you to take this seriously. This university, like all universities in Sweden takes plagiarism and cheating very very seriously, and there can be very dire consequences.

The limits of AI

Additionally, AI doesn't actually understand what it's doing or saying. That might sound like a surprise, but what AI does is string together information based on it's training using statistical probability to determine a "correct" answer. This is why it can be very bad for math, or for something very basic like counting objects or elements.

As an example the ChatGPT models o4-mini and o4 give different answers for how many letters are in certain words, like strawberry. They're generating a response based on patterns, not based on reasoning.

On top of this, this is why it can be bad for programming and why you need to understand the code it tries to give you. For more esoteric, or uncommonly used languages like Haskell or VHDL, it might not actually know how a function works and just guess. These sorts of answers are what we call hallucinations.

It also often can't tie together several files or big projects, because it gets lost in the information it has received. When there's too much information it's easy for AI to get focused in on one thing or to misunderstand what you've written. It's great for small tasks and self-contained tools, because it's often similar to something it has read or been trained on before.

Using AI as an effective tool.

That said, learning to program with AI rather than relying on it can make you a much stronger and a very sought after developer. AI can help you get quick feedback, it can help you understand why a function isn't doing what you expect. It can help you troubleshoot errors that you don't understand yet. It can give you an example function, similar to what you want to write. Seeing what a working function looks like in this language using the same concepts can help you write your own code. In the same vein it can give you a starting point, what we usually call a skeleton. It won't contain all the code you need but it can help you with filler code or to create a structure to follow.

Sometimes documentation can be unclear, or have very few words and just be code. Copy the documentation and ask AI to explain it in plain language. Instead of asking it to write code to do a certain task, ask it to give you an idea for how that sort of function could be written! Do you have repetitive code you need to write but you just need to fill something in? AI can usually do the exact same thing. It's great at that sort of thing! When you give it something to write again and again, or something to summarize, it can be very effective. These ideas for how to use AI are how we want you to learn to use AI if you want to do so. AI is a supportive tool, it's not a shortcut.

But you need to understand what it does. You need to be able to write the code yourself. You are the programmer, not the AI. It is easy to write code that looks good, especially for inexperienced programmers. But teachers and examiners can often recognize AI generated code, and it's usually obvious when a student can't explain or replicate what they've submitted.

As an example, in lots of AI generated text you can see lots of em-dashes (—) being used. These are often used in fiction which AI is often trained on. In informative texts like this, excessive and out of context use can often be an indicator of AI. Stylistic choices like this aren't always an indicator of AI, some people do write like that, but it can definitely suggest the use of AI.

Although usually helpful, sometimes AI can get things very wrong. Your calculator won't correct you if you wrote the wrong number and will instead happily output the answer, not knowing that the inputs were bad. AI works the same way but works on language instead of math.

As an example for how AI can be used we've asked ChatGPT to restructure the above text for clarity. But read it as an exercise, see what it has rewritten, notice how it commonly styles text. There are many tells in the below text which an experienced reader can find in an instant. Some sentences are formatted very poorly because AI is based on text written by humans, who are also prone to errors. At times it also subtly changes the meaning of the text and what it actually means.

We also had to go through and reformat part of the text to make the source-code look readable at all and to even produce a correct result. A direct copy-paste will almost always be incorrect in some way, and formatting like that can be very important for code.

The exact prompt we gave was: "Can you rewrite this text for clarity? Note that the block under the chalmers.se link is directly quoted from that page." Without the comment regarding the quotes it also rewrites quotes, which could lead to incorrect citations.

TDA555 - Introduction to functional programming

Looking up documentation

An important part of programming in any language is knowing how to find documentation on the functions you're using. When using Haskell, hoogle is by far the most useful tool for this.

In hoogle you can search for function names to find their documentation. But sometimes it can be more useful to search for the type of the function you want. Hoogle is smart and will supply a more general function than what you are asking for, as long as it would still type-check.

Hoogle will forward you to the hackage documentation, which is a great place to learn new libraries. They usually have a reasonable readme (if they don't you probably should look at another library), and point towards tutorials helping you understand them. For example here is the hackage documentation of the wonderful library containers.

Debugging in Haskell

The computer does what you tell it to do, not what you expect it to do. This truth has haunted computer programmers of every language, and Haskell is no exception. So how do you avoid bugs in Haskell, and how do you solve them? Here are a few tips and tricks.

A note on print-debugging

In other languages, you might be used to the good old tactic of "print debugging", just sprinkle print statements in your code, and let it run. This tactic is far, far less useful in Haskell. It exists, see this, but it probably won't help you. This is the case since Haskell expressions do not execute in a sequential fashion like in imperative languages, but rather are evaluated when, and if needed.

Do not fret however, there are other ways to help debug your code in Haskell!

Debugging your functions in ghci

The most effective tool to help you in debugging Haskell is ghci. When writing Haskell code you should keep a window open with ghci at all times. While writing your function, experiment in ghci at the same time. Test every function you write with some basic examples to make sure they work as intended.

ghci does have a breakpoint debugger, but effective use of it requires thorough knowledge of lazy evaluation and even then is not all that useful.

Let the compiler do the heavy lifting

Haskell has one of the most advanced and useful type systems out there. Use it to your advantage! There are several ways for GHC to help you avoid bugs.

Supply types for your functions! Long before you start thinking about what steps your function should take, you should figure out what type you want your function to have. What does your input look like? And what does your output look like? Just by doing this step, by telling Haskell what function you are planning on writing you can avoid many errors.

As an example, say that you're writing a function for reading the contents of a file. And then want to use that function in main, and print the contents. One might try to write something like this:

getContents file = do
  contents <- readFile file
  putStrLn "Read file!"

main = do
  contents <- getContents "somefile.txt"
  print contents

[Task] Can you tell what is wrong? What will get printed do you think?

[Solution] main will always print () since that is the result of the call to putStrLn in getContents.

Now, had we gone about writing this function differently, by first figuring out that, what we want getContents to return is an IO String, then the compiler would have told us something was up.

getContents :: FilePath -> IO String
getContents file = do
  contents <- readFile file
  putStrLn "Read file!"

Debug.hs:4:3: error:
    • Couldn't match type ‘()’ with ‘[Char]’
      Expected: IO String
        Actual: IO ()
    • In a stmt of a 'do' block: putStrLn "Read file"
      In the expression:
        do contents <- readFile file
           putStrLn "Read file"
      In an equation for ‘Main.getContents’:
          Main.getContents file
            = do contents <- readFile file
                 putStrLn "Read file"
  |
4 |   putStrLn "Read file"
  |   ^^^^^^^^^^^^^^^^^^^^
Failed, no modules loaded.

GHC is telling us that it expected an IO String but got an IO (). Saying you haven't given me what you said you'd give me.

With the knowledge that GHC will at least correct you when you supply the wrong type. We can feel safer that this solution is correct:

getContents :: FilePath -> IO String
getContents file = do
  contents <- readFile file
  putStrLn "Read file!"
  return contents

Avoiding partial functions Pattern matching and recursion is the bread and butter of Haskell programming. Though by default Haskell does not give a compile time error whenever you don't cover all possible cases. Functions that can handle all their possible inputs are called total. Writing a total function is something admirable and writing partial (non-total) functions is a sin comparable to animal cruelty. Sadly we have some examples of sinful, partial functions in Prelude. Functions like:

head :: [a] -> a
head (x:_) = x

tail :: [a] -> [a]
tail (_:xs) = xs

factorial :: Integer -> Integer
factorial 0 = 1
factorial n = n * factorial (n-1)

These functions are all non-total since they don't handle all their possible inputs. Why is this a bad thing? Because almost always this signals an assumption that is not told to the compiler. And if you don't tell the compiler the assumptions you are making, the compiler cannot help you keep those assumptions true. For head and tail, this assumption would be "The input has to be non-empty", for factorial the assumption would be "the input is positive". You should strive to tell the compiler all assumptions you are making. In general, you can fix your non-total functions in two ways:

1. Restrict the input type to only ones which always return valid cases, or
2. Signal that your function does not always return values by using Maybe or Either in the output.

Which of these you prefer is up to you. In general, the first forces the function caller to make sure the input is correct. While the latter forces the caller to make sure the function didn't fail. There are situations where one or the other is more appropriate. What is never appropriate is writing a non-total function and just keeping track of the assumptions you're making on your own.

For example, head above could be fixed in two ways:

import Data.List.NonEmpty

head' :: NonEmpty a -> a
head' (x :| _) = x

head'' :: [a] -> Maybe a
head'' [] = Nothing
head'' (x:_) = Just x

There is a lot more to say about partial functions, if you're interested check out this blog post

Use QuickCheck

QuickCheck is neat. Very neat in fact. One of the things that makes QuickCheck very neat, is its ability to shrink problematic test cases. Where it tries to find an as simple/small as possible failing test case. Given, for example, the following code that splits a list into two.

split :: [a] -> ([a], [a])
split [] = ([],[])
split (x:y:zs) = (x:xs, y:ys)
  where
    (xs, ys) = split zs

Sadly the author of the code forgot to handle lists of length 1, and as such it will fail for all lists of odd length. Had we tested almost any property of split QuickCheck would have catched this case.

For example with the following property:

splitLengthsProp :: Arbitrary a => [a] -> Bool
splitLengthsProp xs = length (ys ++ zs) == length xs
  where
    (ys, zs) = split xs

Gives this result when QuickChecked:

ghci> quickCheck splitLengthsProp
*** Failed! (after 2 tests):
Exception:
  Factorial.hs:(4,1)-(7,23): Non-exhaustive patterns in function split
[()]

QuickCheck correctly found the singleton list case, pointing you in the right direction for how to solve the problem in your code!

I liked TDA555 and would like to learn more about Haskell!

Where do I go from here?

There is one known best way to learn programming: ✨ to write programs ✨. But I realize that sometimes creativity is lacking, and one can want someone to guide in what programs to write. Every December there is usually a wonderful advent calendar with small daily programming challenges called advent of code, start by doing them!

{{ begin .Data }} Data has a leaderboard for each year's advent of code! Join it here.

There are also a number of elective courses covering more functional programming. In no particular order:

• Domain-specific language of maths
• Advanced Functional Programming
• Programming language technology
• Compiler construction
• Parallel functional programming
• Types for programs and proofs

{{ end }}

Your education

This chapter serves the purpose to give you information which might be important during your time at Chalmers. This includes your rights as a student and what you can do to affect your studies. We will also include general information regarding studying at a Swedish university.

While you are enrolled in a specific program with certain mandatory courses and so on, there remains much room for shaping your own education. The actual details vary depending on program but this chapter will describe common scenarios and when it is time to make decisions. We try to remain neutral as to which choices you should make. You will however find testimonials and comparisons from both satisfied and unsatisfied students.

N.B. As it currently stands, this chapter only includes information for new students but will be expanded upon as time permits.

Credits / Högskolepoäng (HP)

All courses you take will give you hp. At Chalmers and GU most courses are standardized to 7.5hp or multiples thereof. 60hp is equivalent to full-time studies during one year, meaning that each study period will give you 15hp. In Sweden, a bachelor's degree is standardized to 180hp or 3 years worth of full-time studies, while a master's degree is another 120 hp or another 2 years worth of full-time studies.

Grades

You will encounter two different grading systems. The first is the UG scale, which consists of a pass and a fail. This scale is common to both GU and Chalmers.

You will also encounter the TH scale, which consists of U,3,4,5 where U is a failing grade. GU students will sometimes encounter the UV scale instead. This scale consists of U, G and VG, where U is a failing grade. A 5 and a VG is generally very close, although VG tends to be a few percent lower.

The UG scale is mostly used to grade projects where individual assessment is difficult, while the TH and UV are mostly used for exams. Sometimes you have several compulsory elements in a course (for example both a lab and an exam) which can use different scales. It is up to each course to define the final score, although it is most common that the exam is used to set the final score, given that all other activities have been passed.

It is rare to actually receive a failing grade on a project, usually failing a project would simply mean that you have to put in more time to complete the assignment and that a grade is withheld until the project is finished. Project courses can however be challenging since they often require a large amount of teamwork and have loose requirements. In particular, try to get to know your team and set expectations and aspirations early to avoid any miscommunication.

Try not to worry about your grade too much, extremely few relevant companies hire based solely on grades and as long as you have your degree it is usually a greater merit to have partaken in extra-curricular activities.

While studying at university there are two reasons to care about your grades, aside from the obvious fact that a higher grade means that you have learned more, which are either if you wish to do exchange studies or if you want to compete for a doctors degree. Both require greater than passing grades but we will go into more detail about that later.

Students at Chalmers who pass all their courses during their first year (including re-exams) are eligible for Adlerbertska stiftelsens stipendium.

Centrala studiestödsnämnden (CSN)

You most likely already know that CSN provides financial support to students. However, it is important to remember that you must complete a certain number of credits each year to continue to receive support. For your first year, this is 37,5hp or 5 whole courses. For following years this is increased to 45hp or 6 whole courses. Almost all courses gives you three exam oppurtunities to pass a course each academic year, the exception being courses in the final study period as they instead have re-exams during the autumn. All courses have re-exams in August and you can attempt an exam as many times as you would like.

Remember that completed labs count towards your total.

Trouble during your studies

It is very common for students to discover their limitations during their studies, as it can be very stressful. This is not only due to the intensity of the studies but also because, for many, it is the first time they are living on their own or in a foreign country.

For many, the first year is very overwhelming due to these factors, which might lead to failing your courses. Please, do not be dismayed by this, lots of people fail courses here and there, and there is absolutely no shame in it. Do not let anyone tell you otherwise.

Chalmers has a wide safety net to assist you. During the reception, you can always talk to the reception committee, who can direct you to where you can find help. Alternatively, you can always speak with your student guidance counselor.

Student Guidance Councelor

If you feel that you aren't performing as well as you would like in your studies you should speak to your student guidance councelor (SVL). They can help you with putting together a personalized study plan, getting in contact with a psychologist or point you to other resources that could help you in your studies.

Don't delay contacting your SVL, the earlier you tell them, the earlier they can help you!

Studying with functional disabilities

Students with functional disabilities have the right to get assistance. This may mean extended hours or quiet rooms during exams but also include many other kinds of help such as a study mentor. Most students do not know that they have the right to receive support even if they only consider their variations to be mild, so don't hesitate to contact Chalmers if you feel that it would help you in your studies! Please go to this page to find out more.

It is also possible to get paid for providing lecture notes. Find out more about that here.

Exams

Exams are held thrice a year for each obligatory course, usually organized as follows. First in the exam period following the course, then once more in the re-exam period of the following period. All courses have re-exams in August as well. To find exact dates you can search here.

The rules for courses and examination are found here.

Some general advice not found on Chalmers website can be found below.

Preparing for an exam

Aside from reviewing the material from class you might also be interested in looking at old exams. Old exams and solutions can be found through several channels.

• The examiner should provide some example exams on the canvas page.
• You can email the student expedition and ask for old exams and solutions. Every department has their own expedition but most exams relating to computer science can be requested from student_office.cse@chalmers.se. Please keep in mind that their response time might be over a week.

During the exam

As a student, you have certain rights and obligations which you should be aware of. The exam guards do not always know the regulations and it is therefore important for you to be informed of your rights. You can find the

• You do not need to bring your student ID, but you do need to bring a normal photo ID
• If you are suspected of cheating you may still complete your exam! The guards are not allowed to stop you and any such attempts should be reported.
• The exam guards are however allowed to stop you from writing the exam in case you are interrupting others a significant amount. So remain calm, do not shout at the exam guards that they are wrong!
• Should something go wrong, then you will be given extra time to compensate.

After the exam

The examiner must post solutions to the exam by the next working day and the results should be posted on Ladok within 15 working days. If the results are not posted by this time, contact the examiner, and if you can not get an answer from them as to why, contact your Student Educational Committee!

If you feel that some of your rights have been violated or that something else has gone wrong, please contact your Student Educational Committee. They will know how to fix any problem related to your exams.

• TKDAT: dns@dtek.se
• TKITE: snit@chalmers.it
• N1COS: studienamnd@dvet.se

Courses

All university programs have a programme overview that describes a set of courses which are possible to include within a university degree. These courses come in three flavours.

Compulsory

These are the courses you have no say over and are deemed essential for your degree.

Elective

Sometimes you have elective slots in your programme, which means that you can select any course marked as elective within your programme.¹ For master students it may be interesting to know that you can read one or two courses (around 15hp) outside of your programme and still get your masters degree. This can vary between programs so ask your student counsellor before deciding.

You can find your programme overview on Studieportalen by searching for your programme.

Compulsory elective

Your programme sometimes contains a slot where you need at least X number of those courses. These courses are called compulsory electives. Usually, each slot marked as compulsory elective have two to three courses of which you need at least one.

Människa, teknik och samhälle (MTS)

MTS courses as their name implies, do not strictly have to be about your core subjects. Every student enrolled at a Civilingenjörsprogram (TKDAT or TKITE) must take at least 7.5hp worth of courses marked as MTS.

Miljö och hållbar utveckling (MHU)

Similar to MTS courses, you need at least 7.5 credits marked as MHU if enrolled at TKDAT or TKITE.

Laborations

Laborations usually take place during the course, sometimes including the exam week for that course. Laborations tend to have an associated number of the credits of the entire course. This means that the exam rarely represents the entire 7.5 credits of a course, as it is split between labs and exam. Most labs have to be handed in and sometimes even presented in class in order to pass. It is usually hard to redo these labs during the year if you fail, so it is recommend to prioritize them and complete them when the course is given. However, if you fail your laborations, you can still complete the exam and do the labs the next time the course is held. This is often a hassle, so try to stay on top of them!

Schedule

The schedule for your courses can be found on TimeEdit. There you can search for the schedule for individual courses, or entire years for the programs. Once you have searched and gotten the schedule for what you were looking for, you can subscribe to said schedule and add it to your own calendar applications, such as Google Calendar.

Before every course starts you should go to the course canvas page to check the syllabus which may contain important information such as:

• Books and programs required for the course.
• How to sign up for labs.
• Additional scheduling not visible in TimeEdit.
• All compulsory activities of the course.

It is also important to read your student email as teachers or lab partners may contact you there. You should preferably do this daily daily or set up notifications so you know when an email arrives. It is common for students to miss important updates because they do not feel the need to look at their email!

It is your responsibility to stay up to date with published information in a timely manner.

Master's programmes

During the 5 year programme called "Civilingenjör" you will be receiving two degrees, a bachelors degree (Kandidatexamen in swedish) and your master's degree. Oftentimes you will hear people say "during your bachelors", which refers to the first 3 years. Some time in early april during your third year you will get to choose your master's program.

Unfortunately it is hard to share relevant information regarding this choice at the moment. Currently there is a reworking of the master's programmes at all of Chalmers in progress. The full plan for it will be available in October and us at DNS will do our best to share that information then, but if you're reading this in September 2025 then we suggest coming back here in a year when it's been updated with the up to date information!

What we can do is give you the small amount of information we have. The master's are being reworked and plan to be finished in 2027, which means those that started in 2024 will be the first to experience this new system. It's being reworked to add extra flexibility and to make the master's programmes more relevant for the future. They will be a bit more internationally focused with a division of a major and a minor. This means you'll be able to pick one master's that you go deep in depth in and a second master's that you'll get the core courses from.

The reasoning for this is to make that choice a bit simpler, to streamline the master's programmes and to integrate Chalmers better internationally to make exchange years simpler.

Earlier you've picked a master's and had lots of room to pick electives at the same time, which means in effect you could get important courses from several master's programmes and not just one. By changing it to work in the new way, this becomes clearer on the international stage, and should make it easier to study topics you're interested in.

Eduroam

During your time at Chalmers you will have access to something called Eduroam. It is a computer network used by universities and schools across the world. Here we will walk you through how to set it up on your computer

{{ begin .windows }}

{{ .macos .linux }} Windows

On Windows it is easy to connect to Eduroam. Follow these steps:

1. Open your network menu.
2. Click on eduroam and then Connect.
3. Enter <cid>@chalmers.se as the username and then your CID password as the password.
4. Click Connect.

{{ end }}

{{ begin .macos }}

{{ .windows .linux }} MacOS

On MacOS there are two methods, the first one is simpler but we believe it's a newer method so if it doesn't work try the other one.

Approach 1

1. In the wi-fi dropdown from the menu bar click on eduroam.
2. Sign in using <cid>@chalmers.se as the username and then your CID password as the password. Click on OK.
3. You will be asked to verify a certificate, click on continue. If prompted to put in your password or confirm with your fingerprint do that.

Approach 2

1. Go to Eduroams homepage.
2. Click on Click here to download your eduroam® installer.
3. In the menu that opens, click on Chalmers University of Technology. If you don't see it you can use the search bar at the bottom.
4. Click on eduroam®.
5. Click on Continue.
6. A profile will have been downloaded. Double click on it in finder, or click on it in your browsers downloads manager / the MacOS downloads folder on the dock.
7. You will get a pop-up saying the profile has been downloaded, click OK.
8. Open System Settings, at the top under your account name you will see a button titled Profile Downloaded, click here or navigate to it through General/Device Management
9. Double click on the profile titled eduroam®. Click on Install.
10. Put in your CID in the form <cid>@chalmers.se and your password for your CID. You will get another pop up requiring you to put in your computers account password.
11. Now you will be able to connect to Eduroam.

{{ end }}

{{ begin .linux }}

{{ .windows .macos }} Linux

On Linux, there are two different approaches you can use to connect to Eduroam. The first approach should work on most distros, but if not, try the second version.

Approach 1

1. Go to Eduroams homepage.
2. Click on Click here to download your eduroam® installer.
3. In the menu that opens, click on Chalmers University of Technology. If you don't see it you can use the search bar at the bottom.
4. Click on the blue eduroam® button and then on Continue to download the setup script.

Now that you have the script, we will need to install some programs that it depends on in order to run. If you want to look for them yourself, the packages are python3, python3-cryptography, and python3-dbus. Below we provide commands that will install the packages for a few common distros. Open a terminal and run the command for your distro. You might be prompted to enter your user password when running the command.

Ubuntu, Mint, Debian

sudo apt update && sudo apt upgrade && sudo apt install python3 python3-cryptography python3-dbus

Fedora

dnf upgrade && sudo dnf install python3 python3-cryptography python3-dbus

Arch, Manjaro, Artix

sudo pacman -Syu && sudo pacman -S python python-dbus python-cryptography

With the dependencies installed, we can continue with setting up Eduroam.

1. Run ~/Downloasds/eduroam-linux-CUoT-Eduroam.py --gui tty to start the setup.
2. Press !kbd[Enter].
3. Enter <cid>@chalmers.se as your userid, where you replace <cid> with you own CID. Press !kbd[Enter].
4. Enter the password you set for your CID followed by pressing !kbd[Enter]. Note that you will not see your password as you enter it.
5. Enter your password followed by pressing !kbd[Enter] again.

If you entered all of your details correctly, you should now be able to connect to Eduroam.

Approach 2

1. Save the certificates below in ~/.certs/eduroam.pem.
2. Open the network settings and add a new Wi-Fi network configuration.
3. Enter eduroam as the SSID.
4. Under Wi-Fi security, enter the following values and leave the other fields at their default values:

   Field	Value
   Security	WPA/WPA2 Enterprise
   Authentication	Protected EAP (PEAP)
   Anonymous identity	<cid>@chalmers.se
   Domain	eduroam.chalmers.se
   CA certificate	Choose the file from step 2
   PEAP version	Automatic
   Inner authentication	MSCHAPv2
   Username	<cid>@chalmers.se
   Password	Your CID password

5. Save the configuration.

You should now be able to connect to Eduroam.

-----BEGIN CERTIFICATE-----
MIIEMjCCAxqgAwIBAgIBATANBgkqhkiG9w0BAQUFADB7MQswCQYDVQQGEwJHQjEb
MBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHDAdTYWxmb3JkMRow
GAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UEAwwYQUFBIENlcnRpZmlj
YXRlIFNlcnZpY2VzMB4XDTA0MDEwMTAwMDAwMFoXDTI4MTIzMTIzNTk1OVowezEL
MAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UE
BwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMM
GEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczCCASIwDQYJKoZIhvcNAQEBBQADggEP
ADCCAQoCggEBAL5AnfRu4ep2hxxNRUSOvkbIgwadwSr+GB+O5AL686tdUIoWMQua
BtDFcCLNSS1UY8y2bmhGC1Pqy0wkwLxyTurxFa70VJoSCsN6sjNg4tqJVfMiWPPe
3M/vg4aijJRPn2jymJBGhCfHdr/jzDUsi14HZGWCwEiwqJH5YZ92IFCokcdmtet4
YgNW8IoaE+oxox6gmf049vYnMlhvB/VruPsUK6+3qszWY19zjNoFmag4qMsXeDZR
rOme9Hg6jc8P2ULimAyrL58OAd7vn5lJ8S3frHRNG5i1R8XlKdH5kBjHYpy+g8cm
ez6KJcfA3Z3mNWgQIJ2P2N7Sw4ScDV7oL8kCAwEAAaOBwDCBvTAdBgNVHQ4EFgQU
oBEKIz6W8Qfs4q8p74Klf9AwpLQwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF
MAMBAf8wewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9jYS5jb20v
QUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t
b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDANBgkqhkiG9w0BAQUF
AAOCAQEACFb8AvCb6P+k+tZ7xkSAzk/ExfYAWMymtrwUSWgEdujm7l3sAg9g1o1Q
GE8mTgHj5rCl7r+8dFRBv/38ErjHT1r0iWAFf2C3BUrz9vHCv8S5dIa2LX1rzNLz
Rt0vxuBqw8M0Ayx9lt1awg6nCpnBBYurDC/zXDrPbDdVCYfeU0BsWO/8tqtlbgT2
G9w84FoVxp7Z8VlIMCFlA2zs6SFz7JsDoeA3raAVGI/6ugLOpyypEBMs1OUIJqsi
l2D4kF501KKaU73yqWjgom7C12yxow+ev+to51byrvLjKzg6CYG1a4XXvi3tPxq3
smPi9WIsgtRqAEFQ8TmDn5XpNpaYbg==
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIFgTCCBGmgAwIBAgIQOXJEOvkit1HX02wQ3TE1lTANBgkqhkiG9w0BAQwFADB7
MQswCQYDVQQGEwJHQjEbMBkGA1UECAwSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYD
VQQHDAdTYWxmb3JkMRowGAYDVQQKDBFDb21vZG8gQ0EgTGltaXRlZDEhMB8GA1UE
AwwYQUFBIENlcnRpZmljYXRlIFNlcnZpY2VzMB4XDTE5MDMxMjAwMDAwMFoXDTI4
MTIzMTIzNTk1OVowgYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5
MRQwEgYDVQQHEwtKZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO
ZXR3b3JrMS4wLAYDVQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0
aG9yaXR5MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAgBJlFzYOw9sI
s9CsVw127c0n00ytUINh4qogTQktZAnczomfzD2p7PbPwdzx07HWezcoEStH2jnG
vDoZtF+mvX2do2NCtnbyqTsrkfjib9DsFiCQCT7i6HTJGLSR1GJk23+jBvGIGGqQ
Ijy8/hPwhxR79uQfjtTkUcYRZ0YIUcuGFFQ/vDP+fmyc/xadGL1RjjWmp2bIcmfb
IWax1Jt4A8BQOujM8Ny8nkz+rwWWNR9XWrf/zvk9tyy29lTdyOcSOk2uTIq3XJq0
tyA9yn8iNK5+O2hmAUTnAU5GU5szYPeUvlM3kHND8zLDU+/bqv50TmnHa4xgk97E
xwzf4TKuzJM7UXiVZ4vuPVb+DNBpDxsP8yUmazNt925H+nND5X4OpWaxKXwyhGNV
icQNwZNUMBkTrNN9N6frXTpsNVzbQdcS2qlJC9/YgIoJk2KOtWbPJYjNhLixP6Q5
D9kCnusSTJV882sFqV4Wg8y4Z+LoE53MW4LTTLPtW//e5XOsIzstAL81VXQJSdhJ
WBp/kjbmUZIO8yZ9HE0XvMnsQybQv0FfQKlERPSZ51eHnlAfV1SoPv10Yy+xUGUJ
5lhCLkMaTLTwJUdZ+gQek9QmRkpQgbLevni3/GcV4clXhB4PY9bpYrrWX1Uu6lzG
KAgEJTm4Diup8kyXHAc/DVL17e8vgg8CAwEAAaOB8jCB7zAfBgNVHSMEGDAWgBSg
EQojPpbxB+zirynvgqV/0DCktDAdBgNVHQ4EFgQUU3m/WqorSs9UgOHYm8Cd8rID
ZsswDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0gBAowCDAG
BgRVHSAAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29t
L0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDQGCCsGAQUFBwEBBCgwJjAkBggr
BgEFBQcwAYYYaHR0cDovL29jc3AuY29tb2RvY2EuY29tMA0GCSqGSIb3DQEBDAUA
A4IBAQAYh1HcdCE9nIrgJ7cz0C7M7PDmy14R3iJvm3WOnnL+5Nb+qh+cli3vA0p+
rvSNb3I8QzvAP+u431yqqcau8vzY7qN7Q/aGNnwU4M309z/+3ri0ivCRlv79Q2R+
/czSAaF9ffgZGclCKxO/WIu6pKJmBHaIkU4MiRTOok3JMrO66BQavHHxW/BBC5gA
CiIDEOUMsfnNkjcZ7Tvx5Dq2+UUTJnWvu6rvP3t3O9LEApE9GQDTF1w52z97GA1F
zZOFli9d31kWTz9RvdVFGD/tSo7oBmF0Ixa1DVBzJ0RHfxBdiSprhTEUxOipakyA
vGp4z7h/jnZymQyd/teRCBaho1+V
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIG5TCCBM2gAwIBAgIRANpDvROb0li7TdYcrMTz2+AwDQYJKoZIhvcNAQEMBQAw
gYgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpOZXcgSmVyc2V5MRQwEgYDVQQHEwtK
ZXJzZXkgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMS4wLAYD
VQQDEyVVU0VSVHJ1c3QgUlNBIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTIw
MDIxODAwMDAwMFoXDTMzMDUwMTIzNTk1OVowRDELMAkGA1UEBhMCTkwxGTAXBgNV
BAoTEEdFQU5UIFZlcmVuaWdpbmcxGjAYBgNVBAMTEUdFQU5UIE9WIFJTQSBDQSA0
MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEApYhi1aEiPsg9ZKRMAw9Q
r8Mthsr6R20VSfFeh7TgwtLQi6RSRLOh4or4EMG/1th8lijv7xnBMVZkTysFiPmT
PiLOfvz+QwO1NwjvgY+Jrs7fSoVA/TQkXzcxu4Tl3WHi+qJmKLJVu/JOuHud6mOp
LWkIbhODSzOxANJ24IGPx9h4OXDyy6/342eE6UPXCtJ8AzeumTG6Dfv5KVx24lCF
TGUzHUB+j+g0lSKg/Sf1OzgCajJV9enmZ/84ydh48wPp6vbWf1H0O3Rd3LhpMSVn
TqFTLKZSbQeLcx/l9DOKZfBCC9ghWxsgTqW9gQ7v3T3aIfSaVC9rnwVxO0VjmDdP
FNbdoxnh0zYwf45nV1QQgpRwZJ93yWedhp4ch1a6Ajwqs+wv4mZzmBSjovtV0mKw
d+CQbSToalEUP4QeJq4Udz5WNmNMI4OYP6cgrnlJ50aa0DZPlJqrKQPGL69KQQz1
2WgxvhCuVU70y6ZWAPopBa1ykbsttpLxADZre5cH573lIuLHdjx7NjpYIXRx2+QJ
URnX2qx37eZIxYXz8ggM+wXH6RDbU3V2o5DP67hXPHSAbA+p0orjAocpk2osxHKo
NSE3LCjNx8WVdxnXvuQ28tKdaK69knfm3bB7xpdfsNNTPH9ElcjscWZxpeZ5Iij8
lyrCG1z0vSWtSBsgSnUyG/sCAwEAAaOCAYswggGHMB8GA1UdIwQYMBaAFFN5v1qq
K0rPVIDh2JvAnfKyA2bLMB0GA1UdDgQWBBRvHTVJEGwy+lmgnryK6B+VvnF6DDAO
BgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHSUEFjAUBggr
BgEFBQcDAQYIKwYBBQUHAwIwOAYDVR0gBDEwLzAtBgRVHSAAMCUwIwYIKwYBBQUH
AgEWF2h0dHBzOi8vc2VjdGlnby5jb20vQ1BTMFAGA1UdHwRJMEcwRaBDoEGGP2h0
dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FDZXJ0aWZpY2F0aW9u
QXV0aG9yaXR5LmNybDB2BggrBgEFBQcBAQRqMGgwPwYIKwYBBQUHMAKGM2h0dHA6
Ly9jcnQudXNlcnRydXN0LmNvbS9VU0VSVHJ1c3RSU0FBZGRUcnVzdENBLmNydDAl
BggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNlcnRydXN0LmNvbTANBgkqhkiG9w0B
AQwFAAOCAgEAUtlC3e0xj/1BMfPhdQhUXeLjb0xp8UE28kzWE5xDzGKbfGgnrT2R
lw5gLIx+/cNVrad//+MrpTppMlxq59AsXYZW3xRasrvkjGfNR3vt/1RAl8iI31lG
hIg6dfIX5N4esLkrQeN8HiyHKH6khm4966IkVVtnxz5CgUPqEYn4eQ+4eeESrWBh
AqXaiv7HRvpsdwLYekAhnrlGpioZ/CJIT2PTTxf+GHM6cuUnNqdUzfvrQgA8kt1/
ASXx2od/M+c8nlJqrGz29lrJveJOSEMX0c/ts02WhsfMhkYa6XujUZLmvR1Eq08r
48/EZ4l+t5L4wt0DV8VaPbsEBF1EOFpz/YS2H6mSwcFaNJbnYqqJHIvm3PLJHkFm
EoLXRVrQXdCT+3wgBfgU6heCV5CYBz/YkrdWES7tiiT8sVUDqXmVlTsbiRNiyLs2
bmEWWFUl76jViIJog5fongEqN3jLIGTG/mXrJT1UyymIcobnIGrbwwRVz/mpFQo0
vBYIi1k2ThVh0Dx88BbF9YiP84dd8Fkn5wbE6FxXYJ287qfRTgmhePecPc73Yrzt
apdRcsKVGkOpaTIJP/l+lAHRLZxk/dUtyN95G++bOSQqnOCpVPabUGl2E/OEyFrp
Ipwgu2L/WJclvd6g+ZA/iWkLSMcpnFb+uX6QBqvD6+RNxul1FaB5iHY=
-----END CERTIFICATE-----

{{ end }}

Canvas

Chalmers uses a learning platform called Canvas. It's available from both the web and as an app from the app store. For every course you take, you will be able to find the syllabus and any material published alongside the course here. Upon your first log in, you should see your dashboard which will looking something like this:

You will have one card per course, and also one for your programme. Clicking on them will take you to their page. Once you register for more courses, they will also appear here.

After studying here for a while, your dashboard will become cluttered with courses that you have already finished. You can remove them from your dashboard by clicking on the three dots on the course card you want to remove, then Move, then Unfavorite.

If you want to get to a course that you've removed from your dashboard, you do so by clicking on Courses in the bar on the left, then on All Courses. Click on the !icon[star] next to a course to make it available on your dashboard again.

Notifications

To not miss out on any important information about your courses (and to not drown in too much information), it is crucial to set up your notification settings. Click on Account at the top of the bar to the left, and then on Notifications. Here you can configure how often you want notifications about various events and even turn them off completely. This can be done both for your whole account, but also on a course by course basis. You can choose to either turn them off, get them immediately, or get daily or weekly summaries. This can be configured separately for email and push notifications. Emails will go to your student email.

Structure of a course page

We will show the rough structure of a course page on Canvas. Note that it is up to every professor to design their courses Canvas page, so they will most likely be somewhat different from each other. Usually your professors will show you how they have structured their Canvas page on the very first lecture and where you will find important information.

At the top you will see any recent announcements, and the left you will see the different pages that are available for the course. Which pages you have available depends on how your professor have set up the page.

Under "Syllabus" you will find information about important people throughout the course such as your teacher, teaching assistants (TAs), and student representatives. You will also see the general structure of the course, which literature you will be using and where it is available, and how the exam will be structured.

Under "Assignments" you will see all assignments throughout the course. Here you can submit your work, see the status of submitted assignments and any comments you have received on them.

Under "People" you will see a list of everyone who takes the course, and if your course has group assignments you can also pick which group you want to part of here.

Chalmers Apps

Chalmers has a digital platform to help you use some of the programs you need for your courses. It's called Chalmers Apps and is currently being introduced. We don't know to what extent it will be used for TKDAT, but we will walk you through the basics of it here. One example of a program that's available on this platform is DigiFlisp, which will be used in one of your courses, "Grundläggande Datorteknik". If you want Chalmers instructions, they are available here.

Setup

{{ begin .windows }}

AppsAnywhere

On Windows you can install AppsAnywhere directly on your computer. Login to Chalmers Apps using CID@chalmers.se as your username and the password you set for your CID. The first time you do this you will be asked if you have installed AppsAnywhere. Click on Install Now and it should start downloading. Follow the on screen instructions. You should now see a pop-up saying "This site is trying to open AppsAnywhere Launcher". Make sure the checkbox is ticked and click on Open. You might get another pop-up saying that validation failed. In that case, click on Retry Validation. If it succeeds, click on Close Troubleshooter. You should now be finished with the installation. If you see the pop-up asking you if AppsAnywhere is installed again, just click I Already Have It.

{{ end }}

{{ begin .windows .macos }}

Windows App

On Windows and MacOS you can use a program called Windows App to get access to a remote desktop environment to access the programs. Download it from either the Microsoft Store or the App Store and login using CID@chalmer.se and your CID password. On the welcome screen, click Skip in the bottom right corner. Now you will be presented with a list of virtual desktops that you can connect to. You should already have one titled "Chalmers Apps". This is the screen you will see when you start the program the next time.

Underneath the card that says "Chalmers Apps", there is a button that says Connect, press it. This will start up you virtual environment with AppsAnywhere pre-installed and running. When you want to exit the virtual environment, press the "X" in the toolbar at the top of the screen.

{{ end }}

{{ begin .linux }}

Web interface

If you're on Linux, you can only run a remote desktop environment through the web. Go to Chalmers Apps and log in using CID@chalmers.se and your CID password. From here, click on any program, and then Launch, and then Launch the virtual desktop client. You will be taken to a list of virtual environments, with one named "Chalmers Apps". Click on it and you should enter into the virtual environment.

{{ end }}

Using it

Now that you are all setup, go to the Chalmers Apps website again (if you're using Windows App or Linux, enter the website in the virtual desktop) and login as before. Search for the program you want to start and click on Launch. AppsAnywhere should now download the program for you and launch it once it is ready.

With AppsAnywhere running, you can use it to quickly access Chalmers Apps. Do this by pressing the up arrow in the task bar and then right clicking on the AppsAnywhere icon, then pressing Launch Portal. This should take you to the website where you can now search for programs and run them.

FAQ

Who are DNS?

DNS is the Student Educational Committee for TKDAT. We help you contact your teachers, professors and examiners to mediate in situations where you feel they haven't respected you. If you have any questions regarding your rights as a student or how your studies work, you can always ask us.

My exam hasn't been reported

The examiner has 15 working days to report the exam to Ladok, but sometimes there can be a delay between the examiner, the student office and Ladok. If the exam still isn't showing up after 15 working days, please contact the examiner and politely ask about it. If you have an important deadline such as CSN or exchange studies you can always contact your examiner and ask if you can get prioritized grading. It is important for your own sake that you contact your examiner well in advance of any upcoming deadline.

You may also want to contact your Student Educational Committee in the case that your problem is not resolved.

Where can I find important dates?

Chalmers provides this site which has the current years academic plan.

I forgot to apply for a course/exam

If you forgot to apply for a course, you might be able to fix it if you contact your Student Educational Committee, but there is no guarantee. You can also contact your Director of Studies (Utbildningssekreterare) or Student Guidance Councelor (Studievägledare) directly.

If you forgot to apply for an exam, you will have to apply for the next re-exam and take that one. It is not possible to apply after the deadline by contacting the staff.

I failed an exam or laboration

The only thing that can be done is to retake them at the next opportunity. Exams that are in a program plan have to offer 3 exams during a year. A laboration will usually have to be redone next year.

Before and after an exam

Before your exam you should find where your exam will take place and at what time. Write down your anonymous code on a small piece of paper, this is usually allowed. If you forget it, the exam guards can give it to you. Try to be there around half an hour in advance to have some time to prepare yourself. You will not be allowed to have your phone near you as you are writing, make sure to turn it, and any other smart devices off and placing them in your bag or jacket. Make sure to bring identification, without it you will not be allowed to write your exam.

What is required to write an exam is a pen (with ink), a pencil and rubber (unless you're very confident). If the exam allows for a calculator you may bring one. However there is a list of permitted calculators, as well as other information regarding preparation for exams here. It is recommended to bring a water bottle or a drink, and something small to eat during the exam to have energy to complete it. Peanuts and nuts are not allowed due to allergies.

For more information on what to do before, during, and after an exam you can see this page

I feel badly treated by a teacher, teacher assistant or another student

There is a service known as safe at chalmers where you can report incidents.

My lab group is having issues, what should I do?

The short answer is to act in some way. Speak about it with the group to try to solve it. You could talk with a teacher assistant that you feel comfortable with if you think that would help.

My studies aren't going well, what can I do?

Contact your Student Guidance Councelor as soon as possible. They are experts who can help you get back on your feet.

If you have further questions

For more information about your student rights you can see this Chalmers page.

It also includes important rules and information about various topics that might be important to you as a student. If something still feels off or you need someone to mediate for you, then you can contact your Student Educational Committee.

• TKDAT: dns@dtek.se
• TKITE: snit@chalmers.it
• N1COS: studienamnd@dvet.se

Advanced usage of your editor

This section lists features that are useful for everyone but have more complex uses. It is recommended that you have at least started to write some code—even if it's just in the intro course—before looking at this. Otherwise it may be difficult to understand what these techniques do or why you would want to use them.

Shortcuts

First you should know that it is possible to edit the editor shortcuts by searching for Preferences: Open Keyboard Shortcuts in the command palette. You can also search for shortcuts here. The default shortcuts are primarily designed for users with American keyboard layouts and as such, some of them will be very unwieldy to use. Make your editor yours by changing as many shortcuts as you'd like!

Compose keys

Some shortcuts require multiple keypresses. You can enter compose mode by pressing !kbd[!ctrl+k] and then your desired shortcut. For example, opening the menu to edit shortcuts can be opened by first pressing !kbd[!ctrl+k] followed by !kbd[!ctrl+s].

Next error

If your code has errors you can easily go to the next error by pressing !kbd[!ctrl+'].

Format your code

It is easy to write messy code in the beginning. This makes it difficult for TAs and your friends to help you. It is recommended to enable the Editor: format on save option in the preferences so that your code will automatically be formatted when you save. It is also possible to manually format using !kbd[!ctrl+Shift+i].

Formatting does not work when you have syntax errors so if the command doesn't do anything you might have to fix your code first!

Connecting to a remote computer

In the first part of this book we learned about some basic commands which, while useful, barely highlight any of the actual features of using a terminal. One very powerful feature is SSH, which stands for Secure Shell. It allows you to have encrypted terminal access to any remote computer with SSH support from anywhere (anywhere in the world even!). This includes home servers, your desktop, you name it.

Keys

To facilitate remote access to computers, we use something called SSH keys. You've seen them before when we explained how to setup GitHub and GitLab, but here we will go a bit more in-depth. Keys are used to encrypt and decrypt all of the communication between you and the remote computer. They come in pairs where one key is public and shared with others and the other one is private to you. They work a bit like lock keys, but the public key can only lock the data (encrypt it), and the private key can only unlock the data (decrypt it).

To generate keys, we use the ssh-keygen command. Running the command without any flags will give you an Ed25519 key by default, but you can manually specify which type of key you want to generate with the -t flag. Different key types use different algorithms to encrypt you data, but the default is good. You will be asked where to save the key, but it is best to leave it in the default location as most programs expect them to be there. You can specify a passphrase as an extra layer of security, which is essentially a password you have to enter every time you use the key. This can be left empty if you don't want one. Some programs aren't designed to work with passphrases, which is worth having in mind.

Once the keys are generated, you will see a small ASCII-art picture, which is a fingerprint to help you recognise your keys. You will now have two new files called id_ed25519 and id_ed25519.pub inside of the .ssh folder in your home directory. The one ending in .pub is your public key and can be shared. The other one is your private key and should not be shared with anyone.

When using SSH keys together with GitHub or GitLab, you place your public key in your account. This is then used to verify that it is your account which is accessing a repository. It is especially important for private repositories as it then can deny access for those who are not supposed to be able to access it.

Connections

We can now use you new keys to connect to remote computers! This is done by running ssh <user>@<domain>, where <user> is your username on the remote computer reachable at <domain>. When connecting, you have to authenticate and verify who you are, which can be done in a few different ways. If the remote computer already has your public key, it can automatically use that to verify you. Otherwise, you will be prompted for your users password.

[Warning]

You may be prompted with a message about the authenticity of the host. This is an important step where you should verify that the key you're shown is correct. But for now we can simply write yes. If you get this message more than once for the same host, there could be something fishy going on. You can read more about ssh key verification here

Once connected, your terminal and all commands you run will execute on the remote computer. Instead of your own home folder, you will see the home folder on the remote computer. To disconnect, you can either run exit or press !kbd[Ctrl+d].

If you want to try using SSH, Chalmers provides two SSH servers at remote11.chalmers.se and remote12.chalmers.se. Here you use your CID as your username and your CID password for authentication. So would run ssh CID@remote11.chalmers.se. You will get the same home directory that you would get if you logged in physically to a computer on campus.

Copying files to and from remote computers

Now we know how to connect to a remote system, but what if you want to share files it? Then scp (secure copy) is your friend. scp works quite similar to the regular copy, except one of the paths supplied will be preceded by a hostname. To copy a file from your computer to a host write:

bash scp <filepath> <user>@<domain>:<filepath on host>

Similarly, to copy a file from a host to your computer, write:

bash scp <user>@<domain>:<filepath> <filepath to copy to>

For example, if I wanted to copy Main.hs to my home directory on one of the Chalmers remotes, I'd write scp Main.hs davhedg@remote11.chalmers.se:~/. Note that you cannot do this while SSHed into the remote system, you have to do it from your computer.

Going further

You can do a lot more using SSH which we won't go into here. Some examples include forwarding TCP connections and mounting remote file systems. All with the same secure connection. You can read more about it with man ssh or man sshfs.

Contributing

Nice, you have decided that something is missing or should be expanded upon, or perhaps just want to fix a typo. The instructions are written with the expectation that you are at least somewhat familiar with setting up a development environment. If you do not feel up to the task you should try and contact the study board at your division as they should know how to get in touch with the authors.

Request changes

If you have feedback you can file an issue on GitHub. If you have a GitHub account this is an easy process!

To do it you will select New issue on this page and then press Get started on "Feature request". You can then fill out the template, remember to put a descriptive title of what you want and describe why you want it. Here is an example request.

Installation

To set up the development environment, you first of all need mdBook installed.

You should then be able to open the book by running mdbook serve --open in the project root, which will open the web page and dynamically update as you edit it.

Contributing

To start editing pages you just have to edit the files in the ´src´ directory. The pages are written in Markdown, if you are unfamiliar with it I recommend reading this.

When you are done, you should open a pull request on the Data101 GitHub page and describe what you have changed. You may then receive feedback on your edit if there is something that has to be changed, it will then be merged with the project and reflected in the actual book!

Editing & Proofreading

Here are some tips for those who are helping test this book. Remember to fill in this Google form as you go. It is totally OK to skip chapters.

• Try all different operating systems
• Try all different education programs (you do not have to test combinations of OS and programs)
• Measure how long time it took to complete a chapter.
• Test links to see if they go to where you expect them to.
• We are mostly interested in what content should be changed, if everyone focuses on spelling mistakes then we would be wasting your time.
• As you go, write down things that were especially good/bad or immediately caught your attention.

When you are done, submit the form

Modifications to mdBook

To better support the flow of the book some modifications have been made. All modifications in the theme directory can be found by searching for BEGIN DAT101. These additions are custom commands which modify the content in some way. Some of the custom commands can be escape by prepending them with a backslash like this \\{{ .windows }}.

Special sections

You can add warning boxes and tasks with [ <section> ]. This can be either Task, Solution, Danger or Warning. The effect applies to the following paragraph.

Operating system specific content

To remove unnecessary information for some readers you can apply CSS classes to hide content for readers not using the specified OS. You can use {{ .<os> }} to hide the same paragraph and {{ begin .<os> }} and {{ end }} to hide a larger block of text. See this in action on the Git page. You can also specify multiple OS:es by separating them with a .. You can use windows, linux or macos in place of <os>. This is, for example, useful when describing installation processes.

Program specific content

You can also use the same syntax as above to hide content from other programs. The possible identifiers are Data, IT and DV.

Keyboard shortcuts

To write keyboard shortcuts, use the !kbd command. For example like this \!kbd[!ctrl+B]. !ctrl is a special command that can be used within !kbd, and it gets replaced with Ctrl or ⌘ depending on the operating system the user chooses.

Inlining icons

You can include icons as well, use \!icon[icon] to display a windows icon. Any icon from Font Awesome can be used.

Things to keep in mind

• To remain consistent, use British English.

Deploying

This book is automatically deployed using GitHub Actions. Any change pushed to the main branch is compiled and uploaded to https://data101.dtek.se.