Php

We have hackdays this week, so this is a bit early. Schneier: The Pentagon Is Publishing Foreign Nation-State Malware https://www.schneier.com/blog/archives/2018/11/the_pentagon_is.html Android: a 10-year visual history https://www.theverge.com/2011/12/7/2585779/android-10th-anniversary-google-history-pie-oreo-nougat-cupcake Kellan: What I’m up to: tech leadership http://laughingmeme.org/2018/11/12/what-im-up-to-tech-leadership/ The next version of HTTP won’t be using TCP https://arstechnica.com/gadgets/2018/11/the-next-version-of-http-wont-be-using-tcp/ New – Redis 5.0 Compatibility for Amazon ElastiCache https://aws.amazon.com/blogs/aws/new-redis-5-0-compatibility-for-amazon-elasticache/ PageSpeed Insights, now powered by Lighthouse https://webmasters.googleblog.com/2018/11/pagespeed-insights-now-powered-by.html Basecamp: Postmortem on the read-only outage of Basecamp on November 9th, 2018 https://m.signalvnoise.com/postmortem-on-the-read-only-outage-of-basecamp-on-november-9th-2018-9165c315ee7f Answer these 10 questions to understand if you’re a good manager https://qz.com/work/1447711/how-to-tell-if-youre-a-good-manager/ Stripe’s Will Larson on Designing a Performance Management System from Scratch https://blog.gitprime.com/designing-performance-management-systems/ Code As Craft with Rasmus Lerdorf | Nov 13th, 2018 https://www.youtube.com/watch?v=WJJKZM8bruQ New – EC2 Auto Scaling Groups With Multiple Instance Types & Purchase Options https://aws.amazon.com/blogs/aws/new-ec2-auto-scaling-groups-with-multiple-instance-types-purchase-options/ Schneier: More Spectre/Meltdown-Like Attacks https://www.schneier.com/blog/archives/2018/11/more_spectremel.html

Google Geo Developer Blog: Marker Clustering and Heatmaps: New features in the Google Maps Android API Utility Library http://googlegeodevelopers.blogspot.de/2014/02/marker-clustering-and-heatmaps-new.html HHVM and Hack – Can We Expect Them to Replace PHP? http://www.sitepoint.com/hhvm-hack-part-1/ What Application Layer Does A DI Container Belong In? http://paul-m-jones.com/archives/5914 Mockery 0.9.0 Has Landed…Mostly In One Piece! http://blog.astrumfutura.com/2014/02/mockery-0-9-0-has-landed-mostly-in-one-piece/ Coding Standards: Humans Are Not Computers http://blog.astrumfutura.com/2014/02/coding-standards-humans-are-not-computers/

I have confess that this was shorter than I would have thought or wished for, but Thursday is my last day at Splendia. Splendia is a very different company from my previous employer Softonic. While Softonic has all the perks and advantages of a big successful company with a large development team. Splendia is much smaller and when I arrived the whole team had just arrived too and was confronted with a "legacy" code base. The amount we managed to do in this year is just amazing and this wouldn't have been possible without the brilliant team. Fernando (the CTO when I started), recruited very well and made everyone fit in right away. We changed everything, from introducing scrum sprints, going from zero to 3000 unit tests, re-factoring big parts of the system, continuous integration, functional testing and everything else you expect from a modern Internet company. I gave a talk at WeLovePHP last weekend, which talked about all of this. I leave because of changes in the structure of the company and because I have the opportunity to join an exciting new project. More about this when I have started...

Today I gave a talk at WeLovePHP, which is a quarterly talk and workshop series organized by Softonic in Barcelona. They also do one about JavaScript. I can highly recommend them if you are interested in PHP, JavaScript or related topics. I talked about the processes and tools we are using at Splendia. There are no pictures in the slides … sorry.

As hopefully most people working on software projects nowadays we are writing unit tests and do code reviews. Work-flow at Splendia As our project is a large PHP site we are using PHPUnit for unit testing and various static code checking tools (checkstyle, phpmd, pdepend, phpcpd) to verify the quality of our code. All of these are run on our integration branch, whenever a new feature is integrated. Before this can happen the code will be reviewed by other people in the team and only if there is a consensus it will be merged into the integration branch. For the code reviews we are using the pull request system of github. It works very similar to other code review tools, you see a diff view of the changes and are able to add comments to discuss the code. In these comments we are using a convention of "+1", "-1" and "[B]" to give the pull request a thumbs up, down or mark it as blocked because a critical bug was found. Anyone in the team has a vote and is allowed to discuss any request. In addition to this the unit tests and some smoke tests will be run on the code of the pull request to avoid merging broken builds. Only if the tests are successful, there are three positive votes in total and no blocker the request will be merged. In the beginning all of this was done manually. Developers had to run the tests before the created the pull request and only senior developers had the right to merge a pull request. Every couple of hours they would check the list of pull requests and verify that they had enough votes. It was a distraction and also prone to mistakes. What gave us a big push in productivity was the introduction of two tools to the work-flow. ghprb First the GitHub pull request builder plugin, which enables Jenkins to automatically start a job for each pull request. It has additional features, like starting another build if more commits are added or recognising comments that instruct it to retest or white-list people who are allowed to create builds. It is similar to the pull request feature of Travis-CI only with the full possibilities of Jenkins to your disposal. With this we are testing every pull request before it gets merged. We also run a limited set of static code analysis, because we want to keep this build fast to give quick feedback. Currently it takes around seven minutes. PullRequester / plus-pull The second tool is a simple script which was written by one of our developers and it was called PullRequester. It runs as a cron job and checks whether the pull requests satisfy the +1 and successful test rules. If all is OK it automatically merges it. I have reimplemented this script to make it possible to publish it. You can find it under the name plus-pull on github. I have added some more features to make it also useful for open source projects. Final Words Even though these tools are not magic the increase of our productivity was visible. I account this mostly to way it enabled asynchronous working. No developer has to wait for a senior developer or poke someone to merge his code. As long as he can find three people who agree it will be merged automatically. And as everyone is interested in reviews themselves they tend to happen quickly. In the screen-shot you can see how this works in practice.