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.
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.
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.