11 ms·

Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues

233 points by kogir 10y ago

kogir 10y ago
Fred, James and I are in the thread and happy to answer any questions about the product and how we built it. There's definitely more detail than made sense to include in the blog post.
- faitswulff 10y ago
  Thanks for offering! Any thoughts on supporting GitHub Projects?
  - kogir 10y ago
    They're kind of supported right now - in that they do show in the app and you can interact with them. As the GitHub APIs for projects stabilize we'll look into more formal support.
- athenot 10y ago
  This looks very nice! Is there an option to not send data via your server? Some Enterprise deployments I know would not play along with that…
  - kogir 10y ago
    Right now we only support public GitHub, though we're open to considering supporting GitHub Enterprise - perhaps even with an on premises installation. Please reach out to support@realartists.com if you'd like to talk about it.
- newman314 10y ago
  Any chance of GitHub Enterprise or Gitlab support?
  - paulgerhardt 10y ago
    Would also love Gitlab support!
    - mrmondo 10y ago
      Yes GitLab support would be fantastic!
- curun1r 10y ago
  This looks cool, but superficially very similar to GitScout. Can you talk about what differentiates your product from that one? I'm not trying to be negative, but as a user of that program, I just want to know a bit more about the differences I can expect before I invest the time to trial your product.
  - fpotter 10y ago
    Sure. The unique thing about Ship is that it is backed by a continuously synchronized local database of your issues, across all of your repos. This lets Ship run incredibly quickly. Because all of your data is already on hand and up to date, you never wait on the network.
- tobr 10y ago
  I'm fascinated by how it looks almost confusingly similar to Mail.app. Of course a lot of apps use a three-pane layout, but most seem to deviate from the standard UI one way or another. I don't mean not to criticise it - it definitely makes it fit right in as a native Mac app, but it makes me interested in your thinking behind it.
  - kogir 10y ago
    It's possible that Mail.app was a source of inspiration, and that we often found ourselves asking, "Oh, that's like <feature> in email. How do other apps do it?"
QuentinM 10y ago
If only this would support PRs / code review with revisions ... !
- TheTon 10y ago
  We're working on something that I think is really good for PRs and code review. It's part way done, and already I think it's a big improvement in usability over the web based interface on github.com. But, in the interest of shipping Ship, we had to cut it from this 2.0 release. (btw, I'm James, I wrote the client side stuff in Ship)
TAForObvReasons 10y ago
How does it compare to the official Github app: https://desktop.github.com/ https://desktop.github.com/
- kogir 10y ago
  It allows full interaction with GitHub Issues. The official application (I believe) only supports limited interaction with PRs.
mcescalante 10y ago
For a new user, they may have no idea that this is a 30 day trial until they download and run the app, and I don't think that there is pricing information on the website anywhere. Not necessary to have any of this, just some feedback :)
- fpotter 10y ago
  Yep - it's a 30 day free trial. After that it's $9/month. Like GitHub, we're also offering a plan for organizations that want to provide Ship to their whole team. Our pricing page goes into more detail -- https://www.realartists.com/pricing.html https://www.realartists.com/pricing.html You're right, though - we should mention the free trial part on the front page. Thanks for the feedback and for trying it out!
  - csomar 10y ago
    How do you charge a subscription for a downloadable, native app? Does the app stop working if I stop payments?
    - jedberg 10y ago
      The client proxies through their servers, so they probably just break your connection.
    - fpotter 10y ago
      If you cancel or your trial expires, Ship keeps working but it only works with your public repos. The intention is that Ship is always free for open source.
    - wlesieutre 10y ago
      Just ask Autodesk and Adobe, it's all they do anymore
- csomar 10y ago
  Not really, their pricing is pretty clear. It's free for public repos and paying for private ones.
mosselman 10y ago
I just tried the app and I think the typography of the issue list makes it hard to look at for me. Also, I doubt that the app is useful to me. What kinds of teams is it aimed at?
- nkoren 10y ago
  Without intending any snark, here's a guide to getting upvoted rather than downvoted for a comment like this: "I think the typography of the issue list makes it hard to look at for me, because ________(insert constructive criticism here)________" "I doubt that the app is useful to me, because ________(insert thoughtful feedback here)________" I'm sure both the authors of the app and the HN readership at large would be more receptive to such a post.
  - dang 10y ago
    Wow, that's really good. Thank you!
  - mosselman 10y ago
    You are right, thanks for the feedback template. While I don't really mind being down voted, I don't want to be bad for morale with posters.
