Iosevka

Mar. 1st, 2025 05:25 pm
egorius: (Default)

Некоторое время назад искал узкий моноширинный шрифт и наткнулся на Иозевку за авторством некого Renzhi Li. Гарнитура богатая и интересна как минимум тем, что опенсорсная и генерируется кодом. Меня на тот момент все устроило, гарнитура была использована в Мониторинге PostgreSQL и Путеводителе по базам данных, но я не сразу раскурил всю ее прелесть. Но постепенно проникся по-настоящему:

  • Обычный моноширинный шрифт (скажем, PT Mono) позволяет оформлять SQL-код двумя способами: либо жирное начертание идет на выделение ключевых слов, либо жирным печатаются запросы, а светлым — ответ сервера. С Иозевкой вариативность по насыщенности позволяет жирный и полужирный отдать запросам, а светлый оставить для выхлопа.
  • Сама по себе Иозевка выглядят довольно нейтрально, но гарнитура включает массу стилистических сетов, позволяющих сделать начертание более похожим на другие известные гарнитуры. В частности есть сет PT Mono, мимикрирующий_под. С таким сетом запросы лучше сочетаются с основным текстом, который набран PT Serif.
  • Помимо моноширинного начертания имеются квазипропорциональные Iosevka Etoile и Iosevka Aile для кода внутри основного текста, где важна не строгая моноширинность, а равномерность. Почему квази — потому что шрифт остается моноширинным, но некоторые символы чуть ýже (i) или чуть шире (m). Это прям моя давняя мечта. С моноширинными пробелами я уже давно научился бороться (заменяя их на обычные, из пропорционального шрифта), а теперь стало совсем хорошо.

Как это добро использовать. Можно скачать один из готовых бандлов, но там нет стилистических сетов. Поэтому клонируем репу, ставим туда ноду (npm install) и идем в кастомизатор. Там накликиваем себе желаемую конфигурацию, копируем себе получившийся private-build-plans.toml и запускаем сборку (нужная команда приведена на страничке; я собирал без хинтов, для печати они не нужны). И долго терпеливо ждем.

Ну а в Латехе (LuaLaTeX, который умеет в системные шрифты) просто объявляем нужные шрифтовые семейства, объединяя, скажем, SemiCondensed Medium и ExtraBold, SemiCondensed Light и Regular. SemiCondensed позволяет втиснуть больше кода в ограниченную ширину книжной страницы. А в качестве основного моно-шрифта берем, например, Aile Normal, чтобы не смотрелся слишком узко в основном наборе.

На экране результат мне очень нравится. Посмотрим, что получится на печати: скоро выходит долгожданный PostgreSQL. Профессиональный SQL.

egorius: (Default)
Решил тут посмотреть, что за зверь DeepSeek R1, благо даром и без лишних приседаний.

И слегка прифигел. Эта зараза решает задачи по программированию в духе «сделай то-то и то-то одним SQL-оператором»!

Ну ок, не всегда. Иногда выдает что-то с первого взгляда очень похожее на правду, только нерабочее. Но самый прикол в том, что она умеет думать: если подсказать, даже просто намекнуть, она может сообразить, где закралась ошибка. И то, что можно следить за ходом мысли — это прям очень впечатляет.

Оставлю себе на память показательный диалог. На синих плашках мои реплики, на серых — ее размышления и ответы.


В PostgreSQL в двух разных сеансах (обозначенных 1=> и 2=>) выполняются по очереди следующие команды:

1=> CREATE TABLE t(id integer);
1=> BEGIN ISOLATION LEVEL REPEATABLE READ;
2=> BEGIN ISOLATION LEVEL READ COMMITTED;
2=> INSERT INTO t VALUES (1);
2=> COMMIT;
1=> SELECT count(*) FROM t;

Какое число выведет последняя команда?




Хорошо, давайте разбираться. У меня есть два сеанса в PostgreSQL: первый (1=>) и второй (2=>). Они выполняют команды в определённой последовательности. Нужно определить, какое число выведет последняя команда SELECT count(*) FROM t; в сеансе 1.

Сначала посмотрим на последовательность действий:

1. В сеансе 1 создаётся таблица t с колонкой id типа integer.

2. Затем сеанс 1 начинает транзакцию с уровнем изоляции REPEATABLE READ.

3. Сеанс 2 начинает свою транзакцию с уровнем READ COMMITTED.

4. Сеанс 2 вставляет в таблицу t значение (1) и коммитит эту транзакцию.

5. После этого сеанс 1 выполняет SELECT count(*) FROM t; и нужно понять, что он увидит.

Начну с понимания уровней изоляции. Уровень REPEATABLE READ гарантирует, что в течение транзакции будут видны только те данные, которые были закоммичены до начала транзакции, а также изменения, сделанные самой транзакцией. То есть, если другие транзакции закоммитят изменения после начала текущей, то в REPEATABLE READ эти изменения не будут видны.

