Annotated Guide to my Meteor-based Software Engineering Course

I’ve been asked to provide a little more detail about the way I teach Meteor as part of my one semester software engineering curriculum. An archival version of the complete set of modules is here:

http://courses.ics.hawaii.edu/ReviewICS314/modules/

Here’s a basic outline, omitting several modules not directly related to web application development:

Weeks 1-3: Overview of Javascript.
I assume no prior knowledge of JS, but do assume a background in programming. Week 1 concentrates on basic syntax, Week 2 on object orientation, and Week 3 on functional programming using Underscore. Most students are not familiar with passing functions as arguments or functions as return values. I have them use JSFiddle.

Weeks 4-6: Configuration Management, Development Environments, Coding Standards.
During these weeks, I introduce them to Git, GitHub, Intellij IDEA, and ESLint. Now they can write JS with an IDE according to the ESLint AirBnB standards and commit code to GitHub.

Week 7: Basic HTML and CSS.
This is an easy week that overviews simple HTML/CSS. I use FreeCodeCamp modules to introduce this stuff.

Week 8: Semantic UI.
This module introduces my CSS framework of choice, and they learn to use it to build a ‘modern’, responsive web page. I have them find a random home page on the Internet and reproduce it (more or less) in Semantic UI. I try to get them to see that they can get pretty far in UI design by just knowing how to “copy” sites whose UI they like. I used to use Twitter Bootstrap, and that would be a good choice as well.

Week 9: React.
I have them go through the React tutorials, then re-implement their site from last week using the Semantic UI/React integration. For me, it’s these integrated React frameworks that really simplify UI design and implementation. Now they have a decent introduction to front-end technologies completely separate from the back-end.

Week 10: Mongo and Meteor 1.
An introduction to Mongo independent of Meteor, plus an “Hello World” level introduction to Meteor. This week is basically about making sure they have Meteor installed correctly on their laptops and can build the default Meteor app. Plus, how to use Mongo (I do not assume the students have any prior database experience.)

Week 11: Meteor 2.
This week involves short exercises that give them familiarity with three sample applications I’ve created for this class: meteor-application-template-react, which they use as a boilerplate for their Meteor applications, meteor-example-form-react, which provides sample code for building UI controls using the Uniforms framework, and Bowfolios, which is a complete application at close to the complexity level that I expect for their final project.

Weeks 12-13: Meteor 3.
This is a two week module where I step them through the development of a simple CRUD application for an Address Book called Digits. I divide the development into six stages: clone meteor-application-template-react and create the landing page, create a List Contacts page mockup, create the Contacts collection, create the Add and Edit contact forms and pages, add the ability to add timestamped Notes to each contact, and a final cleanup task.

Weeks 14-17: Final Project.
Students spend the last month of the course building a new application from scratch in teams, learning about agile development, testing, and other software engineering concepts. At this point, the focus shifts from the tech stack for web application development to the issues that occur when you are actually trying to solve a real world problem for a customer.

Conclusion:
I think the main difference between my approach and other introductions to Meteor is that I teach the entire set of front end technologies (HTML, CSS, Semantic UI, and React) before introducing Meteor. Most other approaches build a really simple vanilla Meteor app and then make it incrementally more sophisticated. There are pros and cons to each approach; I like this one because it helps students see the front-end technologies as entirely independent from the web application framework.

Another difference is that my approach is very “opinionated”: I require students to use IntelliJ IDEA, ESLint, Semantic UI, React, and Uniforms. This has costs, in that my tech stack has changed over the years as my “opinions” about the appropriate composition have changed. But the benefits are that students learn a pretty cool, pretty modern tech stack, and get a lot of functionality out of a relatively small amount of code.

Also, a couple of shortcomings: I do not attempt to teach them about Meteor Methods so that they can remove the insecure package, nor do I spend much time on unit and whole-app testing modes. I basically run out of time in this semester, but this stuff should obviously be part of a comprehensive introduction.

22 Likes

Thank you for this, I agree with this approach starting from basic Web instead of just Meteor.

I would include a topic about Flexbox (maybe CSS Grid also) then you don’t need to learn Twitter Bootstrap or similar tools.

3 Likes

Hi @philipmjohnson,

thanks for this explanation as well as the link. I also use Meteor as part of my courses at the university, but in a very reduced way, as I’ve only about 3 hours every second week for my course. I focus on setting up the infrastructure as this is the title of the studies: “IT infrastructure management“

How much time do you stay in class with the students, how much is the workload outside the class-room?

If it’s ok for you, I’d like to take your materials as inspiration for an upcoming software engineering program at our university. There’s already a curriculum, but it still needs to be filled with life :slight_smile:

2 Likes

Sure thing, use and/or adapt anything that you want. My course involves two 75 minute sessions per week. The course is “flipped”, so all of the lectures are available online. Class sessions are focused on small group work. I tell students they should plan to spend about 10 hours a week outside of class working on the course.

1 Like

Thank you so much for posting. Your course was a guideline for me learning meteor a few years ago when you posted. I had no real programming experience outside of a few courses so your course was the guideline I used. I also added in freecodecamp since I had no code experience. Your course is an excellent example of how to move at a good pace. I did about 15-20 hour a week and watched your videos and others resources that you would list in each module. Thanks again.

This is wonderful. It would be great if you can add a section on performance and security.

  • performance - i’m thinking to get rid of reactivity where not required

  • security - this has been a pain point for widespread acceptance (or rather enough material to guide through)

These two topics are simply not that complicated:

  1. To get rid of reactivity for any or all pages, just don’t subscribe to any publications and instead use one or more Meteor Methods to get your data when you need it. Bam. Done. (There are LOTS of other performance related issues around scaling etc which are generic to all web apps regardless of platform, but addressing Meteor-specific reactivity performance is almost trivial.)

  2. For security, the Meteor Guide has excellent documentation:

I meant both of them as examples. Optimization can take various forms … dynamic-imports, build procedures, design patterns, bottleneck tracking, etc. I think an entire system was being contemplated around Kadira or Galaxy IIRC around performance optimization.

Similarly for security, I believe someone tried to write a book around it.

If you believe those can be addressed by reading the manual, that’s cool too.

Pete Corey @pcorey wrote the Secure Meteor book - https://www.securemeteor.com/

2 Likes