Tutorial by Examples

Finally, we want to get some of our dynamic data to be stored offline. meteor add ground:db Lists = new Meteor.Collection("lists"); GroundDB(Lists); Todos = new Meteor.Collection("todos") GroundDB(Todos);

The appcache will cause some confusion in your development workflow, because it hides Meteor's auto-updating features. When you turn off the server component of your app, the client portion in your browser will continue working. This is a good thing! But, you don't get the immediate feedback that ...

The first step to logging is simply to run Meteor from the shell, and you'll get the server logs in the command console. meteor The next step is to pipe the contents of std_out and std_err to a logfile, like so: meteor > my_app_log.log 2> my_app_err.log

Once you have your server side logging in place, it's time to hop over to the client side. If you haven't explored the console API, be prepared for a treat. There's actually all sorts of things that you can do with the built in Console API that's native to every Chrome and Safari installation. So mu...

Once you have both your server-side logging running, and your client side development tools, you can start looking at Meteor specific extensions like the Meteor Chrome DevTools Extension. This lets you actually observe server logging in the client! Because the database is everywhere. As is logging. ...

The following example is from 0.5 - 0.7 days, and illustrates how to log an error when the database hasn't populated the client side cursor yet. Template.landingPage.postsList = function(){ try{ return Posts.find(); }catch(error){ //color code the error (red) console.error(erro...

The following uses the Chrome Logging API. If the .group() syntax is used in multiple templates, it will graphically organize the console logs from different templates into a hierarchical tree. You can also see how to inspect the current data context, and how to stringify data. Template.landingPa...

Simple example of using the Chrome Logging API. Template.landingPage.events({ 'click .selectItemButton':function(){ // color code and count the user interaction (blue) console.count('click .selectItemButton'); } });

Logging can often clutter up the console, so it's common to define log levels to control what detail of data is getting logged. A common pattern is to specify a log level variables. var DEBUG = false; var TRACE = false; Template.landingPage.events({ 'click .selectItemButton':function(){ ...

Some teams find that they want to leave console log statements in their code, but not have them display in production. They will override the logging functions if a variable isn't set (possibly an environment variable). Additionally, this may qualify as a security feature in some situations. if (...

If you need something more powerful than the default logging options, you might want to look at a tool like Winston. Go to Atmosphere, and simply search for one of the many Winston packages available. https://atmospherejs.com/?q=winston Be warned, however - Winston is a sophisticated product, and ...

A special mention should be made for the community developed LogLevel package. It appears to strike a balance between being lightweight and simple to use, while working well with Meteor's bundle pipeline and preserving line numbers and filenames. https://atmospherejs.com/practicalmeteor/loglevel ...

This deployment guide assumes you're using an Ubuntu server, and are either self-hosting or using an Infrastructure as a Service (IaaS) provider, such as Amazon Web Services or Rackspace. Your Ubuntu server needs to be running a daemon for launching other apps, for which we recommend the Upstart ser...

One favored approach to deploying to a server is to use Git or GitHub. This basically involves logging into your server, moving to the directory you want to run your app from, then cloning your files directly from GitHub. You then build your app on the server. This approach ensures that platform spe...

Alternatively, you may want to build your application, and then deploy it.. cd myapp meteor build --directory ../output cd .. scp output -r username@destination_host:/var/www/myapp-production

You'll need an upstart script in your /etc/init/ directory. Name it with your app's name, ending in .conf, such as /etc/init/myapp.conf. The basic upstart script looks something like this: ## /etc/init/myapp.conf description "myapp.mydomain.com" author "[email protected]&quot...

If you're running a replica set or have a need to shard your database, you'll want an upstart script that looks something like this: # /etc/init/myapp.conf description "myapp.mydomain.com" author "[email protected]" # used to be: start on startup # until we found som...

Finally, you'll need to start the Upstart daemon, and initialize your app as a service. sudo service myapp start

https://www.phusionpassenger.com/ https://github.com/phusion/passenger https://github.com/phusion/passenger/wiki/Phusion-Passenger:-Meteor-tutorial#wiki-installing

Both Chrome and Safari have built in debuggers. With Chrome, all you have to do is right-click on a web page and 'Inspect Element'. With Safari, you'll have to go into Preferences > Advanced and click on 'Show Develop menu in menu bar'. With Firefox, you'll need to install Firebug