NightMKoder

This is very nonambitious, but I’d love to see a Clojure with less LISP. That is - something like JS syntax but with immutable by default types and const only bindings. Macros would be great too, even if they require a different compilation mode. Top it off with great standard library that has _all_ the collection operations you’ll ever need (e.g. partition-all and dedupe in Clojure). nREPL support or the like is a hard requirement.

Spending the last 6 years writing Clojure has been great. That said, the parens don’t add positively to the experience. They feel like semicolons in C - “the compiler is too dumb to understand this so I have to help it.”

My sense that is that any written record (especially publicly posted records), an admittance of guilt can later be used as evidence in court. That is, if the bar needs to defend itself in court later, admitting guilt now would make that a lot harder.

And they're a bunch of lawyers -- they likely know that.

Java the language? Very likely not. As proof - a majority of Clojure runs in JavaScript without any code changes (via ClojureScript). That said exceptions tend to look like Java classes, so you’ll definitely see Java bits.

Java the JVM? You _probably_ don’t need to know it to get started, but you’ll have to get familiar with JVM deployment, dependency management, packaging, JVM memory settings, etc if you want to run something outside your dev machine. Getting to 90% here is pretty easy, but the last 10% (to me at least) tends to feel a lot more difficult that other languages.

As a small pro-tip: use jstack. I wish every language came with a jstack. It just dumps the stack traces of all threads of a program by pid.

Aren’t those usually capitalized as well? I’ve always though that style in legal texts means “a proper noun defined previously” - in case of plaintiff and defendant, probably on the first page. That said I have no legal background so take that with a grain of salt.

Yep and covered entities are usually related to billing for medical care. As an example, almost all life insurance companies are not even hipaa compliant because they aren’t covered entities.

In net - hipaa doesn’t protect medical information generally - only the subset that’s usually visible to doctors. And even then, it stops working as soon as the info is outside a covered entity.

Yes - exactly what boulos said - I’m coming from the Google “you control your clients” perspective. That said, in some sense you always control your clients - you can always set up localhost proxies that speak your protocol or just tcp proxies.

The thing is service discovery is _always_ inconsistent. By the time you get your set of endpoints from your discovery, it can be out of date by the time you open your socket. Certainly for something like databases you need followers or standby leaders to reject writes from clients - service discovery can’t 100% save you here.

Didn’t realize consul had that. Seems like the right approach - though I wonder why Roblox wasn’t using it.

Fwiw I believe kubernetes did this right - if you shoot the entire set of leaders, nothing really happens. Yes if containers die they aren’t restarted and things that create new pods (eg cron jobs) won’t run, but you don’t immediately lose cluster connectivity or the (built-in) service discovery. Not to say you can survive az failures or the like - or that kubernetes upgrades are easy/fun.

And don’t run dev stuff in your prod kube cluster. Just…don’t.

Admittedly this is armchair architecture talk, but it seems like either consul or Roblox's use of Consul is falling into a CAP-trap: they are using a CP system when what they need is an eventually-consistent AP system. Granted, the use of consul seems heterogenous, but it seems like the main root cause was service discovery. And service discovery loves stale data.

Service discovery largely doesn't change that often. Especially in an outage where a lot of things that churn service discovery are disabled (e.g. deploys), returning stale responses should work fine. There's a reason DNS works this way - it prioritizes having any response, even if stale, since most DNS entries don't change that frequently. That said, DNS is not a great service discovery mechanism for other reasons. Not sure if there's an off-the-shelf solution that relies more on fast invalidation rather than distributed consistent stores.

In case you haven’t seen it - the TreasuryDirect password policy is almost comical. There’s a screenshot in the repo.

The website disables the password input field (and password managers with it). To “type” your password, you have to use some on screen button-based keyboard monstrosity.

If someone wanted to make fun of password rules, this would have been great satire. But no - this is actually how you buy bonds from the US treasury.

I assume you mean `ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) as row_number` with a `WHERE row_number = 1`. We ran into issues with memory usage (i.e. queries erroring because of too high memory usage).

The `ARRAY_AGG` approach uses a simple heap, so it's as efficient as MIN/MAX because it can be computed in parallel. ROW_NUMBER however needs all the rows on one machine to number them properly. ARRAY_AGG combination is associative whereas ROW_NUMBER combination isn't.

