distracteddev90

Does this work well when set up to use my local machine and my personal credentials?

Not the original commenter but I manage a similar system:

1. Wait timings for jobs.

2. Run timings for jobs.

3. Timeout occurrences and stdout/stderr logs of those runs

4. Retry metrics, and if there is a retry limit, then metrics on jobs that were abandoned.

One thing that is easy to overlook is giving users the ability to define a specific “urgency” for their jobs which would allow for different alerting thresholds on things like running time or waiting.

Was affected by this, and so far, windscribe is a far superior service.

The transition was seamless.

Just signed up and this is almost exactly what I've been looking for.

The Github repo mentions a REST api that can be used to push arbitrary data into the system. Are there any docs around this yet?

There is no reason to feel alone, perhaps rare, but not alone. There are others that share your feelings (including myself).

These people are often labelled as the "pragmatic". They also lean towards having a more general scope of knowledge and thus often lack a "speciality".

There are also those that simply wish to solve the problem in the "best" way possible, and will use whichever stack gets them closer to that ideal solution.

disclaimer: purely based on my experience/opinion/perspective.

Turning off javascript also removes most paywalls, even the ones that have started protecting against direct links from search results.

I believe this is symptomatic of an industry moving away from job board based recruiting. There has been a significant change in the recruiting sphere and many talent teams are starting to focus more on sourcing and pursuing passive candidates.

This is the exact situation I'm in and I'm on my 3rd TN. Get a good lawyer and this shouldn't be a problem.

If you do get this visa though, be very careful what you say to the border guards. You need to ensure that when speaking about your work, you always frame it as "work in support of scientific research/innovation".

The main premise in my comment is that the benchmarks do not resemble real world performance, and are therefore misleading.

The comment above (https://news.ycombinator.com/item?id=11626762) further expands on why these kinds of benchmarks, although interesting, have no real value.

Each implementation does something wildly different and responds to different inputs with completely different outputs.

To put it metaphorically, if you put a car engine in two completely different chassis and then race them on a track, you aren't gaining any real insight into relative performance of the engine in the two vehicles.

Also, just to be clear, my qualms are with the benchmarks alone, I think the library is great! Thanks for all the hard work :)

The benchmarks for node.js are terribly misleading. The node.js implementations only ever spawn a single process, and thus node is only running on a single core and uses only a single thread.

Specifically, the http server example(1), doesn't even bother using the standard library provided Cluster module(2). Cluster is specifically designed for distributing server workloads across multiple cores.

All node.js services/applications I've worked on in the past 3 years (that are concerned with scale) utilize a multi-process node architecture.

The current benchmark can only claim that a single python process that spawns multiple threads is 2x faster than a single node.js process that spawns only one thread.

This fact may be interesting to some, but is irrelevant to real world performance.

[1]: https://github.com/MagicStack/vmbench/blob/master/servers/no...

[2]: https://nodejs.org/api/cluster.html

One thing I find interesting is that everyone loves to hate CoffeeScript, but its individual features/syntax are consistently lauded in conversations about other languages.

