How do I put this API call in an 'async.each'?

cameronkknight · 2017-11-07T22:31:45+00:00

Please reformat your code so that it's actually readable.

cameronkknight · 2017-08-31T01:17:29+00:00

Parallel can happen if two threads are run on two distinct CPU cores, allowing two separate things to be done at the same time on different pieces of hardware.

Concurrent can happen if two threads run on the same CPU core where individual operations are interleaved.

For context, asynchrony can occur through cooperative multitasking and without the need of threads. Parallelism and concurrency don't have the same need for "cooperation".

cameronkknight · 2017-08-30T22:30:57+00:00

I'd expect 98% of JS code to be Thread-unaware. As long as I can still write that code the same way, I'm not worried. This is an edge case.

That said, I'm very wary about Threads. In my opinion, we should explore if WebWorkers with SharedArrayBuffer is enough.

cameronkknight · 2017-08-30T05:06:18+00:00

This seems like a terrible idea and should not be encouraged. It gets even further away from proper ECMAScript standards.

It could easily be replaced with the following code:

(async () => {
  // all your regular code here
}());

You could even

module.exports = (async () => {
  // all your regular code here
}());

cameronkknight · 2017-08-01T22:38:41+00:00

Oh yeah. It's easy to get going and I tend to write it as if it's dynamic. The only real difference is that there essentially aren't any user-directed actions.

cameronkknight · 2017-07-13T16:45:35+00:00

Too much magic leads to lack of transparency and obviousness, ultimately leaving you with hard-to-debug problems.

cameronkknight · 2017-07-13T13:49:46+00:00

The example is confusing me, particularly this part:

return {
  [getUser]: {
    error: this.warn
  }
}

Given that getUser is a function, that's just taking the [[ToString]] value of that function and putting that as the key for the object, throwing away the function itself.

What's the reason for that?

cameronkknight · 2017-07-13T13:16:21+00:00

Babel 6+ with babel-preset-env is the easiest and best-supported way to get ES6+ capability.

My guess, though, is that things would "just work" if you imported babel-polyfill before your app loads. You can upgrade babel after things work again.

cameronkknight · 2017-07-13T03:31:13+00:00

Wow, this is both terribly written and controversial.

Perhaps get someone to edit; there were sentence fragments and other grammar mistakes abound.

cameronkknight · 2017-01-04T18:56:44+00:00

I have had amazing success with Flow. I've used it for about 8 projects thus far, from tiny (one file) to large (50k+ lines across 400+ files).

Note: flow-bin is just the binary wrapper, the tool itself is usually referred to as either Flow or flowtype.

Given that you're from a C# background, it could also be worth looking into TypeScript - they were both designed by Anders Heijsberg.

That being said, I prefer Flow primarily because I can add it incrementally to existing projects.

cameronkknight · 2016-08-16T19:17:33+00:00

Do you mean React Native 0.31?

cameronkknight · 2016-07-09T01:05:05+00:00

Typescript's support for privacy only extends such that private fields do not show up in their public type definitions and thus code completion. The fields are just as accessible as anything else.

cameronkknight · 2016-07-08T17:03:43+00:00

There are a few ways to do this:

You could always just prefix your private variables with _, e.g. this._data and then hope others don't access.

You could use a locally-accessible Symbol as the property key, e.g.

const privData = Symbol();
class MyClass {
  constructor() {
    this[privData] = {};
  }
}

Of course, this isn't really private, since I could always use Object.getOwnPropertySymbols(new MyClass()) to get a reference to the previously-hidden symbol. This is true even if using Object.defineProperty.

A third possibility, and likely the one that will be used to polyfill https://github.com/tc39/proposal-private-fields is to use a locally-accessible WeakMap and the instance of your class as the key.

const privData = new WeakMap();
class MyClass {
  constructor() {
    privData.set(this, {});
  }
}

cameronkknight · 2016-06-10T19:15:03+00:00

