Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
81–90 of 106 posts
Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
#82Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
#83This 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. Wh…
> 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.
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.
Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
#84I 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?
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 b…
While I don't really mind being down voted, I don't want to be bad for morale with posters.
Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
#85Earlier quoted context omitted.
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.
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.
Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
#86Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
#87Re: Show HN: Ship 2.0 – A macOS Native Interface to GitHub Issues
#88Earlier quoted context omitted.
Native-"looking" = Looks and feels like nothing native. Always use the best UI for each platform, which is the native UI stack.
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.
Like previous post @LeoNatan25 wrote, they looked and feel nothing like native.