• 3 Posts
  • 51 Comments
Joined 2 years ago
cake
Cake day: June 11th, 2023

help-circle



  • What’s the nature of the temporary system?

    I would consider; remote/temporary systems are not necessarily mine, or setup is not worth it given my concerns on it; There’s different options to install or configure existing shells, I could take my config with me; if it’s a temporary system maybe it’s based on a template that could be adjusted, or auto-setup scripts could be adjusted

    It would depend on how much I use it, how much I miss my setup, or how irritated I get because of missing stuff, and considerations of whether it’s worth it (to me).

    I’m someone who adjusts their environment to their needs and wants, moreso than other colleagues I see. Many people seem to simply accept existing environments and (to me) annoyances.

    When I remote into servers, it’s not typically where I would use much Nushell functionality. Bash and vim is good enough for those things, with just a little bit of configuration. I don’t plan on installing it on work servers, but have recently thought I may install it on my own server for convenience.







  • No, it doesn’t mean only humans can interact with it.

    The key point [of classical REST] is that responses are self-contained self-describing. Requesting a resource response tells you what actions you can take on it. There is no need for application domain knowledge, implicitly or separately-explicitly shared knowledge.

    Some HTTP web apis offer links in their JSON responses for example. Like previous and next page/ref on paging/sectioning/cursor. Or links to other resources. I don’t think I’ve ever seen possible resource actions/operations be included though. Which is what the original REST would demand.

    That’s how I understood it anyway.

    Their suggestion of using HTML rather than JSON is mainly driven by their htmx approach, which the project and website is about. Throughout this article though, they always leave open which data form is actually used. In your quoted text they say “for example”. In a later example, they show how JSON with hyperlinks could look like. (But then you need knowledge about that generalized meta structure.)





  • Kissaki@programming.devtoGit@programming.devGit Commit Creation
    link
    fedilink
    English
    arrow-up
    3
    ·
    edit-2
    3 months ago

    Given that it is high level, I assume you did not want to include this. I’ll mention it here in a comment either way. Text form in the commit message.

    I really like using conventional commit messages and introduced it in my projects. We defined a few types, and more leniently choose optional scopes. It’s very useful for categorizing and skimming through commit lists, and for generating changelogs/release notes. `fix(account): Use correct hasing xy"

    Consistent imperative form is important to me too. The commit message examples talks about “Summary of changes”, which has no verb, and so, may mislead to a different undesirable form of summarizing changes. (“Change xy” instead of “changed xy” or “[now] does xy [at runtime]” or “did z”.)

    I didn’t fully read it, only skimmed, so excuse me if I missed mentions of the commit message text form. It seems very elaborate otherwise.





  • Damn, that’s a long list. Looks like a lot of work to collect and prepare.

    I was looking for more of an overview of it and selected them from the headlines:

    1. 2014: Completely broken IndexedDB implementation
    2. 2015: 100vh (100% viewport height) means a different thing in mobile Safari to everywhere else
    3. 2016: <body /> with overflow:hidden CSS is scrollable on iOS
    4. 2017: Safari incorrectly blocks localhost as mixed content when accessed from an HTTPS page
    5. 2018: OS 11.2.2 broke WebAssembly
    6. 2018: Safari 11.1 broke MessageChannels
    7. 2019: Audio stops playing when standalone web app is no longer in foreground
    8. 2019: PWA in iOS uses old assets after publishing new servicerWorker/assets
    9. 2020: Add Fullscreen API to iOS (& display fullscreen)
    10. 2021: Safari shipped blob.stream(), crashes with a NULL pointer exception
    11. 2021: Appending an element to the shadow DOM in many cases hard crashes the browser process
    12. 2021: LocalStorage is broken when a page is open in more than one tab
    13. 2021: IndexedDB APIs hangs indefinitely on initial page load
    14. 2021: Fetch request streaming is implemented just enough to pass feature detection, but it doesn’t actually work
    15. 2021: IndexedDB API information leaks
    16. 2023: Notifications API: support for the badge, icon, image and tag options
    17. 2024: On-screen keyboard does not show up for installed web apps (PWAs) when focusing a text input of any kind
    18. 2008: Focus events for non-input elements behave differently in Safari to every other browser
    19. 2012: Using border-image with border-style: none is rendered completely wrong
    20. 2014: WebKit doesn’t calculate padding-top/-bottom: n% correctly
    21. 2014: Pointer events should allow for device-pixel accuracy
    22. 2017: Support for 120Hz requestAnimationFrame
    23. 2018: Some Fetch requests incorrectly completely skip the service worker
    24. 2020: Safari 14 shipped a broken replaceChildren() method, which caused glitches in Construct.
    25. 2020: When leaving current scope of PWA, back button incorrectly reads “Untitled”
    26. 2020: Safe-area-inset-bottom still set when keyboard appears
    27. 2020: Support for background-attachment: local has suddenly completely disappeared
    28. 2021: IntersectionObserver and ResizeObserver fire in incorrect order
    29. 2021: Mousemove events fire when modifier keys are pressed, even if the mouse isn’t moved
    30. 2021: Scrolling in home screen apps incorrectly latches to document
    31. 2022: WebM Opus support is inconsistent in Safari
    32. 2022: Installed web app with viewport-fit cover causes overscroll issues, breaks position fixed and -webkit-fill-available
    33. 2023: iPadOS: Viewport doesn’t correctly restore after dismissing software keyboard for installed web apps
    34. 2023: iPadOS: window loses focus when dismissing the keyboard, breaks Page Lifecycle API
    35. 2024: Svh and lvh are incorrect on iOS in third party browsers
    DOM query
    let a = ''
    for (let x of document.querySelectorAll('h3 a[title]')) a += x.title + "\n"
    a
    



  • If Markdown formatting is enough for you, I would look into using a static site generator, like Hugo or Jekyll.

    If you want to keep your existing content as static files but same website skeleton and layout instead of copying and editing files you’ll copy one and create the layout template. Then content and new posts and pages can be generated from Markdown files. If you set up CI they won’t need to run Hugo or what you’re using, only push the Markdown files to your Git repository.

    Whatever you want to do primarily depends on: Your formatting, styling, functionality, and interfacing needs for the editor, and what you’re willing to use or invest for setup.

    Hugo runs from a single binary. The source layout is reasonable. With a single layout the folder structure doesn’t have to be complex.

    I’m not very familiar with alternative [Markdown] static site generators.


  • You’re good to keep your skepticism. If you trust them, the ones creating the tutorial to have vetted to a degree, or that a very popular package like that is vetted to a reasonable degree, you’ll just go ahead with it. (Like most people do without questioning it.)

    You’ll need considerable experience and insight to do good, reasonable risk assessment. Without that, you can either trust and hope in others, or skip the ecosystem and look for alternative technologies.

    It’s also worth noting that your potential impact is considerable lower if you’re only doing local test and development work, not publishing or publicly serving anything. I’m not personally familiar if or to what degree running arbitrary local commands has been limited in the npm ecosystem by now.