Сеанс 1 начал транзакцию в REPEATABLE READ. В этот момент создаётся снимок данных (snapshot), который фиксирует состояние базы данных на момент начала транзакции. Далее, сеанс 2 вставляет запись и коммитит её. Но поскольку сеанс 1 работает в REPEATABLE READ, он должен видеть данные на момент своего начала, то есть до того, как сеанс 2 сделал вставку. Однако есть нюанс: таблица t была создана в сеансе 1 до начала транзакции. То есть таблица уже существует, когда сеанс 1 начинает транзакцию.

Но когда сеанс 2 вставляет данные и коммитит, эти данные добавляются в таблицу t. Теперь вопрос: увидит ли сеанс 1 эти изменения после коммита сеанса 2?

Поскольку уровень изоляции REPEATABLE READ создаёт снимок данных в начале транзакции, все изменения, закоммиченные после этого момента, не будут видны в текущей транзакции. Но важно, что таблица t была создана до начала транзакции сеанса 1. Значит, в снимке сеанса 1 таблица t уже существует. Однако на момент начала транзакции сеанса 1 таблица t пустая, потому что сеанс 2 ещё не вставил данные. Вставка сеанса 2 происходит и коммитится после начала транзакции сеанса 1, значит, в снимке данных сеанса 1 этих изменений нет.

Таким образом, когда сеанс 1 выполняет SELECT count(*), он должен видеть только те данные, которые были закоммичены до его транзакции. Поскольку сеанс 2 вставил данные после начала транзакции сеанса 1, сеанс 1 не должен видеть эту вставку. Но тут нужно проверить, влияет ли то, что таблица создана в том же сеансе до транзакции. Но нет, это не влияет на уровень изоляции. Уровень изоляции определяет видимость данных, а не структуру таблиц. Структура таблиц уже зафиксирована, так как CREATE TABLE был выполнен до BEGIN.

Но после создания таблицы и до начала транзакции в сеансе 1, таблица пустая. Начав транзакцию в REPEATABLE READ, сеанс 1 зафиксирует, что таблица t существует и пуста. Сеанс 2 вставляет строку и коммитит. Однако сеанс 1, при выполнении SELECT, должен видеть только данные, которые были на момент начала его транзакции. То есть, в таблице t должно быть 0 строк. Но это только в случае, если таблица действительно была пустой на момент начала транзакции сеанса 1. Однако, если таблица была создана в сеансе 1, то при создании таблицы она, вероятно, была закоммичена, так как CREATE TABLE — это DDL-операция, которая неявно коммитит транзакцию, если не находится внутри блока транзакции. Но в данном случае сеанс 1 выполняет CREATE TABLE, а затем начинает транзакцию. То есть, CREATE TABLE выполняется вне транзакции и сразу коммитится. Потом начинается транзакция в REPEATABLE READ.

Но тогда, когда сеанс 1 начинает транзакцию, таблица t уже существует и пуста. Сеанс 2 вставляет строку и коммитит. Теперь сеанс 1 делает SELECT. Так как уровень изоляции REPEATABLE READ, он не видит изменения, сделанные после начала его транзакции. Поэтому count(*) вернёт 0.

Но есть ли тут какие-то особенности? Например, в PostgreSQL в REPEATABLE READ можно видеть изменения, сделанные в собственной транзакции, но не других. В данном случае, сеанс 1 не делал никаких изменений, только читает. Сеанс 2 сделал изменения и закоммитил. Но для сеанса 1 эти изменения произошли после начала его транзакции, поэтому они не видны.

Таким образом, ответ должен быть 0.

Сеанс 1 начинает транзакцию с уровнем изоляции REPEATABLE READ, который фиксирует снимок данных на момент начала транзакции. На этом этапе таблица t уже создана, но пуста. Сеанс 2 вставляет строку и коммитит изменения, но это происходит после начала транзакции сеанса 1.

В PostgreSQL уровень REPEATABLE READ гарантирует, что транзакция видит только те данные, которые были закоммичены до её начала. Таким образом, сеанс 1 не увидит вставку, выполненную сеансом 2, так как она зафиксирована позже.

Ответ: 0.



А все-таки, в какой именно момент в транзакции REPEATABLE READ создается снимок, который используется затем всеми командами этой транзакции?




Хорошо, пользователь задал уточняющий вопрос о том, в какой именно момент транзакции с уровнем изоляции REPEATABLE READ в PostgreSQL создается снимок данных. В предыдущем ответе я упомянул, что снимок фиксируется на момент начала транзакции, но, возможно, стоит углубиться в детали.

Сначала нужно вспомнить, как работают уровни изоляции в PostgreSQL. Уровень REPEATABLE READ гарантирует, что в течение всей транзакции видны только те данные, которые были зафиксированы до ее начала. Это отличается от READ COMMITTED, где каждый запрос видит последние зафиксированные изменения.