One of the hardest types of queries in a lot of DBs is the simple `min-by` or `max-by` queries - e.g. "find the most recent post for each user." Seems like Postgres has a solution - `DISTINCT ON` - though personally I've always been a fan of how BigQuery does it: `ARRAY_AGG`. e.g.

  SELECT user_id, ARRAY_AGG(STRUCT(post_id, text, timestamp) ORDER BY timestamp DESC LIMIT 1)[SAFE_OFFSET(0)].*
  FROM posts
  GROUP BY user_id

`DISTINCT ON` feels like a hack and doesn't cleanly fit into the SQL execution framework (e.g. you can't run a window function on the result without using subqueries). This feels cleaner, but I'm not actually aware of any other DBMS that supports `ARRAY_AGG` with `LIMIT`.

Oh wow I didn’t realize they did custom licensing (presumably for a good chunk of change). Good to know!

This is a bit reductionist but a fun story for those that haven’t heard it. The GPL was created so rms could modify his printer driver: https://www.gnu.org/philosophy/rms-nyu-2001-transcript.txt .

FFmpeg is licensed under LGPL which can (albeit carefully) work on the web, but libx264 is GPL. I think that alone makes this project unusable in non-open-source projects? (For reference, GPL does not have any dynamic linking exception, so the copyleft terms apply as soon as you include it in your shipped binary in any way)

Aside from the OSS licenses alone, H.264 encoders/decoders have a required patent license. Most users get around this by using an API (e.g. `<video>` tags, AVFoundation) - which means Google/Apple pay for it when they ship the decoder for Chrome/iOS. How does this project get around that requirement?

As others have mentioned - you’re probably talking about something like a python or node repl. Lisp repl development is not like python or node - you _work_ in the repl. The closer comparison might be between bash+node as a repl - up+enter and the like to rerun tests has an equivalent in clojure+IntelliJ. There’s no copy pasting but there are different key bindings.

One of the best parts about lisp style repl development is that you end up doing TDD automatically. You just redefine a function until it does what you want from sample data you pass in - without changing files or remembering how your test framework works. You can save the output of some http call in a top level variable and iterate on the code to process it into something useful. The code you evaluate lives in the file that will eventually house it anyway so it’s pretty common to just eval the entire file instead of just one function.

Since you don’t ever shut the repl down, developing huge apps is also quite pleasant. You only reload the code that you’re changing - not the rest of the infra so things like “memoize” can work in local development. That’s why it’s a bit closer to your bash shell in other languages.

If you’ve never tried it, I highly recommend trying the Clojure reloaded workflow [1] to build a web app with a db connection. You can really get into a flow building stuff instead of waiting for your migrations to run on every test boot.

[1] https://cognitect.com/blog/2013/06/04/clojure-workflow-reloa...

IANAL but I think the law is about trading - not profiteering. Trading public stocks based on material non-public information is a crime even if you don’t know _what_ will happen to the stock or you predict wrong. You literally cannot lawfully trade the stock no matter your expectation of how the news will be received. In fact I would say any large market reaction after the news breaks means the information was “material.”

Both JFR and agent based implementations only work with non async code. As soon as you do async anything, stack traces are no longer representative so automatic instrumentation is useless.

That said, I’m really hoping Project Loom will fix that issue by getting rid of most async callback-style I/O.

This isn’t mentioned in the article, but I found debug-repl [1] to be amazing when debugging in the repl. For simple prints, wrapping expressions in (doto prn) has always been enough for me without custom readers. But when debugging something super odd, just stopping somewhere and evaluating a bunch of code (with locals in scope) to understand what you’re dealing with is invaluable. Clojure’s immutability makes it especially nice since you can just rerun (most) expressions to “see what happens.”

[1] https://github.com/gfredericks/debug-repl

I’ll have to disagree with you - the problems are similar but somewhat unrelated. Sampling profilers traditionally only sample threads that are actively doing something - i.e. using CPU time. Tracing is closer to wall time profiling rather than CPU time - and global instrumentation actually sucks at that kind of enumeration. The overhead of iterating through 100k goroutines would be too high at any reasonable frequency when most of them are just blocked on something. And most are probably blocked on something you don’t even care to see (eg a worker waiting for work).

Aside from the sampling issue there is also the problem of non-blocking frameworks/languages. It’s easy to add tracing to JS functions that use async/await but it is definitely a mini research project to recover stacks from in-flight promise state machines. Most languages fall into this bucket unfortunately.

