Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
realartists.com
realartists.com
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?
Looks like you connect to their servers for updates.
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.
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.
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.
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.
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)
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?
https://gist.github.com/robbiet480/2f095c910e56255c412d85040...
We've just pushed new client and server versions to cleanup hooks when the last admin user logs out.
New downloads will be the latest version, and current users can update now using the Ship -> Check for Updates menu option. After that, you can logout using Ship -> Account -> Logout. If you used the app earlier and want to be sure all hooks are cleared out, you can log back in once more and then logout again to trigger the removal.
There is also updated documentation here: https://www.realartists.com/docs/2.0/uninstall.html
So about hooks - Hooks are added so that Ship is alerted when new repos are created, issues/labels/milestones/comments are added/modified/deleted, issue templates change, etc. The user experience without hooks is acceptable, but not great. Presumably if you're using Ship, you want it to show the most up to date information.
We disclose when you authorize Ship that you're granting repository and organization webhook permissions. This appears to be insufficient notice. We'll think about that next.
If anyone is still having trouble or needs personalized help, we're reachable at support@realartists.com.
I would love something like Ship for my main public repo, and in fact would prefer to just use Ship for that repo.
As the GitHub APIs for projects stabilize we'll look into more formal support.
9$ per month seems pretty steep when you consider that Github's web interface is free and pretty awesome.
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.
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.
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.
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.
http://www.neat.io/bee/index.html
Unfortunately this application supports only GitHub issues.
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…
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 [1]:https://nylas.com/cloud [2]:http://www.neat.io/bee/security.html [3]:http://www.neat.io/bee/index.html
(I work at Nylas.)
(btw, I'm James, I wrote the client side stuff in Ship)
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.
Actually, we intend for Ship to always be free for (truly) open source. Public repos will always work, even after the trial expires.
Are there features that the web interface doesn't have?
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.
Now, since it works great, there's been no need to replace it.
Our pricing page goes into more detail -- 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!
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.
And as I mentioned in the other comment, QML makes it fairly easy to make UWP/Metro-style apps.
Like previous post @LeoNatan25 wrote, they looked and feel nothing like native.
In any case... Qt does map its widgets to the Win32 ones, it's not just a crude imitation. Apps like OBS, Wireshark, VLC and KeePassX get close to a native appearance, it's just that nobody seems to give a shit about going the extra mile to make an app look native in Windows.
There's this if you wanna see how you can get a Qt app to feel right on every platform: http://www.slideshare.net/qtbynokia/how-to-make-your-qt-app-...
Also, UWP style applications seem fairly easy to make with QML if, again, you give a shit.
"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.
While I don't really mind being down voted, I don't want to be bad for morale with posters.