Live data from Hacker News

In Praise of AutoHotKey

hillelwayne.com

101–110 of 220 posts

Re: In Praise of AutoHotKey

#101

Earlier quoted context omitted.

It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was t…

You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy to save people an enormous amount of work. "No" is the easiest, safest call possible, not a hard call at all. People like him should be shamed.

"Shamed", come on. You don't ask the guy in charge of maintenance to validate new tools. That person's job revolves around stability, and they will always make the safest possible call.

If a new tool is needed, a steering committee of some kind should be used, and IT will be one part of that.

Re: In Praise of AutoHotKey

#102

Earlier quoted context omitted.

You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy to save people an enormous amount of work. "No" is the easiest, safest call possible, not a hard call at all. People like him should be shamed.

"Shamed", come on. You don't ask the guy in charge of maintenance to validate new tools. That person's job revolves around stability, and they will always make the safest possible call. If a new tool is needed, a steering committee of some kind should be used, and IT will be one part of that.

Where I work, IT in general has little say about what tool I use on my PC. They do periodic scans to check that I don't have any known unsafe tools, or tools that are known not to be OK without a formal license. But otherwise, as long as I'm not violating a license and not circumventing my virus scanner, I can use whatever tool I want.

Work would come to a crawl if IT had to validate every single tool used in our company. The notion that this is within IT's scope is flawed. It's the equivalent of asking a government agency to vet every single product that is produced by any company for consumer safety in the whole of the United States, and then rejecting most of them because of the lack of resources to thoroughly vet them.

Re: In Praise of AutoHotKey

#103
I thought AutoHotKey was for automatically assigning simple actions to keys. I was so wrong.

I started playing Path of Exile a while ago and soon found PoE Trade Macro (https://github.com/PoE-TradeMacro/POE-TradeMacro) which allows you to mouse over items, hit a hotkey to send a web API request to a trade site, pops up an overlay with a pricing summary, lets you adjust certain parameters and search again, and so much more. All allowed by the game in case you're wondering, they encourage it.

There's a YT video in the link above showing just some of the features. And I'm pretty sure newer overlays are even more impressive (I haven't checked them out). AHK is far more developed and complex than I gave it credit for.

Re: In Praise of AutoHotKey

#104
post #6

I recently wrote a script that I call with Meta+F, assigned via a Linux Mint keyboard shortcut. It will open Firefox, or focus it if it's already open. Multiple presses will cycle through open instances. Meta+T does the same for terminals. It's like a focused version of Alt+Tabbing through programs.

For this kind of automation, I use pyautogui, but recently I made a kind of front end for that https://github.com/rmpr/atbswp

Re: In Praise of AutoHotKey

#105
post #46

I remember back in 2005-2007, using AHK to make data entry way more efficient, at a few different companies. It's also great for macros in video games.

> It's also great for macros in video games.

I found it tedious to write long macros manually, so I wrote my own tool https://github.com/rmpr/atbswp, for fine grain control AHK is very good, but for quick and dirty things I rely on atbswp.

Re: In Praise of AutoHotKey

#106
post #80

Earlier quoted context omitted.

Karabiner Elements is really popular for this use case. I have Caps set to be escape when pressed and Hyper in conjunction with pressing another key.

The downside is Karabiner Elements requires installing a kext, and macOS Catalina periodically shows warnings saying the kext is a legacy extension.

Man as someone who has been putting off the upgrade that's too bad, I figured their solution of creating kind of a virtual keyboard input would be pretty solid going forward.

Does Hammerspoon work just as well? Karabiner is so incredibly solid.

Re: In Praise of AutoHotKey

#107
This software got me through a really rough hurdle in my earlier years. Had to automate data capture from an accelerometer on a Windows machine. You could only initiate the intended capture from a UI, so automating this for an assembly line testing jig was going to be a real hassle if not for AHK.

Remarkable piece of software. Wish something like that was for *nix.

Re: In Praise of AutoHotKey

#108
post #3

On macOS a similar tool is Keyboard Maestro ( https://www.keyboardmaestro.com/main/ ). I made over 1400+ macros in it over time that automate practically everything for me now. https://wiki.nikitavoloboev.xyz/macos/macos-apps/keyboard-ma...

I'm not quite at 1400 (yet!) but I truly depend on it... a fresh install of macOS feels broken without it. Even better when combined with Karabiner, as you too suggest.

PS: great site!

Re: In Praise of AutoHotKey

#109
post #99

Earlier quoted context omitted.

It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was t…

> It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. Once again, if I wrote my own Python script they would not be involved, and my Python script is as error prone as using AHK. Think of AHK as similar to a compiler + linker. By rejecting AHK because someone can write a program that could screw things up, you might as well…

Okay but if you have an organization whose lead of IT isn't capable of verifying some automation - be it AHK or Python or VisualBasic or F# or haskell or whatever - then it's fine for them to say 'no'. You can go over their head, and that's also okay. Or ask them to bring in someone who's an expert in the technology you're using.

> You've essentially argued that IT should oppose any automation that is not thoroughly tested. And how will they determine how well it is tested? Do they have those skills?

In large scale, business critical applications? Yes. All everything should be thoroughly tested and/or canaried, with several levels of validation before production releases.

> You're merely pointing out that this IT person has been given more power than his skills warrant.

I think I'm pointing out that his job is to be a safeguard against rogue wanna-be programmers whose ability to destroy things far outstrips their ability to test for things (or even think about edge cases). If that's true, they've done a fantastic job.

Re: In Praise of AutoHotKey

#110

Earlier quoted context omitted.

It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was t…

You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy to save people an enormous amount of work. "No" is the easiest, safest call possible, not a hard call at all. People like him should be shamed.

Spoken like someone who's never caused a prod outage at a real company, I guess. I'd say that - outside of some startup or small company that has few (or no?) users - the cautious approach is right. The IT guy knew that he was a podunk pissant warden of a very, very small portion of very, very large organization (an org of a few hundred people is basically nothing compared to the vastness of many oil companies) and that the value that his org provided was compromised by this automated approach, without knowing how to mitigate that compromise. He made the right call, assuming he was just there as a bulwark against exactly this.
Post reply on HN