ByteCode.News
RSS
SubmitLog in

Community

Chat Logs

Monday, May 18, 2026

  1. deebolooks like the guy left but for anyone else, use a platform jdbc wrapper, e.g. AWS has their own that works for rds/aurora and can do faster failover and r/w splitting etc funky stuff
  2. NeXeNdid they, well such a shame
  3. enoqlooking at the npm madness, how do you usually handle API tokens required to publish github releases or access APIs? right now I've got those as env variables which is probably not a good idea
  4. enoqspecifically looking at gradle tasks right now
  5. Shellthey should not be in your environment or accessible to you until you are publishing those releases or accessing those APIs. stick them in a password vault.
  6. enoqand then just read them from stdin?
  7. enoqI've got a bunch of those that I need for a release task
  8. enoqthe alternative ofc would be to read them from an encrypted json file, but I'm not sure if there's something that's commonly used here
  9. deebowe just read stuff from aws secretsmanager as needed
  10. dreamrealI just put it straight in the CI/CD scripts, saves a lot of time
  11. dreamreal"wanna know where the secret is? Just look in the workflow, it's right there, easy peasy"
  12. dreamreal"and no, we're not sure why our releases are riddled with holes and exploits, why do you ask?"
  13. dreamreal"Come to think of it, every time we release, there's a whole bunch of followup releases. Weird, right?"
  14. Inlinecakenet
  15. dreamrealI actually HAVE been wondering why we started embedding openclaw
  16. Inlinethe friendly spies patching further......
  17. Inlinelol
  18. enoqyou are joking, but this is sort of what's happening
  19. dreamrealThat's what makes it funny
  20. dreamrealvery ha ha only serious
  21. cheeserthis is what github secrets are for.
  22. dreamrealbut do we trust THOSE these days
  23. cheesermostly, yeah. yolo and all that.
  24. dreamrealI protect all of my users' secrets by not having users
  25. dreamrealproblem SOLVED.
  26. cheeserthat's the most secure way, really. you can't leak any PII if you don't have any P to I.
  27. enoqlet's say you want to read a text file by passing an input stream, you use a try with resources outside of the method; but what if you pass that stream to an InputStreamReader inside of the file and want to keep the input stream open?
  28. enoqdo you force the method signature to pass an InputStreamReader instead and require the caller to pass that instead of the InputStream?
  29. dreamrealyou want the inputstreamreader open even after you consume it?
  30. dreamrealThis sounds vaguely broken
  31. enoqI want to return a Stream<TextLine>
  32. dreamrealright. So why is it still open when you're out of the block?
  33. enoqso if you close the input stream in the method, the Stream will have a closed input stream when it is being evaluated
  34. enoqhm, gonna whip up some code to demonstrate the problem, one sec
  35. dreamrealSo it sounds like you're actually doing a mapping: you have an inputstream, you want a stream of lines, and the block form is wrong
  36. enoqright, basically trying to figure out how to design the API so I can pass an InputStream and not leak file descriptors
  37. enoqgutt feeling is that the input stream needs a try with resources outside the parse method
  38. dreamrealyou're about to enter callback hell, probably. So how large are these inputstreams?
  39. enoqI definitely could load them into RAM, more interested in how the streaming solution would be done though
  40. dreamrealyou'd leak the handle, speaking literally, by returning something that pulled the data reactively
  41. dreamrealit's a gross model
  42. enoqis there a better way to do that?
  43. dreamrealdepends on the input! Me, I'd return a List<String> personally, unless the input's large or the stream is, well, streamed
  44. dreamreala Flux<String> is an alternative, and it's very efficient, but you'll hate yourself and whoever decided to make you use that, which might mean you hate yourself twice as much, and you'll deserve it
  45. enoqright, what if the input is too large to hold in memory?
  46. dreamrealthen a visitor pattern is your friend, or that flux thing and self-hatred
  47. enoqthat's RxJava, right?
  48. dreamrealFWIW: I do get to deal with this
  49. dreamrealamong others
  50. dreamrealdo you have to deal with context? Like, do the lines relate to each other?
  51. enoqno, I just have to split them based on a marker
  52. dreamrealthen it's easy, visitor is the low-impact version
  53. dreamrealwhat *I* have to do is have a resettinhg stream and parse in blocks, it's great fun
  54. enoqhttps://en.wikipedia.org/wiki/Visitor_pattern this one?
  55. nevetVisitor pattern - Wikipedia
  56. dreamreal(I have expressions that can cross line-endings, possibly MANY line endings, it's great fun)
  57. dreamrealthat's one, yeah
  58. enoqthank you!
  59. dreamrealimagine: void handleInputStream(InputStream is, Visitor visitor) { /* for every line read, call visitor.accept(line); */ }
  60. dreamrealno leakage, generally quite efficient, trivial to test and validate, if visitor has state it can persist outside of the method call, but state still needs to be bounded
  61. dreamrealit's not a *perfect solution with no possible flaws* but it shares that condition with the set of all code
  62. enoqI see, thank you
  63. dreamrealenoq: I don't want to pretend that I am A) the fount of all wisdom (I ain't) and 2) knowledgable about YOUR SPECIFIC INPUTS (I definitely ain't) and D) solving every performance/execution problem from IRC (... I am not)
  64. enoqI know that :)
  65. dreamrealWell, the point is that *I* know that too :D
  66. enoqI'm merely curious what the solutions could be
  67. dreamrealIf you come back in three hours and say "OMG dreamreal you were SO WRONG" I'll shrug and say "sure thing, I wonder why I mentioned caveat emptor..."
  68. dreamrealadvice on IRC tends to be worth every penny you paid for it :D
  69. enoqI'll write an angry letter to Brian Goetz
  70. dreamrealYou should! Make it very stern. Namecheck me and he'll probably laugh at you for it. :D
  71. * [twisti] twitches at A)... 2)... D)
  72. * dreamreal giggles
  73. jbosmansdarnit, opus 4.7 recommends me to use StructuredTaskScope in java 25, despite multiple nudges to double (or triple or ..) check first before responding
  74. jbosmanssorta disappointing
  75. jbosmansi could've been a 10x engineer ^
  76. enoqhm, I thought you shouldn't review AI responses to achieve that 10x speedup
  77. jbosmans:D
  78. jreicherLooks like javabot is dead
  79. NeXeNlooks like my wifi is dead
  80. NeXeNjeeze, every 45 seconds