skyraider

I like the attention to detail this feature reveals - in particular, how if you're in Stripe test mode in browser tab X and type `stripe login`, the cli will open a page in browser tab Y that gives you a test mode webhook secret, without prompting you to select a mode again. Very intuitive.

Nothing listed on AWS Personal Health Dashboard related to this incident. Also nothing abnormal listed on the AWS status page under S3, which is seemingly having DNS resolution issues for buckets with the `[bucket_name].s3.amazonaws.com` pattern.

Right, not unclear on that, just unclear on whether IKBR domiciles the accounts in such a way that you'd trigger filing requirements, and how to know this when using the platform.

How do you use Wealthfront if living abroad? Their FAQ states that they require a permanent US residential address.

Also unclear to me whether Interactive Brokers transparently moves funds to brokerage accounts domiciled in your new jurisdiction, triggering FATCA filing requirements, and if they do a good job of making these clear to customers.

I'm looking to move to Bodrum from NYC for many of these same reasons :-) Turkey has a lot of potential to be a remote work hub.

Even on decentralized networks like ethereum/bitcoin, it's possible for governments and companies to have a major impact on network direction. True economic decentralization is more likely to come from products like Stripe Atlas that give small players scaling and distribution tools that previously, only big corporations or well-resourced founding teams had access to.

Ethereum is providing a base layer protocol for apps that never go down, never fail, and are fully trusted.

Even if we were to grant that these claims are true, we still have to ask what classes of application benefit from slower, more expensive distributed systems. Blockchains solve only one problem, which is consensus formation on ontrusted networks. They do not solve politics, governance, downtime, and certainly not application failure.. these things all exist on blockchains.

Essentially none of the application ported from centralized systems to Ethereum or even Bitcoin actually face Byzantine consensus issues when deployed as centralized systems. Bitcoin can be used as a 24x7x365 global collateral and value transfer instrument - such a system would face consensus problems if implemented on top of traditional banking infrastructure. That's hugely valuable, but pretty much the only problem-solving application to date.

For things like asset ownership and transfer, any kind of voting, real estate, IPOs, etc, most people still have to deal with incredibly bad centralized systems, that would be amazing if rebuilt as centralized node.js apps that talk to a MySQL database. This stuff is low hanging fruit that's a huge pain for massive swathes of humanity. And despite the fact that no Palo Alto real estate broker is talking to the city's land deed system over unreliable networks, where enemy messengers might swoop in and assign your deed to the wrong buyer, there's this myth that we need distributed consensus for this and other problems best solved by... databases.

This is interesting when compared to Amazon Elastic Container Service because of Azure Container Service's support for native Docker clustering tools.

If I am developing user docker-compose, I want to deploy that way, too - at least until I reach scale, at which point I want scheduling and orchestration tools, e.g. Swarm.

For easier disaster recovery, it's very convenient if these scheduling/orchestration tools let you deploy in the same way cross-cloud-provider. Swarm can run on AWS/Azure/GCE/bare metal, whereas ECS (which doesn't support Swarm and has its own scheduling/orchestration toolset) can only run on ECS.

+1 to MS for thinking about native tooling up-front.

It's not US-only.

Not rushing to judgement, but consider looking into your email deliverability. Google's spam filters aren't perfect; resumes from domains with misconfigured deliverability settings do get flagged.

I don't know what you mean exactly. Do you mean you want to test the code that will result after the merge instead of the commit in the feature branch? It would be a nice option to test the merge of the feature branch with master instead of the feature branch itself (you will have to retest all MR’s every time master is updated). BTW The new build trigger API (to be released in a month) is one of the upcoming features that will allow more build customisation.

No, I want to trigger additional types of tests under two circumstances:

- When a merge request is created

- When additional commits are added to a branch for which a merge request exists

The utility is: I don't want to run integration tests if someone is just pushing to a feature branch - that takes up worker time. But I do want to run integration tests before that feature branch gets merged upstream. Achieving this by having everyone submit merge requests to an intermediate branch doesn't work, because we don't know the integration test result until after the merge to the intermediate branch is done, meaning developers might be trying to push a bunch of failing code to the same branch, just to get integration tests to run.

Super.. good to hear! Ideally the community can get a little more involved in design/UX too. I'm not sure if GitLab plans to set the tone there first - perhaps that's also on the roadmap.

Would Roboto work, for instance?

Maybe the typeface isn't so much the issue as the layout? On the issue view, comments and descriptions have different positioning and styling. Also, important information lives above the issue title, which is unexpected.