zacmps 10y ago
Why did you develop just for OSX and would you consider supporting other platforms (Linux!) in future?
- kogir 10y ago
  Well, we had to start somewhere, and macOS is what our team knows best. If there's enough interest, we'd love to support other platforms (including Linux).
  - mixedCase 10y ago
    If you have decoupled your application logic from the UI, you might wanna look into Qt/QML. Opens up support for a lot of platforms, and you can have a native-looking GUI for both Windows and Linux using the exact same codebase without "ifdeffing".
    - davidcollantes 10y ago
      Just curious, could you link an application using Qt/QML with a native-looking Windows GUI?
      - LeoNatan25 10y ago
        Native-"looking" = Looks and feels like nothing native. Always use the best UI for each platform, which is the native UI stack.
        mixedCase 10y ago
        Qt maps its widgets to native ones. As long as you pay the same attention to detail as required when you're accessing the Win32 API directly, you're going to be able to get the same results. And as I mentioned in the other comment, QML makes it fairly easy to make UWP/Metro-style apps.
        10y ago
dbg31415 10y ago
Given all the 3rd-party integrations available to the web interface (ZenHub, Harvest, to... Grammarly even), what's the point of having a native MacOS-only interface? It seems limiting / backwards to have native applications when there's already a universal web interface. Are there features that the web interface doesn't have?
- sehr 10y ago
  It's probably faster, easier on the battery, and seems to follow the macOS UI guidelines.
- kogir 10y ago
  Right now we have some search and charting features that GitHub's web interface doesn't. We also hope to do a much better job with PRs (diff view especially). The big win for us right now (and hopefully other teams) is the ability to view issues from multiple repositories all together. So if you have an organization wide "1.0" milestone, you can actually view all the issues in that milestone from all repos at once. You can also use custom queries to group things however you like across all your repos.
niemyjski 10y ago
Brew support?
- kogir 10y ago
  That's actually a great idea. Do they have a notability requirement?
rsanheim 10y ago
This is a impressive amount of work to keep things fast and to avoid hammering GitHub with redundant requests, which can get you rate limited[1] pretty quickly. Couple questions: * I'm assuming you are using the actual end user's token for auth, so at least you have the 5000 requests per user per hour? * It sounds like the Ship server has a lot of (potentially private) user data sitting around to keep things fast. What sort of security do you have in place to prevent data leaks or malicious access? [1] - https://developer.github.com/v3/#rate-limiting https://developer.github.com/v3/#rate-limiting
- weaksauce 10y ago
  > Ship isn't just another GitHub API client app. Ship's custom server code listens and watches for changes from GitHub, and pushes efficient delta updates to clients. Looks like you connect to their servers for updates.
  - stephenr 10y ago
    I'm not really a GitHub user anyway, but that to me is a complete red flag. Even if you completely trust the company is doing the right thing with regards to being a man-in-the-middle by design, you're also dependent on them being financially successful and interested in this platform for the app to be useful long term. Honestly the 'server' part sounds like a solution looking for a problem.
- kogir 10y ago
  > I'm assuming you are using the actual end user's token for auth Yes. 5000 requests seems like a lot, though the GitHub API requires us to be pretty chatty. To show reactions we have to request them for every issue and comment individually, for example. Even doing it on demand (which we do) still requires a lot of requests. > What sort of security do you have in place to prevent data leaks or malicious access? We take this really seriously, but it's hard to answer comprehensively in a comment. Short story: Principle of least privilege, encryption where appropriate, strong passwords and 2FA for everything, write-only logging, super strict firewall rules, and parameterized queries. I've been interested in security for quite a while and even briefly did security consulting, so to the extent I'm able, I've been doing everything as "correctly" as I know how from the beginning.
davidcollantes 10y ago
Very nice, but $9/month to use?
- kogir 10y ago
  If we're not yet there, the goal is to get to the point Ship is worth at least $9/mo. Are there any features you'd like to see?
thedjinn 10y ago
This app installed webhooks on all of my repos with no automated way to remove them. Very annoying.
- lobster_johnson 10y ago
  Can the OP respond to this? I have _tons_ of repos and don't want to end up in the same situation.
- kogir 10y ago
  You're right, and we're working on a solution for this now.
  - thedjinn 10y ago
    In the meantime I suggest you warn trial users about this. I had to manually remove it from 40 repositories.
  - robbiet480 10y ago
    Please work faster, I wasn't alerted that a webhook would be added and now I have 200+ repos that need to have a webhook removed...
  - lobster_johnson 10y ago
    I dearly hope the solution involves not installing webhooks on all one's repositories. Not sure I understand what the webhook is for. (I've not yet installed the app — because of this issue.) Is this done in order to automatically track Github issue changes? If so, what happens if you want to use this app on a project that you don't have admin rights to?
- tranvu 10y ago
  I was about to download but I saw this comment. Thank you sir.
- robbiet480 10y ago
  I didn't want to wait for a solution that may never come for the webhooks added to 200+ repos of mine/that I have access to, so I hacked this script together. https://gist.github.com/robbiet480/2f095c910e56255c412d850400e90b07 https://gist.github.com/robbiet480/2f095c910e56255c412d85040...
