Jump to content

Ask, Create, Share


Recommended Posts

Ask Create Share

hZe2AUY.png 

 

This workflow lets you open any web submission on the Internet. Such as quickly making a Reddit post to some subreddit, creating a new GitHub repo. Making a post on stack exchange forum and more.

 

The list of web submissions is user curated and can be extended here.

 

For more information, on how you can use the workflow, you can read the GitHub readme.

 

CodeDownload

Edited by nikivi
Link to comment

Short tip on the gif. Instead of cutting it so harshly at the edges of the app, move/hide all your Desktop icons and set a completely white background. Then, when recording keep a bit of the app’s shadow. When played back on a page it’ll look more natural, as if the app itself is there. See the method in action on Homebrew-Cask’s README. It may look a bit fuzzy to you1 but the idea is there.


Also, you should do things slower. I can’t read anything on the gif; it’s hard to keep up.



1.  It appears you may have a retina screen and the gif had to be recorded on a VM made by an app that cannot display in retina resolution.

Link to comment

Yeah the reason I did things as fast is because I wanted to keep the size under 5 MB. If its above, it doesn't render on GitHub. :( 

 

I put the files on a private repository with all other GIF's and that's the only limitation I have. I can try to make a slower version but then I can't show many things. :( 

Edited by nikivi
Link to comment
34 minutes ago, nikivi said:

I wanted to keep the size under 5 MB. If its above, it doesn't render on GitHub.

 

You could always put it up on imgur and then link it. But that’s not necessarily the right solution.

 

The gif in question is almost 3MB. That is definitely too much for what it is, and it looks like it might be a failure on the part of whatever tool you’re using to create the gif. What’s your process?

Link to comment
  • 1 month later...
3 hours ago, nikivi said:

Still not sure how to add auto updating but I will figure it out eventually.

 

If you can figure out Kingpin, you can figure out how the updating works.

 

