├── images ├── ports.jpg ├── apache2.jpg ├── keypair.jpg ├── use-ppk.jpg ├── winscp.jpg ├── ami-choice.jpg ├── ssh-keygen.jpg ├── ssh-login.jpg ├── github-keys.jpg ├── github-paste.jpg ├── ec2-dashboard.jpg ├── instance-list.jpg └── instance-size.jpg ├── planning.csv ├── git-deployment.rst ├── git-setup.rst ├── local_dev_with_vagrant.rst ├── grunt-basics.rst ├── requirements.rst ├── readme.rst └── ec2_wordpress_and_git.md /images/ports.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/ports.jpg -------------------------------------------------------------------------------- /images/apache2.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/apache2.jpg -------------------------------------------------------------------------------- /images/keypair.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/keypair.jpg -------------------------------------------------------------------------------- /images/use-ppk.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/use-ppk.jpg -------------------------------------------------------------------------------- /images/winscp.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/winscp.jpg -------------------------------------------------------------------------------- /images/ami-choice.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/ami-choice.jpg -------------------------------------------------------------------------------- /images/ssh-keygen.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/ssh-keygen.jpg -------------------------------------------------------------------------------- /images/ssh-login.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/ssh-login.jpg -------------------------------------------------------------------------------- /images/github-keys.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/github-keys.jpg -------------------------------------------------------------------------------- /images/github-paste.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/github-paste.jpg -------------------------------------------------------------------------------- /images/ec2-dashboard.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/ec2-dashboard.jpg -------------------------------------------------------------------------------- /images/instance-list.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/instance-list.jpg -------------------------------------------------------------------------------- /images/instance-size.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/thomaswilburn/itc210-resources/HEAD/images/instance-size.jpg -------------------------------------------------------------------------------- /planning.csv: -------------------------------------------------------------------------------- 1 | Planning document: Sprint 2,,,,, 2 | ,,,,, 3 | Task,Estimate,Assigned to,Issue #,Notes, 4 | Blog post template,4 hrs,McNulty,21,, 5 | Staff custom post type,8 hrs,Greggs,18,Carried over from previous sprint, 6 | Research calendar plugins,3 hrs,McNulty,22,, 7 | Set up CSS grid,5 hours,Freamon,24,, 8 | Write user documentation for blogging,3 hrs,Carver,25,, 9 | ,,,,, 10 | Retrospective: Sprint 1,,,,, 11 | ,,,,, 12 | Task,Estimate,Actual,Assigned to,Issue #,Notes 13 | Set up SSH/GitHub sync for staging,2 hrs,1 hr,McNulty,2, 14 | Install WordPress on staging,2 hrs,2 hrs,Freamon,1, 15 | Add theme stubs to repo,2 hrs,4 hrs,Greggs,3,Some pages still need to be fleshed out 16 | Research CSS frameworks,4 hrs,6 hrs,"Perlman, Carver",4,Decided to write our own grid 17 | Set up Grunt automation for theme,8 hrs,9 hrs,Greggs,5, -------------------------------------------------------------------------------- /git-deployment.rst: -------------------------------------------------------------------------------- 1 | Deployment with Git 2 | =================== 3 | 4 | We deploy from source control, instead of uploading files individually, for several reasons: 5 | 6 | 1. It means that our server is always in a known configuration that can be easily re-created from the repo. 7 | 2. It prevents simultaneous editing, where people overwrite each others' changes. 8 | 3. It allows us to quickly roll back changes if something goes wrong. 9 | 4. It comes with a tremendous amount of infrastructure and best practice we can leverage during build processes and review. 10 | 11 | It's not hard to get a Git deploy process running, but it does involve a little groundwork. This guide is a short guide to the process, but we'll be covering it in a little more detail in class. 12 | 13 | Setup 14 | ----- 15 | 16 | First you need to link your server to the GitHub account where your repo is hosted. Follow the instructions on `this page `_ to generate an SSH key and add it to your Git credentials. 17 | 18 | You'll also need to create the repository on GitHub that will contain your repo. This needs to happen whether you have files already or not. For the purposes of this assignment, I'm going to assume that your repository is in an account named ``scc-student`` and the repo name is ``itc210-theme``, but these are just examples. 19 | 20 | Finally, you'll need to initialize your local Git repo. Your repo should be a folder inside your ``wp-content/themes`` directory, since it's a theme and that's where themes go. Creating this repo will depend on your operating system, but I would recommend using the graphical clients that are available from GitHub, since they will let you initialize the repo in any location. It may be easiest to have GitHub initialize a repo with a ``readme.md`` file, and then clone that repo into the ``themes`` directory. 21 | 22 | Note that only one person should create the initial repo. Once it's created, everyone else should either clone or fork it, depending on your comfort level (for GitHub beginners, it's probably easiest to clone and then add everyone as a collaborator on that repo). 23 | 24 | Once you have your server linked to your account, you can log in via SSH and clone the GitHub repo. Navigate to your ``wp-content/themes`` folder and type the following command to clone it (for the sample username/repo given above):: 25 | 26 | git clone git@github.com:scc-student/itc210-theme.git 27 | 28 | This will clone the repo into a folder named ``itc210-theme``. If you want to clone it into a different folder, type that folder name at the end of the command before pressing enter. 29 | 30 | Deployment 31 | ---------- 32 | 33 | Now that your server and GitHub are connected, and the repo is set up, you can deploy to the server. This is easy to do. First, you'll make changes locally, commit them, and sync them up to the GitHub repo. Second, on the server, you will log in, navigate to *inside* the theme directory, and type the following command:: 34 | 35 | git pull origin master 36 | 37 | Piece of cake! This command grabs all changes from the remote repo and fast-forwards your server to match. All changes that are checked in will be replicated on the server. **Do not change files directly**, because this will cause the two to fall out of sync, and you won't be able to easily deploy until we make them match again. You should *only* commit locally and push to GitHub, then pull from there to your staging server. -------------------------------------------------------------------------------- /git-setup.rst: -------------------------------------------------------------------------------- 1 | Setting up your GitHub repos 2 | ============================ 3 | 4 | If you haven't worked extensively with Git, it can be confusing at first. This guide will walk through a simple series of steps you can take to get your repo set up. There are many other ways to initialize and synchronize a repo, but I think this is the easiest path if you're inexperienced. It's split into two steps: first the initial repo setup, followed by the configuration for contributors. 5 | 6 | I will assume through this guide that you're using the graphical Git clients, either for Mac or Windows. You do not need to use the command line for this, although familiarity with the command line will help tremendously with your experience. I'm also going to assume that you have a local WordPress install running. 7 | 8 | Initial setup 9 | ------------- 10 | 11 | We're going to create our repositories using the GitHub website, just because it's the same no matter which OS you're on. Use the ``+`` button in the upper-right hand side to create a fresh repo, named whatever you want. *Make sure* to check the box marked "initialize this repository with a README." That will allow us to clone it immediately. 12 | 13 | Once the repo is created, the site will show you some instructions for pushing to that repo. Ignore them. Instead, click the "clone" button on the right side of the repo's web page. This should open the GitHub for Windows/Mac application, and ask where you want to save the cloned repository. Find your WordPress installation, and choose the ``wp-content/themes`` folder as the destination. This will create a new folder inside of ``themes`` with the README file from your newly-created repo. Go ahead and update the readme, then commit and sync to make sure that the connection is solid. 14 | 15 | Collaborator setup 16 | ------------------ 17 | 18 | Once the initial repo is set up, it's much easier to work with GitHub. Just click the clone button on the repo web page, then choose your ``wp-content/themes`` folder for your local web install when the GitHub client asks where you want the repository. From there, you should be all set to make changes, commit, and sync. 19 | 20 | Working together on GitHub 21 | -------------------------- 22 | 23 | One of the advantages of Git is that it provides tools for managing conflicts: those times when two people make changes to the same file, then try to commit them both. Unfortunately, the graphical GitHub clients are not always very good at dealing with conflict. I'd like to propose the following workflow instead, which takes advantage of Git's lightweight *branches*. 24 | 25 | A Git "branch" is an alternate version of the repo, isolated from any changes that are going on in the master branch. Whenever you start work on a feature, you should create a new branch. For example, if I were going to add CSS for a staffing page, I might use my GitHub client to create a "staff-css" branch. GitHub for Mac has a dedicated Branches tab that you can use to create this branch. On Windows, use the pulldown menu marked "master" (for the default branch) to create a new branch, just by typing its new name. 26 | 27 | On my branch, now you can do whatever work I want, without worrying about what anyone else is doing. Imagine you make several commits, tweaking the styles or templates until your feature is complete. At this point, you'll be ready to submit your changes back into the shared master branch, which is the branch used for staging deploys. First, make sure your local copy of master is up to date, by switching to it and pressing the sync button. Then click "manage" in the branch menu/tab of your client, drag your feature branch to the first box, and the master branch to the second, then click the merge button. Git will create a new commit that merges your changes into the master branch, taking into account commits that may have been made in the meantime by other people. 28 | 29 | If you and other person changed the same line, you'll have to determine a winner. The conflicted files will be marked in your client, and when you open them in your text editor, you'll see something like this:: 30 | 31 | <<<<<<<< HEAD 32 | This is the line or lines currently in master. 33 | ===== 34 | This is the conflicting line you changed in your branch. 35 | >>>>>>>> LONG_ANNOYING_COMMIT_HASH_STRING 36 | 37 | Using your editor, choose which change you want to keep by erasing the others (as well as the conflict markers, like ``<<<<<<< HEAD``). When all the conflict markers are removed, meaning that you've approved the changes you want to keep, the client will show a button allowing you to commit your merge, and then synchronize it up to GitHub. -------------------------------------------------------------------------------- /local_dev_with_vagrant.rst: -------------------------------------------------------------------------------- 1 | Local development with Vagrant 2 | ============================== 3 | 4 | Setting up a development environment, particularly on non-Linux hardware, can be painful - especially if your projects use different languages and databases. To solve this problem, many web developers use Vagrant, a tool for creating, managing, and deleting virtual machines on a per-project basis. 5 | 6 | A *virtual machine* is pretty much exactly what it sounds like: it's a simulation of a computer, running as a program inside of an actual hardware computer. We refer to the simulation as the "guest" and the physical computer as the "host." VM support is baked into modern operating systems and CPUs, meaning that they generally run at or near full speed. Using VMs as a development environment has several advantages over developing only inside the host OS: 7 | 8 | * Each project is isolated to its own little world, and can't interfere with other programs. This is especially nice when using multiple WordPress projects, since they will probably expect their own database. 9 | * Each operating system can be used for its strengths. I prefer the Windows GUI, but love the power of Linux development tools. With a VM, you can have both. 10 | * Onboarding becomes much easier. New teammates can simply spin up a preset VM and immediately know that everything is already hooked up and ready to go. 11 | * Your development environment can exactly match your production environment, which means you don't run into the dreaded "works on my box" problem. 12 | * Security problems and experimental hacks are isolated. If anything happens to the VM you're using, just throw it away and create a new one. 13 | 14 | For this class, I've created a walkthrough that will help you set up a Vagrant box to do your WordPress development. However, once you're comfortable with that, I would encourage you to try creating your own Vagrantfiles. It's a great way to learn about Linux and to test-drive new development stacks like Node, Rails, or Django. 15 | 16 | 1. Install software 17 | ------------------- 18 | 19 | You'll need to start by installing the software for your host computer. You'll need: 20 | 21 | * `VirtualBox `_ - Actual VM hosting software 22 | * `Vagrant `_ - Command-line software for managing VMs 23 | * `GitHub client `_ - If you don't already have it 24 | * Some kind of decent text editor 25 | 26 | 2. Download the Vagrantfile 27 | --------------------------- 28 | 29 | Grab `this gist `_ (either by copying it into your text editor, or by saving the "raw" view) into a file named "Vagrantfile" (no extension). Save this to a folder where you want to work on your project. 30 | 31 | The Vagrantfile is a "recipe" for a virtual machine. It's written in Ruby and tells Vagrant about the configuration of the VM: what operating system image to use as a base, and how to customize it once it's up and running. This particular Vagrantfile specifies a machine based on Ubuntu 12.04 with Apache, PHP, and MySQL - a classic LAMP stack. It also sets up a folder to be shared between the guest and host, so you can edit your theme and other files using your regular tools, as if they were normal files on your hard drive (because they are). 32 | 33 | 3. Start the VM 34 | --------------- 35 | 36 | Navigate to the folder with your Vagrantfile in the command line (Terminal on a Mac) and run `vagrant up`. This will launch the VM and perform first-time setup operations: 37 | 38 | 1. If you don't have the ``hashicorp/precise32`` OS image downloaded, Vagrant will go out and get it from the Internet for you. 39 | 2. Once the image is installed, it creates a new VM from it and starts it up. 40 | 3. Apache, PHP, and MySQL are downloaded from the Ubuntu software repository and installed. 41 | 4. Wordpress is downloaded and unzipped into the shared folder for you. 42 | 5. The placeholder ``index.html`` page is renamed to ``_index.html`` 43 | 44 | It'll take a little while the first time you do all this, so plug in your laptop and go get yourself a hot beverage. Hopefully, when you come back, it'll all be done and the command prompt will be waiting for you. 45 | 46 | Your new server is running on http://localhost:8080. Go ahead and visit that page to complete the WordPress configuration process and set up your first account. The MySQL login information will be dumped out to the command line window so that you can fill it in when WordPress asks for it. 47 | 48 | You can also see the files that it's using on the webserver in the ``www`` subfolder. WordPress should be installed there already, just waiting for you to work on it. 49 | 50 | 4. Control the VM 51 | ----------------- 52 | 53 | Here are some commands that you will find handy: 54 | 55 | * ``vagrant up`` - Starts a VM from a Vagrantfile. 56 | * ``vagrant halt`` - Shuts the VM down (as if the power was turned off). 57 | * ``vagrant suspend`` - Pauses the VM ("sleep mode"). 58 | * ``vagrant resume`` - Unpauses a suspended VM. 59 | * ``vagrant destroy`` - Completely clears and removes a VM from your hard drive. 60 | 61 | Note that none of these commands will affect your shared files. Even if you destroy the VM, your ``www`` folder will still remain, and can be reused if you ``vagrant up`` a new VM in the same folder. 62 | 63 | 5. Install your theme 64 | --------------------- 65 | 66 | This assumes you haven't already cloned your repo. If you have, remove it from your GUI and then continue. 67 | 68 | Although the GitHub client usually puts your repositories in the same GitHub folder each time, it can actually clone them into any location on your hard drive. Clone your team's repository, and place it in the ``/www/wp-content/themes`` subfolder of wherever you placed the Vagrantfile. If you've done this correctly, and it contains both a ``style.css`` and an ``index.php``, it should show up in the Appearance section of your WP admin dashboard. You'll be able to update it, commit, and pull new changes all from the GitHub application. 69 | 70 | 6. Profit! 71 | ---------- 72 | 73 | If you're interested in more information about working with Vagrant, their `Getting Started Guide `_ is genuinely pretty good. Please also feel free to ask me any questions via e-mail on your setup. 74 | -------------------------------------------------------------------------------- /grunt-basics.rst: -------------------------------------------------------------------------------- 1 | Grunt Basics 2 | ============ 3 | 4 | Grunt is a NodeJS build system used by a lot of web projects, since it's portable across operating systems, fast, and effective for a lot of web workflows. It can make your development significantly faster by giving you `LESS `_ compilation, templating, and live reload. 5 | 6 | For this tutorial, I'm assuming that you have a working local WordPress installation, and that you've already downloaded and installed `NodeJS `_. That should be all you need to get started. You'll also need a shell, but luckily one of those comes with GitHub for Windows and Mac. Just open up your repo in the client, and choose either "Open in Terminal" (Mac) or "Open in Git Shell" (Windows) from the menu. 7 | 8 | Installing Grunt 9 | ---------------- 10 | 11 | Getting Grunt installed is a two-step process. That's because it comes in two parts: the command itself, and the actual task runner. First, we'll get the ``grunt`` command installed. Open your command line inside your repo folder, and run the following command:: 12 | 13 | npm install grunt-cli -g 14 | 15 | This asks the Node Package Manager (NPM) to install the Grunt command line interface, and to do so globally, so that it's available anywhere on your system. **Note:** on Macs or Linux, you may need to type ``sudo`` in front of the ``npm install`` command if it needs admin access. 16 | 17 | Once the command is installed, we need to set up the actual Grunt system. Each project gets its own Grunt setup, which is installed in the ``node_modules`` folder. Installing this is also easy:: 18 | 19 | npm install grunt 20 | 21 | The ``node_modules`` folder will contain Grunt and any other Node packages that you might install for this particular project. I'd recommend that you not check these in, however. We'll tell Git to ignore ``node_modules`` by adding it to the ``.gitignore`` file. You can do that manually, or use the following command to tack it onto the file:: 22 | 23 | echo "node_modules" >> .gitignore 24 | 25 | We're also going to install a couple of Grunt plugins to do LESS compilation and file watching using NPM:: 26 | 27 | npm install grunt-contrib-less grunt-contrib-watch 28 | 29 | Your First Gruntfile 30 | -------------------- 31 | 32 | Now that we have it installed, we can tell Grunt about the tasks we want it to automate. You can run any NodeJS scripts you want from Grunt, but its biggest strength is that it can be simply configured to run plugins. In this case, we're going to enable LESS compilation and live reload using a file watch, so that simply saving the file will cause your browser to reload with the changes. 33 | 34 | Create a new file in your project folder named ``Gruntfile.js`` and insert the following code:: 35 | 36 | module.exports = function(grunt) { 37 | //load our plugins that were installed via NPM 38 | grunt.loadNpmTasks("grunt-contrib-less"); 39 | grunt.loadNpmTasks("grunt-contrib-watch"); 40 | 41 | //set our options 42 | grunt.initConfig({ 43 | less: { 44 | dev: { 45 | //compile from style.less to style.css 46 | src: "style.less", 47 | dest: "style.css" 48 | } 49 | }, 50 | watch: { 51 | options: { 52 | livereload: true 53 | }, 54 | //when .less files change, run the LESS task and livereload 55 | less: { 56 | files: ["**/*.less"], 57 | tasks: ["less"] 58 | } 59 | } 60 | }); 61 | 62 | //default task: compile LESS and start the file watch 63 | grunt.registerTask("default", ["less", "watch"]); 64 | 65 | } 66 | 67 | You should also create a ``style.less`` file for our task to compile. Here's an easy one, using a variable and some nesting:: 68 | 69 | @brand-color: darken(red, 50%); 70 | 71 | body { 72 | margin: 0; 73 | 74 | h1 { 75 | color: @brand-color; 76 | } 77 | } 78 | 79 | Now we start up our build system from the command line by simply typing ``grunt`` and pressing return. The default task will run, and you should see the following output:: 80 | 81 | $ grunt 82 | Running "less:dev" (less) task 83 | File style.css created: 0 B → 127 B 84 | 85 | Running "watch" task 86 | Waiting... 87 | 88 | The watch task is now keeping an eye on your files, and will notice when you save a new version, If you update your ``style.less`` file, you'll see it notice the change and re-run the LESS task to produce a new ``style.css`` file (which is what you should actually load in your template). 89 | 90 | Finally, let's enable live reload. The documentation for `watch `_ says to add the following script tag to our page to turn it on:: 91 | 92 | 93 | 94 | Once that's enabled, you'll see the page refresh on its own whenever the watch task runs. That means you don't need to switch back to your browser, ever: just keep it on one side of the screen, with your editor on the other, and it'll reload whenever you save a file that's being watched. Speaking personally, this is a huge productivity boost. 95 | 96 | Where you go from here 97 | ---------------------- 98 | 99 | LESS and watch are great starting tasks, but Grunt can do much, much more. Take a look at its `plugin library `_ to see many of the other capabilities Grunt can offer out of the box, including: 100 | 101 | * Compile and concatenate JavaScript into a single file for faster loading on mobile 102 | * Generate responsive images 103 | * Create a spritesheet from separate icon files 104 | * Simplify your Modernizr settings 105 | * Minify your images 106 | * Generate templates from languages like Jade and HAML 107 | * Inject custom banners and other text into all .php files 108 | * Check your PHP and JavaScript for code errors and style issues 109 | * Run automated tests against your pages to find bugs 110 | 111 | By using a tool like Grunt, it's possible to automate any of the repetitive tasks that you might otherwise find yourself doing over and over again. It also keeps processes uniform and enforces commonality: people may deviate from the plan, but Grunt will always do the same thing. As a standard industry practice, even if you don't end up using Grunt, you should be aware of it and prepared to use it when contributing to open-source projects. -------------------------------------------------------------------------------- /requirements.rst: -------------------------------------------------------------------------------- 1 | Requirements: A Requirements Document 2 | ===================================== 3 | 4 | 1. Introducing Requirements 5 | --------------------------- 6 | 7 | A requirements document is a staple of many development projects, 8 | because it provides a road map for what developers have, and have not, 9 | agreed to do. Writing a requirements document helps to scope out and 10 | organize work, and it prevents feature creep. If you search for samples 11 | online, you'll find a lot of very technical, legally-worded 12 | requirements. I prefer a more casual approach, in keeping with an Agile 13 | philosophy. Don't try to over-specify anything. 14 | 15 | Some Agile teams may decide to skip requirements, and instead start 16 | adding items directly to their task backlog, but in my experience, most 17 | of them still put a document together. Since our project is relatively 18 | well-structured (and has a set deadline) it makes sense for us to take a 19 | more structured approach. We will, however, also take the requirements 20 | from this document and add them as issues on the theme's GitHub repo, as 21 | part of this assignment. 22 | 23 | 2. Overall goals 24 | ---------------- 25 | 26 | The main goal of a requirements document is to get all stakeholders and 27 | developers onto the same page: What are we building? Why are we building 28 | it? What are the use cases that we're trying to address in this project? 29 | Perhaps more importantly, what are we choosing *not* to do? 30 | 31 | After it's written, if anyone is confused about the direction 32 | development is taking or what they should tackle next, the requirements 33 | serve as a common touchstone and reference. That said, requirements are 34 | a living document: if they say that you'll do something, but it turns 35 | out that feature is ill-specified or unrealistic given the time/money 36 | allotted, the requirements should change. 37 | 38 | 3. Background and technical assumptions 39 | --------------------------------------- 40 | 41 | At this point in our requirements document, we would typically sketch 42 | out the background of our project. In the case of a website design, we 43 | might talk about what the organization does, or what existing site they 44 | have that has proven unsatisfactory. Our background should provide 45 | context for the upcoming user stories. 46 | 47 | We also want to lay out our technical assumptions: what are our 48 | platforms, our minimum browser requirements, and any technologies that 49 | are or aren't allowed. For example, we assume for this class that you're 50 | designing a Wordpress theme. You might also assume that the site should 51 | work on IE9+ and evergreen browsers, or that mobile is or isn't a 52 | concern given your target audience. 53 | 54 | 4. User stories 55 | --------------- 56 | 57 | Having laid the groundwork, we now get to the real meat of the 58 | requirements document, which is the user stories. These are short 59 | descriptions of tasks performed by a fictional user, each of which ends 60 | up describing a feature. In some cases, the "user" in question is the 61 | admin, but often it's the external consumer of the website. This sounds 62 | more complicated than it actually is, so here's a few examples of user 63 | stories for a film festival website: 64 | 65 | User Story: Film scheduling 66 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ 67 | 68 | A user wants to get information about which films are playing at the 69 | festival, matched against their own busy schedule. They visit the site, 70 | and on the schedule page they find a listing of all the films sorted by 71 | day and time. Each film listing includes the title, director, actors, 72 | and showtime for each film. Clicking on a film title takes the user to a 73 | detail page, where they can read a short description of the film and see 74 | additional posts that relate to it. Users should also be able to filter 75 | the full listing page by day or genre, so they can quickly find which 76 | films will match their festival visit. 77 | 78 | (Notes: this user story gives us a lot of information about what the 79 | typical user wants to do with the site, which features we need to build, 80 | and some clues as to how we need to set up our taxonomy. But it doesn't 81 | overwhelm us with technical details at this stage. The goal is to give 82 | us a direction, while still allowing room to be flexible.) 83 | 84 | User story: Q&A Recaps 85 | ~~~~~~~~~~~~~~~~~~~~~~ 86 | 87 | The post-film discussions by directors are one of the most interesting 88 | and popular parts of the festival. We'll want to take these online with 89 | a series of posts that are easy to administer. A recap may include a 90 | description of the discussion, audio or video of the panel, and links to 91 | related material. Once a recap is in the system, it should show up in 92 | the film listing page for that film, so that it's easy to find from the 93 | schedule. 94 | 95 | (This story gives us some information on what we need to build on the 96 | backend, as well as how it should appear to a user. Whether we decide to 97 | go with a plugin or a custom post type is up to us, but we know that 98 | either solution must support additional metadata for this story to 99 | succeed.) 100 | 101 | User story: newsletter sign-up 102 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 103 | 104 | The festival has an existing newsletter published via MailChimp. This 105 | new website should give a user an easy way to sign up for the 106 | newsletter, available from all pages. Users should also have the option 107 | to fill out some additional information, such as what kind of films they 108 | enjoy, their contact info, and whether they would be willing to 109 | volunteer for the festival in the future. 110 | 111 | (This story will probably be fulfilled via a plugin, but it mentions 112 | some other data that an out-of-the-box solution may not handle. It also 113 | raises some questions about how we take in and store that additional 114 | data. The requirements document doesn't have to answer those questions, 115 | but it should serve as a starting point when developers start to iron 116 | out the details.) 117 | 118 | 5. Questions 119 | ------------ 120 | 121 | A requirements document in an Agile process is not an end-all, be-all 122 | answer to all questions. Rather, it may also serve as a place to 123 | document where more research is needed. It makes sense to have a section 124 | where you may leave questions, and then return to them later in the 125 | quarter. 126 | 127 | 6. Saying no 128 | ------------ 129 | 130 | Finally, it makes sense to set some limits early on for what you will 131 | *not* be doing on this project. That doesn't sound controversial, but 132 | feature creep is insidious, and it's good to put your foot down early 133 | (it keeps the team focused). For example, you might lay out the 134 | following things that you're not going to do as a team on this project: 135 | 136 | - You will not maintain an e-mail list as a part of the Wordpress 137 | database 138 | - You will not write a shopping cart, or anything that resembles a 139 | shopping cart 140 | - You will not promise any features that require a lot of custom 141 | JavaScript, unless you've got a JS guru on your team 142 | - You will not use any plugins that aren't GPL licensed 143 | 144 | Don't think of the "not doing" section as standing athwart history 145 | screaming "no." Instead, think of it as a powerful tool for making tough 146 | choices. If, while working on the project, you have to choose between 147 | two equally important, but equally time-consuming tasks, having a set of 148 | guidelines that can be used to disqualify one of them from immediate 149 | consideration is extremely helpful. 150 | -------------------------------------------------------------------------------- /readme.rst: -------------------------------------------------------------------------------- 1 | ITC 210 - Fall 2015 2 | =================== 3 | 4 | Summary 5 | ------- 6 | 7 | This is the Fall 2015 syllabus for ITC 210 at Seattle Central College. In this class, students will be partnered with designers to build a site on WordPress for an external client, using real-world tools and techniques. The resulting WordPress theme will be a useful portfolio piece (we hope). 8 | 9 | Required Materials 10 | ------------------ 11 | 12 | There is no textbook for this class. Reading materials will be posted to this repo as needed, either as tutorial texts or links to online resources. For your own part, you will need the following software programs and services: 13 | 14 | * A staging server: You will need a virtual private server (VPS) with PHP, MySQL, Git, and SSH access. Do not use so-called "shared hosting", the performance will be sub-par and you will not be able to deploy easily. Dreamhost offers VPS service for $15 a month, but I recommend looking into Linode ($10/month), Digital Ocean ($5/month), or Amazon EC2 (free for a year, varies after that). Again, *do not use shared hosting*. 15 | * A GitHub account: your WordPress theme must be hosted on GitHub, and preferably will be deployed directly from there to your staging server. All members of your team should collaborate on the same repository. You should also have Git/GitHub installed on your development machine. 16 | * A local PHP/MySQL environment for development. Depending on your computer, you may want to use one of the WAMP/MAMP stacks, or create a Linux virtual machine and work there. The goal is to work locally, then check changes to GitHub, and from there to the staging server. Under no circumstances should you be editing files directly on the remote server. 17 | * A syntax-highlighting code editor: luckily, you have many free options here, including Komodo, Brackets, Caret, and Notepad++. You may also want to look at paying for a copy of Sublime Text, which is well worth the money. 18 | 19 | Assignments 20 | ----------- 21 | 22 | For the most part, your team should work in one-week sprints, as with an Agile workflow. As developers, your work will parallel the designers, and although you do not share assignments you should consider their work an extension of yours. Developers who hang their designers out to dry will suffer penalties. Developer-specific assignments are as follows, although I reserve the right to alter or rearrange them at any time. Individual assignments will be posted with more detail throughout the quarter, although a rough list follows. All assignments are due by midnight on Friday. 23 | 24 | For each individual task within an assignment, create a bug in the issues section of your theme repo, and make sure to close it with references to the relevant commits. Tracking tasks this way will let you better estimate your time, and it will provide me with important information as to who is doing work. If you don't have commits, as far as I'm concerned, you didn't do any work. 25 | 26 | Final grades will be based on these assignments for 70% of their total, 20% for your final presentation, and 10% for class participation. Attending class is not optional. 27 | 28 | Week 1 - Server setup 29 | ##################### 30 | 31 | You should have your staging server up and running, your GitHub repo for your theme stubbed out, and a deployment connection made between the two. The theme only needs to include ``style.css`` and ``index.php`` files for now--you'll be filling in the rest as you go. Email your repo URL and development server address to me via scc@thomaswilburn.net. 32 | 33 | *Due: Friday, Oct. 2* 34 | 35 | Week 2 - Requirements document 36 | ############################## 37 | 38 | Created with your designers, this document will lay out the basic outline of intended work for your site, including extra functionality that will be handled with plugins, browser compatibility, and user stories. See the sample `requirements document `_ (which doubles as a guide to requirements docs) for more information. You should also file your first set of GitHub issues based on these requirements, laying out the first few steps that you are taking and assigning them to your team members. Once those tasks are complete, close the issues. 39 | 40 | *Due: Friday, Oct. 9* 41 | 42 | Week 3 - Information architecture 43 | ################################# 44 | 45 | At this point, you should understand the ontology of your site. With this information, make sure that your theme matches its organization: menus should lead to placeholder pages, and the template heirarchy should reflect the basic structure in which your site is constructed. You are not required to have this in its final state, but I should see evidence of groundwork being laid. 46 | 47 | *Due: Friday, Oct. 16* 48 | 49 | Week 4 - Plugin documentation and configuration 50 | ############################################### 51 | 52 | As your designers work on wireframes, you will pick out the plugins that you need to achieve their functionality requirements, install them, and write up documentation on the install/config process for your end-user. Add this information to your theme's wiki, and also as notes in the theme metadata comment block at the top of ``style.css``. Include links to their home page and support documents. 53 | 54 | *Due: Friday, Oct. 23* 55 | 56 | Week 5 - Information architecture 2 57 | ################################### 58 | 59 | In order to wireframe effectively, you will need to start putting in placeholder content and check to see that your organization holds up. For this sprint, I want to start seeing template partials and sidebars added to the page, with no shared elements being duplicated between templates. Other shared template sections, such as blog post excerpts, should also be moved into their own file and loaded via `get_template_part`. The elements you place on the page do not have to be styled at all, but they should have some sort of indicator so that I can "see" them on the staging server, such as their file name in the HTML. 60 | 61 | *Due: Friday, Oct. 30* 62 | 63 | Week 6 - Unstyled theme 64 | ####################### 65 | 66 | With wireframes complete, you should be able to duplicate their basic arrangement in the browser. Don't worry about colors or exact layout, but the flavor of the page should be there and it should match the mocks on desktop. All basic functionality and navigation should exist. Images should have placeholders. Drop-down menus should work. Plugins should be plugged in. Lorem content should fill your templates like water fills a Bruce Lee metaphor. 67 | 68 | *Due: Friday, Nov. 6* 69 | 70 | Week 7 - Responsiveness 71 | ####################### 72 | 73 | If you started with a decent grid, this work may already be done. At the end of this week, your site should be able to match the wireframes on mobile as well as desktop, in terms of physical arrangement and basic functionality. Use at least one breakpoint for mobile, if not an additional for tablets and small desktop screens. 74 | 75 | *Due: Friday, Nov. 13* 76 | 77 | Week 8 - Color palette 78 | ###################### 79 | 80 | Update your unstyled theme to match the colors and textures of the visual design. Load any webfonts that may be required. Produce a list of missing assets that your designers need to provide. 81 | 82 | *Due: Friday, Nov. 20* 83 | 84 | Week 9 - Visual match 85 | ##################### 86 | 87 | Your designers are required to have page templates ready, which means you are too. After this point, your site should be in code freeze: the rest of the time after this should be spent on testing, bug fixes, and deployment. 88 | 89 | *Due: Friday, Dec. 4* 90 | 91 | Week 12 - Presentation 92 | ###################### 93 | 94 | In the last week of class, you will present your project as a group to the rest of the students. 95 | 96 | -------------------------------------------------------------------------------- /ec2_wordpress_and_git.md: -------------------------------------------------------------------------------- 1 | # EC2, WordPress, and Git 2 | 3 | ## Introduction 4 | 5 | This guide will walk you through the process of setting up a server on Amazon EC2 running WordPress, and deploying a theme via Git. You can run a site on this platform under the free tier on Amazon for up to a year, but you will need an [AWS account](http://aws.amazon.com/free) to do so. You can also set up the same deployment process on another server, as long as you have Git installed and SSH access. I highly recommend [Digital Ocean](https://www.digitalocean.com/signups/) for this, since it offers what's essentially a one-click WordPress server image. If you do not go with EC2, go directly to the section marked "Connecting with GitHub". 6 | 7 | ## Virtual Machines and hosting 8 | 9 | Amazon's EC2 (Elastic Cloud Compute) is, at its most basic level, a virtual machine management service. That means that the "server" hosting your site is not a physical box, but a software emulation. It runs a real Linux operating system, and we interact with it as though it's a real computer, but it's actually a program sharing hardware with a bunch of other virtual computers. For web applications, this tends to be efficient and cheap, since most of the time your process is sitting idle between page requests. It's also more secure, since our programs are almost completely isolated from other users - they can't mess us up, and we can't mess them up. And if you need more horsepower, it's easy to spin up duplicate virtual machines to handle the load. 10 | 11 | Another advantage of working from a VM is that you can set up your local environment to precisely duplicate your live server. It's much easier to prevent bugs when the PHP version and other infrastructure is identical between environments. For example, I use a Windows PC for development, but run a Linux VM through a program called VirtualBox for my WordPress. Any time I need to start on a new project, I create a new VM to host it, which keeps my setup clean and predictable, and I can easily share the VM with team members running OS X or Linux. You don't have to do this for ITC210, but it's a good habit to get into, and tools like [Vagrant](http://vagrantup.com) can make it much easier to manage. 12 | 13 | In this guide, we're going to set up a virtual machine on EC2 that hosts WordPress, pretty much from scratch. Along the way, we'll learn about Linux package management, SSH key pairs, and Git remotes. These are fundamental skills that a modern web developer should have. I am **not** kidding about this: if we could only teach one thing to you at Seattle Central ...well, I would hope it was JavaScript function closures, personally. But the care and maintenance of cloud-based virtual machines is a close second. These are industry-standard best practices, and you are an order of magnitude easier to hire if you understand them. 14 | 15 | ## The most important step 16 | 17 | The following steps are going to seem like a lot of work. They're not actually that bad, and I'll try to put things into context as we go along. But just in case, here's the most important step of the guide, which we're going to refer to as "Step Zero." 18 | 19 | * **Step 0:** _Don't panic._ Relax. It's just a computer, and everything can be fixed. When you start getting frustrated, take a step away for a few minutes. If you're stuck for a long time, e-mail me. Do not wear yourself out for hours on end trying to bludgeon your way to a solution (it almost never works). 20 | 21 | ## Creating your EC2 instance 22 | 23 | ### Configuring the image 24 | 25 | Assuming you have yourself an AWS account, let's get our server running. Inside the [AWS console](https://console.aws.amazon.com/console/home), you'll see a long list of services that Amazon offers to developers. Click on the EC2 link, which should be near the top of the list. Once there, you should see a list of the resources you're using, and underneath that, a big blue button marked "Launch Instance": 26 | 27 | ![EC2 Dashboard](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/ec2-dashboard.jpg) 28 | 29 | ### Operating system, sizes, and ports 30 | 31 | ![AMI Choices](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/ami-choice.jpg) 32 | 33 | The first question you face when creating a new server is which operating system you want to install (these pre-built operating systems are referred to as "images"). We're going to go with Ubuntu, which is a stable and common Linux operating system. You can also install other Linux systems, or even Windows, but Ubuntu is a well-known platform, and it'll be easier for you to find help for it. Click the big blue "Select" button to choose the Ubuntu Server 14.04 image. 34 | 35 | ![Choosing an instance "size"](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/instance-size.jpg) 36 | 37 | On the next screen, Amazon lists the "size" of the instance you're going to create. You can stick with a "micro" VM for now - this won't be very powerful, but it will be more than enough for your needs, and you can run it for a year on Amazon's free tier after signing up. 38 | 39 | At the top of that screen, it lists all the different configuration stages that you can go through. We're going to stick with the defaults for most of them, but we do need to change the security on this VM, so click on option #6, "Configure Security Group". 40 | 41 | ![Security groups](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/ports.jpg) 42 | 43 | By default, no traffic is allowed in or out of your virtual machine except SSH. Obviously, if we're hosting web pages, we need to open up the ports that the browser uses to talk to your server. Click the "Add rule" button and select the items shown in the picture. Once that's done, you can click "Review and launch" at the bottom to continue, look over the configuration if you want, and then click "Launch" to finally start your machine. 44 | 45 | ### Keypairs, not passwords 46 | 47 | ![Creating a keypair](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/keypair.jpg) 48 | 49 | Oops! Just kidding, you can't start your machine without creating a "keypair" first. Basically, Amazon does not let you log into your VM with a password, because people usually choose terrible passwords, and then hackers crack into Amazon VMs and use them to mine bitcoins. So by default, you need to download an SSH keypair, which is a long encrypted file that will act as your "password" to the server. 50 | 51 | Go ahead and give your key a friendly name, then click the "Download key pair" button to get the file. **Do not lose this file.** Without it, you won't be able to get into your VM, and you'll have to tear it down and rebuild it from scratch. Make a copy of the file for anyone who needs access the server. 52 | 53 | Once you have downloaded the file, you can finally press the "Launch instances" button. This time, Amazon will actually start your server. Click "View instances" to go to a screen where you can see all your servers (it should still be booting up). 54 | 55 | ### SSH into your machine 56 | 57 | ![Your instance, initializing](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/instance-list.jpg) 58 | 59 | On the right side, the IP address for your server should be listed. Although you can eventually put a real domain in front of your server, you can also access it directly by IP. Let's log in now and finish setting it up. To work with this server, we're going to log in using Secure Shell, or SSH. It's an encrypted channel that connects to a remote machine and lets us use its command line as though we were sitting right in front of it. You will not need a tremendous amount of command shell knowledge to proceed, but it's another key skill that you should make time to learn. I find that William Shotts' [The Linux Command Line](http://linuxcommand.org/tlcl.php) is an excellent resource for learning how a standard shell works. 60 | 61 | #### For Windows 62 | 63 | The keypair file that Amazon had you download was a .pem file, which will work directly with a Linux or OS X terminal, but isn't compatible with Windows solutions. We're going to use [PuTTY](http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) to connect to the server, and you'll also need the [puttygen](http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html) program from the same page. Download and run puttygen.exe, then choose File -> Load Private Key and select the .pem to convert. It should show you a pop-up confirming that you've loaded the file, at which point you can click the "Save Private Key" button to create a .ppk file that PuTTY can load. 64 | 65 | ![Choosing an auth keyfile](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/use-ppk.jpg) 66 | 67 | Once you've converted the keypair, open up PuTTY and put your server's IP address in for the host name. Next, switch to the Connection -> SSH -> Auth configuration section as shown above, and load the .ppk file with the "browse" button. Once that's done, you should be able to click "Open" to start your session. On the first connection, PuTTY will ask you to confirm the server's identity with the RSA fingerprint. Just click OK. 68 | 69 | Your username for the server is `ubuntu`. The keyfile will be used instead of a password, and then it should dump you out at a command prompt, like so: 70 | 71 | ![You're in!](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/ssh-login.jpg) 72 | 73 | #### For OS X/Linux 74 | 75 | On Linux or OS X, the computer comes with an SSH client, and you don't need to download anything. Just open up your Terminal app, navigate to the directory where you saved your keyfile, and run the following command: `ssh -i keypair_name.pem ubuntu@XXX.XXX.XXX.XXX`, replacing the `XXX` portion with your server's IP address. At that point, you should be connected to the remote machine, and you'll see the message of the day (pretty much like the view above for Windows users, but obviously in a different-looking shell). 76 | 77 | You will probably get an error the first time telling you that the permissions on your key are too permissible. To fix this, run the following code to make your key read-only: `chmod 400 keypair_name.pem`. 78 | 79 | ## Server installation and config 80 | 81 | Once you're logged in, we need to install some software. Your VM starts as a blank slate - Amazon doesn't assume that you want to serve web sites with it, or what kind of technology you want to use. That makes sense, because people do in fact use EC2 for all kinds of purposes. But it does mean that the out-of-the-box experience is not great. 82 | 83 | We're going to install a standard LAMP (Linux, Apache, MySQL, and PHP) stack. Luckily, software installation on Linux is actually very easy. The `apt-get` command will contact the Ubuntu software repositories, download what we need, and set it up for us. Run the following commands to get your server running: 84 | 85 | * `sudo apt-get update` - Asks for the latest Ubuntu package listings, so that we can get current versions of all our programs 86 | * `sudo apt-get install apache2 mysql-server php5 php5-mysql git` - Downloads and installs our server stack, plus the Git software we'll need later 87 | 88 | The `sudo` portion of the command is necessary whenever we do anything administrative on the server, and gives us superuser powers. During the setup, MySQL will ask you to provide a password for the root user. Pick something memorable, and share it with your team. 89 | 90 | Once it finishes, you should be able to navigate to your server in a web browser by typing its IP address into the address bar, and you'll see the Apache server placeholder page: 91 | 92 | ![It's alive!](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/apache2.jpg) 93 | 94 | ## Last steps 95 | 96 | We have a couple more things that we need to do before we can close out the command line. First of all, we need to create your MySQL database, which is pretty easy to do from the command line. 97 | 98 | Remember that root password that it asked you to provide during the setup? Let's use it now. Type the following command and hit enter: `mysql -u root -p`. Type the MySQL root password when it asks. Once in the MySQL command line, create the database with the following SQL command: `CREATE DATABASE wordpress;`. Then hit Ctrl-C to exit the MySQL shell. 99 | 100 | Next, we need to open the web directory up so that you can upload WordPress. By default, Ubuntu's Apache server puts all web files in `/var/www/html`, but that folder is owned by the `root` user, and you can't upload there. Change ownership to your user by running this command: `sudo chown ubuntu /var/www/html -R`. 101 | 102 | ## Install WordPress 103 | 104 | Installing WordPress on EC2 is really no different than installing it anywhere else, so I won't cover it in detail here, except to say that to log into your server over SFTP, you'll also need to provide the same .pem or .ppk file that you use to log in to SSH. In WinSCP, the Advanced button for a server connection will provide a dialog with an SSH -> Authentication section, and you can select the keyfile there. You will not need to provide a password: the keypair file *is* your password. 105 | 106 | ## Connecting to GitHub 107 | 108 | Let's take a moment and talk about how Git deployment works in theory, before we knuckle down into the practice. Perhaps a charming ASCII flow chart will help: 109 | 110 | ``` 111 | +----------------+ +----------------+ +----------------+ 112 | | | | | | | 113 | | Individual | | Individual | | Individual | 114 | | developer | | developer | | developer | 115 | | | | | | | 116 | +-------+--------+ +--------+-------+ +-------+--------+ 117 | | | | 118 | | | | 119 | +------------------+ | +------------------+ 120 | | | | 121 | | | | 122 | +-------v-----v---v-------+ 123 | | | 124 | | GitHub repo | 125 | | | 126 | +------------+------------+ 127 | | 128 | | 129 | +------------v------------+ 130 | | | 131 | | Live server | 132 | | | 133 | +-------------------------+ 134 | 135 | ``` 136 | 137 | In this chart, each developer works independently on a local WordPress installation, and commits/pushes to GitHub when they have some code done. The repo serves as a shared space for code to live. At regular intervals, someone then goes to the live server and requests the latest version of the code, which will contain all the changes that individual developers have made locally. In other words, the server should always have the latest stable version of the software. 138 | 139 | This process has several advantages over the way most students work on WordPress together (i.e., everyone logs in over FTP and edits files directly): 140 | 141 | * Using GitHub, there's a running backup of your code, in case you need to restore it at any time. 142 | * When editing over FTP, care must be taken to not edit the same file simultaneously, or two people will overwrite each others' changes. With this workflow, that can't happen. 143 | * Other coders can't break the WordPress installation for everyone else if they have a syntax error, because they're only editing on their own machine. 144 | * It's easy to deploy to a new server when the client signs off, because you can just clone the repo again. 145 | 146 | Most importantly, this is how software development works at real companies. If anything, it's more elaborate there: at ArenaNet, we had three "branches" in our source control system, each of which was in ascending order of readiness (dev, stage, and live). A change had to be tested locally, then checked in to test on dev, before it was integrated up to stage and, finally, to the live environment where actual users would see it. 147 | 148 | Enough theory, let's get started. 149 | 150 | ### Create a GitHub repo 151 | 152 | The easiest way to start developing is to create the remote repo first, so that you can clone it both locally and on the staging server. In GitHub, create a new repository in one student's account, and choose the option that initializes it with a README file. This repo is going to contain your theme, and only your theme. Add files, such as the standard `style.css` stylesheet, directly to the root folder of the repo. **Do not put the theme in a subfolder of the repository.** 153 | 154 | ### Authenticate the server with GitHub 155 | 156 | Now we need to tell the live server how to connect to GitHub. Like Amazon, GitHub prefers keypairs to passwords for security reasons. Unlike Amazon, we'll need to generate our own keypair file. GitHub [provides a guide](https://help.github.com/articles/generating-ssh-keys/) for this process, but it is a little misleading and primarily intended for people working on a local server, so I'll walk you through the process here. It's still worth reading if you get lost, though. 157 | 158 | First, log into your server using SSH. Once you're in, generate the SSH keypair using the following command: `ssh-keygen -t rsa -b 4096 -C "your_email@example.com"`, which will generate an RSA-encrypted 4096-bit keypair, and tag it with your e-mail address. The utility will ask you some questions, but just hit enter to use the defaults on each one. It should look something like this: 159 | 160 | ![Using ssh-keygen](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/ssh-keygen.jpg) 161 | 162 | Keys come in two matching parts: a public and a private half. We're going to give GitHub the public half, and keep the private half to ourselves. When we connect, those two parts will match up, and GitHub will know that we are who we say we are. 163 | 164 | ![GitHub's SSH Key config](https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/github-keys.jpg) 165 | 166 | Open your GitHub settings panel, and choose the "SSH Keys" section on the left. Click the "Add SSH key" button, which will show a form with two fields. The first is a nickname that you give to this connection, and can be anything you like ("ITC 298 staging server" is a good choice). The second field is where you're going to paste the public key. In your SSH window, show the key by running this command: `cat ~/.ssh/id_rsa.pub`. You can then select the key with the mouse (everything between the two command prompts, from `ssh-rsa` to your e-mail address) and copy it from there into the browser form: 167 | 168 | ![Pasting the key into GitHub]((https://raw.githubusercontent.com/thomaswilburn/itc210-resources/master/images/github-paste.jpg) 169 | 170 | Click the green "Add Key" button to save this key. Now we just need to test it. In your SSH session, run this command to try to connect to GitHub: `ssh -T git@github.com` (say "yes" when it asks if you want to continue). It should respond like so: 171 | 172 | ``` 173 | Hi username! You've successfully authenticated, but GitHub does not provide shell access. 174 | ``` 175 | 176 | Good work! 177 | 178 | ### Cloning your theme 179 | 180 | Finally, we need to clone your repository onto the server, so that you can deploy code. Navigate to to your WordPress themes directory (usually `/var/www/html/wp-content/themes`) in your SSH shell, and run this command: `git clone git@github.com:username/repo_name.git theme_name`. This tells Git to connect to GitHub and clone your repo into a folder named `theme_name`. If you look in that folder, you should see the same files that were in your repo, now copied to the server. 181 | 182 | From this point on, whenever you want to get the latest code from the repository and deploy it to the server, log in to your server, navigate to inside your groups's theme folder, and run `git pull origin master`. For example, if my group's theme was named "Fancy Pants," my SSH session would look something like this: 183 | 184 | ```sh 185 | $ cd /var/www/html/wp-content/themes/fancy_pants 186 | $ git pull origin master 187 | From github.com:thomaswilburn/fancy_pants 188 | * branch master -> FETCH_HEAD 189 | Updating 39eddbd..92e70c8 190 | Fast-forward 191 | header.php | 4 ++-- 192 | less/menu.less | 5 +++-- 193 | less/style.less | 8 ++++++++ 194 | 3 files changed, 13 insertions(+), 4 deletions(-) 195 | $ 196 | ``` 197 | 198 | --------------------------------------------------------------------------------