Поиграл на рояле
Позавчера летел из Кишинева. Зал вылета был полон. Подошел к
— А у вас рояль стоит, на нем можно поиграть?
— Да, можно.
— Стоит два евро, — добавил сотрудник аэропорта, стоящий рядом.
— Два евро?
— Да шутка это, — улыбнулся он.
Сыграл несколько композиций с перерывами на голосовые объявления. В конце несколько человек похлопали, одна женщина поблагодарила :)
WSL: Линуксовая подсистема в Windows
Полноценная
В этот момент разработчики начинают использовать виртуальные машины, локальные или удаленные. Вместе с ними появляются проблемы синхронизации файлов в крупных проектах. Для продуктивной работы PhpStorm индексирует файлы проекта и наблюдает за их изменениями. Когда файлы редактируются на одной операционной системе, а исполняются и управляются из гита на другой, неизбежны задержки синхронизации или тормоза индексирования. Еще и composer
Неискушенный читатель может спросить, зачем вообще разрабатывать на Windows. Причины могут быть разные. Например, корпоративная политика. Админам проще управлять кучей компьютеров с Windows.
Так или иначе, проблема удобной настройки окружения для
Несколько лет после выхода линуксовая подсистема была в состоянии беты, и пользоваться ей было невозможно. Но, начиная с Creators Update, выпущенного в апреле, ситуация изменилась, и nginx вместе с
С практической точки зрения WSL — это командная строка bash, в которой можно устанавливать любой пакет из репозитория Ubuntu 16.04 через apt install
. Диски компьютера примонтированы и доступны в файловой системе через /mnt/c
, /mnt/d
Ребята из Микрософта нацеливались на «интероперабельность»: из bash можно запустить не только линуксовые
Я перевел ежедневную работу на линуксовую подсистему. Обнаружил две проблемы. Первая: не работают
Еще есть особенность: не работают средства автозапуска программ. Пришлось добавить команды service start nginx
в .bashrc
.
И еще есть баг. Через некоторое время процесс beam начинает загружать процессор. Приходится останавливать сервис rabbitmq.
Положительные моменты: можно выкинуть MinGW, виртуальные машины и прочие попытки завести bash на Windows, и работать в полноценной линуксовой консоли. Софт в среде разработки идентичен софту на боевом сервере и обновляется одной командой apt upgrade
.
Спустя три года я
О схеме 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/...
с закодированными в /gb/...
на дешифрованный вариант в редакторе формул.
Пробел в знаниях основ веб-разработки
Одноименный перевод на хабре. Первая цитата о Реакте:
Читаю огромное множество статей, где авторы пишут о разных технологиях, и поверьте, почти все в мире JavaScript пишут об одном или другом из этих фреймворков как будто это абсолютно новая и уникальная инновация. Хотя это отличные инструменты, но каждый из них создан для решения конкретной проблемы. Они основаны на схожем базисе и делают разный выбор в зависимости от задач, для которых оптимизированы.
Можно взять React для примера, потому что он так сильно продвигается в последние несколько лет…
Не поймите меня неправильно, я люблю React. Это феноменально мощный инструмент. Он делает не только возможным, но и простым создание интерфейсов, которые казались нереальными, когда я начинал
веб-разработку. Однако новички в индустрии приходят и видят всю эту шумиху вокруг React и предполагают, что это единственная истина, как следует писать на JavaScript. Сделать новоевеб-приложение? Используй React! Нестандартный шаблон для блога? React! Переделать старый сайт? Переходи на React!
У нас на работе в команде два
Вторая цитата о том, что часто использование готовых инструментов в полную силу позволяет обойтись без велосипедов:
Если все новые разработчики будут с презрением смотреть на CSS, то мы придём к тому, что 2000 строчек JavaScript будут пытаться заново реализовать
position: absolute;
.
Объемный чертеж
Нарисовал в латехе объемный чертеж, но он не пригодился. Так что просто оставлю его здесь.
Чтобы делать такие чертежи, добавил в свой редактор математических текстов Upmath поддержку пакета
Сравните с версий того же чертежа из черновика:
Уязвимости опсосов
Статья на хабре о дырищах у крупнейших операторов сотовой связи:
Любая программа, имеющая доступ в интернет на вашем телефоне с SIM Мегафон, может узнать ваше местоположение с точностью до базовой станции, номер телефона, идентификаторы IMEI и IMSI. С SIM МТС она может получить ваш номер телефона, идентификаторы IMEI и IMSI, а Билайн позволит раскрыть только номер телефона.
Веб-сайт злоумышленника, содержащий специальным образом сконструированынный запрос, позволит раскрыть ваш номер телефона на МТС.
Что интересно, в последнюю рабочую пятницу перед новогодними каникулами.
Мастер-класс о шрифтах
На хабре огромная статья про шрифты — расшифровка выступления Алексея Каптерева. После статьи есть видео. Он системно изложил историю развития шрифтов. Очень интересно и познавательно. Неплохой справочный материал для периодического возвращения.
vw и %
В css есть специальные единицы длины vw
и vh
, равные сотой доле ширины и высоты окна. К сожалению, на них не влияют полосы прокрутки. Например, если на странице есть блок шириной 100vw
, то вдобавок к вертикальной прокрутке обязательно появится горизонтальная.
На стэковерфлоу советчик утверждает, что полоса прокрутки не входит в проценты, поэтому ширина полосы прокрутки есть 100vw - 100%
, и предлагает вариант
body {
width: calc(100vw - (100vw - 100%));
}
И ни советчика, ни 172 проголосовавших не смутило, что в итоге вычитания получается ровно 100%.
Айсберг, который переворачивается
Дмитрий Гудков на Эхе про рейтинги диктаторов:
Вы знаете, у меня очень часто особенно иностранные журналисты спрашивают «Ну, как же вот так? Путин — вот, у него 86%. А что с этим делать?» И я им всегда рассказываю историю про Лужкова, у которого было,по-моему, 75% за неделю до отставки, и через неделю после отставки 50% с лишним уже поддерживали отставку. Это так устроено общественное мнение в России. Как только центр силы меняется, смещается, все эти цифры — они вообщекуда-то улетают. Это как айсберг, который переворачивается. Было у тебя 98%, а потом айсберг перевернулся и у тебя 2 только осталось.
Когда переворачивается айсберг, ничего подобного не происходит. А айсберги действительно переворачиваются, мы это разбирали 10 лет назад.
Синхронная прокрутка
Этот текст я написал в том числе и для себя, чтобы в следующий раз не попадать в ловушку «почему два года назад я сделал так криво, сейчас всё исправлю».
Иногда в интерфейсе нужно одновременно показать два документа с синхронной прокруткой. Прокручиваешь левый документ, и правый тоже прокручивается до соответствующего места. И наоборот. Может показаться, что задача синхронной прокрутки не слишком сложная. Но на самом деле это не так.
Пример синхронной прокрутки есть в каждом интерфейсе просмотра изменений файлов. Вот PhpStorm:
При прокрутке одной версии документа вторая всегда выравнивается так, чтобы на красной линии оказались соответствующие строки. Аналогичный способ я выбрал для своего редактора математических текстов, только ориентир выравнивания сделал посередине:
Здесь мы набираем исходный код и сразу же видим результат. Обратите внимание на неравномерность прокрутки. Слева картинка кодируется одной строкой, а справа она занимает почти всю высоту прокручиваемой области.
Такая неравномерность приводит к ряду проблем. Когда картинка добавляется последней строчкой, в предпросмотре отображается только ее верхушка:
Это естественное поведение алгоритма с выравниванием по ориентиру в центре. И его хотелось бы улучшить. Но от
Другая идея — сделать ориентир не фиксированным, а подвижным. Сначала ориентир расположен вверху. Затем, по мере прокрутки, он сдвигается вниз. Но и здесь нас ждут скользкие моменты. Например, мы знаем, что начало одного и того же абзаца находится в левом документе на высоте в 30%, а в правом на 50%. Пусть левый документ прокрутили на 30%. Тогда мы говорим, что ориентир тоже находится на 30% высоты экрана, переводим 30% в 50%, и располагаем правый документ так, чтобы абзац был на 30% высоты экрана. Проблема в том, что обратное преобразование не обязано давать тот же самый результат. Действительно, тот же самый абзац будет использоваться при прокрутке правого документа на 50%, и в общем случае это разные положения прокрутки. В такой реализации встречаются странные скачки прокрутки при переключении фокуса между документами и даже немонотонность зависимой прокрутки: если вы прокручиваете один документ вниз, то другой в некоторые моменты будет двигаться не вниз, а вверх.
У меня была мысль отказаться от двух прокручиваемых областей, прокручивать только исходный код и умным алгоритмом выводить в области предпросмотра соответствующую область документа. Но проблемы синхронной прокрутки, о которых я рассказал, мешают это сделать.
Похоже, полностью избавиться от проблем синхронной прокрутки вообще нельзя. Вернемся к сравнению файлов. Предположим, в одном файле 100 строк, во втором я превратил сотую строку в еще 400. Прокручивая первый файл, мы никогда не увидим новые 400 строк второго. Как бы мы ни выравнивали второй файл, все 400 строк на экран не поместятся. Это значит, что нельзя убирать вторую прокрутку.
В своем редакторе я оставил синхронизацию прокрутки по ориентиру, но дополнил ее условием: если один документ полностью прокручен вверх или вниз, то второй документ прокручивается полностью.