Важно точно определить момент создания снимка. Документация PostgreSQL говорит, что снимок для REPEATABLE READ создается при первом выполнении команды, читающей данные, а не сразу при BEGIN. Это ключевой момент. То есть если транзакция начинается с BEGIN, но первое обращение к данным происходит позже, снимок создается именно в момент первого чтения.

В исходном примере транзакция в сеансе 1 начинается с BEGIN ISOLATION LEVEL REPEATABLE READ, а затем выполняется SELECT. Значит, снимок создается при первом SELECT. Но в примере после BEGIN транзакции 1 до выполнения SELECT сеанс 2 успевает вставить данные и закоммитить. Поскольку снимок создается только при первом чтении, которое происходит после вставки и коммита сеанса 2, то SELECT в сеансе 1 должен увидеть данные после коммита сеанса 2. Но это противоречит предыдущему ответу, где я сказал, что результат будет 0. Возникло противоречие.

Нужно проверить это. Возможно, я ошибся в предыдущем ответе. В PostgreSQL для REPEATABLE READ снимок действительно создается при первом операторе SELECT, а не при BEGIN. Поэтому если в примере транзакция 1 начинается, затем транзакция 2 вставляет данные и коммитит, и только потом в транзакции 1 выполняется SELECT, то снимок создается в момент первого SELECT, который уже видит изменения от сеанса 2. Тогда результат должен быть 1, а не 0.

Но тогда возникает путаница с тем, как работают уровни изоляции. Возможно, я перепутал с SERIALIZABLE, где снимок создается при начале транзакции. Нужно свериться с документацией PostgreSQL.

Согласно документации, в REPEATABLE READ снимок создается при первом операторе чтения. Таким образом, в примере, если транзакция 1 начала REPEATABLE READ, но до выполнения SELECT в ней произошла вставка и коммит в другой транзакции, то SELECT в транзакции 1 увидит эти изменения, так как снимок создается в момент первого SELECT. Следовательно, результат должен быть 1. Это меняет предыдущий ответ. Но тогда я допустил ошибку в первом ответе.

Но возможно, есть нюансы. Например, если первая транзакция после BEGIN выполняет какие-то операции, влияющие на создание снимка. В данном примере транзакция 1 создала таблицу до BEGIN, затем начинает транзакцию с REPEATABLE READ, затем сеанс 2 вставляет данные и коммитит, и только потом транзакция 1 делает SELECT. Поскольку таблица уже существовала до начала транзакции 1, и снимок создается при первом SELECT, который происходит после коммита сеанса 2, то SELECT должен увидеть вставленные данные. Но это противоречит предыдущему выводу.

Значит, я ошибся в первом ответе, и правильный ответ — 1. Но нужно это проверить на практике или перечитать документацию.

Проверяю документацию PostgreSQL:

"In REPEATABLE READ mode, a snapshot is taken at the start of the first query or data-modification command (SELECT, INSERT, UPDATE, DELETE, or MERGE) within the transaction, and that same snapshot is used for all subsequent commands in the same transaction."

То есть снимок создается при первом запросе или команде модификации данных. В примере транзакция 1 после BEGIN не выполняла никаких команд до SELECT. Поэтому снимок создается в момент выполнения SELECT. В этот момент транзакция 2 уже закоммитила вставку, значит, SELECT должен увидеть строку с id=1. Следовательно, результат будет 1, а не 0.

Таким образом, предыдущий ответ был неверным. Нужно исправить его и объяснить, что снимок создается при первом запросе, а не при начале транзакции. Поэтому в данном случае SELECT в сеансе 1 увидит изменения, закоммиченные сеансом 2 до первого SELECT в транзакции REPEATABLE READ.

В PostgreSQL при уровне изоляции REPEATABLE READ снимок данных создается не в момент выполнения BEGIN, а при первом операторе, обращающемся к данным (например, SELECT, INSERT, UPDATE, DELETE). Это ключевой нюанс, который влияет на видимость изменений из других транзакций.

Итоговый ответ: 1.



Ну да, мысли путаные, но ведь доперла же! Сама!

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

Но интере-е-есно, блин.
egorius: (Default)

Microsoft®, вы только подумайте, SQL Server®. Ну как так, а?

egorius: (Default)

В мае довелось слетать с коллегами в Непал на конференцию. Международную: кроме Непала были представлены Россия (это мы!), Штаты, Пакистан и Индия. Конференция, между прочим, уже вторая, а первая была еще в доковидные времена и злые языки утверждают, что проходила она при свете лучины. Но нет, всё врут! это была керосиновая лампа. В этот раз, к счастью, обошлось без отключения электроэнергии, да и вообще университет Катманду произвел приятное впечатление. В стране взросла нормальная Постгрес-тусовка, которую волнуют всё те же нетленные вопросы: почему всё тормозит, для чего использовать JSON и как мигрировать с Оракла. А декан факультета, Бал Кришна, тот вообще учился в Волгограде и до сих разумеет по-русски.