koolba 10y ago
> Ship 2.0 is two parts, a hybrid Cocoa/ObjC/CoreData/JavaScript/React application that runs on your Mac, and a C#/MSSQL/Orleans server that runs in Azure. Oh, and a little bit of glue written in Python running on AWS lambda. Yes, it's truly an unholy alliance. What compels someone to write a net new application (from scratch with no legacy DB) that uses MSSQL? In my book it's in front of only DB2 and Oracle on the "Will not use unless you're already using it, migration is impossible, and you're going to have to seriously pay me to deal with this" list.
- kogir 10y ago
  We can agree to disagree, but the tooling has definitely saved me enough time to be worth it. That and realistically, no matter the DB chosen, you either use DB specific features or leave performance (often substantial) on the table.
  - koolba 10y ago
    > We can agree to disagree, but the tooling has definitely saved me enough time to be worth it. What specifically are you referring to (regarding tooling)? Do you mean running it on Azure as a managed service that auto scales, programming tools/frameworks like LINQ, or client side GUI tools? From an automation perspective not having a decent CLI for MSSQL to facilitate scripting makes it a pain from day one.
    - kogir 10y ago
      SSMS is pretty great, especially for digging into query plans and deadlock graphs. Same for SQL Server Profiler. We use Database projects in Visual Studio, so all our schema, stored procedures, and other scripts are in version control. We can compile them (additional validation) into dacpac packages, and script updates and deployment to local instances and Azure with sqlpackage and sqlcmd.
  - shortstuffsushi 10y ago
    The one real downside here is that you're tying your users to Windows. If you had a more "pluggable" db layer, they could use the platform of their choice. That said, the code is in C# as well (and not .NET core, from what I saw), so they're pretty tied to Windows anyway, which is awkward since this is a macOS app.
bsimpson 10y ago
I'd be a lot more curious about it if it handled Pull Requests. (Can't find anything in the screenshots or docs to indicate that it does.) The biggest pain point I've seen with GitHub's current UI is that it's hard to track PRs as they evolve over time - old revisions and comments are often hidden away, with no way to indicate what's been resolved and what hasn't. Though to be honest, I'd be skeptical even if it supported that. I imagine finding enough open source people who will pay $9 a month for a wrapper around a free tool is a challenging business model, and I'd hate to become reliant on it only to find it's been sunsetted due to the cost model. Best of luck to the team! I don't mean to be pessimistic, just aware of the realities of the developer tools market.
- kogir 10y ago
  > I imagine finding enough open source people who will pay $9 Actually, we intend for Ship to always be free for (truly) open source. Public repos will always work, even after the trial expires.
synthecypher 10y ago
Nice I use Bee which supports GitHub and JIRA. http://www.neat.io/bee/index.html http://www.neat.io/bee/index.html Unfortunately this application supports only GitHub issues.
nicky0 10y ago
I got as far as the screen where is asks for full read/write access to my code, including all my private repos. I'm fairly sure you won't mess anything up or steal my secrets, but why does it need this?
- kogir 10y ago
  Sadly, with the current GitHub OAuth flow that's the minimal permission needed to access GitHub Issues. See https://developer.github.com/v3/oauth/#scopes https://developer.github.com/v3/oauth/#scopes
- splix 10y ago
  That's what stopped me from using this app. I can't give it access to most of private repos (because NDA and other stuff), and don't have any plans to use it with that repos. What I wanted to play with some public repos, just to see how it works. Apparently I can't do it w/o giving access to private repos too.
old-gregg 10y ago
Fantastic work! Thank you for sharing. Do you guys see pressure from commercial users to offer one-time payment instead of subscriptions?
- fpotter 10y ago
  Thanks! We think the subscription model is the best fit for our product. While Ship is a native Mac app, it also relies on a backend service so we have ongoing costs to cover there. Also, with subscriptions we don't have to play the upgrade game with our customers. We can release features as they're ready instead of holding them all back so we can justify a $50 upgrade for version 3.0. That said, we would certainly accomodate companies that find it easier to pay annually. And, if we end up doing an enterprise, on-premise version, that may have a different pricing structure.
dongslol 10y ago
I'm impressed by the thought, care, and craftsmanship that went into this, and all the more so because it's such a seemingly mundane tool. A better bugtracker UX. What makes this a secretly interesting or important problem?
- rtpg 10y ago
  Well, we have complex e-mail clients right? Imagine if your e-mail client was like the Github issue tracker. This level of pain is what a lot of larger projects go through. You have tags and basic filtering, but the interface has a lot of friction for "power users" of issues. Think of those projects with 1000 open issues, and how you would want to deal with this quickly. Easy access to certain filters, an interface with less noise, etc.
pier25 10y ago
Is there really a market for this? 9$ per month seems pretty steep when you consider that Github's web interface is free and pretty awesome.
- kogir 10y ago
  That's what we're hoping to find out. I think if you give it a try, you may notice some ways the web interface is less awesome ;)
