Understanding what is wrong with meritocracy (part two) – Lukas Smith

Wow, quite a long time since I last wrote a blog post, which clearly hinted towards at least a part two one day. I recently started blogging elsewhere (more on that below) and kinda forgot about my old blog. Lately I have been getting spam on it though, which reminded me of this old post. So here comes part two. I should add that it didn?t really take me 5 years to mature my thoughts on this topic, it just ended up that I communicated those thoughts in other places.

That being said, one of the first learnings as I dove into this topic was that that step one was listening and learning. Basically I started expanding my twitter timeline to include more people specifically tweeting about the issues of diversity and inclusion. But also simply following more people with marginalized communities talking about tech.

I paid attention to the dynamics in discussions. But one of the most clear ways I finally realized and fully accepted that meritocracy is a myth came with this github study that showed that while acceptance rates of PRs from women were well below those of men, the acceptance rate of PRs from women that hid their gender even slightly outpaced those of men.

Due to this reality and the constant pins and needles on top of deliberate harassment, where keeping people from marginalized communities away and pushing those that made it out. We keep hearing about some pipeline problem but the real issue is that people from marginalized communities just see no point in staying. But obviously this is not the root cause. Just going from my personal experience at Liip, I can name more female developers that left IT than male, despite us having way more male developers. The good news here, better diversity is entirely possible in tech if we actually work hard on inclusion. This is why people say ?diversity means nothing without inclusion?.

So with those realizations, I came across a tweet in the spring of 2017 by Erin pointing out the issues with an all white men speaker line up for a SymfonyLive event in the US. I first started rattling off excuses (note sure if just in my head or also in tweets), but eventually this finally gave me the kick I needed to become active. So I started reading more blog posts on the topic. Thanks to Liip?s education budget for all its employees, I ended up hiring Sage Sharp to help me figure out the next steps Symfony should be taken and what pitfalls to avoid that could cause further harm.

I was very happy to find that the Symfony core team was very receptive to this topic. Later that year we formally launched the diversity initiative. More importantly the community, aside from a few voices, was supportive as well and willing to learn and welcome change. We focused on several topics, like improving the language in our docs and on the website. We worked on guides for how to give and receive feedback in issues and PRs but more importantly we also worked on making those a lived reality. Quickly contributors started approaching the diversity initiative for support when they encountered situations where they felt overwhelmed. This helped deescalate a lot of situations but also helped train many contributors.

We also implemented a diversity scholarship to allow people from marginalized communities, that could otherwise not attend, to come and join us at SymfonyCon. One of the biggest successes was the adoption of a code of conduct, which lays the groundwork for safety as we hope to grow our diversity. More importantly, we worked in defining reporting processes and get the CARE (Code of Conduct Active Response Ensurers) trained by Sage Sharp so that they are prepared properly to enforce the code of conduct and sure reporters are properly protected and supported. Overall from the feedback I have seen we have made significant strides in improving our communication and openness. You can read more about this on the Symfony blog.

That being said, all of this hasn?t fixed our demographic issues within the Symfony community. There are still only men on the core team. While there are more visible figures within the Symfony community with a diverse background, we are still miles away from even just reaching the demographic representation of the proprietary software world, let alone the world in general. This is a long long

Truncated by Planet PHP, read more at the original (another 2633 bytes)

Guide to PHP 7.1

PHP 7.1 was an incremental feature release, offering new language constructs, significant performance improvements, and lower resource utilization, making it a natural choice for fast-paced business-critical applications.

In this article, we look at PHP 7.1 features, performance comparisons, end of life, and why the PHP 7.1 release marked such a big change for PHP.

PHP Internals News: Episode 59: Named Arguments – Derick Rethans

PHP Internals News: Episode 59: Named Arguments

In this episode of “PHP Internals News” I chat with Nikita Popov (Twitter, GitHub, Website) about his Named Parameter RFC.

The RSS feed for this podcast is https://derickrethans.nl/feed-phpinternalsnews.xml, you can download this episode’s MP3 file, and it’s available on Spotify and iTunes. There is a dedicated website: https://phpinternals.news

Transcript

Derick Rethans 0:18

Hi, I’m Derick, and this is PHP internals news, a weekly podcast dedicated to demystifying the development of the PHP language. This is Episode 59. Today I’m talking with Nikita Popov about a few RFCs that he’s produced. Hello Nikita, how are you this morning?

Nikita Popov 0:35

Hey Derick, I’m great. How are you?

Derick Rethans 0:38

Not too bad, not too bad today. I think I made a decision to stop asking you to introduce yourself because we’ve done this so many times now. We have quite a few things to go through today. So let’s start with the bigger one, which is the named arguments RFC. We have in PHP eight already seen quite a few changes to how PHP deals with set up and things like that we have had an argument promotion in constructors, we have the mixed type, we have union types, and now named arguments, I suppose built on top of that, again, so what are named arguments?

Nikita Popov 1:07

Currently, if you’re calling a function or a method you have to pass the arguments in a certain order. So in the same order in which they were declared in the function, or method declaration. And what named arguments or parameters allows you to do is to instead specify the argument names, when doing the call. Just taking the first example from the RFC, we have the array_fill function, and the array_fill function accepts three arguments. So you can call like array_fill( 0, 100, 50 ). Now, like what what does that actually mean? This function signature is not really great because you can’t really tell what the meaning of this parameter is and, in which order you should be passing them. So with named parameters, the same call would be is something like: array_fill, where the start index is zero, the number is 100, and the value is 50. And that should immediately make this call, like much more understandable, because you know what the arguments mean. And this is really one of the main like motivations or benefits of having named parameters.

