Search the Community
Showing results for tags 'dev'.
Found 6 results
-
https://github.com/phuibonhoa/alfred-tailwind An Alfred workflow to easily search any Tailwind class, fuzzy matching the name, the generated css, or even other descriptive text. Usage Trigger by typing: TW <search terms> ↩ (Enter) will paste the class in the active window and copy it to your clipboard Ex. text-sm ⇧↩ (Shift + Enter) will paste the slim/haml class (prepended with a .) to the active window and copy it to your clipboard Ex. .text-sm Examples
-
Want to quickly check a page on Learn X in Y minutes (https://learnxinyminutes.com)? That's quite easy with this workflow that I wrote! Installation Install the npm package globally (using npm or yarn): npm install --global alfred-learnxinyminutes yarn global add alfred-learnxinyminutes Requirements You will need Node.js 10 or above Screenshots Invoking with lxy Type something after lxy to begin executing a search I would appreciate any feedback that you might have! Github: https://github.com/solkaz/alfred-learnxinyminutes
-
I’m a newbie to both Alfred development and GitHub version control. I built a new Alfred workflow called Sequential Strings Creator published on Github. I read some documents such as "Exporting and Sharing Workflows” but still confuse about the mechanism of shared release. That is, how should I release the next version so that other Alfred users can get it via the bundle ID? I plan to release the next version by the following steps: Clone the repo from Github remote to local Modify the files and fix the bugs Push the new repo back to the GitHub Release a new version by GitHub with the corresponding alfredworkflow file Is it true that by these procedures, this new version would be received by other Alfred users who use this workflow? Otherwise, what else should I do? Also, is there any method to check whether the release is successfully received by others? -
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.) -
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 -
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
- 7 replies
-
- 6
-
-
- dev
- documentation
- (and 8 more)