eschaton 10y ago
Note: Not actually native, it's apparently a weird hybrid JavaScript thing rather than a Cocoa app. At least it's not just a wrapper around a WebView. And if that weren't enough, it has some weird server component that's not Github's own API server. That means I won't touch it, because who knows what it's doing or sending…
- kogir 10y ago
  I'd say it's as native as Mail.app, which also renders HTML content, and relies on a remote server.
  - citruspi 10y ago
    > relies on a remote server. That isn't really a fair comparison when eschaton says > it has some weird server component that's not Github's own API server. The remote servers that Mail.app communicates that are... the email providers. As far as I'm aware, when I use Mail.app with Fastmail, Apple doesn't send all my Fastmail email through their servers. Mail.app talks directly to Fastmail. A mail client which works like Ship 2.0 would be Nylas[0][1]. For anyone who wants a bug tracker for GitHub Issues, JIIRA, or FogBugz which communicates directly with their issue tracking server[2] someone mentioned Bee[3] further down. [0]:https://nylas.com https://nylas.com [1]:https://nylas.com/cloud https://nylas.com/cloud [2]:http://www.neat.io/bee/security.html http://www.neat.io/bee/security.html [3]:http://www.neat.io/bee/index.html http://www.neat.io/bee/index.html
    - grinich 10y ago
      We actually released a version of Nylas Mail last week that communicated directly with your email provider. (Plus it's free!) More details here: https://blog.nylas.com/nylas-mail-is-now-free-8350d6a1044d https://blog.nylas.com/nylas-mail-is-now-free-8350d6a1044d (I work at Nylas.)
Redoubts 10y ago
So does this mean Ship isn't a stand alone tracker any more?
- kogir 10y ago
  Ship 1.0 will continue to work for the foreseeable future, but you're correct: Ship 2.0 depends on GitHub.
hobarrera 10y ago
Hint: Jira support might sell fast too (if you're looking for a second platform to support). All the people I've know who had to use it hated it (myself included), especially the UI.
- softawre 10y ago
  Hm. I love Jira. I am the admin of my projects though, and get to actively work to make things simple for my team.
mrmondo 10y ago
Looks really lovely, would be great to see GitLab integration, I'm seeing a lot of people move from Github Enterprise to GitLab CE/EE which (IMO) is a lot better to work with.
nohant 10y ago
Hopefully not too late, I'm wondering why do you use AWS lambda for?
- kogir 10y ago
  To be honest, we wanted to play with it, and it was really easy to prototype the OAuth code (and keep our OAuth client secret out of the client) before we had the server deployed. Now, since it works great, there's been no need to replace it.
Simorgh 10y ago
no one else seemed to point this out, but your name is really clever :-). 'Real Artists' for the company name and the product 'Ship', as in 'Real Artists Ship', makes me think back to not too long ago when Mr Jobs was still ...
marcosscriven 10y ago
Serious q - how can I trust your 'Login with GitHub' screen? I'd rather be redirected to my browser, so I can see I'm really logging into GitHub, where, in fact, I normally am anyway. Then you can do the whole oauth thing without me having to trust you don't take my password.
- ezekg 10y ago
  OP, I agree with this. As I mentioned in an earlier comment, I was put on edge using that login screen. There's absolutely no way to know if it's real. I ended up creating a fake GitHub account to test the app because it made me uncomfortable.
- kogir 10y ago
  First, we're not stealing your password. Each of us in the past have used multiple GitHub accounts to partition work and personal life, or different consulting clients. I kept them in independent Chrome profiles. We originally had Ship launch the browser, but it was basically a crap-shoot. I often had to paste the link into a different profile. That said, you're right. We should allow the option to use the system browser. From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok.
  - cstejerean 10y ago
    As a counter point, I have never used multiple GitHub accounts and it's unclear why I would. The separation is provided by contributing to different orgs.
  - lentil 10y ago
    > From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok. That's a bit disingenuous. The fact that privilege escalations exist doesn't mean one has to trust all the software one uses completely and unconditionally; it means there are risks that should be taken into account. Given we're talking about the choice between an authentication method where you can trivially capture someone's password, vs an authentication method where you can't (and where you would need to successfully employ some sort of exploit to do so), then the level of risk involved in each is quite different. (Not only that, but I'd argue people will tend to trust software more when it appears to be making best efforts with regards to security. Any obvious security-related flaws will erode that trust rather quickly.) (Edit: typos)
begriffs 10y ago
I use Github email notifications to keep on top of issues. GH lets you use different email addresses for each organization you belong to, and then you can use an email filter rule to separate issue traffic from the rest of your inbox. Admittedly far less powerful than this desktop app, but also simple, free, and native (via my native mail app). It handles a lot of my needs.

