Welcome to INLS161!

Monday, 20 June 2016

This is a course about pushing our boundaries and learning new things. It is also about learning new ways of doing things that we might already know how to do. Some of the topics and skills covered by the course might be old hat for some of you. Others may not have ever heard of some of these things.

Tools

We'll be using an learning a number of different tools in this class.

GitHub

⊕

To get us started, we will be using GitHub as a repository for our output.

GitHub will also help us learn about version control and the importance of keeping your versions in order.

CodeAnywhere

⊕

Following that, we will use CodeAnywhere to learn about remote operations and to do our web development tasks.

CodeAnywhere is a web-based integrated development environment (IDE). It highlights syntax for a number of different languages and makes it easy to get to your code wherever you are.

In today's session, we are going to make sure that everyone is set up on GitHub and add everyone to an GitHub organization for this class. We will also set up CodeAnywhere and make sure that everyone can log in and set up a Dev Box where you will be able to do some of your work.

Plaintext

We will approach all of the tasks for this class starting with plaintext. This means no GUIs to get in the way of our content or design.

We will learn how to run on a command line interface (CLI) and how to do some basic scripting to automate our work.

Try new things

This is a course about trying new things and learning in non-linear ways. If you are used to doing something one way, then branch out and do it in another way. This might seem difficult at first, but it will only benefit you in the long run. By increasing your flexibility and allowing you to swap different tools in and out of your toolchain as needed, you will develop a very marketable technical skillset.

Next we'll take a look at some different ways of doing things and what that means for us.

This is the meat of today's lecture.

Flexibility == technological skill

As previous mentioned in the notes, this class is about challenging your boundaries with basic technological tools. This will mean sometimes learning what seems to be a really complicated way of doing something that seems like it should be simple.

But things are not always as they appear.

You may think that it is simpler to create a webpage using some specially-designed interface for web design or, worse, creating a document in MSWord and then either copying and pasting that your work into a what-you-see-is-what-you-get (WYSIWYG) editor or exporting to HTML. You can do this, but if you want to use your markup later on or understand what is happening (as we do in this class), it is not a good option.

For example, if you want to make a PDF that is well-formatted, you have a few options as well.

One toolchain looks like this:

LibreOffice Writer (software) > ODT (file format) > Export as PDF (file format)

Another looks like tihs:

Markdown (plaintext markup) > Pandoc (software) > LaTeX (software) > PDF (file format)

The difference here is the way that the SOURCE of the files are conceived. The source for the first option is wrapped up in the interface somewhere. We can't see it. The source for the second option is the original plaintext file using markup to tell the interpreter what to do with it.

Why is this second approach advantageous?

Let's look at a second usage scenario. Let's say that I want to have the same document that I put into PDF, but as a web page also.

From LibreOffice, I have to export HTML and then upload it to a web server. Fine.

If I start with Markdown, however, my toolchain looks like this:

Markdown > Pandoc > HTML

What is better yet is that since the tools in this scenario rely on marked-up plaintext and commands that can be executed without a graphical user interface (GUI), I can probably create the documents server-side rather than having to upload them after working on them locally.

This approach helps with automation and also with having multiple desired output formats that can come from a single source.

There are easy ways to do everything, and there are hard ways to do everything. Neither are ever going to be the right way all the time. The method that you use to complete a task has to depend on the context of the task. The right way will fall somewhere in the middle or be an amalgam of both.

We'll talk more in the next few sessions about operating on a system using the command line for giving instructions and running programs.

For the next session:

I would like you to have a look at the Bill Shotts' "Learning the Shell." ⊕Shotts, William, Jr. “Learning the Shell.” LinuxCommand.org. http://linuxcommand.org/lc3_learning_the_shell.php. Go through each of the steps in the contents listed on that page and try out the commands in your CodeAnywhere DevBox interface that we set up. This is where we will start tomorrow.

I would also like you to read Tristan Harris' blog post ⊕Harris, Tristan. “How Technology Hijacks People’s Minds — from a Magician and Google’s Design Ethicist.” Medium. Last modified May 18, 2016. https://medium.com/swlh/how-technology-hijacks-peoples-minds-from-a-magician-and-google-s-design-ethicist-56d62ef5edf3. about how design choices in interfaces affect how we think and interact.