Tag Archives: meteor

Hosting Meteor JS Applications - My Process on Webfaction

There has been some interest expressed here and on Twitter for a description of the process of moving an application from the free meteor.com to my own server. I run my web applications (such as this blog) on Webfaction, which gives a lot of flexibility for setting up a number of different hosted services. I won't say each step below is easy and as straightforward as it sounds, so feel free to add your difficulties to the comments below, and I'll elaborate. Having the steps in one place will hopefully be as useful for you as it likely will be for me.

Note: Steps 1 - 3 in the list below are just for downloading data you may have collected in an online application onto your computer. If you don't care about the online data, you can skip down to step 4.

  1. I installed Mongo on my local machine from http://www.mongo.org
  2. In a terminal on my local machine, I entered meteor mongo --url my-app.meteor.com to get the username, password, url, port, and database name from the *.meteor.com website. The result is a URL that contains the information you will need for the next step: (username:password@url:port/databasename)
  3. save the data onto my local computer using mongodump --host hostname:port --db databasename -u username -p password -o ~/Desktop where the information from the last step replaces the username, password, etc.
  4. To create a packaged version of the app that runs on my computer, go to the Meteor project directory, and type meteor build --architecture os.linux.x86_64 ./ . This assumes that the server that will be running your project is a Linux machine...but this assumption is probably a good one for most hosting services.
  5. Create a free account on mLab (http://www.mlab.com). The free account gives you 500 MB of space for databases. For comparison, the total size of my most-used application is only 2.7 MB. I think you'll have enough space. The important thing to get, once you have a database set up, is called the URI. If you create a database, there is a box at the top of the page that gives you information that looks like this: mongodb://:@dsXXXXXXX.mlab.com:PORT/DATABASENAME which you will need in the next step.
  6. I learned the Webfaction specific steps from reading this page, though you won't need to do the Mongo steps if you are using mLab as I am. On the Webfaction server, you must install node. You can do this by following the steps here. You must also create a custom WebSockets application. This will give you a port number that you will need in the step below where local variables are set.
  7. Again, this is a Webfaction specific instruction, but you need to attach the application to a domain/URL where your application will be accessed. Save this URL
  8. Once you have created the WebSockets app, upload the .tar file (from step 4) to the /webapps/web-sockets-application directory through ftp and unpack with tar -xzf my-app.tar.gz
  9. Using the mLab information from step 5, the port number from step 6, and the location of the node application from step 6, you'll need to fill in the appropriate parts of the commands below:

    export MONGO_URL="mongodb://:@dsXXXXXXX.mlab.com:PORT/DATABASENAME?autoReconnect=true" # 2
    export MAIL_URL='email-address-for-sending-mail-from-your-app'
    export PORT="PORT-NUMBER-FROM-STEP-6"
    export ROOT_URL="DOMAIN-FOR-APPLICATION-FROM-STEP-7"
    export PATH=~/webapps/node/bin/:$PATH

  10. Almost there, folks. Inside the unpacked .tar directory (which will be called /bundle), enter the /bundle/programs/server/packages directory and run npm install
  11. Go back to the /bundle directory and run nohup node main.js . This terminal command will run a command continuously on the shell, even if you close the terminal.
  12. If you've made it this far, you might just have your Meteor app running on your own server.

I hope this helps you, but if you run into trouble, throw a comment below and I'll see if I can help.

My Journey with Meteor as a Teacher-Coder

Many of you may know about my love for Meteor, the Javascript framework that I've used for a number of projects in and around the classroom. I received an email this morning alerting me (and the many other users) that the free hosting service they have generously offered since inception would be shutting down over the next month.

To be honest, I'm cool with this decision. I think it's important to explain why and express my appreciation for having access to the tool for as long as I have.

I started writing programs to use in my classroom in earnest in 2012. Most of these tended to be pretty hacky - a simple group generator and a program to randomly generate practice questions on geometric transformations were among these early ones. The real power I saw for these was the ability to collect, store, and filter information that would be useful for teaching so that I could focus my time on using that information to decide on the next steps for my students. I took a Udacity course on programming self-driving cars and on web applications and loved what I learned. I learned to use some Python to take some of the programs I had written early on and run them within web pages. I built some nifty online activities inspired by the style of Dan Meyer and put them out for others across the world to try out. (Links for these Half-Full and Shapes tasks are below.) It was astounding how powerful I felt being able to take something I created and get it out into the internet wilderness for others to see.

It was also astounding how much time it took. I learned Javascript to manage the interactivity in the web page, and then once that was working, I switched to Python on the server to manage the data coming from users. For those that have never done this sort of switching, it involves a lot of misplaced semicolons, tabs, and error messages. I accepted that this was the way the web worked - Javascript in front, and Python (or PHP, Rails, Perl, etc.) on the back end. That extra work was what kept someone like me from starting a project on a whim and putting it together. That cost, in the midst of continuing to do my actual job of teaching and assessing students five days a week, was too great.

This was right around the summer of 2013 when a programmer named Dave Major introduced me to Meteor. I did not know the lingo of reactivity or isomorphic Javascript - I just saw the demonstration video on YouTube and thought it was cool. It made the connection between the web page and the server seamless, eliminating the headaches I mentioned earlier. Dave planned to put together some videos and tutorials to help teachers code tools for the classroom using Meteor, and I was obviously on board. Unfortunately, things got in the way, and the video series didn't end up happening. Still, with Dave's help, I learned a bit about Meteor and was able to see how easy it was to go from an idea to a working application. I was also incredibly impressed that Meteor made it easy to get an application online with one line: meteor deploy (application-name here) . No FTP, no hostname settings - one line of code in the terminal, and I could share with anybody.

With that server configuration friction eliminated, I had the time to focus on learning to build truly useful tools for myself. I created my standard based grading system called WeinbergCloud that lets students sign up for reassessments, earn credit for the homework and practice they did outside of class, and see the different learning objectives for my course. I created a system for my colleagues to use to award house points for the great things that students did during the school day. I made a registration and timing system for our school's annual charity 5K run that reduced the paperwork and time required of our all volunteer staff to manage the hundreds of registrants. I spoke at a Meteor DevShop about this a year and a half ago and have continued to learn more since then.

Most importantly to me, it gave me knowledge to share with a class of web programming students, who have learned to create their own apps. One student from last year's class learned about our library media specialist's plan to hold a read-a-thon, and asked if he could create an interactive website to show the progress of each class using, you guessed it, Meteor. Here's a screenshot of the site he created in his spare time:
Screen Shot 2016-03-11 at 10.34.26 AM

And yes, all of these apps have been hosted on the free deploy server at *.meteor.com, and yes, I will have to do the work of moving these sites to a new place. The public stance from Meteor has been that the free site should not really be used for production apps, something I've clearly been doing for over two years now. I re-read that line on the documentation website back in January and asked myself what I would do if I no longer had access to that site. The result: I did what I am paid to do as a master learner, and learned to host a site on my personal server. That learning was not easy. The process definitely had me scratching my head. But it also meant that I had a better understanding of the value that the free site had given me over my time using it.

The reality is that Meteor has clearly and publicly shifted away from being just being that framework that has a free one line deployment. The framework has so much going for it, and the ability to create interesting apps is not going away. The shift toward doing what one does best requires hard choices, and the free site clearly was something that did not serve that purpose. It means that those of us that value the free deploy as a teaching tool can seek other options for making it as easy to get others in the game as it was for us.

Meteor has helped me be better at my job, and I appreciate their work.


As promised, here are those learning task sites I mentioned before:

Credit Expiration & Standards Based Grading

For the background on my reassessment system, check out this previous post.

Here's the run down of my progression in using standards based grading over the past couple of years:

  • When students could reassess whenever they wanted, they often did so without preparation. They also rushed to do as many reassessments as possible at the end of a quarter or semester. I also needed a system to know who had signed up for a reassessment, for which standard they were assessing, and when they were coming in.
    Solution: Students needed to complete a reassessment sign-up form through Google Forms that included reflection on work that was done to review a standard. In general though, the reflection on these forms wasn't strong. I needed more, but didn't get around to clearly defining what I meant by strong reflection.
  • The difficulty of scanning through a form and getting the information I needed prompted me to create an online site using the Meteor programming framework that lets students sign up for reassessments. In real-time, this sorts the reassessments for a given day and helps me stay organized. The problem was that I still wasn't satisfied with what students needed to do to reassess. They needed to review their mistakes, talk to me, practice and get feedback, and then sign up. Having a way to manage that process was essential.
    Solution: The introduction of credits. Students earned credits for working after school, showing me practice problems, and doing other work to support the deliberate practice and learning needed to get closer to mastery.
  • Many students hoarded their credits until the end of the semester. This prevented the cycle of feedback about learning from continuing, and caused the end of the semester to still be a mad rush to reassess whichever standards are lowest in the grade-book using a machine gun approach.

This brings me to what I wrote about in my year-end reflection about SBG at the end of last year. Hoarding credits and saving them until they want to use them causes less reassessment, and that's not right. I want to nudge students to reassess more often and know that they should take opportunities as often as possible to show what they know. I've threatened to make credit expiration happen since August, and students have been asking when it would start.

No time like the present.

After working on this for a couple of days, I've activated a feature on my reassessment management app that allows credits to expire.

Screen Shot 2015-10-15 at 8.45.55 AM

Right now, I will be expiring credits manually. I need to see how students respond to this change before the system does this automatically. I get a visual indication that a given credit has expired and click the 'fire' button to expire the credit. I can also restore the credit if I change my mind. The asterisk button lets me apply the credit lifetime in the input box to a specific credit and change the expiration.

For old credits, I applied a much longer lifetime, but as students learn to adjust their behavior, I'm starting with a ten day expiration lifetime. That seems to be just the right amount of time to get students assessing within a reasonable amount of time of doing work related to a standard. I don't think this changes the time pressure to learn something within a given amount of time, which is one of the benefits of SBG. It does change the pressure to assess within a given amount of time, which I do want to happen.

I'm also adjusting some of my policies that cause the hoarding in the first place. Some of this tendency was a consequence of my system - I haven't let students go from a 5 to a 10 (on a ten point scale) with one assessment session. Mastery is demonstrated over time. I typically had students go from a 5 to an 8 on a perfect first assessment, and then left it there until the unit exam, when students can demonstrate mastery of standards in the context of many other problems.

I'm planning to loosen this progression in light of the credit expiration changes here. If a student is able to demonstrate the ability to answer questions related to a standard, no matter what I throw at them, that's a pretty good hint on their mastery level. It's up to me to give reassessment questions that measure what I'm looking for though. That's where the art of good assessment and experience comes in. I reserve the right to not raise the mastery level if I'm not convinced of a student's level - students know that taking a reassessment does not automatically mean their level will be raised. As long as that understanding continues, I think these changes will lead to better learning.

As always, I'll keep you all updated with how well this works in practice. I can always turn this feature off if it's a disaster.

Building (Ev)anAcademy Exercises for Reassessments

I've written multiple times previously about WeinbergCloud, the system I created using the Meteor framework that lets students sign up for reassessments. Over the course of the semester, I've been developing some aspects of the system that I'm excited about, and I'll talk about them all eventually. One in particular has held my focus for the past few days, and it's probably the one feature I've been talking about for the longest: building a reassessment engine within the system.

Part of this is out of necessity. The wireless network settings on our school network have changed, so the Python reassessment engine that I've used for reassessments over the last two years no longer works when hosted on my personal laptop. I've managed reasonably well this year using problems from textbooks and handouts, but it became time to automate this using my new knowledge of Javascript and Meteor.

Whatever your feelings about Khan Academy, the reality is that the organization has put a lot of energy and resources into developing a pretty comprehensive web application built around assessment. Not only are these resources available for free for teachers and students to use, but the source code is as well. The code for anyone to be able to run their own local version of exercises has been around for a while at Github here. The Javascript libraries that go with these exercises are also pretty impressive and capable - generating random numbers with constraints, simplifying fractions and expressions, and numerous other helper functions are already written by people that code much better than I do. They also wrote a math-typesetting library called KaTEX that has some performance advantages over some other libraries...or so I hear. I'm sure much of the 'why' here is lost on me.

After two days of tinkering, I've adapted some of their code in my app for the purposes of generating questions for reassessments. Writing questions and defining variables is all done in HTML, just as in their own local application, which means it's possible to add questions without having to load in a database through FTP or some other method. The code rendering the questions onto the webpage I had to write myself, but eventually I determined some ways to make this work for me.

I can put in HTML and Javascript definitions into text areas. Here's an example of a question asking for a simplified fraction for slope:
Screen Shot 2015-10-02 at 9.14.46 PM

A preview appears below to make sure the question appears the way I want it. In the variable definitions are strings of Javascript code that calculate and define the variables using the Khan Academy utility functions. The question text is then rendered using KaTEX. The random values change on each reload of the page, but these values could potentially be fixed for an individual student's quiz.

As I create frames for questions, I get a virtually infinite supply of questions I can use for assessing students on learning. Here are a bunch that I put together for testing the interface:

Screen Shot 2015-10-02 at 9.35.43 PM

The next step is to link each question frame to a course standard and build my database of questions. I'm loving the possibilities for building on this further, and will share as they develop. Stay tuned.

#TeachersCoding: Building a VotingBooth with MeteorPad

I previously wrote about a game that I had students build as part of our Meteor app building unit.

Here's another video series that would be of much better use to teachers: Have students vote on an answer to a question. The example I gave in class was of students voting on which picture of my dog Mileaux was the best.

mileauxChoose

This is a fairly simple application of Meteor principles that could be useful in a classroom setting. Since it's all done on MeteorPad, you don't have to install anything on your computer. If you threw this together, and then wanted to actually give it to a class, you could give them the link highlighted in red in the image below. NOTE: This link will change whenever you reload the Meteorpad page, so make sure you share the one corresponding to your instance of the application.

Screen Shot 2015-07-23 at 10.49.18 PM

You can visit the fully functioning code and try it out at this link:
VoteForMileaux - MeteorPad

2014-2015 Year In Review: Web Programming

This was the first year I've taught a computer programming course. The class was a broad survey of programming in HTML5. This was the overall sequence:

    Semester 1:

  1. Hacking a webpage from the browser console
  2. HTML tags, structures, and organization
  3. CSS - page design, classes and IDs, along with using Bootstrap
  4. Javascript - variables, structures, conditionals
  5. jQuery - manipulating the page using events and selectors, animations
  6. Semester 2:

  7. Mongo Databases & Queries
  8. HTML Templates using Blaze
  9. Writing Meteor Apps
  10. Meteor, Media, and the HTML5 Canvas
  11. HTML5 Games using Phaser

I have posted the files and projects I used with students at this repository on Github:
https://github.com/emwdx/webprogramming2014-2015

What did I do?

The class generally began with a warm-up activity that involved students analyzing, writing, or running code that I gave them. This always led into what we were going to explore on a given day's lesson. I would show the class a few lines of code, ask them to make a prediction of what they thought would happen. This might be a visual request - what will this look like? Will there be an error? Was this error intentional or not?

This was all done while students had their laptops closed and notebooks open. I usually designed a series of tasks for students to complete using some code snippets that were saved in the directory on the school server.

We didn't use any textbook, so I knew I needed to create a reference that students could refer back to whenever they got stuck. For each class, I took notes either in Microsoft OneNote or the SMART Notebook software and saved the notes in PDF form. I don't know if students used this or not.

I had three types of assessment:

  • Mini-projects, which were fairly straight forward and had unique answers. These were assessed by general completion (4.5/5) with a (5/5) given for effort to creatively make the code their own. I was fairly loose on that final half point, giving it whenever I saw students clearly engaged by the task. You can see an example of this assignment here.
  • Projects, which had clear guidelines and requirements to meet the minimum grade that ranged from 80 - 90 percent, and then a series of additional tasks that raised the grade up to 100%. The additional task points weren't awarded until the basic requirements were met, though that didn't stop students from trying (see below).
  • Blog posts, which were required for every class. The expectations required a summary of what we learned for each class, along with code snippets, questions about what we learned, or confusion about something they wanted to go over in the next class. As the students became more skilled, this turned into questions that started as "How can we.../Is it possible to...".

Once every two weeks, and usually on a Friday, I had a 20% day during which students could work on anything they wanted related to web programming. Some students worked on previous projects to resubmit them, others experimented with code from the previous class or week. In a couple of cases, students worked on their own pet projects, which included a chat application, a mathematical formula parser, and applying visual design principles to the pages we created in class. I often made suggestions for what students could do at the beginning of the class block, including providing some basic code they could use to experiment.

What worked:

  • Based on feedback from the end of the year, students enjoyed the course. They had a lot of positive comments on the ways I ran the class and that they always got help when they needed it.
  • Forcing students to write down code helped with retention and building a useful reference for later. I didn't require them to write down long blocks of code, but for things like HTML tags and Javascript, I wanted there to be some written reinforcement that things were important. I was pretty strict on deciding when I wanted students to write down code (to activate that part of the brain) and when I wanted them to copy it directly into a text editor and run it.
  • Forcing students to recreate code (and not copy and paste) led to higher activity and interaction between students while learning to code. I saved some code as images, not text, which required students to go line by line and see what they were doing. This was a decision I made early on because it helped me when learning to code. That extra step of needing to look at the code while I was typing it in led me to take a closer look at what it said, and I wanted to give a similar opportunity to my students.
  • The more open ended projects led to much richer questions and interaction between students. I really liked the range of responses I received when I gave open ended projects. Some students were exceptionally creative or went well beyond the requirements to make code that mattered to them.
  • Students were constantly helping each other with their code...when they eventually asked for this help. I was called over many times by students calling out the blanket statement "my code doesn't work" and then handing me their laptop, but over time they learned that I wasn't going to just fix their code for them. They became careful readers of each other's code, when they finally made the step to ask someone to help, though this took some time.
  • I succeeded in having students do more than listen. I never talked for more than 15 minutes before students were actually writing and experimenting with code. This was exactly what I wanted.
  • 20% days were a big hit. Some students wanted this time as extra processing time to complete the mini projects from the rest of the week. Others liked being able to ask me how to do anything, or to find tutorials for HTML elements that they wanted to learn to use. I really liked how well this worked with this group of students and looked forward to it, and not just because it was a reduction in the planning required for class.
  • Videos offered an effective and preferred method for learning to write code in this class. I put together a number of screencasts in which I spoke about the code, and in some cases coded it live. Students were able to pause, copy code to the editor, and then run it pretty easily. Some zipped through it, others took longer, but this is nothing new. The time required to do this, as is always a consideration for me, was often more than I could afford. Luckily, there is plenty of material available already out there, so I was able to step back and give another voice and face a chance to teach my students.

What needs work:

  • The bonus elements for projects were the first things most students wanted to figure out first. Many students did not put in the time to read and complete the basic requirements for projects, resulting in submitted projects that were sent right back as being incomplete. Some of this was a language issue, as there were many ESOL students in the class, but most of it was what we always encounter when working with adolescents: not reading the directions.
  • Students reused a lot of old (and unrelated) code. I emphasized creating simple code from scratch throughout the year, as my expectations were relatively simple. For many students, copying and pasting code was a crutch that led to many more problems than simply writing simple, clean code from the start. I get it - I copy and paste code myself - but I also know how to clean it up. They knew why not to do it (because they all tried it at some point) but some students continued doing it to the end. I need a better plan for helping students not fall into this trap.
  • Many students did not pick up on error messages in the console that said precisely where the problem with the code was located. At times, I expected too much from students, because the console is a scary place. That said, I think I could do a better job of emphasizing how to find the line numbers referenced in these errors messages, regardless of what the error message is.

I really enjoyed teaching this class, and not just because of the awesome group of students that took it. It helped me refine my knowledge and get better at some of the HTML, CSS, and Javascript coding skills that I had used, but often had to relearn every time I wanted to use them.

Feedback, as always, is welcome!

MeteorPad Tutorial: GoldMine

In a unit on Meteor applications for my web design class, I wrote a series of applications to help my students see the basic structure of a few Meteor applications so that they could eventually design their own. The students had seen applications that tallied votes from a survey, compiled links, and a simple blog. This one was about being competitive, and the students were understandably into it.

This tutorial was designed to use MeteorPad due to some challenges associated with installing Meteor on student computers. The first one involved permissions issues since students are not by default given access to the terminal. The second involved connectivity issues to the Meteor servers from China, which unfortunately, I never fully resolved. MeteorPad offered an awesome balance between ease of making an application and minimizing the need for Terminal. For anyone looking to get started with Meteor, I recommend trying out MeteorPad as it doesn't require any knowledge of working in the terminal or software installation.

I was able to take data on the students clicking away as I created new pieces of gold and put it out into the field. I've written previously about my enthusiasm for collecting data through clicks, so this was another fun source of data.

Code can be downloaded here from Github.

Online School Resumes with Meteor

As you may know, I've been teaching a web programming course this year. I wrote previously about the work we did at the beginning of the year making interactive websites using the Meteor framework. Since then, we've spent time exploring the use of templates, event handlers, databases, and routing to build single page applications.

The latest assignment I gave students was to create an online school resume site with a working guestbook. I frequently discuss the importance of having a positive digital footprint online, and one of the most beneficial ways of establishing this is through a site created to share their work. Students worked last week to complete this and submitted their projects. We've had connectivity issues to the Meteor servers from China from school. As a result, some students used Meteorpad, which unfortunately means their sites aren't permanent.

Those that were successful at deploying, however, have persistent guestbooks that anyone can visit and comment upon. Some students added secret pages or like buttons to show that they have learned how to use the reactive features of Meteor. The students were excited when I said I would post links on my blog and have given me permission to share. Here is the set of deployed sites:

Maria's Site
Dominick's Site
Tanay's Site
Luke's Site
Steven's Site
Tiffany's Site

I'm really proud of how far these students have come since the beginning of the year. They have accrued some bad habits of copying code and avoiding commenting their Javascript, but I take some responsibility for not holding them accountable for this. My goal was to have the focus of this course be on building and creating as the first priority, and the second on developing skills as programmers. As with many of the subjects I teach, helping students see the need for the basics is often most easily done with the end product in mind.

If anyone wants recommendations for a summer hire, let me know.

Coding WeinbergCloud - An Update

Over the past few weeks, I've made some changes to my standards based grading system using the Meteor framework. These changes were made to address issues that students have brought up that they say get in the way of making progress. Whether you view these as excuses or valid points, it makes sense to change some of the features to match the students' needs.

I don't know what standard 6.2 means, Mr. Weinberg.

There are many places students could look to get this information. It does make sense, however, to have this information near where students sign up for reassessments.

When students select a standard, a link pops up (if the standard exists) with a description. This has made a big difference in students knowing whether the standard they sign up for is what they actually intend to assess.

Screen Shot 2015-02-13 at 1.07.27 PM

I also added the entry for the current mastery level, because this is important in selecting appropriate assessments. The extra step looking it up in the online gradebook isn't worth it to me, and asking students to look it up makes it their responsibility. That's probably where it belongs.

Can you post example problems for each standard?

The biggest issue students have in searching for online resources for a specific standard is not knowing the vocabulary that will get the best resources. There's lots of stuff out there, but it isn't all great.

I post links to class handouts and notes on a school blog, so the information is already online. Collecting it in one place, and organizing it according to the standards hasn't been something I've put time into.

Students can now see the standards for a given course, listed in order. If students are interested, they can look at other courses, just to see what they are learning. I have no idea if this has actually happened.

Screen Shot 2015-02-13 at 1.20.19 PM

Selecting a standard brings a student to see the full text and description of the standard. I can post links to the course notes and handout, along with online resources that meet my standards for being appropriately leveled and well written.

Screen Shot 2015-02-13 at 1.20.40 PM

At the moment, I'm the only one that can add resources. I've written much of the structure to ultimately allow students to submit sites, up-vote ones that are useful to them, and give me click data on whether or not students are actually using this, but I'm waiting until I can tweak some UI details to make that work just the way I want it.

Mr. Weinberg, I signed up for an assessment, but it's not showing up.

The already flaky internet in China has really gotten flakier as of late. Students are signing up for reassessments, but because of the way I implemented these requests being inserted into the database, these requests weren't actually making it to the server. I've learned a lot more about Meteor since I wrote this a year ago, so I've been able to make this more robust. The sign-up window doesn't disappear until the server actually responds and says that the insert was successful. Most importantly, students know to look for this helper in the upper left hand side of the screen:

Screen Shot 2015-02-13 at 1.14.13 PM

If it glows red, students know to reload the page and reconnect. Under normal Meteor usage conditions, this isn't a problem because Meteor takes care of the connection process automatically. China issues being what they are, this feature is a necessity.

I've written before about how good it feels to build tools that benefit my students, so I won't lecture you, dear reader, about that again. In the year since first making this site happen though, I've learned a lot more about how to build a tool like this with Meteor. The ease with which I can take an idea from prototype to production is a really great thing.

The next step is taking a concept like this site and abstracting it into a tool that works for anyone that wants to use it. That is a big scale project for another day.

Web Application Design Class and Meteor

The first semester of my web design and programming course was an overview of HTML, CSS, Javascript, and jQuery. The end goal is to get students piecing together their own web applications using the Meteor framework. I don't know how sophisticated these will be. The prototypes they are putting together, however, as well as the questions they are asking, show that they are ready for Meteor.

Given that few of my students have programmed before this class, there are some gaps in knowledge that I'll need to think through. The one thing I didn't want to do in this class was declare that students need to go through a full CS course before being able to touch this material. The value of a framework like Meteor is the ease with which anyone can piece together an application. The most consistent theme in this course has been that getting students working with code and troubleshooting upfront is much more productive than a lecture on for-loops. My model has been to have students take a piece of code, figure out what it does, and then hack or tweak it to do something different. As students get more experience, they become more comfortable writing code from scratch to complete a task.

Despite knowing this about my group, I almost didn't do continue the model in exactly this way after the winter break. I was going to do a unit on classes and methods, but in my brainstorming how to do this, I realized that the better approach would be to look at database queries and MongoDB. The concepts of properties would be obvious in the way Mongo stores information, so it would then be easy to talk about the concept of objects once students were interacting with the database. Again, this became more 'Application first, theory second.'

This also meant I had another opportunity to bring up fundamentals of computational thinking. I opened up the lesson by having students look at a screen sized list of all of the ninth grade students and some of the information stored by the school. I asked them questions like this:

  • How many students in Mr. S's advisory are girls?
  • How many students in the red or blue house are in Mrs. M's advisory?
  • Do any students share the same birthday?

They didn't mind this too much, but there were some different answers to the questions that came from counting by hand. It was fairly mindless work and none of them were too bothered by my requests to do it with this data set. Then I told them that we were going to do the same with the list of 160 students in the entire upper school.

Groans.

They didn't ask it because they know me at this point, so I told them that there was, of course, a better way. I taught them some Mongo queries using a sandboxed collection consisting of student information from the school. I then set them loose with a list of questions about a fictional database of people that I generated and posted at http://citizens.meteor.com. (The names for the collection came from the cast list for the most recent Hobbit movie. A fun side project, by the way.) A subsequent lesson was about sorting, limiting, and interacting with an array of returned documents, and students handled it well. We did some quick demonstrations of dot notation, but I didn't make a big deal out of it.

In the next class, I gave students the following prompt:

Mr. Weinberg wants to survey students on their favorite ice cream flavor. He wants to be able to sort the results by grade, gender, and house. Sketch the layout of a web form he could use to collect this information.

Their sketches were good fun:
64BADB57 - image

05D37A55 - image

D844222E - image

I asked them to then work backwards from their database experience: What would a single document in the database containing the results of this survey look like? They were coming up with sample properties and values. I then showed them how these values could be captured from the form elements using jQuery.

Then came the Meteor magic.

I took the web form and pasted it into a template. I took the jQuery calls and put them in an event handler for the template. I added a line to create a collection, made another quick template to show results, and then made a helper to fill that template with the entries in the database. One last thing I put in to prevent rapid submissions – calls to clear out all of the form elements after the database insert.

I typed meteor in the terminal, fixed one error, and then the app was live. I had students go to my IP address and the form popped up. The page started filling with survey results as students realized they could interact with the page. These were initially full submissions, but soon after, lines with empty values showed up as students realized that they could add garbage data and submit them really quickly. I told some of the students that were doing this that people would be doing that with their apps soon, so there would need to be a way to handle it in their apps.

I then set students off in groups to do this same process with different web applications along the lines of the one I used to start class. It was incredibly fun hearing them talk about how they were going to move forward, including a number of new web page sketches. I gave them more concepts to work from, including an after school activities form and a web portal through which students could tell school administration that they were going to be late to school. I asked them to write down potential database queries to help find important information quickly. The really impressive part came when they had ideas for what they wanted to program. One student suggested a database of sports scores. Another, an online store.

The class was abuzz with ideas for what was possible. I knew that I had to show students how to get these into Meteor the next class, in the easiest way possible.

Enter Meteorpad. I made a streamlined form with instructions on how to take the web forms they had designed and get them into a template with as few steps as possible. The students don't currently have terminal access on their Macbooks, so I can't get them to run Meteor locally.

You can check out the MeteorPad template I gave them here:
here...

...and the full set of instructions for adapting their code to it here.

They followed the instructions, and by the end of the class, most had their own versions working. The students then started tweaking them to see what they could do to make it work as they wanted.

Today, my students were going from an idea concept to coding their own apps to getting these prototypes online. Yes, they were primitive, lacked error handling, styling, and had typos. No, the students didn't have much understanding of the differences between helpers and event handlers. That is just fine. It's only January! I originally thought we'd get to this point by the end of the year, so this is a great point to be at right now.

I'm can now help students take their ideas and turn them into working prototypes. These students know how to look up code to do what they want to do. They've happened upon W3Schools web pages and StackOverflow, and while they are generally overwhelmed by what they find there, they know how to ask me the right questions about what they see. This was a great way to end a busy week.

Have a great weekend, everyone!