Threads for philpirj

    1. 3

      Please don’t post more links to this site Calvin, it’s either a troll, or an incompetent person. Their understanding of TLS:

      The client connects to the certificate authority and says “Yo! I got this server information. Is it valid and authentic?”

    2. 1

      they can just block access to; this will completely cut off connectivity to Telegram. But second, they can use a stateful packet inspector. If they see any traffic on 443/tcp where the first data packet lacks the TLS header, then they know it’s a trojan protocol and they can kill the connection (e.g., TCP RST or silently drop)

      Can someone please explain why so many attempts of thr russian government to block telegram failed?

    3. 3

      Here we can see that we exclude the left value by omitting it in the range — starting by 91 instead of 90 in order to exclude the 90 value.

      In which case, for which value of surface the returning value will be different?

        when 70..90   then :second_value
      - when (91..inf) then :third_value
      + when (90..inf) then :third_value

      Same applies to the case with floats, isn’t next_float superfluous?

      But, what if I want to exclude the left operand?

      The cost of next_float and intermittent ranges doesn’t seem to justify that desire.

      1. 1

        Thanks for the feedback. I’ll update the article accordingly ;-)

    4. 1

      I’m not really sure what a practical use case for this would be. What code would you spec like this? Or is it just a trick to be able to use the one-liner syntax?

      I tend to agree with @soulcutter: I think just not having a Cop for this is fine. Or have one that is disabled by default.

      1. 1

        Pretty sure there’s some confusion here. This discussion is about recommending against this syntax, not recommending to using it.

        Proponents of the syntax tend to say that it makes it possible to use the block matchers in combination with one-liner syntax, and that makes it possible to save some keystrokes on writing expect { subject }. I’m not sold on this though.

    5. 1

      I don’t see this as something rubocop needs to have any opinion about whatsoever. It’s legal ruby if you want to use it. Personally I’m not a huge fan of any one-liner RSpec syntax, but I wouldn’t force that opinion on others. My vote would be not to have any cop for this.

      I am a past RSpec core team contributor.

      1. 2

        Agree that it’s a valid Ruby syntax, but it’s not something that RSpec was designed to work with as per Jon Rowe and Myron Marston.

        RSpec::Expectations::Syntax via RSpec::Expectations::ExpectationTarget doesn’t make a clear distinction between BlockExpectationTarget and non-block ExpectationTarget, and mistakenly takes a lambda for a value, is passing it as a target to block matchers that call a .call method on it.

        That makes me think of this as a hack and a shortcoming of RSpec that may eventually be deprecated or becomes impossible.

        1. 1

          If you’re dead-set on protecting people from a possible future because it’s not intended behavior, go ahead. Consider that it’s also possible that it becomes supported despite the thinking in 2015, though, and then you’ll have been steering people away from it. (shrug) I mildly feel as though there being a distinction between BlockExpectationTarget and ExpectationTarget was a (well-intended) mistake. In my mind its meant to provide guidance, and if it misses the mark there it doesn’t mean it’s working incorrectly, it’s just a missed opportunity.

          Feels to me like you’ve made up your mind. This won’t affect me, but my opinion has been registered.

          1. 1

            I’m definitely inclined toward recommending against this syntax, but I also see that you have completely valid points.

    6. 4

      The HTTP system and the Browser.

      1. 2

        There’s Gopher and lynx though.

        1. 2

          yeah I want to get down with Gopher a lot more in the fall.