233 points by kogir 10y ago

kogir 10y ago

Fred, James and I are in the thread and happy to answer any questions about the product and how we built it. There's definitely more detail than made sense to include in the blog post.

faitswulff 10y ago
Thanks for offering! Any thoughts on supporting GitHub Projects?
- kogir 10y ago
  They're kind of supported right now - in that they do show in the app and you can interact with them. As the GitHub APIs for projects stabilize we'll look into more formal support.
athenot 10y ago
This looks very nice! Is there an option to not send data via your server? Some Enterprise deployments I know would not play along with that…
- kogir 10y ago
  Right now we only support public GitHub, though we're open to considering supporting GitHub Enterprise - perhaps even with an on premises installation. Please reach out to support@realartists.com if you'd like to talk about it.
newman314 10y ago
Any chance of GitHub Enterprise or Gitlab support?
- paulgerhardt 10y ago
  Would also love Gitlab support!
  - mrmondo 10y ago
    Yes GitLab support would be fantastic!
curun1r 10y ago
This looks cool, but superficially very similar to GitScout. Can you talk about what differentiates your product from that one? I'm not trying to be negative, but as a user of that program, I just want to know a bit more about the differences I can expect before I invest the time to trial your product.
- fpotter 10y ago
  Sure. The unique thing about Ship is that it is backed by a continuously synchronized local database of your issues, across all of your repos. This lets Ship run incredibly quickly. Because all of your data is already on hand and up to date, you never wait on the network.
tobr 10y ago
I'm fascinated by how it looks almost confusingly similar to Mail.app. Of course a lot of apps use a three-pane layout, but most seem to deviate from the standard UI one way or another. I don't mean not to criticise it - it definitely makes it fit right in as a native Mac app, but it makes me interested in your thinking behind it.
- kogir 10y ago
  It's possible that Mail.app was a source of inspiration, and that we often found ourselves asking, "Oh, that's like <feature> in email. How do other apps do it?"

QuentinM 10y ago

If only this would support PRs / code review with revisions ... !

TheTon 10y ago
We're working on something that I think is really good for PRs and code review. It's part way done, and already I think it's a big improvement in usability over the web based interface on github.com. But, in the interest of shipping Ship, we had to cut it from this 2.0 release. (btw, I'm James, I wrote the client side stuff in Ship)

TAForObvReasons 10y ago

How does it compare to the official Github app: https://desktop.github.com/ https://desktop.github.com/

kogir 10y ago
It allows full interaction with GitHub Issues. The official application (I believe) only supports limited interaction with PRs.

mcescalante 10y ago

For a new user, they may have no idea that this is a 30 day trial until they download and run the app, and I don't think that there is pricing information on the website anywhere. Not necessary to have any of this, just some feedback :)

fpotter 10y ago
Yep - it's a 30 day free trial. After that it's $9/month. Like GitHub, we're also offering a plan for organizations that want to provide Ship to their whole team. Our pricing page goes into more detail -- https://www.realartists.com/pricing.html https://www.realartists.com/pricing.html You're right, though - we should mention the free trial part on the front page. Thanks for the feedback and for trying it out!
- csomar 10y ago
  How do you charge a subscription for a downloadable, native app? Does the app stop working if I stop payments?
  - jedberg 10y ago
    The client proxies through their servers, so they probably just break your connection.
  - fpotter 10y ago
    If you cancel or your trial expires, Ship keeps working but it only works with your public repos. The intention is that Ship is always free for open source.
  - wlesieutre 10y ago
    Just ask Autodesk and Adobe, it's all they do anymore
csomar 10y ago
Not really, their pricing is pretty clear. It's free for public repos and paying for private ones.

mosselman 10y ago

I just tried the app and I think the typography of the issue list makes it hard to look at for me. Also, I doubt that the app is useful to me. What kinds of teams is it aimed at?

nkoren 10y ago
Without intending any snark, here's a guide to getting upvoted rather than downvoted for a comment like this: "I think the typography of the issue list makes it hard to look at for me, because ________(insert constructive criticism here)________" "I doubt that the app is useful to me, because ________(insert thoughtful feedback here)________" I'm sure both the authors of the app and the HN readership at large would be more receptive to such a post.
- dang 10y ago
  Wow, that's really good. Thank you!
- mosselman 10y ago
  You are right, thanks for the feedback template. While I don't really mind being down voted, I don't want to be bad for morale with posters.

zacmps 10y ago

Why did you develop just for OSX and would you consider supporting other platforms (Linux!) in future?