(Not to mention half of ES6 existed in CoffeeScript first, but that's a gripe for another day)

Docker doesn't force you to put your app and your db on the same image. That is up to you. Most have "App" images and "DB" images separate.

If we want to get really specific, Its also common to see the "DB" image split up between the image of the disk where the data is actually persisted, and the image of the actual DB process. This makes it easy to play around with your data under different versions of your DB.

Hrmmmm good point. Not one that applies to me particularly since if I'm on a server then I'm usually only running pre-written .sh scripts.

(edit: this was a reply to the post below.. not sure how I messed that up.. gah.. such a noob)

Would you mind expanding on what fish does out-of-the-box that prezto neglects or hides behind configuration? I am in a similar boat as you and was just wondering what I had to look forward to as a prezto user.

I can clearly see the difference between Fish and regular ol' bash, but struggling to see what value Fish adds above prezto/zsh. Could anyone help me out here?

Agreed. Something like this but based on RethinkDB or FaunaDB would be nice to see. Also if you chose to leverage these newer databases, you could leverage their in-built PUB-SUB support instead of having to using long-polling or placing socket.io/redis ontop of the REST API.

http://rethinkdb.com/docs/publish-subscribe/javascript/

https://faunadb.com/

True, but once you start adding middleware for business logic that conditionally runs for different routes, you end up with requests that get routed in a very non-linear fashion.

My experience regarding building route logic into middleware is that it starts to break down as you add more complicated logic (Real-time support, webhooks, integration with a taskqueue, etc). This is mainly because the middleware pattern works best when it performs an atomic piece of common logic for a large number of routes.

However, when you start using middleware and binding it to a specific route, for a specific collection, you quickly end up with a situation where for any given route, you can no longer look at a single function and parse the flow of logic.

Also, I find these libraries deceptively simple. They may be great for your private weekend blog, but fail to address the major pain points of API implementation in a production setting:

    - Configurable and flexible access control on a per-document basis. 

    - Rate limiting API requests

    - Mutli-node deployments

    - Proper, semantic, backwards-compatible API versioning

    - Realtime support (Websockets, browserchannel, long-polling, w/e you prefer)

Now I'm not saying your library needs to cover all of these pain points, but I challenge you to address all of them using a middleware-based architecture while still maintaining your sanity :)

Just my2c. The project looks great and hope you keep going with it and that I've provided some helpful feedback.

Cheers!

how is this different from https://github.com/wprl/baucis?

Also, whenever I've tried to use something like this for an actual product I end up quickly outgrowing the simple CRUD model since you usually need to implement additional features ontop of the CRUD logic.

Actually would argue that Promises are less composable since you're forced to use whatever control flow paradigm the Promise library has provided or add another library to handle control flow.

By utilizing callbacks, you are free to use Async.js[0] or Step.js[1] to solve the problem you described. These libraries are great since they give you control over parallel vs series execution of the pre-requisite functions as well as solving more complex control-flow problems such as throttling, etc[2] (See link for more examples).

[0] https://github.com/caolan/async

[1] https://github.com/creationix/step

[2] https://github.com/caolan/async#control-flow

edit: Yes, you can also use similar control-flow libraries with Promises (that follow the specification) to achieve similar results but then the argument for using promises for the sake of control-flow breaks down.

I believe Sequelize does this:

https://sequelize.readthedocs.org/en/latest/docs/migrations/

Both callbacks and promises are fairly simple interfaces for calling a function after some other function has completed.

Both interfaces can be abused to give you an ever growing indent and give the appearance of "callback hell"

Both interfaces can be use elegantly to help you reason about your code, make it easy to follow, and handle errors centrally.

Only one is supported natively by node.js and is the standard async interface for 90% of node.js's libraries: Callbacks.

Also, regarding "callback hell", a straw-man argument against callbacks, I highly suggest reading http://callbackhell.com/

Any chance Rdb plans to support a traditional callback style interface for those of us that prefer to stay away from promises?

Mongo is great for when you're rapidly developing a product and/or still operating at a small-medium scale.

Once you start to really scale, you'll start to find a couple parts of MongoDB break-down:

1. MongoDB has no concept of transactions and is not ACID compliant. These short-comings seem innocuous enough at first, but you end up with some crazy potential race conditions that you just end up praying you never face.

2. Distributed MongoDB layers are difficult to implement as well as maintain.

3. MongoDB Replica sets are unpredictable and unreliable in the speed at which they are able to stay up to date and require changes to your code to fully utilize (since you need to ensure you are always reading from a replica when you can, but only ever writing to the master MongoDB instance)

4. At scale, MongoDB will consistently perform worse than Postgres for CRUD-based operations

5. Do you have true relations between documents? Do you ever use Mongoose's convenient `populate()` functionality? If so, you are now making multiple db queries in series when trying to fetch a document(s) from a single collection. This starts to really hurt your query times once you get enough documents/relations in your mongo collections.

I'm sure I'm missing some, but these are some of the areas where MongoDB has fallen down for me in the past.

Feedback:

- The lack of an option to search only vegetarian recipes makes this pretty much useless for me.

- Adding ingredients has a fairly large delay. I suspect some optimizations could be done there.

This looks amazing, and the StrongLoop team is chalked full of some great Node.js developers.

But for some reason I'm still worried about using it as the backbone for an enterprise scale application; it almost does too much. Perhaps I'm just too averse to this amount of "magic" in any piece of infrastructure due to my Django days.

The code is open, but you're not just buying into a single module with a single purpose -- this is an entire architecture. I guess in such cases, worry is warranted before accepted it as the backbone of your company/application.

Is it just me or is this overly complex for what amounts to declaring an EventEmitter, requiring it where needed, and proxying dom events to that EventEmitter?

12-year leases?!?! Please tell me that is a typo and you meant months.

I am a renter as well but we have pretty strict rental agreement regarding these kinds of things. The owner is not even allowed to enter the property without my prior permission or a certain amount of notice.

When you are paying for someone else's house, please do not be afraid to protect yourself with a proper, binding rental-agreement/contract.

Edit: I live in Canada incase that makes a difference.

I don't get this?

Do you need a certain amount of points before you can flag something? I can't seem to find the link anywhere.