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 toward 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 correctly set up Virtual Machines, a tool for running other operating systems (OS) isolated on your machine without having to reinstall your day-to-day OS, so that courses that you take in the future may assume you have access to other operating systems such as Windows or Linux.

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.

If your only experience comes from a course or two during Gymnasiet then you should still find much useful information here but may find the steps to be a bit too granular, hopefully, you can look past this!

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

Structure

Note that it if you print this page 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 the authors 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. 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 will be on the 4th of September 12:00 in HA1, where we will go through how to use Git. The authors will also be available during the PISS-kväll in the afternoon to help you.

The second lectures will be at 12:00 on the 11th of September (HA1) where we will go through the CLI and the Editor.

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 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). 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.

Graphical Remote Desktop

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 Remote desktop software. Here you can find out how to connect, depending on your operating system.

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.

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.

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 many editors to find out which would be most suitable for those just starting. Editors are one of those tools that people have strong opinions about so we decided on VSCode on the following grounds:

• Available on all platforms (Windows, macOS, Linux)
• Not specific to a certain programming language or environment (e.g. PyCharm which only works for Python)
• Extensive plugin support for all environments used in courses at Chalmers.
• Does not require any computer knowledge to get started¹

The only editor which truly fits all of these is Visual Studio Code.

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 click on the link

After installing VSCode, start it. You can now begin programming by creating a new file and start typing. We will now go through some tips on how to use the program but it is okay if you don't remember all of it, you can always come back here later when you have become more used to programming.

Further reading

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

¹ While certain evangelists will tell you otherwise, Vim and Emacs are not suitable for people without extensive knowledge of computing.

Using shortcuts

To give you a taste of what's to come, with VSCode focused, press !kbd[!ctrl+O] (note that it is the letter O not zero) and select a folder containing a project on your computer. If you do not have one, either create an empty folder or download one from the introduction course.

Programing is all about using the keyboard. While the mouse is useful most of the time when using a computer, this is not one of them. Every 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 (the vertical line where text appears), save your file or create a new file, and while this works, it is horribly inefficient compared to using shortcuts. In the beginning, you may not notice this but as you go through the semester it will become second nature to you.

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

On Macs the !kbd[!win] key is replaced by !kbd[⌘] 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 alway be 100% accurate.

You can find most of the common shortcuts in our cheatsheet. Printing one for yourself and bringing it along in your backpack is a good way remind yourself of what you can do with the editor. You should also use this as a reference durign this tutorial, but don't worry if you don't understand what all 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.

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 doing it now will make you fast as lightning by the time you graduate. You will probably neither feel motivated nor have the time 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. 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].

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 four main 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]. Anything that you can do by using your mouse can be done here. Try opening a file using the command palette!

We will learn more about the two remaining modes in the next sections.

Lines

When writing text you seldom worry about adding line breaks, but in code lines have semantic 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] as seen in the previous chapter.

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 got 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. Briefly, 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.

Git - Version Control

A must-have tool for every computer engineer, developer, or really anyone who writes text documents regularly.

Git is a set of tools that help you track the changes you make to your text files. Git 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.

Git is something you will have to use during both your studies and later during your professional career. In project courses, the bachelor's and master's theses it is almost always a requirement. And in nearly every course you will have assignments where collaboration will be far easier if you and your lab partner know and use Git. In addition to this, Git is one of the most used tools in the industry. A true industry standard, you will not find a job after your education that does not require it!

In this tutorial, we will guide you through setting up the necessary software and accounts for a modern Git experience. We will introduce you to the basic concepts of version control. Finally, we will show a basic workflow for collaboration with Git in the typical programming assignments you will encounter during your studies.

We do not yet assume that you are comfortable in the terminal, and will strongly advise using the graphical program GitKraken to handle your git needs. This is an excellent tool that helps to pedagogically visualize the version control concepts. With experience, most users of Git prefer to use the terminal commands. If you are comfortable in the terminal or would prefer to learn that way right away, look no further than this tutorial

Git setup

Install Git

{{begin .macos}}

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

1. 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. 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
   

   To install XCode's command-line tools (and its bundled Git) open a terminal and run the 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
   

2. You can install Git using Homebrew. Homebrew is a package manager for macOS, basically a command-line tool for helping you install various software. It is very useful for developers in various situations and can be installed by following the instructions here. After you've installed homebrew you should be able to type the following into a terminal:

   brew install git
   

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

   git --version
   