На конференцию я вез полный чемодан книжек-малюток (96 штук, двадцать с лишним кило). А в Катманду напечатали тираж «PostgreSQL 14 Internals». Сейчас ее, кстати, уже можно за небольшую денежку напечатать по требованию (paperback, hardcover), и lulu сообщает, что меньше чем за месяц двадцать книг уже приобретено. География занятна: Польша, Франция, Великобритания, Ирландия, Германия, Сербия, Португалия, Болгария, Штаты, Корея и Австралия.

На конференцию я привез обновленный двухдневный вводный курс. Предыдущую версию я читал несколько лет назад в Тель-Авиве, а в этот раз мне помогал мой коллега Павел — вдвоем гораздо веселее. И еще у меня был доклад, который я в начале 2020-го делал на московском PGConf-е, а потом перевел и подался было с ним в Европу, но тут-то и началось: то понос, то золотуха, то медные трубы тазы. А сейчас стряхнул с него пыль, подкрасил и вишь чё — пригодился.

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

Фотографий и впечатлений еще много, продолжение следует.

egorius: (Default)

На Озоне я зарегистрировался — страшно подумать! — в конце 1999-го, и с тех пор я сохранял к нему нежные чувства. Тогда это еще был небольшой книжный магазин.

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

А сегодня понадобилось кое-что сдать. Оказывается, для этого недостаточно просто прийти в пункт выдачи, а надо сначала в личном кабинете оформить заявку на возврат. В заявке для каждой позиции надо сначала выбрать причину возврата из списка, а потом непременно продублировать ее текстом в комментарии, да еще приложить минимум две фотографии. После этого надо терпеливо ожидать одобрения, а «если в течение трех дней статус заявки не изменится, ее надо удалить и обратиться в поддержку для заведения новой».

Ну что ж, до сих пор по инерции я начинал поиск с Озона, теперь буду им заканчивать.

Забавно, что сейчас многие неайтишные компании гордятся своим айти. Как, например, Додо. Вот только плохую пиццу нельзя компенсировать информационными технологиями. Ребята, съездите в Италию: для пиццы нужны не компьютеры, а что-то другое.

Озон тоже к таким относится. Митапы какие-то проводят, в конференциях участвуют. Но с микросервисом головного мозга далеко не уедешь: пока им удалось забыть все мои заказы до 2014 года и продолжает удаваться портить сайт. Эхъ.

egorius: (Default)

Рассказал на конференции об изнанке книжного дела. Получился, видимо, не совсем форматный доклад, но, надеюсь, кому-нибудь было интересно. Видео выложили, так что вот ссылочка.

И чтобы два раза не вставать, вот давний Postgres-вторник со мной на тему книги, спасибо Николаю Самохвалову и Илье Космодемьянскому. С темой доклада никак не пересекается.

Ну и до кучи: перевод книги на английский — спасибо Людмиле Мантровой.

egorius: (Default)

Листая «Компьютерную типографию» Кнута, наткнулся на ценную мысль. В главе «Набор книги Concrete Mathematics» он рассуждает о том, что в математическом шрифте Euler (который они сделали, на минуточку, с Германом Цапфом!) рисунок цифр заметно отличался от того, что используется в обычном текстовом шрифте.

...полезно и разумно различать цифры в тексте и цифры в математических выражениях. Текстовые цифры следует использовать в таких случаях, как «1776 г.», «глава 5» и «41 способ», когда числа служат составной частью обычной литературной фразы; математические цифры, напротив, должны использоваться в контексте типа «наибольшим делителем чисел 12 и 18 является 6», когда числа являются составной частью математического выражения. (Авторы технических текстов, пишущих, например, на японском языке, в котором принято использовать арабские цифры только в формулах, но не в обычном тексте, всегда хорошо чувствовали это отличие; теперь и у меня появился шанс испытать это на себе.)

Ныне никто не делает шрифты для ТеХа. LuaTeX и XeTeX научились использовать системные шрифты, и это очень здорово, но обычный труЪтайп не годится на роль математического — в нем нет нужных символов. Для наших книг я использую семейство PT в качестве основного; для математического набора уговариваю ТеХ брать оттуда же все, что можно, а недостающие глифы (типа квадратного корня) тяну из штатного математического шрифта — обычно они более или менее универсальны и не выделяются. Но это получается ужасно криво и неаккуратно. А с этой новой для меня мыслью можно попробовать решиться на то, чтобы цифры были разные, а переменная x отличалась от второй буквы слова «ухо», набранного курсивом.

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

egorius: (Default)

Банк, очевидно из-за дефицита чипов, решил сделать мою карту бессрочной. Не важно, говорят, что на ней написано 05/22, она будет работать и дальше. Ну ок, будет так будет.

