Marc Köhlbrugge
PRO
@marc
Marked as Duplicate. Please see:
That's not a bad start. It shows there's interest.
Have you talked to @AndreyAzimov? He very recently launched his own menu bar app. Perhaps you can exchange ideas on how get PR and get customers.
Congrats! How much did you make? If you're comfortable sharing 😄
I’m disappointed but confortable with sharing 😊
16 sales = 16 * $2.99 = almost $48
Less Apple cut (30%) = $33.5
That's not a bad start. It shows there's interest.
Have you talked to @AndreyAzimov? He very recently launched his own menu bar app. Perhaps you can exchange ideas on how get PR and get customers.
Cool! Is it possible to upgrade the Workflow from within Alfred, or do we need to use npm? In the case of the latter, feature request: being able to update from within the workflow (maybe even with the occasional check if there are new updates?)
Well thats not really possible. As Alfred does not have support for these kind of things.
You actually should get a message that a new version is available after a release in npm.
The only other solution would be to use Packal.
But as far as I remember people need to install it also, to manage their alfred packages.
And not sure how good the publishing workflow is with packal.
Thanks! I think having duplicate questions won't happen too often (because why ask the same question twice?), but I do indeed need to keep it mind for when it does happen.
I'm thinking of just adding an incrementing number to the end of the slug (e.g. "foo-bar" for the original question, and "foo-bar-2" for the duplicate question)
That might work too.
because why ask the same question twice?
It will happen because there is no search yet so it depends when you will implement it. But again nobody searches because its harder than directly asking (personal opinion because that's what I do all the time on StackOverflow 😂)
For it not to happen you will need a similar questions functionality like StackOverflow
Thanks, that's a fair point. That said, it still seems wise to specify the origin within the CORS configuration so unknowing users (using regular browsers) can't be tricked into uploading to my S3 bucket. I guess that's the point of the origin being configurable by S3?
I am not sure what use cases are there that require public uploads to be honest except running an image hosting site.
Also pretty sure nobody would try to trick uploading the user to upload something to your s3 bucket. But instead upload something themselves and then distribute it.
What you need to do is create a single-use policy, something like explained here - stackoverflow.com/a/18901867/…
Ah yes, I already generate a policy so only signed in users can upload files to our S3 buckets. And files that aren't attached to a saved database entry (e.g. a comment) are automatically pruned.
So I think things are pretty safe as is. Just wondering if there are any best practices otherwise.