TL;DR; Phpactor documents itself
In Phpactor there are lots of units of code which add a category of functionality. One such examples is a Diagnostic Provider. Diagnostic providers provide diagnostics which provide feedback about your code:
a diagnostic being shown in Neovim
The old process for testing a diagnostic provider involved many steps and was tediously time consuming, and there was no documentation for diagnostic providers at all.
Why not tediously invest time in a tedious solution which will make future work less tedious?
There are few things that I really like about Phpactor, but its DI Container [link] is one of them.
In seven years it has hardly changed at all. It’s modular, supports tags, parameters (with schemas) and the has only 233 lines of code including comments and whitespace
There is no YAML, XML or compilation. No auto wiring, no property injection, factory modifiers, weird ways to extend services. All services are singletons.
One morning I sat down at my laptop and looked at a Go service, written 2 months previously, that represented my first attempt with the language. When I wrote it I had been unsure about everything, questioning each line and frequently googling things like “how to do a foreach in Go”. In just two months I was now able to look at this code and immediately see several ways in which it could be improved.
PHPBench currently samples the time taken (in microseconds) to run code around a loop.
This post aims to provide some insight into:
If there is a benefit to using a loop (@Revs) when taking a time sample. The value of using hrtime instead of microtime. Background ¶ PHPBench samples the time taken for your code to run. The default executor does this by iterating over your code a number of times (@Revs) and dividing the total time in microseconds (i.
PHPBench 1.2.0 has been released, the highlights are:
In reports you can now dynamically create and group columns in tables Memory can be displayed in binary memory units Support for filtering by variant name Support for filtering reports Report Improvements ¶ PHPBench 1.1.0 improved report generation, allowing you to use components such as tables and bar charts.
This release improves table generation, adding support for grouping and expanding columns dynamically:
PHPBench 1.1.0 as been tagged!
PHPBench 1.0 removed many features, most were deemed useless, the HTML report was an exception and it has been re-introduced in 1.1 along with other improvements, some of the more notable ones being:
“Safe” parameters: You can now use any serializable class as a parameter. This change included some internal refactorings and I have, to the best of my knowledge, preserved the B/C promise. $include and $include-glob configuration directives to include other configuratoin files.
The templates we use in our favourite MVC frameworks are awful. You pass an unstructured bunch of data to a template which hopes the you passed everything it needed. They do not define what their inputs are, they are not type safe.
For some years I’ve been using a different way of rendering views - it started when I was trying to create a new CMS framework, but since then it has come in useful time and time again.
PHPBench 1.0.0 as been tagged!
I started this project in 2015, I’d like to say I’ve been working on it for six years, but really I worked hard on it for about 6 months to a year and then largely ignored it when I started another project phpactor - which began with me wondering how easy it would be to add PHP auto completion in VIM and ended up with me writing a language server and “maintaining” over 50 packages.
PHPBench Alpha 5 as been tagged.
I tagged PHPBench Alpha 1 in about 5 months ago since that time numerous improvements and features have been introduced, I will talk about three of them.
Local Executor ¶ One problem I had when developing benchmarks is that it’s difficult to debug when the benchmark launches in a separate process, for this reason there is now the local executor:
$ phpbench run --executor=local Will run the benchmark in the same process as PHPBench, allowing you to do whatever you need to do (var_dump($foo);die()) to debug your benchmark.
TL;DR; Maestro is a package maintenance automator which is in development.
It’s Christmas and Phpactor needs to be upgraded to PHP 8.0, but Phpactor has many packages:
$ composer show | grep phpactor | wc -l 42 Most of these packages were created almost 4 years ago, and have been updated little by little as necessary.
Even editing the composer.json file to allow PHP 8 for each repository is a big task - not to mention needing to migrate from Travis to Github Actions (as Travis has become unusable in the past months with build times sometimes taking an hour) - and that’s before I can even start manually editing all the test suites to be compatible with PHPUnit 9.
PHPBench is over 5 years old. I started working on it because I wanted to write a new implementation of the PHPCR spec, and I wanted to ensure that it was faster than the existing Jackalope implementation, I needed a framework to write a large number of performance tests. The existing Athletic framework didn’t quite meet my needs so I decided to write my own.
I didn’t write the next PHPCR implementation (luckily, it would have been terrible) but I did spend the next several months working on PHPBench, a large part of it was written while I was cycling from Vorarlberg (Austria) to Ankara going back through Greece and up to Slovenia.
We had an issue today where a CSV file was being read via. SplFileInfo.
The array keys were being inferred from the headers, and the values transformed based on rules per column.
The issue was that the column was not found:
// data read from CSV $data = [ 'SALUTATION' => '1', ]; var_dump($data['SALUTATION']); // UNDEFINED INDEX ERROR Very confusing!
It turns out that the CSV file was prefixed with a byte order mark, which was being incorrectly parsed into the first header (SALUTATION).
I have been keeping my timelogs in a plain-text timesheet format as follows:
2019-02-11 09:00 [JIRA-1234] Adding some functionality 10:00 [standup] 10:15 [JIRA-1234] Fixing that annoying bug 11:00 [JIRA-2134] Review 12:00 [lunch] 13:00 [JIRA-1234] @pairing 14:00 [confused] 18:00 [finish] 2019-02-12 09:00 ... Bascially, it’s much quick to log my time realistically. I don’t need to continually break my concentration and assign time to tickets as I work on them, or strain to remember (or make up) what I did at the end of the day, or even at the end of the week.