We will install Larave 4.1 with PHP5.5 & Latest nginx on Ubuntu 12.04.3 x64.
apt-get update && apt-get upgrade
adduser [username]
usermod -aG sudo [username]
apt-get -y install git
// Include this at the very top of both your main and window processes, so that | |
// it loads as soon as possible. | |
// | |
// Why does this work? The node.js module system calls fs.realpathSync a _lot_ | |
// to load stuff, which in turn, has to call fs.lstatSync a _lot_. While you | |
// generally can't cache stat() results because they change behind your back | |
// (i.e. another program opens a file, then you stat it, the stats change), | |
// caching it for a very short period of time is :ok: :gem:. These effects are | |
// especially apparent on Windows, where stat() is far more expensive - stat() | |
// calls often take more time in the perf graph than actually evaluating the |
const JSZip = require('jszip') | |
const { parseBuffer } = require('bplist-parser') | |
const { isObject, each, find } = require('lodash') | |
const parseArchivedValue = value => { | |
return parseBuffer(new Buffer(value, 'base64')) | |
} | |
const parseArchivedString = obj => { | |
const { $objects } = parseArchivedValue( |
const webpack = require('webpack') | |
const { environment } = require('@rails/webpacker') | |
// Don't use commons chunk for server_side_render chunk | |
const entries = environment.toWebpackConfig().entry | |
const commonsChunkEligible = Object.keys(entries).filter(name => name !== 'server_side_render') | |
environment.plugins.set('CommonsChunkVendor', new webpack.optimize.CommonsChunkPlugin({ | |
name: 'vendor', | |
minChunks: (module, count) => { |
(function () { | |
expose('createMyComponent', register, factory); | |
/** | |
* Exposes your new component to the window or to a module | |
* | |
* @param {string} name - the factory name to expose | |
* @param {function} definition - the definition of your web component. registers to the document | |
* @param {function} factory - method for programmatically creating web component | |
*/ |
/* | |
The original files are 960x319. | |
Image sizes to save: | |
* 800x266 - Retina for 480x320 resolution (400 logical pixel wide panel areas) | |
* 740x246 - Desktop and iPad | |
* 616x205 - Retina for 320x480 resolution (308 logical pixel wide panel areas) | |
* 400x133 - 480x320 resolution | |
* 308x102 - 320x480 resolution |
/** | |
* Fluid typography between a min & max font-size and molten leading | |
* calc(minSize + (maxSize - minSize) * ((100vw - minPort) / (maxPort - minPort))); | |
*/ | |
:root { | |
font-size: 100%; | |
} | |
body { | |
font-size: 1em; |
This is a demonstration of a bi-directional hierarchical sankey diagram produced in javascript, html and css using d3. (Refresh page to generate new random data)
Sankey diagrams represent flows between nodes by varying the thickness of the connecting links.
This diagram was based off of Mike Bostock's sankey diagram, but additionally incorporates bi-directionality into the flow and caters for hierarchical relationships between nodes to allow drill down into the data.
All javascript code to generate the diagram markup is contained in the app.js
file, but the underlying calculations are performed using a custom plugin: bihisankey.js.
This version addresses the issue with double clicking. Demo: http://bl.ocks.org/emoruzzi/6f8140c4d903e64ae35dce0c971e488f
Please read this gist by DasWolke it goes into a much better explanation of why you should use microservice Discord bots.
This is about my experience in making a microservice discord bot.
To start let's look at the core design I was looking for in creating my bot
(https://i.imgur.com/bWxXyc3.png)
I was looking to have multiple gateways that serve different shards groups this design could allow for a beta or premium version of the bot to be hosted on the same service more easily. I also wanted plug and play workers that don't store any information and could be restarted or crash without having any downtime and be scaled just by changing the replica value in docker swarm.
I started using FreeNAS in August 2013. It is fantastic piece of software and I have been really impressed by the upgrades just in the few months I've been using it. It looks like they recently went to a plugin system as of version 9 to make installing software easier for end users. I've ran into several issues related to plugins and user + group permissions so I decided to just use the available FreeBSD port system. After fiddling for a few days (now turned into months) I believe I have created something helpful for the community and anyone interested in picking up the port system. The sandbox nature of FreeNAS's jail system is especially helpful for playing around without having any consequence on your core system.
Here are straight-forward instructions to setting up a bunch of different software on FreeNAS. If you make a terrible error, just throw up another plugin sandbox and repeat.