Author: William Turrell

Kindle Paperwhite 2018 detailed review

Updated 4 May 2019

This is only after a few day’s ownership – but I’ll keep it updated.  I’m comparing this (a Paperwhite 10th generation) to my previous (refurbished) Kindle basic 7th generation which I used for ~ 2 years.

– The 300dpi screen *is* worth it. Text is sharper at lower sizes.  Individual characters are less ‘damaged’ and faded after screen refreshes or actions like requesting and dismissing the dictionary window etc. Photos and illustrations (still black and white obviously) look great, compared to ‘ok’ on the lesser screen.
– The Paperwhite case is much more comfortable to hold than the harsher, more sharply edged plastic in the previous design.
– Page turns are definitely snappier than the Kindle 7. (In comparison, this has a next generation display, greater RAM and a newer processor).
– It doesn’t crash as often when reading The Times (which I don’t read everyday, but it has crashed once, so there’s clearly still some problem there, my theory being it’s the size of the paper: the .pobi file – the Kindle periodicals format – is ~ 25MB compared to roughly 5MB for the New York Times and much smaller sizes for books.)

Update Feb 2020: it hasn’t crashed in months (software version 5.12.3, Dec 2019)

– Battery life seems a little better (it takes longer to charge, which is always a good sign) – at best my old Kindle was lasting 4-5 days between charges (with heavy use).
– The white front light is better than I expected (very even, works well at night at levels ~7,8,9,10). It’s especially good indoors during daylight where you have an average or low amount of light coming through the window: in these situations it genuinely does boost the background to “paper white”, and helps reduce unwanted shadows from your hands cast on the screen, without you thinking you are looking at an illuminated display.
– The “Invert black and white” option (see Settings, Accessibility) is less good than I expected (the grey background is too prominent).
– The entirely flat screen takes a little getting used to – it’s quite easy to slide your thumb over the next article link at the bottom of newspapers / magazines by accident. However you don’t have the issue of false infra-red triggers by other objects.
– There’s a power save feature on these models.  I believe it’s activated after one hour in standby – the ‘Waking up’ period each time is 3-4 seconds.

When you get it:

– You need to login to Amazon manually
– You need to enter wifi credentials
– It’ll likely not be running the very latest software (mine seemed to update after I’d connected it to a charger)
– You receive a new @kindle.com email address, so you will need to change address books or 3rd-party services such as Instapaper, otherwise documents will continue to go to your old device.

Things you need to do on Amazon site (‘content and devices’ section):

– Change your default Kindle device
– ALSO you have to edit the ‘subscription settings’ for any newspaper or magazine (Change the ‘Deliver future editions to’ setting) – this doesn’t happen for you, even after changing the default device.

Other caveats:

– Vocabulary builder, My Clippings etc. starts from scratch on a new Kindle
– A short USB charging cable I’d been using for my old Kindle, which I chose to plugin through an Apple wired keyboard (the keyboard has 2 USB sockets of it’s own) didn’t work properly with the new Kindle – macOS complained the power drain was too high and kept shutting the ports down. However as soon as I connected the new supplied lead, it worked correctly.

The lesson is to not always trust cables or assume all micro-USB to USB are created equal.

If anyone would like my old (fully working) Kindle or can suggest a good place to recycle in the UK, send me an email.

Fixing invalid public key for packages.sury.org

Update 21 March 2021: there’s been a recent uptick in traffic to this page – the current problem everyone is having is due to an expired key.  Read more in this deb.sury.org github issue.

Solution (Debian 10.8 Buster):

(comments in various places suggest removing the old key is crucial)

sudo apt-key del B188E2B695BD4743
sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

Useful command worth noting:

apt-key list

Original April 2019 blog post:

If you’re running Debian and using:

deb https://packages.sury.org/php/ stretch main

(it might be in /etc/apt/sources.list.d/php.list rather than the usual sources.list)

… you may see this error:

Err:5 https://packages.sury.org/php stretch InRelease
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php stretch InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743
W: Failed to fetch https://packages.sury.org/php/dists/stretch/InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY B188E2B695BD4743
W: Some index files failed to download. They have been ignored, or old ones used instead.

This isn’t widely blogged yet, however the best source of info is the Issue queue for the deb.sury.org GitHub repository – it turns out that in mid-March, the key for each repository on sury.org was regenerated due to a compromised server.

Here’s the command to download the new one, after which apt will work as expected.

sudo wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg

 

Drupal 6 Nginx config fragment

Here, for anyone needing to host a D6 LTS site, is a working Nginx fragment (tested with Nginx 1.10.3).

You can reuse your standard Drupal 8 config for everything else (e.g. images, protecting private files and so on).

# Drupal 6 LTS
index index.php;

location / {
    if (!-e $request_filename) {
       rewrite ^/(.*)$ /index.php?q=$1 last;
    }
}

Ordinarily, for modern Drupal sites, I’d use the following standard try_files statement, but I couldn’t get it serve D6 subpages correctl (it just redirects to the homepage, even with the q=… added – email me if you know why).

# Drupal 8
location / {
    try_files $uri /index.php?$query_string;
}

 

 

 

Drupal 6 – troubleshooting ‘Site off-line’ db error

A straightforward problem, but one I’ve wasted time on when setting up a D6 LTS site.

Symptom:

The site is currently not available due to technical problems. Please try again later. Thank you for your understanding.

If you are the maintainer of this site, please check your database settings in the settings.php file and ensure that your hosting provider’s database server is running. For more help, see the handbook, or contact your hosting provider.

The uncommented example line in default.settings.php is:

$db_url = ‘mysql://username:password@localhost/databasename’;

