Category Archives: Allgemein

Do I belong on the speaker list of a conference?

Recently a friend of mine wrote about why he didn’t submit to the Call for Papers for a Conference. And – even though the reasoning is absolutely straight forward – I felt that it was wrong. It took a while for me to realize what exactly it was.

I’m not a conference-organizer myself, I only know that it it a tough job. And keeping the balance between known and reliable speakers that help sell tickets and new faces that can become the next reliable and known speakers must be a challenge. And then trying to also have a balanced amount of speakers from usually underrepresented groups1 in tech must be even harder. And being one of those “white males” that seem to be everywhere on tech conferences I can’t feel how it is to be underrepresented.

But I am pretty sure of one thing. When conference-organizers are going through the trouble of doing a Call for Papers it’s not because they already know whom they want to speak or they will reject your talk because they think you’re not good enough! They want bright people to speak! They want people that know their topic! They want people that have something to say! And that might even include You!

There is only one way to be sure that you do not belong onto the speaker list of any conference that has a Call for Papers. And that is by not submitting!

But when you submit, chances are that the conference organizers think that You are one of those bright people they are looking for! That You are one of the people that know their topic! That you are one of the people that have something to say! In short: That You are the right person to speak!

Yes, chances are much higher that you’ll receive a rejection letter. But that happens to every speaker2. But by not submitting you will not even receive a rejection letter.

I know from myself that Impostor-Syndrome has a lot to do with it. But just because you think you don’t belong onto that speaker-panel doesn’t mean that others think different! And that you earned your place “up there”. But for that you have to show that you want to sit up there!

So next time you’re thinking about whether to not participate in a Call for Papers because you don’t think you belong there: Leave that decision to the conference organizers!

Or do you think different?

1whoever belongs to these underrepresented groups is a completely different story!
2https://tessamero.com/blog/open-source-thoughts/item/so-your-talk-wasnt-selected

Voting to replace the current voting representative of the Aura project

Currently the FIG-Members vote whether the Aura-Project is required to replace its representative. Why is that?

During the last few weeks (months?) the mailinglist of the Framework Interoperability Group (PHP-FIG) was home to the drama-lama. A lot of push and shove around one single person and how to react appropriately.

I try to be as objective as possible: Apparently some people from the PHP-Community felt harrassed by the way one person discussed with them. And that one person seemed to “look for trouble” by pushing discussions and raising issues in an aggressive manner. I myself know of at least one person that didn’t get involved with the FIG due to this person. And there are others that left the FIG due to or felt personaly attacked by that person.

So the representatives of the FIG where asked to do something about one person creating a toxic atmosphere. Due to there not being a precedence for such a behaviour and there being no clear regulations for such a case things went messy. Heated debates and unlucky words from both sides where the result of the question how to handle people that create a toxic environment, cause people to leave the FIG and damage the reputation of the FIG.

Long story short: There is no way the FIG can do something against such a person without a regulation that every new participant accepts. Call it CoC or nettiquette or bylaws or whatever you like. There’s common sense and general niceness but some people just lack both. And as such a regulation isn’t (currently) accepted by people on the FIG-mailinglist, there’s no way of removing someone from the list.

But what can be done is that said person can not speak as a member of the FIG anymore. And that’s what the vote is about. Revoke the privilege of being heard as an authority of the FIG and making it absolutely clear that the FIG does not condone such behaviour that drives others away and makes people feel attacked.

The vote is not about the expertise or about liking or not liking. It’s not about questioning the FIG, it’s bylaws, regulations or PSRs.

This vote is about the tone and way of interacting with one another. And it is about whether or not the members of the FIG accept agressive and harassing interaction with one another – and by accepting it actually promoting it.

But it can not be the last step. No one should think that the case is closed after this vote regardles it’s outcome. In my eyes the FIG needs a regulation that allows banning of people that don’t adhere to them from participation altogether (throughout the ir controlled media). But that’s a next step!

For me personally the result of this vote will decide about the future of the FIG in the PHP-Community

To commit composer.lock or not

Whether to commit a composer.lock-file to a repository or not seems to be a somewhat religious decision. Either you follow Raphael Dohms and commit your lock-file or you follow Marco Pivetta and you don’t.

