the-simian

import bpy
import os
import time

# get the scene
scn = bpy.context.scene

# get the output path
output_path = scn.render.filepath

the-simian

var Twitter = require('twitter');   
var client = new Twitter({
    consumer_key: '',
    consumer_secret: '',
    access_token_key: '',
    access_token_secret: ''
  });
    
var stream = client.stream('statuses/filter', {track: 'Garth Brooks'});
stream.on('data', function(event) {

the-simian

//take a joi object and return a string that is actually ok to display on a front-end

import _ from 'lodash';

function joiToEnglish(joiErr){
  return _
    .chain(joiErr.details)
    .reduce((collected, detail) => {
      collected[detail.context.key] = collected[detail.context.key]  || [];
      collected[detail.context.key].push(detail.message.replace(`"${detail.context.key}"`, ''));

the-simian

"Overcoming Anxiety ...and the Silent Functional Revolution"

Where does programming anxiety come from?

Sometimes the worst thing you can do is learn how your favorite framework is actually built. This can happen quite by accident; when you finally have enough moving pieces and start to hit the walls of that framework's abstraction. Digging deeper and deeper until you've turned it inside out and question the ship upon which you sail as you drift into the deep waters of complexity. You feel the impending obsolesce of your current tools, and possibly the very programming patterns you've known all these years. The more you learn, the more anxious you become.

And there is this undercurrent in the blogs, tweets, articles and thought-leadership that is pecking away at your certainty. They are all saying you should be more functional. What is functional? Does that mean React? or Lodash? Is it something a language is, or something a framework does?

This talk is about making sense of all of this confusion, in

the-simian

var gulp = require('gulp');
var webpack = require('webpack');
var config = ('../../../webpack.config')

var config = {
 ///
};

function buildScripts(callback) {
  

the-simian

'use strict';

var gulp = require('gulp');
var webserver = require('gulp-webserver');

var serverOpts  = {
      livereload: true,
      //directoryListing: true, //toggle this to show directory listing instead of serve index
      open: true
    };

the-simian

'use strict';

var gulp = require('gulp'),
  ghPages = require('gulp-gh-pages');

function deploy() {
  return gulp
    .src('./dist/**/*')
    .pipe(ghPages());
}

the-simian

Object.keys(Event).forEach(function (etype) {
    if(etype.indexOf("MOUSE") > -1){
       return;
    }
    document.addEventListener(
        etype.toLowerCase(), console.log.bind(console), false
    );
});

the-simian

#External Task Groups in Gulp.

###Goal: Create a group of reusable tasks as a fully seperate module, that can maintain their dependencies, and be integrated into many other projects. The reason to extenalize these, is for a few reasons. Firstly, I Imagine this as a private module for myself or my shop to use. In some ways it violates the modularity of existing npm modules. This isnt a single purpose item sporting the usual prefix gulp-whatever. Another reason is it allows to keep a standardized stask list for a shop up to date across multiple projects, without duplicating the code in many projects. In our case, we have some frontend devops tasks , such as complxity analysis, hintling, linting, test runnign and so on. We want to be able to maintain that process, while giving everyone a similar entry point. If we improve the 'shops devops tooling' it would be nice to not have to go to every single project and add more code. Finally, this allows the quite large list of gulp- dependencies in the npm file to

the-simian

80's Baby
larz0 (https://github.com/larz0)
1.0.2	 80's Baby Theme for Brackets. Inspired by Silkie's 80's Baby. A Brackets original.

Beautify
Drew Hamlett [email protected] (https://github.com/drewhamlett/)
1.1.5	 Format JavaScript, HTML, and CSS files

Bigger Extensions Panel
Alex Bardanov