3 ms·

Anything where we can't host the tool and point it at git repositories on a server we control is a complete non-starter for us, unfortunately. This is mostly be

Anything where we can't host the tool and point it at git repositories on a server we control is a complete non-starter for us, unfortunately. This is mostly because our development and test environments are not connected to the Internet. Other than that, I took a quick look at your product and it's feature-wise close to something I would want to use. Only comments I would make would be that non GitHub projects generally want the review tool to handle the branch management (a.k.a storing pull requests, flagging their status, etc.): of course only focusing on GitHub lets you not worry about that and get a product running much sooner... You should spend some serious time looking at your page load times as well - I'm 10msec away from your server and the demo code review at https://reviewable.io/reviews/Reviewable/demo/1 https://reviewable.io/reviews/Reviewable/demo/1 took nearly three full seconds to load, even with most static assets already cached since I didn't timeline it on the first attempt.

piotrkaminski 11y ago
Thanks for taking a look! Unfortunately, developing self-contained tools that customers run behind a firewall is a complete non-starter for me. ;-) Developing against the GitHub API does carry some non-trivial advantages: among other things, I never actually clone any repos. This wouldn't be possible with a raw git repo. I'm considering adapting the tool to AWS CodeCommit, though, which might be a decent middle ground. Making my own equivalent of pull requests is actually the least of the changes I'd need to make, though. And yeah, performance is a never-ending battle... But considering that all the work is done in the browser (fetching sources, diffing, formatting, etc.) I think it's actually not too bad. Again, like running in the cloud, it's a trade-off of in favor of flexibility and development speed.

piotrkaminski 11y ago

Thanks for taking a look! Unfortunately, developing self-contained tools that customers run behind a firewall is a complete non-starter for me. ;-) Developing against the GitHub API does carry some non-trivial advantages: among other things, I never actually clone any repos. This wouldn't be possible with a raw git repo. I'm considering adapting the tool to AWS CodeCommit, though, which might be a decent middle ground. Making my own equivalent of pull requests is actually the least of the changes I'd need to make, though. And yeah, performance is a never-ending battle... But considering that all the work is done in the browser (fetching sources, diffing, formatting, etc.) I think it's actually not too bad. Again, like running in the cloud, it's a trade-off of in favor of flexibility and development speed.