Объемный чертеж

Нарисовал в латехе объемный чертеж, но он не пригодился. Так что просто оставлю его здесь.

Чтобы делать такие чертежи, добавил в свой редактор математических текстов Upmath поддержку пакета tikz-3dplot. А еще в последнее время меня просили добавить пакеты stmaryrd (набор символов для информатики) и bussproofs (выводы доказательств).

Сравните с версий того же чертежа из черновика:

Пробел в знаниях основ веб-разработки

Одноименный перевод на хабре. Первая цитата о Реакте:

Читаю огромное множество статей, где авторы пишут о разных технологиях, и поверьте, почти все в мире JavaScript пишут об одном или другом из этих фреймворков как будто это абсолютно новая и уникальная инновация. Хотя это отличные инструменты, но каждый из них создан для решения конкретной проблемы. Они основаны на схожем базисе и делают разный выбор в зависимости от задач, для которых оптимизированы.

Можно взять React для примера, потому что он так сильно продвигается в последние несколько лет…

Не поймите меня неправильно, я люблю React. Это феноменально мощный инструмент. Он делает не только возможным, но и простым создание интерфейсов, которые казались нереальными, когда я начинал веб-разработку. Однако новички в индустрии приходят и видят всю эту шумиху вокруг React и предполагают, что это единственная истина, как следует писать на JavaScript. Сделать новое веб-приложение? Используй React! Нестандартный шаблон для блога? React! Переделать старый сайт? Переходи на React!

У нас на работе в команде два фронтенд-разработчика. После знакомства с требованиями они заявили, что не видят причин не делать клиентскую часть на Реакте. Я не смог возразить и дал им свободу. Прошло 7 месяцев, и они до сих пор обсуждают вопросы типа формата хранения данных в стейте. Эти вопросы решены, как говорится, «из коробки» в настоящих фреймворках типа Эмбера (Ember JS). Эмбер диктует, как писать код и как разложить его по полочкам. И это большое достоинство по сравнению с Реактом — библиотекой отображения.

Вторая цитата о том, что часто использование готовых инструментов в полную силу позволяет обойтись без велосипедов:

Если все новые разработчики будут с презрением смотреть на CSS, то мы придём к тому, что 2000 строчек JavaScript будут пытаться заново реализовать position: absolute;.

О схеме URL сервиса генерации картинок с формулами

В посте про объемный чертеж я привел саму картинку, но не ее код. А без кода картинка бесполезна: нельзя ни подсмотреть, как она сделана, ни изменить под свои нужды.

На самом деле код картинки содержится в ее адресе. Как писал Якоб Нильсен 19 лет назад, URL — это интерфейс. И я принял такое интерфейсное решение. Формула на латехе (например, a^2+b^2=c^2) кодируется и добавляется в урл:

//i.upmath.me/svg/a%5E2%2Bb%5E2%3Dc%5E2

По нему открывается сама картинка с формулой: $$a^2+b^2=c^2$$.

Таким образом, из адреса картинки расшифровкой можно получить ее исходный код. Чтобы облегчить этот процесс, я сделал адрес другого вида (от svg остается последний символ):

//i.upmath.me/g/a%5E2%2Bb%5E2%3Dc%5E2

По этой ссылке открывается веб-интерфейс генератора картинок с заполненным исходным кодом. Вы меняете код и сразу видите результат:

Вообще, исходный код может быть достаточно длинным. Вот пример, в котором на комплексной плоскости отмечены первые 10 степеней числа $$1+i\pi/10$$:

\begin{tikzpicture}[scale=1.0545]\small
\tikzset{>=stealth}
\def\k{10}
\def\p{3.1415926/\k}
\def\r{3.1}
\def\l{5.8}
\def\t{0.07}
\draw[->,thin,gray] (-\l,0)--(\l,0);
\draw[->,thin,gray] (0,-0.6)--(0,\l);
\draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$};
\foreach \l in {1,...,\k}
   \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)});
\draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}) node[pos=0.91,above] {$-1,\!5934+0,\!1561i$};
\draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$}
(-\r,\t)--(-\r,-\t) node[below]{$-1$}
(\t,\r)--(-\t,\r) node[left]{$1$}
(0,0) node [anchor=north west,yshift=-0.07cm] {$0$};
\draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l);
\end{tikzpicture}

Результат:

$$\begin{tikzpicture}[scale=1.0545]\small \tikzset{>=stealth} \def\k{10} \def\p{3.1415926/\k} \def\r{3.1} \def\l{5.8} \def\t{0.07} \draw[->,thin,gray] (-\l,0)--(\l,0); \draw[->,thin,gray] (0,-0.6)--(0,\l); \draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$}; \foreach \l in {1,...,\k} \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)}); \draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}) node[pos=0.91,above] {$-1,\!5934+0,\!1561i$}; \draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$} (-\r,\t)--(-\r,-\t) node[below]{$-1$} (\t,\r)--(-\t,\r) node[left]{$1$} (0,0) node [anchor=north west,yshift=-0.07cm] {$0$}; \draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l); \end{tikzpicture}$$

