A clipboard manager is an absolute have to have.
Having the last 40 or so clibboard items available to me instinctively has increased my productivity and the speed at which i can do anything on a computer.
I use the one that is part of the Alfred power pack, but there are plenty of others out there. https://www.alfredapp.com/help/features/clipboard/
For Windows, there's Ditto (http://ditto-cp.sourceforge.net/). It's insanely useful for slinging text around, like when you're copy-pasting a ticket number into several different places in-between other bouts of work that need the clipboard. Also useful for saving small URL/code/SQL snippets and retrieving them with a quick incremental search.
Whichever I have tried I always felt like a slave.
The ones with enough experience to hate thoroughly so far are:
- bash
- powershell
- windows cmd/batch
- ansible
- terraform
- azure clis, azure powershell api
- aws python api, cli
- Jenkins
- MS Team Foundation Services
- Docker (one of the nastiest ones)
- Rancher
I always managed to solve the tasks with the tools at hand (one of these), but all have so many weak points one must always work around, that I cannot say any single one made me feel like a boss when I had to use them for any non-trivial task.
Many tools are indeed not the 'feel like a boss' type, but the 'thoroughly hate it' kind. Having tried plenty of tools for cfg mgmt for example, GPO, Ansible and CFengine basically make you want to jump out of a window, as well as diverse puppet versions. Same goes for SCM/VCS systems that can't even get on Subversion-level, which by itself nowadays is a reason to not take a job.
- Workspaces! These help with focus and isolate the "blast radius" of getting randomized
- Spectacles: windows manager to assign windows to left/right side of screeen, across monitors, or left, middle or right 1/3
- CopyClip: I don't use this clipboard manager all the time, but when I do, it SAVES MY BUTT
- Sublime: speaking of saving my butt...Sublime has never once lost a single file. I love Vim but Sublime has flawless reliability
- Cmd+0: Global hotkey to "new browser window" If you do something 20+ times a day, make it super stupid fast (I know it conflicts with "reset zoom" but I can just manually adjust zoom back to 100%)
- Shell scripts: If I'm typing more than 3+ commands over and over again, just script it. Scripting isn't scary and more developers need to be doing it. (I seem to be the only one on my team, which is why I say that)
For me, Keyboard Maestro[1], which is probably the one app I couldn't live without.
With it, I can do things like highlight any git sha (or any sha range) in the terminal, press a keyboard command and it will launch my diff tool with the diffs for just that commit.
I also use it to do inline transpiling of different code. I have keyboard commands for transpiling my highlighted Sass or ES6 code and replacing it with the result.
It's so powerful, there's very little it can't do.
Jenkins is fantastic because you can plug it into just about everything, and trigger your job that does $whatever either on a timer, manually or with an HTTP GET request. When I started at this company, Jenkins was nothing more than a web server used to launch an all-encompassing build script on SVN commit. Since then, I've redesigned all builds using plugins such that Jenkins now manages the whole process (previous admins had reinvented so. f*cking. much. stuff Jenkins does natively) and we're using Jenkins to automate just about everything we can plug it into.
This and Powershell, which although its syntax is mind-bending and in some cases just outright appalling, is a decent attempt at a scripting language with exceptional power over Windows.
Got any tips you could share regarding the Jenkins setup? I'm going to be needing to rework our current Jenkins build system—which sounds pretty similar to your "all-encompassing build script"—as we're about to migrate from Perforce to SVN. I know what we've got setup is pretty bad, but I don't know much about best practices for build organization.
You also get the benefit of it the jobs being built on a shared environment. If developer A wants to build a job, $THING-A and developer B wants to build a their job, $THING-B, there's no having to look through code for environment variables or other differing, machine-specific issues, that might pop up when building with something like, for example, Terraform.
Emacs - even a novice elisp programmer has more power to automate their Emacs environment than I've seen in any other tool. If you've ever wondered how a small community managed to maintain near feature-parity with popular IDEs for 3 decades, this is it.
I'd disagree on "feature parity" for some usecases. For example, I used Emacs as my Java IDE for some time, but it lost that race in a hurry as IDEs caught up to JDEE. And it wasn't even close within a year or two after that.
I'm not even sure if Emacs will hold up to tools like IntelliJ for Ruby/Rails/JavaScript development at this point, although in that space it's a lot closer.
Overall, however, I agree: Emacs is freakin' awesome. Heck, I booted into it as my shell for a few years. I keep meaning to get back into it but I rarely have the time, and I need to learn more Vim as well. Time is the enemy.
Me too. I'm now much more proficient in emacs-lisp than in Python, my second-best language. I don't write bash scripts often enough to remember all the gotchas.
It's a little embarrassing how much I do through emacs: manipulating the file system, url fetching, RPC... stuff you really shouldn't be doing with your text editor. But hey, the tool you know...
An automator script to gather AWS session credentials from a web-based provider and paste them in '~/.aws/credentials' for local testing and administration.
It's saved me an insane amount of time lately.
That said, my second biggest time saver has been saving language reference and library docs to my local drive:
Near-instant rendering, available anytime my computer is powered on, and they still link to the external docs when I have to follow some esoteric link.
I use a combination of F# scripts and PowerShell. Anytime I need to do data manipulation, code generation, or anything hard core development related I use F#. I could use PowerShell for this, but I'm more comfortable and feel I have more control with fsx scripts. For all the server related tasks or automated build tasks I use PowerShell. We're a heavy MS shop, and I get that it may not work for everyone, but we leverage so many MS technologies that it just makes sense to go with the flow.
I'm obviously biased (CTO and Co-founder), but I love automation, that's why I'm part of the bitrise team in the first place ;)
The CLI is similar to something like rake, but the config lives in a single file which can be moved anywhere, and you can get a list of available "tasks" (workflows in the bitrise terminology) by running `bitrise workflows` or `bitrise run` without any parameter.
There's also an open source editor (UI) available for it (https://discuss.bitrise.io/t/offline-workflow-editor-workflo...), which is now part of the "base plugins" which gets installed by the Bitrise CLI. It's also really light weight, as the CLI is a single binary distribution (written in Go).
My favorite tool this year has been SaltStack. It manages the entire lifecycle of our VMs now (provisioning and state management) and it was very easy to create a Slack bot with it that can update our production/dev environments.
Salt is a little confusing at first, since it's essentially just a framework for systems management with Python + ZeroMQ, but you can do a lot with it.
I love Salt. Worked with it in a past life, and now use Puppet, because that predated me.
The pillar model and the patterns around it are great. Heira is a terrible substitute, despite kind of following a superficially similar structure.
I also really liked the idea of reactors, but that came to be right around the time I left that gig, so I didn't get to play much with it other than writing some toys.
In general, Salt just feels well architected. Puppet, in comparison, feels like a ramshackle collection of useful things that just don't mesh well. The language design makes me think of Perl without a competent language designer.
I will say that Salt has a higher upfront learning curve. I highly recommend giving yourself enough time to throw out your first attempt at designing anything more than a simple system setup.
I too love salt, but its roots as a remote command execution tool really hinder it in a lot of cases. This is especially true when you try to do something outside the well trod path; such as attempting to verify that commands issued by the salt master were actually initiated by an authorized party.
In the long run, I think I prefer Ansible, if only because it limits how much control any one server has over your infrastructure. Ansible breaks down when you have a lot of servers (thousands), but IMO at that point you really should be working at a slightly higher level of abstraction with VM images and automated scaling groups.
I've tried reading the saltstack doc many times, I still am very confused. To the point that I've stuck to ansible, despite truly thinking saltstacks might be better.
Is there any not confusing doc about saltstack available?
While Salt did great things to our deployment abilities (we didn't really have much prior to it) … it's not a tool I can recommend. It's design in comparable to PHP or MySQL, and I frankly believe someone should write the equivalent of "A Fractal of Bad Design" or "Do Not Pass This Way Again" for it.
1. Salt simply broadcasts commands out to the nodes connected to it. Because it has no concept of who should be connected to it, it cannot compute whether a node is missing, or if that missing node matters. It's test.ping command is just another command, too, so it suffers the same problems rendering it useless as a ping command
1. Salt's CLI will return success on failure.
1. It is not able to parallelize within a node.
It helps to know what a "state" looks like in Salt past here (this is YAML):
a_name: # the name of the state; the name/and mapping value here comprise the state
pkg.installed: # a state function; this installs a package
- arg1: value # args to the function. Yes, it's a list of single-element maps.
- arg2: value
user.present: # another state function
- …
These are effectively steps that salt will execute, typically in the order you define them, with some exceptions: a. you can specify dependencies b. you can specify that things run "first" or "last"
Also, note that this YAML file is templated with Jinja2.
1. You can't create and depend on a "PHONY" target; this means if you want to depend on the result of several states, you're SoL. You can just inline the set of states that you need, everywhere you need them, which is bad, or you can use a temporary file on disk, which is a hack.
1. Attempting to write code (which, really, is what SLS is) in YAML is crazy. (You can actually write these in at least 4 different languages! All Salt needs is a JSON-like structure.)
1. It is not able to pass information between "states" (a "state" in salt is a task in the grand list of stuff it needs to execute).
1. The error reporting leaves much to be desired. If you make a mistake in a YAML file, you can easily receive back errors with wrong line numbers, wrong file names, quoting the wrong part of the file.
1. At least when we used it, there was no way to properly escape inputs to the YAML file. (This might have been fixed; I honestly can't remember. At some point, it was "fixed", but not really, because the fix didn't work for any practical purpose.)
1. The minions would just "crash", and by crash, I mean, just stop responding. Since its not an outright crash
1. Bug reports were generally met with "you're not using the latest version, please upgrade"; generally, I'm understanding of this attitude, as it takes some work to determine if a bug being experienced in an old version is still present in a new version. Salt's architecture made upgrading nigh-impossible: minions/servers of different versions weren't compatible; DNS couldn't be used to switch minions over in some of our hair-brained ideas to gradually upgrade as the minions would cache DNS results indefinitely.
1. Minions would reconnect automatically; for whatever reason, reconnecting took a considerable toll on the server. If you hit the point where there were too many minions talking to the server, the fleet as a whole would go into a death spiral: too many minions attempting to connect causes an already connected one to miss a keepalive ping, and reconnect. Now you have yet another minion attempting to reconnect, and the problem is worse. More and more minions start doing this, and you're hosed. We had to restart the entire fleet of minions (by hand, b/c our manner of running a distributed command on the fleet was salt) multiple times.
1. Salt in some places, such as templating a file on a minion, needs to reference a file on the server. A relative path would have sufficed wonderfully, but instead Salt uses "salt: URLs". a. they're not URLs, and b. they MUST be absolute. This means that if you move a subtree of stuff (such as for refactoring), you're forced to adjust these URLs. Thankfully, they're easily greppable.
For anyone using Mac OS X, I highly recommend setting up a keyboard shortcut for the text-to-speech tool. See [1] for instructions and screenshots.
The computer voice is not too annoying, and it can read news articles and blog posts to you, rather than wasting your eyes. I often do the dishes or exercise while the computer reads hacker news to me.
The text-to-speech tool is also very useful to proofread any text you might be writing—I catch a lot of typos this way.
An answer for the less technical crowd: Zapier. It allows me to tie all of my favorite tools together. Those that do not integrate natively can be accessed via API if you want to put the time into it.
Heck, this is great for technical people too. There's the public integrations, but I use the dev platform for private things all the time. Takes some extra coding, but once the interface is built everything else comes free. That plus code steps and I'm set.
Terraform! Watching infrastructure being created and configured in seconds on AWS (or even openstack) is amazing. Preferably paired with something like chef or ansible.
All of the automation tools out there always felt clunky to me. Ansible has been working fairly OK so far for my usage, but I can't imagine using it if I was managing hundreds of machines.
I considered using saltstack, but despite spending a few hours reading their doc, I'm still very confused by all the lingo.
I recently started reading and considered using NixOS, but the still relative newness (it's 14 years old!) makes me worry about missing packages and updates.
I felt the same way about Saltstack. I've worked at shops that use Puppet (with and without Hiera) and CFEngine. In my person projects I've used a lot of Ansible.
Out of all the CM systems I've tried Ansible feels the most sane. It still has a some things that annoy me, but overall I've found it the easiest to deal with.
My current shop puts everything in Docker containers and runs them on DC/OS scheduled via Marathon. I don't touch the CM parts anymore, but I think our DC/OS team provisions the actual nodes via Puppet.
Ansible is basically my favourite automation tool, though I use it less to "save time" and more for peace of mind. I can define how I want my servers set up and ensure that every time I spin up a new one or make a deploy, all the proper steps are followed automatically.
Though technically, this can save time in tracking down errors or weird state-based bugs, I guess? So it even still qualifies under that.
This might be a bit on the noob side but I always feel like a boss when I get a complicated project set up to be built and deployed with one double-click or keystroke. Even though it's just knowing how to use MSBUILD/NAnt/Ant/make and robocopy/cp, it's still satisfying.
I get a lot of lift out of ndjson-cli (though jq is a lot more popular) for command-line JSON manipulation. I've found it incredibly powerful for scripting and piping with web/RESTful services.
[+] [-] clarkenheim|9 years ago|reply
[+] [-] arise|9 years ago|reply
[+] [-] sillysaurus3|9 years ago|reply
[+] [-] kodfodrasz|9 years ago|reply
The ones with enough experience to hate thoroughly so far are:
- bash
- powershell
- windows cmd/batch
- ansible
- terraform
- azure clis, azure powershell api
- aws python api, cli
- Jenkins
- MS Team Foundation Services
- Docker (one of the nastiest ones)
- Rancher
I always managed to solve the tasks with the tools at hand (one of these), but all have so many weak points one must always work around, that I cannot say any single one made me feel like a boss when I had to use them for any non-trivial task.
If you want to feel like a boss, be a boss!
[+] [-] oneplane|9 years ago|reply
[+] [-] valbaca|9 years ago|reply
- Workspaces! These help with focus and isolate the "blast radius" of getting randomized
- Spectacles: windows manager to assign windows to left/right side of screeen, across monitors, or left, middle or right 1/3
- CopyClip: I don't use this clipboard manager all the time, but when I do, it SAVES MY BUTT
- Sublime: speaking of saving my butt...Sublime has never once lost a single file. I love Vim but Sublime has flawless reliability
- Cmd+0: Global hotkey to "new browser window" If you do something 20+ times a day, make it super stupid fast (I know it conflicts with "reset zoom" but I can just manually adjust zoom back to 100%)
- Shell scripts: If I'm typing more than 3+ commands over and over again, just script it. Scripting isn't scary and more developers need to be doing it. (I seem to be the only one on my team, which is why I say that)
[+] [-] natecavanaugh|9 years ago|reply
It's so powerful, there's very little it can't do.
[1]: https://www.keyboardmaestro.com
[+] [-] neurocroc|9 years ago|reply
[+] [-] gargravarr|9 years ago|reply
This and Powershell, which although its syntax is mind-bending and in some cases just outright appalling, is a decent attempt at a scripting language with exceptional power over Windows.
[+] [-] strictfp|9 years ago|reply
[+] [-] Psilidae|9 years ago|reply
[+] [-] autotune|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] dangirsh|9 years ago|reply
[+] [-] davelnewton|9 years ago|reply
I'm not even sure if Emacs will hold up to tools like IntelliJ for Ruby/Rails/JavaScript development at this point, although in that space it's a lot closer.
Overall, however, I agree: Emacs is freakin' awesome. Heck, I booted into it as my shell for a few years. I keep meaning to get back into it but I rarely have the time, and I need to learn more Vim as well. Time is the enemy.
[+] [-] girzel|9 years ago|reply
It's a little embarrassing how much I do through emacs: manipulating the file system, url fetching, RPC... stuff you really shouldn't be doing with your text editor. But hey, the tool you know...
[+] [-] falcolas|9 years ago|reply
It's saved me an insane amount of time lately.
That said, my second biggest time saver has been saving language reference and library docs to my local drive:
Near-instant rendering, available anytime my computer is powered on, and they still link to the external docs when I have to follow some esoteric link.[+] [-] kemiller2002|9 years ago|reply
[+] [-] viktorbenei|9 years ago|reply
I'm obviously biased (CTO and Co-founder), but I love automation, that's why I'm part of the bitrise team in the first place ;)
The CLI is similar to something like rake, but the config lives in a single file which can be moved anywhere, and you can get a list of available "tasks" (workflows in the bitrise terminology) by running `bitrise workflows` or `bitrise run` without any parameter.
There's also an open source editor (UI) available for it (https://discuss.bitrise.io/t/offline-workflow-editor-workflo...), which is now part of the "base plugins" which gets installed by the Bitrise CLI. It's also really light weight, as the CLI is a single binary distribution (written in Go).
[+] [-] tapoxi|9 years ago|reply
Salt is a little confusing at first, since it's essentially just a framework for systems management with Python + ZeroMQ, but you can do a lot with it.
[+] [-] _jal|9 years ago|reply
The pillar model and the patterns around it are great. Heira is a terrible substitute, despite kind of following a superficially similar structure.
I also really liked the idea of reactors, but that came to be right around the time I left that gig, so I didn't get to play much with it other than writing some toys.
In general, Salt just feels well architected. Puppet, in comparison, feels like a ramshackle collection of useful things that just don't mesh well. The language design makes me think of Perl without a competent language designer.
I will say that Salt has a higher upfront learning curve. I highly recommend giving yourself enough time to throw out your first attempt at designing anything more than a simple system setup.
[+] [-] falcolas|9 years ago|reply
In the long run, I think I prefer Ansible, if only because it limits how much control any one server has over your infrastructure. Ansible breaks down when you have a lot of servers (thousands), but IMO at that point you really should be working at a slightly higher level of abstraction with VM images and automated scaling groups.
[+] [-] gouggoug|9 years ago|reply
Is there any not confusing doc about saltstack available?
[+] [-] deathanatos|9 years ago|reply
1. Salt simply broadcasts commands out to the nodes connected to it. Because it has no concept of who should be connected to it, it cannot compute whether a node is missing, or if that missing node matters. It's test.ping command is just another command, too, so it suffers the same problems rendering it useless as a ping command
1. Salt's CLI will return success on failure.
1. It is not able to parallelize within a node.
It helps to know what a "state" looks like in Salt past here (this is YAML):
These are effectively steps that salt will execute, typically in the order you define them, with some exceptions: a. you can specify dependencies b. you can specify that things run "first" or "last"Also, note that this YAML file is templated with Jinja2.
1. You can't create and depend on a "PHONY" target; this means if you want to depend on the result of several states, you're SoL. You can just inline the set of states that you need, everywhere you need them, which is bad, or you can use a temporary file on disk, which is a hack.
1. Attempting to write code (which, really, is what SLS is) in YAML is crazy. (You can actually write these in at least 4 different languages! All Salt needs is a JSON-like structure.)
1. It is not able to pass information between "states" (a "state" in salt is a task in the grand list of stuff it needs to execute).
1. The error reporting leaves much to be desired. If you make a mistake in a YAML file, you can easily receive back errors with wrong line numbers, wrong file names, quoting the wrong part of the file.
1. At least when we used it, there was no way to properly escape inputs to the YAML file. (This might have been fixed; I honestly can't remember. At some point, it was "fixed", but not really, because the fix didn't work for any practical purpose.)
1. The minions would just "crash", and by crash, I mean, just stop responding. Since its not an outright crash
1. Bug reports were generally met with "you're not using the latest version, please upgrade"; generally, I'm understanding of this attitude, as it takes some work to determine if a bug being experienced in an old version is still present in a new version. Salt's architecture made upgrading nigh-impossible: minions/servers of different versions weren't compatible; DNS couldn't be used to switch minions over in some of our hair-brained ideas to gradually upgrade as the minions would cache DNS results indefinitely.
1. Minions would reconnect automatically; for whatever reason, reconnecting took a considerable toll on the server. If you hit the point where there were too many minions talking to the server, the fleet as a whole would go into a death spiral: too many minions attempting to connect causes an already connected one to miss a keepalive ping, and reconnect. Now you have yet another minion attempting to reconnect, and the problem is worse. More and more minions start doing this, and you're hosed. We had to restart the entire fleet of minions (by hand, b/c our manner of running a distributed command on the fleet was salt) multiple times.
1. Salt in some places, such as templating a file on a minion, needs to reference a file on the server. A relative path would have sufficed wonderfully, but instead Salt uses "salt: URLs". a. they're not URLs, and b. they MUST be absolute. This means that if you move a subtree of stuff (such as for refactoring), you're forced to adjust these URLs. Thankfully, they're easily greppable.
[+] [-] ivansavz|9 years ago|reply
The computer voice is not too annoying, and it can read news articles and blog posts to you, rather than wasting your eyes. I often do the dishes or exercise while the computer reads hacker news to me.
The text-to-speech tool is also very useful to proofread any text you might be writing—I catch a lot of typos this way.
[1] https://docs.google.com/document/d/1mApa60zJA8rgEm6T6GF0yIem...
[+] [-] mercwear|9 years ago|reply
[+] [-] Xavdidtheshadow|9 years ago|reply
[+] [-] falsedan|9 years ago|reply
[+] [-] outworlder|9 years ago|reply
[+] [-] hamilyon2|9 years ago|reply
[+] [-] gouggoug|9 years ago|reply
I considered using saltstack, but despite spending a few hours reading their doc, I'm still very confused by all the lingo.
I recently started reading and considered using NixOS, but the still relative newness (it's 14 years old!) makes me worry about missing packages and updates.
[+] [-] djsumdog|9 years ago|reply
Out of all the CM systems I've tried Ansible feels the most sane. It still has a some things that annoy me, but overall I've found it the easiest to deal with.
My current shop puts everything in Docker containers and runs them on DC/OS scheduled via Marathon. I don't touch the CM parts anymore, but I think our DC/OS team provisions the actual nodes via Puppet.
[+] [-] DanHulton|9 years ago|reply
Though technically, this can save time in tracking down errors or weird state-based bugs, I guess? So it even still qualifies under that.
[+] [-] cristobal23|9 years ago|reply
[+] [-] rdiddly|9 years ago|reply
[+] [-] purple-dragon|9 years ago|reply