Threads for philpirj

    1. 3
      philpirj avatar philpirj 3 years ago | link | on: Not So Secret Messages

      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
      philpirj avatar philpirj 3 years ago | link | on: Not So Secret Messages

      they can just block access to 149.154.160.0/20; 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
      philpirj avatar philpirj 4 years ago | link | on: The case statement and ranges

      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
        mehdi-farsi avatar mehdi-farsi 4 years ago | link | on: The case statement and ranges

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

    4. 1
      Confusion avatar Confusion 4 years ago | link | on: Call for discussion: RSpec Implicit Block Expectation Syntax

      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
        philpirj avatar philpirj edited 4 years ago | link | on: Call for discussion: RSpec Implicit Block Expectation Syntax

        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
      soulcutter avatar soulcutter 4 years ago | link | on: Call for discussion: RSpec Implicit Block Expectation Syntax

      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
        philpirj avatar philpirj 4 years ago | link | on: Call for discussion: RSpec Implicit Block Expectation Syntax

        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
          soulcutter avatar soulcutter 4 years ago | link | on: Call for discussion: RSpec Implicit Block Expectation Syntax

          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
            philpirj avatar philpirj 4 years ago | link | on: Call for discussion: RSpec Implicit Block Expectation Syntax

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

    6. 4
      pnathan avatar pnathan 4 years ago | link | on: NIH Bingo: Wheels you (constantly) want to reinvent?

      The HTTP system and the Browser.

      1. 2
        philpirj avatar philpirj 4 years ago | link | on: NIH Bingo: Wheels you (constantly) want to reinvent?

        There’s Gopher and lynx though.

        1. 2
          pnathan avatar pnathan 4 years ago | link | on: NIH Bingo: Wheels you (constantly) want to reinvent?

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