kogir 10y ago
Well, we had to start somewhere, and macOS is what our team knows best. If there's enough interest, we'd love to support other platforms (including Linux).
- mixedCase 10y ago
  If you have decoupled your application logic from the UI, you might wanna look into Qt/QML. Opens up support for a lot of platforms, and you can have a native-looking GUI for both Windows and Linux using the exact same codebase without "ifdeffing".
  - davidcollantes 10y ago
    Just curious, could you link an application using Qt/QML with a native-looking Windows GUI?
    - LeoNatan25 10y ago
      Native-"looking" = Looks and feels like nothing native. Always use the best UI for each platform, which is the native UI stack.
      - mixedCase 10y ago
        Qt maps its widgets to native ones. As long as you pay the same attention to detail as required when you're accessing the Win32 API directly, you're going to be able to get the same results. And as I mentioned in the other comment, QML makes it fairly easy to make UWP/Metro-style apps.
        10y ago

dbg31415 10y ago

Given all the 3rd-party integrations available to the web interface (ZenHub, Harvest, to... Grammarly even), what's the point of having a native MacOS-only interface? It seems limiting / backwards to have native applications when there's already a universal web interface. Are there features that the web interface doesn't have?

sehr 10y ago
It's probably faster, easier on the battery, and seems to follow the macOS UI guidelines.
kogir 10y ago
Right now we have some search and charting features that GitHub's web interface doesn't. We also hope to do a much better job with PRs (diff view especially). The big win for us right now (and hopefully other teams) is the ability to view issues from multiple repositories all together. So if you have an organization wide "1.0" milestone, you can actually view all the issues in that milestone from all repos at once. You can also use custom queries to group things however you like across all your repos.

niemyjski 10y ago

Brew support?

kogir 10y ago
That's actually a great idea. Do they have a notability requirement?

rsanheim 10y ago

This is a impressive amount of work to keep things fast and to avoid hammering GitHub with redundant requests, which can get you rate limited[1] pretty quickly. Couple questions: * I'm assuming you are using the actual end user's token for auth, so at least you have the 5000 requests per user per hour? * It sounds like the Ship server has a lot of (potentially private) user data sitting around to keep things fast. What sort of security do you have in place to prevent data leaks or malicious access? [1] - https://developer.github.com/v3/#rate-limiting https://developer.github.com/v3/#rate-limiting

weaksauce 10y ago
> Ship isn't just another GitHub API client app. Ship's custom server code listens and watches for changes from GitHub, and pushes efficient delta updates to clients. Looks like you connect to their servers for updates.
- stephenr 10y ago
  I'm not really a GitHub user anyway, but that to me is a complete red flag. Even if you completely trust the company is doing the right thing with regards to being a man-in-the-middle by design, you're also dependent on them being financially successful and interested in this platform for the app to be useful long term. Honestly the 'server' part sounds like a solution looking for a problem.
kogir 10y ago
> I'm assuming you are using the actual end user's token for auth Yes. 5000 requests seems like a lot, though the GitHub API requires us to be pretty chatty. To show reactions we have to request them for every issue and comment individually, for example. Even doing it on demand (which we do) still requires a lot of requests. > What sort of security do you have in place to prevent data leaks or malicious access? We take this really seriously, but it's hard to answer comprehensively in a comment. Short story: Principle of least privilege, encryption where appropriate, strong passwords and 2FA for everything, write-only logging, super strict firewall rules, and parameterized queries. I've been interested in security for quite a while and even briefly did security consulting, so to the extent I'm able, I've been doing everything as "correctly" as I know how from the beginning.

davidcollantes 10y ago

Very nice, but $9/month to use?

kogir 10y ago
If we're not yet there, the goal is to get to the point Ship is worth at least $9/mo. Are there any features you'd like to see?

thedjinn 10y ago

This app installed webhooks on all of my repos with no automated way to remove them. Very annoying.

lobster_johnson 10y ago
Can the OP respond to this? I have _tons_ of repos and don't want to end up in the same situation.
kogir 10y ago
You're right, and we're working on a solution for this now.
- thedjinn 10y ago
  In the meantime I suggest you warn trial users about this. I had to manually remove it from 40 repositories.
- robbiet480 10y ago
  Please work faster, I wasn't alerted that a webhook would be added and now I have 200+ repos that need to have a webhook removed...
- lobster_johnson 10y ago
  I dearly hope the solution involves not installing webhooks on all one's repositories. Not sure I understand what the webhook is for. (I've not yet installed the app — because of this issue.) Is this done in order to automatically track Github issue changes? If so, what happens if you want to use this app on a project that you don't have admin rights to?
tranvu 10y ago
I was about to download but I saw this comment. Thank you sir.
robbiet480 10y ago
I didn't want to wait for a solution that may never come for the webhooks added to 200+ repos of mine/that I have access to, so I hacked this script together. https://gist.github.com/robbiet480/2f095c910e56255c412d850400e90b07 https://gist.github.com/robbiet480/2f095c910e56255c412d85040...

koolba 10y ago

