shtylman

Can you hoist the `if (result)` into the `try` part of the statement? (Without seeing more context hard to know why that wouldn't work for you).

Another pattern to avoid the above is to remember that async functions return promises and that .catch() also returns a promise. So your above logic can be written as:

  const result = await funcThatReturnSomeType().catch(doSomethingWithErr);
  if (result) {
    doSomething(result);
  }

Personally I find SQL much easier to read. In a product where you might allow users to write queries it is a much more pleasant UX experience to write and read SQL than it would be to do so for ES queries. It isn't a problem to understand how to build an ES query object but an ES query object is pretty terrible to read IMO.

It is none of their business why I needed my money or how many trips it took.

the future is now

Duplicate dependencies affecting client side "size" is highly overrated. We can make tools (and have tools) that can compare files for same content and only include them in client side bundles only once. De-duplicating the same could should be a tooling issue. If I want to use client side modules that depend on two different versions of the same library I should be able to do this. Disk space is cheap and we can do the rest via post processing.

Systems where people seem to live under the assumption that if they don't get the latest patch updates or security updates their code will somehow be inferior and they will instantly be hacked. They think that semver will magically solve the problems of having to keep your application dependencies up to date if you want the latest changes/features/fixes.

Pinning in development is equally necessary if you hope to bring sanity to your development team all using the same codebase. Not pinning may be great for a one person 'team' or modules where you control everything, but can be a major time sink when one person is seeing a bug in a patch version they have and another developer is not seeing the same bug because they are on a newer patch. Allowing developers to "clone" consistent versions of the codebase is as important as deploying consistent versions to production.

Why should they reconsider it? Someone that just got into development and might want to show their friends or family something they are hacking away on. According to you they now need to learn about VPS, some random nginx settings or other SSH nonsense and meet some arbitrary "minimal" criteria you have decided upon because that is how you would do it. I think you should reconsider your acceptance of people that don't share your same technological expertise.

To me the ease of having the library be installable with the "canonical" package manager of my platform is too convenient; just "feels" more natural and simpler. I actually thought about writing a node.js ngrok client but then gave up on the idea since localtunnel was working well enough and I personally didn't need the other features from ngrok which I didn't have in localtunnel.

I wouldn't worry about the whole rewrite in c thing. If your server protocol is simple enough, writing clients in the native languages will be better than writing bindings. Installing bindings trips up a lot of users that are not used to compiled software.

You can. See the README.

Author of the project here.

I want to clarify why this project exists (as many seem to point out that other projects or methods exist for doing this).

TL;DR; If you think of localtunnel as just a shitty ngrok (or name your project here), you are missing the point and probably don't have the same use cases I do.

1. It was made overnight at some hackathon because I was not satisfied with the other tunneling options I found. They required either an account or some stupid ssh setup. I got to thinking of ways to create a tunnel that simply had an CLI tool and instantly get a tunnel no setup. It worked, I kept it.

2. It is written as a library first, CLI tool second. This means it can be used to create tunnels in a test suite if you want to use services like saucelabs to run browser tests (see https://github.com/defunctzombie/zuul). This is leveraged by projects like socket.io and engine.io (among others). This is perhaps the main reason I keep it around despite there being alternative CLI tools.

3. Both the client and server code are availably and easy to install and use. Companies do this when they want to run their own tunnels for privacy (or whatever their reasons... I don't care).

4. Yes, I know the name is identical to the old ruby?python? one. Whatever. That one seems defunct now anyway.

The fix for this is to use a module. Simple. Not a problem.

The generator example has no error handling (at least not from what I can see).

Once the "callback hell" example was re-written with named functions, it is not much different than the generator example and depending on how you are testing, easier to test because it separates out IO from logic (Which you could still do in the generator example).

One thing callback style code has begun to make me think about is the nesting/IO complexity of the functions a I write. When you nest, the IO/event boundary is visible in the code (by the indentation). As you continue to nest, you can start to get a clear idea of the amount of IO being done and where a particular function may be doing too much. Anyhow, most of this is preference anyway :)

I'll get the medic.

As long as every jquery plugin and other code that depends on jquery continues to require all of jquery, all this module stuff is useless. I am sure it helps you organize jquery Dev but it still doesn't help actually define real dependencies on a per component basis.

Lots of those are for Sizzle.

jQuery would be great if it broke up all those tiny little and completely orthogonal things it does into modules so that people could use them as needed. No one library is going to provide everything for every project but making everyone require your ajax code when all they wanted was an `offset()` function is equally backwards thinking. We have much better tooling now to work with modules and to reuse code.

Arguments about CDN caching are some sort of premature optimization (or I don't know what really). Most early projects don't need it and other projects can trivially use many of the free (or super low cost) CDN providers if they care that much.

My issues with jQuery are not at how awesome it has worked in the past or how well it has hidden/handled lots of browser quirks; it is that thinking in terms of "everything is dom manipulation" is the wrong abstraction for doing organized and maintainable front-end code. The things jQuery does well would be useful within smaller components or libaries but now we are back to the original issue of jQuery is one giant blob.

This is a lie. The internet browser is way too good.

This is very unfortunate that they are doing this if the data was scraped and not hitting their servers. Is it that some part of the data they think is copyrighted (like grades) versus just courses?

I run a similar service for other schools (courseoff.com) and I have run into this before. I bet what happened was their site failed to cache the course data or seat information and was thus making lots of requests to the Yale servers. To Yale it might appear like a DoS from this site.

Obviously I don't know for sure but I would venture to bet this block was more an automated response than malicious intent against the site.

You don't have to trust anything. If you want to NIH everything yourself, nothing is stopping you. It is however more likely that many packages on NPM are better than the ones you or your team can create if simply for the fact that they may have been created by a person very versed in the particular domain the package is for. Or maybe it will be shit but whatever :)

IMO bug bounty payouts are a more effective use of funds for a project. Paying per commit is like paying per line of code. At least with a bug bounty you (the giver) can specify which particular item interests you. If you want to donate money to the project as a whole, then it seems easier to just communicate with the project owner/maintainer and send them funds directly.

Because writing plain javascript is simpler for the majority of people to understand and will run in more places without the need for custom setups. Module authors will not write to these custom implementations since it would greatly limit the audience for their module.

Lots of problems can be solved with one language depending on the language. And I have worked on several single language stack projects. Having a single language stack has many benefits. Right too for right job is only relevant if the right tool doesn't do many jobs good enough.

Don't be hatin' just cause you have never seen panic buying ;)

Ironically enough, due to check fraud that check might not help you as much as you think ;)

I don't know what algos they use to detect fraud but being a veteran does not always mean there won't be fraud on your bank account. Remember, this is not about those five 10 dollar transactions you authorized, this is about that one 5 thousand dollar one that was the result of fraud. From their point of view, a false positive is much better than a false negative.

The risk is not that your account will be debited, it is that you will go to your bank and claim the charge was not authorized by you after having moved the coins off their site. Now, maybe your bank account was compromised, and the attacker used your info to get coins. The bank will still refund you at the expense of coinbase. Remember, it isn't the "good" actors these actions are meant to protect against. A business like coinbase is a target 24/7 for many malicious individuals with access to lots and lots of compromised accounts.

What price would you then give the user?

Based on your username, I am going to assume you are referring to this lawsuit:

http://www.scribd.com/doc/139975904/Aaron-Greenspan-lawsuit

In which case you are the Plaintiff suing these companies which is very different than the US government suing them.

Yes, wires are much more difficult to reverse but they can be reversed. In my experience, your financial institution must get your prior approval before reversing a wire (which is not true for ACH reversals). Wires also you a completely different system of clearing funds which is part of the reason reversal requirements are different.

Coinbase uses a method called "ACH" to electronically request the money from your bank account. The problem with this method is that it is relatively easy for a fraudster to get the information needed to do this (routing and account number) and submit that as their account on coinbase. Consumer protection banking laws in the US are very consumer favorable and thus if someone goes to their bank and claims they did not authorize the transaction (of coinbase taking the money from your account) the funds will be returned to you and coinbase will take the hit. Now, typically this is less of an issue, but with bitcoin, coinbase is not able to take back any bitcoins they have let you withdraw. Thus you can see where this leaves them in a very delicate situation about having to monitor how and who they withdraw money from as well as the amounts.