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.
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.
People living abroad who are US citizens will often use an address they're associated with - parents or other close relatives. That's what I did for years. I think there are services you can use too.
In turn, I'm curious why he bothers with Wealth Front rather than just parking it all in a few Vanguard funds. That cash account looks pretty attractive, but other than that...?
I am a huge fan of Vanguard, but Vanguard Japan has strong compliance concerns about providing services to Americans and Vanguard US has strong compliance concerns about providing services to people living in Japan, so I cannot conveniently consume Vanguard services directly.
I think that's more an "Ask them" question than an "Ask me" question but single data point: neither my tax advisors nor myself felt a lack of clarity with respect to the treatment of their IBSJ and IBLLC accounts, a distinction they are (appropriately) pedantic about with respect to Japan.
Opening an IB account as a US citizen living in Germany resulted in the IB account being domiciled in the UK - NOT what I was going after, because they then could not allow me to buy non-EU ETFs. I've heard that it used to be different, and that's why I opened an account with them, but they've changed policies within the past year.
Pro-tip for other American taxpayers living abroad: do NOT buy non-US-domiciled ETFs or other funds; PFIC will eat up most of any gains.
Schwab is reasonably-equipped for serving the US citizen expat market.
Right, but it’s a nasty Catch-22 for US taxpayers, which is anyone with US citizenship. Can’t buy non-EU ETFs because PRIIPs, would be stupid to buy EU ETFs because PFIC.
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.
you do you but i'd highly recommend moving to a non-income tax state (and city) beforehand, alongside drivers license, cell phone bill in new place, etc. NYC and NYS tax authorities are getting more and more relentless as upper/middle class ppl leave the city, so you'll need serious documentation that you aren't just leaving and coming back soon if you want to avoid getting stuck still paying them.
Turkey is run by a near-dictator and is right next door to a country in the midst of a civil war; it certainly doesn't look like a safe place to move to.
Istanbul and Bodrum are probably safer than most US cities. Also, go search an google for yesterday's mayoral elections in Istanbul. A BIG step in the right direction.
> 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.
>>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
Nobody denies its slow, its a waste of resources, its buggy, its hyped. its a lot of things many early systems was. Its all challenges that people try to solve. What is interresting is if those things can be solved. And i dont understand Why so many dont see a benefit if we could one day build true decentralized systems... its not the distributed or avalibility thats important. Its not like goverments or companies always have the peoples best interrest when they make decissions.
> Nobody denies its slow, its a waste of resources, its buggy, its hyped
A lot of people deny all of that, actually.
> slow
They say "there is no faster way to achieve distributed consensus".
> waste
They say "it's not wasteful because its securing the network".
> buggy
They say "unlike all other software systems, it's never been hacked!".
> hyped
They say "it's literally the greatest innovation since the internet"
> And i dont understand Why so many dont see a benefit if we could one day build true decentralized systems
I have no idea, I guess most engineers are just too jealous of early adopters getting rich to be willing to give cryptocurrency a chance. There are so many problems that can be solved right now with cryptocurrency if the community would just give cryptocurrency a fair shot instead of always trying to say that it doesn't solve any real problems.
Note: the previous paragraph is a satirical portrayal of a cryptocurrency enthusiast attempting to explain why the entire software community isn't hyped about cryptocurrency.
Perhaps Im just a dreamer... but i believe in an open-source, decentralized, free information, patentless World... Where one day nobody can rewrite history, can force a monopoly down our throath, lock us in, be unaccoubtable for their actions, censor us or run us around like sheep. One day we stop shooting ourselves in the foot and pee our pants and stop being blind to the tech giants like they have our best interrest. A true decentralized system might be nesssary one day to avoid us being enslaved in democrazy
> Perhaps Im just a dreamer... but i believe in an open-source, decentralized, free information, patentless World... Where one day nobody can rewrite history, can force a monopoly down our throath, lock us in, be unaccoubtable for their actions, censor us or run us around like sheep
> open-source
Blockchain software is an amazing example of open-source software, but blockchain is ultimately unimportant with respect to the entire open-source movement as whole.
> decentralized
Blockchains are decentralized, but they can't "decentralize the world" because they don't exist in the world so they necessarily require outsourcing any real world effects to untrustworthy humans who do not have to respect the state of the blockchain in the material world.
> free information
Not sure what this even means, but whatever market incentives exist that might keep information from "being free" will always exist, regardless of blockchains.
> patentless
The patent system is a political institution that will exist regardless of blockchains.
> nobody can rewrite history
As has been demonstrated many times, blockchain history can be trivially rewritten given the appropriate political influence of those who control the nodes. The DAO is a classic example of that.
> force a monopoly down our throath
Blockchains do absolutely nothing to stop this.
> be unaccoubtable for their actions
Blockchains do absolutely nothing to stop this.
> censor us or run us around like sheep.
A government can effortlessly censor you and doesn't really care if are able to flip some bits in an arbitrary digital ledger.
> One day we stop shooting ourselves in the foot and pee our pants and stop being blind to the tech giants like they have our best interrest
The cryptocurrency community does not have our best interest at heart.
> A true decentralized system might be nesssary one day to avoid us being enslaved in democrazy
This is the height of cryptocurrency delusion. I regret that I have to sound so dismissive but I think the monumental assertions you're putting forward are fundamentally disconnected from history and our current reality.
What you Seem to ignore is that my aspiration is to fix the flaws and come up with a Better system and you Seem to focus on the past and currency Which is just a small part of the picture. Control of nodes is just a reference to some current implementation details. DAO was also just bugs exploited. Being able to alter the current State of the Ledger doesnt make it invisible that you did it, or prevents others from not agreeing with you.
Im thinking about civilations destroyed or Winners of war rewriting history, or powerfull companies and poltiticians covering up information that was already out there... eg recently we found out its easy to delete from waybackmachine. If you cannot Imagine we Can build true decentralized tamperproof systems or could ever have a neeed for one i suggest you study human history.
> "Im thinking about civilations destroyed or Winners of war rewriting history, or powerfull companies and poltiticians covering up information that was already out there... "
None of these are engineering or technical problems. They are all extremely complex meatspace-based problems that get solved (if they are even solvable at all, or even actual problems) well outside of the realm of computer code.
Bitcoin and Satoshi's Glorious Blockchain is, was, and always will be a solution in search of a problem.
Sorry i dont believe that. Its the only place it can ever get solved if at all. Putting trust in people has so far proved to be flawed.
Again had you made eg waybackmachine immutable then we hadent seen recent discussions about who Said What. Again look at eg bittorrent... how succesfull have copyright holders Been at preventing filesharing...
In regard to bitcoin it works pretty well for a lot of things and not so much for others. Just as everything. Personally it served me well.
And Having background in lottery abd payment industries i Can tell you we are already using it.. current systems are a terrible mess Which Anyone who ever had to implement against visa mastercard banks etc can tell you All about. Private blockchain ledgers like in the mentioned corporations is already in use and even more in the future.
> What you Seem to ignore is that my aspiration is to fix the flaws and come up with a Better system
Admirable goals but lots of us have aspirations. You need to demonstrate how your suggestions can actually help, and at this point, explaining it is not enough, you and your community need to stop talking about it and actually do something. No other software requires so much vocal defense.
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.
Sure goverments can affect etherum and bitcoin but they cant stop it globally and Im talking about the next generations build from the learnings of bitcoin and the likes. Its not just about money but information any kind that could benefit. Stripe is cool but just one area and its centralized and itself relies on payment networks like visa and mastercard, banks and other psp networks all the way to the POS.
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.
One of our primary goals with ACS is to make sure we offered versatility with the platform. We wanted to support both a choice of orchestrators (DCOS and Swarm) and wanted to expose these open source solutions directly, enabling cross-cloud mobility.
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.
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.
The quick reply to your comments is: we're working on almost all of it.
> - 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.
We're working hard on this and focus more and more of our development capacity to this.
> - 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.
There are a lot of improvements coming in this field. Especially the integration and setup of runners is going to be easier. We're hoping to make this a zero-step setup thing.
Same with documentation. Our new GitLab CI maintainer Kamil has been spending a lot of time on writing documentation.
> - 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.
This is interesting, I'm passing it onto Kamil.
> - 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.
This is be interesting to look at. I'm not sure whether we have something like this in the planning, but I'm taking note.
> - Typography could be improved. When you're looking at the issues page all day, this is quite noticeable.
We're worried about adding page load by including typefaces. We might change our minds on this. What OS are you using?
Would Roboto work, for instance?
> - Slack integration is not great; it dumps links to "GitLab Enterprise Edition" instead of useful commit/changeset stuff like GitHub does.
We welcome contributions to improve it. This is not a focus at the moment, but considering the popularity of Slack, we can definitely have a look at this.
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.
> We're working hard on this and focus more and more of our development capacity to this.
No, no, no. :) It's not a development thing, it's a design thing. The good part is that your users are well-defined - developers; you could do a great job there, but don't allocate your developers to it. Hire or contract someone experienced in UX.
P.S. With a good UX work, you might end up not only bettering GitLab's layout but also discovering new, differentiating and truly useful (user-wise) features.
> 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.
I agree out interface can be a lot better. Our first interaction engineer will start September 1 to improve it.
>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.
There’s a lot of going on in this field. We are listening to people’s user cases and trying hard with the rest of community to extend documentation that will cover them. I agree the test runner registration should give better feedback if there are failures. False positives shouldn't happen, please create an issue if they do.
> 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.
Agree, we have that on our roadmap: allow to run commands in case of script failure.
> 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.
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.
> 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.
> But I do want to run integration tests before that feature branch gets merged upstream.
Specifically, the integration tests should run against the version of the source code in the feature branch that the merge request is about. The target branch can be merged into the feature branch to have full coverage of the post-merge status, so the target branch's importance is really minimal here.
> Yes, 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).
Actually no, that's not what I was trying to get at. The tests just have to run against the version of the source code in the feature branch. If the integration tests need to cover anything else, it should be inserted into the feature branch manually. Stale branches are their own problem and are quite common, independent of CI-related testing. Running unit tests all the time is fine, but it would be nice if special additional tests can be triggered only for new merge requests and for updated merge request source branches but not feature branch pushes unassociated with merge requests.
Yes, 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).
Question for you: as a GitLab Enterprise user, knwoing that GitLab has CI built-in, is there a situation in which you would buy CircleCI to go alongside it? Obviously we (we being CircleCI, founder here) have GitHub Enterprise support, and I wonder if we should build GitLab Enterprise support too.
> is there a situation in which you would buy CircleCI to go alongside it?
Well, we were using circleci for a while until the switch to gitlab-ci just recently. Biggest problem was that the circleci runners lose the local docker cache, which meant that unnecessary large chunks of time were spent redoing docker container builds, slowing everything down in our workflow. Note that we run unit tests in docker containers, and to speed things up it would be useful to run unit tests in parallel on multiple separate machines, in addition to preserving the local docker cache on each runner machine.
> So assuming we fixed that, would you buy it (considering esp that GitLab CI exists and you already use GitLab)?
Yes but no, we already switched and we're on to other things. We reported the docker cache issues to you guys a looong time ago, and we get it- most of your customers are probably focusing on webapp unit testing, and probably not on building docker containers and then running unit tests in those containers. There's a lot of hammering to get each CI solution to work just right, but maybe we could switch back more easily if you guys made a gitlab-ci compatibility layer..... (big project, I know).
Oh also we have somewhat-malleable self-hosting requirements, but I mean for the right solution we've been able to forego self-hosting in the past.
That was true in the early days. Now we have toooooons of Docker customers, so this thing is right at the top of our TODO list (and would be done already if it wasnt architecturally hard).
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.
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.