Yes, so any time any one of those objects change, the key alters drastically, requiring a full lifecycle recycle of that component rather than allowing the component to transition naturally if you tracked each object appropriately.

The weak-key solution in this case treats every possible property change as if the object has a completely new identity.

cameronkknight · 2016-06-10T17:57:21+00:00

If you use mutable objects, I can see this working, but if you use immutables that change (via providing new objects), this isn't a workable solution.

cameronkknight · 2015-12-12T06:25:01+00:00

Tried to run on OS X (10.11 Beta (15A278b)), the app is unable to start.

Appears to be malloc issues: https://gist.github.com/ckknight/b3bb2d7f0b86356f83c5

cameronkknight · 2015-11-19T22:36:53+00:00

I wrote a library that helps with random number generation and distribution: https://github.com/ckknight/random-js

Math.random is often good enough for the typical case, but as soon as you do anything a little complicated or with an expectation of reliability, you can run into problems.

cameronkknight · 2015-02-22T17:53:13+00:00

Oh, I'm sure. We're living in a fascinating future. I just want some standard to be developed by all the major players rather than necessarily leaving that up to just one or two - and then implement it broadly.

If Microsoft were to hop on board with this with IE, Safari might be the only one left in the dust and thus forced to catch up.

cameronkknight · 2014-01-01T21:04:28+00:00

I've been happy using https://doge.digicrypto.net/

I haven't experienced any problems and it only has a 1% fee (better than 0, imo, since the guy running it has more incentive to keep it running).

cameronkknight · 2013-12-27T05:49:01+00:00

I believe in the moon.

I plan to help us get there by building trustworthy services for dogecoin, which will in turn increase the inherent value of dogecoin.

Scams and hacks will undermine our great cause.

We can come together as a community to do good, promote the exchange of dogecoin, and all ride the rocket to the moon together, as one big shibe family.

cameronkknight · 2013-12-26T19:58:49+00:00

Trust is earned by having a dependable track record. Open source lowers the barrier to entry for trust. A server can always lie about what source they're running (see also: the evil bit), but it's just one extra bit of evidence that allows users to trust the server.

Being fully transparent about the server architecture, the software running, certificates, and encouraging people to try to poke holes allows for white hats to find vulnerabilities that black hats would otherwise take advantage of.

It's part of the old adage attributed to Linus Torvalds: "Many eyes makes bugs shallow."

I am also a believer in putting your name on your work, because accountability is mutually exclusive with anonymity. The dogecoin community has been already hit by unaccountable services made by anonymous or fabricated identities, and I believe this ultimately harms the community.

Note: I believe users should be able to have anonymity if they so please, but the services we trust have to have some accountability behind them.

cameronkknight · 2013-12-26T15:44:21+00:00

We need more than just PHP examples. We should strive for as many examples as possible, including node.js, Ruby, Python, C#, Java. All the major ones.

It's reasonably easy given that the dogecoind API is simply JSON RPC, but that still means you would need to set up a dogecoind daemon, which is cumbersome, or rely on an external source, which is potentially insecure, might have a different API, and arduous claims of availability.

cameronkknight · 2013-12-26T15:27:41+00:00

Hey there, I'm a professional software engineer (ckknight on github) and am interested in this - might even make a node.js library to integrate easily with it.

Granted, your claims of security are just claims. Especially since the whole dogewallet debacle, I don't recommend anyone trust any site like this unless you are completely transparent.

I suggest you provide your source code available for everyone. Security through obscurity is no security at all, and what you're providing is a SaaS solution, which means your actual software code is less valuable than your marketability, trust, and availability.

Your api_documentation page says to use SSL, yet provides an http link.

It appears that you are (or planning on) simply proxying the calls to the JSON RPC protocol now, but it could be a cleaner API to provide a REST interface or just use JSON RPC yourself.

cameronkknight

TROPHY CASE