Наступило первое июня и, конечно, гладкость бумаги сменилась оврагами реальности. Турникет в метро сказал «досвидос» так быстро, что стало понятно: запрос он никуда не посылал и принял решение самостоятельно. Этим же днем ситуация с моментальным отказом повторилась в кафе.

Отсюда мораль. Товарищи разработчики, не проявляйте инициативы, когда вас не просят! Передайте реквизиты в платежную систему и пусть она сама разбирается. Она лучше знает, чем вы. Жизнь, она сложнее, чем может показаться.

Тем более, что в данном случае никакой экономии нет и в помине. Каков процент владельцев карт с истекшим сроком, пытающихся оплатить ими покупки? Что страшного случится, если они получат отказ не моментально, а через пару секунд? Написали проверку, просто потому что могли. Двоечники.

egorius: (Default)

Тема сыра была популярной в 2014-м, но сейчас об этом почему-то снова стали вспоминать. Одни люди жалуются, что в магазине не купить пармезана. Другие (они, надо полагать, считают себя более патриотически настроенными) возражают:

— Во-первых, нет никаких проблем: вон, полно аргентинского пармезана. А во-вторых, наши фермеры научились варить сыр ничуть не хуже! Езжайте на рынок, попробуйте и ощутите гордость_за!

А нельзя так, чтобы и у наших все получалось, и импортный сыр можно было купить? Честное слово, я очень рад за отечественных сыроделов, у них действительно начинает кое-что получаться (и аргентинским желаю успехов, у них тоже когда-нибудь получится). Но гордость я почувствую в тот момент, когда увижу на полке итальянский пармезан по соседству с российским, и задумаюсь, какой взять.

Сыр тут, конечно, ни при чем. Можно подставить любой продукт, технологию или еще что-то, ставшее недоступным.

Больше нельзя просто так взять и полететь в Европу. — Подумаешь! Во-первых, можно съездить куда-нибудь еще, в Турцию, например. А во-вторых, у нас огромная страна, в которой полно прекрасных и удивительных мест ничуть не хуже_чем!

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

Все вопросительные предложения тут — риторические, ответ на них понятен.

* * *

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

А что получается, когда (очевидно неглупые) люди начинают притягивать политику в программирование, мы уже видим. Лишились доверия внешние зависимости: если не потеряешь данные, то как минимум узнаешь о взглядах автора. Компании уходят с нашего рынка; ушел Adobe, и теперь мне не очень понятно, как готовить следующую версию книги к требованиям типографии. Все это, безусловно, способствует установлению мира во всем мире.

А в комментариях к посту Брюса Момджяна «Abuse of Open Source?» люди рассуждают, что надо бы отлучить Postgres Pro от сообщества, дабы не помогали российской военщине. Хорошо, что управляющий комитет сохраняет адекватность, хотя уже само наличие поста говорит о том, что тема обсуждается.

Ну нафиг политику, пойду лучше рогаликов куплю.

egorius: (Default)

Ну сколько можно о говне,
Давайте лучше обо мне.
Игорь Иртеньев

А у меня, между прочим, книга вышла. Про Постгрес, конечно.

Появилась она не на пустом месте: ей предшествовали пять лет курсов (которые мы делали с Павлом Лузановым, и которые продолжаем делать расширенным составом) и статей на Хабре. И все равно работа над книгой заняла еще целый год. Не все успел написать, что хотел, зато удалось догнать паровоз PostgreSQL и включить новинки 14-й версии. А про что не успел, напишу иншалла в следующем издании.

Это был очень интересный сам себе режиссерский опыт. В книге все сделано одними руками: текст, код, рисунки, верстка, обложка. Разумеется, мне помогало много хороших людей (респект им и уважуха), но сваливать неудачи просто не на кого. Если обезумевший мир войдет в берега и PGConf состоится, расскажу на ней об этом.

Как обычно, pdf доступен свободно, а на бумаге книгу можно купить на сайте ДМК и во всех магазинах.

egorius: (Default)

Robert Heinlein, «The Moon Is a Harsh Mistress»

Непрочитанная вовремя классика. Сюжет по нашим временам несколько наивен (жители Луны борются за независимость от метрополии, а внезапно оживший суперкомпьютер им помогает), но Хайнлайн — это Хайнлайн, no huhu.

Занятно, что компьютер программируется на Логлане.

В книге полно сленга, с которым не справляются словари, но в целом все понятно.

Mike was not official name; I had nicknamed him for Mycroft Holmes, in a story written by Dr. Watson before he founded IBM.

Don’t explain computers to layman. Simpler to explain sex to a virgin.

Took an envelope from kit, dumped item on desk: corpse of house fly which I had charred with a hot wire and fetched. (о починке компьютера)

More than six people cannot agree on anything, three is better—and one is perfect for a job that one can do.

The corollary should be left as an exercise for the student.

“Sovereign,” like “love,” means anything you want it to mean; it’s a word in dictionary between “sober” and “sozzled.”