I spent some time verifying usernames/passwords and adjusting ansible scripts, what I hadn’t noticed was I need mysqli (Mysql Improved – which has been around since way with mysql v4.1.3), not mysql.

So remember to check the connection protocol as well as the credentials.

 

Drupal – troubleshooting PHP files downloading rather than executing

A fairly straightforward problem that won’t be unique to Drupal, but you may run into when migrating PHP applications from other hosts.

I was reviving an old D6 site that had been hosted on another ISP (Hostgator, as it happens) and on setting it up on Acquia DevDesktop (which is a local MAMP stack) found PHP wouldn’t execute as normal.

First, isolate the problem:

  • i.e. do other sites besides this one, running on the same computer (typically you’ll get this problem on a local dev setup) work correctly?
  • create a test PHP file (e.g. containing  <?php echo "Hello, world!";  or <?php phpinfo(); and load it

Solution in my case:

  • check the .htaccess – it had the following, which was redirecting all PHP requests to a PHP  binary that didn’t exist.  Once commented it out PHP could run correctly.
# $Id$
# Use PHP56 as default
AddHandler application/x-httpd-php56 .php
<IfModule mod_suphp.c>
 suPHP_ConfigPath /opt/php56/lib
</IfModule>

Of course any .htaccess files become irrelevant if you move your dev or production sites to Nginx, but it’s a good idea to read through it anyway.

Things I never knew existed: Gitk

Gitk is a built-in GUI repository browser for Git.

There are options, but to begin with, just launch it by typing gitk

It’s fast and handy if you just want to quickly browse commits or staged/unstaged files and don’t have an alternative GUI app.

Also a useful companion if you’re doing interactive staging.

You can instantly search full commit messages (matching commits will be shown in bold, remember to set IgnCase otherwise the search is case sensitive).

You can also use the touching paths option to look for files affected by a commit, and you can search by strings added or removed or changing lines matching.

There’s a second search box for finding things in the diffs.

You can modify colours, fonts and so on.

NB: Sourcetree has command line tools as well (so you can type stree, though I couldn’t get them to install properly when I tried).

Utility first CSS – observations / lessons learnt

I’ve been trying Tailwind CSS recently.  I’ll likely to continue using it.

People talk about Component First vs Utility First CSS frameworks – in my opinion the important word here is “first” – you should use your own best  judgement to combine the two techniques.

  • Start prototyping the design using atomic styles.
  • Observe where you’re reusing the same styles a lot and/or it’ll be a pain (e.g. paragraphs of body text)
  • Build components for these using @apply in your CSS file (between @tailwind components; and @tailwind utilities;)
  • Don’t bother build components for things you are unlikely to reuse.

Does the HTML source code look a horrible with all those styles? 

A bit when you very first see it.  But:

  • most code you didn’t write yourself looks confusing initially
  • maybe your CSS file looks confusing close up too

There are several ways Utility First can save time:

  • You’ll be switching back and forth between HTML and CSS rather less
  • There won’t be as much friction in the early stages of building the site (you’ll be plugging in atomic classes and seeing the results straight away, you won’t be worrying about how to name things or constructing BEM selectors) – however you should keep an eye out for when you need to build a component.
  • Obviously for a while you’ll be referring to the framework’s documentation a lot to learn the class names, but in the case of Tailwind CSS there’s an autocomplete search field on the site.  The abbreviations for margin, padding, flexbox etc., once learnt, are logical and easy to remember.
  • I find specifying code for screen breakpoints a lot simpler (typically I end up with lots of nesting in conventional CSS/SASS).
  • No maths needed when building grids etc.

Can you still customise everything?

Yes. Your tailwind.js config defines everything – colours, breakpoints, font  sizes, font families, leading, the grid etc. etc.

Who’s it good for:

  • Developers who aren’t working in CSS every single day and can’t remember the intricacies of flexbox or grids.
  • Anyone who doesn’t want their site to look like every other Bootstrap site (or any other framework that comes with pre-built components)

Can you still use it with SASS?

Yes (my typical build process for static sites uses Gulp and PostCSS)

Performance issues

There are two aspects to this, the CSS file size/download speed, and the speed the browser can process the quantity of selectors in it.

By default Tailwind will generate a very large CSS file with several thousand selectors.  But with a little optimisation (turning off unused colours and screen sizes) you can dramatically reduce this.   Also, the size is modest if served minified and gzipped.

Further reading:

Memcached and PHP 7.3

Update – Sep 2019: PECL memcached extension v3.1.0 and above support PHP 7.3

Just a note that the PECL memcached extension doesn’t work with PHP 7.3 yet, you need to stay on PHP 7.2.

This is the error I got when trying to running sudo perl install memcached (along with several sasl deprecation warnings):

/private/tmp/pear/install/memcached/php_memcached.c:1284:20: error: expression is not assignable

NB: Also, don’t get memcache and memcached mixed up when searching extensions.

WordPress – WPML – fix an incorrect language

I had a site using WPML (WordPress Multilingual) where the site’s language picker was set to English but a Chinese translation was consistently showing up for one particular item.

This turned out to be a simple case of the wrong language being set for the post in the database, but to the best of my knowledge you’d never be able to find that out from the UI.

Fortunately it’s easy to detect and fix with some simple PHP and SQL – the examples below use WP-CLI commands.

Firstly, you can use wp shell to verify the language the post is set to.

wpml_get_language_information('',123456);

The language is stored in the wp_icl_translations table, where element_id = the post ID.  So, using wp db query:

update wp_icl_translations set language_code = 'zh-hans' where element_id = 123456;

The above sets the post language to Chinese, which means it won’t be visible when the English version is requested.

Remember to clear any caches you are using.