sMite stands for ‘simple Mite’, which to most people still means nothing at all. Mite is a time tracking web service, and depending on how companies make use of it things can become more complicated than they should be.
smite is how I tried to tackle this complexity in less than 8 hours!
My first and currently only Joomla component development was for the SWA UK website. The component manages memberships, events, tickets, results and more and is a rewrite of a previous component for Joomla 1.
But in this post lets ignore what the component does and instead concentrate the development workflow that is used. After lots of research at the beginning of development I decided to ignore other methods of developing a component and this is what I ended up coming up with.
Recently some articles appeared on the English Wikipedia Signpost about Wikidata (1, 2, 3). Reading these articles, especially the second and third, pushed me to try to make a dent in the ‘problem’ of references on Wikidata. It turns out that this is actually not that hard!
Recently I switched from using Guzzle 5 to Guzzle 6 in my mediawiki-api-base PHP library. Everything went very smoothly except for there being no compatible version of the retry-subscriber that I had previously used. The subscriber has been replaced by retry middleware of which I was provided an extracted example. In this post I cover my implementation for the mediawiki-api-base library.
Roughly a year and a half ago I started writing a collection of PHP libraries to make interaction with the Mediawiki API and extension APIs super easy. The base library has just made it to 2.0.0!
The new release really only uses the new version of the Guzzle HTTP library which makes use of PSR-7 and adds async get and post methods using the Guzzle promise library.
This library is the first of the addwiki collection that has actually reached 1.0.0 let alone 2.0.0! All of the other libraries, including wikibase-api and mediawiki-api are still a work in progress with lots to be added. The next likely to be released will be the wikibase-api library once I try to also add async functionality there!
A snippet of the async functionality added in mediawiki-api-base can be seen below:
// Get an API object and login
$api = MediawikiApi::newFromPage( 'https://en.wikipedia.org/wiki/Berlin' );
$api->login( new ApiUser( 'username', 'password' ) );
// Initiate each request but do not block
$requestPromises = array(
'Page1' => $api->postRequest( FluentRequest::factory()->setAction( 'purge' )->setParam( 'titles', 'Page1' ) ),
'Page2' => $api->postRequest( FluentRequest::factory()->setAction( 'purge' )->setParam( 'titles', 'Page2' ) ),
'Page3' => $api->postRequest( FluentRequest::factory()->setAction( 'purge' )->setParam( 'titles', 'Page3' ) ),
// Wait on all of the requests to complete.
$results = Promise\unwrap( $requestPromises );
// You can access each result using the key provided to the unwrap function.
print_r( $results['Page1'], $results['Page2'], $results['Page3'] )
Recently I have been spending lots of time looking at the Wikimedia graphite set-up due to working on Grafana dashboards. In exchange for what some people had been doing for me I decided to take a quick look down the list of open Graphite tickets and found T116031. Sometimes it is great when such a small fix can have such a big impact!
I don’t mean Mediawiki is crap! The Change Risk Anti-Patterns (CRAP) Index is calculated based on the cyclomatic complexity and code coverage of a unit of code. Complex code and untested code will have a higher CRAP index compared with simple well tested code. Over the last 2 years I have been tracking the CRAP index of some of Mediawikis more complex classes as reported by the automatic coverage reports, and this is a simple summary of what has been happening.
Now if you have ever come across issues caused by non strict comparisons before then this is going to seem like a piece of cake, but remember, everyone makes mistakes.
Strict equality compares two values for equality where the values must also be the same type. Non strict or loose equality compares values while not caring about their type. Strict equality is almost always the correct comparison to use, and if it is not used when it should be many unexpected things can happen.