They care about skin color—by making point of how they don’t care.

When faced with a problem you do not understand, do any part of it you do understand, then look at it again.

Особенно доставляют русские словечки.

Nyet, tovarishchee.

Zdra’stvooeet’ye, Gospazha! I am most happy to see you.

Chin dropped and I said, “Bojemoi!” softly and reverently.

egorius: (Default)

Брайан Керниган, «Время UNIX»

Совсем свежая книга, собирался уже купить на Амазоне (UNIX. A History and a Memoir), а тут «Питер» выпустил перевод. Не без косячков, но вполне читабельно, молодцы. А сама книга, естественно, отличная. Погружает в атмосферу.

О Ричарде Хэмминге:

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

Он чувствовал, что программированию нужно учить, как и написанию текстов. Должно быть чувство стиля, отделяющее плохой код от хорошего. А программистов следует учить писать код и ценить хороший стиль. (см. по теме)

О Bell Labs:

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

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

Про книгоиздание:

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

Лучшее описание взаимоблокировки:

«После вас». «Нет, только после вас».

И немного о кальках с английского. Кроме заимствования слов есть и более тонкое влияние на уровне оборотов речи. Многие этого даже не замечают. Как пример: «взять такси», хотя раньше его только ловили или вызывали.

А вот из книги: обеспечивают многим программам на Awk длину в одну или две строки. В оригинале — many Awk programs are only a line or two long.

Или еще: набор из 20–30 команд, в оригинале — repertoire of 20 or 30 commands.

Конечно же, это надо переводить не дословно, а как пара строк, пара десятков команд.

egorius: (Default)

В издательстве ДМК Пресс скоро выйдет из печати книга Эдварда Сьоре (Edward Sciore) «Проектирование и реализация систем управления базами данных». Переводил Андрей Киселев, я выступал редактором. Было интересно, мы старались.

Есть довольно много книг про устройство СУБД: какие используются алгоритмы, как выглядят структуры данных. Но мало кто разбирает реализацию всех этих теоретических идей. Оно и понятно: реализации обычно слишком сложны и слишком быстро меняются, чтобы взять и внятно рассказать о них.

Автор этой книги долго учил студентов базам данных и написал под это дело «игрушечную» СУБД SimpleDB. Игрушечную в том смысле, что используются очень простые (и, как следствие, часто очень неэффективные) алгоритмы, но все необходимые компоненты «взрослых» СУБД — на месте. Главная фишка книги в том, что читатели получают не только необходимую теорию, но и песочницу для экспериментов. Сделайте так, чтобы контрольная точка не блокировала остальную работу, реализуйте обнаружение взаимоблокировок, добавьте в систему индекс на основе хеширования; научите планировщик использовать эвристики — и все это в СУБД, изучить код которой можно за неделю.

Не к минусам книги, но к особенностям могу отнести реализацию на Java. Знание этого языка требуется от читателей (впрочем, ничего заумного автор не использует). Но кому-то может наоборот хорошо зайти.

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

egorius: (Default)

Слушайте, кто все эти люди, которые пишут опенсурс?

Ведь сорс же, сорцы, аутсорс... Откуда там «у» вообще?

egorius: (Default)

Alex Petrov, «Database Internals»

Неплохой обзор технологий, связанных с хранением данных в СУБД и распределенными системами (подзаголовок книги — a deep dive into how distributed data systems work). Узнал для себя много нового.

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

Вторая часть посвящена распределенным системам. Тут дается обзор используемых технологий и алгоритмов: обнаружение сбоев, выборы лидера, репликация данных, распределенные транзакции и достижение консенсуса. Что хочу сказать: как только начинается NoSQL, проблема согласованности реплик превращается в адское месиво, потому что под флагом CAP творят что хотят и изгаляются кто во что горазд. Надеюсь, что рано или поздно вся эта буйная поросль придет к чему-то удобоваримому, будет проглочена реляционными СУБД и на некоторое время наступит всеобщее щастье.

P. S. Удивило крайне низкое качество издания. Отсутствие лигатуры «fi», формулы набраны моноширинным шрифтом (!), ужасные рамочки вокруг иллюстраций... Думал лучше об O’Reilly.

egorius: (Default)

Luca Ferrari, «PostgreSQL 11 Server Side Programming Quick Start Guide»

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

В примерах то изобретаются велосипеды, то придумывается что-то, не имеющее практического смысла. Бывают примеры откровенно глупые, а местами даже вредительские (типа, перехватывайте в ваших функциях все исключения подряд). Исключений и отката к точке сохранения автор, по-моему, вообще не понимает. Часто говорится о подробностях, явно лишних для Quick Start Guide, но что-то важное при этом недоговаривается. Делаются странные предположения о наличии или отсутствии у читателя определенных знаний.

В общем, не советую.

Ганс-Юрген Шёниг, «Осваиваем PostgreSQL 11»