Derick Rethans 2:20

Of course developers that use an IDE already have this information available through an IDE. But of course named arguments will also start working for people that don’t have, or don’t want to use an IDE at that moment.

Nikita Popov 2:31

At least in PhpStorm, there is a feature where you can enable these argument labels for constants typically only. This would basically move this particular information into the language, but I should say that of course this is not the only advantage of having named parameters. So making code more self documenting is one aspect, but there are a couple couple more of them. I think one important one is that you can skip default values. So if you have a function that has many optional arguments, and you only want to say change the last one, then right now you actually have to pass all the arguments before the last one as well and you have to know: Well, what is the correct default value to pass there, even though you don’t really care about it.

Derick Rethans 3:19

If I remember correctly, there are a few functions in PHP’s standard library, where you cannot actually replicate the default value with specifying an argument value, because they have this really complex and weird kind

Truncated by Planet PHP, read more at the original (another 22256 bytes)

PHP 8.0.0 Alpha 1 available for testing – PHP: Hypertext Preprocessor

The PHP team is pleased to announce the first testing release of PHP 8.0.0, Alpha 1. This starts the PHP 8.0 release cycle, the rough outline of which is specified in the PHP Wiki. For source downloads of PHP 8.0.0 Alpha 1 please visit the download page.Please carefully test this version and report any issues found in the bug reporting system.Please DO NOT use this version in production, it is an early test version. For more information on the new features and other changes, you can read the NEWS file, or the UPGRADING file for a complete list of upgrading notes. These files can also be found in the release archive. The next release will be Alpha 2, planned for 9 Jul 2020.The signatures for the release can be found in the manifest or on the QA site.Thank you for helping us make PHP better.

Unit test naming conventions – Matthias Noback

Recently I received a question; if I could explain these four lines:

/** * @test */
public function it_works_with_a_standard_use_case_for_command_objects(): void

The author of the email had some great points.

  1. For each, my test I should write +3 new line of code instead write, public function testItWorksWithAStandardUseCaseForCommandObjects(): void
  2. PSR-12 say that “Method names MUST be declared in camelCase”. [The source of this is actually PSR-1].
  3. In PHPUnit documentation author say “The tests are public methods that are named test*” and left example below
  4. PHPStorm IDE from the last version gives for you ability to generate a TestCode and they do not use an underscore too:

    PHPUnit generating test code

  5. I opened a popular frameworks (Symfony, Laravel, YII2, CodeIgniter4) test folders in Github and then I opened a popular PHP library and also do not find underscore usage in test and @test annotation.

This made me realize that, yes, what I’m doing here is a convention, and maybe it’s not the most popular one.
Well, I’ve seen tests that use an even less conventional approach to method naming by using some kind of character that isn’t a space but still looks like one:

/** * @test */
public function it works with a standard use case for command objects(): void

This is too much for me, but who knows, in a couple of years maybe…

I’ll first respond to the objections now:

  1. I don’t think it’s bad to write 3 new lines for every test method.
    It’s not like it’s actual code that gets duplicated, it’s just an annotation.
    The code never has to be modified, so it will never suffer from Shotgun Surgery (unless you switch test frameworks maybe).
    Anyway, I have a live template configured in PHP so I only have to type it and it will complete this with /** @test */ public function etc. We’ll talk about it later.
  2. Philosophically speaking, I don’t think a test method is a regular object method.
    Yes, of course, it is technically a method. PHPUnit instantiates your TestCase and will call its methods.
    But that is just the way PHPUnit does it.
    You might as well write something like this:

    it('works with a standard use case for command objects');
    

    In fact, there are test frameworks that let you write tests like this.

    You will never find any normal code (a.k.a. production code) call these test methods.
    I do think that would look rather weird.

    Instead of regular methods, I think we should consider test methods to be documentation or more specific: specification.
    This makes other aspects than code style conventions more important: it needs to be readable and precise.
    And in my experience testItWorksWithAStandardUseCaseForCommandObjects is really hard to read.
    Then again, maybe I just have to practice.

    But what if your code style fixer automatically turns “snake_case” method names into camelCase ones?
    Just configure the tool to ignore your tests.

  3. The way things are done in framework documentation can, but doesn’t have to be considered the standard.
    The writer of the documentation has different goals than you have.
    Maybe they want to show the easiest way to get started with their framework.
    Maybe they just show the way that most users do it.
    Maybe nobody knows what most users do, and they just pick a way.
    What I do know is that the PHPUnit documentation also mentions this other way: “Alternatively, you can use the @test annotation in a method’s docblock to mark it as a test method.”
  4. Although I love PhpStorm, I’m totally not inclined to do as they do.
    As an example, they have invented the convention that we have to annotate all the exceptions that a method throws.
    They also have an inspection that warns you about calling a method that could throw an exception.
    I bet that a lot of developers have since been wrapping things in try/catch blocks and coming up with inventive ways of dealing with exceptions.
    Not because we have to, but because the IDE developers thought it would be a good idea.
    End of rant.
    Conclusion: don’t let the IDE determine how you write your code (unless you have thought about it and agree with it of course).
    When it comes to generating a test class and “generating test methods”: totally ignore what PhpStorm h

Truncated by Planet PHP, read more at the original (another 4445 bytes)