HackerTrans
トップ新着トレンドコメント過去質問紹介求人

G1N

no profile record

コメント

G1N
·昨年·議論
No support for arm64 unfortunately :( OP, I tried installing via rosetta on macOS arm:

   arch -x86_64 sh -c "$(curl -fsSL https://raw.githubusercontent.com/ezpieco/gethooky/master/tools/install.sh)"
And I get the following error:

   mv: fastcopy: open() failed (to): /usr/bin/hooky: Operation not permitted
I curl'd and installed the x86 version manually into my ~/.zsh_scripts folder to get past this; I think for darwin clients you need to install to /usr/local/bin to get past perms errors (maybe just for arm macs?).
G1N
·昨年·議論
Been looking for something like git machete for the longest time, thanks for sharing!
G1N
·昨年·議論
This is a really cool app! I wish you would also put your pricing information on the website (as far as I can tell the only way to discover this without downloading the app is by looking at the in-app purchases section on the App Store listing, apologies if I missed it on the website)
G1N
·昨年·議論
I think OP might have meant something closer to neumorphic/ claymorphic design?
G1N
·昨年·議論
Man (capital M) is probably being interpreted as some proper noun, maybe Isle of Man in this case?
G1N
·昨年·議論
twelve-ten+five=

six (84%)

Close enough I suppose
G1N
·昨年·議論
The "Features" and "Community" links don't navigate/ scroll anywhere for me. Using Chrome 133 arm64 on macOS.

As an aside, is it just me or do a lot of these new project management apps coopt Linear's style? Not saying that this is completely derivative, the website just gave me those vibes (and I won't sign up to try out the demo so maybe some screenshots on the front page would be nice :P)
G1N
·昨年·議論
Seems like Python support is up next for this project: https://github.com/anistark/feluda/pull/18
G1N
·昨年·議論
Would you be open to a PR adding support for installing from npm? Not sure if you guys are willing/ comfortable to publish there as well, but did notice you already have Node support for scanning
G1N
·昨年·議論
They're saying PRs and issues but I can't access github.com or github oauth for logging into external services. Need to migrate our org off of using github auth for anything critical I think, this is twice so far this year that we've had these issues.
G1N
·昨年·議論
Was trying to install homebrew on a device and kept wtfing because the clone step kept failing… thought I was crazy
G1N
·2 年前·議論
happy new year HN :)
G1N
·2 年前·議論
Very different from everyone here I think, but we’re currently running into weird artifact eviction issues in our GitHub actions pipelines ( our fault for using GitHub CI, I’m aware lol). We’ve set up some CLI tools to help with this (basically scanning artifacts and freeing on some LRU basis), but I’d really like some tool that lets me view artifact creation stats across an entire GitHub org to figure out which teams’ actions need to be throttled. Not sure if that’s in scope at all for your project but throwing it out there nonetheless
G1N
·2 年前·議論
Had an old roommate who moved here after getting married to be closer to family. Weirdly, the name never at any point came up so I think everyone is just kind of resigned to the fact that they live in a place called Cumming
G1N
·2 年前·議論
Very informative, thank you!
G1N
·2 年前·議論
Former guy who used to reverse engineer Venmo/ other fintech/ bank APIs here. They really don’t care most of the time
G1N
·2 年前·議論
Based on the other replies here it seems like it's to differentiate taps vs mouse clicks, keyboard events in js don't have a screenX or screenY property (you can run this in your browser console on this HN post to confirm):

  (() => {
    const logEvent = event => console.log({
      coords: [event.screenX, event.screenY],
      type: event.type
    });
    const input = document.querySelector("textarea");
    // use "keydown" instead of "keypress" to detect all keyboard input instead of just character producing input 
    input.addEventListener("keydown", logEvent);
    input.addEventListener("click", logEvent);
  })();
Type in or click on the reply text input and you'll see that the coords array is undefined for all keyboard events. I haven't tried this equivalent on a touch device however, so not sure how it's handled there.
G1N
·2 年前·議論
RE this line of code at the bottom of the article:

  const isInvokedByMouse = event =>
  event.type === 'click' && (event.screenX !== 0 || event.screenY !== 0);
Why do you even have to check if screenX and screenY are non-zero (as opposed to just checking typeof event.screenX == "number")? Wouldn't that mean (and this is a wild edge-case) that if someone positioned their browser window so that the menu was in the top left corner (at position 0,0) the event handler would break again? Is this to block synthetic click events like (<div />).click()? Keyboard events don't have a screenX or screenY from what I remember as well.
G1N
·2 年前·議論
Of course not. While some development acceleration might be expected, at best you'll get some multiple that is representative of the overall quality and experience of the devs you work with.

Copilot has definitely helped me speed up via not having to type a lot of boilerplate and line completion, but I'd say that would be at most ~50% speed up when it comes to greenfield development and half that when it comes to maintenance work (and even these figures are probably generous). A 4x speed up sounds ridiculous; expectations like this are how your codebases get filled with GPT generated garbage that is connected together with GPT generated glue and then wrapped with GPT duct tape and a bow
G1N
·2 年前·議論
> Copy-paste is OK once. The second time you're introducing duplication (i.e., three copies), don't. You should have enough data points to create a good enough abstraction. The risk of diverging implementations of the same thing is too high at this point, and consolidation is needed. It's better to have some wonky parameterization than it is to have multiple implementations of nearly the same thing. Improving the parameters will be easier than to consolidate four different implementations if this situation comes up again.

The more I do this software engineering thing the more I feel like this “advice” bites me in the butt. Understanding when you should duplicate code versus when you should consolidate (or if you should just write a TODO saying “determine if this should be split up by [some set in stone timeline]”) is simply just a HARD problem (sometimes at least), and we should treat it as such.

DRY/ WET or whatever shouldn’t be a maxim (let alone a habit! lol), it should at best be a hand-wavey 2-bit dismissal you give an annoyingly persistent junior software dev who you don’t want to actually help!