Sewdn

  // Available variables:
  // - Machine
  // - interpret
  // - assign
  // - send
  // - sendParent
  // - spawn
  // - raise
  // - actions

Sewdn

TL;DR

Meteor is great at sharing code between different builds for different platforms. You can use the same source for your browser builds, server builds, your builds for iOS, Android, ... But how to organize your project to be able to orchestrate your builds for different apps and services from the same source? This post elaborates on the reasons why you need these different builds and how you could accomplish this with Meteor easily.

Use cases: Why would you build different apps?

1. Different apps for different roles

Say you have an app with completely different end user experiences depending on their role. It is common practice to have the user logged in, check her authorization (role) and then setup different routes or load different templates to serve that type of user’s needs. While doing so, all types of users load the same build and the app decides what portions of the build to use and what not to use.

Sewdn

Youtdoor Bookings platform

TL;DR

Make your existing customers spend more and reduce your sales cost.

Possibilities of platform

Setup a platform for your customers where he can

• browse the available advertising locations
• browse the available advertising formats/possibilities
• browse the availability of advertising locations

Sewdn

##TL;DR A package eco-system like atmosphere.js is great! Every developer should share his and give back to the community. However, sometimes there is no real value in sharing your packages (they're just too domain specific). But you still want to share these packages across different applications, and work on them with a team of developers. This pattern describes how to setup private packages using git submodules.

Why is this useful?

Sewdn

TL;DR

A query defines a set of conditions on a collection of documents. Most of the time, only the documents that meet these conditions need to be published to the client. In many cases the query's conditions are subject to the state of the application (for instance the selected sorting field). This pattern describes how to update your query's result set reactively with meteor without losing the cursor's state. This way, results are preserved over different adjustements of a query if they meet both set of conditions.

an example case

To illustrate this pattern best, we'll be using the following example case throughout.

Let's say you have a collection of Players and a collection of Games. We track each score in a Scores collection. Some example data:

Players:

Sewdn

#!/bin/bash
#
# MongoDB Backup Script
# VER. 0.1
# Note, this is a lobotomized port of AutoMySQLBackup
# (http://sourceforge.net/projects/automysqlbackup/) for use with 
# MongoDB.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by

Sewdn

@mixin makecircle($height: 10px, $width: 10px) {
    $radius: sqrt(($height * $width)/pi());
    @include border-radius($radius);
    height: $radius*2;
    width:  $radius*2;
}

.myCircle {
    @include makecircle(10px, 25px);   
}