Этот пример я взял из статьи о формуле Эйлера $$e^{i\pi}=-1$$. Первую версию картинки рисовал вручную. В Maple выполнил возведение в степень и построил график. Открыл его в фотошопе и поверх дорисовал стрелки-векторы, оси координат.

На версию с графиком в tikz ушло столько же времени, или даже больше. Но масштабируемость результата находится на совершенно другом уровне. Чтобы нарисовать первым способом вдвое больше векторов, нужно потратить вдвое больше времени. Второй способ требует изменения одного числа k в исходном коде, и foreach сделает всю работу. Вот 20 векторов:

$$\begin{tikzpicture}[scale=1.0545]\small \tikzset{>=stealth} \def\k{20} \def\p{3.1415926/\k} \def\r{3.1} \def\l{5.8} \def\t{0.07} \draw[->,thin,gray] (-\l,0)--(\l,0); \draw[->,thin,gray] (0,-0.6)--(0,\l); \draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$}; \foreach \l in {1,...,\k} \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)}); \draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}); \draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$} (-\r,\t)--(-\r,-\t) node[below]{$-1$} (\t,\r)--(-\t,\r) node[left]{$1$} (0,0) node [anchor=north west,yshift=-0.07cm] {$0$}; \draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l); \end{tikzpicture}$$

Вот 50:

