| type OperationState<T> = { | |
| status: 'unstarted'; | |
| } | { | |
| status: 'started'; | |
| } | { | |
| status: 'running'; | |
| isRunning: true; | |
| } | { | |
| status: 'completed'; | |
| value: T; |
| class Component { | |
| constructor(o) { | |
| this.components = {}; | |
| this.listeners = {}; | |
| } | |
| init(o) { | |
| } |
| # https://github.com/mhenrixon/sidekiq-unique-jobs/issues/161 | |
| # Even worse: https://github.com/mhenrixon/sidekiq-unique-jobs/issues/234 | |
| class SidekiqUniqueJobsHashCompactor | |
| include Sidekiq::Worker | |
| sidekiq_options queue: "slow" | |
| def perform | |
| # Skip if there are jobs queued... | |
| return unless Sidekiq::Queue.all.select { |q| q.size > 100 }.blank? |
Similar to mpipe, this short module lets you string together tasks so that they are executed in parallel.
The difference is that it lets you use generators, functions which yield results instead of returning them. Each yielded item gets passed to the next stage.
You can specify that one or more copies of the workers operate on the input queue.
| #!/bin/sh | |
| # This pre-commit hook will prompt for every file that contains a `console.log`, `debugger` | |
| # or `puts` statement. This should avoid stupidly commiting debugging information :) | |
| exec < /dev/tty | |
| confirm() { | |
| echo "${1:-Are you sure? [y/N]}" | |
| read -r response |
| function mapValues(obj, fn) { | |
| return Object.keys(obj).reduce((result, key) => { | |
| result[key] = fn(obj[key], key); | |
| return result; | |
| }, {}); | |
| } | |
| function pick(obj, fn) { | |
| return Object.keys(obj).reduce((result, key) => { | |
| if (fn(obj[key])) { |
| global | |
| pidfile /var/run/haproxy.pid | |
| log 127.0.0.1 local0 | |
| maxconn 4000 | |
| # set default parameters to the intermediate configuration | |
| # tune.ssl.default-dh-param 2048 | |
| # ssl-default-bind-ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA | |
| defaults | |
| log global |
OK, you can pretty much ignore what I wrote below this update, because it doesn't really apply anymore.
I wrote this over a year ago, and at the time I had spent a couple of weeks trying to get Kafka 0.8 working with .NET and then Node.js with much frustration and very little success. I was rather angry. It keeps getting linked, though, and just popped up on Hacker News, so here's sort of an update, although I haven't used Kafka at all this year so I don't really have any new information.
In the end, we managed to get things working with a Node.js client, although we continued to have problems, both with our code and with managing a Kafka/Zookeeper cluster generally. What made it worse was that I did not then, and do not now, believe that Kafka was the correct solution for that particular problem at that particular company. What they were trying to achieve could have been done more simply with any number of other messaging systems, with a subscriber reading messages off and writing
Hi Nicholas,
I saw you tweet about JSX yesterday. It seemed like the discussion devolved pretty quickly but I wanted to share our experience over the last year. I understand your concerns. I've made similar remarks about JSX. When we started using it Planning Center, I led the charge to write React without it. I don't imagine I'd have much to say that you haven't considered but, if it's helpful, here's a pattern that changed my opinion:
The idea that "React is the V in MVC" is disingenuous. It's a good pitch but, for many of us, it feels like in invitation to repeat our history of coupled views. In practice, React is the V and the C. Dan Abramov describes the division as Smart and Dumb Components. At our office, we call them stateless and container components (view-controllers if we're Flux). The idea is pretty simple: components can't
| import Ember from 'ember'; | |
| /** | |
| * Presents a mutable interface to an immutable array. | |
| * | |
| * As you make changes to the array, it tracks which objects are new, | |
| * which objects have been removed, and which objects were in the | |
| * original array. To use an instance of this class, set the | |
| * `original` property to an array. This array will not be touched as | |
| * you make changes via the mutable interface. E.g. |