{{end}}

{{ begin .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-get install git

On Arch-based distros you want to run:

sudo pacman -S git

Then verify your install by running:

git --version

{{end}}

{{ .windows }} On Windows, you want to install Git by downloading the installer from here and following the instructions.

Create an account on GitHub

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

Chalmers also supplies its own GitLab instance where you log in with your CID. Which we recommend for school projects as it is without, any extra setup, and has unlimited private repositories.

We recommend setting up a GitHub account, as this account 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, among them unlimited Private Repositories, and a free subscription GitKraken Pro, which we recommend using.

Install GitKraken

With a GitHub account in hand, and Git installed I am sure you're eager to get started. And if you're comfortable in the terminal you absolutely can, but we recommend also downloading a GUI for managing Git called GitKraken.

GitKraken can be installed from their website here: GitKraken

When asked to sign in, use your newly created GitHub Student account to automatically receive the pro features for free.

You will probably also want to enable the GitLab integration in GitKrakens preferences as well.

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.

Creating your first repository

Open up gitKraken and initialize a new repository somewhere! In gitKraken you can use !kbd[!ctrl+T] to switch to a new tab, and !kbd[!ctrl+I] to start initializing a repo. For now, you can ignore .gitignore and LICENSE, just give your repo a name and location. Now you should find a screen with a whole mess of things in it, in the middle, you'll find the tracked changes in your repo. For now, there should only be one called Initial commit.

Use the shortcut !kbd[!ctrl+Shift+E] and you should be able to open the repository in an editor (You may have to set up which editor to use first, in which case GitKraken will guide you). In the editor, you should see one file README.md which is a file commonly used to describe the contents of the repo.

Your first commit

Onto your first change! In Git your changes are grouped into a commit. While you're working on your files the basic idea is that you commit each time you want to save a state 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.

With your repository open in your editor, create a new file and add some content! For example, you could add a file Main.hs and add:

main = putStrLn "Hello, Git!"

If you then open GitKraken it should have detected your change!

View the change and you'll see a panel where you can build your next commit. To add the code to your next commit, stage that file. You can then continue writing code if you want, and stage these changes as well. When you feel happy with your staged changes you can add a commit message describing what you've done and commit. You've now saved the change and created a snapshot which you can jump back to at any time!

It is important to note, that only the changes you stage get added to the commit. The basic 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 → Index → Head.

That's all there is to a commit! Test yourself! Can you add the following to Main.hs and commit the change as Add type signature to main?

main :: IO ()
main = putStrLn "Hello, Git!"

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 along 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. In GitKraken you can add a remote from the left panel. If you've logged in through GitHub you should be able to create a remote repo there. If not, it is probably best to go to Settings → Integrations and log in with your GitHub account.

You can also create your remote repository on GitHub/Lab, and add this repo as remote in GitKraken.

Now that you have a remote and 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 on your local, you pull these changes. In GitKraken there are buttons for pushing and pulling in the top panel.

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

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. To do this, simply copy the URL of the GitHub repo and use !kbd[!ctrl+N] in GitKraken. When you clone a repo, it is automatically set up to have the proper remote.

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.

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 local cannot sync (or when two branches are unable to merge, but we'll get to that later).

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 GitKraken has found a list of the conflicting files in the panel to the right, click one of them! Clicking the file will allow you to pick which version of each row to keep! But before choosing which row(s) to keep, it is worth looking at what your file looks like now. Open your file and you'll find that it looks 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.

There are two easy ways to solve the conflict.

1. In GitKraken, click the file with conflicts and choose the rows as you wish. Keep in mind that you can pick and choose from both changes, and add additional rows as well.
2. Or you could open the file in your editor. Write what you want the merged result to look like, making sure to remove all the tags. When the file contains what you want it to contain go back to GitKraken and mark that file as resolved.

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. Git should have pre-made an appropriate git message for you. Congrats! You've just solved your first merge conflict.

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 remote repository, either through Github.com or in GitKraken using !kbd[!ctrl+I].
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!
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.

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 very easy to create and very 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.

Installation

{{.windows}} To get started on Windows you have to install WSL, if you have followed the instructions from Getting started then you should already have it. Otherwise, go back to that page and install it now.

Windows also provides the native PowerShell and cmd.exe utilities. These work very differently from most other shells and are not used as often in the industry. Therefore we have decided not to focus on them in this book.

WSL is a way to run Linux on your Windows PC. You can read more about Linux here.

{{.macos}} Mac users do not have to install anything.

{{.linux}} Linux users do not have to install anything.

Getting started

{{.windows}} Start WSL by searching for Ubuntu in the window start menu.

{{.macos}} To open a terminal, press !kbd[!cmd+Space] and then enter terminal.

{{.linux}} Start a terminal, how to open one depends on your distro. Commonly !kbd[Ctrl+Alt+T], !kbd[!win+T] or !kbd[!win+Enter] usually opens one. Otherwise, search for how to open terminal <insert your distro here>.

Before we begin to write any commands you should know that your terminal remembers where on your filesystem it is. When it is started it is usually in your home folder and as you begin running commands it might change location.

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 by that it is in fact incredibly difficult to destroy anything using the terminal.

With your terminal open let's try writing a command. Enter ls and it will display all files in your working directory, the directory you are currently inside. ls stands for list.

To find out which our current working_directory is we can run pwd, print working directory.

Let's create a new directory by using mkdir, short for make directory. Run mkdir test_directory and then ls again and you will see your new directory. All words separated by a space after the command are collectively referred to as arguments. In this case. mkdir is the command, while test_directory is the first argument.

When we present new commands we might write them like this mkdir <path> the argument in angle brackets is a placeholder for whatever you decide to enter.

We can enter a different directory by using the command cd <path>. cd is short for change directory. This is synonymous with changing our working directory

[Task] What command should you run to enter the new directory that you just created?

[Solution] Run cd test_directory.

We can move files with mv <path> <new path>. mv is also commonly used to rename files. Similarly to move, there's copy cp <path> <other path>, which makes a copy of the file instead of moving it.

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

Reading and editing files

To print a text file you can use cat <path>. On the other hand, if you want to edit a file in your terminal you can usually use nano or vim. These editors are not trivial to use and rely heavily on keyboard shortcuts.

If you are interested in trying them, feel free to experiment as they are useful tools to know of. You can exit vim by pressing !kbd[Escape] and then typing :q followed by !kbd[Enter].¹

Cheatsheet

Take a look at the cheatsheet from the previous chapter to find some common tasks. We will go through most of them during this chapter.

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.
• !kbd[Ctrl+L] clears the whole terminal.

¹vim is infamously known for being difficult to exit.

Paths

A path is a string that specifies a location on your filesystem. The paths we have used so far are relative, meaning that they are interpreted from our current working directory.

Paths can also be absolute. This means that instead of interpreting the path from working directory it is instead interpreted from the root of the filesystem. All paths that start with a / are considered absolute.

There are also some special path symbols. A path starting with ./ refers to the same place as the working directory but is more explicit. Thus documents and ./documents are equivalent. There is also ../ which refers to the parent directory.

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.

Finally, it is also possible to use ~/ in most shells, which refers to the home directory, wherever you might currently be. Keep in mind that most programming languages do not understand ~/.

[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 folder and ls ../ lists the content of the parent directory.

Flags

Now lets go back go the home directory using either cd ~/ or cd ../. Most shells also allow you to simply write cd without any arguments to go to your home.

Let's try and remove the directory we just created. To do this we use the rm <path> command, you might be seeing a naming pattern by now. This is short for remove.

If you try and remove the directory by running rm test_directory it will refuse to do so as it is a directory. To remove directories you need to append a flag. Flags are switches that change the behavior of the program. In our case we need to append the --recursive flag to remove files recursively. This means that if our path is a directory we have to go through the directory and delete all files within that directory as well. Flags are added just after the command like this: rm --recursive <path>. You can add as many flags as you want to but some combinations may not make sense.

[Danger]

The rm command is the only command we are going to use that can be potentially dangerous, especially combined with the --recursive --force flags. The command will never ask you if you are sure before deleting a file, and it won't go to the trash bin, it will just be gone. Without the --recursive flag it will never delete more than one file, or delete directories with files in them so it is usually not an issue.

The help flag

Almost all command-line programs include a special flag that will print help information. This is almost always --help.

[Task] Try and get the help information for ls, what does ls --all do?

[Solution] It prints all files, even those beginning with a . which are usually hidden.

Short-hand flags

Some commands have single-letter flags which are easier to type. Most programs for example allow you to print -h instead of --help. However, the programs we have used so far do not allow this, it never hurts to try.

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

[Solution] It is -r.

Environment variables

Whenever we start a shell, some variables are assigned to the session. These are called environment variables and are refreshed every time you restart the terminal. You can see all your variables using printenv.

All variables can be used inside your shell. For example, your home directory is stored in a variable called HOME. Accessing a variable is done by prefixing the variable with $. To change the working directory to your home you could then write cd $HOME, which in my case would be translated to cd /home/dave.

$PATH

This variable contains all the directories where your shell will search for binary files (files that can be executed). Normally the command has to specify the path of the file to be executed. Without the PATH variable, we would have to write /usr/bin/ls but since /usr/bin is in our PATH variable, our shell will try and automatically find the file.

To clarify, it is possible to execute files that are not in our path. Let's say we have a file called do_cool_stuff in our current directory, then we could write ./do_cool_stuff to execute it, even if it isn't in our PATH.

At some point, you will probably try to run a command and find an error message like:

command not found: <command you just wrote>

This is almost always because you don't have the directory that your command is at, added to $PATH.

Autocompletion

Most shells allow you to autocomplete commands and arguments. If you press !kbd[Tab] the shell will try to autocomplete the command, or if there are multiple alternatives, print them. For example, writing r and then pressing !kbd[Tab] will give you all commands starting with r. When autocompleting arguments it will try to autocomplete to available files and folders.

Some shells require you to double-tap !kbd[Tab] to see all available alternatives.

Globbing

While our examples for rm only have one argument, it is possible to supply as many files as we want. It would however get very tedious to write out all files one by one so there is a tool we can use to select multiple files. This is called globbing and allows us to select all files that match a certain pattern. As an example rm *.txt deletes all .txt files in the current directory. The * is a placeholder that means anything goes. You can use this symbol wherever in a path.

Here are a few more examples.

Print all files starting with k

cat k*

Print all files start with h and end with s.txt

cat h*s.txt

deletes all files in the Downloads directory, ignoring any directories

rm Downloads/*

Connecting to a remote computer

This requires a working cid!

We have just used some basic commands which, while useful barely highlight any of the actual features of using a terminal. One very powerful feature is SSH which allows you to get a shell just like the one you have open now, but on any remote computer with SSH support. This includes home servers, your desktop, you name it.

This is particularly useful for connecting to the school PCs from anywhere, (anywhere in the world even!). The ssh command can be used with the following syntax ssh <user>@<domain>. Chalmers provides two SSH servers at remote11.chalmers.se and remote12.chalmers.se. Your username is your cid. So for example I could connect using ssh davhedg@remote11.chalmers.se. You will then be prompted for your Chalmers password. It is the same as the one you use for email and Eduroam.

[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

You should now be logged in and ready to go. You can now run the same commands as before but instead of the home folder on your computer, you will see your home folder on the Chalmers computer system. This is the same home that you will have access to if you log in physically at one of the computers on campus.

SCP, copying files from, and to a remote computer using SSH

Now just connecting to a remote shell is all fine and good, but what if you want to share files between your computer and a remote host? Then secure copy, scp is your friend. scp works quite similar to the regular copy, except one of the paths supplied will be preceded by a host. To copy a file from your computer to a host write:

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

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

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

For example, if I wanted to copy Main.hs to the remote I'd write scp Main.hs davhedg@remote11.chalmers.se:~/

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.

Virtualization

Sometimes you will have a lab that requires you to run software that is unsupported by your operating system or systems architecture. The first thing that comes to mind is to install the operating system on your computer or use a computer at school with support for the software in question.

However, this is very unflexible and there is a much better way. Virtual Machines. A Virtual Machine is a simulated computer that can run any operating system or architecture depending on your needs. The initial setup can be a bit complicated but it will make labs so much easier!

Setup

{{ begin .linux }}

Ubuntu

Install the virtualbox package using apt.

apt-get install virtualbox

Arch

Install the required packages using pacman.

pacman -S virtualbox virtualbox-host-modules-arch

{{ end }}

{{ begin .macos }}

[Danger] The new M1 mac use a different system architecture than most other systems. It is therefore very difficult to set up x64 emulation on these systems. If you need to use a virtual machine we recommend that you instead use the computers at school.

First, you have to find out which processor architecture your Mac has. This can be done by looking in About this mac. If you have an M1 model, it means that you have the Arm ISC, otherwise you have an x64 chipset.

If you have an x64 machine then download and install VirtualBox from their webpage. Select OS X hosts, which is the old name for MacOS.

{{ end }}

{{ begin .windows }}

Download and install VirtualBox from their webpage. Select Windows hosts.

{{ end }}

The next step is to download an Ubuntu install image. Ubuntu is a user-friendly distribution of Linux. If you use Windows you may remember this from the WSL setup described in Getting started.

You are now ready to get started!

Creating our first VM

With virtualbox open, select New in the menu to the right. There are several things we need to provide, first of which is a name. We will refer to the VM as ubuntu-data101 but feel free to name it something else if you wish.

• Machine folder is where you want to save the VM. The defaut option is usually fine.
• Type should be Linux.
• Version should be Ubuntu (64-bit).
• Memory size should be at least 2048MB.

You will be prompted to select Disk settings as well. The default options work fine, so just press Create.

Installing the guest OS

Start the VM by selecting your VM in the list to the left and pressing Start in the menu to the right.

A new window will open asking you for the Ubuntu Desktop image. Select the file we downloaded earlier and continue.

Another window will open which will show you the graphical output of the VM. As the VM is just booting up it will just be a terminal for now but will soon boot into an actual desktop where you will be prompted to install Ubuntu.

Most of the installation steps will be self-explanatory and the defaults should suffice in most cases. Remember to keep the language set to English.

These steps will be exactly the same should you wish to install Ubuntu to your own desktop.

Use the detect keyboard feature to correctly set the keyboard layout. There are many variants of each language layout and it can be easy to select one which has almost the same layout and it will be difficult to notice.

When prompted to select installation type, simply choose Erase disk and install ubuntu. This will only wipe the virtual drive we created and not your real drive.

When creating your user it is still good practice to use a secure password even though it is just a virtual system.

[Warning] If you forget your password you will not be able to use your VM anymore and will have to reinstall it! It is good practise to use a password manager to store your passwords. Speak to an older student to help you become more secure!

After waiting for the installation to finish, restart the VM. The VM is now ready to use!

Pro-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.

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.

Official or high-quality sources

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

ChatGPT and other AI services

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 rarely allowed during exams and only sometimes permitted in labs. If you are unsure whether you are allowed to use them, ask your teacher. Using tools that are not permitted by the examiner could result in suspension from your studies!

It is easy to write code that looks good, especially for inexperienced programmers. However, upon further inspection by an experienced examiner, it could be obvious that it was written by AI. At the very least, you are expected to fully understand how the code works and behaves.

AI is however a very powerful tool. For example, the text above was drafted by the authors and then rewritten for coherence and structure by ChatGPT!

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

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). Otherwise, it may be difficult to understand what these techniques do or why to use them.

Shortcuts

First you should know that it is possible to edit the editor shortcuts by opening >Preferences: Open Keyboard Shortcuts. 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!

Your education

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.

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.
• 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 you feel that some of your rights have been violated or that something else has gone wrong, please contact your student board. 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 program plan 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 program plan, which means that you can select any course marked as elective within your program plan.¹ For master students it may be interesting to know that you can read one or two courses (around 15hp) outside of your program plan and still get your masters degree. This can vary between programs so ask your student counsellor before deciding.

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

Compulsory elective

Your program plan 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.

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.

¹ There may still be prerequisite requirements.

FAQ

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 Studienämnd in the case that you 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 Studienämnd, but there is no guarantee. You can also contact your Director of Studes (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.

What should I bring to an exam?
What is required to do an exam is a pen (with ink), pencil and rubber. If the exam allows for a calculator, one can bring one of the allowed ones. It is recommended to bring some form of water bottle or drink, and something small to eat during the exam to have energy to complete it. Peanuts and nuts in general are not allowed due to allergies.

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

If something still feels off or you need someone to mediate for you, then you can contact your Studienämnd

They can be reached at {{ .Data }} dns@dtek.se {{ .IT }} snit@chalmers.it {{ .DV }} studienamnd@dvet.se

Course tips and tricks

The following pages consist of tips and tricks for effective studies in some specific courses. They also serve as a way to share tips and tricks for debugging, finding libraries, and documentation for the programming languages used in these courses.

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.

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 .Data }}

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.

Now cd into preprocessor and run cargo build --release which will build our custom preprocessor.

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.

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. The syntax is {{ .macos }}. See this in action on the Git page. You can use windows, linux or macos. This will hide the section from those using other operating systems. This is useful when describing installation processes.

You can also use {{begin .<os>}}

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.