Перевод второго издания Mastering PostgreSQL 11 готовится к выходу в ДМК Пресс. Прочитал, выдал издательству кучку правок и редакторских примечаний. Если все предложения будут учтены, то в кои-то веки перевод окажется лучше оригинала.

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

Где хорошие авторы, ау?

egorius: (Default)

Вот и Красноярск! Раз уж Яр, то пусть будет что-нибудь красненькое.

Вообще говоря, в Красноярске я был один раз давным-давно. Проводилась там какая-то олимпиада по программированию, и от нашего ШЮПа поехала команда. Жили мы тогда на какой-то турбазе, а города я совсем не запомнил. Из ярких воспоминаний остались мороз и подошедший через полчаса Икарус, да еще чувак с двустволкой, которому по приколу было попугать неместных.

А на олимпиаде мы заняли последнее место: дисквалифицировали нас за то, что предложили решения двух задач, а по правилам надо было выбрать только одну. Вторую я уже не помню, а вот первая была про нормальные алгоритмы Маркова (хоть они так и не назывались). Каково было мое удивление на первом курсе ВМК, когда я понял, что уже знаю тему. Очень красивая вещь, кстати.

Вручили нам по утешительному компьютерному журналу (Dr. Dobb’s это был? вот не помню), как раз хватило почитать на весь обратный полет. Тогда еще Ил-62 в Красноярск летал, мда.

egorius: (Default)

Tracy Kidder, «The Soul of a New Machine»

Книга про группу инженеров Data General, которые спроектировали и в 1980 году выпустили 32-разрядную машину Eclipse MV/8000. Проект сделали всего за полтора года в условиях жесткой конкуренции не только с DEC, но и внутри самой компании. Книга создана писателем-журналистом, который провел все это время вместе с командой: прекрасный образец захватывающего и правдивого повествования в сочетании с технической грамотностью.

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

Looking into the VAX, West had imagined he saw a diagram of DEC’s corporate organization.

No one keeps track the hours we work. That’s not altruism on Data General’s part. If anybody kept track, they’d have to pay us a hell of a lot more than they do.

Wallach spent about twenty hours in the Framingham Public Library ... just in order to add these flourishes [речь об эпиграфах] to his spec. They added something. They revealed the class of feelings that Wallach brought to his job.

The game of programming — and it was a game — was so fascinating.

The mushroom theory of management: put’em in the dark, feed’em shit, and watch’em grow.

Nothing happens unless you push it.

Promising to achieve a nearly impossible schedule was a way of signing up.

Not everything worth doing is worth doing well.

If you say you’re gonna do it in a year and you don’t take it seriously, then it’ll take three years. The game of crazy scheduling is in the category of games that you play on yourself, in order to get yourself to move.

There aren’t that many opportunities in this world to be where the action is, making an impact.

It’s a binary world; the computer might be it’s paradigm. And many engineers seem to be binary people within it. ... It doesn’t matter if you’re ugly or graceless or even half crazy; if you produce right results in this world, your colleges must accept you.

It’s hard to fix something when it’s working.

The first step in fixing something is getting it to break.

The way to stay on schedule is to make another one.

It doesn’t matter how hard you work on something. What counts is finishing and having it work.

Some problems are easy to find and hard to fix; some are hard to find and easy to fix; some go both ways.

That’s the bear trap, the greatest vice. Your job. You can justify just about any behavior with it. Maybe that’s why you do it, so you don’t have to deal with all those other problems.

egorius: (Default)

Все слова в прошлый раз сказал, теперь просто картинки.

 

 

 

 

Нашел две (всего!) программы для просмотра картинок, которые умеют управление цветом. Одна — Gwenview — какая-то совсем убогая и KDE-шная притом. Другая — Geeqie — максимально кривая, но в ней хотя бы можно вручную переставлять местами картинки. Пока не найдется что-то более адекватное, буду пользоваться ей.

В Фотошопе мне достаточно было сделать одну операцию: crop. Но это слишком просто, поэтому в GIMP надо сделать три.

Сначала crop, потом resize. Если сразу делать resize, то получается 901×600 (ну или 900×599), а это неаккуратненько. А crop не умеет менять размер, как в Фотошопе (задача висит уже 10 лет).

И еще оказалось, что встроенный в GIMP цветовой профиль sRGB — ICCv4, а браузеры обычно понимают только ICCv2. Так что третьим шагом приходится конвертировать пустое в порожнее.

При этом встроенных средств автоматизации нет, макрос записать нельзя, а предлагается немного попрограммировать на Питоне, обращаясь к функциям редактора через какую-то библиотеку. Unix way, чё.

NUC’em

Sep. 29th, 2018 11:43 pm
egorius: (Default)

Сидят как-то Диггер, командир Нортон и т. Комманд Ком, а мимо идет отец Вындоуз. «Сидите, — говорит. — Ну, ну. Скоро все подо мной сидеть будете». Никто ему так ничего и не ответил. Один т. Комманд Ком сплюнул и грязно выругался. «Проходи, проходи, — сказал, — оболочка дешевая».

