Skip to content

Instantly share code, notes, and snippets.

Pieter Soudan Sewdn

Block or report user

Report or block Sewdn

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
View project-builds.md

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
Sewdn / ytdr.md
Last active Aug 29, 2015
Yououtdoor
View ytdr.md

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
View private-packages.md

##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?

View query-collections.md

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:

View automongobackup.sh
#!/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
Sewdn / SassDynamicVariables.scss
Created Jul 30, 2012 — forked from rhythmus/SassDynamicVariables.scss
dynamic variables for Sass (squaring the circle :-)
View SassDynamicVariables.scss
@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);
}
You can’t perform that action at this time.