> Ship 2.0 is two parts, a hybrid Cocoa/ObjC/CoreData/JavaScript/React application that runs on your Mac, and a C#/MSSQL/Orleans server that runs in Azure. Oh, and a little bit of glue written in Python running on AWS lambda. Yes, it's truly an unholy alliance. What compels someone to write a net new application (from scratch with no legacy DB) that uses MSSQL? In my book it's in front of only DB2 and Oracle on the "Will not use unless you're already using it, migration is impossible, and you're going to have to seriously pay me to deal with this" list.

kogir 10y ago
We can agree to disagree, but the tooling has definitely saved me enough time to be worth it. That and realistically, no matter the DB chosen, you either use DB specific features or leave performance (often substantial) on the table.
- koolba 10y ago
  > We can agree to disagree, but the tooling has definitely saved me enough time to be worth it. What specifically are you referring to (regarding tooling)? Do you mean running it on Azure as a managed service that auto scales, programming tools/frameworks like LINQ, or client side GUI tools? From an automation perspective not having a decent CLI for MSSQL to facilitate scripting makes it a pain from day one.
  - kogir 10y ago
    SSMS is pretty great, especially for digging into query plans and deadlock graphs. Same for SQL Server Profiler. We use Database projects in Visual Studio, so all our schema, stored procedures, and other scripts are in version control. We can compile them (additional validation) into dacpac packages, and script updates and deployment to local instances and Azure with sqlpackage and sqlcmd.
- shortstuffsushi 10y ago
  The one real downside here is that you're tying your users to Windows. If you had a more "pluggable" db layer, they could use the platform of their choice. That said, the code is in C# as well (and not .NET core, from what I saw), so they're pretty tied to Windows anyway, which is awkward since this is a macOS app.

bsimpson 10y ago

I'd be a lot more curious about it if it handled Pull Requests. (Can't find anything in the screenshots or docs to indicate that it does.) The biggest pain point I've seen with GitHub's current UI is that it's hard to track PRs as they evolve over time - old revisions and comments are often hidden away, with no way to indicate what's been resolved and what hasn't. Though to be honest, I'd be skeptical even if it supported that. I imagine finding enough open source people who will pay $9 a month for a wrapper around a free tool is a challenging business model, and I'd hate to become reliant on it only to find it's been sunsetted due to the cost model. Best of luck to the team! I don't mean to be pessimistic, just aware of the realities of the developer tools market.

kogir 10y ago
> I imagine finding enough open source people who will pay $9 Actually, we intend for Ship to always be free for (truly) open source. Public repos will always work, even after the trial expires.

synthecypher 10y ago

Nice I use Bee which supports GitHub and JIRA. http://www.neat.io/bee/index.html http://www.neat.io/bee/index.html Unfortunately this application supports only GitHub issues.

nicky0 10y ago

I got as far as the screen where is asks for full read/write access to my code, including all my private repos. I'm fairly sure you won't mess anything up or steal my secrets, but why does it need this?

kogir 10y ago
Sadly, with the current GitHub OAuth flow that's the minimal permission needed to access GitHub Issues. See https://developer.github.com/v3/oauth/#scopes https://developer.github.com/v3/oauth/#scopes
splix 10y ago
That's what stopped me from using this app. I can't give it access to most of private repos (because NDA and other stuff), and don't have any plans to use it with that repos. What I wanted to play with some public repos, just to see how it works. Apparently I can't do it w/o giving access to private repos too.

old-gregg 10y ago

Fantastic work! Thank you for sharing. Do you guys see pressure from commercial users to offer one-time payment instead of subscriptions?

fpotter 10y ago
Thanks! We think the subscription model is the best fit for our product. While Ship is a native Mac app, it also relies on a backend service so we have ongoing costs to cover there. Also, with subscriptions we don't have to play the upgrade game with our customers. We can release features as they're ready instead of holding them all back so we can justify a $50 upgrade for version 3.0. That said, we would certainly accomodate companies that find it easier to pay annually. And, if we end up doing an enterprise, on-premise version, that may have a different pricing structure.

dongslol 10y ago

I'm impressed by the thought, care, and craftsmanship that went into this, and all the more so because it's such a seemingly mundane tool. A better bugtracker UX. What makes this a secretly interesting or important problem?

rtpg 10y ago
Well, we have complex e-mail clients right? Imagine if your e-mail client was like the Github issue tracker. This level of pain is what a lot of larger projects go through. You have tags and basic filtering, but the interface has a lot of friction for "power users" of issues. Think of those projects with 1000 open issues, and how you would want to deal with this quickly. Easy access to certain filters, an interface with less noise, etc.

pier25 10y ago

Is there really a market for this? 9$ per month seems pretty steep when you consider that Github's web interface is free and pretty awesome.

kogir 10y ago
That's what we're hoping to find out. I think if you give it a try, you may notice some ways the web interface is less awesome ;)

eschaton 10y ago

