Monthly Archives: March 2016

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.

Taking Time Learning Math: A Student's Perspective

Yesterday was our school's student led conference day. I've written previously on how proud these days make me as an educator. Whens students do genuine reflection on their learning and share the ups and downs of their school days, it's hard not to see the value of this as an exercise.

During one conference, a student shared a fascinating perspective on her learning in math. This is not the usual level of specificity that we get from our students, so I am eager to share her thinking. Here's the student's comment during the conference:

“It isn’t that I don’t like math. Learning takes time in math, and I don’t always get the time it takes to really understand it.”

I asked her for further clarification, and this was her response:

...Math is such an interesting subject that can be “explored” in so many different ways, however, in school here I don’t really get to learn it to a point where I say yeah this is what I know, I fully understand it. We move on from topic to topic so quickly that the process of me creating links is interrupted and I practice only for the test in order to get high grades.

It's certainly striking to get this sort of feedback from a student who is doing all the things we ask her to do. The activities this student is doing in class are not day-after-day repetitions of "I do, we do, you do" - we do a range of class activities that involve exploring, questioning, and interacting with other students.

This student's comment is about limitations of time. She isn't saying that we aren't doing enough of X, Y, or Z - quite the contrary, she just is asking for time to let it sink in. She doesn't answer the question of what that time looks like, but that's not her job, it's ours.

I know I always feel compelled to nudge a class forward in some way. This doesn't mean I moving through material more quickly, but I do push for increased depth, intuition, or quality conversation about the content in every class period. Her comment makes me realize that something still stands to be improved. Great food for thought for the weekend.

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:

Choosing the Next Question

If a student can solve $latex 3x - 1 = 5 $ for x, how convinced are we of that student's ability to solve two step equations?

If that same student can also solve $latex 14 = 3x + 2 $ , how does our assessment of their ability change, if at all?

What about $latex -2-3x= 5$ ?

Ideally, our class activities push students toward ever increasing levels of generalization and robustness. If a student's method for solving a problem is so algorithmic that it fails when a slight change is made to the original problem, that method is clearly not robust enough. We need sufficiently different problems for assessing students so that we know their method works in all cases we might through their way.

In solving $latex 3x-1 = 5 $ , for example, we might suggest to a student to first add the constant to both sides, and then divide both sides by the coefficient. If the student is not sure what 'constant' or 'coefficient' mean, he or she might conclude that the constant is the number to the right of the x, and the coefficient is the number to the left. This student might do fine with $latex 10 =2x-4 $ , but would run into trouble solving $latex -2-3x = 5$ . Each additional question gives more information.

The three equations look different. The operation that is done as a first step to solving all three is the same, though the position of the constant is different in all three. Students that are able to solve all three are obviously proficient. What does it mean that a student can solve the first and last equations, but not the middle one? Or just the first two? If a student answers a given question correctly, what does that reveal about the student's skills related to that question?

It's the norm to consider these issues in choosing questions for an assessment. The more interesting question to me theses days is that if we've seen what a student does on one question, what should the next question be? Adaptive learning software tries to do this based on having a large data set that maps student abilities to right/wrong answers. I'm not sure that it succeeds yet. I still think the human mind has the advantage in this task.

Often this next step involves scanning a textbook or thinking up a new question on the spot. We often know the next question we want when we see it. The key then is having those questions readily available or easy to generate so we can get them in front of students.