Prefinem

How can apple justify $1000 for a stand?

You should play it while you can. It's a very fun game and the PVE server is some of the best relaxing gameplay I have experienced (as long as falling into an abyss doesn't stress you out)

SpatialOS is doing much more than that. It's main goal was bringing a single world spread over multiple server instances instead of individual servers.

It's like atlas vs ark, not like unreal vs unity

If you are writing a reviver, what difference is it to instead write a deep clone function?

JSON.parse(JSON.stringify(obj)) !== deepClone(obj)

EDIT: Also, how can you determine if the string should be a date, or a string? Sure, if it fits, you can always convert it to a Date, but if your first object is coming from something that sends ISO Dates as strings and you used JSON.parse with a reviver, you would get a different object.

Piping is relatively easy to write a function for. Here [0] is a package that I wrote that has a few trivial functions (including pipe) for things such as this.

0: https://www.npmjs.com/package/afpf

Not OP, but where I work, we have a hybrid approach for our system.

> Share code between your SPAs, for example, utilities?

We alias a common folder for our utils with webpack which allows all our code to use the same utilities. We actually have two. One for shared frontend and backend, and one for just shared frontend

> What if your SPAs have large dependencies (React, Vue), should every SPA come with their own?

Webpack code splitting is how we split our apps. We also build into multiple bundles to keep bundle size small. That does mean that React does get bundled with each, but if you split thing appropriately, you can potentially save off a few MB with caching each bundle from page to page.

> Should every SPA have its own build tools?

With webpack, you can build all your bundles with one config / command

> What if there's an update to a library, should it be allowed that one SPA runs on an older library?

We have a root package.json for all of our react apps. This means that we don't update a library unless we can update it across the board. It takes more time to test upgrades, but it also means smaller bundles, easier package management and easier maintenance in the long run.

I will be honest, I was completely unaware of your other products, not that I would be your target audience. That being said, thank you for not pushing your other products on tracker users. That was something that always annoyed me with Atlassian.

Oh wow. So yeah, I guess we call it pivotal so much at work that I didn’t even realize it was actually called Pivotal Tracker.

It’s a great product. The speed and ease of use is amazing.

Tracker?

Not parent, but we replaced Atlassian with Github and Pivotal

Thanks. It's been through a few revisions and really needs to be reworked for mobile. If you have any input, I would be more than willing to hear it.

