Tutorial by Examples: t

The first thing to do when taking your Meteor app offline is to create some visual indication of whether the local client app is connected to the server or not. There are lots of ways to do this, but the simplest way is to probably do something like this: Template.registerHelper('getOnlineStatus', ...

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 ...

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 ...

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

You'll need to add debugger statements to your code: Meteor.methods({ doSomethingUself: function(){ debugger; niftyFunction(); } });

For server side debugging, you'll need to use a tool like Node Inspector. Before you get started, check out some of these useful tutorials. HowToNode - Debugging with Node Inspector Strongloop - Debugging Applications Easily Debugging Meteor.js Walkthrough with Screenshots of Using Node Inspecto...

Besides Node Inspector, some people have reported success with a npm utility called debug. MeteorHacks - Debugging Meteor with npm debug