Being unable to trigger CI builds based on merge requests (which can dispatch a build for a commit ID, but you've probably already pushed that commit) is probably the most problematic for us at the moment.

Maybe it would be cool if GitLab came up with some basic design principles/goals and accepted contributions toward that end. I know we'd be interested in contributions here and there to improve workflow/UX.

GitLab Enterprise user here. GitLab's open-source policy is one of the major reasons we chose it (along with self-hosting and fairly modern, built-in continuous integration), but the GitLab community could use some additional design and documentation effort.

Things that almost make me want to switch back to GitHub:

- GitLab is really hard to look at. All of our devs are having trouble visually locating comments in diffs. We're always scrolling through the left-side menu looking for the issues tab. It's hard to visually differentiate between items like comments in merge requests. Our eyes just can't find and follow things. Even BitBucket looks better.

- GitLab-CI has poor documentation on runners, and a rather buggy test runner registration process that doesn't provide any debugging output and produces false positives quite often.

- GitLab-CI has no unconditional cleanup directive, like CircleCI does... but if you're re-using a test runner instead of tearing down the server each time, unconditional cleanup is the one thing you need. And no, the Docker executor doesn't solve this because we don't want to test our Docker containers inside Docker.

- CI is based on commit IDs. You can't run particular CI events on merge requests. For example, this means no way to run integration tests on merge requests.

- Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.

- Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.

If the community/GitLab can focus on putting on some of the design polish and service integration polish that GitHub has, GitLab would be a total winner for us, long-term.

LedgerX - New York, NY (Manhattan). Local or remote.

We are building regulated bitcoin infrastructure for Wall Street, which will be launched once our application to the CFTC has been approved. We have built a bitcoin options exchange and clearinghouse platform, which, upon approval, will give U.S. financial institutions a legal and regulated way to access promising bitcoin technology, as well as bitcoin derivatives.

Our backend technology is based on Python, C++ and ZeroMQ. We are looking for software engineers.

Send email to zach@ledgerx.com.

LedgerX - New York, NY (Manhattan). Local or remote.

Join us to build a US-based exchange for virtual currency derivatives.

We have a Python, ZeroMQ and C++-based backend. We are looking for a software engineer who can build out features all the way to our React.js frontend.

Please email zach@ledgerx.com.

Well, OP is saying that fallacies in logic are really only fallacies if the assumptions that constitute the definition of that fallacy actually apply to a particular situation. Because situations differ so much, context is critical, and OP is saying that people often incorrectly define real-world social situations as instances of logical fallacies.

Yes, and the ironic thing is that the 'well-actually' person is often /less/ correct in that they miss the main point in pursuit of compliance with arbitrary rules.

Being pedantic is akin to writing beautiful code that never gets used.

To be more specific - the notion that it's a courtesy is mistaken. It's considered rude at best, and the general public may (rightly) interpret a well-actually as a mark of low social or emotional intelligence.

So, we must carefully consider what really signals intelligence.

Linguistic errors pale in comparison to errors of understanding like missing the point.

I think the OP used 'logical fallacy' ironically.

But maybe not: Consider this. Many, many formal systems describe behavior and not some underlying truth. The question of whether reality can even be reduced to a formal system is still open.

From the above axioms, we can reasonably conclude that what formal systems prove is provably true only insofar as the axioms reflect underlying reality exactly.

In 'social' formal systems like the one that describes logical fallacies, it is clear that context is inherently lacking, that the axioms are approximations, and that the system cannot be expected to accurately describe reality.

Thus, we can formally conclude that logical fallacies are, well, approximations.

I know you're doing it in jest, but it's interesting how often the tendency to 'well-actually' minor, irrelevant factoids and the tendency to reduce conversations to axiomatic systems appear together. It's part of the hacker desire to be Less Wrong (TM).

But in doing so, they are More Wrong (TM). Both situations involve missed social cues. Correcting a minor point is another way of saying you place a higher priority on correctness for its own sake - even if doing so prevents you from reaching higher goals - than you do on understanding.

These things can make it hard to for non-hackers to converse with hackers, and vice versa.

Of course, in the theory, there aren't price controls (because one of the fundamental lessons of economics is that price controls cause shortages).

And in reality, there are lots of price controls on generics. That's not a bug with the theory; drug production is only a partially free market at best.

Yes, this is what happens when justice gets politicized by populist fury. It's extremely scary.

Everyone here seems really eager to take the DOJ at face value. Wow. Quite a reversal.

In order to get anywhere, the DOJ has to charge HSBC with willful violations. So of course the government alleges that the violations were willful. Everyone here seems perfectly willing to accept those accusations, and every allegation in the DPA, regardless of the level of evidence presented in court.

The knee-jerk reaction here seems to be that if someone running a corporation is alleged to have a subpar compliance program, it's all part of a giant willful conspiracy.

This DPA raises the interesting question of what constitutes sufficient AML/KYC compliance. Fine. It looks like HSBC had a subpar program, which is illegal, even though there aren't precisely defined standards for AML/KYC in terms of what's adequate at scale. But people here are still really eager to criminally prosecute people for failing to prevent money laundering.

This is hugely different from knowingly helping drug cartels, which is what HSBC is being accused of in the media.

Sure. Another way to interpret "JavaScript" is that it means using one of the various data-binding frameworks. But who knows, I didn't write the article.

Probably talking about JSON and similar formats like JSON API.

The graph shows old techs that currently serve as more-or-less substitute goods for REST. He's saying the four items listed below have a much smaller or even tiny but, as of recently, nonzero following.

In context, the graph is intended to show the dominance of REST over time and not how it's losing out to any of the other items.

I would add that if you think it's not so hard to imagine, maybe share your imaginations with others. Simply asserting it's easy to imagine hasn't worked out well for science in terms of communicating its findings to the public. There are still lots of people who find that imagining hard - it's a psychological barrier to accepting evolution for many people.

Right. My point is that the evidence is there but there's a difficulty in developing or accepting an intuition for evolution given the huge timescales involved in unicellular-to-human evolution, even though it's well-supported by inductive and deductive evidence.

Not to go all [0][1][2][3] on one word in your thoughtful comment, but for me, it is always worthwhile to ponder the fact that the theory of evolution is not about chance per se.

You take the intelligent-design approach - pattern recognition on designed things. I hear you. But what about the compelling inductive evidence we have that deterministic, if chaotic, natural systems are perfectly capable of establishing a feedback loop and modifying themselves?

IMHO, accepting evolution is all about wrapping one's head around the notion that the result of this modification, when stretched over unimaginably large timescales, is significant change.