Александ Голубев, «Притчи о компьютерных жителях»

Решил давно назревавший вопрос апгрейда — обзавелся зверьком по имени Intel NUC. Благодаря добрым людям™, подогнавшим скидку, на смену огромному ящику пришла маленькая коробочка, щедро набитая памятью и SSD.

Заодно избавился и от богомерзкого Вындоуза. С семеркой я еще как-то свыкся, но десятка — чур меня, чур. NUC хоть официально и не поддерживает ничего_кроме, однако Xubuntu 18.10 встала, как родная.

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

Во-первых, диск. За прожитые годы накопилось примерно 2 ТБ барахла, с которым жалко расставаться. Внутрь (помимо SSD M.2) влезает еще диск 2.5", но все модели больше 2 ТБ имеют нестандартную высоту 15 мм и тупо не помещаются. Поэтому единственный устраивающий вариант — внешний USB-диск.

Первое, что я попробовал — ADATA с Western Digital WD40NPZZ на 4 ТБ внутри. Когда он показал скорость чтения на уровне 3–4 МБ/сек, я заподозрил неладное, полез разбираться и обнаружил две проблемы. Первая — технология® 512e: внутри диск работает с секторами по 4 КБ, но притворяется, что по 512 байт (чтобы не нарушать отчетности). Если не выровнять начало раздела по границе физического сектора, получим лишние дисковые операции. Вроде бы Линукс должен это и сам понимать, но нет, не понимает.

После переформатирования скорость последовательного чтения выросла до фантастических 15 МБ/сек, и запись была примерно на том же уровне. Дальнейшее вскрытие показало, что в этом диске (и, похоже, уже во всех 4+ ТБ) применяется технология® SMR. Она увеличивает плотность записи ценой того, что приходится не только записывать свою дорожку, но и перезаписывать соседние. Тормозные, короче, диски от рождения, а еще и у ядра Линукса что-то не ладится с их поддержкой.

Как это влияет на скорость чтения я не понял, но тут диск начал покрываться битыми секторами и я с нескрываемым удовольствием отнес его обратно. Возможно, вдобавок ко всему еще и экземпляр достался бракованный.

После этого я купил самый большой диск со старой технологией™ PMR, какой смог найти: Toshiba Canvio Connect II на 3 ТБ. На этом все проблемы с внешней памятью внезапно закончились.

Во-вторых, виртуализация mac OS. Макось нужна мне только для запуска RPP, но без нее никак. Раньше я прекрасно обходился стареньким Снежным Леопардом, но под новым VirtualBox он отказался запускаться, мотивируя это паникой ядра. На борьбу было потрачено много сил; в итоге пришлось плюнуть и влезть на Высокую Гору.

В-третьих, управление цветом. Был приятно удивлен, что DisplayCAL отлично дружит с моим X-Rite i1Display Pro, создает нужный профиль и сам загружает его куда следует. Понятно, что найти под Линукс программу, умеющую управление цветом, не просто, но можно (и GIMP среди них).

Беда пришла, откуда не ждали: Макось не захотела прислушиваться к цветовому профилю. Наверное, именно на эту проблему было убито больше всего времени. В итоге все оказалось просто: какой-то дурацкий баг в последней бете RPP. Взял стабильную версию и все заработало.

В-четвертых, камера. Ждал засаду, потому что под Вындоуз Fujifils X100S видна только из Проводника® как какое-то спецустройство. Но нет, в Линуксе камера монтируется как обычный диск, и это прекрасно.

В-пятых, каталогизатор. Собственно, я сам себе каталогизатор и вручную все раскладываю по каталогам, так что нужен просто удобный способ быстро просматривать тонны картинок. Раньше пользовался Гугловской Пикасой. Что теперь — пока не понял. Вообще выбор невелик, поскольку нужно управление цветом.

В-шестых, Фотошоп. Была идея запустить настоящий Фотошоп в Макоси, но CS2 с известным ключом оказался еще PowerPC-шным, эмуляция доступна только в Снежном Леопарде, который не работает... В общем, попробую обойтись без него.

Собственно, от Фотошопа мне обычно нужен только кроп и нерезкое маскирование. С первым GIMP точно справляется, второе пока не пробовал, но тоже должен. Делали его, конечно, криворукие чудаки, но в Линуксе, увы, весь графический интерфейс такой.

Занятно, что в репозитории Xubuntu лежит GIMP 2.8, а чтобы поставить свежий 2.10 приходится использовать какой-то неведомый flatpak. Обилие всяких пакетных систем немного обескураживает.

Profile

egorius: (Default)
egorius

July 2025

M T W T F S S
  123456
78910111213
14151617181920
21222324252627
28293031   

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Jul. 1st, 2025 09:59 pm
Powered by Dreamwidth Studios