$$\begin{tikzpicture}[scale=1.0545]\small \tikzset{>=stealth} \def\k{50} \def\p{3.1415926/\k} \def\r{3.1} \def\l{5.8} \def\t{0.07} \draw[->,thin,gray] (-\l,0)--(\l,0); \draw[->,thin,gray] (0,-0.6)--(0,\l); \draw[green!40!black](\r,0) -- (\r,\p*\r) node[midway,right] {$i\pi/\k$}; \foreach \l in {1,...,\k} \draw[->] (0,0) -- ({(\l-1)*atan(\p)}:{((sqrt(1+\p*\p)^(\l-1)*\r)}); \draw[->,red] (0,0) -- ({\k*atan(\p)}:{((sqrt(1+\p*\p)^\k*\r)}); \draw[very thin] (\r,\t)--(\r,-\t) node[below]{$1$} (-\r,\t)--(-\r,-\t) node[below]{$-1$} (\t,\r)--(-\t,\r) node[left]{$1$} (0,0) node [anchor=north west,yshift=-0.07cm] {$0$}; \draw [line width=0.21mm,opacity=0] (-\l,-0.6) rectangle (\l,\l); \end{tikzpicture}$$

URL последней картинки длиной 1192 символа. В принципе, такие длинные адреса не очень красивы. Но и большой проблемы в этом нет. В стандарте нет ограничений на длину URL, да и с практическим ограничением в браузере или веб-сервере при штатном использовании сервиса я не сталкивался.

Меня просили изменить алгоритм кодирования, чтобы укоротить адреса. Необходимости в этом я пока не вижу. Но если буду делать доработку, то поступлю аналогично. Адрес /svgb/... с закодированными в base-64 бинарными данными будет вести на картинку, /gb/... на дешифрованный вариант в редакторе формул.

WSL: Линуксовая подсистема в Windows

Полноценная веб-разработка на Windows всегда была нелегкой. Для небольших сайтов хватало сборок апача с PHP вроде Денвера. Но как только в проекте требуется memcached, redis или что-то более сложное, настройка окружения существенно усложняется или вообще становится невозможной.

В этот момент разработчики начинают использовать виртуальные машины, локальные или удаленные. Вместе с ними появляются проблемы синхронизации файлов в крупных проектах. Для продуктивной работы PhpStorm индексирует файлы проекта и наблюдает за их изменениями. Когда файлы редактируются на одной операционной системе, а исполняются и управляются из гита на другой, неизбежны задержки синхронизации или тормоза индексирования. Еще и composer где-то нужно запускать, что добавляет путаницы с синхронизацией.

Неискушенный читатель может спросить, зачем вообще разрабатывать на Windows. Причины могут быть разные. Например, корпоративная политика. Админам проще управлять кучей компьютеров с Windows.

Так или иначе, проблема удобной настройки окружения для веб-разработки на PHP была решена только в Windows 10. В ней появилась линуксовая подсистема, или WSL. Она позволяет запускать скомпилированные для линукса бинарники. При этом ядро линукса отсутствует, а системные вызовы к нему на лету транслируются в Win API. В общем, WSL — это Wine наоборот.

Несколько лет после выхода линуксовая подсистема была в состоянии беты, и пользоваться ей было невозможно. Но, начиная с Creators Update, выпущенного в апреле, ситуация изменилась, и nginx вместе с php-fpm нормально заводится и работает.

С практической точки зрения WSL — это командная строка bash, в которой можно устанавливать любой пакет из репозитория Ubuntu 16.04 через apt install. Диски компьютера примонтированы и доступны в файловой системе через /mnt/c, /mnt/d и т. д.

Ребята из Микрософта нацеливались на «интероперабельность»: из bash можно запустить не только линуксовые elf-бинарники, но и обычные exe-файлы. Процессы могут без проблем работать друг с другом. Например, мне было лень делать дамп и переносить базу данных, и я оставил ее в Windows. К ней успешно подключается php-fpm.

Я перевел ежедневную работу на линуксовую подсистему. Обнаружил две проблемы. Первая: не работают unix-сокеты. Решается использованием TCP-сокетов в конфигурации php-fpm и nginx. Вторая: nginx падает при загрузке файлов, из-за того что вызывает нереализованную функцию. Решается запуском встроенного в PHP веб-сервера при тестировании загрузки файлов. Ситуация у меня возникала редко. Может быть ее уже исправили, а я об этом и не знаю.

Еще есть особенность: не работают средства автозапуска программ. Пришлось добавить команды service start nginx в .bashrc.

И еще есть баг. Через некоторое время процесс beam начинает загружать процессор. Приходится останавливать сервис rabbitmq.

Положительные моменты: можно выкинуть MinGW, виртуальные машины и прочие попытки завести bash на Windows, и работать в полноценной линуксовой консоли. Софт в среде разработки идентичен софту на боевом сервере и обновляется одной командой apt upgrade.

Спустя три года я всё-таки перешел на Windows 10, линуксовая подсистема стала в этом решающим фактором.

Поиграл на рояле

Позавчера летел из Кишинева. Зал вылета был полон. Подошел к бизнес-залу. Он был перекрыт (видно на фото справа). Девушка за стойкой информации сказала, что он на реконструкции.
— А у вас рояль стоит, на нем можно поиграть?
— Да, можно.
— Стоит два евро, — добавил сотрудник аэропорта, стоящий рядом.
— Два евро?
— Да шутка это, — улыбнулся он.

Сыграл несколько композиций с перерывами на голосовые объявления. В конце несколько человек похлопали, одна женщина поблагодарила :)

Здесь нет выхода

Уравнение Максвелла

Центральное место на этой фотографии занимает формула $$\nabla\cdot\vec{B}=0$$ на разрисованной стене.

Это одно из уравнений Максвелла в дифференциальной форме. Вероятно, оно должно вдохновлять играющих на площадке детей.

Собираем долги после обедов с коллегами

Как я рассказывал в прошлый раз, после обеда с коллегами выгодно заплатить за всех. Тогда в конце месяца банк вернет больше денег (кешбек). Но есть и обратная сторона — нужно следить, все ли возвращают деньги.

На первый взгляд проблема возврата долга небольшая. Но каждый день мы ходим с разными коллегами по разным кафе и тратим разные суммы. Они чаще переводят деньги на карту в мобильном интернет-банке. Изредка возвращают наличными. Кто-то сразу, кто-то потом. Пропустишь раз или два в течение месяца и окажешься в убытке.

Хочется ненавязчивого контроля. Чтобы о возврате денег не приходилось вспоминать самому. Чтобы деньги собирались с минимальными усилиями (записывать куда-то долго, требуются волевые усилия). Со временем я выработал элементарную систему. Она удовлетворяет перечисленным требованиям и ничего не стоит.

Для сбора долгов я складываю чеки за обед в кошелек. Несколько раз в неделю просматриваю список переводов в интернет-банке, сверяю с чеками и выкидвываю те, по которым деньги уже вернули.

Достоинства этого волшебного метода трудно переоценить. Официант сам дает чек вместе с картой, и я кладу в кошелек и карту, и чек. Чеки не теряются, они надежно лежат в кошельке вместе с картами и небольшим запасом наличных. Чеки периодически попадают в поле зрения и своим видом напоминают: «Посмотри переводы и выбрось ненужные». Когда я занят, чеки спокойно лежат и ждут день-два. Мне не надо помнить о сборе денег. Я никому не надоедаю фразами «не забудь перевести за обед».

Иногда коллеги забывают вернуть деньги. Я прихожу и говорю:
— Слушай, мы в понедельник были в «желтых дверях», и, похоже, ты не перевел мне деньги. Вот чек. В истории переводов у меня пусто.
— Да? Сейчас посмотрю. А, да, сейчас переведу, извини.

При оплате за большую компанию вам пригодится и второй чек, в котором сумма разбита по пунктам меню.

← сюда туда →