Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

realartists.com

Post reply on HN
Print view View original

41–50 of 106 posts

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

#41

Post by kogir »

koolba wrote: post #38

> 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 "…

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.

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

#42

Post by joshuahornby »

koolba wrote: post #38

> 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 "…

Care to expand what makes MYSQL so bad?

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

#43

Post by koolba »

kogir wrote: post #41
koolba wrote: post #38

> 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 "…

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.

> 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.

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

#44

Post by kjbflsudfb »

joshuahornby wrote: post #42
koolba wrote: post #38

> 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 "…

Care to expand what makes MYSQL so bad?

OP mentions MSSQL (Microsoft SQL Server), not MySQL.

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

#45

Post by koolba »

joshuahornby wrote: post #42
koolba wrote: post #38

> 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 "…

Care to expand what makes MYSQL so bad?

MSSQL = Microsoft SQL Server : https://en.wikipedia.org/wiki/Microsoft_SQL_Server

MySQL = https://en.wikipedia.org/wiki/MySQL

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

#46

Post by thedjinn »

kogir wrote: post #40
thedjinn wrote: post #35

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

You're right, and we're working on a solution for this now.

In the meantime I suggest you warn trial users about this. I had to manually remove it from 40 repositories.

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

#47

Post by kogir »

koolba wrote: post #43
kogir wrote: post #41

Earlier 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.

> 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.

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.

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

#48

Post by bsimpson »

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.

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

#49

Post by davidcollantes »

mixedCase wrote: post #29
kogir wrote: post #25

Earlier quoted context omitted.

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).

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".

Just curious, could you link an application using Qt/QML with a native-looking Windows GUI?

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

#50

Post by tptacek »

kogir wrote: post #36
rsanheim wrote: post #31

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. Wh…

> 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 ta…

For whatever this is worth to anyone: there are not a lot of people who run bug tracking services that I would trust with my Github credentials, but Nick is one of them.
Post reply on HN