TBH, Kingpin is overkill for such a simple workflow (it's for programs with lots of commands and options). It might have been a better idea to copy and adapt the update example workflow.

 

Code-wise, you'd only need to replace the placeholder code that generates dummy results with your own code to parse your CSV into Items.

 

Link to comment

Hey @deanishe. Can you please help understand what I am doing wrong? 

 

So I am following on your advice in modifying the example workflow and made the changes here.

 

But calling it from script filter gives me a stack trace error : 

 


	/Users/nikivi/go/src/git.deanishe.net/deanishe/awgo/workflow.go:655 +0x43
main.run()
	/Users/nikivi/go/src/github.com/nikitavoloboev/alfred-ask-create-share/main.go:98 +0x340
git.deanishe.net/deanishe/awgo.(*Workflow).Run(0xc4200b50e0, 0x12fc5a0)
	/Users/nikivi/go/src/git.deanishe.net/deanishe/awgo/workflow.go:581 +0x253
main.main()
	/Users/nikivi/go/src/github.com/nikitavoloboev/alfred-ask-create-share/main.go:141 +0x39
12:18:13 workflow.go:570: ---------------- END STACK TRACE -----------------
12:18:13 feedback.go:441: Sent 1 result(s) to Alfred
12:18:13 workflow.go:698: [ERROR] runtime error: invalid memory address or nil pointer dereference
12:18:13 workflow.go:726: ---------------------- 2ms -----------------------
[2017-09-13 12:18:13][input.scriptfilter] {
  "variables": {
    "AW_SESSION_ID": "1HH2GDNYXXVI7HVSZWK1B182"
  },
  "items": [
    {
      "title": "runtime error: invalid memory address or nil pointer dereference",
      "valid": false,
      "icon": {
        "path": "/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/AlertStopIcon.icns"
      }
    }
  ]


I suppose the reason is that I call it wrong. Here is the workflow I use that I built from that code. I am super confused by this. ?

 

Thank you for any help. 

 

 

Edited by nikivi
Link to comment

Thank you. It fetches Items now. 

 

However the update always pulls my first ever release, not the latest.

 

I tried to play around with setting different versions in the 'Workflow Version' but no matter what I type there it will always fetch the first release I have submitted to GitHub.

 

One idea I have why this might happen is that I use this command line tool to build and symlink my workflow. And that will always set my info.plist to version 1.0 when it builds the workflow. I am not really sure what else might be causing this. 

 

I updated my code on GitHub and here is the built workflow.

 

Thank you a lot for any help. I really wish I can get this working.

Edited by nikivi
Link to comment
23 minutes ago, nikivi said:

And that will always set my info.plist to version 1.0 when it builds the workflow

 

Did you even look in the debugger? The first thing AwGo logs is your workflow version. It says 0.9, not 1.0.

 

17 minutes ago, nikivi said:

However the update always pulls my first ever release, not the latest.

 

No, it doesn't. It downloads the second release. The one you've tagged "2". As you may know, 2 > 1.2.  The docs are very clear about the fact that updates are based on (mostly) semantic version numbers.

 

Your previous issue—forgetting to give your workflow a version number—is something that happens to everyone now and again (and as a result, I've updated AwGo to panic with a clear error message if you try to set an Updater for a workflow with no version number. Thanks for "finding" the issue). But this time, the log file tells you exactly what's going on:

21:33:02 update.go:166: Latest release: 2.0.0
21:33:02 update.go:211: downloading release 2.0.0 ...

I'm sure you can understand how annoying it is for me to answer your questions when you haven't even tried to figure out the problem by reading the log file, and also post an error report containing entirely false information (again, because you didn't even read the log).

 

I sincerely suggest you learn JavaScript, Node and alfy by @sindresorhus, instead of using Go and AwGo. It's fast—much faster than PHP/Python/Ruby, and I know speed is very important to you.

 

The Go language itself is pretty simple, but the community and docs assume a fairly high level of programming competence. As a statically-typed language with pointers, it also requires quite a high level of attention to detail.

 

By all appearances, you currently possess neither.

 

JavaScript and its community are much more attuned to sloppiness.

Link to comment

The workflow finally has auto updating + I added icons for visual clarity. Can grab update from GitHub.

 

5 hours ago, deanishe said:

Did you even look in the debugger?

I did look at it but somehow missed the part where it logged the version. No idea how.

 

5 hours ago, deanishe said:

I'm sure you can understand how annoying it is for me to answer your questions when you haven't even tried to figure out the problem by reading the log file

I do understand it and I feel very bad that it has to be this way. I don't feel good asking these questions either and looking like a fool trying to ask rather `idiotic` in hindsight questions and I try to learn from each of the encounters. At least I have learned the lesson of not posting images instead of workflows. 

 

5 hours ago, deanishe said:

By all appearances, you currently possess neither.

You are right. I am not the best programmer and never claimed to be. I think though that you didn't become so good at this instantly either. You probably learned too although maybe asked fewer questions than I did. But yeah it is my fault though, I really suck at noticing these little things and often give up too quickly when things go wrong and that is something I have to learn to fix.

 

5 hours ago, deanishe said:

I sincerely suggest you learn JavaScript, Node and alfy by @sindresorhus, instead of using Go and AwGo

I actually have tried Alfy for a bit before and it is AwGo that actually brings me joy developing workflows. I also find reading Go stdlib much nicer than node docs. 

 

5 hours ago, deanishe said:

but the community and docs assume a fairly high level of programming competence

That is true, but I found Golang community actually quite welcoming and friendly to newcomers which is nice.

 

5 hours ago, deanishe said:

JavaScript and its community are much more attuned to sloppiness.

I think thats simply due to the number of JavaScript developers. 

 

Having said that, I am still learning both programming and playing well with Alfred and I appreciate all the help you've given me thus far. It really opened up my eyes to many things. And of course thank you for the amazing AwGo, debugging and developing workflows with it is seriously awesome as you can see from which files and lines the logs were called and many more little things that I am only now starting to appreciate. 

 

It feels good to know that my workflows are now auto updated. I also think the name of this workflow is kind of appropriate to this 'discussion'.

Edited by nikivi
Link to comment
3 hours ago, nikivi said:

give up too quickly when things go wrong and that is something I have to learn to fix.

 

That is the impression I get. You're clearly not stupid. I wish you would spend a bit more time using your brain before using mine. 

 

3 hours ago, nikivi said:

I think though that you didn't become so good at this instantly

 

Have you heard the expression, "make one to throw away"?

 

A lot of coders, me included, appear better because they keep their first version entirely private. When it's mostly (or even only half) done, they see the silly mistakes they made. Then they throw it away and write a new, much better version now they understand the problem better. 

 

That's the version everyone else sees.

 

I make lots of silly mistakes. The  difference is, I fix most of them myself before I let anyone else see the code.

 

Maybe 5-10% of my code is in public repos. The rest is in very dodgy prototypes that mostly work for me, but which I'd never release without entirely rewriting.

Link to comment
6 hours ago, deanishe said:

A lot of coders, me included, appear better because they keep their first version entirely private. When it's mostly (or even only half) done, they see the silly mistakes they made. Then they throw it away and write a new, much better version now they understand the problem better. 

 

There’s a quote from The Cathedral and the Bazaar that I come back to often: “you often don't really understand the problem until after the first time you implement a solution. The second time, maybe you know enough to do it right. So if you want to get it right, be ready to start over at least once”.

Link to comment
1 hour ago, deanishe said:

You're rewriting Homebrew-Cask, aren't you?

 

Close! I did go to an old post on Homebrew-Cask to copy that quote verbatim (I’ve linked back to that issue so many times I know the issue number by heart). To cut the post short, the most important takeaway from it was to announce the end of our old way of installing apps (symlinking to ~/Applications) to the new way (moving the app bundle to /Applications). But all that is done now; everything but a tiny internal change that’s and low priority.


But if HBC were restarting from scratch, there are other core things I’d do differently. I’ve been thinking of starting an experimental project for it (maybe an excuse to learn Haskell), but a current lack of money/time prevents me from doing so. So far it’s just a bunch of ideas spread around loose txt documents.

Link to comment
5 minutes ago, vitor said:

maybe an excuse to learn Haskell

 

Is Haskell particularly suited to such a project? Or do you just want a reason to learn it? It seems like a fairly significant dependency, though I assume Homebrew has it. I'd imagine it would reduce the potential pool of contributors significantly, too, even if it would increase the average quality of pull requests.

 

EDIT: Oh, I know that issue, too.

Edited by deanishe
Link to comment
29 minutes ago, deanishe said:

Or do you just want a reason to learn it?

 

That one. Haskell Programming: From First Principles has been lauded as an amazing book for it and Haskell itself as a language that changes the way you look at programming in general, so I’d like to give it a try.

 

31 minutes ago, deanishe said:

I'd imagine it would reduce the potential pool of contributors significantly, too, even if it would increase the average quality of pull requests.

 

That’s true, but if it took off it might also increase interest in the language. However, since the main core things I’d like to change are related to how the cask files themselves are constructed, that would not be a major issue. Many of our contributors don’t know ruby or don’t even know how to code, but since cask files themselves are simple, they can contribute easily.

 

All that said, I’m not married to Haskell for that idea. At one point I even considered Bash, just to test the concepts quickly.

Link to comment
2 minutes ago, vitor said:

Haskell itself as a language that changes the way you look at programming in general, so I’d like to give it a try.

 

Heard the same, but the Haskell code I've seen looks harder to understand than even Perl.

 

I've been wanting to learn a Lisp for much the same reason for quite some time. The books and tutorials I've found have all been too mathematical for my tastes :( 

Link to comment
17 minutes ago, deanishe said:

Heard the same, but the Haskell code I've seen looks harder to understand than even Perl.

 

I've been wanting to learn a Lisp for much the same reason for quite some time. The books and tutorials I've found have all been too mathematical for my tastes :( 

 

Same here, on all accounts. That’s why that specific book (and all accompanying praise) sparked my interest. It’s written by both an experienced programmer and a novice (never coded before). They wrote the book at the same time he was teaching her.

 

20 minutes ago, nikivi said:

Just wanted to ask. @vitor what are your thoughts on nix as a package manager? I believe that does something that you may want to implement in the end?

 

I know of it, but never looked at it in depth. Don’t remember the exact reasons, but likely because it wasn’t focused on macOS. Linux already has a ton of package managers, and they’re so ingrained in their systems most software lends itself to being distributed by them and you might choose one package over the other due to that.


On macOS, the case is very different. There are tons of closed-source apps and many different distribution models. Exceptions abound, each with their own flavour of differences. It’s complex enough that for all intents and purposes, Homebrew and Homebrew-Cask are still different projects with different teams. They’re now seamlessly integrated, but even though we try not to step on each other’s toes, even our rules for what constitutes an acceptable package are different, and we intend to keep it that way.


In sum, from my experience, with the current state of affairs a good macOS package manager (that includes closed-source packages) should be focused on macOS first.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...