For almost two years, I’ve been developing Meteor using several Ubuntu VMWare virtual machines running inside a Windows host; this weekend, I moved all of my Meteor development functions to Windows native, taking advantage of the new Meteor Windows support.
You might ask: why would one do this? The main reason is that it will smooth out some kinks in my development process. Much of this has to do with Eclipse. Many months back, I used to run Eclipse on Ubuntu (Unity) on VMWare, and I’d do all of my editing from within the Ubuntu operating system.
Because I desperately needed multiple displays, I was doing something kludgy: I had created a network mount on Ubuntu (which contained my source code), then using Eclipse on Windows, I was able to map a network drive to that Ubuntu network share using Samba. The effect was my Windows Eclipse would modify the Ubuntu-resident source code, and I could therefore use multiple displays. In order to build or do other things, I’d switch over to Ubuntu, but editing was done on Windows.
I am now building Meteor on Windows. I have created a bunch of batch scripts that support the build/release process, including scripts to automatically SSH or FTP builds to my test Ubuntu machine or EC2.
So, things are better, but not perfect. Because Meteor Windows support is bleeding-edge, there are some warning messages that are generated during the build and install processes. Apparently these messages are non-fatal, but they can give you pause because during those operations you tend to want everything to go perfectly. I believe that when Meteor upgrades to a later version of Node.js these problems will be solved. Currently Meteor is on Node.js 0.10.36, which is a couple of releases back (Node.js is now at 0.12.X).
I still have one mundane task left to complete this process, and that is to get my Windows MongoDB database set up as a replica set so that it closely matches production. Replica set can really help Meteor performance, because Meteor can leverage the so-called OPLOG to get notified of state changes in MongoDB the second they happen. Without a replica set, Meteor goes into a different mode where it polls for state changes. It also spends a significant amount of time doing comparisons (before and after) of result sets to infer state changes. None of this is needed with OPLOG enabled, so once this is done I should be getting snappy performance from my development environment. We have OPLOG tailing set up on on all of our production instances, and I can attest it makes a big difference.