Blog

Later Ctrl + ↑

How to install Aegea

To install Aegea, the blogging engine, you will need:

  • A server with Apache, PHP 5 and MySQL,
  • FTP or SFTP access to the server or another way to access the server’s file system,
  • Access to a MySQL database.

If you don’t have all this or don’t know what this means, you will not be able to install Aegea on your own. Seek assistance.

Get Aegea package
Download the Aegea zip archive from the website and unzip it:

Inside, you will see files like these (the list may differ depending on the version):

Put files on server
Upload all these files to the server (I’m using the FTP client Flow here):

As you can see, I’ve created a “blog” folder on the server and put the files in that folder:

Open Installer with browser
Navigate to the server with your browser. As I’ve created the folder “blog” for Aegea, I go to blogengine.me/blog/:

Enter your MySQL database access parameters: the server, the username, the password and the database name. The last thing to fill in is the password that you want to use to access your blog (you can change it later):

Click “Start blogging” and go:

Permission problems
You may find that instead of the Installer Aegea shows you something like this:

In this case, you need to change the permissions of Aegea’s folder and everything inside it to let the engine do anything it wants. Select the folder “blog” (in my case) and press ⌘I (in Flow’s case) to open its details:

Click the pencil icon next to Permissions (or open the permissions in some other way). Set permissions like this:

Then go back to the browser and press “Try again”. Installer should work now.

Venice

I’ve updated the “World” section with photos from Venice.

Introducing Aegea

Introducing Aegea, a great blogging engine.

An engine is a program that runs on the blogger’s website. It provides the writing tools to the author, shows the posts to the readers and lets them write comments. Medium.com (or similar) is simpler, but they can shut down and take all your posts offline. With an engine, the blog runs on your own website and you have access to the files and the database (you don’t have to deal with the files or the database, but you own all the data).

I want most people to have access to personal blogging in this way. That’s why it uses the most easily available platform: PHP with MySQL.

Aegea powers this and many other blogs. Among my favourites:

With Aegea, you can use the built-in neutral theme or customise it however you like (this blog is an example). Be flexible with comments: allow and disallow them globally or per post. Refine posts using Drafts. Add images, videos, audio or code to illustrate your point. Organise your writing with tags.

Designers, writers, musicians and software developers use Aegea to show their work, communicate and spread knowledge. They love it because it’s simple and fast yet does everything they need. Aegea is free for personal use and paid for business use.

Learn more and get Aegea at blogengine.me.

Reminders app is so buggy

Reminders is one of buggiest apps Apple has ever made. Sometimes it forgets to remind, sometimes it reminds twice. It cannot sync anything between Macs, iOS devices and the watch. And now, it decided to remind me of five things:

Reminders app

Thanks, I guess.

Emerge 1.3 with video support and replay control

In 2013, I released Emerge, a page load coordinator:

Normally, when a complex web page is loading, elements appear in random order, causing unpleasant flashing. To replace it with nice and coordinated animations, programming is required. Emerge.js simplifies the task by removing the need to write any JavaScript code. The framework uses a declarative approach, where you specify the desired behaviour for each element and do not think about the implementation.

See also the introductory blog post.

Version 1.3 adds support for video tags and an easy-to-use replay control useful for debugging.

Update for free

If you’ve bought Emerge, you get the updates for free. Just re-download using the same link you got when you bought the script. Or drop me a line if you have any questions.

Map and reality: diagrams

In the previous two parts, we’ve figured out that the preferred distortion and layers depend on the map’s supposed use case.

With public transport maps, our goal is to help the customer get from point A to point B using the displayed transport network.

This is a map of Paris Metro of 1915:

Paris Metro, 1915

The city is shown in full detail. There are many layers. The metro lines, however, stand out because of the use of contrasting red thick lines.

Compare with the map of London underground railways of 1908:

London underground railways, 1908

The lines of different railways are denoted by different colours. The rest of the city — the roads, the parks and the river — makes one pale-gray layer.

But even this layer is removed by 1932:

London underground railways, 1932

The river Thames is the only non-railway object that remains on this map. And it is the only device that links the railways to the surface geography.

It is always interesting to explore a detailed map with lots of layers. But in this case, the pleasure of exploration is much less important than the customers’ ability to quickly pick out which train to take. The information richness is sacrificed to the comprehension speed.

But as we see, despite all the simplifications, the central part is still rather hard to read. In several places, arrows had to be used to clarify the correspondence of labels and stations.

The engineer Harry Beck has come up with a radical idea. He suggested redesigning the maps using the principles of electrical circuit drawings.

Electrical circuit

Such drawings prioritise the logical connection between the elements over their physical position. What if a railway map also displayed first and foremost the logical connection between the stations?

The Beck’s diagram replaced the map in 1933:

Beck’s Underground map, 1933

All lines segments were put to the angles of 45° and 90°. The distances between stations were equalised.

The modern diagram has twice as many lines and many more layers, but it inherits the Beck’s principles:

Modern London Underground map

Compare with a geographical map of the same lines:

Geographical London Underground map

The central part here is so dense that it had to be put in a cutaway at a bigger scale. And even so, everything turned out very small. Now we see that showing “true” geography is not universally useful. This geographical map is much harder to read. For the railways’ customers, the diagram excels.

If the distances between the stations are equal, the reader will grasp that it’s just a convention and won’t rely on it. If the lines are strictly at 45° or 90°, the reader will grasp that they do not represent the actual paths of the underground tracks and won’t rely on it either. But this doesn’t mean that you can get rid of any geographical reference.

