Gleb's Notes

Configuring Ubuntu 17.10 to behave like Unity

2018-04-02T15:16:00+01:00

I've recently upgraded from Ubuntu 16.04 to Ubuntu 17.10. The new Ubuntu uses Gnome desktop by default instead of Unity. Gnome is quite different but luckily can be customized to match Unity's behaviour very closely. Here is how.

Goals

Show the current time in the top bar on the right.
Show legacy app indicators (tray icons) on the right.
Merge the window title bar with the top bar when maximized.
Hide the top-left Activities button.
Allow quick device selection via the top bar Sound button.
Place window buttons on the left.

Setup guide

First, install Tweaks, a GNOME configuration UI that has options that are not yet available in the default Settings app:
```
sudo apt install gnome-tweak-tool
```
Then install x11-utils, a package often required by Gnome extensions:
```
sudo apt install x11-utils
```
You can install Gnome extensions from https://extensions.gnome.org and manage and configure the installed extensions in Tweaks -> Extensions.
Install the Unite extension for goals 1-4.

Alternatively, e.g. if Unite doesn't work for you or you'd like more customization, install the following plugins: No title bar, Hide activities button, and Frippery Move Clock.
Install the Sound Input & Output Device Chooser extension to add sound device selection to the top bar sound menu.
To place window buttons on the left, adjust Tweaks -> Windows -> Titlebar Buttons -> Placement.

Other tips

If you use Google Chrome, enable "Use system title bar and borders" in chrome://settings for consistency with other apps.

You can disable animations from Tweaks -> Appearance -> Animations.

You can change the default monospace font from Tweaks -> Fonts. I prefer Hack Regular at 11pt:

sudo apt install fonts-hack-ttf

To have your multi-monitor setup work on the login screen, run:

sudo cp ~/.config/monitors.xml /var/lib/gdm3/.config/

Keyboard shortcuts can be configured in Settings -> Devices -> Keyboard. I find it useful to remove Maximise window and instead set Toggle maximisation state to Super + Up.

Database-agnostic case-insensitive equality, full text search

2016-03-31T03:00:00+01:00

Different relational databases treat text search very differently. The new DbTextSearch gem provides a unified interface on top of ActiveRecord for SQLite, MySQL, and PostgreSQL to do:

Case-insensitive string-in-set querying, and CI index creation.
Basic full-text search for a list of terms, and FTS index creation.

DbTextSearch does all the heavy lifting under the hood, hiding the complexity of handling each database differently away, which is great for gem authors, when migrating an application from one database to another, or writing code that must support multiple databases.

Here is how db_text_search handles different types of columns in different databases for case-insensitive comparisons:

DbTextSearch case-insensitive string matching methods
Column type	SQLite		MySQL		PostgreSQL
Column type	Detected types	Search / index	Detected types	Search / index	Detected types	Search / index
Case-insensitive	always treated as case-sensitive	`COLLATE NOCASE`	default	default	`CITEXT`	default
Case-sensitive	always treated as case-sensitive	`COLLATE NOCASE`	non-`ci` collations	`LOWER` no index	default	`LOWER`

Full-text search is even more gnarly. Great that you don't have to worry about that if you use this gem! Check it out and learn more on github.com/thredded/db_text_search.

Internationalization made easier with static analysis

2014-02-27T08:41:00+00:00

i18n-tasks finds and manages missing and unused translations in your application. The default approach to locale data management with gems such as i18n is flawed. If you use a key that does not exist, this will only blow up at runtime. Keys left over from removed code accumulate in the resource files and introduce unnecessary overhead on the translators. Translation files can quickly turn to disarray.

i18n-tasks improves this by using static analysis. It scans calls such as I18n.t('some.key') and provides reports on key usage, missing, and unused keys. It can also can pre-fill missing keys, including from Google Translate, and it can remove unused keys as well.

i18n-tasks can be used with any project using i18n (default in Rails).

It can make translation easier in many ways:

$ i18n-tasks
Usage: i18n-tasks <command> [options]
    -v, --version      Print the version
    -h, --help         Display this help message.

Available commands:

  missing             show missing translations
  unused              show unused translations
  translate-missing   translate missing keys with Google Translate
  add-missing         add missing keys to the locales
  find                show where the keys are used in the code
  normalize           normalize translation data: sort and move to the right files
  remove-unused       remove unused keys
  config              display i18n-tasks configuration
  xlsx-report         save missing and unused translations to an Excel file

See `<command> --help` for more information on a specific command.

There are lots of settings and you can use this on non-ruby codebases.

Reports come rendered in colourful full-resolution terminal tables:

$ i18n-tasks usages 'activities.*'

Save Redis memory with large list packing

2013-08-31T17:54:00+01:00

Redis is great for storing certain types of data that do not do well in a relational database. It is great for storing caches and statistics too. However, the storage capacity of redis is capped by RAM size, so care is required when storing large amounts of data in it.

I will show you a trick to reduce memory usage and improve the speed of the redis list type for storing series-type data (e.g. time series). Redis packs small lists of ints, reducing their memory usage by 10-40%. The exact list size threshold at which redis stops compressing is defined by the list-max-ziplist-entries setting and defaults to 512.

