Search the Community

Here's a workflow that's useful for developers; it allows you to convert between timestamps and formatted datetime strings with ease. Simply type "df" followed by: "now", a UTC unix timestamp, or a formatted datetime string. This will present you with the parsed date in various formats ready to copy to your clipboard. Download

A significant problem in adding Alfred 3 features to my workflows is that Alfred-Workflow's update mechanism, which is based on GitHub releases and used by scores of workflows, has no way to tell if a workflow is Alfred 2 compatible or not. Either there's a release with a higher version number containing an .alfredworkflow file or there isn't. That's how GitHub releases work. Developers currently have 2 options to prevent their updated-for-Alfred-3 workflows trying to break themselves in Alfred 2: Start a new repo Mangle the release in some way that older library versions ignore it No. 1 is not a popular solution for obvious reasons. With option 2, you can either mess up the tag (version number) to something that isn't a valid semver, but contains one, like "a3v1.0.1", or you change the file extension of the upload to something that isn't .alfredworkflow. Changing the file extension involves deliberately breaking the fewest things, so that's currently the preferred solution, and it's the one I'm going to go with. The library will rename the file after download if need be. The problem then is that anyone who downloads the file directly from the releases page then won't be able to install it without first changing the extension. That seems to be the least evil on offer, however, and it would be awesome if Alfred 3 "blessed" this behaviour by adding support from an additional, Alfred-3-only file extension. Alfred 2 apparently also has issues with installing workflows it shouldn't because it doesn't support them. A v3-only file extension could head off issues in that direction much more simply that heaps of logic in Alfred 2 to figure out if it's about to overwrite a functioning workflow with a newer, but incompatible, version. In the above-linked GitHub issue, Shawn goes further and says Alfred 3 should use a different extension by default (i.e. if I export a workflow from Alfred 3, it gets a different extension) to provide "a consistent visible indication to the user that a workflow is only for Alfred 3". Certainly a valid point, but it not one I came here to push, as I'd be happy with an "everything works and nothing is broken" solution to the problem as laid out above. (It would also allow parallel Alfred-2 and -3 workflows in the same GitHub release, not that this strikes me as a particularly compelling reason.)

Hey guys, I've just created "Dev Doctor" it has autosuggestions for development amongst others http://wemakeawesomesh.it/alfred-dev-doctor/ A simple walkthorugh of the kinds of things you can do with Alfred Dev Doctor. A really simple documentation helper for alfred. Supports: Languages & Frameworks with autosuggest search PHP - php {query} JavaScript - js {query} jQuery - jq {query}, jquery {query} HTML - html {query} CSS - css {query} Python - py {query}, python {query} node.js - node {query} Ruby on Rails - rails {query} Haskell - haskell {query} Erlang - erlang {query} C - c {query} Languages & frameworks with keyword search: Laravel - larval {query} Bootstrap - bs {query} Flask - flash {query} .NET - .net {query} Java - java {query} Android - android {query} iOS - ios {query} Asset search github repos - github {query} icons - icon {query} Let me know what you think of it It's also on github https://github.com/sydlawrence/alfred-dev-doctor Syd