Note: Not actually native, it's apparently a weird hybrid JavaScript thing rather than a Cocoa app. At least it's not just a wrapper around a WebView. And if that weren't enough, it has some weird server component that's not Github's own API server. That means I won't touch it, because who knows what it's doing or sending…

kogir 10y ago
I'd say it's as native as Mail.app, which also renders HTML content, and relies on a remote server.
- citruspi 10y ago
  > relies on a remote server. That isn't really a fair comparison when eschaton says > it has some weird server component that's not Github's own API server. The remote servers that Mail.app communicates that are... the email providers. As far as I'm aware, when I use Mail.app with Fastmail, Apple doesn't send all my Fastmail email through their servers. Mail.app talks directly to Fastmail. A mail client which works like Ship 2.0 would be Nylas[0][1]. For anyone who wants a bug tracker for GitHub Issues, JIIRA, or FogBugz which communicates directly with their issue tracking server[2] someone mentioned Bee[3] further down. [0]:https://nylas.com https://nylas.com [1]:https://nylas.com/cloud https://nylas.com/cloud [2]:http://www.neat.io/bee/security.html http://www.neat.io/bee/security.html [3]:http://www.neat.io/bee/index.html http://www.neat.io/bee/index.html
  - grinich 10y ago
    We actually released a version of Nylas Mail last week that communicated directly with your email provider. (Plus it's free!) More details here: https://blog.nylas.com/nylas-mail-is-now-free-8350d6a1044d https://blog.nylas.com/nylas-mail-is-now-free-8350d6a1044d (I work at Nylas.)

Redoubts 10y ago

So does this mean Ship isn't a stand alone tracker any more?

kogir 10y ago
Ship 1.0 will continue to work for the foreseeable future, but you're correct: Ship 2.0 depends on GitHub.

hobarrera 10y ago

Hint: Jira support might sell fast too (if you're looking for a second platform to support). All the people I've know who had to use it hated it (myself included), especially the UI.

softawre 10y ago
Hm. I love Jira. I am the admin of my projects though, and get to actively work to make things simple for my team.

mrmondo 10y ago

Looks really lovely, would be great to see GitLab integration, I'm seeing a lot of people move from Github Enterprise to GitLab CE/EE which (IMO) is a lot better to work with.

nohant 10y ago

Hopefully not too late, I'm wondering why do you use AWS lambda for?

kogir 10y ago
To be honest, we wanted to play with it, and it was really easy to prototype the OAuth code (and keep our OAuth client secret out of the client) before we had the server deployed. Now, since it works great, there's been no need to replace it.

Simorgh 10y ago

no one else seemed to point this out, but your name is really clever :-). 'Real Artists' for the company name and the product 'Ship', as in 'Real Artists Ship', makes me think back to not too long ago when Mr Jobs was still ...

marcosscriven 10y ago

Serious q - how can I trust your 'Login with GitHub' screen? I'd rather be redirected to my browser, so I can see I'm really logging into GitHub, where, in fact, I normally am anyway. Then you can do the whole oauth thing without me having to trust you don't take my password.

ezekg 10y ago
OP, I agree with this. As I mentioned in an earlier comment, I was put on edge using that login screen. There's absolutely no way to know if it's real. I ended up creating a fake GitHub account to test the app because it made me uncomfortable.
kogir 10y ago
First, we're not stealing your password. Each of us in the past have used multiple GitHub accounts to partition work and personal life, or different consulting clients. I kept them in independent Chrome profiles. We originally had Ship launch the browser, but it was basically a crap-shoot. I often had to paste the link into a different profile. That said, you're right. We should allow the option to use the system browser. From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok.
- cstejerean 10y ago
  As a counter point, I have never used multiple GitHub accounts and it's unclear why I would. The separation is provided by contributing to different orgs.
- lentil 10y ago
  > From a strict security standpoint though, a malicious native app has remote code execution on your box. It's game over. You're just one local privilege escalation away from complete compromise. At some point you have to trust reputation or never use any software. If this is a concern for you, native apps aren't for you, and that's ok. That's a bit disingenuous. The fact that privilege escalations exist doesn't mean one has to trust all the software one uses completely and unconditionally; it means there are risks that should be taken into account. Given we're talking about the choice between an authentication method where you can trivially capture someone's password, vs an authentication method where you can't (and where you would need to successfully employ some sort of exploit to do so), then the level of risk involved in each is quite different. (Not only that, but I'd argue people will tend to trust software more when it appears to be making best efforts with regards to security. Any obvious security-related flaws will erode that trust rather quickly.) (Edit: typos)

begriffs 10y ago

I use Github email notifications to keep on top of issues. GH lets you use different email addresses for each organization you belong to, and then you can use an email filter rule to separate issue traffic from the rest of your inbox. Admittedly far less powerful than this desktop app, but also simple, free, and native (via my native mail app). It handles a lot of my needs.