bminor13
Are you saying that you prefer SQL over PromQL for metrics queries? I haven't tried querying metrics via SQL yet, but generally speaking have found PromQL to be one of the easier query languages to learn - more straightforward and concise IME. What advantages does SQL offer here?
Location: Raleigh, NC (US)
Remote: Yes
Willing to relocate: Yes
Technologies: Backend programming (Go, C++, Rust), scripting (Python), build tools (Bazel, Buildbarn), and infra (Docker, Kubernetes) (and more!)
Résumé/CV: https://www.linkedin.com/in/scott-minor-a360a821/
Email: [email protected]Seems like brute-force search for adjacent values with the same rank is possible, but guaranteeing that intermediate higher-rank values dont also exist may not be (for an attacker). Maybe one mitigation on this sort of attack is to search for higher-rank extra values to insert to break up large G-nodes?
This also assumes they can know the hash function (if rank is chosen by cryptographically-secure hash); maybe also salting values before hashing could thwart these sorts of attacks?
Have you looked at ARC? It sounds similar - it is a cache split between LRU and MFU areas, where the split point changes dynamically depending on the workload. https://www.youtube.com/watch?v=F8sZRBdmqc0 is a fun watch on the topic.
Is data in the ARC double-cached by Linux's disk caching mentioned in the post? If so, is it possible to disable this double-caching somehow?
(I don't think it produces a volume of data that escapes the free tier, but I'd have to check)
Whether the codegen/libraries for a particular language provides a more idiomatic binding for these well-known wrappers is up to the implementation - for example, golang libraries have conveniences added for well known libraries: https://pkg.go.dev/google.golang.org/protobuf/types/known. Rust libraries may have the same; I'm not as familiar with the ecosystem there.
Here are some of the things I appreciate about Jsonnet:
- It evals to JSON, so even though the semantics of the language are confusing, it is reasonably easy to eval and iterate on some Jsonnet until it emits what one is expecting - and after that, it's easy to create some validation tests so that regressions don't occur.
- It takes advantage of the fact that JSON is a lowest-common-denominator for many data serialization formats. YAML is technically a superset of JSON, so valid JSON is also valid YAML. Proto3 messages have a canonical JSON representation, so JSON can also adhere to protobuf schemas. This covers most "serialized data structure" use-cases I typically encounter (TOML and HCL are outliers, but many tools that accept those also accept equivalent JSON). This means that with a little bit of build-tool duct-taping, Jsonnet can be used to generate configurations for a wide variety of tooling.
- Jsonnet is itself a superset of JSON - so those more willing to write verbose JSON than learn Jsonnet can still write JSON that someone else can import/use elsewhere. Using Jsonnet does not preclude falling back to JSON.
- The tooling works well - installing the Jsonnet VSCode plugin brings in a code formatter that does an excellent job, and rules_jsonnet[0] provides good bazel integration, if that's your thing.
I'm excited about Jsonnet because now as long as other tool authors decide to consume JSON, I can more easily abstract away their verbosity without writing a purpose-built tool (looking at you, Kubernetes) without resorting to text templating (ahem Helm). Jsonnet might just be my "one JSON-generation language to rule them all"!
---
Though if Starlark is your thing, do checkout out skycfg[1]
There is no "default workflow" for git - Git can be used in a variety of ways; everyone has their own personal preference, and some of these workflows are shaped by interacting with systems like Github/Gerrit/etc.
Every place I've ever worked at has either:
- a home-grown wrapper around git to make common operations easy
- a recommended set of git aliases around common operations
Of all the capabilities of the Github CLI, `gh pr checkout` is the only one I use, because it makes it easy to fetch a PR locally by ID without configuring a remote per fork. I'm pretty glad I didn't have to write this myself.
Presumably these hypermedia endpoints are all equally accessible - couldn't the removal of one break another application if the latter app decided to depend on a particular hypermedia snippet from the first?
If there are multiple teams in an org that own HTMX endpoints, aren't the set of endpoints effectively a sort of interface boundary? Or is there a good way of declaring certain endpoints "private" and ensuring they're only fetched from particular applications? (Maybe separate domains for every app?)
> Fixing psychological and emotional problems through cultural change just doesn't solve anything.
By my reading, the two quotes are in direct opposition to one other. It sounds like you are advocating for cultural change - just a different type/approach than is currently used?
I get the feeling there's more to Prolog than I was able to unlock - can you recommend any reference materials for beginners?
Remote: Yes
Willing to relocate: No
Technologies: C/C++, Embedded C/C++, Golang, Rust, Bazel, Docker, Postgres
Resume: On request via email
Email: hnjobs *at* scottminor.email
Hey, I'm Scott! I'm a versatile team member, having been a part of both small and large organizations alike. My skillset is diverse and skews towards backend + embedded programming languages and environments, though I have dabbled in frontend projects (Angular on web, Flutter on mobile), build tooling (migrating codebases to Bazel monorepos with custom rules), and deployment (Kubernetes).
I'm looking to transition into remote work so that I can stay clear of the Bay Area traffic post-Covid. Need a hand on interesting projects? Drop me a line via the email above and let's chat!
OTOH, one can still reasonably use a closed laptop if it has a display plugged in, so closing the lid no longer implies an intent to stop using it. Because of this alone, going to sleep in this context might not be the most sane default.
Some examples of when I've personally closed a laptop with the screen plugged in without wanting it to sleep:
* Working at a desk where the laptop doesn't fit with the lid open * Starting a video when connected to a TV in a dark room, where the laptop's screen is a distracting source of light
The issue is not ambiguity in the declaration, but rather the callsite: it's rarely possible to tell if a parameter is passed as a value, ref, or const ref at a particular callsite without consulting the function declaration. Oftentimes, one reads code without comparing each function call to its declaration, so it's easy to miss instances where objects are passed around by mutable ref rather than the more common const ref.
Using a pointer for the mutable cases resolves this ambiguity by forcing different syntax to be used at the callsite, which reminds:
* code authors that the parameter they're passing can be modified by the function call (they should think carefully about whether this is desired)
* code readers that a function call is potentially modifying its parameter (which can aid in debugging)
> Q1: Yes Q2: - Q3: No Argument: `Widget& widget`
...or `Widget* widget`, which has drawbacks but makes it more clear at the callsite that the argument passed may be modified. The Google style guide prefers this for this reason: https://google.github.io/styleguide/cppguide.html#Reference_...
> Q1: No Q2: No Q3: - Argument: `Widget widget`
Q2 IMO should have an addendum to read "Is it expensive to copy a Widget and if not, will it always be cheap" because there is nothing to stop someone from adding to Widget until it crosses the threshold of "expensive", at which point someone needs to go through and update all the callsites to pass by const ref. Widget's copy cost really needs to be part of its API contract before pass-by-value can be allowed.
> To minimize I/O and take advantage of operating system caching, csearch uses mmap to map the index into memory and in doing so read directly from the operating system's file cache. This makes csearch run quickly on repeated runs without using a server process.
Does anyone know some resources where I can read more about this technique? (how-to, pros/cons, caveats, etc.) I'm interested in figuring out the best way to have a commandline tool persist state that it can quickly access across multiple runs, but so far a background server process is the only technique I'm familiar with.
...this is if you don't look up hints/other people's designs, of course.
The workstation is not connected to the codebase via SSH on a server, but rather the version control clients are remote and mapped into the local filesystem via FUSE. So the workstation is less of a dumb terminal; programs that access the code can run locally, even though the code itself is not stored locally. Therefore, version control clients can be accessed with various web-based tools as well.
Not all developers used a workflow that includes Piper/CitC, but most do. From my limited view, the Piper/CitC workflows were the most painless.
Debugging - I only ever used a debugger for Python, and in those cases the application I was running was local. Otherwise I never used a debugger but rather logging (printf debugging, essentially). I'm of the opinion that if you have to open a debugger to understand the code, you've already lost. Others might have better stories.
Remote machine - as mentioned above, there is no remote machine. Things are done on your workstation. The build commmands can build things locally (slow) or farm them out to a cluster of build machines in datacenters (fast). See https://bazel.build/faq.html#does-bazel-require-a-build-clus...