• 1 Post
  • 47 Comments
Joined 1 year ago
cake
Cake day: July 4th, 2023

help-circle
  • All the electronics inside are very much capable of combustion.

    Your power supply inside the printer body for example can very much fail and burst into flames.

    And tbh it’s not that uncommon for that to happen with 3d printers. They’re often made with very cheap parts and prone to cheap work on the inside bits.

    Add on how much of a high wattage load they meed to handle for extended periods of time and yeah, sometimes the inner wiring bursts into flames and the whole thing goes up.

    I always recommend keeping a cheap lil smoke alarm directly overhead any 3d printer, seriously. Those fuckers can very much spontaneously burst into flames lol



  • Sometimes its a physical issue in your setup.

    Double check your cable, double check the carriage, and double check the rails, look for potential obstructions.

    I had one print that kept failing in the exact same place each time, couldn’t figure it out, then I watched it live and the dang ribbon itself was physically catching on a specific part of the geometry mid print and then the print would twist a bit, lol.

    Something to consider, I’d recommend visually watching that specific layer when it’s coming up to see if you see something happen.




  • Yup, I usually have it set to the slowest setting when typing.

    I find I work much better and can think clearer while walking, as it keeps the blood flowing and makes me feel more awake and engaged.

    If I have a tough problem I’m trying to work through I turn the speed up to a faster pace and sorta just work through it in my head while speed walking, often this helps a lot!

    During meetings when I’m bored I also turn the speed up a bit.

    I often get around 10k to 12k steps in a day now.

    Note I don’t stay on the treadmill all day long, I usually clock a good 4 hours on it though.

    Then I take a break and chill on the couch with my work laptop, usually I leave my more “chill” tasks like writing my tests for this part, and throw on some Netflix while I churn all my tests out.

    Highly recommend it, I’ve lost a good 15ish lbs now in the past year since I started doing it, and I just generally feel a lot better, less depressed, less anxious :)


  • I have heard of jupyter but am not familiar with its nuances.

    But doing python dev with neovim is very doable, it uses the same LSP I think.

    I personally have a dedicated dev machine running debian that has everything on it, including nvim configured.

    I SSH into my dev box from other machines to do work, because neovim is a TUI it “just works” over SSH inside the terminal itself, which is what I like about it.

    It feels good to just

    1. SSH into my box
    2. tmuxinator my-project-name

    And boom, 4 tmux tabs pop open ready to go in the terminal:

    • nvim (pointing at the project dir)
    • lazygit already open
    • nvim (pointing at my secrets.json file elsewhere)
    • an extra general console window opened to project root

    And I can just deep dive into working asap in just those 2 steps, it feels very smooth.

    I often can even just do tmux a (short for attach) to just straight re-open whatever session I last had open in tmux, instantly jumping right back into where I left off.


  • I try and start using it for basic tasks, like note taking, to get used to its interface and basic commands like :w and :q, as well as switching between insert and cmd mode.

    Once you are familiar with switching between modes, copying, pasting, etc, then you probably will wanna Starr learning it’s lua api and how to load in some QoL plugins. Basic stuff like treesitter, telescope, and nvim-tree are good places to start.

    Once you feel comfortable with swapping between files with telescope and configuring plugins, I’d deep dive into getting an LSP up and running for your language of choice so you can actually code.

    In the interim I’d recommend getting comfy with using tmux in your terminal, try and open new tmux tabs to do units of work instead of constantly cding around.

    I like to keep 4 tmux tabs open for a project:

    • nvim
    • lazygit
    • secrets file open in nvim (usually my secrets file is in another dir so it doesn’t check into git)
    • a general terminal tab for running commands

  • From my experience the only big changes I’d say I made overtime are:

    1. Font size bumped up

    2. Switched to neovim from visual studio, which took like a year to relearn my entire workflow (100% worth it though)

    3. Switched from multiscreen setup to one single big screen (largely due to #2 above no longer needing a second screen, tmux+harpoon+telescope+fzf goes brrrr)

    4. Switched to a standing desk with a treadmill, because I became able to afford a larger living space where I can fit such a setup.

    If I were to do this meme though it’d mostly be #1, there just came a day when I had to pop open my settings and ++ the font size a couple times, that’s how I knew I was getting old.



  • You can’t “invoke logic via HTML attributes,”

    Oh boy a semantic argument

    Proceeds to describe how you can use HTMX to invoke logic via HTML attributes

    Whatever you want to call it, trigger, invoke, whatever.

    You can leverage HTML attributes to automatically cause arbitrary Javascript ajax calls to happen by extension if those attributes being present.

    Trying to argue the semantics of this is stupid.

    You put HTML attributes on shit, and the presence of those attributes in turn causes arbitrary Javascript client side logic to fire off purely due to the presence of those attributes.

    That’s like, literally it’s entire shtick.

    And any web dev who remotely understands the point of CSP and why it was created, should instantly have alarm bells going off at the concept of triggering arbitrary ajax via html attributes.

    “HTMX doesn’t bypass CSP! It just (proceeds to describe the exact mechanism by which it bypasses CSP)”

    It’s bonkers how many people don’t grok this, SMH.


  • I see you don’t understand what the word “if” means, and you also don’t understand modern js practices.

    That’s like saying you “serve React client side” and “transpile JavaScript into more JavaScript.” Jesus, I feel like I’m taking crazy pills.

    You don’t serve react client side, any junior dev is familiar with transpiling framework code to produce their website. Yes, you 100% transpile react code before serving it, the fact you dont understand what I am talking about speaks volumes. It’s clear this whole time I’ve been having a discussion with someone who doesn’t even know the absolute bare minimum of day 1 front end dev. If you don’t understand how literally normal and industry standard something as basic as transpiling js is, you have literally zero business spreading info about something far more serious as HTMX.

    You are in zero way qualified to be recommending anyone expose their websites to the security nightmare that is HTMX, stop spreading misinfo, stop encouraging devs to do so.ething stupid, and go learn the basics of FE dev practices.

    If you don’t understand the tools of the trade, stop spreading terrible info about them online.

    Everything you have written in this entire thread has made everyone who has read it stupider and you have actively made the internet a worse place. You are a prime example of the exact thing that is wrong with web devs nowadays.

    Go back to the drawing board, you have a LOT to learn still it sounds like.


  • I prefer just writing my html, js, css, as is, and then transpiling to pack it down, treeshake, hash, cache bust, CSP, etc etc.

    The amount if headache, overhead, inversion of control, mess, and bloat involved in frameworks tends to make me spend way too much time on writing boilerplate.

    template and slot exist now, and modern js can do most of the shit fancy libs used to.

    There’s very little need for frameworks unless you meed a SUPER dynamic website that has tonnes of mutability.

    The amount if times i see people load in like 3 frameworks and 10mb of bullshit and ten js files to make a fucking static form that doesn’t even do anything fancy is insane.

    Just fucking write the like… 8 lines of normal code to populate the form, wtf? Why are we using routers at all, HTTP already exists and does that, why did we re-invent http?

    Front-end devs need to spend less time installing npm packages to try and magically solve their issues and just learn how to actually write code, SMH.


  • pixxelkick@lemmy.worldtoProgrammer Humor@lemmy.mlSingle-Page Application
    link
    fedilink
    arrow-up
    1
    arrow-down
    1
    ·
    edit-2
    5 months ago

    Just to be clear, are you talking about some kind of templating library that literally transpiles all the htmx logic and instead packs it into individual ajax logic in js files “per element”, such that you don’t need to serve htmx client side and instead you pre-transpile all the ajax logic out to separate files?

    Cause the very start of my statements was that if we had something like that then HTMX would be fine, as a templating lib that transpiled out to html+js.

    That you can CSP lockdown, because now you no longer are able to invoke arbitrary logic with html attributes, only the explicitly transpiled ajax can and all concepts of htmx have been actually removed from the final html+js you actually serve to the client.

    If that is what you are talking about above, then please link me because that sounds awesome and is what HTMX outta be, and would remove all of its security issues.

    If that’s not what you are talking about, and you truly dont understand the fact that you can’t compare an html element that triggers logic (which you can’t CSP block), to a script chunk that performs logic (which you can CSP block), then I think you do indeed need to go read up on and understand what the point if CSP is and why it was implemented in browsers.

    The two are apples and oranges. HTML elements should not be capable of invoking logic arbitrarily, that violates a core principle of html.



  • pixxelkick@lemmy.worldtoProgrammer Humor@lemmy.mlSingle-Page Application
    link
    fedilink
    arrow-up
    1
    arrow-down
    2
    ·
    edit-2
    5 months ago

    That’s not broad enough.

    If you in any way have functionality that handles anything remotely requiring security, do not use HTMX.

    This goes way beyond “parameterized endpoints”.

    Listen extremely closely and pray to God anyone dev with more than 2 brain cells groks how serious th8s vulnerability is:

    HTMX enables arbitrary invocation of ANY api endpoint with cookies included, through html attributes, which inherently can’t be covered by Content Security Policy

    This is deeply important for any web dev worth their salt to understand.

    Sanitizing User input should be your LAST layer of defence against attack vectors. Not, NOT, your first and only

    It’s supposed to be your “break in case of emergency” system, not your primary (and only remaining) defense layer.


  • why you didn’t properly sanitize user input

    This is like someone pointing out that blowing a giant hole in the hull of your ship causes it to take on water, and you respond by asking “well why aren’t you bailing out the water with a bucket?”

    You do understand why Content Security Policy exists, and what it is for… right?

    “We don’t need a watertight ship hull for the voyage, just reinvent and implement a bunch of strapping young lads that 24/7 bail water out of the ship as it sails, it’s faster and more efficient than doing something crazy like building your ship to be secure and water tight.”


  • CSP allows you to whitelist/blacklist arbitrary Javascript, and ideally you completely blacklist online js from being executed at all, such that only .js files of same domain can be invoked by your website.

    This serves the role of locking down injection attacks, only your explicitly approved Javascript can be invoked.

    HTMX enables invoking of logic via HTML attributes on HTML elements… which CSP can’t cover

    Which means you re-open yourself to injection attacks via HTML. Attackers can inject an HTML element with HTMX attributes and no amount of CSP will stop HTMX from going “Okey doke!” And invoking whatever the attributes say to do.

    This effectively shoots even a completely locked down CSP config square in the nuts, totally defeating the entire point of using it.

    It’s a cute idea but what is needed is a way to pre-emptively treat HTMX as a template file that transpiles everything out so the ajax happens in a separate .js file

    If we had that, then it’d be safe and secure, as the whole “htmx attributes on elements” thing would just be a templating syntax, but when transpiled it wouldn’t be supported anymore so attackers can no longer inject html as an attack vector



  • pixxelkick@lemmy.worldtoProgrammer Humor@lemmy.mlSingle-Page Application
    link
    fedilink
    arrow-up
    2
    arrow-down
    9
    ·
    edit-2
    5 months ago

    Unfortunately it also kicks Content Security Policy square in the nuts and shoots a giant hole right through your website security, so if anyone on my team brings up using it I inform them it’s an instant security fail if we so much as touch it.

    It’s a cute idea but horribly implemented. If your website has any security requirements, do not use htmx

    Edit: the fact so many people have no idea about this and are downvoting is sad. People need to learn how CSP headers work, and why inherently HTMX completely bypasses this as it currently is designed.