3 ms·
It's closer to weekly than biennial. At GitHub's size, there are minor hiccups that affect a small number of users more often than any one user will see. My co
by arohner 14y ago
It's closer to weekly than biennial. At GitHub's size, there are minor hiccups that affect a small number of users more often than any one user will see.
My company (https://circleci.com https://circleci.com) uses GitHub OAuth and checks out code as its core functionality. Believe me, I get emails every time GitHub has an issue for 30 seconds.
- 1qaz2wsx3edc 14y agoYea, I could see that volume from a SaaS service. As a user though, I'd say github has service issues every month. I think the last one was caused by a massive ddos or an exploded db and faulty fail over. They're pretty good a keeping a sinking ship floating and as long as `git` doesn't go down, it's not the worst thing in the world. It's prolly terrible for you service guys.
- mh- 14y agowe're currently evaluating CI solutions and I've been meaning to give Circle a look. Am I overlooking a tour (or just a single screenshot?) on your website? Based on skimming your docs it seems like this could be a much more approachable solution than your competitors.. and based on the care taken in the designing your website/brand I'm guessing you invested in making a good UI. show it off! :) edit: before someone suggests 'just sign up for the trial and look' -- as mentioned, Circle's authentication is (understandably) via GitHub -- that means authorizing them to write to my private repositories without seeing anything about the product.
- pbiggar 14y agoHey mh-, I'm the other founder. You're not overlooking a tour, there isn't one at the moment. Currently, our UI is boring. We (and most CI services) do a basic list-of-builds UI. I don't think that's good enough, but we've been short staffed until recently due to fund-raising, but now we're finally getting a chance to think about how best to provide the best user experience around that. The things that are amazing about Circle now are outside the UI. For example, we can auto-parallelize long builds to run in a fraction of the time. Your tests run blazingly fast on our boxes (we've spent months ensuring we're the fastest service by a long way). We do personalized notifications of failures (cause you don't care what your colleague does on his branch). So please don't judge us on how pretty our pictures are :) FYI: we hate the "write to my private repos" thing too, but with GitHub's permissions model there isn't a better alternative (there are alternatives, they're all bad).
- mh- 14y agoHi Paul, thanks for the reply! I wasn't judging you guys on the 'pictures' at all. :) Was just giving some candid feedback from my experience. I actually signed up write after I wrote that, and was going to post again once I'd had a chance to try it. I did get to try it briefly and I actually think the UI, while simple, is better than the other (albeit much more complex) solutions I've been looking at. >FYI: we hate the "write to my private repos" thing too, but with GitHub's permissions model there isn't a better alternative (there are alternatives, they're all bad). IMO, this would be a big improvement and is doable: let me sign up (still via GitHub auth) without asking for the repo or user scopes. Then have a call-to-action that upgrades the token, as part of the guided welcome into Manage Repos. [I realize this could hurt your funnel, perhaps offer this path buried in the FAQ somewhere if that's a concern] If you pass nothing for the scope param to the GitHub API, that gives you the authentication piece with read-only access to the user's public stuff. Then just add a "Hey, we can only see your public repos by default - click here [..]" that sends them into the web flow again with the additional scopes, to upgrade your auth token. Also, while I'm giving unsolicited advice :) - it may be obvious, but letting the user know that when they follow a repo (and just doing this on the first repo they use would be fine) that you're going to add an SSH key would probably be a good addition. Since adding a deploy key sends an email to all admins of the organization, some users might want to give people a heads-up they're trying out Circle. . . . Anyway, Circle looks great already and I'm eager to see what other stuff you guys have in store. I'll certainly be using it for some of my projects.
- pbiggar 14y agoThanks for the feedback! There's definitely a lot of ways we can do this, and each has tradeoffs. One tradeoff that came up when we tried to switch to public-only authentication first is that the login button needed to have different scopes - and apparently a lot of people try to sign up via that button. I agree that we need more warning with the SSH keys. I'll try to figure out where to put that - we used to warn in a previous iteration, but we're moving very quickly and some things get lost sometimes (especially with A/B tests). We're doing a lot of work to provide user education around what they should expect from Circle, so that's definitely a must-have. Thanks!