Here is the trick: we will transparently partition a list into many small lists of list-max-ziplist-entries size. By storing lists under the threshold, we take advantage of redis' ability to pack them.

Here is a memory usage benchmark with random int values between 0 and 10:

To benchmark access speed let's try some random accesses on a large list:

bm_speed: 3,000,000 keys, 100 random range reads
                           user     system      total        real
regular                0.380000   0.040000   0.420000 (  0.686875)
partitioned            0.390000   0.060000   0.450000 (  0.482544)

Even despite Ruby overhead we still have both wall-clock time and memory savings. A regular redis list is a linked list, so getting ranges out of it is slow. However, when we use this technique the list is partitioned, and it only takes O(1) to get to the correct partition. As you increase list-max-ziplist-entries, memory savings increase and range queries get slower.

I published a Ruby implementation of this approach for int and time series.

Are you doing something similar? I am curious to hear other approaches.

Thanks @ddtrejo for your edits and suggestions!

Notes

Packing efficiency depends on the data. Benchmark with your real data.
You can implement a similar trick for hashes and sets, redis will compress them based on the respective -ziplist-entries values.
Tested on redis 2.6.14, installed via homebrew on OS X 10.8.3.

Inline CSS web fonts

2013-08-28T17:34:00+01:00

If you serve web fonts via URL, the browser makes a separate request for every web font.

This is what the timeline looks like for a URL referenced font:

Ready Load

Fonts included from stylesheets cause extra requests that only starts once the DOM has loaded. This causes a delay and flash of missing text or a font change flash while the fonts are loading.

However, you can avoid extra requests and rendering issues if you inline the fonts as data-uris.

Inline web fonts with this script:

# download inliner and mark it as executable
curl https://gist.githubusercontent.com/glebm/6360088/raw > inline-fonts.rb; chmod +x inline-fonts.rb
# provide URL or path to convert
./inline-fonts.rb 'https://fonts.googleapis.com/css?family=Arimo:400'

The script outputs CSS with all the url values inlined in data-uris, woff format. You can now deliver the fonts and CSS together in 1 request and the rendering is perfect, no more FOUC or font change.

There be dragons

base64 encoding causes a +33% file size increase, but gzip mitigates this
when there are more fonts files at some point it is faster to download them in parallel, depending on the font sizes and latency / bandwidth of the audience.
public CDN files may already be in browser cache (e.g. the most popular Google Web Fonts)
the most common format woff is supported everywhere but IE 8, stock Anroid Browser, and Chrome on Windows, which has a general rendering issue with some fonts, and base64 is slow on Android 2 and iOS 5. You will have to serve other formats to these browsers

Most individual font sizes are in 10 - 20 KB range; if you only use a few font files this could easily cut down initial load times by 5-20%. Measure with any client-side monitoring tool to find out (it is best if your tool shows the distribution, and not just the average).

This is what the timeline looks like once the fonts are inlined:

When inlined, all the fonts are finished downloading before DOMContentReady fires.

Alternatively, you could try using Google Page Speed Module, which may intellegently apply this and other optimizations, but has it's own drawbacks. SPDY should already be on for both timelines.

Store screenshots of your web app in Git

2013-08-23T17:22:00+01:00

Have you ever had a change break your site? Even when the tests pass?

Testing functionality is hard
Testing UI is even harder

What if every time you commit, you got a visual diff of every web page that changed? It is surprisingly easy to do.

How?

All we need is a headless browser and a testing environment.

For Rails you can use poltergeist + rspec and just do this like in the tests for my Rails Email Preview gem. You then simply list the shots you want:

describe 'Take screenshots', driver: :poltergeist do
  it 'home page' do
    visit '/'
    screenshot! 'home'
  end

  it 'user account page' do
    sign_in Fabricate(:user)
    visit my_account_url
    screenshot! 'my-account'
  end
end

The code will simply place screenshots into spec/screenshots each time the test suite is run.

Once you add spec/screenshots to git, things get interesting.

Perks unlocked

With your screenshots under version control, you will

Always know when you introduce a change that changes the display
See which commits changed screens in your app
Instantly see what your app looked like at any point in time

You must use git submodule add {separate repo URL} spec/screenshots to keep screenshots in a separate repo, as it will get large. You can also script rewriting images out of older commits via git filter-branch if repo grows too large.

Below is an image diff as rendered by Github. This is visual version history and your private git wayback machine.

I hope this post has helped you. Please let me know if you already do this, as I'm curious to hear other approaches.

– @glebm

Thanks @ddtrejo for your edits and suggestions!

Gleb's Notes

Configuring Ubuntu 17.10 to behave like Unity

Goals

Setup guide

Other tips

Database-agnostic case-insensitive equality, full text search

Internationalization made easier with static analysis

See also

Save Redis memory with large list packing

Notes

See also

Inline CSS web fonts

Ready Load

There be dragons

See also

Store screenshots of your web app in Git

How?

Perks unlocked

See also