Teaching Meteor to Beginners
CSCI16 - Web Development with Meteor
Ben and I have been using Meteor professionally for over a year. After meeting at a nearby co-working space, Cloud85, we quickly decided to join forces to create an app that addressed a pressing local need: simple online signups and payments for small businesses. We called it SimpleSignup. Ben came from a Ruby on Rails background and I had most recently been working with Django. Because we wanted to quickly prototype the app—and neither of us really wanted to do a deep dive into Rails or Django at the time—we decided to try Meteor. Very quickly we were hooked by the speed with which we could MVP our product.
When the opportunity arose to teach a class on web development at Williams College, Meteor was our first choice. It provides several major advantages over competing frameworks that makes it a great fit for teaching beginners:
2) Local development setup, including the database, is done with one command line instruction.
curl https://install.meteor.com/ | sh That’s it!
3) MongoDB means students don’t have to learn, yet, about schema, migrations and the like
4) Free one-line deployment to Meteor’s hosted servers (EDIT: as of March 2016 Meteor has eliminated their free hosting tier in favor of Galaxy)
These assumptions proved true in practice. Within one hour our students—again, largely total beginners—had installed Meteor, modified the default website, and deployed to their own custom, Meteor-hosted URL. Pretty amazing!
During the class we mixed short lectures with frequent, interactive projects. This was important since we figured the students’ attention span would drift off after about 15 minutes. And given we were introducing so much new, technical information, we wanted to make sure the students stayed engaged and worked alongside us on the exercises.
Having two instructors also turned out to be crucial. While one of us spoke up front, the other roamed the class and could respond to individual students who had a specific question or problem. Since we worked through many exercises as a group, this helped the students not fall behind and, if they had an interesting programming issue, we’d pause and talk it through with the whole class.
Class 1 - HTML
We started off by showing the students about View Source and then played around with Inspect Element so they could modify an existing webpage. This was a big hit and an easy way to demonstrate HTML and CSS. It’s easy to forget how cool this is for beginners.
Next we discussed the Front-End vs the Back-End, since it’s a core part of web development and also not intuitive for beginners. Finally we dove into HTML itself, talking through the basics and having students work through examples on their own in JSBin.
For the second hour of class students downloaded Atom and created a webpage in HTML. To open the HTML file in a browser, we had them simply save the file to their desktop and then double-click on it, which opened in their default web browser. There was an audible “a-ha” from many students when this happened and reinforced our feeling that it was important to use a real text editor and web browser right away.
After the initial rush of seeing their code on a web page, the students quickly became familiar with the standard web development flow of coding, saving the file, and refreshing the web browser. (Fun fact: Meteor does live reloads, so students only spent a few classes having to save/reload manually like this.)
We ended class with some fun slides discussing what to do when they became stuck on a coding issue. The mindset of a developer is not the same as the mindset of undergrdas at a liberal arts college, so we wanted to have the students become comfortable with making mistakes, being clueless, and using Google and other resources for help.
For homework students created their resume in HTML, with the promise that we would show them how to put it online and style it better with CSS in class 2.
Class 2 - CSS & Introduction to Meteor
We covered a ton of material in this class. Looking back on it, I’m surprised we accomplished so much in just 2 hours. To begin, we showed the students the sample resume we were going to build in class thanks to CSS and custom fonts. Since students already knew about View Source, they could go and find the complete code for this file to double-check their work at any point.
The final CSS/Google fonts exercise we built with students was to update their resume from the homework to look more like the initial sample resume.
In the second hour we showed students How to Create a Google Analytics Account and demonstrated live Analytics for a site with real traffic. It was definitely creepy/cool for the students to see the data that’s available out of the box with Google Analytics, especially location mapping, search queries, browser/device versions, and content drill downs.
Next we wanted to install Meteor. But to install Meteor you must use the command line, which is a full-stop barrier for most beginners. On the official Meteor site there are good installation instructions and tutorials, but they are designed for developers already familiar with web development and the command line. This probably makes sense given that Meteor sees itself as a cutting-edge platform for professionals, but it’s a lost opportunity, in our view, to make Meteor more accessible to first-timers.
In any event, we covered the Command Line with slides and interactive exercises. We had the students create, via the command line, a “code” folder on their desktop for all their work so far, mainly just HTML/CSS files. The most common confusion for students was getting lost in the directory structure. So sometimes when they tried to run Meteor locally, which requires typing
meteor it wouldn’t work because they were up/down a level. It really is a mind-bender the first time you think of your computer in terms of directories and not a mouse-driven GUI.
But with the command line covered, we were on to Installing Meteor, which is just a simple one line example. Meteor helpfully installed a demo app and so students could run Meteor locally and interact with it in their browser. Then we played around with modifying the default html/css code a bit. And finally students replaced the default code with their existing online resumes from homework the night before. We added in a custom Google Analytics tag for each student and deployed with Meteor’s one-line deployment to their hosted servers.
Over the weekend students could both share their work with friends/family/fellow students, they could track it too! This built up a lot of excitement and enthusiasm for class 3 the following week.
Then we dove into the Creating a Meteor Guestbook example together. This gave us the chance to cover forms, templates, events, collections, publications, and subscriptions. Heady stuff! This ended up taking the rest of class 3 and all of class 4. You can see the 59(!) slides here.
I’m sure the students didn’t fully grasp all of these concepts on this first go round, but they live coded along with us and got things to work. The slides and code were online so they could review on their own after. And, since there were two teachers, while one us was upfront live coding and explaining the other could roam the class and help students who became stuck.
If there were only one of us, this amount of material might have been too much. But students plugged along and asked questions when needed. Before this session of classes we had considered doing more of the same structure for future classes on Meteor concepts: lectures, interactive exercises, small projects. However the enthusiasm and aptitude students showed convinced us to let them start the following week on group projects and we would work in additional materials as needed. Again, with two instructors, we could provide adequate one-on-one help to the groups as they started working on their ideas during class time.
Class 5 - Git, CSS Preprocessors
As students started more complex projects, we needed to introduce git and Github. We had many internal discussions around if we even wanted to get into this; certainly git is essential to professional developers, but it can be confusing and deep waters for beginners. If we had stuck to individual projects, we likely would not have tackled git. But for group projects, we felt it was essential and so we dove in.
The Intro to Git lecture went down smoothly and students were able to use it themselves and create/connect to Github. In hindsight, we should have done more here since we didn’t really cover git in groups, how to do git merges, adding permissions on Github, and other topics that came up quickly.
Next we covered CSS Preprocessors, specifically SCSS, and showed how using variables saves a lot of time in CSS by using a simple example its colors. Meteor packages are easy to install, so the exercise went well. However finding Meteor third party packages is not a highlight of the framework. To do so you must use Atmospherejs.com which is not a great experience: it’s hard to navigate, has no search filters, and it’s a mixed bag what you get as a result. For example, when you search for “bootstrap” there are, as of this writing, 523 results and no easy way to discern the proper package. Meteor Development Group does maintain a small number of official packages that are guaranteed to be up-to-date, but for most packages there is little documentation and the process is poor. In general, we advised the students to use Google when looking for 3rd party packages by Googling something like “bootstrap atmospherejs” which would usually return the top result.
In the second half of the class students divided into groups and began brainstorming and sketching out projects for the final week and a half of the class. Their homework was to work on these further.
Class 6 - Responsive Design & Routing
In hindsight, we covered Responsive Design too quickly. The concepts made sense to students, but media queries, breakpoints, and thinking in pixels is a lot to digest the first time around. To throw in Bootstrap on top of that was probably too much. It would have been better if we devoted a full class to all of this rather than only 30 minutes. Our thought was that we could show students how if only they used containers, rows, and columns, they could quickly achieve responsive sites. And then we highlighted some Bootstrap navbar examples. But it was too much and students had to piece a lot of this together on their own time.
The Introduction to Routing was more successful. We decided to use IronRouter and not tackle FlowRouter or the debates in the current Meteor community around what routing package to use. This is another aspect of Meteor that could be improved; routing should be a core part of the framework, not a third party package.
On a related note, we had students just use Meteor’s built-in tempting engine, Blaze. For homework some of the CS students worked through Meteor’s To-Do list app in React, but we left React out of the classroom discussion. If we teach this class a year from now, we may have to tackle React as Meteor has signaled its intent to move away from Blaze permanently. While we understand Meteor must listen to its core users, this is disappointing to us as Blaze+Spacebars is fantastic as a simple templating solution and much more accessible to beginners than React.
Students were tasked with making their projects responsive, which again provided a nice way for the less-technically savvy to get involved by installing and updating the design. At this point most groups had divided duties pretty well amongst front and back end code.
The rest of the class students worked on projects and we went around helping them debug issues. In general we avoided giving straight answers, instead talking them through how to solve issues, usually by using Google, experimenting themselves, and only helping them with actual code when they appeared truly on the wrong track.
Class 7 & 8 - Hosting Options and Group Presentations
The last two classes were primarily in-class coding sessions where Ben and I would help groups with their coding and product issues. It turned out that students were primarily interested in ride-sharing or music-sharing apps! There were two students groups on each project. Login for all projects is restricted to Williams students only, but you can see screenshots of the apps below.
Conch (YouTube-powered collaborative music app)
Herd (short distance ride sharing app)
PartyUp (Spotify-powered collaborative music app)
ClunkerU (longer distance ride sharing app)