But I think the truth is somewhat in between.

Recently I decided to create a badge for Badge Poser that shows whether the lock-file is commited or not. It’s something you can see easily from the repo but hey, it’s a fun project!

And instantly I stumbled over a commited lock-file! Because as it seems, commited composer.lock-files can be a blessing or a curse. What happened? I thought – as the project commited their composer.lock-file – it would be a good idea to run a composer install instead of a composer update. After all I should be left with a working installation after the install-command. That’s why we would commit the lock-file in the first place, isn’t it?

But as it turned out, the composer.lock-file was created some time ago with a now hopelessly outdated PHP-version. I have PHP 7 running on my machine, but the composer.lock-file obviously was created using something like PHP 5.3 or PHP 5.4. So instead of getting a running version of the project, I got composer yelling at me that it can’t resolve an installable version of my lock file. Hm.

Version mismatch

So it looks like it’s dependent on the PHP-Version you are running whether the composer.lock can be used or has to be updated. Sadly there’s no hint that tells me which PHP-Version the file has been created with so I will have to test whether an install will work or not.

Entry the “config/platform”-parameter. It allows the creator of a package to specify what PHP-Version should be used to resolve the dependencies regardless of what the actual PHP-Version is. This might have the consequence of installing useless packages as installed packages might not work on the installed PHP-Version.

So one thing to have in mind when committing or receiving a composer.lock-file is, that it contains a set of dependencies, that was working for the committer but it might not work for the user as the environment might have changed to a point where the packages of the composer.lock-file might not be usable anymore. Consider a locked Version of phpunit/phpunit:4.8 because the file was created using PHP 5.5 and you are running PHP 7.

Dev-Mismatch

The second thing that came to my mind was that the lock-file might or might not contain the dev-requirements. So when you are developing a lib you’d want other developers to have the same versions of your dev-tools so it’s a good idea to have them in the lock file. And when you are developing a web-project (website of a certain extend) you might want to use the lock-file to automatically deploy the libs you where testing agains. But as it’s for deployment you’d create the lock-file without the dev-dependencies. That will then leave other developers without the dev-dependencies, so they will have to run a composer update (because composer install will tell you that you should either run composer install --no-dev or composer update) anyway.

And also when you do automated testing against the lowest,locked,latest-strategy you might run into issues with locked packages not being able to run on the current platform even though they are installed without an issue. Have a look for example at https://travis-ci.org/heiglandreas/composerlocktest/jobs/133745846. The test fails due to PHPUnit being installed in the wrong version due to that version being locked in the composer.lock-file

Conclusion

Be careful when you commit your lock-file. Indicate clearly what PHP-Version you used when creating it. Either by providing the suggested version using the platform-Parameter or by pointing it out in the documentation very clear. And remember to only automatically test the locked dependencies with the PHP-Versions you created the composer.lock

Be careful when you use a lock-file. Check whether there is a hint to the provided version in the composer.json file or in the documentation of the project you are using. Have a look at the CI-config-file, it might give you a hint.

Timezones and PostgreSQL

After the aforementioned talk (and in preparation to the next installment of it) I checked how to do the MySQL-Example in PostgreSQL. It’s easily possible, but it takes a bit more time to get around to it. But hey, it’s a tool for grown-ups, isn’t it? 😉

Again we create the table using this snippet:

CREATE TABLE datetime(
  zeit timestamp without time zone,
  zone character varying(255)
)

INSERT INTO datetime (zeit, zone)
VALUES
    ('2014-03-04 12:23:34','Europe/Berlin'),
    ('2016-05-03 23:12:23','Europe/Busingen'),
    ('2016-05-03 23:12:23','America/Chicago')
;

So to select all entries that are before 14:00H in UTC-Timezone in PostgreSQL we’ll use this query:

SELECT * FROM datetime 
WHERE 
    extract(HOUR FROM zeit AT TIME ZONE zone AT TIME ZONE 'UTC')
    <= 14;

Here we tell PostgreSQL to interpret the value in zeit as localtime in timezone zone and then to convert that to timezone UTC. It will output this:

2014-03-04 12:23:34 | Europe/Berlin
2016-05-03 23:12:23 | America/Chicago