auxiliarymoose

Yep, I've been importing CDs to Apple Music (which I buy from my local music store) and adding them to my Android phone for personal listening. It's a great way to spend money on music in a way that supports local businesses!

Thanks for the catch! Fixed :-)

Well, it's posted on Hacker News which is a general audience including people working on electrical/signal/audio/radio-frequency systems among other things (not just low-level network code) where BPF has a different meaning, so I think disambiguation is appropriate.

~Well, if you asked a randomly-chosen person (technical or non-technical) they would probably say NASA is "the organization that does the space things" — it's pretty well-known~

~On the other hand, BPF means different things in different domains, and isn't ubiquitous in the same way~

Edit: I should have written it out, that's on me :-)

Sure, but if you are sharing with a general audience (where people aren't necessarily coming from your own domain) it's a good idea to make the writing accessible.

My first thought would have been Band-Pass Filter, which is also a filter potentially related to computer systems.

I work in an industry with a lot of Three-Letter Acronyms (TLAs) and eXtended Three-Letter Acronyms (XTLAs) (sometimes known as Four-Letter Acronyms (FLAs)), and there they are often overloaded in their meanings. So in my experience, being clear about the definition is helpful to readers so they can immediately understand the document without having to triangulate meanings from the rest of the document.

I'm guessing Berkeley Packet Filter: https://en.wikipedia.org/wiki/Berkeley_Packet_Filter

This is why National Aeronautics & Space Administration (NASA) guidance is the following:

Acronyms often confuse readers. Avoid them whenever possible. If an acronym is necessary for future reference, spell the full word and follow with the acronym in parentheses on the first reference. For example, The General Services Administration (GSA).

https://nasa.github.io/content-guide/abbreviations-and-acron...

There is also this longer memo on the NASA Technical Reports Server: https://ntrs.nasa.gov/citations/19950025292

Alternatively, it is a conscious decision to help prevent users from causing complicated situations.

Given a highly configurable system, users will find ways to (unintentionally) tie it into knots, so adding some guardrails can help reduce complexity demons down the line (both in the technical implementation and the user experience).

I guess I prefer to give people making things the benefit of the doubt.

federated hardware (a bunch of raspberry pis networked into a high availability kubernetes cluster, hidden across various local coffee shops for free power and bandwidth)

It's easy to convert because CSG is a small subset of what BREP can do.

It's analogous to "all squares are rectangles, but not all rectangles are squares" (squares=CSG, rectangles=BREP)

CSG by itself isn't suitable for most CAD use-cases.

It is open source, so you could send pull requests with improvements: https://github.com/instructure/canvas-lms

Creo (and Onshape) both support STEP AP242 export, but customers may choose to export to an older version for better compatibility with third-party systems that have not implemented recent standards.

Generally, at export time, choosing the oldest format version which still has all of the features you need will make it most likely others will be able to open the data.

I think there's a lot of potential for some more old-school UI in business software. People using points of sale, CRM/ERP/PLM/etc. systems, intranet portals, and so on don't really care about how nice it looks. Efficiency is more important.

Especially if it can be easy for non-technical people to build efficient UIs and databases (so they don't have to resort to spreadsheet contraptions), I think there's an opportunity here...

I've also felt that composition is unnecessarily hard in web & data infrastructure. I do game development as a hobby, and web + data technology is in the stone age compared to game engines when it comes to composability.

For example, say I develop some object (scene) in Godot Engine. It interacts with the environment using physics simulation, renders 3D graphics to the screen with some shaders and textures, and plays back audio from its 3D location.

I can send this scene to some other user of Godot, and it will naturally just work in their project, including colliding with their objects, rendering in their viewport (including lighting and effects), and the player will hear the location of the object spatially.

Of course there is much more you can do in Godot, too: network requests, event-driven updates, localization, cross-platform inputs, the list goes on. And all of these compose and scale in a manageable way as projects grow.

Plus the engine provides a common data and behavior backbone that makes it possible for a single project to have code in C++, C#, GDScript, and even other languages simultaneously (all of these languages talk with the engine, and the engine exposes state and behaviors to each language's APIs).

In fact, I've been thinking about making a Godot-inspired (or perhaps even powered) business application framework because it's just such a productive way of building complex logic and behavior in a way that is still easy to change and maintain.

So I imagine if Cambra can bring a similar level of composability for web & data software, it could dramatically improve the development speed and quality of complex applications.

You can just git submodule in the dependencies. Super easy. Also makes it straightforward to develop patches to send upstream from within your project. Or to replace a dependency with a private fork.

In my experience, this works great for libraries internal to an organization (UI components, custom file formats, API type definitions, etc.). I don't see why it wouldn't also work for managing public dependencies.

Plus it's ecosystem-agnostic. Git submodules work just as well for JS as they do for Go, sample data/binary assets, or whatever other dependencies you need to manage.

How do I decline it?? I keep clicking no, hide, not interested, cancel, etc. but it keeps showing up and activating...if I had a nickel for every time I clicked it on accident in Azure because a layout shift moved it under my mouse when trying to press a button I would have a lot of nickels. It even showed up as an app on my phone because I guess the Office 365 entry got hijacked...

Sure it's not officially called the "standard library," more precisely it would be "the parts of the ECMAScript and CSS standards implemented by all popular evergreen browsers," but "standard library" expresses this in the way people usually talk about programming languages.

No, it means using the crypto module in the standard library instead of importing some third party dependency.

There are certainly security benefits to keeping things in-house. Less exposure to supply-chain attacks (e.g. shai-hulud malware) and widespread security bugs (e.g. react server components server-side RCE). Plus it's much easier to do a complete audit and threat model of the application when you built and understand everything soup-to-nuts.

Of course, it also means you have to be cautious about problems that dependencies promise to solve (e.g. XSS), but at the same time, bringing in a bunch of third-party code isn't a substitute for fully understanding your own system.

Thanks for creating and sharing that resource! I'm reading through it now, and it looks fantastic. I'll share it the next time someone asks where to get started with web dev.

Come to think of it, I should write up the techniques I use, too...e.g. I have simple wrappers around querySelector() and createElement() with a bit of TypeScript gymnastics in a JSDoc annotation to add intellisense + type checking for custom elements.

Would you be open to a pull request with a page on static analysis/type checking for vanilla JS? (intro to JSDoc, useful patterns for custom elements, etc.) If not, that's totally OK, but I figure it could be interesting to readers of the site.

And agreed on vanilla/dependency-free not being a silver bullet. There aren't really one-size-fits-all solutions in software, but I've found a vanilla approach (and then adding dependencies only if/when necessary) tends to help the software evolve in a natural way and stay simple where possible.

yeah, plus stack traces, debuggers, and profiling tools are easier to use when all of the non-essential complexity is stripped out. which in turn means it's possible to work productively on software that solves more complex problems.

that's in contrast with the sort of stuff that invariably shows up when something falls over somewhere in a dependency:

    cannot access property "apply" of null
    at forEach()
    at setTimeout()
    at digest()
    at callback()
    at then()
    ...

I really think writing dependency-free JavaScript is the way to go nowadays. The standard library in JS/CSS is great. So are static analysis (TypeScript can check JSDoc), imports (ES modules), UI (web components), etc.

People keep telling me the approach I am taking won't scale or will be hard to maintain, yet my experience has been that things stay simple and easy to change in a way I haven't experienced in dependency-heavy projects.

Take async for example. You have to choose some third-party async runtime which may or may not work with other runtimes, libraries, platforms, etc.

With Go, async code written in Go 1.0 compiles and runs the same in Go 1.26, and there is no fragmentation or necessity to reach for third party components.

Godot Engine has pretty good UI building tools.

The places where it poses challenges in my experience are high quality typesetting/rich text, responsive UI that requires a wide range of presentations (i.e. different layout structures on mobile vs desktop), and granular control over rendering details.

But for functionality-oriented UI, it's hard to beat its simplicity and scalability, particularly when you want to develop on one platform (e.g. computer) and have everything "just work" identically on other form factors (web/tablet/etc.).

For example, Godot's editor is bootstrapped/built in Godot, and runs natively on Web, Android, and Quest XR among other platforms.

Godot is pretty lightweight (especially considering how powerful it is), generally about a second or less. But maybe they are looking for a fast enough startup time that the engine can be started when showing something onscreen and torn down when not visible. In which case, I can see the startup time being an issue.

AWS GovCloud is accessible to commercial customers.

Much of the problem stems from inconsistent application of icons. This would have gone better if Apple established (and followed!) clear guidelines for exactly which icon to use for which standard action (e.g. search).

That the icons exist is not necessarily a problem, since they can help teach users which buttons in the UI do which actions. (menu bar for discovery, app UI for less mouse travel + contextual options). But that requires consistency, which the current implementation lacks...

Accordion behavior is discussed in the article in the "Accordions / Expanding Content Panels" section:

Use the same name attribute on all related details (like radio buttons) to restrict only one open panel at a time

And tabs can be a <details>-based accordion with some creative CSS to adjust the layout (left as an exercise for the reader, but I could write up an example if that would be helpful!)

They shared the polling code in the article. It doesn't request another jpeg until the previous one finishes downloading. UDP is not necessary to write a loop.

Because displaying user-submitted images is pretty common and doesn't feel like a security footgun, but displaying user-submitted HTML is less common (and will raise more careful security scrutiny).

The crazy thing is that today the JavaScript standard library is very robust, and yet the culture of pulling in a ton of dependencies persists. It's so much easier to develop code against a stable and secure platform, yet it seems the choice is often to pull in hundreds of bits of code maintained by many different parties (instead of doing a little more in-house).