Shameless plug, I made one that uses an AWS Lambda and S3 and encrypts everything before it gets sent over the wire. You can view a live version of it here (https://todos.md/) or view the source here (https://github.com/Prefinem/TODOS.md)

EDIT: grammar hurts

Just saying they didn't do nothing. Maybe they didn't do as well as they could have, but they did do something.

NPM revoked all tokens. How is that irresponsible?

https://status.npmjs.org/incidents/dn7c1fgrr7ng

I used it so much in my text editor, I ended up creating a site that did the same thing but kept things synced

https://todos.md/

I was in the same boat waiting excitedly the whole time.

> A Deferred object is returned by the obsolete Promise.defer() method to provide a new promise along with methods to change its state.

> Starting from Gecko 30, this object is obsolete and should not be used anymore. Use the new Promise() constructor instead (or use the above backwards/forwards compatible Deferred function given below). For example, the equivalent of

Seems like it's obsolete. [0]

If you want to write async code, use async / await.

    const run = async () => {
        const response = await new Promise((resolve, reject) => methodOne(data, (e, res) => e ? reject(e) : resolve(res)));
    };

If you spend enough time with fat arrow, it's as easy to read as `function` is. On top of that, IMO it looks cleaner. It also allows you to do scope binding in a different manor which in React is much better.

This:

    <a onClick={this.onClickEvent.bind(this)}>Click Me</a>

becomes this:

    <a onClick={(event) => this.onClickEvent(event)}>Click Me</a>

[0] https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_...

Life is more fun with fat arrows sometimes

    new Promise(function (resolve, reject) {
        methodOne(data, function (error, response) {
            if (erorr) {
                reject(error);
            } else {
                resolve(response);
            }
        })
    })

vs

    new Promise((resolve, reject) => methodOne(data, (error, response) => error ? reject(error) : resolve(response)));

Not OP, but thanks for the link to that app. It's quite amazing.

I am also interested in knowing. Seeing as it's been a business and had a trademark, I would assume 6 figures, but I honestly have no clue.

Wes Bos has some good courses that takes you up through ES6 which will be pretty close to the latest node version

Awesome, thanks for this!

The irony is that sublime text doesn’t slog down

The linter was the issue.

I actually have better performance with Sublime Text and JavaScript than I do with vim and JavaScript. I wish that weren’t the case.

If you know if any better ways to get vim working with Syntastic for linting (eslint), I would love to know.

Not sure, but I have had vim lock up my MacBook Pro with 16GB of RAM and force me to do a hard reboot

Yup yup, I went down that path and converted our then very basic deployment process to use serverless and instantly hit hard limits.

We don't use cloudformation because honestly, it sucks. It's hard limits are a pain in the ass to get around (with 150 lambda functions, we need hundreds of resources, so that means nested stacks, which just suck) and it managing the api gateway just doesn't do what we want.

We have a custom script to deploy our own API Gateway using the AWS SDK and we generate a swagger file from simple json config files.

For the API Gateway issues, so far, we have a few things that are something we have to watch out for.

- All lambda endpoints through APIG are lambda proxy type. This means we can have a framework handle standard request / response stuff. The downside is that we can't support binary endpoints easily because they haven't fixed that issue yet.

- HTTP proxy pass through endpoints have to be added to the swagger somehow before we deploy. This is a little annoying, but not a huge issue

- Merge vs Override for deployments. We merge in beta, and override in other environments. This allows us to keep endpoints exactly as they are, but allow flexible testing in beta

1 APIG for 1 micro service isn't great IMO at scale since we run all our endpoints under on domain and mapping all of them would be a pain.

Yes, we have all of our functions in a single mono repo, broken into projects, and then folders for each function, similar to this:

- src/project1/function1/

- src/project1/function2/

- src/project2/function1/

- src/project3/function1/

- src/project3/function2/

- src/project3/function3/

Deploying the functions is done by project, so we deploy all of one project, then move to the next, and so on and so forth.

We follow a very similar pattern and we are at over 150 micro services right now (AWS Lambda).

A couple of things different that we do since we are building and then deploying to AWS:

- Build only on dedicated deployment branches (beta, qa, preview, prod)

- Build all functions (transpile, yarn, lint, etc) on every merge into the branch, but only deploy functions with different checksums (saves on api calls to AWS)

- We cache node_modules, but otherwise don't have any special build requirements and babel takes care of targeting node6.10 for Lambda

Total build time is between 8-13 minutes. There are some things we can do to speed up install that we haven't yet because it's not an issue yet but just a short list of things to note.

- Each function has it's own package.json for it's own packages. We maintain a list of npm packages that we download into a single folder first (that doesn't get deployed) to allow yarn to use those files from cache. We will eventually switch to an offline install for each function which essentially just copies the package folder and sets up anything it needs.

- We have a tarball package that includes all of our shared code / config files. Yarn seems to always want to download this file, regardless if we pre-download it.

- We deploy a single api endpoint for all of our micro services through API Gateway which cuts down on the time to deploy since API Gateway has a pretty hard throttle. This means we create a deployment on API Gateway every merge. We have one APIG for each environment

You probably shouldn't be putting your Lambda Functions in a VPC unless it needs access to a VPC resource. There was a pretty good presentation on that in the "What's new in Serverless" seminar.

On top of that, I believe you can do a /2 CIDR which gives you over a million IPs to use. Not sure why you think that wouldn't be enough.