Welcome to CodeUnion's Fundamentals of Web Development workshop. If you're reading this, it means you've decided to take a bit of a risk with us. We appreciate that and promise to reward you with a fun, rewarding, and positive learning experience.
- Navigating this Repo
- The On Boarding
- On Boarding Tasks
- Your Development Environment
- The Command Line
- Git at CodeUnion
- Feedback
- Expectations
- Students should expect that teachers will...
- We expect that students will...
- Weekly Rhythm
- Projects
- Exercises
- Examples
- Group Sessions
guides/ # Helpful explanations on various topics
session-notes/ # Notes from live sessions
communications.md # How to reach instructors and other students
sprint-1/ # Instructions for Sprint 1 (weeks 1-2)
sprint-2/ # Instructions for Sprint 2 (weeks 3-4)
sprint-3/ # Instructions for Sprint 3 (weeks 5-6)
sprint-4/ # Instructions for Sprint 4 (weeks 7-8)
README.md # You are here. :)
syllabus.md # High-level overview of the workshop
The On Boarding phase will ensure your technical environment functions appropriately. It will build your understanding of our code feedback cycle and it will begin your introduction to the concepts and tools that define web development. A solid foundation and clear understanding of CodeUnion during the On Boarding phase will help you acclimate to our system of building technical skills.
On Boarding involves a decent amount of 'grunt work'. The work might seem chunky, unclear and overly complicated. It is unclear, chunky and overly complicated. We will help you with everything. Your job is to dive into the pool without hesitation and ask us every time you encounter a step, task, turn, juke or jive that you can't deal with or don't understand. Our job is to make sure you are supported and that you can finish the on boarding phase in a timely fashion.
Please complete in order.
- Read and digest the syllabus.
- Read and digest communications and help.
- Make sure you ask for help or support whenever you feel stuck.
- Read and digest working with the development environment.
- Ensure you have ruby 2.0 or higher, a code editor like sublime and git functioning.
- Read and digest git basics.
- Visit your own github profile, upload a pic and add a publicly viewable email address.
- Fork, clone and run the dot env tutorial.
- Understand how to correctly store 'environmental keys'.
- If you find yourself getting require errors, look at the bundle tutorial.
- Install the CodeUnion command-line tool
- Read this repository's README carefully so that you understand how it works.
- This is how you submit feedback! So you should use it.
- For the ❤️ of 🐒 🐒 🐒 square away your indentation settings!
- CodeUnion and all ruby coders require 'Soft-tabs' of 2 space width.
- Get started with Sprint 1
- Don't forget to send feedback requests!
You have successfully on boarded when you complete the above tasks and begin making requests for feedback on your code. Completing the on boarding phase by the first day of your workshop will really help maximize your coding momentum. That being said, you should aim to complete your on boarding process as soon as you can but for certain, no later than the end of the first week of your Web Fundamentals Workshop.
Useful longterm learnings
- Read, digest and configure your terminal.
- Read, digest and learn some unix.
- Setup your github ssh keys.
Purely Optional
- Join our facebook group, we post code, memes, invites to parties and whatever else seems like fun.
- https://www.facebook.com/groups/codeunion/
Before you start anything, make sure you have your local development environment up and running correctly by going through our guide to setting up and verifying your development environment
The command line is that scary-seeming, all-text interface you often see in movies and vintage computer ads. We've come a long way since then. After your text editor, most of your development time will be spent on the command line. In fact, according to RescueTime, Jesse spent 23% of all his software development time in 2014 there.
To start, you only need to understand a few basic commands. Here are some resources:
- Skillcrush's Command Line Overview
- CodeUnion's Command Line Essentials
- Treehouse's Command Line Basics
- Zed Shaw's Command Line Crash Course
On Mac OS X, you can access the command-line by running Terminal.app. On Windows, you can access it by running Windows PowerShell.
Important Please read our Git Basics guide, which covers the critical aspects of git and GitHub that we'll be using at CodeUnion.
Git and GitHub form the foundation for much of CodeUnion's learning experience, so it's critical you become familiar with GitHub, git, and the common workflows we use to interact with each other. In particular, you should understand what the following phrases mean inside and out:
- Creating a repository on GitHub
- Cloning a repository from GitHub
- Forking a repository on GitHub
- Committing code and pushing it to a repository on GitHub
We expect much of the first week to involve getting students comfortable with git and GitHub. If you're looking for more material, we recommend:
- Four videos about git from the creators and maintainers of git
- CodeSchool's Try Git mini-course
Ahhh, feedback, the lifeblood of CodeUnion's ability make sure everyone progresses.
Asking for, giving and receiving actionable feedback are all learned skills. Ask for feedback on small amounts of code, provide context whenever necessary.
At CodeUnion, feedback is so important that we baked it into our command-line tool. Requesting feedback on your code is just a command away:
$ codeunion feedback request URL
Where URL is either a pull request or a specific commit.
Follow the instructions on the README for the CodeUnion command-line tool to get started.
When configuring the tool for giving feedback, set the configuration variable feedback.repository to codeunion/feedback-requests-web-fundamentals/, like this:
$ codeunion config set feedback.repository codeunion/feedback-requests-web-fundamentals
All requests for feedback are stored as issues in the codeunion/feedback-requests-web-fundamentals repository. If an issue is open, it means that feedback has not yet been given.
- Reply to requests for feedback within at most 24 hours
- Receive all feedback from students with gratitude and grace — personal, professional, or otherwise.
- Give specific, actionable, and encouraging feedback.
- Actively foster a learning environment that empowers their students.
- Dedicate a minimum of 20 hours / week coding — and that means hands-on-keyboard coding, not, say, thinking about coding while in the shower.
- Proactively and regularly seek feedback on their code, no matter how incomplete, inelegant, or unpolished they consider it.
- Clearly communicate expectations and inform teachers when those expectations aren't being met.
- Treat their teachers and fellow students with respect and be sensitive to differences in background, life circumstances, and culture.
Consider these expectations binding. If you, as a student, feel we're not living up to our end of the bargain, you should feel comfortable pointing it out and expect a grateful, gracious, and honest response.
The workshop is 8 weeks long and it's critical to establish a consistent weekly rhythm. These are the key moving parts for every two-week sprint, each built around giving and receiving different flavors of feedback from teachers and fellow students.
The "spinal cord" of the workshop is a collection of weekly projects, starting from basic command-line Ruby applications to proper, hosted-on-a-server web applications. Even if what the projects do is simple, each one is meant to be "shippable" software.
Early on in the workshop we'll be the one defining and scoping the projects for you. As the workshop progresses, you'll be working on projects of your own choosing.
Every student should aim to complete at least one project per week. If a project isn't on track, there's probably a problem with the project's scope that should be addressed ASAP! Ask us for feedback. :)
A code exercise is a small, self-contained exercise designed to complement the concepts you'll need to work on your projects for that week.
Most of our exercises are designed be completed in less than an hour by someone with appropriate prior knowledge. Our goal is preparing these exercises is not to ensure that you "get them right," but to establish well-calibrated and productive code→feedback→refactor loop.
We do not expect students to complete every exercise every week, but you should be attempting as many as you can. Remember, the top priority is getting feedback from us, even if your code is incomplete. They're also perfect for revisiting later.
Examples are a great way to learn. Often times just reading or being told how something works is not enough: we need examples to provide tangibility and context.
As much as we can, we try to provide example code for the concepts covered in the coures. Often times these examples are instructors' implementations of projects and exercises.
Use them to learn from. Poke at them. Ask questions. Try things out and break them.
We have two, 2-hour group sessions every week. The schedule is determined by the teachers and students in that workshop based upon their respective availability.
Although there might be lecture-like material in some of these sessions, the main goal is to help students through shared problems and practice skills that are only easily practiced in the presence of a teacher, e.g., learning how your teacher would tackle a problem you've been struggling with.
That means: come prepared.