Looks so promising, what's the timeline for something like MUI?

MUI is probably the design system I'll add next, but as for the timeline I'm not really sure. I want to go a little deeper with Chakra UI and explore e.g. theming before branching out to other design systems.

It's not perfect or painless but I think jsonapi-serializer is pretty good

Big fan of raw sql, but practically speaking (as it relates to developing with rails) CTEs can be rewritten as subqueries, the advantage being that they are linear instead of nested in SQL.

With AR queries you can do the same and make it linear in ruby (and then the computer doesn't really care if your sql is nested)

    last_three_posts = Post.limit(3).order(created_at: :desc)
    @posts = Comment.where(post_id: last_three_posts)

The problem here is that you are loading all the votes as AR instances which is fine at small scale, but as your app gets larger, loading and instantiating thousands of Vote instances just to then break them down into an integer will start to drag on your controller.

If you can count in the database itself it's a big win. Although no doubt your solution is cleaner code.

One neat trick that I think is relatively lesser known is that you can select arbitrary sql expressions in ActiveRecord and those values are made available on the instances.

(Also I think the above sql needs to be tweaked since you need the votes count grouped by comment not by post)

A one to many relationship in pure SQL is an awkward fit with a Rails app as it requires serializing (at least) the many as json. Then there's this weird conceptual gotcha where one resource is an AR instance and another is a pure hash.

I'd probably make a scope and association to help out here:

    class Comment
      scope :with_vote_count, ->{ joins(:votes).select('comments.*').select('count(votes.*) as vote_count') }
    end

    class Post
      has_many :comments
      has_many :comments_with_vote_counts, ->{ with_vote_counts }, class_name: 'Comment'
    end

    # in controller
    @posts = Post.includes(:comments_with_vote_counts).limit(3).order(:created_at: :desc)

    # in view/serializer, posts and comments are both AR instances
    @posts.each do |post|
      post.comments.each do |comment|
        comment.vote_count # => Integer
      end
    end

This should give you 2 queries, one to load the posts, then one to load the comments and vote counts for the relevant posts. Controller stays nice and slim and the complexity is delegated to sql via the join scope, without any other dependencies.

* edited for HN code block syntax

Django will do something similar (possibly a little more elegantly) if one is familiar with how to use the Prefetch APIs [1]:

    Post.objects.order_by("-created_at").prefetch_related(
        Prefetch(
            "comments",
            queryset=Comment.objects.annotate(
                vote_count=Count("votes")
            ),
        )
    )[:3]

This will generate the following two queries:

    SELECT
        "post"."id",
        "post"."created_at",
        "post"."title",
        "post"."content"
    FROM "post"
    ORDER BY "post"."created_at" DESC
    LIMIT 3;

    SELECT
        "comment"."id",
        "comment"."post_id",
        "comment"."content",
        COUNT("vote"."id") AS "vote_count"
    FROM "comment"
    LEFT OUTER JOIN "vote"
        ON ("comment"."id" = "vote"."comment_id")
    WHERE "comment"."post_id" IN (3, 2, 1)
    GROUP BY
        "comment"."id",
        "comment"."post_id"

[1] https://docs.djangoproject.com/en/4.1/ref/models/querysets/#...

Personally, I find the Rails version a bit more elegant because it is declarative, reusable and composable, while Django's approach is a more utilitarian "just write the dang query when you want it." But both are a great illustration of how a well-designed ORM can give you the tools you need to get good performance.

You can do the same kind of thing in Django. The approach is a little different, but it's the same basic idea.

https://docs.djangoproject.com/en/4.1/topics/db/managers/#cu...

What about incorporating Ukraine, Belarus, Georgia, and Russia into NATO?

Ukraine gets the Donbas back in return for international recognition of Crimea as Russian territory.

Fanciful, I know. And questionable whether Article 8 would hold up. But advantages:

1. End to the conflict 2. Security guarantees for all of Europe 3. Repurposing of NATO from anti Russia alliance to anti China alliance, ie pivot to Asia

It's very difficult to imagine a world where Russia would accept being in an alliance in opposition to its largest (in economy, population, border, and area) neighbor and its current largest trading partner.

Not to mention that this current war would look like a sibling fight relative to what China would do if it saw a risk of NATO first-strike capabilities coming anywhere near its borders.

The military endgame sadly is somewhere between a destroyed Ukraine in perpetual conflict and regime change, depending on the efficacy of Ukrainian resistance.

Sorry to say, autocrats do not withdraw from a conflict like this regardless of attrition. Their power is their legitimacy and defeat is a threat to both their rule and probably their life. I mean look at how much flak Biden took withdrawing from Afghanistan despite being able to say that it was a horrible idea and someone else's fault.

This is a little different from Afghanistan and Iraq though, Russia's security concerns are valid and probably ameliorated by Ukraine as a failed state (as opposed to a NATO aligned state) so conquering and pacifying the country is not necessary.

The only real humanitarian solution is a diplomatic solution. I wonder if written guarantees that Ukraine and Georgia will never join NATO would be enough now honestly.

> I wonder if written guarantees that Ukraine and Georgia will never join NATO would be enough now honestly.

They would never have been enough; that was the abusive partner going "if you'd just do x I wouldn't have to hit you so much". Consider the ease with which Russia violated their own (https://en.wikipedia.org/wiki/Budapest_Memorandum_on_Securit...).

Honestly, I fear the resistance being too effective.

Russia is on the offensive when viewing this conflict in isolation. Zoom out to geopolitics and it is very much on the defensive.

They are locked in this conflict and if they cannot achieve their goals they will escalate. They also own the most nuclear weapons of any country on earth.

This is what the Art of War says when it says not to put enemies in a corner.

This is also a very realpolitik take on this. It goes without saying that all of this is a humanitarian disaster.

H3 cell indexes are just integers so you can easily make a compound index of (cell_index,timestamp). This would be easy in SQL and I'd have to imagine just about anything else that supports a compound index.

Note that LinkedIn could make this whole issue moot by putting their data behind a login tomorrow. The 9th circuit decision pretty clearly stated that.

The only reason the data is public is for marketing purposes, to sign up more users.

I want some of my LinkedIn profile to be public. I DON'T want any random company scraping that PII data, storing it, processing it and making money from it.

Is that too much to ask?

Of whom?

In this case it would be the US courts. In Britain it would be the ICO who despite claims from companies like hiQ to be GDPR "compliant" they clearly aren't.

I thought they were prevented from doing that (at least at some point, by injunction)

Each Linked In user has the option to make as much or as little of their information public. I don’t see how any injunction can stop that. None of this data belongs to LinkedIn. It nudges us to make more of our data public.

I don’t even want to get into what goes on in the mind of a Linked In “influencer”.

I am convinced salvation cannot come from the courts and at the same time Congress has ceded all authority to the White House. The goal for everyone in our industry must be complete abolition of the CFAA but that can’t happen until we can get Congress to act.

Yeah each user gets the choice right now as a consequence of LinkedIn's product design.

As far as I know, there's no reason it couldn't be "Log in to see this profile".

I believe the injunction bars LinkedIn from blocking hiQ specifically from accessing the publicly available information (which again is public by LinkedIn's choice). They made a point to draw a distinction between the public stuff and stuff behind a login/password.

This is a pretty bad headline. I don't know that i would characterize this as revived.

The same 9th circuit who held last year that LinkedIn could not block hiQ from scraping public data, just got asked to reconsider the same case, except now there is additional precedent that SCOTUS says if you had permission to access the computer then it's not a violation of the CFAA (even if you are a shady corrupt cop).

Hard to see this turning out any other way than the 9th circuit reaffirming their decision (or even strengthening it) and then it's up to LinkedIn to try SCOTUS again

The 9th Circuit never reached a resolution; that case was over a preliminary injunction, and HiQ was only required to demonstrate that they had raised "serious doubts" about LinkedIn's behavior. The court decided to stop prior to the actual case until Van Buren was resolved.

Also, the injunction preventing LinkedIn from blocking HiQ has nothing to do with the CFAA. LinkedIn can't block HiQ because HiQ is alleging that doing so constitutes tortious interference under California law. Again, whether it is or not hasn't been decided, it was only ruled that HiQ raised "serious doubts" as to whether that's the case. Were HiQ and LinkedIn not competitors, LinkedIn would be free to continue blocking HiQ.

The CFAA bit has to do with whether LinkedIn can sue HiQ under the CFAA; it's just an alternative to try to kill their business in the event they lose the tortious interference part. It's a federal law, so it may supersede the state level tortious interference laws. The issue at hand in that case is whether a user can be considered "unauthorized" without providing an affirmative form of authentication. I.e. does IP blocking someone and sending a cease-and-desist make them unauthorized, and does ignoring that cease-and-desist and circumventing IP blocks constitute "unauthorized access"? Or, more generally, does the CFAA protect systems that aim to keep specific people out, or only ones designed to only allow specific people in?

So at this point, it's "revived" in the sense that SCOTUS made a ruling, and the actual case can move forward to resolution. I expect it to end up in the Supreme Court.

I like the outcome of the 9th Circuit's decision, but their reasoning is horrid. The difference between a system that only allows 3 people in and a system that stops everyone except those 3 from logging is purely semantic. The former is far, far more common, but the difference is largely one of practicality. It's drastically easier to build a system that only allows 3 people in than one that keeps everyone else out. However, in their ruling it's perfectly legal to circumvent the banlist solution. It's only illegal to circumvent allowlist solutions.

It also seems incoherent with regards to DDoS attacks. Their stance is that sites that don't require authorization are open to the public (they are "entitled to access by a computer"), regardless of the method in which the public chooses to consume the information as long as it is via computer. A DDoS is a form of access, and their opinion is that companies cannot set terms around how you access their computers; therefore it would follow that since they can't "unauthorize" me, I am implicitly authorized to DDoS them. And if I'm not, where's the line between DDoS and not? Accessing public data can't be a crime; is accessing it in whatever the most expensive way for them to serve it to me a problem? I can make a scraper that pulls competitors prices from their site using their search bar and do it in the most inefficient way possible by iterating through all the character combinations to overwhelm their search infrastructure. Is their only recourse really to put that behind a login?

I don't see any way to read the CFAA under their opinion that makes any kind of sense. I agree, public data should be public, but it really should be addressed in another piece of legislature. This is just going to be an awful can of worms to open.

> I disagree with that SCOTUS decision. It completely obliterated CFAA. Imagine if they said nurses/doctors could do that with their terminals and it didn't violate HIPAA.

The court was absolutely correct in their ruling. If you don't want cops using that data for their own purposes, it should be against the law.... it doesn't make sense to use the CFAA as a catch all for stopping people from misusing data they were given access to. If we do, it gives every private company the ability to make breaking their EULA a criminal offense. That is ridiculous.

HIPPA is a good example of how the law should work. You make what you want illegal; it has nothing to do with computers.

Why would the cop using a computer to access the information be against the law but not a cop going and reading a paper file?

> HIP[A]A is a good example of how the law should work. You make what you want illegal; it has nothing to do with computers.

HIPAA has lots of rules that apply only with computers (or, specifically, a very interesting definition of “electronic transaction”), which is a big reason fax is still a thing in healthcare, because transactions conducted by fax are not considered “electronic” under HIPAA, so a variety of rules that apply when transactions are conducted electronically do not apply.

> use the CFAA as a catch all for stopping people from misusing data they were given access to. If we do, it gives every private company the ability to make breaking their EULA a criminal offense. That is ridiculous.

That is a stretch. This case was specifically applied to the public sector and 'not completely unauthorized' makes CFAA almost inapplicable to public sector databases.

> I disagree with that SCOTUS decision. It completely obliterated CFAA. Imagine if they said nurses/doctors could do that with their terminals and it didn't violate HIPAA.

I don't see the similarity between CFAA and HIPAA, here, and SCOTUS didn't obliterate the CFAA. Theybsimply said, if you are authorized to use a system, your use of the system isn't unauthorized. That's fairly straightforward.

HIPAA, on the other hand, regulates disclosure of specific data. You can violate HIPAA even if you are authorized to use a system that holds covered data.

And HIPPA covers more than just computers. It includes paper records. Using just the CFAA as crutch for data the should not misused still allows misuse of paper documents or overhearing a conversation ect...

They made it unenforceable in the public sector. Some people make parallels that both law enforcement and healthcare are somewhat a public good.