Now all that said, if you can make some automation that preemptively creates spans for you - kind of like a sampling profiler “creates” stack traces - that would be super cool. The worst part about tracing is sprinkling the tracing code in all the places you need it. You inevitably miss a few spots that show up as “missing” bars in the gannt view. Having something that fills in those blanks is invaluable.

Im not sure why this is cataclysmic for FB - they’re mostly a first party advertiser. App tracking transparency doesn’t prevent Facebook from running ads on their own apps and using SkAdNetwork to track conversions (which works even if the user opts out).

Granted the fidelity and latency of SkAdNetwork is a concern but hardly enough to materially impact the bottom line.

The Apple policy requires that opting out is not treated adversely. See https://developer.apple.com/app-store/user-privacy-and-data-...

Hmm I’m not aware of a way to do that short of fingerprinting a browser and running the same fingerprint on app launch. Would you happen to have docs for that approach?

I think it’s a bit more nuanced than that. The new policy doesn’t seem to try to break ads attribution globally - e.g. the App Store ads attribution continues to work regardless of tracking transparency choices. They’re also not trying to prevent first-party tracking - i.e. app analytics and the like.

Apple could have thrown a bone to folks and just allowed passing url parameters or similar through the App Store links to the app after it’s installed. No third party needs to get the data and advertisers get to actually know ROI like they do with the rest of the web.

Alternatively I’d love if Apple actually took a stance against data aggregation. Take on the actual creepy corps like LexisNexis or Experian or Transunion. Interest tracking is peanuts by comparison. Not to say we shouldn’t start somewhere, but I hope tracking transparency doesn’t end here.

I was researching something similar recently (sticky elements covering anchor scrolling) and there’s a somwhat modern solution to that: https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padd... . As usual with new tech though, doesn’t work in Safari (and hence all of iOS) for now. I wonder if the same property could be used to make pgup/pgdown/space work correctly.

Could the sscanf bug also be a security issue? Most C strings are null terminated, but I could imagine using sscanf to read outside of bounds due to the null-seeking behavior on a non-null terminated array.

If it is an issue, I think it probably can’t be used for more than a DoS or a timing attack. That said after meltdown & co anything is possible.

While that is true, Google hasn’t always used OS abstractions. Case in point - the browser chrome (of Google Chrome to try to disambiguate). They could have used their own UX if they wanted. They just didn’t.

I agree with both you and the parent from a principles perspective. There's no reason sharing on the web has to be somehow limited to whatever the website author chose to support.

My problem is that this just isn't a pragmatic choice right now. The chicken-and-egg problem is somewhat true, but the carrot was already there for web devs - iOS and Android implement web share. And it's an excellent UX - better than anything you can make yourself.

The problem with the desktop share experience is that it is strictly worse than putting 2-3 social buttons & copy link for 95% of people. Neither Facebook nor WhatsApp support the share target API right now (quick post-edit: Twitter does though). Even if they did, there's another hurdle [1]:

  To register your app as a share target, it needs to meet Chrome's installability criteria. In addition, before a user can share to your app, they must add it to their home screen.

So, again, pragmatically what people are going to start doing is - change from "if (navigation.share)" to "if (navigator.share && isMobile)". And I think that sucks - there will have to be another slow-moving wave of change once the desktop share is "good enough" to enable for everyone.

[1] - https://web.dev/web-share-target/

Would anyone happen to have a screenshot of the web share experience on Windows? Is it also on for OSX?

The API made a lot of sense to use on mobile - for example to send an SMS. You need to use apps to share. Bringing it to desktop, it may actually be less usable than just putting social share buttons directly on the page. I don't know a lot of people that use the OS-level apps on desktops (e.g. contact sync or logging into facebook). Does this end up a glorified `mailto` button for most people?

This article seems like a case of jumping to conclusions. While Google somehow taking some time to figure out what to write is certainly an explanation, it is not the only one.

Given the classic App Store experience of opaque waiting, I would wager Apple is holding Google’s updates. Why is anybody’s guess - a disagreement on the privacy aspect is definitely a probable explanation. I wouldn’t necessarily blame Google straight up though. Apple has an financial incentive to make Google look bad that I just can’t trust.

As several folks pointed out, I was wrong with the translation. Evidently my family who are proper Russians have been humoring my half-correctness. Sorry for the incorrect info above everyone!

I did learn that фен can actually mean other kinds of hair dryer-like heat guns (from https://ru.m.wikipedia.org/wiki/Фен). I assume that’s what these folks used to heat various components.