# Understanding this guide Some conventions used in this guide: * Wherever you see text that is formatted `like this`, it is a code snippet. You should copy and paste instead of attempting to type this out; this will save you debugging time for finding your typos. * You will see a $ at the beginning of many of the lines of code. This indicates that it is to be entered and executed at the terminal prompt. Do not type in the dollar sign $. * Wherever there are `` in the the code, these are meant for you to insert your own information. Most of the time, it doesn't matter what you choose **as long as you stay consistent throughout this guide**. That means if you choose `Barney` as your ``, you must use `Barney` every time you see ``. Choose carefully. Do not include the `< >` brackets in your name. ### Before you get started Some familiarity with using the terminal will go a long way, so if you aren't comfortable with what `cd` and `ls` do, take a look at some of the Linux Shell / Terminal commands on the [Troubleshooting](../Resources/troubleshooting.md) page and the reference links on the [Technical Resources](../Resources/technical-resources.md) page. One helpful thing to do before starting any software work is to log your terminal session. This will allow you to go back and see what you did at a later date. This will also be immensely helpful if you request help from other OpenAPS contributors as you will be able to provide an entire history of the commands you used. To enable this, just run `$ script ` at the beginning of your session. It will inform you that `Script started, file is `. When you are done, simply `$ exit` and it will announce `Script done, file is `. At that point, you can review the file as necessary. ### What you won't see in this guide You won't see a full loop where you can just download the code, press a button, and have a live loop. There are many places where there are examples, and instructions, but you must do the work to understand how to communicate between devices and transfer data between reports and files. This is key for helping you understand what you are building and how it will work. In some cases, the documentation needs to be built out further, with easier to understand language and more examples. However, there are a few things (like a full `cron` example) that are not included in this guide, and intentionally so in order to ensure that you have full intent and autonomy in building your system for yourself.