/*
*= require "application/all"
*/
=begin | |
Need to install gems heroku, newrelic_rpm | |
$ gem install heroku newrelic_rpm | |
Set your apps setting | |
app_name : heroku's app_name of auto scaling | |
license_key : NewRelic api key. You can get heroku's NewRelic admin console. "App setting" and "Agent configuration" | |
execute with cron every minutes | |
$ ruby ./adjust_dynos_with_newrelic.rb |
// ==UserScript== | |
// @name Show Full Domain on Hacker News posts | |
// @description Sets full domain on hacker news posts. | |
// @namespace http://userscripts.org/users/119115 | |
// @include http://news.ycombinator.com/* | |
// @include https://news.ycombinator.com/* | |
// @match https://news.ycombinator.com/* | |
// @match http://news.ycombinator.com/* | |
// ==/UserScript== |
(ns noise.gen | |
(:require [ionsails.noise.perlin :as perlin])) | |
(defn get-range | |
([width] | |
(for [x (range width)] | |
(vector x))) | |
([width height] | |
(for [y (range height) | |
x (range width)] |
We can look at two sides of the management coin: What do the individuals get out of it? And what benefit does the whole system derive from it?
I will disregard any benefits that accrue to managers just by holding the position of managing. Those are just circular logic. Circular logic abounds in discussions of management and hierarchy. For example, consider status reports. It will be said that status reports are necessary so managers know what their employees are working on. It’s
Turning The Design Clock Back | |
Object-oriented design principles haven't had the effect we hoped for. The | |
SOLID principles are excellent design guidelines, but experience shows that | |
programmers find them difficult to follow. What do we do about this? | |
Surprisingly, the Structured Design literature of forty years ago contains | |
compelling solutions to many current design problems. They're simple and easy | |
to understand, but were lost in the noise as OO rose to popularity. We'll | |
reinterpret these simple design ideas in a modern context, finding that many of | |
our most promising new design ideas resemble them. Rapid web application |
I've been struggling to come up with a good pattern for handling loading state in Flux (specifically using Fluxxor, though I think this is an issue for any implementation).
When I say "loading state," what I mean is state in a store that tracks:
- Whether the data handled by the store was loaded
- Whether the store is currently attempting to load data
- Whether the data loaded successfully or errored
- The error message, if it errored
Here's my first (very simple) pass at this, a store mixin called LoadingStoreMixin.js
:
Clojure Developer for Malware Analysis Product | |
The ThreatGRID team at Cisco is looking for experienced clojure | |
developers to work on our large scale, malware analysis product. Our | |
entire platform is built on Clojure, from the Clojurescript UI, | |
through the API services, around the event processing subsystem, and | |
down to the core.logic analysis engine. | |
Our system runs as a distributed cluster in the cloud, and shrunk | |
down to a single on-premises appliance. This keeps us focused on |
#!/bin/bash | |
i=0 | |
files=() | |
# sort spec files by number of examples for better balancing | |
for file in $(find ./spec -name "*_spec.rb" -print0 | xargs -0 grep -e "^ *it" -c | sort -t: -k2,2rn | awk -F":" '{ print $1 }') | |
do | |
if [ $(($i % $CIRCLE_NODE_TOTAL)) -eq $CIRCLE_NODE_INDEX ] | |
then | |
files+=" $file" |
require('node.io').scrape(function() { | |
this.getHtml('http://www.reddit.com/', function(err, $) { | |
var stories = []; | |
$('.entry .title').each(function(title) { | |
stories.push(title.text); | |
}); | |
this.emit(stories); | |
}); | |
}); |