In 2007 I made a rectilinear Moscow Metro map as an experiment:

While the principles of the above diagram are easy to figure out, there still is a problem: even if you live in Moscow, you will have a hard time finding your station.

Since any map is perceived in reference to the image of reality formed by the geographical maps, you have to respect that. If the reader knows roughly where a station is in the city, they should be able to find it on the diagram, too.

Why are browsers so slow?

I understand why rendering a complicated layout may be slow. Or why executing a complicated script may be slow. Actually, browsers are rather fast doing these things. If you studied programming and have a rough idea about how many computations are made to render a page, it is surprising the browsers can do it all that fast.

But I am not talking about rendering and scripts. I am talking about everything else. Safari may take a second or two just to open a new blank tab on a 2014 iMac. And with ten or fifteen open tabs it eventually becomes sluggish as hell. Chrome is better, but not much so.

What are they doing? The tabs are already open. Everything has been rendered. Why does it take more than, say, a thousandth of a second to switch between tabs or create a new one? Opening a 20-megapixel photo from disk doesn’t take any noticeable amount of time, it renders instantaneously. Browsers store their stuff in memory. Why can’t they just show the pixels immediately when I ask for them?

You may say: if you are so smart, go create your own browser — and you will win this argument, as I’m definitely not that smart (I don’t think any one person is, by the way).

But I remember the times when we had the amazing Opera browser. In Opera, I could have a hundred open tabs, and it didn’t care, it worked incredibly fast on the hardware of its era, useless today.

You may ask: why would a sane person want a hundred open tabs, how would you even manage that? Well, Opera has had a great UI for that, which nobody has ever matched. Working with a hundred tabs in Opera was much easier back then than working with ten in today’s Safari or Chrome. But that’s a whole different story.

What would you do today if you opened a link and saw a long article which you don’t have time to read right now, but want to read later? You would save a link and close the tab. But when your browser is fast, you just don’t tend to close tabs which you haven’t dealt with. In Opera, I would let tabs stay open for months without having any impact on my machine’s performance.

Wait, but didn’t I restart my computer or the browser sometimes? Of course, I did. Unfortunately, modern browsers are so stupid that they reload all the tabs when you restart them. Which takes ages if you have a hundred of tabs. Opera was sane: it did not reload a tab unless you pressed Reload. To show you the tab, it just reopened everything from its disk cache. Which took a couple of seconds.

Modern browsers boast their rendering and script execution performance, but that’s not what matters to me as a user. I just don’t understand why programmers spend any time optimising for that while the chrome is laughably slow even by ten-years-old standards.

I want back the pleasure of fast browsing.

You should follow me on Twitter, here

Likely 2.2 for single-page applications and more

We’ve just released Likely 2.2 which adds support for single-page applications and includes many more improvements.

Ivan Akulov, the project’s maintainer, writes:

Most modern single-page apps use History API which allows developers navigate between pages without refreshing them. Since 2.2, Likely supports this API out of the box! If you place the buttons on a page and then do history.pushState () or history.replaceState (), Likely will automatically catch these changes and update itself. (Navigating backwards and forwards is also supported, of course.)

If you don’t use History API, call likely.initiate () when you need the buttons to update.

Since 2.1 we have a Telegram button, and now we add LinkedIn:

Likely LinkedIn button

There are also great improvements under the hood. As the result, the file size has been cut in half. And the code is now covered with automated tests.

See the GitHub release page for a more detailed description.

Map and reality: layers

In Map and reality: distortion I talked about how distortion is inevitable on a map and the question is what to distort given a particular task.

Now let’s talk about layers. What properties of land should a map display?

Physical and geographical world atlas (1964)

Physical and geographical world atlas (1964)

A physical map shows terrain: oceans, trenches, plains and mountains. On a political map, the land is divided into countries and states. A mineral resources map is covered with the symbols of mineral deposits and oilfields.

One can’t say that a physical map is “truer” than, say, a railroad atlas. The following map shows the history of Amsterdam’s development, and it’s also true. Red houses are the oldest, the blue ones are the newest:

Buildings age in the Netherlands

A good cartographer will find ways to display lots of data on a map:

A map of Chelyabinsk region, Russia (1956)

A map of Chelyabinsk region, Russia (1956)

This map displays terrain, the region boundaries, motorways and railroads, settlements, ponds, mountain ridges, height markings, parallels and meridians.

By carefully choosing colour shades, widths and styles of lines, typefaces of text, the cartographer achieves clear separation of visual layers. Background colours that marks the heights are unsaturated to let one see the labels clearly. A particular hatching is used along the region boundaries to make them well distinguishable. The letters У Р А on the left separated by many other designations, are perceived as one label ЮЖНЫЙ УРАЛ (Southern Ural) on the full map thanks to a special typeface.

The more features are shown on a map, the more interesting it is to explore it.

However, there are circumstances that do not suggest an unhurried examination by a curious reader. Sometimes a map should just answer a narrow set of practical questions.

A pedestrian map shows the main landmarks, sidewalks, bike lanes, subway stations, toilets and Wi-Fi zones:

WalkNYC wayfinding system (2013)

A nautical chart displays water depths, navigational hazards, important routes, harbours and the details of the coastline:

A nautical chart

The depths are marked with numbers — while the shades of blue as used on physical maps are more illustrative, a sailor wants the actual values. The dry land gets very little attention.

The choice of the layers and the way to separate them, as well as the choice of appropriate distortion, depends on the map’s goal and supposed use.

Continued in Map and reality: diagrams.

Earlier Ctrl + ↓