January 2014
Instructor: Al Zimmerman
Email: azimmerman@portlandcodeschool.com
Email (personal): auraelius@gmail.com
Phone (text and voicemail): 593-970-3645
Office Hours: Monday & Wednesday before & after class.
For definitive contractual agreements, see the "Portland Code School Student Enrollment Agreement" that you signed. Nothing in this syllabus is intended to supercede or replace terms agreed to in that document. Where a conflict exists, that document will apply.
The core abilities for students in our program are as follows. They are designed to be the overarching goals for everything you do. Each of them have been specifically requested by the employer network and we believe that they are good goals for all developers to aspire to and flesh out.
- Create code quickly and efficiently
- Create high quality code
- Collaborate with teammates effectively
- Understand and apply current technologies
- Learn new technologies easily
- Understand and apply computer science concepts
- Understand and apply business and product development concepts
- Speak effectively about technology in interviews and while networking
- Utilize the technical and functional aspects of each lesson’s topic
Class hours: **Tuesday & Thursday 6p-9p, plus several Saturdays a month. Saturday hours will be announced at least 1 weeks in advance. The class meets Tuesdays and Thursdays and frequent Saturdays.
This course requires 6 hours most weeks, 13 hours one week each month, for classroom time. In addition, students will have to devote approximately 20 outside hours of their own time each week.
So, bottom line, this is a second job of between 25-30 hours each week if you want to get your money's worth.
The first Tuesday, we meet in the classroom. Future Tuesdays, we will meet in a variety of locations, some times in the classroom, some times at local companies.
The first Tuesday of each month, we will attend the Ruby Brigade meetups at New Relic in downtown Portland. Getting a job or understanding the Ruby on Rails community is a primary focus of this class and this meetup is the primary way of doing both.
Other Tuesdays each month will be lab sessions. Depending on our schedule, which is customized for each class, we may meet in the classroom or at a Hack & Help session. You'll get at least one weeks notice with the location prior to each Tuesday, but most of them will be at New Relic.
Every Thursday, the class meets in the PCS classroom.
The first Saturday of every month, our class joins with the JavaScript class on a full Saturday session. The classes will be reviewing GitHub usage, learning web application front end languages like HTML and CSS, or working on career topics -- material that is germane to both classes. Other Saturdays the Ruby on Rails class will sometimes meet for three hours in the morning in the PCS classroom. These Saturday sessions will depend on the class schedule, which, as we said, is different for every class and depends on what you and your cohort require. You will get as much advance notice as possible for the sessions.
You should all have access to a Google calendar called, "PCS" and should have received an email to this effect. If you haven't, please contact Kristina or Cris or me and we will make sure the class calendar is available to you. I will try to make sure this calendar is always up-to-date.
I am available for office hours every Tuesday and every Thursday from 3 PM to 6 PM in the PCS classroom. I'm also willing to meet with you by prior arrangement, either online in a Google hangout or Skype screen sharing session or in a location that we both can get to easily. My calendar is as tightly fitted as a Moroccan mosaic, however, and we may have to work a little to find a time that works for both of us. Office hours work best.
My Code School email is azimmerman@portlandcodeschool.com. Email to this address will get a reply within 24-48 hours. My cellphone is 503-970-3645, but it only works for text or voicemail. If you text me, please prefix your text with the word "PCS". Texts or voicemail will get a reply within 4 hours.
The "Pickax Book" (that is, Programming Ruby 1.9 & 2.0 (4th edition): The Pragmatic Programmers' Guide by Dave Thomas, with Chad Fowler and Andy Hunt) is required for this class. This is the definitive reference for the Ruby language and every Ruby programmer has either read it, or claims that they have, or knows that they should have and feels really guilty about it and hopes that no one finds out they haven't yet. An early edition is online at http://ruby-doc.com/docs/ProgrammingRuby/ Much of the Ruby language is still the same as the version 1.8.7 that this free, online edition of the pickax describes. However, the current version of Ruby is described in the current version edition of the book. The book is available at Pragmatic Programmers at http://pragprog.com/book/Ruby4/programming-Ruby-1-9-2-0.
Please purchase the current electronic edition. I know it is easier and frankly more fun to read a paper edition of a book, but after you go through the book in detail in this class, most of your access to this book will be looking up aspects of the language as you need them while you code. The electronic edition is much more suitable for this purpose. Also, one of the skills you need to cultivate as a professional programmer is the ability to read difficult, detailed documents online using screens. This can be difficult; you need to start practicing this as soon as possible. Finally, if you purchase the electronic edition, Pragmatic Programmers will keep it up-to-date for free, issuing upgraded versions as needed.
Many of you have programming experience in other languages. If you do not, if Ruby and this class is your first programming experience, please get a copy of Chris Pine's book Learning to Program. Again, a early edition is available for free on the web at http://pine.fm/LearnToProgram/. However, you will enjoy reading the up-to-date version that is available, again, through Pragmatic Programmers at http://pragprog.com/book/ltp2/learn-to-program . You will go through this book once and then give it away to another beginning programmer after you are familiar with the Ruby language. It is a nice, easy introduction to the language that many people find fun and easy to follow. However, it is not a reference like the Pickax book.
There are many other books on various topics in the Ruby ecosystem. We'll recommend some of them in class as we go along. I hesitate to recommend that you pick up copies at this time because it will be more useful for you to learn Ruby by exploring one or two references in depth then to skim many references. During your career, you will read many books on programming, But let's start with just one: the Pickax.
You all have Treehouse accounts. If you did not receive notice of your Treehouse account, please contact me. There are many alternative screencasts available for all of the topics that we will cover in this class, but I want you to invest time in the Treehouse ones. For some of you, screencasts will be a slow experience. Feel free to speed up the playback or to skip ahead to the quiz for each module to see if you already know what they are teaching.
You are required to complete the quizzes and earn the badges. You and I will review your progress every two weeks to make sure you are on track.
Later in the course, you will receive accounts on codeschool.com in order to take specific courses. Your instructor will give you additional information.
Everybody has different learning styles: some people learn well through screencasts. However, realistically, the density of information is very low. Screencasts can make some subjects more accessible by having a friendly person introduce you, but there is no substitution for reading about topics on your own, studying them in depth, and then applying your knowledge by programming.
As you watch screencasts, some topics will be difficult. Some people have a natural inclination to seek out other textbooks or other screencasts when the one they are watching or reading is difficult to understand. However, this is just a delaying tactic, a form of avoidance. If you are having difficulty learning using one method of learning, the best technique is to use an entirely different method of learning. In our case, the best alternative when you think you don't understand how to code is to start coding. I encourage you to work with IRB and actually program in Ruby while you watch the screencasts. Stop the playback and try it yourself. Turn a normally passive activity, watching TV, into an active learning experience by programming while you watch.
One of the themes of this course is, "ask the language." Ruby and the Ruby toolset makes it very easy just to ask the language itself how it works. There is no better way to learn programming then to program, to fail, and to puzzle out what is going on. It will be a waste of time for you to switch textbooks or switch screencasts if you find that the offered resources are not giving you immediate understanding.
Finally, don't use screencasts as your primary source of information. I have observed students, when faced with a question during a code challenge, stop and re-watch a half-hour series of screencasts when they could look up the answer in the Pickaxe in a minute.
The first series of required screencasts are: Ruby Foundations Deep Dive (http://teamtreehouse.com/library/ruby-foundations) Git Basics Deep Dive (http://teamtreehouse.com/library/git-basics) Console Foundations Deep Dive (http://teamtreehouse.com/library/console-foundations-2) Try to watch several screencasts from each series before you come to class on Tuesday just to make sure that you know where to find them. You are responsible for earning several badges in each series every week. Then we'll add more series.
The web is full of places where you can learn to program. Again, the problem isn't finding a resource, it's completing what you set out to do. We've chosen one or two that we want you to work to completion.
Required: CodeAcademy (http://www.codecademy.com/tracks/ruby) Optional: RubyMonk (https://rubymonk.com)
Assignment: Do the 15 minute tutorial at http://tryruby.org before Tuesday just to warm up.
You need to provide your own computer for this class.
Most Ruby on Rails programmers use MacBook Pros. Rails was developed originally on the OSX operating system and most of the best tools are still developed on that operating system first. The important aspect of OSX is the underlying UNIX-like operating system.
A good alternative is Linux/GNU. Many Ruby on Rails programmers use it. In fact, most of your web applications will be deployed on Linux/GNU virtual hosts in the cloud. Any Debian-based distribution will do.
Windows is a poor alternative. We don't encourage or support Windows in this class.
If you have a Windows laptop and you cannot manage to obtain a MacBook Pro to work with in this class, we will have a work session for creating a virtual Linux instance that you can use for class activities. I don't think we have any MacBooks available for rental any more, unless you've already made arrangements with Cris to get one. Used MacBook Pros are available at the Mac Store and various locations online. You don't need an extremely powerful one, but we can talk about the minimum specs if you are in this situation.
You are required to learn and use Sublime Text. (http://www.sublimetext.com) The "stable" version is V2, but I've been using V3 for a long time and it's fine. (http://www.sublimetext.com/3) Sublime Text is not free. You can try it for free and that will get you through this class, but you should consider buying a copy when you get a job.
Now, you may already have a favorite text editor. I understand where you're coming from. However, one characteristic of professional programmers is they can walk into a shop and quickly adopt whatever toolset that company is using. Lots of programmers use Sublime Text and, if all the students in this class use it, we can learn from each other and get the most out of the tool. There will be more tools introduced as the class goes on, but a text editor is a good place to start.
My ultimate goal is to be able to give a shining recommendation about you to any and all possible employers. Over the years, I have managed and hired many software engineers at both a junior and senior level. My goal is that I would want to hire you myself.
Along the way, I will be asking myself the same questions about you that all hiring managers will be asking about you:
- Can you work in a team?
- Can you follow instructions and finish assignments?
- Can you extrapolate from vague inputs and take the initiative to resolve 0. any missing information?
- Do you have a bias towards action and taking risks?
- Can you manage your use of your own time?
- Can you deliver on time in a team context?
- Do you have effective learning strategies?
- Can you use test driven development techniques?
- Do you write idiomatic Ruby?
- Can you effectively use a web framework like Rails to produce a web application? Notice that the soft skills are at the top of the list and the programming skills are at the bottom. We will talk more about this in class.
We will check-in 1-on-1 every two weeks. You will get early notice if you need to step up your game in any particular area.
This class is "homework first" - with the exception of the first session, all sessions require students to prepare by watching screencasts, reading assignments, coding, testing, or otherwise performing assignments /before/ the next class so that they arrive ready and prepared to contribute to the team. You will not have the opportunity to catch up in class.
Students who attend class unprepared diminish the learning opportunities for everyone, not just themselves.
This class depends upon an atmosphere of mutual respect among students and staff. Together, we create a safe place to listen, learn, speak candidly, and fail safely. This is not a typical college class, it's a team effort producing a final product: jobs for everyone. You have the opportunity to make deep connections here that you will enjoy the rest of your career.
Students are expected to act at their highest capacity and with mutual respect for each other regardless of age, race, gender identity and expression, sexual orientation, or prior experience. Instructors are expected to lead in this regard by example.
In a related vein, this class requires work in close proximity to others as we code and debug in pairs and small groups. Good hygiene is mandatory and an additional sign of respect for your colleagues.
If you experience or perceive a problem, attempt to work it out on your own, if possible, but do not hesitate to bring it privately to the attention of your instructor. If this is unsatisfactory, bring it to the attention of Cris Kelly, Portland Code School Director.
Each term, students may collaboratively establish other norms and expectations specific to that cohort.
This course relies on the following cycle to teach each new concept:
- Watch, listen, read, and write
- Play & fail
- Challenge yourself
- Collaborate with others
- Teach
Watch, listen, read, and write: Some concepts are easy, some take a little while longer to internalize. So we provide multiple modalities: screencasts, reading, conversation. We encourage note-taking both personally, by hand, and for the class as whiteboard or easel scribe
Play and fail: Children learn faster than adults because they play and they don't care about failing. We encourage a playful, safe learning environment. We use interactive coding tools and encourage students to try every new idea out for themselves. We encourage test-driven development, where the first step is failure (and the last step is triumph!).
Challenge yourself: Studies have shown that you learn the most when you have the most to lose - right after failure. For some people, it feels bad to feel stupid. For us, confusion is the first sign that we're learning and the first taste of fun times ahead.
This course teaches students how to become self-learners, how to challenge themselves to learn new skills through experimentation and trial and error. To that end, many exercises and quizzes are taken from around the web through a meticulous process to make sure the carefully curated work is relevant and high quality. The answers are all available to students if they look for them. None of these are tests in the traditional sense. If they wanted to, students could easily find, copy, and claim these answers for their own. However, this would all but guarantee that they do not acquire the skills necessary for employment. By participating in this course, students agree not to use google, StackOverflow, or similar methods to simply find, copy, and claim answers to exercises and quizzes for their own work.
Collaborate with others: Employers tell us that the most important skill is working on teams. Students work together in pairs and larger groups to understand problems, design solutions, and construct code. They use test-driven design to verify that their solutions work. They perform code walk-throughs to compare their work with the rest of the class. The point is to make sure that everybody in the class arrives at a working solution, not to find out which students are capable of finding a solution on their own and which are not.
This class puts an emphasis on participating in community. We require students to attend local community events in the beginning, then we expect them to volunteer at and eventually lead community events. Like experienced developers, we use the community as our primary means for building a business network and finding employment.
Teach: You don't fully understand something until you teach it to others. This class requires students to teach each other and gives them frequent practice in small, easy doses to help them become comfortable.
This also includes blogging and contributing to online forums like mailing lists and StackOverflow.com. Helping others in the community by relating what you know is an excellent way to earn a good reputation and build a personal brand. The reason this is such a wonderful time to be learning software development is because people are so willing to help each other. Students learn how to pay this forward.
After getting some basics under their collective belts, students will be requested to identify one or two potential projects that they can accomplish in teams of 2 or 3. These projects should provide meaning or value on a topic the students find interesting. If they can't identify a project, Portland Code School and its network of partners and employers may have several to choose from.
Students will pitch one of these projects to the PCS staff and will collaborate with staff to scale the scope so that students have a good chance of success by the end of term (including some failures along the way!).
During the final week of class, students will present their completed projects to their fellow students, staff, and members of our employer network.
The details of this schedule are subject to change.
- Course overview, web application architecture
- Tools: Development environment setup
- Career: Intro to Portland & online developer communities
- Ruby: Syntax, Variables, Operators, Expressions IRB, Intro to objects
- Product development: Working in pairs, working in teams, agile methods
- Career: Participating in communities
- Tools: Exploring, reading, & watching code with a debugger
- Tools: Documentation and other sources of information
- Ruby: Core & Standard libraries
- Ruby: Conditionals, Loops, Iterating across collections, more objects
- Assessment checkpoint
- Career: Building a business network by building community
- Tools: Introduction to test-driven development
- Tools: Writing tests, running tests
- Background: HTML & CSS
- Ruby: contributed libraries: using gems and the bundler
- Ruby: Methods and Classes
- Ruby: Writing tests with rspec
- Ruby: command line interfaces
- Product development lifecycle : Analysis, Design, and Construction
- Career: Portland Ruby Brigade
- Saturday classroom
- Assessment checkpoint
-
Sinatra, continued
-
Exploring the HTTP protocol & REST resources
-
Using Sinatra to respond to HTTP with Ruby
-
Ruby: Procs, Blocks, and Lambdas
-
Tools: Deploying Sinatra on Heroku
- Career: Presenting yourself and what you've learned
- Specifying a web application: personae, page flows, and wireframes
- Rails: Installation, MVC architecture, Models, Controllers and Views, CRUD scaffolds
- Assessment checkpoint
- Background: Databases, Entities, Attributes, Tables, SQL, NoSQL
- Tools: Database clients
- Rails: Views, Dynamic Content, Templates, Layouts, Partials
- Specifying a web application: User stories and scenarios
- Rails: View testing
- Tools: User stories as tests with Cucumber & Capybara
- DevOps: Testing, Staging and Production environments
- Rails: Controllers, CRUD by hand
- Rails: Testing controllers
- Assessment checkpoint
- Careers: Technical job bestiary
- Rails: Models, ActiveRecord, Migrations, Associations
- Rails: Model testing with Factory Girl and RSpec
- Product development: What makes a good capstone project
- Career: Finding & growing project partnerships
- Rails: Continuing tutorial work
- Product development: Capstone project pitches from business partners
- Assessment checkpoint
- Career: Building a reputation and a personal brand
- Business: APIs, program ecologies, and B2B
- Rails: Serving REST APIs
- Rails: Ajax
- Product development: Making meaning, creating value, the pitch
- Product development: Student team project proposal pitch sessions
- Career: Freelance and temp work strategies
- Product development: Capstone team formation
- DevOps: Application debugging on Heroku
- DevOps: Application monitoring on Heroku
- Assessment checkpoint
- Product development: Student team project work
- Career: Interviewing, creating the job you want
- Career: Presenting at Hack & Help
- Product development: Student team project work
- Assessment checkpoint
- Career: Tools and techniques for a lifetime of learning
- Product development: Student team project work
- Product development: Finish and Present Projects
- Final assessment
Copyright © 2008-2014 Alan Zimmerman
Used by permission by Portland Code School